Discussion:
api for ncp
(too old to reply)
calliet gérard
2021-07-29 15:27:33 UTC
Permalink
Hello,

I'm not an archeologist. Somewhere in the word they use VAX/VMS 5.5-H2,
and for again a long time. I'll be retired when they'll stop the servers.

So I'm training new guys who will do the job.

I try to help them take the job as fun as possible.

We learn this year decnet.

I'm wondering if we could play with ncp from program, using some api.

Did something like that exist?

Thanks,

Gérard Calliet
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Stephen Hoffman
2021-07-29 16:44:31 UTC
Permalink
Post by calliet gérard
I'm wondering if we could play with ncp from program, using some api.
SPAWN it, of course. Ugly, but workable.

The DECnet Network Information and Control Exchange (NICE) Protocol
stuff was documented (in the in the DECnet network architecture
manuals). I'll leave you to find the DECnet Phase IV architecture
manuals, but they're around at Bitsavers, if not elsewhere. The network
management layer (NML) network function block (NFB) $qio API was
(mostly) not documented (in the then-VAX/VMS manuals). There were a few
specific NML NFB functions documented for DECnet task-to-task object
declarations and such. But the NML NFB API could do rather more than
what was documented.

1980s-era C examples of some of what wasn't documented within DECnet,
and what was underneath Network Control Program (NCP):
https://www.digiater.nl/openvms/freeware/v50/srh_examples/nfb.c
https://www.digiater.nl/openvms/freeware/v50/srh_examples/nice.c
https://www.digiater.nl/openvms/freeware/v50/srh_examples/nfb2.b32

There's a directory of undocumented stuff that somehow dropped off the
Freeware (probably my error), but this old stuff can still be found on
the 'net.
In this old DECUS_UNDOC_CLINIC stuff, there's a related logical name
useful for debugging the above NML-related activities, as well as
debugging DECnet File Access Listener (FAL) and RTPAD activities:
https://web.archive.org/web/20000816191216/http://www.openvms.compaq.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/MISC_LOGICALS.TXT


There's a fake debugger and a "nodebug" tool and some other old toy
examples that were using undocumented or semi-documented features, too:
https://web.archive.org/web/20000816191149/http://www.openvms.compaq.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/FAKE_DEBUG.C

https://web.archive.org/web/20000816191220/http://www.openvms.compaq.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/NDBG_NODEBUG.MAR


Further entrenching your code in the past and into NCP and into DECnet
generally is not the path forward, though.

And the use of semi- or undocumented DECnet features and OpenVMS arcana
is most definitely not the path forward.
--
Pure Personal Opinion | HoffmanLabs LLC
calliet gérard
2021-07-30 14:09:46 UTC
Permalink
Post by Stephen Hoffman
Post by calliet gérard
I'm wondering if we could play with ncp from program, using some api.
SPAWN it, of course. Ugly, but workable.
The DECnet Network Information and Control Exchange (NICE) Protocol
stuff was documented (in the in the DECnet network architecture
manuals).  I'll leave you to find the DECnet Phase IV architecture
manuals, but they're around at Bitsavers, if not elsewhere. The network
management layer (NML) network function block (NFB) $qio API was
(mostly) not documented (in the then-VAX/VMS manuals). There were a few
specific NML NFB functions documented for DECnet task-to-task object
declarations and such. But the NML NFB API could do rather more than
what was documented.
1980s-era C examples of some of what wasn't documented within DECnet,
https://www.digiater.nl/openvms/freeware/v50/srh_examples/nfb.c
https://www.digiater.nl/openvms/freeware/v50/srh_examples/nice.c
https://www.digiater.nl/openvms/freeware/v50/srh_examples/nfb2.b32
There's a directory of undocumented stuff that somehow dropped off the
Freeware (probably my error), but this old stuff can still be found on
the 'net.
In this old DECUS_UNDOC_CLINIC stuff, there's a related logical name
useful for debugging the above NML-related activities, as well as
https://web.archive.org/web/20000816191216/http://www.openvms.compaq.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/MISC_LOGICALS.TXT
There's a fake debugger and a "nodebug" tool and some other old toy
https://web.archive.org/web/20000816191149/http://www.openvms.compaq.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/FAKE_DEBUG.C
https://web.archive.org/web/20000816191220/http://www.openvms.compaq.com/freeware/srh_examples/DECUS_UNDOC_CLINIC/NDBG_NODEBUG.MAR
Further entrenching your code in the past and into NCP and into DECnet
generally is not the path forward, though.
And the use of semi- or undocumented DECnet features and OpenVMS arcana
is most definitely not the path forward.
Thanks a lot.

