Discussion:
UUCP for VMS
(too old to reply)
Bill Gunshannon
2017-04-08 16:17:08 UTC
Permalink
Assuming at least some here saw my recent comments about UUCP,
I have a question.

I recently acquired an O'Reilly book on UUCP to refresh my memory
on setting up and running UUCP Systems. It has an interesting
comment in the appendix on "UUCP for Non-UNIX Platforms".

UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.

Just out of curiosity, is there really anything that drastic that
would have changed to make the software no longer usable under VMS?

I am thinking of taking a look at it with the hope of getting a VMS
system up on the network. And, who knows, maybe some VMS users might
be happy to move back to the days when SPAM wasn't a problem. The
number of VMS users worldwide is probably an easily manageable number
so that they could all communicate with each other using a network that
doesn't suffer from many of the "advantages" of SMTP.

bill
Robert A. Brooks
2017-04-08 16:22:33 UTC
Permalink
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.

So, it's likely that DECUS UUCP *will* run on OpenVMS VAX V5.5.
--
-- Rob
Bill Gunshannon
2017-04-08 16:39:37 UTC
Permalink
Post by Robert A. Brooks
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.
So, it's likely that DECUS UUCP *will* run on OpenVMS VAX V5.5.
Yes, but would it run on any modern version of OpenVMS or has something
been changed that is likely to obsolete older software? I always thought
VMS prided itself on not obsoleting old systems.

In any event, if I find the time to setup one of my VAXStations with a
7.something version of VMS I might find it interesting to try a port of
Taylor UUCP (because I would want UUCP over IP and not over a telephone
line.)

bill
Arne Vajhøj
2017-04-08 21:04:32 UTC
Permalink
Post by Robert A. Brooks
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.
I thought it was 5.5-2 that got the "Open" when POSIX support was added!?

Arne
Stephen Hoffman
2017-04-08 21:30:20 UTC
Permalink
Post by Arne Vajhøj
I thought it was 5.5-2 that got the "Open" when POSIX support was added!?
"What became confusing is that the OpenVMS name was introduced first
for OpenVMS AXP V1.0 causing the widespread misimpression that OpenVMS
was for Alpha AXP only, while ‘‘regular VMS’’ was for VAX. In fact, the
official name of the VAX operating system was changed as of V5.5,
though the name did not start to be actually used in the product until
V6.0."
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2017-04-08 23:47:16 UTC
Permalink
Post by Arne Vajhøj
I thought it was 5.5-2 that got the "Open" when POSIX support was added!?
"What became confusing is that the OpenVMS name was introduced first for
OpenVMS AXP V1.0 causing the widespread misimpression that OpenVMS was
for Alpha AXP only, while ‘‘regular VMS’’ was for VAX. In fact, the
official name of the VAX operating system was changed as of V5.5, though
the name did not start to be actually used in the product until V6.0."
Thank you, once again, Stephen. Much greater detail but closer to what
I remembered.

bill
Paul Sture
2017-04-08 22:48:20 UTC
Permalink
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.
I thought it was 5.5-2 that got the "Open" when POSIX support was added!?
From the "VMS at 20" book.

1991

• OpenVMS name change announced.
• NVAX, DIGITAL’s fourth VAX microprocessor, implemented in 0.75-micrometer
CMOS technology; shipped in VAX 6600 systems.
• OpenVMS V5.5 shipped.
• DIGITAL and Microsoft Corporation announced alliance allowing
Microsoft Windows to retrieve and exchange data with local area
network servers running DIGITAL PATHWORKS software.
• DECnet Phase V announced.

and

OpenVMS/AXP V1.0 November 1992 - Alpha is here!

• Support for new Alpha processors DEC 3000 Models 400, 400S, 500 & 500S DEC
4000 Model 600 DEC 7000 Model 610
• Based on VMS V5.4
• DECmigrate for translating VAX images
• MACRO-32 compiler
• No clusters, no RMS journaling, no shadowing, no SMP

OpenVMS/VAX V6.0 June 1993
• Support for new processors – VAX 7000 Model 650/660, VAX 10000 Model
650/660
• Rationalized and Enhanced security (Level C2 compliance)
• Multiple queue managers across cluster
• HELP/MESSAGE utility
• Support for ISO 9660 CD-ROM format
• Adaptive Pool Management
• SYSMAN cluster wide SHUTDOWN and startup logging
• Cluster wide Virtual I/O cache
• Extended physical and virtual addressing
• Protected subsystems
• DECnet/OSI
• DECwindows XUI replaced by DECwindows Motif
--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.
j***@yahoo.co.uk
2017-04-10 13:11:37 UTC
Permalink
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.
I thought it was 5.5-2 that got the "Open" when POSIX support was added!?
From the "VMS at 20" book.
1991
• OpenVMS name change announced.
• NVAX, DIGITAL’s fourth VAX microprocessor, implemented in 0.75-micrometer
CMOS technology; shipped in VAX 6600 systems.
• OpenVMS V5.5 shipped.
• DIGITAL and Microsoft Corporation announced alliance allowing
Microsoft Windows to retrieve and exchange data with local area
network servers running DIGITAL PATHWORKS software.
• DECnet Phase V announced.
and
OpenVMS/AXP V1.0 November 1992 - Alpha is here!
• Support for new Alpha processors DEC 3000 Models 400, 400S, 500 & 500S DEC
4000 Model 600 DEC 7000 Model 610
• Based on VMS V5.4
• DECmigrate for translating VAX images
• MACRO-32 compiler
• No clusters, no RMS journaling, no shadowing, no SMP
OpenVMS/VAX V6.0 June 1993
• Support for new processors – VAX 7000 Model 650/660, VAX 10000 Model
650/660
• Rationalized and Enhanced security (Level C2 compliance)
• Multiple queue managers across cluster
• HELP/MESSAGE utility
• Support for ISO 9660 CD-ROM format
• Adaptive Pool Management
• SYSMAN cluster wide SHUTDOWN and startup logging
• Cluster wide Virtual I/O cache
• Extended physical and virtual addressing
• Protected subsystems
• DECnet/OSI
• DECwindows XUI replaced by DECwindows Motif
--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.
Thank you.

Useful content, with context, and an attributed source (not
just Wikipedia). Always useful, not just round here.

Much better (usually) than an anonymous context-free quote
with no context.

Your "first of April" sig cookie seems particularly
appropriate in the circumstances.

Have a lot of fun.
Paul Sture
2017-04-13 09:35:19 UTC
Permalink
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.
I thought it was 5.5-2 that got the "Open" when POSIX support was added!?
From the "VMS at 20" book.
1991
• OpenVMS name change announced.
• NVAX, DIGITAL’s fourth VAX microprocessor, implemented in 0.75-micrometer
CMOS technology; shipped in VAX 6600 systems.
• OpenVMS V5.5 shipped.
• DIGITAL and Microsoft Corporation announced alliance allowing
Microsoft Windows to retrieve and exchange data with local area
network servers running DIGITAL PATHWORKS software.
• DECnet Phase V announced.
and
OpenVMS/AXP V1.0 November 1992 - Alpha is here!
• Support for new Alpha processors DEC 3000 Models 400, 400S, 500 & 500S DEC
4000 Model 600 DEC 7000 Model 610
• Based on VMS V5.4
• DECmigrate for translating VAX images
• MACRO-32 compiler
• No clusters, no RMS journaling, no shadowing, no SMP
OpenVMS/VAX V6.0 June 1993
• Support for new processors – VAX 7000 Model 650/660, VAX 10000 Model
650/660
• Rationalized and Enhanced security (Level C2 compliance)
• Multiple queue managers across cluster
• HELP/MESSAGE utility
• Support for ISO 9660 CD-ROM format
• Adaptive Pool Management
• SYSMAN cluster wide SHUTDOWN and startup logging
• Cluster wide Virtual I/O cache
• Extended physical and virtual addressing
• Protected subsystems
• DECnet/OSI
• DECwindows XUI replaced by DECwindows Motif
--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.
Thank you.
Useful content, with context, and an attributed source (not
just Wikipedia). Always useful, not just round here.
Thank you. I have quoted from that source so many times over the years
that it would have been worth my while sticking it into a bunch of
editor buffers (or wherever), preformatted for usenet posting.

