Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What would you miss if DECnet got the chop? Was: "bad select 38" (OpenSSL on VMS)

1,310 views
Skip to first unread message

Paul Sture

unread,
Sep 18, 2016, 3:25:42 AM9/18/16
to
On 2016-09-17, David Froble <da...@tsoft-inc.com> wrote:
> Stephen Hoffman wrote:
>>
>> I'd be seriously tempted to announce the deprecation and eventual
>> removal of DECnet, for that matter.
>
> Booo! Hisssss!
>
> Ok, we know it's not secure. Run at your own risk.
>
> I'm guessing that DECnet users use it only in house, for FAL and such, so if the
> in house environment is secure, then security isn't an issue for DECnet.
>
> If it's not going to take up time and effort, then why kill it off?
>
> I personally find it can be useful.
>
> It sure is handy when you need to shutdown and re-start TCP/IP on a remote (but
> in house) system.

I'd certainly miss one or two things that DECnet does:

o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail of software
installations and configuration sessions. Yes, many terminal emulators can
do logging, but those logs aren't on the target system.

o - using DECnet as a means of placing BACKUP savesets on another node, and
restoring them from other nodes (where 'other' can be either local or
remote).

o - DECnet tasks. Useful but I haven't seen many customers use these.

o - FAL

--
It was untidy, so got unplugged.
It was unplugged, so got thrown away.

Dirk Munk

unread,
Sep 18, 2016, 4:35:27 AM9/18/16
to
First of all, which DECnet do you mean? DECnet Phase IV should have
been abandoned years ago, DECnet Phase V has been the successor for
years now, but many DECnet users are just to plain lazy to learn how it
works. They took a look at the UI, concluded that is was very different
from the NCP commands of Phase IV, and just gave up. Or are they too
stupid to understand it?

Has no one ever noticed the analogy between Windows and VMS in this
respect? Windows uses Netbios over IP the same way VMS can use DECnet
Phase V over IP. Or have you ever heard of Microsoft abandoning Netbios
in favour of plane IP stuff like FTP etc. ?

Besides DECnet we also have cluster traffic. It is also insecure. So
let's just abandon VMS clusters as well???

DECnet and cluster traffic can both use IP for transport. How to make
that traffic very secure? It is so simple, use IPsec! But when I
proposed that in this forum, it was made very clear that I'm an idiot to
propose the only way to encrypt IP traffic that has an real
architectural idea behind it, instead of the many hobby solutions like
SSL, SSH etc.

But again, you must make an afford to implement IPsec, and we don't want
to do that. Quick and dirty solutions that are prone to lots of
maintenance on the application level are much and much better. Thinking
in layers, whereby encryption is part of the network and has nothing to
do with applications, idiotic.

So yes, you can use all the nice features DECnet has to offer, but no
one cares to deal with these days. And you can use it in a safe way as
well. Oh yeah, and remember, DECnet is deeply embedded in VMS, VMS was
build around the idea of networking with DECnet. You do remember how
full VMS file specifications looks?

node::disk:{directory}file.extension.version

It start with node::

Try that with plain IP.

Some one recently wrote a article about the status of IPv6, and about
the status of RFC's . It was shocking to read what an enormous mess it
is. That is the problem with IP, it is one enormous out of hand hobby
project with lots of overlapping poorly defined 'standards' that are
really no standards at all (!!). It is exactly what we should not have
in times that well structured security and dependable network
communication is of the utmost importance.

David Froble

unread,
Sep 18, 2016, 5:22:04 AM9/18/16
to
I use IV, which suits my purposes. Sorry you don't approve. Actually, I don't
give a damn what you think. If you're going to take the attitude that it's your
way or the highway, well, good luck, you''ll need it, but I don't think you'll
have it. People are allowed to have differing opinions. Even stupid people
like me.

> Has no one ever noticed the analogy between Windows and VMS in this
> respect? Windows uses Netbios over IP the same way VMS can use DECnet
> Phase V over IP. Or have you ever heard of Microsoft abandoning Netbios
> in favour of plane IP stuff like FTP etc. ?
>
> Besides DECnet we also have cluster traffic. It is also insecure. So
> let's just abandon VMS clusters as well???
>
> DECnet and cluster traffic can both use IP for transport. How to make
> that traffic very secure? It is so simple, use IPsec! But when I
> proposed that in this forum, it was made very clear that I'm an idiot to
> propose the only way to encrypt IP traffic that has an real
> architectural idea behind it, instead of the many hobby solutions like
> SSL, SSH etc.
>
> But again, you must make an afford to implement IPsec, and we don't want
> to do that. Quick and dirty solutions that are prone to lots of
> maintenance on the application level are much and much better. Thinking
> in layers, whereby encryption is part of the network and has nothing to
> do with applications, idiotic.
>
> So yes, you can use all the nice features DECnet has to offer, but no
> one cares to deal with these days. And you can use it in a safe way as
> well. Oh yeah, and remember, DECnet is deeply embedded in VMS, VMS was
> build around the idea of networking with DECnet. You do remember how
> full VMS file specifications looks?
>
> node::disk:{directory}file.extension.version

Yes, my thoughts also ....

> It start with node::
>
> Try that with plain IP.
>
> Some one recently wrote a article about the status of IPv6, and about
> the status of RFC's . It was shocking to read what an enormous mess it
> is. That is the problem with IP, it is one enormous out of hand hobby
> project with lots of overlapping poorly defined 'standards' that are
> really no standards at all (!!). It is exactly what we should not have
> in times that well structured security and dependable network
> communication is of the utmost importance.

In general I agree with what you've written. I consider DECnet as a part of
VMS, and if one really doesn't want VMS, then just go and use something else.

Jan-Erik Soderholm

unread,
Sep 18, 2016, 5:39:26 AM9/18/16
to
Den 2016-09-18 kl. 09:18, skrev Paul Sture:
> On 2016-09-17, David Froble <da...@tsoft-inc.com> wrote:
>> Stephen Hoffman wrote:
>>>
>>> I'd be seriously tempted to announce the deprecation and eventual
>>> removal of DECnet, for that matter.
>>
>> Booo! Hisssss!
>>
>> Ok, we know it's not secure. Run at your own risk.
>>
>> I'm guessing that DECnet users use it only in house, for FAL and such, so if the
>> in house environment is secure, then security isn't an issue for DECnet.
>>
>> If it's not going to take up time and effort, then why kill it off?
>>
>> I personally find it can be useful.
>>
>> It sure is handy when you need to shutdown and re-start TCP/IP on a remote (but
>> in house) system.
>
> I'd certainly miss one or two things that DECnet does:

I miss a few features that my first car had in the early 80's, but
I do not want it back anyway.

>
> o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail of software
> installations and configuration sessions. Yes, many terminal emulators can
> do logging, but those logs aren't on the target system.
>

I prefer *not* to have it at the target system. If so, I also need
access to that target system, that might be at some customer site that
i left "yesterday". If I need a trace of my work, I create it as a log
from my terminal emulator on my laptop.


> o - using DECnet as a means of placing BACKUP savesets on another node, and
> restoring them from other nodes (where 'other' can be either local or
> remote).
>

How many (in a moderately large installation) still shuffle BACKUP savesets
around? We use: https://storserver.com/software/storserver-software-abc/

Jan-Erik Soderholm

unread,
Sep 18, 2016, 5:50:58 AM9/18/16
to
> What would you miss if DECnet got the chop?

Or more important, what would my customer miss if DECnet got the chop?

Nothing.

And myself? I do not remember last time I used a DECnet
based tool, utility, command file or whatever. 10+ years?
We still start DECnet (IV), but I do not really know why.

I fully agree that DECnet once was a nice environment with
a really good integration with VMS, but If I turn 180 degree
around at the future, I cannot see DECnet there.

I think we have to accept that the rest of the world selected
TCPIP for networking.



Dirk Munk

unread,
Sep 18, 2016, 6:32:44 AM9/18/16
to
Thanks David.

My ideas about Phase IV are not just opinions. Phase IV is a dead end,
it won't be long before you can't buy routers for Phase IV. You can't
make Phase IV traffic secure, you can't use it in a IP-only network
environment, you can't use it over the internet. Those are facts, not
opinions.

I will go further then that. By sticking to DECnet Phase IV, you will
affectively kill DECnet. If DECnet is nothing else then an IP port for
your network people, then who cares. If it is a completely different
network environment, it will be all the more reason to kick DECnet and
even VMS out.

Does this make sense to you?

I'm sure DECnet Phase IV suits your purpose, but the nice thing with
DECnet is nothing changes on the application level when you go from
Phase IV to Phase V. Now look at IP, go from IPv4 to IPv6. You have to
rebuild your application, put two networks stacks in for as long you're
using dual stack.

So in your case:
- Go from DECnet Phase IV to DECnet Phase V: you don't have to change
anything in your application.
- Go from OSI transport to IPv4 transport: you don't have to change
anything in your application.
- Go from IPv4 transport to IPv6 transport: you don't have to change
anything in your application.
- Go from insecure to encrypted networking with IPsec: you don't have to
change anything in your application.


johnwa...@yahoo.co.uk

unread,
Sep 18, 2016, 7:22:03 AM9/18/16
to
I'm convinced, but then I learned DECnet IV (protocols and
applications), OSI (protocols and applications), and IP4
(protocols and applications) and IP6 (vision - the rest
was still years away) all in the same few years in the
late 1980s (and not just on VMS either).

Afaict, the thing that did for DECnet/OSI (Phase V, etc)
was the learning curve of its unified management interface.
Its immediate OSI/VMS predecessor, VOTS/OSAK/etc, was
understandable to near-normal human beings. DECnet/OSI
suffered from "Swiss penknife syndrome".

IPv6 is still barely more than a vision for most folk. It
may be supplied and enabled with every modern Window box
and many/most Linux boxes, but how many people actually
know they've got it, let alone actually use it?

Do I want DECnet to hang around? I don't think the question
is properly formed: do we mean protocols on the wire,
applications that people use, or what? Though I suspect
the answer might still be "no" to both questions for many
people.

I see OMNI and OSAP are still on the latest VSI roadmap
(a pair of related products which started life as ways
to talk in a formally standardised vendor-independent
way to shop floor machines and other stuff too). Built
originally on OSI networking. I would be interested to
know if they still require an underlying OSI network,
or whether minnows like Siemens, GE, etc (and their
customers) have accepted that IP-only networks are the
future for manufacturing networks for everyone,
everywhere.

Dirk Munk

unread,
Sep 18, 2016, 8:09:59 AM9/18/16
to
Everybody who has an IPv6 internet connection. You will use it without
knowing it. Every Google request, every Netflix film, every Youtube film
will be transported over IPv6. Far more people then you may think.

>
> Do I want DECnet to hang around? I don't think the question
> is properly formed: do we mean protocols on the wire,
> applications that people use, or what? Though I suspect
> the answer might still be "no" to both questions for many
> people.
>

DECnet as an API for applications, and as the always present
functionality in VMS. Not as protocol on the wire, no need you can use IP.

> I see OMNI and OSAP are still on the latest VSI roadmap
> (a pair of related products which started life as ways
> to talk in a formally standardised vendor-independent
> way to shop floor machines and other stuff too). Built
> originally on OSI networking. I would be interested to
> know if they still require an underlying OSI network,
> or whether minnows like Siemens, GE, etc (and their
> customers) have accepted that IP-only networks are the
> future for manufacturing networks for everyone,
> everywhere.
>
Using IP as transport protocol is an OSI standard! It is not DECnet
Phase V specific. So I don't see any reason that OMNI and OSAP could not
be transported over IP. Now of course Siemens, GE etc. must also have
implemented the IP transport stack in their OSI networking for this to work.

Jan-Erik Soderholm

unread,
Sep 18, 2016, 10:10:12 AM9/18/16
to
> Everybody who has an IPv6 internet connection...

Right. But it doesn't help that your Windows/Linux client comes
with an IPv6 stack built-in when your router and ISP has it
disabled anyway. And why should *I* care? Google, Youtube and
everything else works just fine.

Dirk Munk

unread,
Sep 18, 2016, 10:29:44 AM9/18/16
to
I'm sure it doesn't interest you. The fact that there are no more IPv4
addresses available, who cares. The fact that this way the internet
can't expand any more, not important. The fact that ISP's have to use
carrier grade NAS that cripple all kind of network connections, a futility.

I know Sweden is a bit behind with IPv6, but Belgium for instance has
over 45% IPv6 connectivity. Google notices a steep incline in IPv6
traffic, and the end of the year it will be 20% on their servers.

It is interesting to see that you claim that IP is the future, and
DECnet is the past, and then you're not interested in IPv6 what is the
necessary future for IP.

Dirk Munk

unread,
Sep 18, 2016, 10:31:16 AM9/18/16
to
Carrier grade NAT of course, not NAS.

Marc Van Dyck