I don't need a path forward in the situation, just a path backward :) -
They need training for a totally freezed platform, for which they will
make support for more than again 10 years.
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Stephen Hoffman
2021-07-30 15:27:44 UTC
Permalink
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :) -
They need training for a totally freezed platform, for which they will
make support for more than again 10 years.
I can't count the number of times I've heard variations of that same
"we can't" story told and re-told.

With staff dutifully and earnestly repeating what management has told them.

Then upper management decides the old needs gone.

And the same staff immediately commenced repeating the new management position.

I've met various cases where the porting or remedial work was triggered
by the departure of specific long-timers and/or specific senior folks,
too.

But yes, you're stuck with an installation of {whatever} with a whole
lot of {whatever} and clearly any resolution of this is blocked by
{whatever}.

Right up until upper management nopes some or all, switches directions,
and off we go on some whole new IT adventure.

Put differently, I've met claims similar to what this installation
professes, and the port or the remediation or replacement work started
the next day.

[eg: work on Alpha is ending, we're porting to Itanium. Writing this on
the day after the last available shipments of Itanium processors from
Intel, too.]

It's really quite striking to watch the speed of these IT transitions,
particularly after how slowly and painfully everything IT was working
prior.

If this particular case follows the general pattern I've met elsewhere,
I'd expect to see incremental ports to Linux and Ada, absent some
moderate-sized entity adding support for semi-recent Ada on OpenVMS
x86-64 and this addition alongside a sudden willingness to upgrade from
OpenVMS VAX to OpenVMS x86-64. This as the patience with the older
stuff ages out.
--
Pure Personal Opinion | HoffmanLabs LLC
calliet gérard
2021-07-30 15:59:29 UTC
Permalink
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :)
- They need training for a totally freezed platform, for which they
will make support for more than again 10 years.
I can't count the number of times I've heard variations of that same "we
can't" story told and re-told.
With staff dutifully and earnestly repeating what management has told them.
Then upper management decides the old needs gone.
And the same staff immediately commenced repeating the new management position.
I've met various cases where the porting or remedial work was triggered
by the departure of specific long-timers and/or specific senior folks, too.
But yes, you're stuck with an installation of {whatever} with a whole
lot of {whatever} and clearly any resolution of this is blocked by
{whatever}.
Right up until upper management nopes some or all, switches directions,
and off we go on some whole new IT adventure.
Put differently, I've met claims similar to what this installation
professes, and the port or the remediation or replacement work started
the next day.
[eg: work on Alpha is ending, we're porting to Itanium. Writing this on
the day after the last available shipments of Itanium processors from
Intel, too.]
It's really quite striking to watch the speed of these IT transitions,
particularly after how slowly and painfully everything IT was working
prior.
If this particular case follows the general pattern I've met elsewhere,
I'd expect to see incremental ports to Linux and Ada, absent some
moderate-sized entity adding support for semi-recent Ada on OpenVMS
x86-64 and this addition alongside a sudden willingness to upgrade from
OpenVMS VAX to OpenVMS x86-64. This as the patience with the older stuff
ages out.
You jump too fast on your (right) evaluations. Here it's a
from-the-begining stuck, validated-one, don't move even something in the
hardware. Think about a nuclear submarine - a pure example -, or a
spatial station. Or the coliseum in Roma : the gardians cannot change a
stone. Not at all a general case.
I hope you like museum, however. There are no new versions of "La Joconde".
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Dave Froble
2021-07-30 17:03:41 UTC
Permalink
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :)
- They need training for a totally freezed platform, for which they
will make support for more than again 10 years.
I can't count the number of times I've heard variations of that same "we
can't" story told and re-told.
Of course, "we can" is always true. Perhaps expensive. But perhaps not
the right decision.
With staff dutifully and earnestly repeating what management has told them.
What else can they do?
Then upper management decides the old needs gone.
Usually those making such decisions are not capable of making good
decisions.