I might just do that for next time :-)
Post by j***@yahoo.co.uk
Much better (usually) than an anonymous context-free quote
with no context.
Your "first of April" sig cookie seems particularly
appropriate in the circumstances.
Have a lot of fun.
You too.
--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.
Kerry Main
2017-04-13 12:51:14 UTC
Permalink
-----Original Message-----
Sture via Info-vax
Sent: April 13, 2017 5:35 AM
Subject: Re: [Info-vax] UUCP for VMS
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax
system. We
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run
on OpenVMS.
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp
and
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Bill Gunshannon
runs under VMS 5.4-x or VMS 5.5.
There is an inconsistency above. The name "OpenVMS" came
about (I think)
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
around the time of VAX/VMS V5.4. Wikipedia claims that it first
showed
Post by j***@yahoo.co.uk
Post by Paul Sture
Post by Arne Vajhøj
Post by Robert A. Brooks
up around VAX/VMS V5.4-2, which sounds about right.
I thought it was 5.5-2 that got the "Open" when POSIX support was
added!?
Post by j***@yahoo.co.uk
Post by Paul Sture
From the "VMS at 20" book.
1991
• OpenVMS name change announced.
• NVAX, DIGITAL’s fourth VAX microprocessor, implemented in
0.75-micrometer
CMOS technology; shipped in VAX 6600 systems.
• OpenVMS V5.5 shipped.
• DIGITAL and Microsoft Corporation announced alliance allowing
Microsoft Windows to retrieve and exchange data with local area
network servers running DIGITAL PATHWORKS software.
• DECnet Phase V announced.
and
OpenVMS/AXP V1.0 November 1992 - Alpha is here!
• Support for new Alpha processors DEC 3000 Models 400, 400S, 500
& 500S DEC
4000 Model 600 DEC 7000 Model 610
• Based on VMS V5.4
• DECmigrate for translating VAX images
• MACRO-32 compiler
• No clusters, no RMS journaling, no shadowing, no SMP
OpenVMS/VAX V6.0 June 1993
• Support for new processors – VAX 7000 Model 650/660, VAX
10000 Model
Post by j***@yahoo.co.uk
Post by Paul Sture
650/660
• Rationalized and Enhanced security (Level C2 compliance)
• Multiple queue managers across cluster
• HELP/MESSAGE utility
• Support for ISO 9660 CD-ROM format
• Adaptive Pool Management
• SYSMAN cluster wide SHUTDOWN and startup logging
• Cluster wide Virtual I/O cache
• Extended physical and virtual addressing
• Protected subsystems
• DECnet/OSI
• DECwindows XUI replaced by DECwindows Motif
--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.
Thank you.
Useful content, with context, and an attributed source (not
just Wikipedia). Always useful, not just round here.
Thank you. I have quoted from that source so many times over the years
that it would have been worth my while sticking it into a bunch of
editor buffers (or wherever), preformatted for usenet posting.
I might just do that for next time :-)
Post by j***@yahoo.co.uk
Much better (usually) than an anonymous context-free quote
with no context.
Your "first of April" sig cookie seems particularly
appropriate in the circumstances.
Have a lot of fun.
You too.
Re: VMS at 20 ..

A nice VMS at 20 brochure for those that like to walk down memory lane: (great read, really shows the creativity of those involved, importance of Fortran/Cobol in design and lots of great pics - including Ronald Regan with Ken Olsen!)

<http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623368>

A few extracts:
"Creativity with discipline. From its inception, DIGITAL realized the importance of creativity, and sought to create an environment in which individual creativity would thrive within a disciplined environment. The strategy was to hire talented people and empower them to develop plans, have those plans reviewed and approved, and to accept ownership of the project. The company believed that people would be most productive when they had to meet milestones and stay within a budget—this is where the discipline factor came in. Each product line group was responsible for meeting its plan within time and budget constraints."

"Dave Cutler started the first VMS April Fool’s jokes. One year, Andy Goldstein replaced the line printer driver so that everything printed out backwards. On another April 1, the entire system message file was replaced with joke messages—including ones like “File not found. Where did you leave it?”

"The DEC-10 was used to compile the VMS modules written in Bliss because at the time the Bliss compiler only ran on a DEC-10. The Bliss code had to be transported by tape to the PDP-11 to be linked."

And something related to what Steve has been pushing-
"As the technical writer, my belief was that the technical writer is the advocate for the customer. So I always put myself in the shoes of someone who is trying to learn how to use the system, and wrote the documentation accordingly. The VMS Documentation Group grew from five people in 1977 to 45 in 1987, and the documentation set grew from 9,000 to 20,000 pages. It was a massive effort.”

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Phillip Helbig (undress to reply)
2017-04-13 14:51:27 UTC
Permalink
I don't know if this is the same one I am familiar with. There is a
scene where a manager says "Our three goals on this project are: time to
market, time to market, time to market." An engineer then asked "What
about quality?" The reply was: "Quality is not a goal; it is a given."

Those were the days.
Michael Moroney
2017-04-08 16:44:37 UTC
Permalink
Post by Bill Gunshannon
I recently acquired an O'Reilly book on UUCP to refresh my memory
on setting up and running UUCP Systems. It has an interesting
comment in the appendix on "UUCP for Non-UNIX Platforms".
Does anyone still use UUCP?
Post by Bill Gunshannon
Just out of curiosity, is there really anything that drastic that
would have changed to make the software no longer usable under VMS?
I'm going to guess that they were thinking going from VMS->OpenVMS was
a huge step from a major OS overhaul or something. Or perhaps going
from VAX to Alpha was. VAX->Alpha was largely recompile and go for non
system software, with the major exception of Macro-32. You had to do a
lot of things to make the stricter Alpha compiler happy in many cases.
Bill Gunshannon
2017-04-08 17:01:09 UTC
Permalink
Post by Michael Moroney
Post by Bill Gunshannon
I recently acquired an O'Reilly book on UUCP to refresh my memory
on setting up and running UUCP Systems. It has an interesting
comment in the appendix on "UUCP for Non-UNIX Platforms".
Does anyone still use UUCP?
Other than there the fact that there is a group (called HECNET for a
reason I don't know) who have a UUCP Network running much like the
people who have the DECNET Network running, there is also an effort
right now to setup a simulation of the original 80's USENET for the
upcoming (2019) 50th Anniversary of UNIX. It is going to be comprised
of mostly emulated system with historical names but is also accepting
modern, non-historical, systems. I have my first system up running
Taylor UUCP on FreeBSD. Not historical, but then my interests run
more along the lines of UUCP as practical solution to a real world
problem than just a museum artifact. I would hope people here would
also understand the notion that old does not necessarily mean bad and
sometimes a solution has been before our eyes for ages but jaundice
prevents us seeing it.
Post by Michael Moroney
Post by Bill Gunshannon
Just out of curiosity, is there really anything that drastic that
would have changed to make the software no longer usable under VMS?
I'm going to guess that they were thinking going from VMS->OpenVMS was
a huge step from a major OS overhaul or something. Or perhaps going
from VAX to Alpha was. VAX->Alpha was largely recompile and go for non
system software, with the major exception of Macro-32. You had to do a
lot of things to make the stricter Alpha compiler happy in many cases.
Interesting. So you think no one actually tried it just assumed VMS
and OpenVMS were not necessarily the same OS. (I actually thought the
OpenVMS moniker came much later than V5.4 but if Wiki said it, it must
be true and accurate. :-)

I'll have to start by just trying the DECUS version to see what it does.

bill
Scott Dorsey
2017-04-08 22:45:08 UTC
Permalink
Post by Bill Gunshannon
Just out of curiosity, is there really anything that drastic that
would have changed to make the software no longer usable under VMS?
A bunch of new protocols were added around that time to support some of
the high performance modems that became available around then. So there
were a lot of changes to the code base. If you just intend on using g
or i protocol and nothing else you might be fine.

I believe there were also a lot of changes made to MAIL-11 at the time
too, so compatibility with the mail system may be an issue.
Post by Bill Gunshannon
I am thinking of taking a look at it with the hope of getting a VMS
system up on the network. And, who knows, maybe some VMS users might
be happy to move back to the days when SPAM wasn't a problem. The
number of VMS users worldwide is probably an easily manageable number
so that they could all communicate with each other using a network that
doesn't suffer from many of the "advantages" of SMTP.
I think you'll find that running uucp in this day and age is a nightmare,
in part because spam is a problem. And if you think it's a problem with
a fat pipe, it becomes a huge one when your fat pipe is run down into a
narrower one.

There are still reasons to run uucp today; we had a customer until about
two years ago who was served off a satellite in molnya orbit who only had
connectivity in short bursts, during which time we would batch transfer
mail to them. That customer now has a modern network connection, though,
and every day there are fewer and fewer reasons.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Bill Gunshannon
2017-04-08 23:44:23 UTC
Permalink
Post by Scott Dorsey
Post by Bill Gunshannon
Just out of curiosity, is there really anything that drastic that
would have changed to make the software no longer usable under VMS?
A bunch of new protocols were added around that time to support some of
the high performance modems that became available around then. So there
were a lot of changes to the code base. If you just intend on using g
or i protocol and nothing else you might be fine.
True, but all the other systems will still talk the old protocols so
that doesn't really break anything.
Post by Scott Dorsey
I believe there were also a lot of changes made to MAIL-11 at the time
too, so compatibility with the mail system may be an issue.
Unless it turned mail into something other than a 7bit clean text based
system it should not have affected it either. But as a side note, are
you saying VMS Mail is MAIL-11? I thought that was an RSX thing.
Post by Scott Dorsey
Post by Bill Gunshannon
I am thinking of taking a look at it with the hope of getting a VMS
system up on the network. And, who knows, maybe some VMS users might
be happy to move back to the days when SPAM wasn't a problem. The
number of VMS users worldwide is probably an easily manageable number
so that they could all communicate with each other using a network that
doesn't suffer from many of the "advantages" of SMTP.
I think you'll find that running uucp in this day and age is a nightmare,
Having run both SMTP based and UUCP based mail systems I think I can
safely say UUCP is a breeze. Took me less than an hour to have it
up and running. Taylor UUCP (not in the default FreeBSD installation)
and PostFix (also not in the default FreeBSD installation but much
better than Sendmail).
Post by Scott Dorsey
in part because spam is a problem. And if you think it's a problem with
a fat pipe, it becomes a huge one when your fat pipe is run down into a
narrower one.
Ummmm... Spam isn't a problem at all on a UUCP network. It happens at
most once and then the peer is gone. It is also possible to actually
make the offender pay, which can not be done on the Internet as it
exists today. Why is it that intelligent people can't understand how
UUCP Networks actually function (compared to how email is moved on the
Internet using SMTP)?
Post by Scott Dorsey
There are still reasons to run uucp today; we had a customer until about
two years ago who was served off a satellite in molnya orbit who only had
connectivity in short bursts, during which time we would batch transfer
mail to them. That customer now has a modern network connection, though,
and every day there are fewer and fewer reasons.
The availability of highspeed networks has eliminated the only downside
that UUCP ever had. How would you like to have a network that let you
discuss VMS, communicate with other VMS developers, users and VARS with
no possibility of Spam or phishing attacks or any kind of spoofed
emails or news articles? And, no, BITNET isn't coming back. (Although I
still wish I could find a copy of the J-Net software in source for
playing with.)