unread,
Sep 18, 2016, 11:07:38 AM9/18/16
to
Paul Sture laid this down on his screen :
The important is not to hurt applications... Moving to DECnet over IP
is totally harmless to them. So if development resources become scarce,
I'd say keep the top layers only, with IP transport, and ditch the
rest.
The systems I'm responsible for are still using FAL and task-to-task
thousand times per day, and there are no plans to change that.
Abandoning them is unthinkable in my opinion.

--
Marc Van Dyck

Scott Dorsey

unread,
Sep 18, 2016, 11:14:32 AM9/18/16
to
Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>
>I think we have to accept that the rest of the world selected
>TCPIP for networking.

And, that being the case, we need to have the same features that people
have liked with DECNET (such as the remote save sets) available with IP.

In the Unix world, I use the SFTP filesystem for a lot of things that I
would have done more easily with DECNET transfers in the VMS world. In
the Windows world they have SMB fileshares integrated in much the way
DECNET is integrated into VMS.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey

unread,
Sep 18, 2016, 11:17:35 AM9/18/16
to
In article <f3uDz.569452$Nh2....@fx09.ams1>, Dirk Munk <mu...@home.nl> wrote:
>
>My ideas about Phase IV are not just opinions. Phase IV is a dead end,
>it won't be long before you can't buy routers for Phase IV. You can't
>make Phase IV traffic secure, you can't use it in a IP-only network
>environment, you can't use it over the internet. Those are facts, not
>opinions.

This is true, however Phase V is also a dead end.

The days of worldwide DECNET over a public network are gone, gone, gone.

Anybody using DECNET today is likely tunnelling it through IP if they are
going any distance. Better to take out some layers and use standard IP
protocols to begin with.

>I will go further then that. By sticking to DECnet Phase IV, you will
>affectively kill DECnet. If DECnet is nothing else then an IP port for
>your network people, then who cares. If it is a completely different
>network environment, it will be all the more reason to kick DECnet and
>even VMS out.

This argument was a good argument a decade ago, but it's too late now.
You are beating a dead horse.

VAXman-

unread,
Sep 18, 2016, 11:37:49 AM9/18/16
to
In article <enr1bd-...@news.chingola.ch>, Paul Sture <nos...@sture.ch> writes:
>On 2016-09-17, David Froble <da...@tsoft-inc.com> wrote:
>> Stephen Hoffman wrote:
>>>
>>> I'd be seriously tempted to announce the deprecation and eventual
>>> removal of DECnet, for that matter.
>>
>> Booo! Hisssss!
>>
>> Ok, we know it's not secure. Run at your own risk.
>>
>> I'm guessing that DECnet users use it only in house, for FAL and such, so if the
>> in house environment is secure, then security isn't an issue for DECnet.
>>
>> If it's not going to take up time and effort, then why kill it off?
>>
>> I personally find it can be useful.
>>
>> It sure is handy when you need to shutdown and re-start TCP/IP on a remote (but
>> in house) system.
>
>I'd certainly miss one or two things that DECnet does:
>
>o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail of software
> installations and configuration sessions. Yes, many terminal emulators can
> do logging, but those logs aren't on the target system.

Not on the top of my list but it would be nice to have about.



>o - using DECnet as a means of placing BACKUP savesets on another node, and
> restoring them from other nodes (where 'other' can be either local or
> remote).
>
>o - DECnet tasks. Useful but I haven't seen many customers use these.
>
>o - FAL

Seconded! DCL commands using NODE::<file-spec> are things I use quite often
and rely upon.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

Jan-Erik Soderholm

unread,
Sep 18, 2016, 11:39:46 AM9/18/16
to
Den 2016-09-18 kl. 17:14, skrev Scott Dorsey:
> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> I think we have to accept that the rest of the world selected
>> TCPIP for networking.
>
> And, that being the case, we need to have the same features that people
> have liked with DECNET (such as the remote save sets) available with IP.
>

Who are "we"? The (remaining) VMS user community? Do we think that we
can decide what should be used on networks or the internet in general?

My guess is that we simply have to learn to live without remote save sets.

The best service we can do for VMS is to "play well" with whatever is
expected on todays networks. Right, there is DECnet-over-IP, but it
seems as most user/sites simply decided to use TCPIP tools directly.

> In the Unix world, I use the SFTP filesystem for a lot of things that I
> would have done more easily with DECNET transfers in the VMS world. In
> the Windows world they have SMB fileshares integrated in much the way
> DECNET is integrated into VMS.

I would guess there are a few more Windows nodes out there, then there
are VMS nodes. I guess volume does have *some* impact here.


> --scott
>

Dirk Munk

unread,
Sep 18, 2016, 11:54:06 AM9/18/16
to
Scott Dorsey wrote:
> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>
>> I think we have to accept that the rest of the world selected
>> TCPIP for networking.
>
> And, that being the case, we need to have the same features that
> people
> have liked with DECNET (such as the remote save sets) available with > IP.

YOU ALREADY HAVE THOSE FEATURES !!!!! IT IS CALLED DECNET OVER IP !!!!!

Why on earth would any one try to invent something that is already
there, that is plain silly. No other OS could use those features.

Dirk Munk

unread,
Sep 18, 2016, 12:01:08 PM9/18/16
to
What "rest" do you mean? The OSI transport layers? They don't change and
are part of kit. If you don't use them, they will not bother you.

roger...@gmail.com

unread,
Sep 18, 2016, 12:10:06 PM9/18/16
to
On Sunday, September 18, 2016 at 3:32:44 AM UTC-7, Dirk Munk wrote:
>
> I will go further then that. By sticking to DECnet Phase IV, you will
> affectively kill DECnet. If DECnet is nothing else then an IP port for
> your network people, then who cares. If it is a completely different
> network environment, it will be all the more reason to kick DECnet and
> even VMS out.
>
> Does this make sense to you?

I'll take the blame. I've also been blamed for killing CP/M (by sticking
with CP/M 2.2) and WordStar (by sticking with WordStar 4).

It's only obsolete when something better comes along.
--
roger ivie
roger...@gmail.com

Dirk Munk

unread,
Sep 18, 2016, 12:28:35 PM9/18/16
to
Yes DECnet is very obsolete for VMS. I'm sorry, I've forgotten this.
What is the plain IP replacement for something simple as FAL please?

Scott Dorsey

unread,
Sep 18, 2016, 1:16:29 PM9/18/16
to
Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>Den 2016-09-18 kl. 17:14, skrev Scott Dorsey:
>> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>>
>>> I think we have to accept that the rest of the world selected
>>> TCPIP for networking.
>>
>> And, that being the case, we need to have the same features that people
>> have liked with DECNET (such as the remote save sets) available with IP.
>
>Who are "we"? The (remaining) VMS user community? Do we think that we
>can decide what should be used on networks or the internet in general?

The remaining VMS user community.

What is used on the internet in general, we can't control. But how VMS
supports it is something that maybe we can.

>My guess is that we simply have to learn to live without remote save sets.

Why? Why can't that be implemented readily over IP? Either the way Unix
systems do it with a false filesystem that is really a front end to sftp,
or the way Windows systems do it with a filesystem that is a front end to
smb?

Either one would be fine, it would give us the functionality we want, using
existing network infrastructure.

>The best service we can do for VMS is to "play well" with whatever is
>expected on todays networks. Right, there is DECnet-over-IP, but it
>seems as most user/sites simply decided to use TCPIP tools directly.

I agree thoroughly. Doing that means integrating IP more tightly into
VMS and removing some legacy DECNET stuff from VMS.

>> In the Unix world, I use the SFTP filesystem for a lot of things that I
>> would have done more easily with DECNET transfers in the VMS world. In
>> the Windows world they have SMB fileshares integrated in much the way
>> DECNET is integrated into VMS.
>
>I would guess there are a few more Windows nodes out there, then there
>are VMS nodes. I guess volume does have *some* impact here.

Not only that, but both sftp and smb are routable over the public
internet. Although if I had to choose a protocol for the job I would
not choose smb.

Scott Dorsey

unread,
Sep 18, 2016, 1:17:59 PM9/18/16
to
Dirk Munk <mu...@home.nl> wrote:
>Scott Dorsey wrote:
>> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>>
>>> I think we have to accept that the rest of the world selected
>>> TCPIP for networking.
>>
>> And, that being the case, we need to have the same features that
>> people
>> have liked with DECNET (such as the remote save sets) available with > IP.
>
>YOU ALREADY HAVE THOSE FEATURES !!!!! IT IS CALLED DECNET OVER IP !!!!!
>
>Why on earth would any one try to invent something that is already
>there, that is plain silly. No other OS could use those features.

There's the problem right there. "No other OS could use those features."

Maybe I want to put my remote saveset on a Solaris machine. Maybe I
want to put it on a disk appliance. We live in a world where we need
to coexist.

Dirk Munk

unread,
Sep 18, 2016, 1:46:10 PM9/18/16
to
That is, or better will be possible.
You create a container file on any OS, and offer that container file
over iSCSI to VMS. VMS will see a volume, you can format that volume
with VMS, and use it to store data.
The host operating system will only see a very big file, it can not look
inside the container disk for individual VMS files..

Scott Dorsey

unread,
Sep 18, 2016, 2:16:41 PM9/18/16
to
Dirk Munk <mu...@home.nl> wrote:
>Scott Dorsey wrote:
>> Dirk Munk <mu...@home.nl> wrote:
>>> Scott Dorsey wrote:
>>>> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>>>>
>>>>> I think we have to accept that the rest of the world selected
>>>>> TCPIP for networking.
>>>>
>>>> And, that being the case, we need to have the same features that
>>>> people
>>>> have liked with DECNET (such as the remote save sets) available with > IP.
>>>
>>> YOU ALREADY HAVE THOSE FEATURES !!!!! IT IS CALLED DECNET OVER IP !!!!!
>>>
>>> Why on earth would any one try to invent something that is already
>>> there, that is plain silly. No other OS could use those features.
>>
>> There's the problem right there. "No other OS could use those features."
>>
>> Maybe I want to put my remote saveset on a Solaris machine. Maybe I
>> want to put it on a disk appliance. We live in a world where we need
>> to coexist.
>
>You create a container file on any OS, and offer that container file
>over iSCSI to VMS. VMS will see a volume, you can format that volume
>with VMS, and use it to store data.
>The host operating system will only see a very big file, it can not look
>inside the container disk for individual VMS files..

That doesn't sound very much like compatibility to me.

Sheesh, just give me a standardized shared filesystem over IP, that I can
address from the command line. With good performance. I don't even care
what kind it is as long as it's standard and widely-compatible.

There was a time when DECNET was a great thing. Back in those days, my
employers ran a network with over a thousand DECNET notes in several
areas. We were on NREN so that we could readily copy a file over to a
university in Spain or vice-versa. It was great. If anything went wrong,
I could call the networking office and they would fix it because everybody
there knew DECNET.

The last two DECNET nodes shut down a couple years ago, after a decade or
so of being tunnelled through IP and a decade of my having to listen to
the networking guys about "those weird-ass servers."

It was here, and it was good, and it was widely compatible. But it's not
here any more, it's not good any more, and it sure isn't compatible with
anything much any more. There was a time when it would have been possible
to extend it and keep it living, but that window closed long ago. It's
time to leave it dead and stop wasting time, energy, and money that could
be spent taking care of the living.

It's time to let it go along with SNA and Appletalk...

David Froble

unread,
Sep 18, 2016, 2:51:18 PM9/18/16
to
I don't have any Solaris.

I don't have any *ix.

This is what DECnet does for me. It can do more, but this one example is good
enough.

$ DISK0:
$ backup/image/noalias/ignore=(LABEL,INTERLOCK) DISK0: -
AS800::DISK2:[BACKUP]DFE90A_DISK0.BCK /save_set
$
$ DISK1:
$ backup/image/noalias/ignore=(LABEL,INTERLOCK) DISK1: -
AS800::DISK2:[BACKUP]DFE90A_DISK1.BCK /save_set

Ok, now that considered a utility, similar to DIRECTORY, SUBMIT, and such. Why
argue for one and want to do away with the other?

No, I don't use DECnet for general network stuff. TCPIP won that war long ago.
But that doesn't mean DECnet cannot be useful on VMS systems.

If anyone wants to cut something, climb out on a limb, and cut closer to the
tree than where you are. Leave my DECnet alone. It ain't hurting you. It
doesn't cost you anything.

And yes, I'm aware that V could do the same, but I don't need it, IV is just
fine for me.

Some of you must be bored and have nothing better to do ....

Alan Frisbie

unread,
Sep 18, 2016, 3:31:10 PM9/18/16
to
On 09/18/2016 12:18 AM, Paul Sture wrote:

> I'd certainly miss one or two things that DECnet does:
>
> o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail of software
> installations and configuration sessions. Yes, many terminal emulators can
> do logging, but those logs aren't on the target system.
>
> o - using DECnet as a means of placing BACKUP savesets on another node, and
> restoring them from other nodes (where 'other' can be either local or
> remote).
>
> o - DECnet tasks. Useful but I haven't seen many customers use these.
>
> o - FAL

I would certainly miss the ability to talk to my RSX-11 systems.
They (both real physical ones and SIMH instances) may be old,
but they just sit there and work.

Alan

Scott Dorsey

unread,
Sep 18, 2016, 3:38:53 PM9/18/16
to
David Froble <da...@tsoft-inc.com> wrote:
>I don't have any Solaris.
>
>I don't have any *ix.

You're in the minority, sadly.

>This is what DECnet does for me. It can do more, but this one example is good
>enough.
>
>$ DISK0:
>$ backup/image/noalias/ignore=(LABEL,INTERLOCK) DISK0: -
> AS800::DISK2:[BACKUP]DFE90A_DISK0.BCK /save_set
>$
>$ DISK1:
>$ backup/image/noalias/ignore=(LABEL,INTERLOCK) DISK1: -
> AS800::DISK2:[BACKUP]DFE90A_DISK1.BCK /save_set
>
>Ok, now that considered a utility, similar to DIRECTORY, SUBMIT, and such. Why
>argue for one and want to do away with the other?

I'm not. I'm arguing for the ability to do exactly the same thing with no
changes (perhaps not even a syntax change) but with the underlying mechanism
standardized and compatible with other systems.

Jan-Erik Soderholm

unread,
Sep 18, 2016, 4:40:43 PM9/18/16
to
We have *all* storage of our VMS system on an IBM V7000 SAN. No "local"
disks at all. So all data and the backups are already on "some other
system". Backups are in IBM/Tivoli b.t.w. We do not handle any regular
BACKUP save sets at all, either local or remote.



Kerry Main

unread,
Sep 18, 2016, 7:05:04 PM9/18/16
to comp.os.vms to email gateway
Those that hang on to IPV4 are in the same boat as those that
hang on to DECnet Ph IV.

Reference:
https://www.google.com/intl/en/ipv6/
https://www.google.com/intl/en/ipv6/faq.html

Unfortunately for both camps, the replacements for IPV4 (IPV6)
and DECnet Ph IV (Ph V) are not without their own issues and
challenges. However, this does not mean one should ignore the
coming realities.

The reality is that there will need to be much longer periods of
coexistence than the originators of both IPV6 and DECnet Ph V had
ever envisioned.

The reality is that the future IoT world is not going to happen
on IPV4, so start planning your coexistence strategy now.

Btw, if you think other countries are not getting the jump on
things for the future, check this link out:

http://bit.ly/2d490EA
China's first IPv6 network enters operation - Network links 25
universities in 20 cities at speeds up to 10Gbps

The above article was from 2004.

A bit more current - June 2012:
http://bit.ly/2d49g6E
China racing towards IPV6


Regards,

Kerry Main
Kerry dot main at starkgaming dot com







Dirk Munk

unread,
Sep 19, 2016, 2:55:29 AM9/19/16
to
Yes, and if you had switched to DECnet Phase V over IP, your network
guys would never have known you're using DECnet. No need for tunnels,
completely transparent.

If your community would have done that, you still could be using DECnet.
In fact if you're still using VMS, you can set it up now, it will take
about 15 minutes per server, and you will have your full DECnet
functionality back. Except for perhaps some firewall settings (port
numbers), your network guys will have no idea.


> It was here, and it was good, and it was widely compatible. But it's not
> here any more, it's not good any more, and it sure isn't compatible with
> anything much any more. There was a time when it would have been possible
> to extend it and keep it living, but that window closed long ago. It's
> time to leave it dead and stop wasting time, energy, and money that could
> be spent taking care of the living.
>
> It's time to let it go along with SNA and Appletalk...
> --scott
>

Appletalk changed from the Appletalk/Ethertalk transport protocols to
the IP transport protocol. Windows changed from the Netbeui transport
protocol to IP. And DECnet can use IP as well.

Dirk Munk

unread,
Sep 19, 2016, 2:59:35 AM9/19/16
to
Putting your VMS volumes on a multi-vendor SAN storage array is nothing
new, it has been around for at least 15 years or so.

I wonder if IBM backup haa the same functionality as VMS backup. There
is a lot of intelligence in VMS Backup!


Dirk Munk

unread,
Sep 19, 2016, 3:16:45 AM9/19/16
to
How do you want to achieve that? VMS has file versions, Unix and Windows
don't. Do you want to abandon VMS file versions, or should Unix, Linux
and Windows learn hows to use file versions?

For Unix and Windows a file starts at point A and ends at point B, and
in between are bytes. If these files have record separators, then it
will be a <cr> for the one, and a <lf> for the other. VMS knows these
files as stream files, or files with an undefined contents. Normal VMS
files are structured, a concept completely unknown to Unix and Windows.
Cobol for instance needs structured files, so a Cobol compiler on Unix
or Windows has to define its own structured files, but Unix and Windows
will be completely unaware of that.

How do you want to combine these things in one file system?

johnwa...@yahoo.co.uk

unread,
Sep 19, 2016, 5:35:34 AM9/19/16
to
Interesting isn't it.

Shiny sells, but engineering details make things actually
work (or, quite frequently in IT, not work) right.

Engineering by PowerPoint, as the NASA Columbia inquiry
(and various others since) called it. Others call it
faith-based engineering.

BlackCat

unread,
Sep 19, 2016, 8:08:16 AM9/19/16
to
On 18.09.2016 09:18, Paul Sture wrote:
> On 2016-09-17, David Froble <da...@tsoft-inc.com> wrote:
>> Stephen Hoffman wrote:
>>>
>>> I'd be seriously tempted to announce the deprecation and eventual
>>> removal of DECnet, for that matter.
>>
>> Booo! Hisssss!
>>
>> Ok, we know it's not secure. Run at your own risk.
>>
>> I'm guessing that DECnet users use it only in house, for FAL and such, so if the
>> in house environment is secure, then security isn't an issue for DECnet.
>>
>> If it's not going to take up time and effort, then why kill it off?
>>
>> I personally find it can be useful.
>>
>> It sure is handy when you need to shutdown and re-start TCP/IP on a remote (but
>> in house) system.
>
> I'd certainly miss one or two things that DECnet does:
>
> o - the ability to do a SET HOST 0 /LOG= to get a log / audit trail of software
> installations and configuration sessions. Yes, many terminal emulators can
> do logging, but those logs aren't on the target system.
>
> o - using DECnet as a means of placing BACKUP savesets on another node, and
> restoring them from other nodes (where 'other' can be either local or
> remote).
>
> o - DECnet tasks. Useful but I haven't seen many customers use these.
>
> o - FAL
>
Surely many of the existing OpenVMS customers, like ours, are using applications that still use DECnet.
So why would you want to make these unhappy? No one is asking for new functionality (bar a few minor improvements), but just
continued support.
Even though DECnet is a (very) mature product, I have yet to see the equivalent loadsharing and failover capabilities in other
network protocols.

Johnny Billquist

unread,
Sep 19, 2016, 8:37:03 AM9/19/16
to
On 2016-09-18 12:32, Dirk Munk wrote:

> My ideas about Phase IV are not just opinions. Phase IV is a dead end,
> it won't be long before you can't buy routers for Phase IV. You can't
> make Phase IV traffic secure, you can't use it in a IP-only network
> environment, you can't use it over the internet. Those are facts, not
> opinions.

They are opinions, and not facts. Or else I must be dreaming as my RSX
system is talking to VMS systems using DECnet phase IV over IP.

Hmm. Nope. Not dreaming... The circuits are still up.

Johnny

Johnny Billquist

unread,
Sep 19, 2016, 8:41:41 AM9/19/16
to
NFS or Samba are the most common ones, but there are many...

Johnny

David Froble

unread,
Sep 19, 2016, 9:02:13 AM9/19/16
to
This! This is the reality. Is there any reason to piss off currently happy
customers?

I'd guess that if DECnet is enhanced that many current users would NOT do
anything to make use of new features. If they needed more, they would have
moved to something else long ago.

Bob Koehler

unread,
Sep 19, 2016, 9:32:35 AM9/19/16
to
In article <nrlmbk$if0$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>
> In general I agree with what you've written. I consider DECnet as a part of
> VMS, and if one really doesn't want VMS, then just go and use something else.

Having used DECnet on VMS, MVS, RSX, TOPS-20, MS-DOS, Ultrix, AIX, and
Linux, I find your concept much too narrow for reality.

Bob Koehler

unread,
Sep 19, 2016, 9:37:00 AM9/19/16
to
In article <SgzDz.577571$uE7.1...@fx14.ams1>, Dirk Munk <mu...@home.nl> writes:
>
> Yes DECnet is very obsolete for VMS. I'm sorry, I've forgotten this.
> What is the plain IP replacement for something simple as FAL please?

DEC submitted a RFC for a FAL-like capability. It didn't get adopted.
ISO/OSI also submitted an RFC for thier equivalent to FAL as
an IP protocol. It dwasn't adopted, either.

In a world where a whole bunch of folks run around on thier
byte-stream-only file systems caliming "binary always works", the
recognition of more powerfull file systems with other file organizations
can't get above the hype.

Bob Koehler

unread,
Sep 19, 2016, 9:39:53 AM9/19/16
to
In article <nrmi85$gf0$1...@panix3.panix.com>, klu...@panix.com (Scott Dorsey) writes:
>
> Maybe I want to put my remote saveset on a Solaris machine. Maybe I
> want to put it on a disk appliance. We live in a world where we need
> to coexist.

Excelent example, Both Sun and Ki used to sell DECnet for Solaris.
Don't know if they still do. The Linux DECnet code is probably not
all that hard to port to a UNIX.

But I do think IP remote savesets could be added to BACKUP, just like
FTP and RCP were added to COPY.

Sometime after VSI becomes a profit making business.

Scott Dorsey

unread,
Sep 19, 2016, 9:46:55 AM9/19/16
to
In article <AZLDz.728601$m8.4...@fx12.ams1>, Dirk Munk <mu...@home.nl> wrote:
>
>Yes, and if you had switched to DECnet Phase V over IP, your network
>guys would never have known you're using DECnet. No need for tunnels,
>completely transparent.

We did that around fifteen years ago. It's completely transparent when
everything is working perfectly but as soon as there are performance issues,
diagnosis becomes a problem because the networking people are not used to
seeing that traffic.

>If your community would have done that, you still could be using DECnet.
>In fact if you're still using VMS, you can set it up now, it will take
>about 15 minutes per server, and you will have your full DECnet
>functionality back. Except for perhaps some firewall settings (port
>numbers), your network guys will have no idea.

We're using VMS and we're using IP and it's just fine.

Scott Dorsey

unread,
Sep 19, 2016, 9:48:43 AM9/19/16
to
Dirk Munk <mu...@home.nl> wrote:
> Scott Dorsey writes:
>>
>> Sheesh, just give me a standardized shared filesystem over IP, that I can
>> address from the command line. With good performance. I don't even care
>> what kind it is as long as it's standard and widely-compatible.
>
>How do you want to achieve that? VMS has file versions, Unix and Windows
>don't. Do you want to abandon VMS file versions, or should Unix, Linux
>and Windows learn hows to use file versions?

The way Multinet did it (making the file version part of the filename)
works pretty well.

>For Unix and Windows a file starts at point A and ends at point B, and
>in between are bytes. If these files have record separators, then it
>will be a <cr> for the one, and a <lf> for the other. VMS knows these
>files as stream files, or files with an undefined contents. Normal VMS
>files are structured, a concept completely unknown to Unix and Windows.
>Cobol for instance needs structured files, so a Cobol compiler on Unix
>or Windows has to define its own structured files, but Unix and Windows
>will be completely unaware of that.

Take a look at how Multinet does that too. These were solved problems decades
ago.

Dirk Munk

unread,
Sep 19, 2016, 10:16:41 AM9/19/16
to
Yes, they had Phase IV, not Phase V.

Stephen Hoffman

unread,
Sep 19, 2016, 10:35:51 AM9/19/16
to
On 2016-09-18 07:18:38 +0000, Paul Sture said:

> I'd certainly miss one or two things...



Nobody here — nobody — wants to have to rework their existing
application code. Ask that question of anyone around, and you will
get the obvious and expected answer.

A better question is... If you're overhauling an existing or doing a
wholly new application on OpenVMS, what features of OpenVMS do you plan
to use or want to use? What existing features would you not plan to
use?

The use of DECnet — wonderful old protocol, that — just isn't on that
list for the vast majority of sites. Yes, a few of you have a PDP-11
or some other weird hardware stashed somewhere. Good on you. You're
not the future of any operating system. DECnet is simply not going to
be used in any substantial application updates, and not for new
application designs and deployments.