You mean like the port of VMS to the itanic?
And the same staff immediately commenced repeating the new management position.
I seem to recall at least one VMS engineer who looked forward to the
port ...
I've met various cases where the porting or remedial work was triggered
by the departure of specific long-timers and/or specific senior folks, too.
Yeah! Get rid of the old fossils so we can do what we want to do.
Which may not bear much resemblance to what the company needs.
But yes, you're stuck with an installation of {whatever} with a whole
lot of {whatever} and clearly any resolution of this is blocked by
{whatever}.
Too many "whatevers" for that to say much.
Right up until upper management nopes some or all, switches directions,
and off we go on some whole new IT adventure.
Like the port of VMS to the itanic?
Put differently, I've met claims similar to what this installation
professes, and the port or the remediation or replacement work started
the next day.
It has to do with desire. Desire to keep costs down. Desire to "do
something".
[eg: work on Alpha is ending, we're porting to Itanium. Writing this on
the day after the last available shipments of Itanium processors from
Intel, too.]
It's really quite striking to watch the speed of these IT transitions,
particularly after how slowly and painfully everything IT was working
prior.
If this particular case follows the general pattern I've met elsewhere,
I'd expect to see incremental ports to Linux and Ada, absent some
moderate-sized entity adding support for semi-recent Ada on OpenVMS
x86-64 and this addition alongside a sudden willingness to upgrade from
OpenVMS VAX to OpenVMS x86-64. This as the patience with the older stuff
ages out.
Sooner or later, something new is required, and isn't easy/possible in
the old system(s). Not "if", but "when".

Note, while I took some cheap shots at the port of VMS to the itanic,
the reality was that those who would need to continue development and
production of Alpha just WERE NOT GOING TO DO SO !!! Alpha was
dead, dead, dead ...

When Intel threw a bone to the people using Alpha, by coughing up $200M
or so, if I remember correctly, things moved on.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-07-30 17:53:42 UTC
Permalink
Post by Dave Froble
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :)
- They need training for a totally freezed platform, for which they
will make support for more than again 10 years.
I can't count the number of times I've heard variations of that same "we
can't" story told and re-told.
Of course, "we can" is always true. Perhaps expensive. But perhaps not
the right decision.
Gerard has just implied that certification issues are involved.

If so, that changes the picture completely, especially when it
comes to the cost of any replacement.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
abrsvc
2021-07-30 18:31:04 UTC
Permalink
Post by Simon Clubley
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :)
- They need training for a totally freezed platform, for which they
will make support for more than again 10 years.
I can't count the number of times I've heard variations of that same "we
can't" story told and re-told.
Of course, "we can" is always true. Perhaps expensive. But perhaps not
the right decision.
Gerard has just implied that certification issues are involved.
If so, that changes the picture completely, especially when it
comes to the cost of any replacement.
Gerard hasn't said and probably can't say what the system does or
what kind of certification is involved. Personally, I can not
believe a VAX could be certified for anything today. Even J-Stars
eventually moved off of the VAX.
bill
J-stars went to alpha from Motorola a long time ago. The alpha was able to complete data load, computation AND display in less time than the Motorola computation and display only IRRC.

There are a number of different certifications at multiple levels. I have been involved in federal certifications of software programs running VAX software on emulators, so yes there are still certifications for VAX today.

Dan
Stephen Hoffman
2021-07-30 20:19:20 UTC
Permalink
Post by abrsvc
J-stars went to alpha from Motorola a long time ago. The alpha was
able to complete data load, computation AND display in less time than
the Motorola computation and display only IRRC.
There are a number of different certifications at multiple levels. I
have been involved in federal certifications of software programs
running VAX software on emulators, so yes there are still
certifications for VAX today.
JSTARS: "Our latest central computer replacement program upgrades the
current computers with powerful, advanced technology running Linux -
delivering a quantum leap forward to the mission system."

https://news.northropgrumman.com/news/releases/northrop-grumman-awarded-17-5-million-contract-for-fifth-generation-upgrade-of-e-8c-joint-stars-central-computers




If OpenVMS VAX or even VAX/VMS works for y'all, stay there.

But do expect to pay ongoing and increasing costs for avoiding upgrades
or avoiding porting (from VAX/VAX to OpenVMS x86-64, or from OpenVMS
VAX to Linux, etc), right up until management decides otherwise and
orders a port, or orders a replacement.