bill
Scott Dorsey
2017-04-09 00:12:17 UTC
Permalink
Post by Bill Gunshannon
Post by Scott Dorsey
in part because spam is a problem. And if you think it's a problem with
a fat pipe, it becomes a huge one when your fat pipe is run down into a
narrower one.
Ummmm... Spam isn't a problem at all on a UUCP network. It happens at
most once and then the peer is gone. It is also possible to actually
make the offender pay, which can not be done on the Internet as it
exists today. Why is it that intelligent people can't understand how
UUCP Networks actually function (compared to how email is moved on the
Internet using SMTP)?
But we don't live on a uucp network. We live in the IP world, and unless
you are going to have an isolated mail system with no connection to the
real world, you're going to be taking mail from the big IP pipe and stuffing
it down that uucp connection.

And when you stuff spam from the big pipe into the little pipe, the little
pipe clogs up fast.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Bill Gunshannon
2017-04-09 00:39:33 UTC
Permalink
Post by Scott Dorsey
Post by Bill Gunshannon
Post by Scott Dorsey
in part because spam is a problem. And if you think it's a problem with
a fat pipe, it becomes a huge one when your fat pipe is run down into a
narrower one.
Ummmm... Spam isn't a problem at all on a UUCP network. It happens at
most once and then the peer is gone. It is also possible to actually
make the offender pay, which can not be done on the Internet as it
exists today. Why is it that intelligent people can't understand how
UUCP Networks actually function (compared to how email is moved on the
Internet using SMTP)?
But we don't live on a uucp network.
That's a choice that can be remedied. Why does everyone automatically
assume it has to be one or the other?
Post by Scott Dorsey
We live in the IP world, and unless
you are going to have an isolated mail system with no connection to the
real world, you're going to be taking mail from the big IP pipe and stuffing
it down that uucp connection.
Or, you could have two where one of them is loaded with spam which you
can't aggressively filter without the very real danger of missing emails
that me be important, especially if your a business. But you can have
two separate networks that allow some of your traffic, possibly your
most important traffic protected. Right now, the way I am reading and
replying to this I am using a mail client that shows me three different
"folders". Two of them are totally separate news servers. One carries
all the real stuff and periodically some spam slips thru even though
they do their best to prevent it. Of course that leaves open the
question, "What articles have I not seen because their spam filters
mistook it for spam and deleted it?" And then I have a third folder
is email on a machine that I use for mailing lists. I have two other
email servers I use and I could just as easily put them in there, too
but I prefer not to at this time. Accessing info from multiple sources
is common today. Why not put it to good use? The resources needed to
setup UUCP are trivial. As I stated, I setup a FreeBSD 11.0 box and
in one hour was on a UUCP network doing email and news. (both completely
separate from the Internet) At the FreeBSD site you can even get a
ready to run vhd file so that you could set it up on a VM anywhere.
(I have a copy running on VirtualBOX on the system with all my other
test and research systems.) Nothing to it.

How does this apply to c.o.v, you ask?

Simple, really. My concept of reviving UUCP works best in what one
would see as "Independant Email Domains". The VMS Community is one
such Domain. There are multiple ways of setting it all up but because
of the nature of the Domain it can be quite simple. Let's start by
having some soul volunteer to be a hub. (VSI? Island? Hoffman Labs?
or even some individual but preferably not someone at home using
dyndns.) And then all the other members of the VMS Community establish
a UUCP link with the hub. And you know have a private email domain
strictly for the business of discussing VMS, doing VMS business or any
other thing the Community sees as desired. No SPAM. Connectivity is
determined by the admin at the hub. You grant, restrict or remove users
based on the norms of the Community. You could even run news as well
with your own collection of groups. Instead of just c.o.v you could
have any number of finely targeted groups for discussing technical
issues, business issues, social issues (like who is buying the beer, not
what political system is best). Of course, it doesn't need to be single
hub. It an be multi-hub or even full-mesh, but the hub structure ends
out having the least overhead at the network level.

Think about it.

bill
Post by Scott Dorsey
And when you stuff spam from the big pipe into the little pipe, the little
pipe clogs up fast.
--scott
j***@gmail.com
2017-04-09 08:01:55 UTC
Permalink
Post by Bill Gunshannon
Post by Scott Dorsey
But we don't live on a uucp network.
That's a choice that can be remedied. Why does everyone automatically
assume it has to be one or the other?
Because we have a tcp/ip network that is cheap, far faster, etc., etc.
Post by Bill Gunshannon
Simple, really. My concept of reviving UUCP works best in what one
would see as "Independant Email Domains". The VMS Community is one
such Domain. There are multiple ways of setting it all up but because
of the nature of the Domain it can be quite simple. Let's start by
having some soul volunteer to be a hub. (VSI? Island? Hoffman Labs?
or even some individual but preferably not someone at home using
dyndns.) And then all the other members of the VMS Community establish
a UUCP link with the hub. And you know have a private email domain
strictly for the business of discussing VMS, doing VMS business or any
other thing the Community sees as desired. No SPAM. Connectivity is
determined by the admin at the hub. You grant, restrict or remove users
based on the norms of the Community.
But, see, you don't need the uucp transport layer for that at all. All you need are mail servers that only talk to certain other mail servers, for the mail traffic in their domain.
Post by Bill Gunshannon
You could even run news as well
with your own collection of groups. Instead of just c.o.v you could
have any number of finely targeted groups for discussing technical
issues, business issues, social issues (like who is buying the beer, not
what political system is best). Of course, it doesn't need to be single
hub. It an be multi-hub or even full-mesh, but the hub structure ends
out having the least overhead at the network level.
You can do this right now with news servers and news reader software. Again, the transport layer is irrelevant. ANU NEWS, the news reader that we pulled into the DECUS UUCP package (thanks to Mark Pizzolato for writing the "glue" to UUCP and figuring out how to hook it all up), is already also a fully fledged netnews server too. And (just like Unix news software) it didn't need uucp; in fact it was originally put on the DECUS tapes in a form that would exchange news over tcp/ip (with both other ANU NEWS systems and Unix news servers). The only reason to ever use uucp for news was if you didn't have tcp/ip internet available.

I don't know if it was ever built for Alpha binaries either.

And again, see, you don't need uucp to set up a "private news domain". You just configure your news clients and servers to only talk to the other clients and servers you choose.

(It also became a complete dog when the number of saved news items in a newsgroup became too large, thanks to some unfortunate dependencies on the implementations of Files-11. Again, I never heard word of an improved version.)

Jamie Hanrahan
***@cmkrnl.com
Bill Gunshannon
2017-04-09 14:38:14 UTC
Permalink
Post by j***@gmail.com
Post by Bill Gunshannon
Post by Scott Dorsey
But we don't live on a uucp network.
That's a choice that can be remedied. Why does everyone automatically
assume it has to be one or the other?
Because we have a tcp/ip network that is cheap, far faster, etc., etc.
I'm not talking about replacing tcp/ip. UUCP can run on top of it.
Just like SMTP, FTP and SSH.
Post by j***@gmail.com
Post by Bill Gunshannon
Simple, really. My concept of reviving UUCP works best in what one
would see as "Independant Email Domains". The VMS Community is one
such Domain. There are multiple ways of setting it all up but because
of the nature of the Domain it can be quite simple. Let's start by
having some soul volunteer to be a hub. (VSI? Island? Hoffman Labs?
or even some individual but preferably not someone at home using
dyndns.) And then all the other members of the VMS Community establish
a UUCP link with the hub. And you know have a private email domain
strictly for the business of discussing VMS, doing VMS business or any
other thing the Community sees as desired. No SPAM. Connectivity is
determined by the admin at the hub. You grant, restrict or remove users
based on the norms of the Community.
But, see, you don't need the uucp transport layer for that at all. All you need are mail servers that only talk to certain other mail servers, for the mail traffic in their domain.
In your example it becomes one or the other. Without massive white-
listing and black-listing (a major administrative nightmare) how do
you propose top keep trusted email separate from the rest of the
Internet with all its spam and malware?
Post by j***@gmail.com
Post by Bill Gunshannon
You could even run news as well
with your own collection of groups. Instead of just c.o.v you could
have any number of finely targeted groups for discussing technical
issues, business issues, social issues (like who is buying the beer, not
what political system is best). Of course, it doesn't need to be single
hub. It an be multi-hub or even full-mesh, but the hub structure ends
out having the least overhead at the network level.
You can do this right now with news servers and news reader software. Again, the transport layer is irrelevant. ANU NEWS, the news reader that we pulled into the DECUS UUCP package (thanks to Mark Pizzolato for writing the "glue" to UUCP and figuring out how to hook it all up), is already also a fully fledged netnews server too. And (just like Unix news software) it didn't need uucp; in fact it was originally put on the DECUS tapes in a form that would exchange news over tcp/ip (with both other ANU NEWS systems and Unix news servers). The only reason to ever use uucp for news was if you didn't have tcp/ip internet available.
I don't know if it was ever built for Alpha binaries either.
And again, see, you don't need uucp to set up a "private news domain". You just configure your news clients and servers to only talk to the other clients and servers you choose.
(It also became a complete dog when the number of saved news items in a newsgroup became too large, thanks to some unfortunate dependencies on the implementations of Files-11. Again, I never heard word of an improved version.)
Jamie Hanrahan
I am merely offering an alternative with much less administrative
effort to clean up the morass that is the current status quo.

I would have commented more on what you said but working with the 500
character lines was just more than I could deal with today.

