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

[Paul Sture]

On 2016-11-25, johnwallace4 at yahoo.co.uk <johnwallace4 at yahoo.co.uk> wrote:
> 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.

And here's an example of the problem faced by a relatively small company
who went the NETBEUI route, with that protocol no longer being available
with Windows 7:

<http://www.theregister.co.uk/2014/04/02/the_mathematics_of_trust/>

--- start quote ---
This machine shop is family owned and operated. There are three owners
with maybe 15 people working there during peak season. They turn over
about $1m a year. Much of their equipment was bought in the late 1990s
and is perfectly serviceable today. Equipment like CnC lathes that can
only accept jobs from networked PCs running NetBEUI.

The companies that manufactured the equipment no longer exist. There is
nobody to rewrite the code in that lathe. The machinists running the
shop certainly don't know how to do it, and a forklift upgrade of all
their gear would cost $7m.
--- end quote ---

Methinks that the figures could be substantially larger for customers
who went the DEC/Omni and DEC/OSAP route.

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

Indeed.

--
tar: Cowardly refusing to create an empty archive