If y'all aren't keeping your own stuff current on OpenVMS, and keeping
your apps ~competitive across the available choices, y'all are headed
for trouble anyway. Trouble which has a habit of sneaking up.
--
Pure Personal Opinion | HoffmanLabs LLC
abrsvc
2021-07-30 20:30:18 UTC
Permalink
Post by Stephen Hoffman
J-stars went to alpha from Motorola a long time ago. The alpha was
able to complete data load, computation AND display in less time than
the Motorola computation and display only IRRC.
There are a number of different certifications at multiple levels. I
have been involved in federal certifications of software programs
running VAX software on emulators, so yes there are still
certifications for VAX today.
JSTARS: "Our latest central computer replacement program upgrades the
current computers with powerful, advanced technology running Linux -
delivering a quantum leap forward to the mission system."
https://news.northropgrumman.com/news/releases/northrop-grumman-awarded-17-5-million-contract-for-fifth-generation-upgrade-of-e-8c-joint-stars-central-computers
If OpenVMS VAX or even VAX/VMS works for y'all, stay there.
But do expect to pay ongoing and increasing costs for avoiding upgrades
or avoiding porting (from VAX/VAX to OpenVMS x86-64, or from OpenVMS
VAX to Linux, etc), right up until management decides otherwise and
orders a port, or orders a replacement.
If y'all aren't keeping your own stuff current on OpenVMS, and keeping
your apps ~competitive across the available choices, y'all are headed
for trouble anyway. Trouble which has a habit of sneaking up.
--
Pure Personal Opinion | HoffmanLabs LLC
There are times when there is not too much of a choice without a significant investment in time and hardware. I have been involved with a number of cases to keep VAXen or Alphas running due mainly to custom hardware interfaces that are not easy to replace. I am completing a case now, where the conversion to PLCs from VAX systems and Westinghouse Data Highway interfaces are being replaced. These have reliably worked for almost 40 years. The cost to replace is in the millions in both hardware and software. This is not a task taken lightly. In this case, emulation was not an option.

In a few other cases, the system worked just fine and there was no financial justification for re-writing the custom application. Here, emulation made sense as the cost was less than hardware service and there was essentially zero software cost. Will this be the solution forever, not likely. But, this at least eases the pain so that a replacement can be found or created over time.
calliet gérard
2021-08-02 16:58:13 UTC
Permalink
Post by Stephen Hoffman
J-stars went to alpha from Motorola a long time ago.  The alpha was
able to complete data load, computation AND display in less time than
the Motorola computation and  display only IRRC.
There are a number of different certifications at multiple levels.  I
have been involved in federal certifications of software programs
running VAX software on emulators, so yes there are still
certifications for VAX today.
JSTARS: "Our latest central computer replacement program upgrades the
current computers with powerful, advanced technology running Linux -
delivering a quantum leap forward to the mission system."
https://news.northropgrumman.com/news/releases/northrop-grumman-awarded-17-5-million-contract-for-fifth-generation-upgrade-of-e-8c-joint-stars-central-computers
If OpenVMS VAX or even VAX/VMS works for y'all, stay there.
But do expect to pay ongoing and increasing costs for avoiding upgrades
or avoiding porting (from VAX/VAX to OpenVMS x86-64, or from OpenVMS VAX
to Linux, etc), right up until management decides otherwise and orders a
port, or orders a replacement.
If y'all aren't keeping your own stuff current on OpenVMS, and keeping
your apps ~competitive across the available choices, y'all are headed
for trouble anyway. Trouble which has a habit of sneaking up.
I understand better from what point of view you speak.

I agree with you that nowadays the most important thing is to be
competitive, and to pay the lesser possible for things. It's a sort of
evidence to survive todays, and all of us, computer scientits have to be
the more agile to cope with that.

On my job here, I'm just a very old man: I try to make programs which
can do usefull, or even necessary things. And I work for even older men
who had decided some day that what had been truly certified had to go on
as it was certified.

I'm wondering what you are thinking about obsolescence, for your washing
machine or your television. Do you think it would be better we change
them each year? I think washing machine sellers would think it is a lot
better. But I don't think so. It is not at all the same domain, but what
I try to explain is that there are contexts where the goal is: not to
change anything, because of x constraints. There are domains where the
certification is about human live protection, for example, and the
concept of competitivity is not adequate.

Do you like Mozart? And do you prefer interpretors who play Mozart as it
is written, or the ones who improvize? - I do like Jazz, however, so the
question is opened.
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Dave Froble
2021-08-02 19:12:34 UTC
Permalink
Post by calliet gérard
On my job here, I'm just a very old man: I try to make programs which
can do usefull, or even necessary things. And I work for even older men
who had decided some day that what had been truly certified had to go on
as it was certified.
There are no guarantees. None!

I could have a really hard time trying to think of anything that humans
build that will always stay the same. That once something is acquired
that it will last "forever" (nothing does that, even the universe) or
that an exact duplicate can be purchased. Try to buy a Ford model-T.
Try to purchase a new version of any older automobile. Even our food
changes. Wheels are still round, but tires change.

People even change their sex ...

:-)

So to declare that something can never change, might be easy to say, but
impossible to enforce.

Perhaps certification can be designed so that each piece of a whole
could be individually certified. Perhaps not.