bill
j***@gmail.com
2017-04-10 05:37:04 UTC
Permalink
Post by Bill Gunshannon
Post by j***@gmail.com
Post by Bill Gunshannon
Post by Scott Dorsey
But we don't live on a uucp network.
That's a choice that can be remedied. Why does everyone automatically
assume it has to be one or the other?
Because we have a tcp/ip network that is cheap, far faster, etc., etc.
I'm not talking about replacing tcp/ip. UUCP can run on top of it.
Just like SMTP, FTP and SSH.
In your example it becomes one or the other. Without massive white-
listing and black-listing (a major administrative nightmare) how do
you propose top keep trusted email separate from the rest of the
Internet with all its spam and malware?
Simple: Your servers for your trusted sites don't gateway the email to the greater internet.
Post by Bill Gunshannon
I am merely offering an alternative with much less administrative
effort to clean up the morass that is the current status quo.
I just don't see that manually configuring the systems. file, which is a
list of your "neighbor" systems, amounts to "much less
administrative effort". Same for the need to construct bang paths.
Post by Bill Gunshannon
I would have commented more on what you said but working with the 500
character lines was just more than I could deal with today.
(You're still hitting return other than at paragraph breaks? Whatever
you're using for a newsreader doesn't autowrap long lines?)
Post by Bill Gunshannon
UUCP is much better than SMTP.
Um... uucp, _per se_, isn't a mail transfer protocol at all.
It's just a file transfer mechanism. It's far more akin to ftp than
to smtp. The uucp protocols (g, f, etc.) don't know a thing about email.
(Or netnews.)

uucp suites generally do include uux (which sends a command to a remote
system and requests that it execute it) and uuxqt (which is the command
server that runs on the remote system). Mail over uucp uses that. The details on how file transfers are made to perform as a mail transport mechanism, they're in the "UUCP 'g' Protocol Description" that I wrote -
I think it's bundled in the DECUS uucp package.

The DECUS uucp implementation of uuxqt never implemented anything
except the "rmail" and the equivalent news-import command, as the
security issues with remote command execution were something we
just didn't want to touch. Accordingly we had no uux at all - our
foreign mail protocol interface just hand-generates the necessary
"work files" ("X" and "D" files) and sends 'em over. Same for the
news interface.

If all you need to do is transfer a couple of files, and you have IP
connectivity, why bother running uucp (any uucp protocol, doesn't
matter) over IP? Why not just use ftp? (Heck, you could use Kermit
for that matter.)

If you uuxqt-style mail transfer is much better than SMTP,
why do you think it didn't replace SMTP/POP?

It sounds like your real goal is a private network of mail and news
servers. Well, again, you can have that right now with existing
internet protocols. I'm not sure why the configuration task would
be any more work than using uucp as the transport layer.

And, again, mail routing is going to be an issue for the users...
unless either a) you have one common hub and everyone else talks to them (would suck to be them) or b) everyone talks to literally everyone else.

Jamie Hanrahan
***@cmkrnl.com
Bill Gunshannon
2017-04-10 12:59:41 UTC
Permalink
Post by j***@gmail.com
Post by Bill Gunshannon
Post by j***@gmail.com
Post by Bill Gunshannon
Post by Scott Dorsey
But we don't live on a uucp network.
That's a choice that can be remedied. Why does everyone automatically
assume it has to be one or the other?
Because we have a tcp/ip network that is cheap, far faster, etc., etc.
I'm not talking about replacing tcp/ip. UUCP can run on top of it.
Just like SMTP, FTP and SSH.
In your example it becomes one or the other. Without massive white-
listing and black-listing (a major administrative nightmare) how do
you propose top keep trusted email separate from the rest of the
Internet with all its spam and malware?
Simple: Your servers for your trusted sites don't gateway the email to the greater internet.
If you mean gateway the UUCP email, your right, they don't that's the
purpose of having a second, secure network.
Post by j***@gmail.com
Post by Bill Gunshannon
I am merely offering an alternative with much less administrative
effort to clean up the morass that is the current status quo.
I just don't see that manually configuring the systems. file, which is a
list of your "neighbor" systems, amounts to "much less
administrative effort". Same for the need to construct bang paths.
When I was doing UUCP (before there was an Internet) I didn't have to
manually figure out bang-paths. The system did it. And we had a lot
less resources in those days. Are you telling me a PDP-11 with 2 RD54
disks (159 MB each) running Ultrix-11 was somehow more capable than the
systems we are running today? Remember what I said? Many things have
gone away in the past not because of inherent design flaws but because
we lacked the technology to support them only to be re-invented later
(frequently in a form not as good as the original would have been if
development had just continued.)

Most of the "administrative effort" today is trying to say ahead of the
Spammers and cleaning up after the actions of these social misfits.
Post by j***@gmail.com
Post by Bill Gunshannon
I would have commented more on what you said but working with the 500
character lines was just more than I could deal with today.
(You're still hitting return other than at paragraph breaks? Whatever
you're using for a newsreader doesn't autowrap long lines?)
I take it your not following the other thread on Usenet content. :-)
When I try to reply to your messages Thunderbird puts your entire
paragraph on a single line making it impossible to read, much lesas
comment to particular sentences.
Post by j***@gmail.com
Post by Bill Gunshannon
UUCP is much better than SMTP.
Um... uucp, _per se_, isn't a mail transfer protocol at all.
Very true. It handles mail as just another file. This allows a number
of other things that SMTP doesn't do. Like hiding all of the metadata
including the ultimate recipient of the email until that information is
actually needed. It also would allow the easy incorporation of end to
end encryption of the entire message including the meta data that was
in the headlines not so long ago.
Post by j***@gmail.com
It's just a file transfer mechanism. It's far more akin to ftp than
to smtp. The uucp protocols (g, f, etc.) don't know a thing about email.
(Or netnews.)
Your point? UUCP can be used to move email in a more secure manner than
SMTP. And, it exists and it has been tested and debugged.
Post by j***@gmail.com
uucp suites generally do include uux (which sends a command to a remote
system and requests that it execute it) and uuxqt (which is the command
server that runs on the remote system). Mail over uucp uses that. The details on how file transfers are made to perform as a mail transport mechanism, they're in the "UUCP 'g' Protocol Description" that I wrote -
I think it's bundled in the DECUS uucp package.
The DECUS uucp implementation of uuxqt never implemented anything
except the "rmail" and the equivalent news-import command, as the
security issues with remote command execution were something we
just didn't want to touch. Accordingly we had no uux at all - our
foreign mail protocol interface just hand-generates the necessary
"work files" ("X" and "D" files) and sends 'em over. Same for the
news interface.
I really don't know why your trying to explain how UUCP works to me as
I apparently know more about it than you do. None of what you said
in that paragraph means anything positively or negatively to the
question at hand.
Post by j***@gmail.com
If all you need to do is transfer a couple of files, and you have IP
connectivity, why bother running uucp (any uucp protocol, doesn't
matter) over IP? Why not just use ftp? (Heck, you could use Kermit
for that matter.)
FTP is as much of a security nightmare as SMTP. Kermit was a cute toy
but its only real value was for moving files between machines that did
not support a real TCP/IP suite. The advantage of UUCP is that all of
the hooks to do safe, reliable, secure email are already there and have
been extensively tested and proven.
Post by j***@gmail.com
If you uuxqt-style mail transfer is much better than SMTP,
why do you think it didn't replace SMTP/POP?
You have it backwards. SMTP replaced UUCP. The reason being that at
the time UUCP was expensive (using Ma Bells phone lines to send email)
and the world SMTP was introduced into was much different. (Many places
didn't even use passwords because just like we left our front doors
unlocked computer users assumed no one would walk in and do damage.
Society changed. We changed the way we protect our homes with things
like ADT. We now need a way to do the same for email and SMTP can't be
fixed because the flaws are inherent in the design. You can put
lipstick on a pig but it's still a pig.
Post by j***@gmail.com
It sounds like your real goal is a private network of mail and news
servers. Well, again, you can have that right now with existing
internet protocols. I'm not sure why the configuration task would
be any more work than using uucp as the transport layer.
Because if you try and do this using SMTP unless you build your own
private physical network you will be exposing your heavily flawed
system to the world and all the miscreants and script-kiddies out
there. It is the protocol design that is flawed.
Post by j***@gmail.com
And, again, mail routing is going to be an issue for the users...
unless either a) you have one common hub and everyone else talks to them (would suck to be them) or b) everyone talks to literally everyone else.
Funny, that. There were central hubs in the old days, and even given
the limited resources it worked really well. Ever heard of UUNET? Or
the system it replaced, seismo? But, as I said, one can do full-mesh
but as you said, it is more initial overhead. And I wouldn't recommend
it as the optimal design. But having some number of central servers for
specific Email Domains is very doable. And, the big thing that some
people always seem to miss is that this is not a one way or the other
system. The UUCP network can be setup as it is being done right now
(mostly for fun kinda like the DECNET Network). People can choose to
join it or not. Groups of people can do this creating their own hub
and then have the hub connect to the "backbone". Think of a all of the
large potential Email Domains out there. .EDU -- researchers being
able to do their collaboration without having to deal with all the spam.
.GOV -- .MIL -- .ORG Let grandma continue to send her picture of
dancing kitties using SMTP but give people who want to take email back
to the days when it was eminently usable for serious work that ability.
No one would be forced onto it, but it is usually considered a good
thing to have choices.