There are more than a few areas of OpenVMS that really need help, too.
DECnet isn't one of those areas, but any effort spent on those old
areas such as DECnet — testing, qualification, kitting, securing,
whatever — is effort that could go to new work and new testing and new
features for those folks that are moving forward.

Those of you with existing applications? If any of you have DECnet or
telnet or ftp or otherwise — and claim you believe in OpenVMS security
— please stop deluding yourselves. Because that's what you are doing.
Go get your VT52 terminals powered up and fire up your TECO editor or
whatever your chosen interface, and start working to get your
applications and your code over to TLS and secure connections and IPv6.

Unfortunately in current OpenVMS, getting TLS and IPv6 working involves
much more effort than it should be and is much less integrated than
DECnet ever was, which should tell you something about how OpenVMS has
been backsliding.

Even given infinite resources, some code has to go away. Some
judicious and carefully-handled code has to go away. There is some
code that is an anchor impeding progress. Failure to remove runt or
deprecated or problematic APIs inevitably produces a ginormous and
unmaintainable and un-documentable and un-securable morass — whether
it's an application or an operating system.

Yes, customers will have to rework some of their code for better
security or better features. There's just no way around that. The
cost of creating compatibility eventually and inevitably goes to
infinity, and — as I have pointed to specific cases here in comp.os.vms
before — the desire for compatibility can block all changes in areas
that really need to be changed to better secure the platform. You can
delude yourself into believing the password hash is secure — and it's
way too fast to be secure — or that VAX C code isn't buggy and unstable
and quite possibly insecure — or any number of other issues in older
APIs and older code. There are specific things that need to be
changed that can't be changed without breaking compatibility, or that
deprecation will produce better results in actively-maintained and new
code.

If you can't rework your application code, then stay on a long-term
support release or — as more than a few folks have done over the years
— simply fall off of support entirely.

Catering to the folks that aren't reworking their code — whether for
good and valid reasons, or just because it's been abandoned — just
holds back OpenVMS and the rest of the folks that are able and willing
to do that. And it saddles the folks that can rework their code with
the added costs and complexities and difficulties. Have you looked at
doing 64-bit addressing on OpenVMS? It's a marvelous design that
provides compatibility, and makes new 64-bit work much more effort than
it should be. But I digress.

VSI can either do what's been done for the last years and cater
exclusively to the existing installed base — likely lucrative for a
while, but we all know where that ends — or they can internalize and
adopt the leadership role they already possess where they want to take
OpenVMS and where they want or need to improve OpenVMS and start to
work toward and start to tell us that story. Clinging to old APIs and
insecure network protocols like DECnet and telnet and ftp and
preserving the current and unintegrated IP and bad IPv6 support is not
the future of any viable operating system platform. OpenVMS can
either cater to folks with old legacy apps — probably a decent
business, at least for a few years — or VSI can get going toward a
modern operating system with modern features, modern capabilities,
marketing, and drag the apps forward...

Well, you get the picture...




--
Pure Personal Opinion | HoffmanLabs LLC

Michael Moroney

unread,
Sep 19, 2016, 11:29:35 AM9/19/16
to
I am following this thread with interest because I put
a bunch of effort getting DECnet V/DECnet Plus to build
at VSI, what we got from HP was a bit of a mess. Since
then I wondered, how many customers actually use DECnet V
(or DECnet IV), and for what.

Of course the VMS builtin where you could access any
file on your DECnet with almost any software just by
using the file spec node::dev:[dir.sub]file.ext is
really great, and is missed on TCP/IP.

Stephen Hoffman

unread,
Sep 19, 2016, 11:45:02 AM9/19/16
to
On 2016-09-19 15:28:27 +0000, Michael Moroney said:

> Of course the VMS builtin where you could access any file on your
> DECnet with almost any software just by using the file spec
> node::dev:[dir.sub]file.ext is really great, and is missed on TCP/IP.

There's nothing to preclude RMS from being updated to connect to remote
RMS FAL servers via TLS, using either certificates or Kerberos for
authentication.

Or — for a somewhat larger investment — via sftp, rather than requiring
a FAL server.

It'd be easier to implement if there was a central distributed
authentication service and password store on OpenVMS, too. But I
digress.

On other platforms, this involves a mount and the use of SMB or NFS for
remote access, or ssh. Remote FAL file access on OpenVMS hasn't been
commonly used around any of the local systems I'm aware of or deal
with, outside of file copies or maybe TYPE commands — and I can
trivially display file contents or various other operations via ssh, if
I'm not copying the file.

But then I'd much rather see COPY /SFTP and better IPv6 integration
than any sort of support for FAL access via TLS or sftp, too. Once
the base OS is IP-aware and IP-integrated to at least the level of
DECnet, then...

Jim

unread,
Sep 19, 2016, 11:47:52 AM9/19/16
to
On Monday, September 19, 2016 at 11:29:35 AM UTC-4, Michael Moroney wrote:
> I am following this thread with interest because I put
> a bunch of effort getting DECnet V/DECnet Plus to build
> at VSI, what we got from HP was a bit of a mess. Since
> then I wondered, how many customers actually use DECnet V
> (or DECnet IV), and for what.

Current VSI customer here using DECnet "SET HOST 0/LOG" to capture keystrokes for sessions used by system support staff. Occasional use of other DECnet applications occurs - but, we wouldn't likely miss any of those should they disappear.

Kerry Main

unread,
Sep 19, 2016, 12:05:04 PM9/19/16
to comp.os.vms to email gateway
> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Michael Moroney via Info-vax
> Sent: 19-Sep-16 11:28 AM
> To: info...@rbnsn.com
> Cc: Michael Moroney <mor...@world.std.spaamtrap.com>
> Subject: Re: [Info-vax] What would you miss if DECnet got the
> chop? Was: "bad select 38" (OpenSSL on VMS)
>
An interesting note on this ..

I was doing large DC migration last year where the mission
critical OS was Solaris (some Windows, Linux). They had a huge
amount of batch jobs (thousands per day) using a commercial
scheduler (forget which one).

They were constantly transferring files all over the place
internally for maint, archiving, reporting and likely a host of
other reasons via sftp. The sftp pwds were maintained inside the
batch jobs. There was a number of different application support
groups so changes had to be coordinated between groups.

They had security policies in place which stated pwds needed to
change something like every 120 days. It was a horrendous mess as
they had to go into all of their batch jobs to fix passwords and
then coordinate with impacted groups on other systems.

While I am sure there must be cleaner ways to do this, there was
just so many jobs and different groups, that even today, this is
their reality using TCPIP internally.

Point being is that even if it is internal use only, the DECnet
proxy access is not something to be simply thrown away.

Scott Dorsey

unread,
Sep 19, 2016, 12:15:59 PM9/19/16
to
Kerry Main <kemain...@gmail.com> wrote:
>I was doing large DC migration last year where the mission
>critical OS was Solaris (some Windows, Linux). They had a huge
>amount of batch jobs (thousands per day) using a commercial
>scheduler (forget which one).
>
>They were constantly transferring files all over the place
>internally for maint, archiving, reporting and likely a host of
>other reasons via sftp. The sftp pwds were maintained inside the
>batch jobs. There was a number of different application support
>groups so changes had to be coordinated between groups.
>
>They had security policies in place which stated pwds needed to
>change something like every 120 days. It was a horrendous mess as
>they had to go into all of their batch jobs to fix passwords and
>then coordinate with impacted groups on other systems.

This is incredibly boneheaded. sftp has public key stuff built into it
to allow this sort of thing to be done transparently without any need to
have passwords in a file.

The people responsible for this should be taken out and shot. This
violates so many common sense security rules it's not funny, and in
the end it makes things less convenient rather than more.

>While I am sure there must be cleaner ways to do this, there was
>just so many jobs and different groups, that even today, this is
>their reality using TCPIP internally.

Sounds to me like your customer needs to hire someone who actually
knows about TCP/IP, and fast. Before they get compromised, hopefully.

>Point being is that even if it is internal use only, the DECnet
>proxy access is not something to be simply thrown away.

I assure you that the same incompetent morons who put passwords in files
for sftp would be doing it for decnet as well..

Scott Dorsey

unread,
Sep 19, 2016, 12:18:07 PM9/19/16
to
Michael Moroney <mor...@world.std.spaamtrap.com> wrote:
>I am following this thread with interest because I put
>a bunch of effort getting DECnet V/DECnet Plus to build
>at VSI, what we got from HP was a bit of a mess. Since
>then I wondered, how many customers actually use DECnet V
>(or DECnet IV), and for what.

It's all gone here, and at all of our customers.

>Of course the VMS builtin where you could access any
>file on your DECnet with almost any software just by
>using the file spec node::dev:[dir.sub]file.ext is
>really great, and is missed on TCP/IP.

Absolutely. VMS clearly needs some way of doing that
transparently and with file format information preserved.
It doesn't need DECNET underneath to do it though.

Dirk Munk

unread,
Sep 19, 2016, 2:10:40 PM9/19/16
to
Dear Michael,

What I would like to see is the replacement of RFC1006 and RFC1859 in
DECnet Phase V by RFC2126. That will add the possibility to run
DECnet/OSI over IPv6. This RFC is almost 20 years old by now, and should
have been implemented years ago (not the fault of VSI of course).

Complement that by IPsec, and we can have the safest DECnet traffic
possible, as well as the safest cluster traffic possible.

How difficult can it be???

I see absolutely no reason for yet another set of horrible IP protocols
with security and encryption on the application level.

Network security en encryption are functions of the network, *not* of
applications.

IP people are hobbyists, so they design all kind of protocols for just
simple file transfers. FTP, FTPS, SFTP, SCP, and I'm sure there are even
more. It is ridiculous.

DECnet is deeply embedded in VMS, it is relatively very simple to use,
even from within programs.

For VMS <> VMS traffic it is great, for other kinds of traffic use
something different.

Dirk Munk

unread,
Sep 19, 2016, 2:25:11 PM9/19/16
to
*IF* you would like to set up such a file system, it should be something
like Stornext, a distributed file system.

Dirk Munk

unread,
Sep 19, 2016, 2:51:33 PM9/19/16
to
If you set up DECnet over IP, you can do it.

copy HPE.com::$1$DKA100:[Scott]textfile.txt VSI.com::$1$DKA400:[Dorsey]

it's already there, how difficult is it to understand that.

Why do you want to reinvent something that is already there.

Not only that it is already there, it has far more functionality then
just a simple file transfer.

Perhaps we should give DECnet over IP a new name, ICFV. IP Connector For
VMS, it would make a lot of people very happy, a new IP utility for VMS.

Some mentioned that Multinet has it too. That is incorrect, Multinet has
to translate DECnet phase IV names & addresses into IP DNS names. You
have to set up such a translation table.

I have no idea what happens if the remote node has a different DECnet
address the you have in your translation table.

Suppose you set up a translation entry for DECnet node ABC with DECnet
address 5.1 and DNS name remote.away.com.

However remote.away.com has DECnet address 10.1, will the communication
fail? I expect it will.

So Multinet uses tunneling, whereas DECnet Phase V does not.

hb

unread,
Sep 19, 2016, 2:54:02 PM9/19/16
to
On 09/19/2016 03:48 PM, Scott Dorsey wrote:
> The way Multinet did it (making the file version part of the filename)
> works pretty well.

Which is how a filename is stored in the ods-2/5 file header, anyway.
Only directories contain a single file name and (separate) versions.

David Froble

unread,
Sep 19, 2016, 2:55:54 PM9/19/16
to
You're always so easy to get along with Bob ....

:-)

Yes, there have been implementations of the DECnet transport part on multiple
OSs, both DEC and others. But, as far as I know, there has not been the full
range of DECnet tools available on those environments. As an example, does FAL
exist on all those implementations?

For me, it's the utilities, tools, and such that I feel make DECnet worth
keeping around. Much more so than the communications stuff. Of course, those
utilities, tools, and such do use the communications stuff.

David Froble

unread,
Sep 19, 2016, 3:13:24 PM9/19/16
to
Michael Moroney wrote:
> I am following this thread with interest because I put
> a bunch of effort getting DECnet V/DECnet Plus to build
> at VSI, what we got from HP was a bit of a mess.

I've read that statement way too many times. Got to wonder, "what were they
thinking", if indeed they (HP) was thinking at all.

> Since
> then I wondered, how many customers actually use DECnet V
> (or DECnet IV), and for what.

Then you would know more than most how much effort it will be to keep DECnet
around, perhaps without any new work. Can you answer that question? How much
effort is required to keep DECnet on VMS?

> Of course the VMS builtin where you could access any
> file on your DECnet with almost any software just by
> using the file spec node::dev:[dir.sub]file.ext is
> really great, and is missed on TCP/IP.

It's really things like this that are valuable. I really don't care about the
communications link. That said, I'm sure there are those still using it.