The more stubborn someone gets, the more it will likely cost when change
will happen, like it or not.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-08-02 20:39:36 UTC
Permalink
Post by Dave Froble
So to declare that something can never change, might be easy to say,
but impossible to enforce.
Absent unusually-isolated deployment or administrative circumstances,
software is "done" as much as lawns are "mowed".
Post by Dave Froble
Perhaps certification can be designed so that each piece of a whole
could be individually certified. Perhaps not.
Ayup. Operating and updating and re-certifying in parts is often the
most reliable and affordable way to update a complex application.

The alternative involving the often-substantial risk of wholesale
upgrade or wholesale replacement.

Incremental app changes can involve (for instance) incremental
development work around migrating DECnet connections to IP SSL/TLS/DTLS
connections.
Post by Dave Froble
The more stubborn someone gets, the more it will likely cost when
change will happen, like it or not.
Ayup. The further back an app gets, the larger the effort involved to
update it, or to port it, or to port its data.

A decade or two of "can't do that" can toggle into "we're doing that"
in a day, too. It's impressive to watch from afar.

Do I like the upgrade treadmill we're on? Nope. But we're on it.

And the windows for exploit remediation upgrades are ever-shorter,
which means working toward better robustness, whether to
BeyondCorp-like or otherwise.
--
Pure Personal Opinion | HoffmanLabs LLC
calliet gérard
2021-08-02 21:16:53 UTC
Permalink
Best to be in on that earlier, rather than later.
So the changing is like necessity - which is an intrinsik paradox,
isnt'it? -, and more than that it's a duty to be his servant.

Or because the only thing we can observe is the changing, the changing
is the most immobile necessity. "nothing new under the sun". On my side
there is not a more borrying thing than the perpetual duty of service of
the "changing"... which is the perpetual redoing of the same.

The perfect pleasure of the blues is the seventh guitar accord: a subtul
changing in the same, here is the real new.

yes,yes summer time :)
--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Lawrence D’Oliveiro
2021-08-12 04:12:29 UTC
Permalink
Post by calliet gérard
I'm wondering what you are thinking about obsolescence, for your washing
machine or your television. Do you think it would be better we change
them each year?
What if the manufacturer was able to stop you from getting parts to fix it and keep it going?

If you want a proper analogy with proprietary computer systems, that is it.
Dave Froble
2021-07-30 23:11:02 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :)
- They need training for a totally freezed platform, for which they
will make support for more than again 10 years.
I can't count the number of times I've heard variations of that same "we
can't" story told and re-told.
Of course, "we can" is always true. Perhaps expensive. But perhaps not
the right decision.
Gerard has just implied that certification issues are involved.
If so, that changes the picture completely, especially when it
comes to the cost of any replacement.
Just about all applications are certified to some extent, from engineer
and user testing, to formal and extensive documentation of, well,
testing. For various reasons some applications are subject to very
extensive testing, and some very well should be.

What I find appalling is the "it's done, it will never need to change"
and such mentality. Most things are never done. An example.

Some people who build experimental aircraft take that attitude, ie; it's
built, it will never come apart again. Bullshit! There are annual
condition inspections, pre-flight inspections before every flight, and
such. It's never done. There will always be repairs, upgrades, and
such. The reality, everything on that aircraft is a consumable, fuel
rather quickly, paint not so quickly, and the basic airframe, but
hopefully not so quickly.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phil Howell
2021-07-31 07:22:26 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by calliet gérard
I don't need a path forward in the situation, just a path backward :)
- They need training for a totally freezed platform, for which they
will make support for more than again 10 years.
I can't count the number of times I've heard variations of that same "we
can't" story told and re-told.
Of course, "we can" is always true. Perhaps expensive. But perhaps not
the right decision.
Gerard has just implied that certification issues are involved.
If so, that changes the picture completely, especially when it
comes to the cost of any replacement.
Just about all applications are certified to some extent, from engineer
and user testing, to formal and extensive documentation of, well,
testing. For various reasons some applications are subject to very
extensive testing, and some very well should be.
What I find appalling is the "it's done, it will never need to change"
and such mentality. Most things are never done. An example.
Some people who build experimental aircraft take that attitude, ie; it's
built, it will never come apart again. Bullshit! There are annual
condition inspections, pre-flight inspections before every flight, and
such. It's never done. There will always be repairs, upgrades, and
such. The reality, everything on that aircraft is a consumable, fuel
rather quickly, paint not so quickly, and the basic airframe, but
hopefully not so quickly.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
https://webinfo.uk/webdocssl/irse-kbase/ref-viewer.aspx?refno=1559669757&document=2.10%20strangaric%20-%20legacy%20train%20control%20system%20stabilisation.pdf

This is an example of modernising a legacy system
Loading...