bill
David Froble
2017-04-10 18:14:34 UTC
Permalink
Post by Bill Gunshannon
I take it your not following the other thread on Usenet content. :-)
When I try to reply to your messages Thunderbird puts your entire
paragraph on a single line making it impossible to read, much lesas
comment to particular sentences.
"Hilight", "Edit", and "Rewrap" works for me. Yeah, a PITA, but, it's not too
hard to "get there from here".
t***@glaver.org
2017-04-11 05:19:34 UTC
Permalink
Post by Bill Gunshannon
Your point? UUCP can be used to move email in a more secure manner than
SMTP. And, it exists and it has been tested and debugged.
SMTP has beeen tested and debugged, and there are a variety of implementations
if you don't like Sendmail, or whatever the default is on your system. SMTP has
TLS extensions, username authentication extensions, etc. SMTP can reject that
100MB message because you don't like the sender, the message is too big, and
so on. UUCP has to receive the whole message (possibly going <Burp!> in the pro-
cess), and then discard it.

If your objection to SMTP is that random people can connect to your TCP port 25,
just put in some access rules, either on the system that is running SMTP or on
your firewall / router / etc. to limit access to only those systems you want to
talk to.
Post by Bill Gunshannon
I really don't know why your trying to explain how UUCP works to me as
I apparently know more about it than you do. None of what you said
in that paragraph means anything positively or negatively to the
question at hand.
Ummm, you *DO* know who you are talking to on the other end of that conver-
sation, right? Just checking...
Post by Bill Gunshannon
And I probably should have mentioned the fact that it is still in FreeBSD
means something as there has been a lot of stuff removed that was also still > in use.
You may want to familiarize yourself a little more with FreeBSD. Things that
are removed from the FreeBSD distribution (as opposed to the ports collection)
are generally removed for one of three reasons:

1) They have restrictive licenses and are replaced by equivalent packages
with more permissive licenses (ideally BSD 3-clause).
2) They are insecure, or are updated on a faster schedule than FreeBSD major
versions. In the latter case they usually get moved to ports.
3) They are larger or complicated to configure in relation to the function-
ality used by FreeBSD "as shipped". These get replaced with something
"leaner and meaner" and the original package moved to ports.

In the case of uuencode, it is in /usr/src/usr.bin/uuencode and uses the BSD
license. That means it is unlikely to ever be evicted. If it was in the
/usr/src/contrib area it might be replaced, but I doubt there's a smaller im-
plementation to be found.

sendmail and ntp are two possible /usr/src/contrib candidates for replacement
with more lightweight versions at some point in the future.
Bill Gunshannon
2017-04-11 12:32:42 UTC
Permalink
Post by t***@glaver.org
Post by Bill Gunshannon
Your point? UUCP can be used to move email in a more secure manner than
SMTP. And, it exists and it has been tested and debugged.
SMTP has beeen tested and debugged, and there are a variety of implementations
That's true, but nobody is saying its shortcomings are bugs. It works
exactly as it was designed. And that is the problem.
Post by t***@glaver.org
if you don't like Sendmail, or whatever the default is on your system. SMTP has
TLS extensions, username authentication extensions, etc. SMTP can reject that
100MB message because you don't like the sender, the message is too big, and
so on.
Size isn't a problem. Content is the problem. And SMTP falls very
short of being able to control that. Otherwise, we wouldn't have a
SPAM or malware problem with email.
Post by t***@glaver.org
Post by Bill Gunshannon
UUCP has to receive the whole message (possibly
going <Burp!> in the pro-
Post by t***@glaver.org
cess), and then discard it.
Again. looking at UUCP as it was 30 years ago. Connections today are
over IP and totally reliable. No more burps. And no more 3 hour phone
connections to move a file.
Post by t***@glaver.org
If your objection to SMTP is that random people can connect to your TCP port 25,
just put in some access rules, either on the system that is running SMTP or on
your firewall / router / etc. to limit access to only those systems you want to
talk to.
How do you know who to restrict? Which addresses are spammers and
which are legitimate potential email patrons?
Post by t***@glaver.org
Post by Bill Gunshannon
I really don't know why your trying to explain how UUCP works to me as
I apparently know more about it than you do. None of what you said
in that paragraph means anything positively or negatively to the
question at hand.
Ummm, you *DO* know who you are talking to on the other end of that conver-
sation, right? Just checking...
About as much as he knows who I am (or what my background is.)
Post by t***@glaver.org
Post by Bill Gunshannon
And I probably should have mentioned the fact that it is still in FreeBSD
means something as there has been a lot of stuff removed that was also still > in use.
You may want to familiarize yourself a little more with FreeBSD. Things that
are removed from the FreeBSD distribution (as opposed to the ports collection)
1) They have restrictive licenses and are replaced by equivalent packages
with more permissive licenses (ideally BSD 3-clause).
2) They are insecure, or are updated on a faster schedule than FreeBSD major
versions. In the latter case they usually get moved to ports.
3) They are larger or complicated to configure in relation to the function-
ality used by FreeBSD "as shipped". These get replaced with something
"leaner and meaner" and the original package moved to ports.
In the case of uuencode, it is in /usr/src/usr.bin/uuencode and uses the BSD
license. That means it is unlikely to ever be evicted. If it was in the
/usr/src/contrib area it might be replaced, but I doubt there's a smaller im-
plementation to be found.
OK. I can buy that. but, uuencode isn't really a part of the
conversation and was only posted to emphasis the point that UUCP
is old. I never denied that. But old doesn't mean bad and it doesn't
mean not usable. It also doesn't mean it can't be the solution to a
particular problem.
Post by t***@glaver.org
sendmail and ntp are two possible /usr/src/contrib candidates for replacement
with more lightweight versions at some point in the future.
I would hope that other than on "vintage" systems nobody was running
Sendmail any more as better choices have been available for a long
time.

bill
t***@glaver.org
2017-04-11 15:12:17 UTC
Permalink
Post by Bill Gunshannon
Size isn't a problem. Content is the problem. And SMTP falls very
short of being able to control that. Otherwise, we wouldn't have a
SPAM or malware problem with email.
How do you know who to restrict? Which addresses are spammers and
which are legitimate potential email patrons?
The same way you build a UUCP map, by knowing who connects to who. Except
instead of needing to build a full graph via pathalias, all you need is a
list of the IP addresses of the hosts in your little walled garden.

And unless you can convince everybody else that they want to be in the
walled garden too, at least somebody is going to have a MTA that will
accept SMTP mesages and gateway them into UUCP, which kind of defeats the
point.
Post by Bill Gunshannon
Again. looking at UUCP as it was 30 years ago. Connections today are
over IP and totally reliable. No more burps. And no more 3 hour phone
connections to move a file.
Way up at the top of this thread, you did say you wanted to start with
DECUS UUCP, right? It was wonderful software for its time, but it was al-
ways a bit twitchy, particularly when interfacing with software outside of
its control, like VMS Mail and ANU News. And regardless of the underlying
transport, UUCP is still going to receive the whole file and then decide
to discard it (what is your home Internet usage capped at?), while SMTP
can just look at the from/to during the connection setup and go "Nope, I
don't want that. <click>"
Post by Bill Gunshannon
Post by t***@glaver.org
Ummm, you *DO* know who you are talking to on the other end of that conver-
sation, right? Just checking...
About as much as he knows who I am (or what my background is.)
We may be a bunch of old geezers, but I still remember both of you. Do you re-
member me? uunet!rutgers!spcvxb!spcvxa!terry
Phillip Helbig (undress to reply)
2017-04-11 16:07:45 UTC
Permalink
Post by Bill Gunshannon
Post by t***@glaver.org
If your objection to SMTP is that random people can connect to your TCP
port 25, just put in some access rules, either on the system that is
running SMTP or on your firewall / router / etc. to limit access to only
those systems you want to talk to.
How do you know who to restrict? Which addresses are spammers and
which are legitimate potential email patrons?
I have found that dropping (not rejecting with some error message, which
can cause backscatter spam) email connections to non-existent addresses
and using zen.spamhaus.org as a real-time black-hole list gets rid of
probably 99 per cent or more of spam. What is left is much less than
legitimate email.

DISK$USER:[SYSTEM.TCPIP_SMTP]TCPIP$SMTP.CONF;1 <--- cluster-common

Symbiont-Checks-Deliverability: FALSE
RBLs : zen.spamhaus.org

One could argue that one should be polite and provide proper error
messages and also allow connections from anyone, but both are just not
practical. However, the price is low. People mis-typing an email
address must be really far down on the list of computer problems, and
anyone can send email through an official SMTP relay server for at most
a small fee.

Alternate gateway: SMTP-RELAY.DYNACCESS.DE

Incoming mail comes directly to my cluster:

217.250.203.222 10 multivax.dynaccess.net
217.114.73.109 15 mail-reject.DE
185.17.144.141 20 backup-mx1.DE
80.83.115.219 21 backup-mx2.DE

I've been running my own SMTP server on VMS for 20 years. While Hoff
has pointed out that some things about the setup are not RFC-conforming,
in practice there don't seem to be any problems (and, yes, I would
otherwise notice at least most of them).
Phillip Helbig (undress to reply)
2017-04-10 16:20:45 UTC
Permalink
Post by Bill Gunshannon
Post by j***@gmail.com
Post by Bill Gunshannon
I would have commented more on what you said but working with the 500
character lines was just more than I could deal with today.
(You're still hitting return other than at paragraph breaks? Whatever
you're using for a newsreader doesn't autowrap long lines?)
I take it your not following the other thread on Usenet content. :-)
When I try to reply to your messages Thunderbird puts your entire
paragraph on a single line making it impossible to read, much lesas
comment to particular sentences.
People just don't get it. People really think that because THEY see
wrapped lines on their screen, then everyone else will as well, even
though their newsreader sends one line per paragraph.

It doesn't matter if the line breaks are inserted by hand, like the one
at the end of this line, or inserted automatically by software, like the
one at the end of the second line in this paragraph. In both cases, the
resulting file---which is sent to the NNTP server---will have line
breaks there. (By the way, written in EDT.)