So, for many, the real questions are:

1) What capabilities of DECnet should be retained?

and

2) What effort would be required to implement those capabilities using TCP/IP?

Hans Vlems

unread,
Sep 19, 2016, 3:14:51 PM9/19/16
to
I guess commercially DECnet is as dead as a dodo.
Functionally, for my own use, three things speak for it:
1 it is very nicely integrated into DCL
2 it allows network connectivity to systems that do not have IP
3 it allows me to configure the IP stack and log on via ethernet (yes LAT dors that too).

I'll stay away from the phase IV / V discussion because it's outside the scope of the question.
Hans

David Froble

unread,
Sep 19, 2016, 3:19:33 PM9/19/16
to
Ok, more thoughts.

I'm guessing TCP/IP is sort of the same on multiple platforms. Maybe not. But
if it is, then implementing some of the DECnet capabilities using TCP/IP might
not be considered part of TCP/IP, but VMS extensions (tools) to the product.

But, then it could be argued, DECnet as it is now is just that, VMS specific tools.

One could ask, why re-invent the wheel?

David Froble

unread,
Sep 19, 2016, 3:27:46 PM9/19/16
to
I'm basically lazy ....

I've thought of implementing a FAL using sockets ....

Did I mention, I'm lazy? It would be a lot of work, and the first thing that
would happen is criticism of the decisions I'd have made. So, why bother? At
least as long as DECnet is available ....

Dirk Munk

unread,
Sep 19, 2016, 3:33:10 PM9/19/16
to
David Froble wrote:
> Bob Koehler wrote:
>> In article <nrlmbk$if0$1...@dont-email.me>, David Froble
>> <da...@tsoft-inc.com> writes:
>>> In general I agree with what you've written. I consider DECnet as a
>>> part of VMS, and if one really doesn't want VMS, then just go and use
>>> something else.
>>
>> Having used DECnet on VMS, MVS, RSX, TOPS-20, MS-DOS, Ultrix, AIX, and
>> Linux, I find your concept much too narrow for reality.
>>
>
> You're always so easy to get along with Bob ....
>
> :-)
>
> Yes, there have been implementations of the DECnet transport part on
> multiple OSs, both DEC and others. But, as far as I know, there has not
> been the full range of DECnet tools available on those environments. As
> an example, does FAL exist on all those implementations?

Bob didn't mention MAC OS. MACs also had FAL, and it was a beautiful
implementation. If you copied a file from MAC to MAC (using your VMS
system for the command), the complete file would be transferred,
resource fork + data fork. If you copied a file to your VMS system, only
the data fork would be copied, the resource fork was useless for VMS.

Indexed files on RSX and VMS are different. If you copy an indexed file
between RSX and VMS, you get a proper indexed file on the other side (if
it was within the limits of that OS of course).

FAL knows the characteristics of the OS, and will 'translate' files if
necessary.

No such functionality exists with IP.

Dirk Munk

unread,
Sep 19, 2016, 3:36:28 PM9/19/16
to
Hallelujah, thank you, thank you.

johnwa...@yahoo.co.uk

unread,
Sep 19, 2016, 3:55:05 PM9/19/16
to
Careful. Terminology matters. Proper FAL functionality
doesn't exist within the usual IP applications. There
could be (are?) ways of doing FAL over IP using something
other than the usual IP-oriented applications. One of
them might be to use one of the various ways of routing
DECnet over IP, assuming both ends speak FAL and DECnet.
(I think you already knew this - others may not).

Apologies if that's not as clear as it should be, it's
been a long day.

Michael Moroney

unread,
Sep 19, 2016, 3:59:59 PM9/19/16
to
David Froble <da...@tsoft-inc.com> writes:

>Michael Moroney wrote:

>> Since
>> then I wondered, how many customers actually use DECnet V
>> (or DECnet IV), and for what.

>Then you would know more than most how much effort it will be to keep DECnet
>around, perhaps without any new work. Can you answer that question? How much
>effort is required to keep DECnet on VMS?

Now that it builds, essentially zero if there is no new work and no
bugs reported. But we had to be able to build it in case someone
does report a bug, and we are to create a version with the fix.

Of course, once x86 comes along, we would have to build it (and
everything else) for x86.

There is always a chance some big VMS project breaks something in
DECnet that would require fixing ( = $$$) Perhaps the new file system?
I don't know.

Michael Moroney

unread,
Sep 19, 2016, 4:01:34 PM9/19/16
to
koe...@eisner.nospam.decuserve.org (Bob Koehler) writes:

>In article <SgzDz.577571$uE7.1...@fx14.ams1>, Dirk Munk <mu...@home.nl> writes:
>>
>> Yes DECnet is very obsolete for VMS. I'm sorry, I've forgotten this.
>> What is the plain IP replacement for something simple as FAL please?

> DEC submitted a RFC for a FAL-like capability. It didn't get adopted.
> ISO/OSI also submitted an RFC for thier equivalent to FAL as
> an IP protocol. It dwasn't adopted, either.

If anyone has a pointer to either of these proposals, I'd be interesting
in looking through them.

Bob Koehler

unread,
Sep 19, 2016, 4:08:48 PM9/19/16
to
In article <ySVDz.652732$_Y7.6...@fx21.ams1>, Dirk Munk <mu...@home.nl> writes:
>
> DECnet is deeply embedded in VMS, it is relatively very simple to use,
> even from within programs.

DECnet is known by RMS. A very usefull decision. Requires FAL.
So all the HLL got DECnet file access without knowing it.

Look at the workarounds made available when the FAL server is running
on UNIX. Yes, they worked. No, I didn't try to use them from
Fortran.

Bob Koehler

unread,
Sep 19, 2016, 4:10:25 PM9/19/16
to
In article <nrpcbi$rk8$1...@dont-email.me>, David Froble <da...@tsoft-inc.com> writes:
>
> Yes, there have been implementations of the DECnet transport part on multiple
> OSs, both DEC and others. But, as far as I know, there has not been the full
> range of DECnet tools available on those environments. As an example, does FAL
> exist on all those implementations?

Yes, they all had FAL. Can't access files via DECnet without a FAL.

Bob Koehler

unread,
Sep 19, 2016, 4:13:04 PM9/19/16
to
In article <U3XDz.520650$oJ4.4...@fx23.ams1>, Dirk Munk <mu...@home.nl> writes:
>
> Bob didn't mention MAC OS. MACs also had FAL, and it was a beautiful
> implementation. If you copied a file from MAC to MAC (using your VMS
> system for the command), the complete file would be transferred,
> resource fork + data fork. If you copied a file to your VMS system, only
> the data fork would be copied, the resource fork was useless for VMS.

Well, we had Macs, and we have Pathworks for Macs, but I only listed
DECnet implementations that I myself had used and we didn't have
DECnet on those Macs.

The wonderfull thing with FAL was that it sits on DNA, which
understands RMS on VMS, RMS and FCS on RSX, whatever they call it
on MVS, and byte streams on all those other things. Somebody really
did good work on DNA.

Dirk Munk

unread,
Sep 19, 2016, 4:23:17 PM9/19/16
to
I see no reason why the new file system should break DECnet. I suppose
it would require making changes to FAL.

Stephen Hoffman

unread,
Sep 19, 2016, 4:28:05 PM9/19/16
to
On 2016-09-19 16:03:57 +0000, Kerry Main said:

> An interesting note on this ..
>
> I was doing large DC migration last year where the mission critical OS
> was Solaris (some Windows, Linux). They had a huge amount of batch jobs
> (thousands per day) using a commercial scheduler (forget which one).
>
> They were constantly transferring files all over the place internally
> for maint, archiving, reporting and likely a host of other reasons via
> sftp. The sftp pwds were maintained inside the batch jobs. There was a
> number of different application support groups so changes had to be
> coordinated between groups.
>
> They had security policies in place which stated pwds needed to change
> something like every 120 days. It was a horrendous mess as they had to
> go into all of their batch jobs to fix passwords and then coordinate
> with impacted groups on other systems.
>
> While I am sure there must be cleaner ways to do this, there was just
> so many jobs and different groups, that even today, this is their
> reality using TCPIP internally.
>
> Point being is that even if it is internal use only, the DECnet proxy
> access is not something to be simply thrown away.

If the site is requiring password changes every four months — at least
some of the standards bodies are finally realizing the problems with
that, and NIST and other entities are finally starting to move away
from that recommendation — and if the site is not already using
certificates or (better) LDAP authentication? Um, okay. If the
folks are actually using hard-coded passwords in shell scripts (I hope
not!), then — sure — DECnet proxies are certainly an appropriate
(equally wonderfully bad) choice.

Absent extenuating circumstances or explicit waivers, I'd seriously
consider removing any security auditor or agency that approved a DECnet
connection in any environment that required secuity or handled
sensitive data, much less a DECnet connection involving a DECnet proxy
login.

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/

https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes

Dirk Munk

unread,
Sep 19, 2016, 4:57:07 PM9/19/16
to
No, it is not.

DECnet Phase IV and DECnet Phase V are two completely different products.

Phase V has a IP transport stack, DECnet nodes are known by their IP DNS
names. So you can use DECnet Phase V in an IP-only network.

Phase IV only knows the old Phase IV DNA stack, very much unwanted in
modern networks, and unusable on the internet.

Multinet can tunnel Phase IV traffic over IP, but that is a rather
static affair. You still have to use DECnet names, Multinet will
translate them to IP DNS names from a translation table.

If we both would have DECnet phase V over IP enabled, then I could use
this commandline to get a file from your VMS system:

copy vax.vlems.freenet.de::dka500:[public]text.txt []

No need for any preparation or configuration what so ever.

This will never be possible with Phase IV.

Dirk Munk

unread,
Sep 19, 2016, 5:00:03 PM9/19/16
to
I fully agree.

Jan-Erik Soderholm

unread,
Sep 19, 2016, 5:25:35 PM9/19/16
to
Den 2016-09-19 kl. 08:59, skrev Dirk Munk:
> Jan-Erik Soderholm wrote:
>> Den 2016-09-18 kl. 19:46, skrev Dirk Munk:
>>> Scott Dorsey wrote:
>>>> Dirk Munk <mu...@home.nl> wrote:
>>>>> Scott Dorsey wrote:
>>>>>> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>>>>>>
>>>>>>> I think we have to accept that the rest of the world selected
>>>>>>> TCPIP for networking.
>>>>>>
>>>>>> And, that being the case, we need to have the same features that
>>>>>> people
>>>>>> have liked with DECNET (such as the remote save sets) available
>>>>>> with > IP.
>>>>>
>>>>> YOU ALREADY HAVE THOSE FEATURES !!!!! IT IS CALLED DECNET OVER IP !!!!!
>>>>>
>>>>> Why on earth would any one try to invent something that is already
>>>>> there, that is plain silly. No other OS could use those features.
>>>>
>>>> There's the problem right there. "No other OS could use those
>>>> features."
>>>>
>>>> Maybe I want to put my remote saveset on a Solaris machine. Maybe I
>>>> want to put it on a disk appliance. We live in a world where we need
>>>> to coexist.
>>>> --scott
>>>>
>>>>
>>>
>>> That is, or better will be possible.
>>> You create a container file on any OS, and offer that container file over
>>> iSCSI to VMS. VMS will see a volume, you can format that volume with VMS,
>>> and use it to store data.
>>> The host operating system will only see a very big file, it can not look
>>> inside the container disk for individual VMS files..
>>
>> We have *all* storage of our VMS system on an IBM V7000 SAN. No "local"
>> disks at all. So all data and the backups are already on "some other
>> system". Backups are in IBM/Tivoli b.t.w. We do not handle any regular
>> BACKUP save sets at all, either local or remote.
>>
>
> Putting your VMS volumes on a multi-vendor SAN storage array is nothing
> new, it has been around for at least 15 years or so.
>
> I wonder if IBM backup haa the same functionality as VMS backup. There is a
> lot of intelligence in VMS Backup!
>
>

I have no idea what "IBM backup" is. We use ABC:

https://storserver.com/software/storserver-software-abc/

Jan-Erik Soderholm

