[Info-vax] DECnet Phase IV and VMS code comments

[johnwallace4 at yahoo.co.uk]

On Friday, 25 November 2016 14:12:13 UTC, Johnny Billquist  wrote:
> On 2016-11-25 10:21, Dirk Munk wrote:
> > My question is, why are you interested in this very old protocol? DECnet
> > Phase V was designed for let's say an OSI Internet, so I'm sure it's
> > beter designed in this respect. Before some one else tries to point it
> > out, yes I know it doesn't have encryption when used with the OSI
> > transport layers. It could have been done, and it still can be done
> > using TLS, that has been designed for the OSI transport layer. I'm sure
> > VSI will look into this :-)
> 
> We've been over this before. I very much disagree, and I seriously doubt 
> VSI will put any work into Phase V, and I believe the comments from 
> others here pretty much agreed with that.
> 
> You seem to be just about the only person who haven't got it that OSI is 
> dead, and so is Phase V. (And it's an ugly corpse, and trying to revive 
> it would not make it any prettier...)
> 
> 	Johnny

Your opinion on whether Phase V is important or not is less
important than the $$$ from the customers who may be
interested in the continued support of OSI stuff.

DEC/Omni and DEC/OSAP, back in the day, both relied on
Phase V/OSI support. They are used for talking between
VMS boxes and the plant floor automation devices that
control multi-million-dollar multi-decade-lifetime
automation systems. Not some $5 here today gone
tomorrow PC peripheral.

Have a look at the roadmap. Do you see OMNI and OSAP
still on there? I did. Am I 100% confident this means
there is no alternative to OSI on VMS for talking to
these devices? Not confident at all. But it might be
interesting to know, so that well-informed comments
can be made. (Or at worst, to update the information
provided last time this topic came up).

Money talks, as DaveF, who doesn't get out much,
already pointed out (and indeed as you eventually
acknowledged yourself).

Opinions are cheap, usable standards-based multi-vendor
connectivity code (and usable support) can be more
expensive.

It might be nice if there was a reasonably recent SPD
for OMNI/OSAP readily accessible.