(To be fair, VMS MAIL with SEND/NOEDIT will wrap the lines on the screen
but send a long line, but a) I think that everyone who uses this knows
this and b) if there is more than one line to be sent /EDIT is the way
to go. I've certainly never had cause to complain about long lines sent
from VMS MAIL.)
Tom Allebrandi
2017-04-09 07:28:22 UTC
Permalink
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
I was one of three people who worked on DECUS UUCP. One guy did the UUCP
'g' transport work, another guy hooked in a USEnet newsreader, and I did
the hooks to VAX Mail.

My suspicion is that it might still be possible to get the UUCP
transport up and running on the latest OpenVMS. I don't recall that
there was any kernel mode stuff in the transport.

I have no idea what shape the USEnet hooks and newreader are in. I'm
guessing that the newsreader we used has been long since abandoned.

From the work I did, I would tend to doubt that the hooks to VAX Mail
still work. VAX Mail at that time had a callout API that let you
provide alternate transports. The callout API was implemented kind of
like a Windows DLL or a *nix .so would be today. The hooks may still be
there, but I'd bet they changed over time.

I'm certain that DECUS UUCP ran on VMS 5.5-2. That's what is still on my
Microvax-II, and I got the MV2 so that I could work on DECUS UUCP and
some stuff I was doing on CMUIP towards the end of 1993. (I've got the
OpenVMS licenses from HP, I've just never gotten around to the upgrade.
I'm also not 100% sure that the version of CMUIP I have on there will
talk to anything. That would make things a little difficult to get the
installation packages onto the machine and moved off to TK50's.)

I've got a vague recollection that the guy who did the UUCP transport
did get it running on an Alpha. But I could be wrong. I did drop him a
note about this thread and maybe he'll check in.

For myself, and I think for the others, by the 1992/93 timeframe we had
simply moved on to other things. I went to a company that was not doing
any VAX work -- it was all PC based. The transport guy was in the
process of moving his focus from VMS to Windows NT and I don't recall
where the USEnet news guy ended up.

There are people still oferring UUCP service via dialup or over the
Internet. SDF Public Access UNIX in Seattle (sdf.org) is one such place.

I don't what parts I've still got laying around. (I've got 16 TK50's
with various things on them.) If anyone decides to take a crack a DECUS
UUCP, feel free to drop me a line.

Cheers!

--- tom allebrandi
***@ytram.com or ***@sdf.org
Bill Gunshannon
2017-04-09 14:30:20 UTC
Permalink
Post by Tom Allebrandi
Post by Bill Gunshannon
UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.
I was one of three people who worked on DECUS UUCP. One guy did the UUCP
'g' transport work, another guy hooked in a USEnet newsreader, and I did
the hooks to VAX Mail.
My suspicion is that it might still be possible to get the UUCP
transport up and running on the latest OpenVMS. I don't recall that
there was any kernel mode stuff in the transport.
I have no idea what shape the USEnet hooks and newreader are in. I'm
guessing that the newsreader we used has been long since abandoned.
From the work I did, I would tend to doubt that the hooks to VAX Mail
still work. VAX Mail at that time had a callout API that let you
provide alternate transports. The callout API was implemented kind of
like a Windows DLL or a *nix .so would be today. The hooks may still be
there, but I'd bet they changed over time.
I'm certain that DECUS UUCP ran on VMS 5.5-2. That's what is still on my
Microvax-II, and I got the MV2 so that I could work on DECUS UUCP and
some stuff I was doing on CMUIP towards the end of 1993. (I've got the
OpenVMS licenses from HP, I've just never gotten around to the upgrade.
I'm also not 100% sure that the version of CMUIP I have on there will
talk to anything. That would make things a little difficult to get the
installation packages onto the machine and moved off to TK50's.)
I've got a vague recollection that the guy who did the UUCP transport
did get it running on an Alpha. But I could be wrong. I did drop him a
note about this thread and maybe he'll check in.
For myself, and I think for the others, by the 1992/93 timeframe we had
simply moved on to other things. I went to a company that was not doing
any VAX work -- it was all PC based. The transport guy was in the
process of moving his focus from VMS to Windows NT and I don't recall
where the USEnet news guy ended up.
There are people still oferring UUCP service via dialup or over the
Internet. SDF Public Access UNIX in Seattle (sdf.org) is one such place.
I don't what parts I've still got laying around. (I've got 16 TK50's
with various things on them.) If anyone decides to take a crack a DECUS
UUCP, feel free to drop me a line.
Cheers!
--- tom allebrandi
I think I will. Probably try to get a VAXStation up early this week
and if I have success I will try something newer on an Alpha. But, if
I have any success at all it is still just a stepping stone as Taylor
UUCP would be the target. Phone modems are the dead issue in this
technology. Need to be able to do UUCP over IP.

bill
Tom Allebrandi
2017-04-11 06:47:04 UTC
Permalink
Post by Bill Gunshannon
I think I will. Probably try to get a VAXStation up early this week
and if I have success I will try something newer on an Alpha. But, if
I have any success at all it is still just a stepping stone as Taylor
UUCP would be the target. Phone modems are the dead issue in this
technology. Need to be able to do UUCP over IP.
I am putting on my running shoes and headed out for an undisclosed
location as soon as I finish typing this...

I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
encryption.

:-) :-)

--- tom
Simon Clubley
2017-04-11 12:31:10 UTC
Permalink
Post by Tom Allebrandi
I am putting on my running shoes and headed out for an undisclosed
location as soon as I finish typing this...
I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
encryption.
I once tried to run SLIP or PPP (I don't remember which) over LAT.
The performance left something to be desired (which if you know how
LAT works, you will understand why). :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-04-11 12:46:06 UTC
Permalink
Post by Simon Clubley
Post by Tom Allebrandi
I am putting on my running shoes and headed out for an undisclosed
location as soon as I finish typing this...
I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
encryption.
I once tried to run SLIP or PPP (I don't remember which) over LAT.
The performance left something to be desired (which if you know how
LAT works, you will understand why). :-)
Simon.
I can't imagine why. I thought PPP was designed for doing just such
gyrations. I know I ran connections between the IBM Mainframe and
some IBM remote box over PPP when I set up the initial network at the
University to support all the 3270 terminals (over leased lines) and
it seemed to work. Didn't last long, though, as the IBM went away in
favor of a big VAX.

As for UUCP. I ran it quite successfully over 1200 baud AX.25 in
research. Never found anyone interested in actually using it. But
then, I found nothing but resistance to TCP/IP over AX.25, too. And
just look at what happened to running OSI over AX.25. There was a
case of the opposite problem I am finding. They refused anything new.

bill
Simon Clubley
2017-04-12 17:47:07 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
I once tried to run SLIP or PPP (I don't remember which) over LAT.
The performance left something to be desired (which if you know how
LAT works, you will understand why). :-)
I can't imagine why. I thought PPP was designed for doing just such
gyrations. I know I ran connections between the IBM Mainframe and
some IBM remote box over PPP when I set up the initial network at the
University to support all the 3270 terminals (over leased lines) and
it seemed to work. Didn't last long, though, as the IBM went away in
favor of a big VAX.
I said LAT, not PPP. :-)

LAT buffers data and sends it in packets at fixed intervals (usually
10s of milliseconds apart). It's also a multiplexing protocol so each
data slot is much smaller than an Ethernet frame. It's design goal
to handle terminal traffic only.

It's been a long time since I did this, but I also vaguely seem to
remember some issues around it being all too easy to cause data
overrun type issues when routing PPP/SLIP over LAT but I don't
remember if that was a PPP/SLIP to LAT VMS driver interface issue
or a terminal server issue.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-04-11 12:36:48 UTC
Permalink
Post by Tom Allebrandi
Post by Bill Gunshannon
I think I will. Probably try to get a VAXStation up early this week
and if I have success I will try something newer on an Alpha. But, if
I have any success at all it is still just a stepping stone as Taylor
UUCP would be the target. Phone modems are the dead issue in this
technology. Need to be able to do UUCP over IP.
I am putting on my running shoes and headed out for an undisclosed
location as soon as I finish typing this...
I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
encryption.
:-) :-)
--- tom
I haven't actually tried it yet but running UUCP over SSH is one of
my targets. But, as I said earlier, because email is just a file
being moved between peers and doesn't appear as email except at the
originating and terminating points it would be trivial to throw in
the hooks needed to encrypt the payload providing even better security
because not only the text of the message would get encrypted but also
all the metadata like who the ultimate receiver of the email is.

bill
j***@gmail.com
2017-04-09 07:45:33 UTC
Permalink
Wow, where to begin?

Of course DECUS uucp ran just fine on "OpenVMS" on VAX hardware. As far as I know, it was never ported to VMS on Alpha, let alone Itanium. (And I would like to think that if it had been, someone would have let me know, maybe even sent me a source tree...) So that's why the binaries won't run on modern hardware. I can't think of a reason why they shouldn't run on the latest version of VMS that runs on VAX hardware, or on emulated VAX hardware. Except that...

MAIL-11: The DECUS uucp interface to VMS Mail (developed by Tom Allebrandi as a fork of the PMDF foreign mail protocol interface by Kevin Carosso) does not directly participate in the MAIL-11 protocol, so changes to that protocol shouldn't affect it. (n.b.: If your VMS 5.5 system can still exchange DECnet email with a current VMS system, they're apparently compatible.)