unread,
Sep 19, 2016, 5:28:31 PM9/19/16
to
Den 2016-09-19 kl. 09:16, skrev Dirk Munk:
> Scott Dorsey wrote:
>> Dirk Munk <mu...@home.nl> wrote:
>>> Scott Dorsey wrote:
>>>> Dirk Munk <mu...@home.nl> wrote:
>>>>> Scott Dorsey wrote:
>>>>>> Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>>>>>>>
>>>>>>> I think we have to accept that the rest of the world selected
>>>>>>> TCPIP for networking.
>>>>>>
>>>>>> And, that being the case, we need to have the same features that
>>>>>> people
>>>>>> have liked with DECNET (such as the remote save sets) available with
>>>>>> > IP.
>>>>>
>>>>> YOU ALREADY HAVE THOSE FEATURES !!!!! IT IS CALLED DECNET OVER IP !!!!!
>>>>>
>>>>> Why on earth would any one try to invent something that is already
>>>>> there, that is plain silly. No other OS could use those features.
>>>>
>>>> There's the problem right there. "No other OS could use those features."
>>>>
>>>> Maybe I want to put my remote saveset on a Solaris machine. Maybe I
>>>> want to put it on a disk appliance. We live in a world where we need
>>>> to coexist.
>>>
>>> You create a container file on any OS, and offer that container file
>>> over iSCSI to VMS. VMS will see a volume, you can format that volume
>>> with VMS, and use it to store data.
>>> The host operating system will only see a very big file, it can not look
>>> inside the container disk for individual VMS files..
>>
>> That doesn't sound very much like compatibility to me.
>>
>> Sheesh, just give me a standardized shared filesystem over IP, that I can
>> address from the command line. With good performance. I don't even care
>> what kind it is as long as it's standard and widely-compatible.
>
> How do you want to achieve that? VMS has file versions, Unix and Windows
> don't. Do you want to abandon VMS file versions, or should Unix, Linux and
> Windows learn hows to use file versions?

In 99 cases out of 100 in real production environments, that "other"
system that your VMS systems are talkning to, are *not* VMS systems.

So the concept of file versions as we know it from VMS is irrelevant
when talkning to other systems anyway.


>
> For Unix and Windows a file starts at point A and ends at point B, and in
> between are bytes. If these files have record separators, then it will be a
> <cr> for the one, and a <lf> for the other. VMS knows these files as stream
> files, or files with an undefined contents. Normal VMS files are
> structured, a concept completely unknown to Unix and Windows. Cobol for
> instance needs structured files, so a Cobol compiler on Unix or Windows has
> to define its own structured files, but Unix and Windows will be completely
> unaware of that.
>
> How do you want to combine these things in one file system?
>
>>
>> There was a time when DECNET was a great thing. Back in those days, my
>> employers ran a network with over a thousand DECNET notes in several
>> areas. We were on NREN so that we could readily copy a file over to a
>> university in Spain or vice-versa. It was great. If anything went wrong,
>> I could call the networking office and they would fix it because everybody
>> there knew DECNET.
>>
>> The last two DECNET nodes shut down a couple years ago, after a decade or
>> so of being tunnelled through IP and a decade of my having to listen to
>> the networking guys about "those weird-ass servers."
>>
>> It was here, and it was good, and it was widely compatible. But it's not
>> here any more, it's not good any more, and it sure isn't compatible with
>> anything much any more. There was a time when it would have been possible
>> to extend it and keep it living, but that window closed long ago. It's
>> time to leave it dead and stop wasting time, energy, and money that could
>> be spent taking care of the living.
>>
>> It's time to let it go along with SNA and Appletalk...
>> --scott
>>
>

Michael Moroney

unread,
Sep 19, 2016, 5:29:06 PM9/19/16
to
When I said "DECnet" I meant the whole ball of wax which gets built
along with base DECnet Plus. DECnet base, FAL, all the other objects
nobody uses, and so forth. I was thinking of FAL when I mentioned
the new file system.

Chris

unread,
Sep 19, 2016, 5:42:36 PM9/19/16
to
On 09/18/16 23:01, Kerry Main wrote:

> The reality is that the future IoT world is not going to happen
> on IPV4, so start planning your coexistence strategy now.
>

IPV6 may be the future and will be required for externally facing
kit, there's no need for it at all for a small to medium sized
network behind a router or firewall. My isp may use IPV6 and I
suspect much of the path to external sites is or will be IPV6,
but it's about appropriate tech for the task in hand and avoiding
kit upgrade for no reason at all. Much of the older or even recent
ip infrastructure is still IPV4 only and if you don't need the
address space, you don't need IPV6, not the expensive kit upgrades.

In fact, with the kit here, IPV6 is either disabled or removed from
the kernel build options altogether, so never appears to clutter
up interface listings. Less is more etc...

Regards,

Chris


> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>

Dirk Munk

unread,
Sep 19, 2016, 5:51:25 PM9/19/16
to
Yes, what else is new? Those systems don't have DECnet either, so what
is the point of this remark?

For those systems you can use another utility as FAL.

Chris

unread,
Sep 19, 2016, 6:01:28 PM9/19/16
to
On 09/19/16 15:45, Stephen Hoffman wrote:
> On 2016-09-19 15:28:27 +0000, Michael Moroney said:
>
>> Of course the VMS builtin where you could access any file on your
>> DECnet with almost any software just by using the file spec
>> node::dev:[dir.sub]file.ext is really great, and is missed on TCP/IP.
>
> There's nothing to preclude RMS from being updated to connect to remote
> RMS FAL servers via TLS, using either certificates or Kerberos for
> authentication.
>
> Or — for a somewhat larger investment — via sftp, rather than requiring
> a FAL server.
>
> It'd be easier to implement if there was a central distributed
> authentication service and password store on OpenVMS, too. But I digress.
>
> On other platforms, this involves a mount and the use of SMB or NFS for
> remote access, or ssh. Remote FAL file access on OpenVMS hasn't been
> commonly used around any of the local systems I'm aware of or deal with,
> outside of file copies or maybe TYPE commands — and I can trivially
> display file contents or various other operations via ssh, if I'm not
> copying the file.
>
> But then I'd much rather see COPY /SFTP and better IPv6 integration than
> any sort of support for FAL access via TLS or sftp, too. Once the base
> OS is IP-aware and IP-integrated to at least the level of DECnet, then...
>
>

You might also have a look at the rsync utility, which has a myriad of
options and is used here and everywhere for backups and file access
across the network. No nfs mounts required either, as it uses a modified
ftp protocol for it's work. Works with IPV6 also...

Regards,

Chris

Stephen Hoffman

unread,
Sep 19, 2016, 6:05:13 PM9/19/16
to
On 2016-09-19 20:57:03 +0000, Dirk Munk said:

> No, it is not...

You can continue to explain this as often as you do and can continue to
correctly point out the many aspects of DECnet and OSI that are
technically superior to IP networking, and can certainly continue to
presume we do not understand any of that, or that we might disagree
with your statements around the various benefits of DECnet. We very
much understand all of which you are pointing to. I certainly do.
You are entirely correct about the general superiority of the DECnet
products, too.

But that doesn't matter. This due to having utterly missed the
networking market and a large chunk of the then-increasing Unix market,
and OSI in particular having turned into one of the more complex
products to configure and manage on OpenVMS, and with one of the most
utterly-missed-the-audience user interfaces ever shipped on OpenVMS.
NCL (and DEC Enterprise Management Architecture) is one of the most
exceptionally elegant and all-encompassing user interfaces around, and
one that clearly did not meet the needs of its target market. Each
revision did get better and easier to manage, too. (Integrating
products with DEC EMA was a whole lot of work, though. Which is part
of why that never really happened.)

DECnet Phase IV, IV+, V — and all of the parts of OSI that didn't end
up getting reused and effectively migrated out of the old OSI model and
over into IP networking — utterly missed the market, and these products
are now utter dead ends, insecure, problematic and increasingly limited
and system-dependent, and spending time on any of this stuff detracts
from the work necessary to make OpenVMS (more) viable in the current
and near-term future.

DECnet Phase IV, IV+ and V is not now and never will be the path
forward, nor will the networking stack arising from the old OSI model.

DEC made the same mistakes that you are repeating here, too. Thirty
years ago. DEC management and development had a firm belief in the
value of technical superiority products. Products which took far too
long to get onto the market, were far too limited in availability, cost
far too much in terms of system resources (back then), were too limited
in platform support, and — in aggregate — completely and utterly missed
the market when the resulting products became available.

Not to mention that DEC came up with a user interface and management
design that needs more than a little user interface assistance.

If VSI is to spend time and effort dragging any of the networking
products forward, and better integrating and securing the networking,
let it be IP and TLS and related support. The current TCP/IP Services
stack has problems similar to the DECnet OSI management, though with an
even more scatter-shot and inexplicably complex configuration and
management interface than DECnet OSI featured.

The inclusion of DECnet is not going to be a priority in new
application development work and application overhauls, outside of a
few specific environments.

For all its ugliness, IPv6 is the path forward. That IPv6 path might
or should or will include adding Google's BBR congestion control work
https://plus.google.com/+SamiLehtinen/posts/PCiCHhFRWTr as well as a
complete user interface overhaul, integrating TLS and SFTP, and various
other updates. OpenVMS has to deal with IPv6. DECnet? DECnet is
useful for legacy code and legacy sites, when security, authentication
and heterogeneous networking are not requirements.

Your approach and your preference here certainly mirrors DEC
development and DEC marketing, from most of thirty years ago. This
approach did not end well for DEC and DECnet, either. DEC spent more
than a little time and effort on developing and marketing and providing
and supporting OSI, and — when the implosion of OSI in the market
became something that simply couldn't be ignored, and when the various
governments walked back from their plans to require OSI support in
favor of IP support — OpenVMS and IP networking never really recovered
from this.

VSI has a opportunity to change that IP and IPv6 integration. But
nothing VSI can do will ever bring back DECnet Phase IV, IV+ or V.

Keep DECnet around for legacy sites and legacy applications, and for
folks that have no interest in encryption or authentication, and for
the foreseeable future. Beyond that? Full speed on IPv6...

Dirk Munk

unread,
Sep 19, 2016, 6:14:33 PM9/19/16
to
I have no idea what kind of DECnet functionality is used by VMS
customers, so you may be quite wrong with "all the other objects nobody
is using".

RdB two-phase commit databases for instance use DECnet.

John E. Malmberg

unread,
Sep 19, 2016, 6:17:47 PM9/19/16
to
On 9/19/2016 10:28 AM, Michael Moroney wrote:
> I am following this thread with interest because I put
> a bunch of effort getting DECnet V/DECnet Plus to build
> at VSI, what we got from HP was a bit of a mess. Since
> then I wondered, how many customers actually use DECnet V
> (or DECnet IV), and for what.
>
> Of course the VMS builtin where you could access any
> file on your DECnet with almost any software just by
> using the file spec node::dev:[dir.sub]file.ext is
> really great, and is missed on TCP/IP.

I use DECNET-IV and have used DECNET-PLUS for copying files between VMS
systems on a local network.

I also set up network objects to do privileged operations. One of those
more useful tools is one that replicates password hashes on my local LAN
to keep all the VMS passwords in sync.

I also use the TELL.COM utility along with DECNET to use one VMS system
as a CMS repository to centrally manage all the VMS systems in the
network. SYSMAN requires a password for non-clustered nodes.

I stopped using DECNET-PLUS mainly because I had problems getting it to
work on new installations on an Alpha emulator, and it is much simpler
to just use DECNET-IV for a simple LAN.

This all currently only hobbyist use.

Regards,
-John
wb8...@qsl.net_work

John E. Malmberg

unread,
Sep 19, 2016, 6:55:03 PM9/19/16
to
On 9/18/2016 3:35 AM, Dirk Munk wrote:

> First of all, which DECnet do you mean? DECnet Phase IV should have
> been abandoned years ago, DECnet Phase V has been the successor for
> years now, but many DECnet users are just to plain lazy to learn how it
> works. They took a look at the UI, concluded that is was very different
> from the NCP commands of Phase IV, and just gave up. Or are they too
> stupid to understand it?

The last time this thread came up, I asked for an on-line resource that
could be used for a hobbyist to get a simple DECNET Phase V network running.

I got no answers at all. It was like my post went into the bit-bucket.
Or maybe some posts to the news groups are not making into the info-vax
mailing list.

You can not simply translate NCP commands to NCL. Too many commonly
used NCP commands do not translate to NCL. And many times there is no
documented way to translate them.

In some cases it involves knowing some Decnet V name for something that
NCL is not smart enough to default to the only way it is set on the
system and the NCL help will not provide you with enough prompting to
find out what it wants to construct the command. And no way to know
which Phase V manual might possibly have the answer.

I can get DECNET IV running simply by running a script and passing some
simple information. I should be able to do that with the successor.

Now I have spent a bit of time with Phase V, and converted all my
network object scripts to work with it. At one time my entire VMS
network was Phase V.

And I still am having far more trouble with it for a simple setup. I
have also worked with other OSI protocols on VMS. I have seen the fall
out of many OSI protocol changes as they evolved.

I have had so much trouble with Phase V debugging that I decided it was
not worth the hassle and have been removing it as I update my home
systems, since I never see the need to tunnel it over TCP/IP.

And I forget exactly what issue I was trying to do as it was well over
16 years ago, but one of the things I wanted to script with NCL was only
documented to be done through a DECWindows Utility. I could find no
documentation anywhere on how to use NCL to extract the same
information. The same operation was trivial to do with Decnet IV.

As far as a UI or documentation, Phase V was a major jump backwards.

I do not see Phase V replacing TCP/IP for communication with non-VMS
hosts. Without that, IMHO, Phase V is pretty much in the same boat as
Phase IV. I think I can still get Phase IV clients for non-VMS, or at
least get the source for them.

Regards,
-John
wb8tyw@qsl_network

Stephen Hoffman

unread,
Sep 19, 2016, 7:15:44 PM9/19/16
to
On 2016-09-19 22:01:26 +0000, Chris said:

> You might also have a look at the rsync utility....

Ayup; I'm aware of rsync. Last I checked, it was a little messy to
port that to OpenVMS too, but I digress.

There are any number of other approaches available.

Among others, git or hg, or any of the distributed packages that
maintain and update installed software and associated dependencies —
OpenVMS is a little lacking in these areas, too.

Dirk Munk

unread,
Sep 19, 2016, 7:21:17 PM9/19/16
to
Yes I know. The ICT world wants quick and dirty. One hype after the
other. There are three times more computer languages then there are
human languages.

One day something terrible will happen that will make us realise that
ICT is not kindergarten stuff, but has to be taken seriously.

>
> Not to mention that DEC came up with a user interface and management
> design that needs more than a little user interface assistance.
>
> If VSI is to spend time and effort dragging any of the networking
> products forward, and better integrating and securing the networking,
> let it be IP and TLS and related support. The current TCP/IP Services
> stack has problems similar to the DECnet OSI management, though with an
> even more scatter-shot and inexplicably complex configuration and
> management interface than DECnet OSI featured.

We all know that the present IP stack is junk, and we're waiting for the
new one. I have no idea why you think the configuration is so difficult,
I never had any problems. But there's always room for improvement.

>
> The inclusion of DECnet is not going to be a priority in new application
> development work and application overhauls, outside of a few specific
> environments.
>

DECnet is a mature product, except for using IPv6 as transport and
including the new file system, there's nothing that needs updating or
what ever.

> For all its ugliness, IPv6 is the path forward. That IPv6 path might
> or should or will include adding Google's BBR congestion control work
> https://plus.google.com/+SamiLehtinen/posts/PCiCHhFRWTr as well as a
> complete user interface overhaul, integrating TLS and SFTP, and various
> other updates. OpenVMS has to deal with IPv6.

Tell me something new, I've been saying that for over 10 years now.

> DECnet? DECnet is
> useful for legacy code and legacy sites, when security, authentication
> and heterogeneous networking are not requirements.

DECnet is for VMS <> VMS communication, nothing else. I have always said
that.

>
> Your approach and your preference here certainly mirrors DEC development
> and DEC marketing, from most of thirty years ago. This approach did
> not end well for DEC and DECnet, either. DEC spent more than a little
> time and effort on developing and marketing and providing and supporting
> OSI, and — when the implosion of OSI in the market became something that
> simply couldn't be ignored, and when the various governments walked back
> from their plans to require OSI support in favor of IP support — OpenVMS
> and IP networking never really recovered from this.
>
> VSI has a opportunity to change that IP and IPv6 integration.

Yes, and they have to build the best and most elaborate IP stacks possible.

> But
> nothing VSI can do will ever bring back DECnet Phase IV, IV+ or V.
>
> Keep DECnet around for legacy sites and legacy applications, and for
> folks that have no interest in encryption or authentication, and for the
> foreseeable future. Beyond that?

I *WANT* encryption on DECnet, but not with bolted on products like TLS
etc. Many years ago I was at a meeting in the Digital building in
Utrecht, you will remember it. There was a meeting about new
enhancements, it as the first time I heard about IPsec. My first thought
was "finally a piece of real architecture in IP". Putting encryption and
security on the network level where it belongs. And these days it can
even be handled in the NIC, and that is the best place for it as you
will well know.

Full speed on IPv6...

I agree, BUT:
- IPv6 isn't even an official internet standard yet !!!
- The routing standards are not properly defined and implemented,
certainly with regard to packet fragmentation and reporting over ICMP.
- The fucking idiots at the IETF completely forgot how to properly
define the functionality of CE routers (Global addresses, ULA addresses,
DNS), and how and where to store the DNS entries of the global IPv6
addresses of the device in the home LANs. Consumers will want to connect
to devices on their home LAN from the internet, that is standard these
days. I saw that problem years ago, and wondered how it would be solved.
They have hardly started thinking about it, let alone defining the
functionality of a CE router in this respect. Because of all the
security aspects involved, it will be quite a job building a proper CE
router instead of the insecure junk we can buy these days.
- I'm sure there are many other issues as well, and that after more then
20 years of development. Wow .....

That is what I hate about IP. Thousands and thousands of RFC's, but only
half baked solutions. No proper design, no proper concepts. One hobby
project after the other, 20 half baked solutions for the same problem.

I have been using IPv6 for some 7 or 8 years now, and trying to push my
ISP to get it up and running. They have been working on it for at least
six years, and still they have problems. Not in the least with those
stupid cable routers (incl. Cisco of course).


Dirk Munk

unread,
Sep 19, 2016, 7:32:04 PM9/19/16
to
That is the usual approach for these things, never do something new if
you can avoid it.

Or you can use the Facebook approach. They were fed up with dual stacks,
brain dead programmers who only built in the IPv4 stack in their
applications, and so on. So they went for IPv6 only on all systems,
except for the ones facing the internet of course.

Instead of fleeing backwards, they fled forward. A better approach in my
view, because in the end you will have to convert anyway.

Dirk Munk

unread,
Sep 19, 2016, 7:49:24 PM9/19/16
to
John E. Malmberg wrote:
> On 9/18/2016 3:35 AM, Dirk Munk wrote:
>
>> First of all, which DECnet do you mean? DECnet Phase IV should have
>> been abandoned years ago, DECnet Phase V has been the successor for
>> years now, but many DECnet users are just to plain lazy to learn how it
>> works. They took a look at the UI, concluded that is was very different
>> from the NCP commands of Phase IV, and just gave up. Or are they too
>> stupid to understand it?
>
> The last time this thread came up, I asked for an on-line resource that
> could be used for a hobbyist to get a simple DECNET Phase V network
> running.

There is a configuration manual, it's really just a simple commandfile
you have to run. It takes about 5 minutes.

>
> I got no answers at all. It was like my post went into the bit-bucket.
> Or maybe some posts to the news groups are not making into the info-vax
> mailing list.
>
> You can not simply translate NCP commands to NCL. Too many commonly
> used NCP commands do not translate to NCL. And many times there is no
> documented way to translate them.

True, what you need is a picture with all the OSI layers and their NCL
objects. That is quite essential, and certainly when you start with NCL.
The you can work your way up from the NIC to the upper layers.

>
> In some cases it involves knowing some Decnet V name for something that
> NCL is not smart enough to default to the only way it is set on the
> system and the NCL help will not provide you with enough prompting to
> find out what it wants to construct the command. And no way to know
> which Phase V manual might possibly have the answer.
>
> I can get DECNET IV running simply by running a script and passing some
> simple information. I should be able to do that with the successor.

That can be done!

>
> Now I have spent a bit of time with Phase V, and converted all my
> network object scripts to work with it. At one time my entire VMS
> network was Phase V.
>
> And I still am having far more trouble with it for a simple setup. I
> have also worked with other OSI protocols on VMS. I have seen the fall
> out of many OSI protocol changes as they evolved.
>
> I have had so much trouble with Phase V debugging that I decided it was
> not worth the hassle and have been removing it as I update my home
> systems, since I never see the need to tunnel it over TCP/IP.

It is *NOT* a tunnel. You replace DECnet Phase IV or OSI names by IP DNS
names. Unlike MultiNet that is using a tunnel.

>
> And I forget exactly what issue I was trying to do as it was well over
> 16 years ago, but one of the things I wanted to script with NCL was only
> documented to be done through a DECWindows Utility. I could find no
> documentation anywhere on how to use NCL to extract the same
> information. The same operation was trivial to do with Decnet IV.
>
> As far as a UI or documentation, Phase V was a major jump backwards.
>
> I do not see Phase V replacing TCP/IP for communication with non-VMS
> hosts.

Of course not, no one is claiming that. Once again, DECnet is for VMS <>
VMS communication. with DECnet over IP you can do it ona IP-only
network. That's it.

David Froble

unread,
Sep 19, 2016, 8:56:56 PM9/19/16
to
It's not the things we see that are a problem. We can anticipate and fix such.
It's the things we don't see until they bite us on the ass, hard, that are a
problem.

BlackCat

unread,
Sep 20, 2016, 4:07:45 AM9/20/16
to
On 19.09.2016 17:28, Michael Moroney wrote:
> I am following this thread with interest because I put
> a bunch of effort getting DECnet V/DECnet Plus to build
> at VSI, what we got from HP was a bit of a mess. Since
> then I wondered, how many customers actually use DECnet V
> (or DECnet IV), and for what.

Michael,
if you are taking requests?

One of the most basic things that should have been done yonks(= a long time) ago was 'oping', yes ping at the Network Layer (ISO8473).
ISO8473 and ISO9542 are the protocols that a DECnet Phase V End System would use when communicating with other DECnet PhaseV systems.
This ping Echo function 'oping' was already present in the first versions of DECnet/OSI for OSF/1 (1993?) .
Basically as in TCP/IP, it is a Echo Request/Response function implemented at the network layer.
Now DECnet+ and its OpenVMS predecessors only ever implemented the response function, ie. you can ping an OpenVMS DECnet+ from a
system that had implemented the Client function such as a Tru64 system with DECnet+, but you can never initate an 'oping' on an
OpenVMS DECnet+ system. :-((
It was always a mystery to me of how many variances existed between the implentations of DECnet+ on Tru64 and DECnet+ on OpenVMS.?*!
References: ISO/IEC 8473-1 1998(E) RFC1575 (1994)
Hopefully HP will let you have access to the Tru64 'oping' Client code.


Chris

unread,
Sep 20, 2016, 6:00:26 AM9/20/16
to
Which is why, once again, VMS needs a software abstraction layer that
presents a unix / Linux interface. Do that once, do it right and most
if not all of the useful os code is available with just a recompile.

A short step from that to a full package oriented environment for VMS.
Sheer luxury :-)...

Regards,

Chris

Johnny Billquist

unread,
Sep 20, 2016, 6:36:16 AM9/20/16
to
On 2016-09-19 20:51, Dirk Munk wrote:
> Some mentioned that Multinet has it too. That is incorrect, Multinet has
> to translate DECnet phase IV names & addresses into IP DNS names. You
> have to set up such a translation table.

That is bollocks.
There are no translation table. You have DECnet circuits, who just use
IP as the transport mechanism, instead of DDCMP, or ethernet, or
whatever other transport you can think of.
At VMS, this is totally invisible. You set up the circuit, and then in
DECnet, you just have a connection between two phase IV nodes, just like
if you had run a cable between them. There is nothing more to it.

> I have no idea what happens if the remote node has a different DECnet
> address the you have in your translation table.

I have no idea what you are talking about.

> Suppose you set up a translation entry for DECnet node ABC with DECnet
> address 5.1 and DNS name remote.away.com.
>
> However remote.away.com has DECnet address 10.1, will the communication
> fail? I expect it will.
>
> So Multinet uses tunneling, whereas DECnet Phase V does not.

You are just talking nonsense. You do not tell, at the local machine,
what the DECnet address of the remote machine is. No more than you do
that with any kind of circuit.

Stop spreading disinformation when you obviously don't know anything.

Johnny

Johnny Billquist

unread,
Sep 20, 2016, 6:54:35 AM9/20/16
to
On 2016-09-19 20:55, David Froble wrote:
> Bob Koehler wrote:
>> In article <nrlmbk$if0$1...@dont-email.me>, David Froble
>> <da...@tsoft-inc.com> writes:
>>> In general I agree with what you've written. I consider DECnet as a
>>> part of VMS, and if one really doesn't want VMS, then just go and use
>>> something else.
>>
>> Having used DECnet on VMS, MVS, RSX, TOPS-20, MS-DOS, Ultrix, AIX, and
>> Linux, I find your concept much too narrow for reality.
>>
>
> You're always so easy to get along with Bob ....
>
> :-)
>
> Yes, there have been implementations of the DECnet transport part on
> multiple OSs, both DEC and others. But, as far as I know, there has not
> been the full range of DECnet tools available on those environments. As
> an example, does FAL exist on all those implementations?

Without making a thorough check - yes I believe so. Definitely true for
RSX, Windows, Linux, TOPS-20 and Ultrix. Never having played with MVS or
AIX, so I can only guess on those, but it wouldn't make sense if it
wasn't there.
(I think I can show you RSX, Windows, TOPS-20 and Ultrix straight away
if you want to see it...)

> For me, it's the utilities, tools, and such that I feel make DECnet
> worth keeping around. Much more so than the communications stuff. Of
> course, those utilities, tools, and such do use the communications stuff.