But, the foreign mail protocol interface (the thing that's invoked by wrapping a To: address in uucp%"***@bar.com", and that lets you receive mail from the UUCP transport with a replyable From: line, instead being "from" the account under which the transport runs) may well have changed. We did have an idea for how to do the mail interface differently, requiring nothing running with BYPASS and no funny mail interface code.

Also re. mail - the uucp mapping project was shut down long ago, so you'd be back to crafting bang-paths. Do you really wanna do that?

I frankly don't see the point of bringing up uucp today, but I certainly won't stand in anyone's way if they want to try it. I have no time for it and don't even have an Alpha or Itanium system to test it on.

Jamie Hanrahan
***@cmkrnl.com
Simon Clubley
2017-04-09 23:49:16 UTC
Permalink
Post by Bill Gunshannon
I am thinking of taking a look at it with the hope of getting a VMS
system up on the network. And, who knows, maybe some VMS users might
be happy to move back to the days when SPAM wasn't a problem. The
number of VMS users worldwide is probably an easily manageable number
so that they could all communicate with each other using a network that
doesn't suffer from many of the "advantages" of SMTP.
$ set response/mode=good_natured

While you are at it, why don't you try resurrecting FidoNet, ARC file
compression, uuencode attachments and VT52 terminals ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-04-10 00:02:43 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
I am thinking of taking a look at it with the hope of getting a VMS
system up on the network. And, who knows, maybe some VMS users might
be happy to move back to the days when SPAM wasn't a problem. The
number of VMS users worldwide is probably an easily manageable number
so that they could all communicate with each other using a network that
doesn't suffer from many of the "advantages" of SMTP.
$ set response/mode=good_natured
While you are at it, why don't you try resurrecting FidoNet, ARC file
compression, uuencode attachments and VT52 terminals ? :-)
Because FidoNET was never a good idea. It was yet another example of
someone doing something that already existed and doing it badly.

Arc isn't better than anything available today. UUCP is much better
than SMTP.

Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.

I can't say about VT52 as by the time I stopped using Televideo the
VT100 was already the standard. I still use VT100 (in emulation) all
the time today. GUI's have never eliminated character cell terminals.
But then, anyone here would know that.

I am not trying to push old for the sake of old I am trying to
demonstrate that newer is not synonymous with better and sometimes
one needs to look to the past to find where they went off the path
and how to get back on it.

bill
Arne Vajhøj
2017-04-10 23:53:14 UTC
Permalink
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.

But I would deem it extremely rare in actual usage today.

Arne
Bill Gunshannon
2017-04-11 00:04:44 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
Well, I know I stil use it once in a while. :-)

bill
Bill Gunshannon
2017-04-11 01:24:58 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
Well, I know I stil use it once in a while. :-)
And I probably should have mentioned the fact that it is still in
FreeBSD means something as there has been a lot of stuff removed
that was also still in use.

bill
Phillip Helbig (undress to reply)
2017-04-11 07:55:30 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
UUENCODE, say, a PDF file, then just email it from the command line or
include it in a message. Many email clients correctly interpret it as
an attachment. Some (notable Outlook) don't.

There was a discussion a while back on how best mail attachments from
VMS MAIL. This is by far the easiest if the mail client interprets it
correctly.
Jan-Erik Soderholm
2017-04-11 10:51:30 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
It is my prefered way to send something from VMS to my mail.

ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.

It always ends up as a normal attachment in my (Outlook) mail.
Phillip Helbig (undress to reply)
2017-04-11 12:02:00 UTC
Permalink
Post by Jan-Erik Soderholm
It is my prefered way to send something from VMS to my mail.
ZIP the file.
Not necessary if PDF (already compressed).
Post by Jan-Erik Soderholm
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
Interesting. Did you have to configure something to get this to work?
Jan-Erik Soderholm
2017-04-11 12:41:27 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Soderholm
It is my prefered way to send something from VMS to my mail.
ZIP the file.
Not necessary if PDF (already compressed).
Yes, it does depend on the actuall file, of course...
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Soderholm
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
Interesting. Did you have to configure something to get this to work?
Configure where? But no, I did nothing. The VMS files behaves just as
any other attachment from any other source. I can either preview
within Outlook or double-click to in some application.
Bill Gunshannon
2017-04-11 12:38:45 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
It is my prefered way to send something from VMS to my mail.
ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
But... But.. It's old. It can't possibly be usable or the correct
solution to a problem, right?

bill
Jan-Erik Soderholm
2017-04-11 12:45:05 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
It is my prefered way to send something from VMS to my mail.
ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
But... But.. It's old. It can't possibly be usable...
It is *very* usable...
or the correct solution to a problem, right?
To what problem? To view a file that is not othervise viewable
on VMS, it works perfectly well. Or what is "a problem"?
bill
Bill Gunshannon
2017-04-11 13:03:51 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
It is my prefered way to send something from VMS to my mail.
ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
But... But.. It's old. It can't possibly be usable...
It is *very* usable...
or the correct solution to a problem, right?
To what problem? To view a file that is not othervise viewable
on VMS, it works perfectly well. Or what is "a problem"?
I guess I was too subtle again. :-)

bill
David Froble
2017-04-11 13:15:04 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
It is my prefered way to send something from VMS to my mail.
ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
But... But.. It's old. It can't possibly be usable...
It is *very* usable...
or the correct solution to a problem, right?
To what problem? To view a file that is not othervise viewable
on VMS, it works perfectly well. Or what is "a problem"?
Me thinks in this case the "problem" is perhaps an inability to recognize sarcasm?
Jan-Erik Soderholm
2017-04-11 13:21:55 UTC
Permalink
Post by David Froble
Post by Jan-Erik Soderholm
Post by Jan-Erik Soderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
Arne
It is my prefered way to send something from VMS to my mail.
ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
But... But.. It's old. It can't possibly be usable...
It is *very* usable...
or the correct solution to a problem, right?
To what problem? To view a file that is not othervise viewable
on VMS, it works perfectly well. Or what is "a problem"?
Me thinks in this case the "problem" is perhaps an inability to recognize sarcasm?
Ah, right. I think I see Bills point know... :-)
Yes, you are right Bill, how can this possibly be usable... :-)
Stephen Hoffman
2017-04-11 14:39:34 UTC
Permalink
Post by David Froble
Me thinks in this case the "problem" is perhaps an inability to recognize sarcasm?
Wait... Sarcasm? I thought the whole thread was satire?
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2017-04-12 02:27:30 UTC
Permalink
Post by Jan-Erik Soderholm
Post by Arne Vajhøj
Post by Bill Gunshannon
Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.
uuencode is stille available in many software.
But I would deem it extremely rare in actual usage today.
It is my prefered way to send something from VMS to my mail.
ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.
It always ends up as a normal attachment in my (Outlook) mail.
But wouldn't B64 also work?

And maybe even just /FOREIGN?

Arne
Tom
2017-04-11 07:23:11 UTC
Permalink
Post by Bill Gunshannon
I am not trying to push old for the sake of old I am trying to
demonstrate that newer is not synonymous with better and sometimes
one needs to look to the past to find where they went off the path
and how to get back on it.
I probably should of mentioned that the DECUS UUCP project had two goals.

1) Bring a solid and reliable UUCP to VMS systems so that they could join
in the fun.

Even though we were on UUCP, Jamie and I used to have near real time
discussions using mail. (We were neighbors in the tree.)


2) Create a network of VMS systems using UUCP for discussions relevant to
VAXes and VMS. Originally, the VMSnet was intended to be seperate from the
USEnet. We started out doing our own email routing and newsgroup
distributions. (That's how we got the creation of the VMSnet newsgroup tree
past the "Gods of the USEnet.")

The VMSnet newsgroup tree is still there. It's pretty much descended into
garbage and spam.

But, I wonder if it would be worth it to prune the tree, and then see if we
could send out newgroup messages to convert the remaining groups from open
access to moderated.


--- tom

PS: I remember VT52's. I had to repair one once, and was able to track the
problem to a single bad IC out of the 30+ chips on the motherboard.
Paul Sture
2017-04-11 19:42:26 UTC
Permalink
Post by Tom
PS: I remember VT52's. I had to repair one once, and was able to track the
problem to a single bad IC out of the 30+ chips on the motherboard.
The VT52s we had died at regular intervals, always from the same
problem. PSU or a capacitor, I forget the details now, but it was a
lengthy process to get to the offending part[1], and the same time to
reassemble everything afterwards.

The VT100 and subsequent VTs were a lot easier to get into, and I don't
readily recall any of them failing. In comparison certain OEM models
had the life of a fruit fly.

[1] my memory says 45 minutes to disassemble, 45 minutes to reassemble,
and those were official DEC book times, which seems hard to believe
nowadays, but even halving it comes out at 45 minutes for the full job.
--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.
Tom
2017-04-11 07:05:43 UTC
Permalink
Post by Simon Clubley
$ set response/mode=good_natured
While you are at it, why don't you try resurrecting FidoNet, ARC file
compression, uuencode attachments and VT52 terminals ? :-)
Simon.
There are very active retro computing communities all around the world,
especially here in Seattle.

Next time you are up this way, be sure and visit the Living Computers
Museum + Labs, (http://www.livingcomputers.org/) They have all kinds of
vintage hardware running that people can sit down and play with.

Here's a link to their hardware page:
http://www.livingcomputers.org/Discover/At-The-
Museum/VintageComputers.aspx

Among other things they have

- the CDC6500 that was at Purdue University in the '70s. I think you can
request a login and connect to it over telnet.


- They also have a DECSYSTEM-10 and two DECSYSTEM-20s.Someone recently
claimed the bigger DEC 20 was the same machine that Microsoft used when
they were getting started. (In their early days, Microsoft cross
compiled a lot of their 808x products on a DEC 20 running TOPS-10.)

I'm not sure that the story is true, I thought Microsoft had the little
single cabinet 2020 in those days. That's why we had one where I worked,
But,that's a story for another day.

Cheers!

--- tom
Simon Clubley
2017-04-11 12:39:15 UTC
Permalink
Post by Tom
Post by Simon Clubley
$ set response/mode=good_natured
While you are at it, why don't you try resurrecting FidoNet, ARC file
compression, uuencode attachments and VT52 terminals ? :-)
There are very active retro computing communities all around the world,
especially here in Seattle.
Yes, I know and it's something I actively encourage.