Agree.

Johnny

Johnny Billquist

unread,
Sep 20, 2016, 7:03:15 AM9/20/16
to
On 2016-09-19 21:33, Dirk Munk wrote:
> David Froble wrote:
>> Bob Koehler wrote:
>>> In article <nrlmbk$if0$1...@dont-email.me>, David Froble
>>> <da...@tsoft-inc.com> writes:
>>>> In general I agree with what you've written. I consider DECnet as a
>>>> part of VMS, and if one really doesn't want VMS, then just go and use
>>>> something else.
>>>
>>> Having used DECnet on VMS, MVS, RSX, TOPS-20, MS-DOS, Ultrix, AIX,
>>> and
>>> Linux, I find your concept much too narrow for reality.
>>>
>>
>> You're always so easy to get along with Bob ....
>>
>> :-)
>>
>> Yes, there have been implementations of the DECnet transport part on
>> multiple OSs, both DEC and others. But, as far as I know, there has not
>> been the full range of DECnet tools available on those environments. As
>> an example, does FAL exist on all those implementations?
>
> Bob didn't mention MAC OS. MACs also had FAL, and it was a beautiful
> implementation. If you copied a file from MAC to MAC (using your VMS
> system for the command), the complete file would be transferred,
> resource fork + data fork. If you copied a file to your VMS system, only
> the data fork would be copied, the resource fork was useless for VMS.
>
> Indexed files on RSX and VMS are different. If you copy an indexed file
> between RSX and VMS, you get a proper indexed file on the other side (if
> it was within the limits of that OS of course).

Indexed files on RSX and VMS are not different. VMS is just a superset
of RSX. RSX only have up to RMS Prologue version 2.

If you copy a file, no translation is done. You get it block by block.
If it is prologue version 3, RSX RMS will just tell you that it's an
unsupported prologue version when you try to access it.

You can also request that NFT translates files during transfer. But that
can't be done for indexed files. But it can be done between stream and
record format files for example.

> FAL knows the characteristics of the OS, and will 'translate' files if
> necessary.

Technically, it's not FAL that do the translation, but the client. In
RSX that part is called NFT. In VMS I'm not sure it even have a name...
But FAL itself tries to do things simple. It's on the client side any
magic will be done, if needed, or requested.

For example, if you read a file from a TOPS-20 (or RSTS/E, or Unix)
system, the file will normally be a stream file. By default, that will
be translated into a sequential record file since that is how text files
are represented natively in VMS or RSX. But FAL will serve the stream as
such.

> No such functionality exists with IP.

That is nonsense. If we talk file transfer, then we talk FTP. FTP deals
with text files being stored in different formats on different systems,
and do the translation just fine as well.

Johnny

Johnny Billquist

unread,
Sep 20, 2016, 7:04:56 AM9/20/16
to
FAL is a good example of when DEC got it right.
CTERM is a good example of when DEC got it wrong.
There are good and bad parts in DECnet... :-)

Johnny

Johnny Billquist

unread,
Sep 20, 2016, 8:51:36 AM9/20/16
to
On 2016-09-19 20:53, hb wrote:
> On 09/19/2016 03:48 PM, Scott Dorsey wrote:
>> The way Multinet did it (making the file version part of the filename)
>> works pretty well.
>
> Which is how a filename is stored in the ods-2/5 file header, anyway.
> Only directories contain a single file name and (separate) versions.

Not sure how relevant that is. In RSX each directory entry actually
store the file name and version. If you have two versions, each have
their own full directory entry.
More to the point is that all file name operations infer a version if
none were given in the original name. So that you can say "FOO.BAR" and
a file version is used, meaning the full file name contain parts that
you did not type. But you can of course also explicitly give the version
number you are interested in.
Which is quite different from how some other operating systems might
look at things.

Johnny

Chris

unread,
Sep 20, 2016, 8:55:00 AM9/20/16
to
On 09/19/16 23:32, Dirk Munk wrote:

> That is the usual approach for these things, never do something new if
> you can avoid it.
>
> Or you can use the Facebook approach. They were fed up with dual stacks,
> brain dead programmers who only built in the IPv4 stack in their
> applications, and so on. So they went for IPv6 only on all systems,
> except for the ones facing the internet of course.
>
> Instead of fleeing backwards, they fled forward. A better approach in my
> view, because in the end you will have to convert anyway.
>

Agreed, it makes sense for an organisation with that many nodes and
volume of traffic. When the change does come, the internal IPV6
should be well proven, with all the bugs and systems management
familiarity well understood. It's not a no cost change for
system admin though.

Still see no point for smaller subnets, where a IPV4 to IPV6
translation is more cost effectively handled globally...

Regards,

Chris

John E. Malmberg

unread,
Sep 20, 2016, 9:19:52 AM9/20/16
to
On 9/19/2016 6:49 PM, Dirk Munk wrote:
> John E. Malmberg wrote:
>> On 9/18/2016 3:35 AM, Dirk Munk wrote:
>>
>>> First of all, which DECnet do you mean? DECnet Phase IV should have
>>> been abandoned years ago, DECnet Phase V has been the successor for
>>> years now, but many DECnet users are just to plain lazy to learn how it
>>> works. They took a look at the UI, concluded that is was very different
>>> from the NCP commands of Phase IV, and just gave up. Or are they too
>>> stupid to understand it?
>>
>> The last time this thread came up, I asked for an on-line resource that
>> could be used for a hobbyist to get a simple DECNET Phase V network
>> running.
>
> There is a configuration manual, it's really just a simple commandfile
> you have to run. It takes about 5 minutes.
>
>>
>> I got no answers at all. It was like my post went into the bit-bucket.
>> Or maybe some posts to the news groups are not making into the info-vax
>> mailing list.
>>
>> You can not simply translate NCP commands to NCL. Too many commonly
>> used NCP commands do not translate to NCL. And many times there is no
>> documented way to translate them.
>
> True, what you need is a picture with all the OSI layers and their NCL
> objects. That is quite essential, and certainly when you start with NCL.
> The you can work your way up from the NIC to the upper layers.

With the Phase V documentation, I can find out only about 80% of what a
system manager needs to know to automate configuration and management to
the same level as I can with Phase IV.

I can not find the rest in the documentation, and I have spent a lot of
time on that.

>> In some cases it involves knowing some Decnet V name for something that
>> NCL is not smart enough to default to the only way it is set on the
>> system and the NCL help will not provide you with enough prompting to
>> find out what it wants to construct the command. And no way to know
>> which Phase V manual might possibly have the answer.
>>
>> I can get DECNET IV running simply by running a script and passing some
>> simple information. I should be able to do that with the successor.
>
> That can be done!
>
>>
>> Now I have spent a bit of time with Phase V, and converted all my
>> network object scripts to work with it. At one time my entire VMS
>> network was Phase V.
>>
>> And I still am having far more trouble with it for a simple setup. I
>> have also worked with other OSI protocols on VMS. I have seen the fall
>> out of many OSI protocol changes as they evolved.
>>
>> I have had so much trouble with Phase V debugging that I decided it was
>> not worth the hassle and have been removing it as I update my home
>> systems, since I never see the need to tunnel it over TCP/IP.
>
> It is *NOT* a tunnel. You replace DECnet Phase IV or OSI names by IP DNS
> names. Unlike MultiNet that is using a tunnel.

Sorry for confusion on the terms.

For most U.S. residential home broadband ISPs, direct incoming access to
our systems are prohibited by the ISP Terms of Service.

So the only way that I would need DECNET V over TCP/IP is if I had a VPN
type tunnel set up and a cooperating remote site.

>> And I forget exactly what issue I was trying to do as it was well over
>> 16 years ago, but one of the things I wanted to script with NCL was only
>> documented to be done through a DECWindows Utility. I could find no
>> documentation anywhere on how to use NCL to extract the same
>> information. The same operation was trivial to do with Decnet IV.
>>
>> As far as a UI or documentation, Phase V was a major jump backwards.
>>
>> I do not see Phase V replacing TCP/IP for communication with non-VMS
>> hosts.
>
> Of course not, no one is claiming that. Once again, DECnet is for VMS <>
> VMS communication. with DECnet over IP you can do it ona IP-only
> network. That's it.

So what is the reason for me to learn Decnet V and deploy it locally
instead of Decnet IV?

Is there a strong demand to hire people that can configure and
troubleshoot DecNet V? I am not seeing that on past job searches.

Instead I am seeing a requirement of having a DecNet V expert as just
one more reason for upper management to be considering moving off of
VMS, even if they have not told the people maintaining the VMS systems.

My most recent U.S. job search with Glassdoor salary lookups showed that
most VMS jobs are paying about 50 to 80 % of what is currently being
offered for people with equivalent Linux skills.

Being able to setup and manage Jenkins, Chef/Salt-stack/cobbler, on
Linux etc all pays a lot more, and even though these are pretty easy to
learn on-line and test on home equipment, those jobs both pay more and
are easier to find.

My skills learned on updating GNV and Perl on VMS are currently what is
keeping me employed at non-VMS jobs.

Regards,
-John
wb8tyw@qsl_network

John E. Malmberg

unread,
Sep 20, 2016, 9:25:34 AM9/20/16
to
On 9/20/2016 5:00 AM, Chris wrote:
> On 09/19/16 23:15, Stephen Hoffman wrote:
>> On 2016-09-19 22:01:26 +0000, Chris said:
>>
>>> You might also have a look at the rsync utility....
>>
>> Ayup; I'm aware of rsync. Last I checked, it was a little messy to port
>> that to OpenVMS too, but I digress.
>>
>> There are any number of other approaches available.
>>
>> Among others, git or hg, or any of the distributed packages that
>> maintain and update installed software and associated dependencies —
>> OpenVMS is a little lacking in these areas, too.
>>
> Which is why, once again, VMS needs a software abstraction layer that
> presents a unix / Linux interface. Do that once, do it right and most
> if not all of the useful os code is available with just a recompile.

rsync as last I looked at the source needs one of:

A. A working fork for straight port.

B. A C Compiler that support a thread local storage qualifier, which
would allow a pass with an editor to do most of the work to convert it
to threads.

C. A major bit of work to identify which static variables are used for
sending, and which for receiving and then put them in a thread context
variable.


I got pretty far with step C before I needed to move on to other things.

I have a proof of concept port which in spite of both threads sharing
static variables with out coordination actually works about 95% of the time.

Regards,
-John
wb8...@qsl.net_work


Dirk Munk

unread,
Sep 20, 2016, 10:20:33 AM9/20/16
to
How local is local? On one switched network segment? Suppose your
company has two VMS systems using DECnet, but these systems are not on
the same network segment. They are/must be separated by routers for
whatever reason, then with DECnet over IP your network people will be
very happy.

David Froble

unread,
Sep 20, 2016, 10:41:50 AM9/20/16
to
Now, that is some real wishful thinking.

As Michael has mentioned, above, the VMS stuff received from HP was "a bit of a
mess". What do you think the T64 stuff, something long ago discontinued, will
be like, if it even still exists?

I do agree, PING is rather useful.

Chris

unread,
Sep 20, 2016, 12:11:14 PM9/20/16
to
On 09/20/16 13:26, John E. Malmberg wrote:

> rsync as last I looked at the source needs one of:
>
> A. A working fork for straight port.

That sounds like the hard bit, the rest being not too difficult
perhaps. If VMS has TCP/IP, one assumes that it has a socket
library already ?

>
> B. A C Compiler that support a thread local storage qualifier, which
> would allow a pass with an editor to do most of the work to convert it
> to threads.
>

The first question being, is there a fairly up to date gcc and
associated tools for VMS ?.

>
> C. A major bit of work to identify which static variables are used for
> sending, and which for receiving and then put them in a thread context
> variable.
>
>
> I got pretty far with step C before I needed to move on to other things.
>
> I have a proof of concept port which in spite of both threads sharing
> static variables with out coordination actually works about 95% of the
> time.
>

You must have put a lot of work into that and probably noone knew about
it :-). If VSI haven't the time right now to do this, why not an open
source collaboration group for VMS, organised and run by the users,
perhaps with input and help from VSI ?. I haven't programmed anything on
VMS since the mid 1990's, but there must be enough people around with
the skills and time to contribute to such a group. As I said, the first
project needs to be the abstraction layer, never mind how incomplete it
is to start with, but proof of concept and a way forward. Would be much
better to put effort into that, rather than ticking off ports one
by one.

Teamwork is the way forward, but it needs someone to build and manage
the organisational structure first...

> Regards,
> -John
> wb8...@qsl.net_work
>
>

Jan-Erik Soderholm

unread,
Sep 20, 2016, 12:27:46 PM9/20/16
to
>As I said, the first project needs to be the abstraction layer,...

Isn't that what GNV is (ment to be)?
It is loading more messages.
0 new messages