The point I was making is that Bill is in danger of thinking something
is better simply because he's more comfortable with it, instead of
considering whether the newer solution might be designed to solve
a different problem and to do that in a better way than the older
problem can.

In this case, SMTP and the underlying protocols are designed to be used
on a global scale by a vast number of machines that don't know each other.
Can UUCP scale to that level ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Bill Gunshannon
2017-04-11 13:02:31 UTC
Permalink
Post by Simon Clubley
Post by Tom
Post by Simon Clubley
$ set response/mode=good_natured
While you are at it, why don't you try resurrecting FidoNet, ARC file
compression, uuencode attachments and VT52 terminals ? :-)
There are very active retro computing communities all around the world,
especially here in Seattle.
Yes, I know and it's something I actively encourage.
The point I was making is that Bill is in danger of thinking something
is better simply because he's more comfortable with it,
Comfort has nothing to do with it. I looked a t a problem (one that
some consider a very serious problem and growing every day) and looked
at solutions. One solution rises rapidly to the top with its only
real anchor being the fact that it is not new.
Post by Simon Clubley
instead of
considering whether the newer solution might be designed to solve
a different problem and to do that in a better way than the older
problem can.
A newer solution could be designed. But, how long would you estimate
it would take to come up with a new email protocol that does not have
the problems of the current system, design it, implement it, field it.
(We won't go into getting it accepted because you can see from this
conversation how hard getting anything accepted is likely to be!)

I think we need to come up with something new. But the problem exists
now and a solution exists now. And, it can all be done transparently
to the user, which is one of the major requirements of any such system.
Post by Simon Clubley
In this case, SMTP and the underlying protocols are designed to be used
on a global scale by a vast number of machines that don't know each other.
And that last phrase is a major part of the problem. In order to
function you have to accept email from people you don;t know and who's
identity you can can not verify or even have any reasonable hope of
trusting.
Post by Simon Clubley
Can UUCP scale to that level ?
I think a network based on UUCP, if done properly can. And at the same
time provide the needed security to prevent joe script-kiddie or even
serious spammers from reducing it to the level of the current system.


bill
Chris Scheers
2017-04-11 21:41:27 UTC
Permalink
Post by Tom
- They also have a DECSYSTEM-10 and two DECSYSTEM-20s.Someone recently
claimed the bigger DEC 20 was the same machine that Microsoft used when
they were getting started. (In their early days, Microsoft cross
compiled a lot of their 808x products on a DEC 20 running TOPS-10.)
I'm not sure that the story is true, I thought Microsoft had the little
single cabinet 2020 in those days. That's why we had one where I worked,
But,that's a story for another day.
Since Paul Allen is the driving force behind the LCM, it is quite possible.

I know that they have Mr. Allen's DECSYSTEM, but I don't know details
about it.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Rich Alderson
2017-04-13 20:18:23 UTC
Permalink
[ DISCLAIMER: I currently hold the title of Sr. Systems Engineer at
Living Computers: Museum + Labs, and have the honor to be the first
person employed by the project what turned into that museum, in 2003.
In that time, I have been curator, collections manager, exhibit designer,
systems programmer, developer, systems administrator for our online
offerings, hardware maintenance technician, web site designer, etc.
Prior to that, I worked for XKL, LLC, for ~10 years, doing customer
advocacy, pre- and post-sales support, and systems administration for
the company. I know a thing or two about the history. --rma]
Post by Tom
There are very active retro computing communities all around the world,
especially here in Seattle.
Next time you are up this way, be sure and visit the Living Computers
Museum + Labs, (http://www.livingcomputers.org/) They have all kinds of
vintage hardware running that people can sit down and play with.
http://www.livingcomputers.org/Discover/At-The-Museum/VintageComputers.aspx
Among other things they have
- the CDC6500 that was at Purdue University in the '70s. I think you can
request a login and connect to it over telnet.
Indeed. On the home page for Living Computers, under "Get Involved" on the
menu bar (not where I'd have put it), there is a "Request a Login" item which
will take you to a form which offers accounts on 8 systems (with more coming
in the future):

XKL Toad-2 TOPS-20 v7.1
DEC 2065 Tops-10 v7.04
VAX-11/780-5 VMS 7.3
PDP-11/70 Unix v7
VAX-11/730 BSD 4.3
WE 3B2 Unix SVR3
Xerox Sigma 9 CP-V
CDC 6500 NOS
Post by Tom
- They also have a DECSYSTEM-10 and two DECSYSTEM-20s.Someone recently
claimed the bigger DEC 20 was the same machine that Microsoft used when
they were getting started. (In their early days, Microsoft cross
compiled a lot of their 808x products on a DEC 20 running TOPS-10.)
Well, technically ;-) there are 3 Decsystem-10s in the big computer room on
the 2nd floor, since the difference between a Dec-10 and a DEC-20 was which
operating system was running on the hardware. The orange system (DEC-2065)
is running Tops-10 v7.04; the DEC-1070 (KI-10 processor, big blue boxes) is
running Tops-10 v6.03A; and the blue KL-10 (not painted by DEC but by a
previous owner) is running WAITS, the Stanford Artificial Intelligence
Labortory's OS which descended from the PDP-6 monitor and diverged from
Tops-10 at the 4S72 monitor release.

There is a Toad-1 and a pair of Toad-2 systems running TOPS-20 v7.1 (the XKL
release of the OS); there are also a pair of DECSYSTEM-2020s awaiting my time
to get ITS running on one (the former MIT-AI KS-10) and TOPS-20 v4.1 (on a
system previously owned by my late friend Mark Crispin.

None of these particular systems was ever in use at Microsoft. In point of
fact, the 2065 was the development machine at XKL until we had enough Toad-1
systems to eat our own dog food.
Post by Tom
I'm not sure that the story is true, I thought Microsoft had the little
single cabinet 2020 in those days. That's why we had one where I worked,
But,that's a story for another day.
Until the move from Albuquerque (the return from exile?), Microsoft leased time
on Tops-10 systems owned by other organizations. Paul Allen moved to Seattle
two weeks earlier than the rest of the company to take delivery of a 2020; this
brought about a move from Tops-10 to TOPS-20 as the development platform for
the company. They acquired at least one KL-10 system as the company grew, as
well as a pair of PDP-11/70s dubbed Kermit and Miss Piggy for Xenix development
(and Miss Piggy is the system listed above as running Unix v7).



Rich Alderson
Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134

http://www.LivingComputers.org/
--
Rich Alderson ***@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen
Steven Schweda
2017-04-27 22:48:53 UTC
Permalink
Post by Bill Gunshannon
The packagae is available at
ftp://ftp.uu.net/systems/vms/uucp
and runs under VMS 5.4-x or VMS 5.5.
You tried that link? It failed for me.
Post by Bill Gunshannon
Just out of curiosity, is there really anything that drastic
that would have changed to make the software no longer usable
under VMS?
The C compiler is one thing which might.

Knowing nothing, I looked around and found some 'Version
2.0 of DECUS uucp (formerly "VMSnet software")' from (mostly)
1992, at:
ftp://ftp.decuserve.org/decus/vms/sig_tapes/vax92a/uucp/

After some "wget -r" action (and plenty of "set file
/attr" action on the text files), I got some readable files.

Gzip can un-compress the ".bkp-z" files, and the usual
tools for BACKUP save-set adjustment can make the results
usable. (The apparent expectation in 1992 was that the
supplied VAX executables like [.BIN]COMPRESS.EXE and
[.BIN]MODATT.EXE would be adequate to handle these tasks.
They're less directly useful on an Alpha system.)

I spent some time looking for how-to-build instructions,
but found only how-to-use instructions. (They could be in
there somewhere, and I've missed the obvious before.)
Lacking direction, I began by trying to build the "make"
program ([UUCP.TOOLS.MAKE.V33]). After some hours of
pounding on the source code to clear numerous/various
compiler complaints -- I'll guess that VAX C didn't do
%CC-W-PTRMISMATCH -- I actually got it to work well enough to
build itself (which is the only test I've tried):

ALP $ mcr [-]make /verify
$ @ALP$DKC100:[UUCP.TOOLS.MAKE.V33]MAKE39066134.COM;1
$ On Control_Y Then Goto The_Exit
$ On Error Then Goto The_Exit
$ cc make.c/obj=make.obj
$ cc mstring.c/obj=mstring.obj
$ cc cmdline.c/obj=cmdline.obj
$ set command makecmd.cld/object=makecmd.obj
$ cc dates.c/obj=dates.obj
$ link make.obj,-
mstring.obj,-
cmdline.obj,-
makecmd.obj,-
dates.obj
$The_Exit:
$ Save_Status = $STATUS
$ Delete/NoLog ALP$DKC100:[UUCP.TOOLS.MAKE.V33]MAKE39066134.COM;1
$ Verify_Flag = F$Verify(Verify_Flag)

Not having written much 25-year-old C code lately, I
hesitate to criticize the coding style of this stuff, but HP
C V7.3-010 suffers from no such reticence. If this one
program is representative of the remainder, then I'd say that
someone trying to whip this stuff into shape for a modern C
compiler would have some serious work ahead of him. (And I
wouldn't expect the result to cope well with ODS5, either.)

My quick guess would be that if there's any (more) modern
UUCP software out there, then porting that to VMS would be
smarter (and easier) than trying to resurrect this fossil.

Only one man's opinion, of course.

Loading...