Device locked by non existing process.

[Jan-Erik Söderholm]

Hi.

$ tcpip sh ver

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V8.4-2L2

Sometimes we get a device (TNA device) looked-up having an
"Owner process ID" that has an PID of an process that doesn't
exist (at that moment). The “Owner process” field is empty.

$ sh dev/fu tna8110

Terminal TNA8110:, device type LA120, is online, record-oriented
device, carriage control.

Error count 0 Operations completed 390
Owner process "" Owner UIC [MK]
Owner process ID 0008C069 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 2 Default buffer size 132

There is no process "0008C069".

This prevent us from doing a clean application restart (which
includes a telnet /delete and telnet /create of the TNA device).

Now, is there an easy way to clear out this “owner PID” field?

The current “solution” is to switch to another/new fixed TNA number
for that specific application. The locked device seems to disappear
after some time (we don’t care really).

Regards, Jan-Erik.

[Stephen Hoffman]

On 2018-04-04 16:57:38 +0000, Jan-Erik S derholm said:

> $ tcpip sh ver
>
> HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
> on a COMPAQ AlphaServer DS20E 666 MHz running OpenVMS V8.4-2L2
>
> Sometimes we get a device (TNA device) looked-up having an "Owner
> process ID" that has an PID of an process that doesn't exist (at that
> moment). The “Owner process” field is empty.

> ...

> There is no process "0008C069".
>
> This prevent us from doing a clean application restart (which includes
> a telnet /delete and telnet /create of the TNA device).
>
> Now, is there an easy way to clear out this “owner PID” field?

No supported means, and nothing that I'd be inclined to do on a
production server.

Also check with VSI support about the rundown handling. Might be able
to drop one of the IP timers or maybe enable keepalive, depending on
what's causing that TN device to eventually clear itself.

Easiest approach? Don't use fixed TN names. Use logical names or a
database reference or a lock resource block or a command specification
or whatever else might be appropriate to allow the software to find the
target TN device.

Slightly more involved approach? Figure out why the process formerly
known as 0008C069 is exiting, and maybe allow it to (better) clean up,
before the process shuffles off to its final resting place in the great
PID graveyard.


--
Pure Personal Opinion | HoffmanLabs LLC

[DaveFroble]

Some things, and I believe the TN logical devices are one, stay around a bit
before going away. The time 2 minutes seems to be something I've seen in the
past. It's been a while, so I may mis-remember, but I think there is a
parameter somewhere that sets this timeout. Why there is a timeout rather than
immediate clean-up, I don't know.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Jan-Erik Söderholm]

When doing a "clean" telnet /delete, it takes approx. 15 sec between the
device going to "offline" until it is removed completely. But these devices
with bogus PID stays way longer. The actual device in the example above
is gone now, but that was approx. 6 hours ago.

The actual device points to a label printer. It seems as the application
tried to print something, the printer was not accessible, and the
application was stopped (a terminal app run from a login.com file).

And yes, as Stephen also commented (kicking in open doors), we (I) have
been thinking of a completely different solution where device numbers
are picked from a pool at each restart and with a larger usage of logicals.
But that was not how this was built 25+ years ago. It all started using
physical TTAnnn: ports, then for many years used LTAnnnn: ports, and
finally (since like 15 years) TNAnnnn: ports. The application code has not
changed, it still uses QIO to terminal devices.

> It's been a while, so I may mis-remember, but I think there
> is a parameter somewhere that sets this timeout.  Why there is a timeout
> rather than immediate clean-up, I don't know.

I have had that question as a ticket with VSI support, but they
could not find a way to adjust that 15 sec delay between "offline"
and removal of the TNA device. It seems to be burried within the
telnet device driver.

[Simon Clubley]

What is the state of the underlying TCP/IP connection itself
both during those 15 seconds and also when problems occur ?

Note: not Telnet level state, but the TCP level state.

Is the Telnet device hanging around until the underlying TCP/IP
connection has fully disappeared ?

When you have problems, is the underlying TCP connection getting
stuck in one of the time or close wait states ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Stephen Hoffman]

On 2018-04-04 23:21:51 +0000, Jan-Erik S derholm said:

> And yes, as Stephen also commented (kicking in open doors), we (I) have
> been thinking of a completely different solution where device numbers
> are picked from a pool at each restart and with a larger usage of
> logicals.

What, no Rdb query to find the printer?

> But that was not how this was built 25+ years ago. It all started using
> physical TTAnnn: ports, then for many years used LTAnnnn: ports, and
> finally (since like 15 years) TNAnnnn: ports. The application code has
> not changed, it still uses QIO to terminal devices.

Are these telnet devices marked as spooled perchance, and might
changing that spooled status clear up the stuck devices? Worth a try.
There's been a long, weird and sometimes buggy history of spooled
devices on OpenVMS, and spooled devices and print queues haven't always
played well together either. And if there are symbionts involved, add
another layer of timeouts and complexity. I'd assume no symbionts and
spooled devices given old code and $qio, but I've seen all matter of
mongrel implementations over the years. The temporary files variously
involved sometimes getting lost in the file system and accreting to
fill the spool-associated storage device, too.

[Richard Maher]

Inner mode I/O pending?

Can you OPEN it and READ/WRITE?

[Michael Moroney]

DaveFroble <da...@tsoft-inc.com> writes:

>> Now, is there an easy way to clear out this “owner PID” field?

...

>Some things, and I believe the TN logical devices are one, stay around a bit
>before going away. The time 2 minutes seems to be something I've seen in the
>past. It's been a while, so I may mis-remember, but I think there is a
>parameter somewhere that sets this timeout. Why there is a timeout rather than
>immediate clean-up, I don't know.

It has to do with that in theory, packets destined for the closing telnet
port can still be floating around on the net somewhere, and you don't want
them to go to a new application using the same port. They are supposed to
be all gone within the timeout period (affected by TTL). Part of the TCP
design.

As to the port being allocated to nonexistent processes, it can be the
driver not maintaining a reference count correctly, or the driver ignores
cancels to I/Os that for some reason take substantial time to complete.
(a process going away will have cancels issued for any I/Os it still has
outstanding)

[Jan-Erik Söderholm]

Don't know, can try that next time if I remember it.
It might very well have something to do with pending I/Os.
That might also be a simple addition to the restart scripts.

[Jan-Erik Söderholm]

Den 2018-04-05 kl. 01:36, skrev Simon Clubley:
> On 2018-04-04, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>> Den 2018-04-05 kl. 01:04, skrev DaveFroble:
>>> It's been a while, so I may mis-remember, but I think there
>>> is a parameter somewhere that sets this timeout.  Why there is a timeout
>>> rather than immediate clean-up, I don't know.
>>
>> I have had that question as a ticket with VSI support, but they
>> could not find a way to adjust that 15 sec delay between "offline"
>> and removal of the TNA device. It seems to be burried within the
>> telnet device driver.
>>
>
> What is the state of the underlying TCP/IP connection itself
> both during those 15 seconds and also when problems occur ?
>
> Note: not Telnet level state, but the TCP level state.
>
> Is the Telnet device hanging around until the underlying TCP/IP
> connection has fully disappeared ?
>
> When you have problems, is the underlying TCP connection getting
> stuck in one of the time or close wait states ?
>
> Simon.
>

Note that the 15 sec delay before removal, is not some error situation,
it is always like that when deleting a TNA device.

When there are problems, the TNA device doesn't get removed at all.

[Jan-Erik Söderholm]

Den 2018-04-05 kl. 01:43, skrev Stephen Hoffman:
> On 2018-04-04 23:21:51 +0000, Jan-Erik S derholm said:
>
>> And yes, as Stephen also commented (kicking in open doors), we (I) have
>> been thinking of a completely different solution where device numbers are
>> picked from a pool at each restart and with a larger usage of logicals.
>
> What, no Rdb query to find the printer?

If it wasn’t meant as a joke, then what has Rdb to do with TNA devices?

But of course you can use Rdb to store your username -> printer config.
But this was created before 1994 when Rdb was introduced here and uses
RMS based lookup tables for those things.

>
>> But that was not how this was built 25+ years ago. It all started using
>> physical TTAnnn: ports, then for many years used LTAnnnn: ports, and
>> finally (since like 15 years) TNAnnnn: ports. The application code has
>> not changed, it still uses QIO to terminal devices.
>
> Are these telnet devices marked as spooled perchance, and might changing
> that spooled status clear up the stuck devices?

I didn't know that TNA devices can be marked "spooled". For other printers,
where the printout is not direct to the printer but using a printer queue,
we have LTA devices that are spooled, so that the appication can just print
to the device and get the output submitted to the printer queue.

> Worth a try. There's been
> a long, weird and sometimes buggy history of spooled devices on OpenVMS,
> and spooled devices and print queues haven't always played well together
> either.

The spooled LTA devices and queues are bullet proof. Never a single issue
or hanging device or queue or anything.

Application -> (spooled) LTA device
LTA device -> LTA queue ("logical")
LTA queue -> physical DCPS printer queue

$ sh dev LTA9950:
LTA9950: Online spooled 0
$ sh que lta9950
Logical queue LTA9950, idle, assigned to XYZ
$ sh que XYZ
Printer queue XYZ, idle, on xxxx::"IP_LPD/n.n.n.n", .....
$

> And if there are symbionts involved, add another layer of timeouts
> and complexity.  I'd assume no symbionts and spooled devices given old code
> and $qio,

As I recall, the application that prints to spooled LTA devices are also
doing that using QIO calls.

But again, the actual case here uses direct application -> label printer
communication. No spooling or queues involved.

[Simon Clubley]

On 2018-04-05, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:

> Den 2018-04-05 kl. 01:36, skrev Simon Clubley:
>>
>> What is the state of the underlying TCP/IP connection itself
>> both during those 15 seconds and also when problems occur ?
>>
>> Note: not Telnet level state, but the TCP level state.
>>
>> Is the Telnet device hanging around until the underlying TCP/IP
>> connection has fully disappeared ?
>>
>> When you have problems, is the underlying TCP connection getting
>> stuck in one of the time or close wait states ?
>>
>

> Note that the 15 sec delay before removal, is not some error situation,
> it is always like that when deleting a TNA device.
>

Yes, I understood that. When a TCP connection closes during normal
operation, it goes through a series of states before being finally
removed from the system.

I was wondering if the 15 second delay was because the underlying
TCP close sequence was also taking 15 seconds to complete.

> When there are problems, the TNA device doesn't get removed at all.
>

Which is why the state of the underlying TCP connection would be
of great interest when that happens. Do you have keepalive probing
enabled for your TCP connections ?

[Stephen Hoffman]

On 2018-04-05 06:58:24 +0000, Jan-Erik S derholm said:

> Den 2018-04-05 kl. 01:43, skrev Stephen Hoffman:
>> On 2018-04-04 23:21:51 +0000, Jan-Erik S derholm said:
>>
>>> And yes, as Stephen also commented (kicking in open doors), we (I) have
>>> been thinking of a completely different solution where device numbers
>>> are picked from a pool at each restart and with a larger usage of
>>> logicals.
>>
>> What, no Rdb query to find the printer?
>
> If it wasn’t meant as a joke, then what has Rdb to do with TNA devices?
>
> But of course you can use Rdb to store your username -> printer config.
> But this was created before 1994 when Rdb was introduced here and uses
> RMS based lookup tables for those things.

Non-spooled, non-queued, direct-access device I/O for printers is
fairly rare in new implementations in recent years.

Given your fondness for Rdb, it that would seem a reasonable way to map
the target devices.

>>> But that was not how this was built 25+ years ago. It all started using
>>> physical TTAnnn: ports, then for many years used LTAnnnn: ports, and
>>> finally (since like 15 years) TNAnnnn: ports. The application code has
>>> not changed, it still uses QIO to terminal devices.
>>
>> Are these telnet devices marked as spooled perchance, and might
>> changing that spooled status clear up the stuck devices?
>
> I didn't know that TNA devices can be marked "spooled".

Most any serial device can be spooled, AFAIK.

Obviously spooling allows the app to do its thing and not wait for the
printer. It was a common optimization, back when apps were writing
directly to devices.

> For other printers, where the printout is not direct to the printer but
> using a printer queue, we have LTA devices that are spooled, so that
> the appication can just print to the device and get the output
> submitted to the printer queue.

>
>> Worth a try. There's been a long, weird and sometimes buggy history of
>> spooled devices on OpenVMS, and spooled devices and print queues
>> haven't always played well together either.
>
> The spooled LTA devices and queues are bullet proof. Never a single
> issue or hanging device or queue or anything.

There have been issues with spooled devices over the years. Mostly
around cleaning up the temporary files. There were patches to fix the
known cases, but it's possible that spooled files can be "lost" over
reboots or such.

[Jan-Erik Söderholm]

Den 2018-04-06 kl. 22:51, skrev Stephen Hoffman:
> On 2018-04-05 06:58:24 +0000, Jan-Erik S derholm said:
>
>> Den 2018-04-05 kl. 01:43, skrev Stephen Hoffman:
>>> On 2018-04-04 23:21:51 +0000, Jan-Erik S derholm said:
>>>
>>>> And yes, as Stephen also commented (kicking in open doors), we (I) have
>>>> been thinking of a completely different solution where device numbers
>>>> are picked from a pool at each restart and with a larger usage of
>>>> logicals.
>>>
>>> What, no Rdb query to find the printer?
>>
>> If it wasn’t meant as a joke, then what has Rdb to do with TNA devices?
>>
>> But of course you can use Rdb to store your username -> printer config.
>> But this was created before 1994 when Rdb was introduced here and uses
>> RMS based lookup tables for those things.
>
> Non-spooled, non-queued, direct-access device I/O for printers is fairly
> rare in new implementations in recent years.

Oh, sorry. I was not talkning about something built in "recent years",
I might have been somewhat unclear on that point. I know perfectly well
how I'd like a lot of these things to be designed and built, if done today.

>
> Given your fondness for Rdb, it that would seem a reasonable way to map the
> target devices.

Much of this design was done and built before Rdb 1.0 was released.

>
>>>> But that was not how this was built 25+ years ago. It all started using
>>>> physical TTAnnn: ports, then for many years used LTAnnnn: ports, and
>>>> finally (since like 15 years) TNAnnnn: ports. The application code has
>>>> not changed, it still uses QIO to terminal devices.
>>>
>>> Are these telnet devices marked as spooled perchance, and might changing
>>> that spooled status clear up the stuck devices?
>>
>> I didn't know that TNA devices can be marked "spooled".
>
> Most any serial device can be spooled, AFAIK.
>

OK. For some reason the LAT was kept for the spooled devices when
TCPIP was intruduced. I just thought that TNA devices could not be
used in the same way. I hae not seen that yu can create TNA devices
without a corresponding TCPIP host/port. The LTA devices does not
have a host/port, that are just "spooled".

> Obviously spooling allows the app to do its thing and not wait for the
> printer.   It was a common optimization, back when apps were writing
> directly to devices.
>

Our apps needs to know if the label printouts went OK, within 10s of
a second. It seems harder if using spooling and queues.

>> For other printers, where the printout is not direct to the printer but
>> using a printer queue, we have LTA devices that are spooled, so that the
>> appication can just print to the device and get the output submitted to
>> the printer queue.
>
>>
>>> Worth a try. There's been a long, weird and sometimes buggy history of
>>> spooled devices on OpenVMS, and spooled devices and print queues haven't
>>> always played well together either.
>>
>> The spooled LTA devices and queues are bullet proof. Never a single issue
>> or hanging device or queue or anything.
>
> There have been issues with spooled devices over the years.  Mostly around
> cleaning up the temporary files.   There were patches to fix the known
> cases, but it's possible that spooled files can be "lost" over reboots or
> such.

Are you talking about lost files "not found in a directory"? No such files
at the moment. And that has probably not been checked in several years.
Not an issue that we are worrying about daily.

[DaveFroble]

Reading about a 25+ year old app still providing good service today is
refreshing. Probably quite a few of them still doing so.

In my perverse way, I'm then compelled to ask, what 25+ year old weendoze apps
are still doing good service today? Unix apps?

I'd agree that today there may be better methods of doing some things, but,
there is also something to "if it ain't broke, don't fix it".

[Arne Vajhøj]

On 4/6/2018 8:06 PM, DaveFroble wrote:
> Reading about a 25+ year old app still providing good service today is
> refreshing.  Probably quite a few of them still doing so.
>
> In my perverse way, I'm then compelled to ask, what 25+ year old
> weendoze apps are still doing good service today?

Given that NT 3.1 was released July 1993 probably none.

:-)

But some will probably show up in 2025 and 2028.

Arne

[johnwa...@yahoo.co.uk]

How much would any sensible person want to bet on any
significant number of Window boxes still running the
same way in 2025 (never mind 2028) ?

I know some people round here said "VMS will be dead in
five years", and said it much more than five years ago.
That turned out to have been a misprediction. Turns out
VMS might even last longer than SPARC and Solaris, which
would be a laugh in some ways.

Meanwhile, back in the commodity world of Windows and
Linux, what are the odds of anything available today (let
alone five years ago) still being relevant in five years
time?

I don't even know how to start answering the question for
Linux in general (nothing against Linux where appropriate,
but the question above isn't realistically answerable,
though narrowing it down might help, e.g. SuSe Linux
Enterprise typically offers a ten year lifecycle).

That said, here's a current published MS OS lifecycle
for Win7, Win8, Win10:
https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Have a read if you like, what follows is my commentary.

It seems fair to summarise it for mainstream (non-Enterprise
and non-Embedded) Windows OS customers as:
"anything you can buy today or may have bought in the past
will be end of mainstream service life two years from now if
not sooner" [1].

The obvious exception is the "Long Term Service" flavour
of Windows Server 2016, scheduled to be on mainstream
support until 2022, and extended support till 2027 (if
MS still have a relevant service delivery ecosystem at
that stage).

A handful of customers have historically chosen to pay $$$M
direct to MS for continued 'support' even after 'extended'
support runs out. Will that option still be available (or
useful) in a few years?

Anyone who's bet any serious money on non-mainstream Wintel
systems e.g. MS Windows RT (the ARM version) etc hopefully
won't make the same mistake again. Windows IoT seems likely
to head the same way in general, perhaps with a few corporate
exceptions e.g. in the automotive market.

Windows Embedded on x86, for anyone who's interested, is
basically EOL for new designs unless people want to migrate
their applications to Windows 8 or 10 (why would they?).

The existing Win7-based flavours of Windows Embedded are
mostly end of mainstream support alredy; some (e.g.
Windows PoS) reach end of extended support life in 2021.

Any Window boxes I directly support haven't gone beyond
Windows 7; one of the reasons for that is that the
people/systems I personally know that *have* gone beyond
Win7 haven't found it a very productive experience (to
put it politely); some have gone (or will soon go) back
to Win7.

In those circumstances, I do wonder what kind of
people are deploying Windows 10 systems at the moment,
especially as MS have made it very clear that Windows
10 is designed around being offered as a service, with
continuous updates (ie someone else's computer, someone
else's sysadmins, someone else's network, etc - just
like bureau timesharing, but with emojis rather than
teletypes). Slightly different rules apply to Windows 10
in Enterprise deals.

From a commercial point of view, Win10 seems to
make the existing MS support ecosystem into a
threatened species - you're either a Cloud customer
with a corporate Cloud provider, or you're an
Enterprise customer (with your own cloud?). Not
much space in between for smaller outfits or for
"unusual" requirements (e.g. the National
Instruments LabView etc market would be one
visible example where the gear has to be onsite
for resilience and responsiveness reasons???)

MS have tried to discourage further deployments
of Win7, both by making it increasingly hard to
buy, and by leaving the Windows Update process
(for fresh Win7 installs) broken at various times
in the last few years [2]. I did experience the
borked Windows Updates but stuck with Win7, and
the Windows Update process appears to have been
working again (for my fresh installs) since a
year or two ago. Hallelujah.


So, 2025 seems a very long way away from today
in commodity IT terms. The widely used commodity
OSes don't quite seem to know where they're
headed or when they'll get there.

Meanwhile VMS in its VSIVMS flavour is moving
forward in a way which few would have predicted;
more progress would doubtless be welcome,
particularly in the bigger (non-Engineering)
picture.

See you in 2025? 2028?


[1] https://docs.microsoft.com/en-gb/windows-server/get-started/windows-server-release-info
[2] https://superuser.com/questions/951960/windows-7-sp1-windows-update-stuck-checking-for-updates

[seasoned_geek]

On Wednesday, April 4, 2018 at 6:21:53 PM UTC-5, Jan-Erik Söderholm wrote:
> >>
> >> Sometimes we get a device (TNA device) looked-up having an
> >> "Owner process ID" that has an PID of an process that doesn't
> >> exist (at that moment). The “Owner process” field is empty.
> >>
>

> I have had that question as a ticket with VSI support, but they
> could not find a way to adjust that 15 sec delay between "offline"
> and removal of the TNA device. It seems to be burried within the
> telnet device driver.

Been doing some TCP/IP service coding recently. One of the reasons I am so adamant about VMS needing a TCP/IP Software Appliance instead of the somewhat consistent with *nix that did everything wrong train wreck we have is this type of thing.

Here is what I have noticed running things in Debug and periodically shooting out of the saddle.

Killing a PID off which has a pending socket IO on a port will leave that port completely un-usable until the configured maximum timeout. On my system, I believe that is two minutes. There was some horribly outdated doc I found with a search, but given it had a Compaq logo on it, I didn't trust it. Somewhere in this TCPIP configuration, this can be changed though, according to that doc. If yours is taking longer, your value is probably higher. Sorry, I didn't look to see where it was.

The horrible advice found in the "Best Practices" documentation on-line can also cause this issue. The "server" side of the connection is only supposed to call ShutDown() when it is officially jumping over the edge of a cliff. (Documentation and flowchart not clear on that. Makes it look like Server should shutdown( blah, 2) when it is done spewing to client because many clients don't bother to ever shutdown even when they go away.)

At any rate, calling the shutdown() from the server side as part of cleanup code when exiting, can also leave the port in a state where you must also wait for some timeout period which may or may not be configurable. If TCPIP or you try to restart that service it will fail to bind with a "port already in use" type error.

[seasoned_geek]

On Friday, April 6, 2018 at 7:29:51 PM UTC-5, Arne Vajhøj wrote:
>
> Given that NT 3.1 was released July 1993 probably none.
>
> :-)
>
> But some will probably show up in 2025 and 2028.

Never happen. Not in this or any other life time. Those apps aren't providing good service TODAY.

[seasoned_geek]

Nice post.

Windows mobile, which FAIN was different from Windows Embedded x86, was EOL last year. It caused a rash of business looking for people to port their Windows phone apps to Android. It also spawned another rash of Qt phone app work for companies smart enough to want one source which could cross compile to multiple targets.

Neither Windows nor Android will actually be here in 5 years. I have posted this before in here, but will post it again.

Windows is going the Apple route. Putting what looks like a Windows desktop on top of Ubuntu. Windows 10 is the first serious tire kicking in that direction.

Both Canonical and Google are pursuing Fuchsia (different flavors soon to have ever so annoying API differences) as their core platform. Android unfixable. Spectre and Meltdown were also unfixable on many Android devices due to Android being locked into an ancient kernel without much of an update path.

Canonical will get funding from Microsoft to part with Ubuntu which will make for an interesting reduction in Linux distros if MS decides to not put up source repos. Awful lot of YABUs will go away.

Microsoft has legal and financial reasons for doing what Apple already did. Nobody can effectively sue an OpenSource based project for security failures, but they can successfully sue a close source commercial OS.

(Something to really keep in mind when pursuing worthless x86 platform.)

Somehow Apple even managed to avoid getting sued when they choose to release a version of the OS without a password on root.

https://www.csoonline.com/article/3238890/security/apples-high-sierra-allows-root-with-no-password-theres-a-workaround-to-help.html

Google has legal and financial reasons to jettison Android, especially with the Facebook appearance before Congress. Google right now cannot do anything to mitigate the Android device exposure other than buy every exploitable device currently on the market. THERE IS NO FIX. The kernel is so completely out of date because newer versions wouldn't let the butchered Android code run. It's cheaper and far less effort to make Fuchsia work...provided EU or Congress doesn't force Google to purchase __EVERY__ vulnerable Android device. That is 2-in-1, tablet and phone running Android. The hardware makers are not liable. It is purely Google holding the bag.

Having said all of that...

There is a dry cleaners in/near Beaverton Oregon which is running a system on DOS. They even still have a functioning MFM/RLL hard drive. I heard the chirping Seagate cricket while checking out and looked around at the monitor. I expressed my shock that they were still running DOS, in such a hot and humid environment no less. She said the machine came with the business and they had no idea what to do when it failed. Maybe they could find a PP Zip drive to copy off to before it dies? Odds of finding an ISA bus nick card with DOS only drivers pretty slim. Maybe Lantastic is still around?

The Toyota dealership where I purchased a car launched a DOS application to enter all of my sales information. The manager said a lot of dealers in the area ran the same package, even if they weren't Toyota. Screen looked like it "might" have been written with DataBoss. It's not like they could show me the source code.

Very few Windows systems ever managed to perform an essential function.

DOS based systems came about when people were desperately trying to solve everyday problems. Once these core things were solved the solution was kept. There was no need to replace it. While it has been a few years since I spoke with them, there are still companies running DOS based Btrieve applications nursing an old Netware server along. One of them is a stand-alone Btrieve application I wrote back in the late 1980s early 1990s. Yes, it is DOS too. It generates their invoices and payroll based on truck loads drivers hauled. The price per ton and payment per mile were configurable and all they needed to do was enter the weight tickets and then select the generate option.

You won't find people nursing Windows 3.x along like this. The WINE package really kind of sucks. Despite miles of improvements, it still really sucks. Most of the focus is on games so it still doesn't load office suites like Lotus SmartSuite 98 and run them correctly. It gets worse as you move forward into 95, 98, 2000, xp, etc.

The "commodity" hardware got suckier too. Power supplies used to out last up to 5 montherboards. Now, the average mobo lifespan isn't any longer, but it outlasts 5 of the "standard" power supplies it was either shipped with or the models recommended by the manufacturer.

[DaveFroble]

Gee John, some real interesting thoughts, and information.

Jan Erik may have mentioned that his customer may in the future replace the
current applications (and OS) using something new. Or maybe I'm delusional
(again) and he hasn't mentioned such.

Anyway, what thoughts should go through the selection process should some entity
be facing a replacement of their apps, for whatever reason? If the entity has
the common sense to look at VMS and realize that while at times the owner of the
OS has been less than reliable (understatement), not once did the OS fail to the
extent that the apps needed a wholesale change. If the entity has the common
sense to ask if any other environment has displayed such a long useful life
span, perhaps IBM and VMS come to mind. Any others?

Yes, apps will need to adapt as time passes. The world changes, and good apps
need to be agile enough to meet new requirements. But that's a far cry from
total app replacement.

From a cost standpoint, from what I've read, Jan Erik's customer can do what
they do, and count on an outside service to maintain and upgrade their apps.
That's many times a rather small cost.

Now if only we could count on common sense actually existing, then perhaps VMS
has a brighter future than many predict.

[DaveFroble]

seasoned_geek wrote:
> The horrible advice found in the "Best Practices" documentation on-line can
> also cause this issue. The "server" side of the connection is only supposed
> to call ShutDown() when it is officially jumping over the edge of a cliff.
> (Documentation and flowchart not clear on that. Makes it look like Server
> should shutdown( blah, 2) when it is done spewing to client because many
> clients don't bother to ever shutdown even when they go away.)

I'm guessing that's a design issue. The design I've been using uses the concept
that each connection is a single transaction. Has been working well.

Client requests a connection
Server grants the connection
Client sends data
If server detects connection dropped, server closes connection
If client detects connection dropped, client closes connection
Server sends back completed request
Server closes connection
Client closes connection

I'm aware that there can be requirements for differing designs.

[seasoned_geek]

On Saturday, April 7, 2018 at 4:17:14 PM UTC-5, DaveFroble wrote:
> seasoned_geek wrote:
> > The horrible advice found in the "Best Practices" documentation on-line can
> > also cause this issue. The "server" side of the connection is only supposed
> > to call ShutDown() when it is officially jumping over the edge of a cliff.
> > (Documentation and flowchart not clear on that. Makes it look like Server
> > should shutdown( blah, 2) when it is done spewing to client because many
> > clients don't bother to ever shutdown even when they go away.)
>
> I'm guessing that's a design issue. The design I've been using uses the concept
> that each connection is a single transaction. Has been working well.
>
> Client requests a connection
> Server grants the connection
> Client sends data
> If server detects connection dropped, server closes connection
> If client detects connection dropped, client closes connection
> Server sends back completed request
> Server closes connection
> Client closes connection
>
> I'm aware that there can be requirements for differing designs.
>

Works fine when you are only doing one per second or something like that. When you write a script to send several dozen back to back from the command line you will start seeing connection refused then the port will be wonky, keeping existing connections but not allowing new ones.

Somewhere in the untrustable documentation you will find squirreled away a shutdown(blah, 2) call requires a reset/idle period of n-seconds before re-use. Even killing off the service and restarting it won't allow a rebind. Wait for the timeout period before restart and life once again is good.

If you operate in the *nix anarchy must reign world and only shoot the connection after it has been idle for many seconds, life is also good.

Rapid fire connect-short message-shutdown-close operation causes TCP/IP to have an upset tummy and it pukes on you.

[Jim]

Check out the setting of socket option SO_REUSEADDR (and friend
SO_REUSEPORT) for reuse of address/port combo before TIME_WAIT
timer expires.

[seasoned_geek]

On Saturday, April 7, 2018 at 6:00:37 PM UTC-5, Jim wrote:

> Check out the setting of socket option SO_REUSEADDR (and friend
> SO_REUSEPORT) for reuse of address/port combo before TIME_WAIT
> timer expires.

Thanks. I set the socket options in the program. Same problem. Didn't go digging through the arcane TCP/IP configuration stuff to see if there was something tweakable there. Anyone who runs it most likely wouldn't bother either. All of the *nix code I looked at didn't bother to Shutdown() or Close(), then again, *nix did pretty much everything wrong when it comes to TCP/IP.

There also seems to be some magic hidden internal connection backlog which overrides, without throwing error, the program set value. When you set a backlog to 50 and have the server shutting down accepted connections, a rapid fire script sent 12 individual short messages should never come back with "connection refused," but it does.

[DaveFroble]

All I can say is that it's working quite well with many transactions per second.

[Arne Vajhøj]

On 4/7/2018 6:06 AM, johnwa...@yahoo.co.uk wrote:
> On Saturday, 7 April 2018 01:29:51 UTC+1, Arne Vajhøj wrote:
>> On 4/6/2018 8:06 PM, DaveFroble wrote:
>>> Reading about a 25+ year old app still providing good service today is
>>> refreshing.  Probably quite a few of them still doing so.
>>>
>>> In my perverse way, I'm then compelled to ask, what 25+ year old
>>> weendoze apps are still doing good service today?
>>
>> Given that NT 3.1 was released July 1993 probably none.
>>
>> :-)
>>
>> But some will probably show up in 2025 and 2028.
>

> How much would any sensible person want to bet on any
> significant number of Window boxes still running the
> same way in 2025 (never mind 2028) ?

The way of thinking that if a system works then there
is no need to replace it and does not really matter if
the software if officially EOL is not limited to VMS
world.

There were millions of Windows 2000 and 2003 servers
deployed.

The majority is long gone. And of the remaining many will
go before they reach the 25 year mark.

But some will be left running.

> Meanwhile, back in the commodity world of Windows and
> Linux, what are the odds of anything available today (let
> alone five years ago) still being relevant in five years
> time?

Relevant is a very subjective word.

Some places OS'es is kept running way after the OS version
is EOL.

We got a reminder last year with the Petaya malware. MS
ended up delivering patches for XP (2001) and 2003 even
though they were EOL, because some places they were
still used.

Maybe foolish but that does not change the fact that they were
there.

> That said, here's a current published MS OS lifecycle
> for Win7, Win8, Win10:
> https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet
>
> Have a read if you like, what follows is my commentary.
>
> It seems fair to summarise it for mainstream (non-Enterprise
> and non-Embedded) Windows OS customers as:
> "anything you can buy today or may have bought in the past
> will be end of mainstream service life two years from now if
> not sooner" [1].

That is correct but also misleading.

The new Windows 10 EOL policy state that a given patch level
is only supported for 2 years.

But they will supply new patches allowing for support until 2025.

Anyway Windows 10 is desktop not server and the above
was about server.

There are supposedly over 500 million Windows 10
PC's out there.

Home PC's are bought with Windows 10.

Companies are slowly rolling Windows 10 out as well.

Arne

[Arne Vajhøj]

On 4/7/2018 3:18 PM, seasoned_geek wrote:
> Both Canonical and Google are pursuing Fuchsia (different flavors
> soon to have ever so annoying API differences) as their core
> platform. Android unfixable. Spectre and Meltdown were also unfixable
> on many Android devices due to Android being locked into an ancient
> kernel without much of an update path.

> Google has legal and financial reasons to jettison Android,
> especially with the Facebook appearance before Congress. Google right
> now cannot do anything to mitigate the Android device exposure other
> than buy every exploitable device currently on the market. THERE IS
> NO FIX. The kernel is so completely out of date because newer
> versions wouldn't let the butchered Android code run. It's cheaper
> and far less effort to make Fuchsia work...provided EU or Congress
> doesn't force Google to purchase __EVERY__ vulnerable Android device.
> That is 2-in-1, tablet and phone running Android. The hardware makers
> are not liable. It is purely Google holding the bag.

Really good story.

Only problem is that it has nothing to do with reality.

Newer Android versions run on Linux kernel 4.4 or newer.

That is from 2016 - not ancient.

And far ahead of various Linux server distros. RHEL 7 is
still on 3.10 and I believe SUSE 12 is still on 3.12.

Arne

[George Cornelius]

> There is a dry cleaners in/near Beaverton Oregon which is running a system =
> on DOS. They even still have a functioning MFM/RLL hard drive. I heard the =
> chirping Seagate cricket while checking out and looked around at the monito=
> r. I expressed my shock that they were still running DOS, in such a hot and=
> humid environment no less. She said the machine came with the business and=
> they had no idea what to do when it failed. Maybe they could find a PP Zip=
> drive to copy off to before it dies? Odds of finding an ISA bus nick card =

> with DOS only drivers pretty slim. Maybe Lantastic is still around?

I have working ISA NICs. Made by HP, no less. With BOTH AUI and BNC.
Also have the 10baseT variant.

Should I take off the $0.10 garage sale stickers and up the price to $10K?

Also have an old Pentium system that I boot off CD (barely), to get to
Knoppix 3.7 since that's the only thing that still runs on it well
enough to use for anything. But there is DOS on it, too, as long as
you don't try to use more than the first 500MB of the HDD.

George

[Bill Gunshannon]

On 04/16/2018 02:30 AM, George Cornelius wrote:
>> There is a dry cleaners in/near Beaverton Oregon which is running a system =
>> on DOS. They even still have a functioning MFM/RLL hard drive. I heard the =
>> chirping Seagate cricket while checking out and looked around at the monito=
>> r. I expressed my shock that they were still running DOS, in such a hot and=
>> humid environment no less. She said the machine came with the business and=
>> they had no idea what to do when it failed. Maybe they could find a PP Zip=
>> drive to copy off to before it dies? Odds of finding an ISA bus nick card =
>> with DOS only drivers pretty slim. Maybe Lantastic is still around?
>
> I have working ISA NICs. Made by HP, no less. With BOTH AUI and BNC.
> Also have the 10baseT variant.
>
> Should I take off the $0.10 garage sale stickers and up the price to $10K?

I would have to dig around but I am sure I still have ISA NIC's in
my collection. I used to have a bunch of WD8003's which were the
only NIC's I ever used that could saturate a network. Especially
running BLASTER.

>
> Also have an old Pentium system that I boot off CD (barely), to get to
> Knoppix 3.7 since that's the only thing that still runs on it well
> enough to use for anything. But there is DOS on it, too, as long as
> you don't try to use more than the first 500MB of the HDD.

Puppy Linux comes to mind. I am running a copy of WaryPuppy on an old
Gateway Laptop and it is perfectly usable. even the Office Suite. :-)

bill

[George Cornelius]

In article <fjjl1m...@mid.individual.net>, Bill Gunshannon <bill.gu...@gmail.com> writes:
> I would have to dig around but I am sure I still have ISA NIC's in
> my collection. I used to have a bunch of WD8003's which were the
> only NIC's I ever used that could saturate a network. Especially
> running BLASTER.

Well,there was that bug/standards violation in the Lance chips used
by Sun in an era when the were claiming unexpctedly high thoughput on
congested networks. Seems the chip did not wait the full required
silent interval after detecting a collision, thus tending to beat
the non-Sun systems to the punch.

Yes, I know others including DEC used Lance, but somehow Sun was singled
out by the researcher that brought it to light.

George

[seasoned_geek]

On Monday, April 16, 2018 at 1:35:30 AM UTC-5, George Cornelius wrote:
>
> Also have an old Pentium system that I boot off CD (barely), to get to
> Knoppix 3.7 since that's the only thing that still runs on it well
> enough to use for anything. But there is DOS on it, too, as long as
> you don't try to use more than the first 500MB of the HDD.
>

Take a look at
http://www.damnsmalllinux.org/
or for slightly more
https://www.linuxliteos.com/

[hb]

DSL is a Live CD with a size of 50 MB. But it seems DSL is no longer
maintained. The last version is from 2008.

Linux Lite is current: 3.8 32bit - 1st February, 2018, you need a DVD:
SIZE: 1.1GB - DVD.

Maybe TCL, Tiny Core Linux (http://www.tinycorelinux.net) is an option.
It is current: linux kernel version 4.14.10, size is about 16 MB. You
need a network connection to add/download (more) applications. And you
can get it remastered with the ods5 kernel module, about 18 MB
(http://www.vms2linux.de/ods5fs.html)

[seasoned_geek]

On Sunday, April 8, 2018 at 7:12:47 PM UTC-5, Arne Vajhøj wrote:
> Really good story.
>
> Only problem is that it has nothing to do with reality.
>
> Newer Android versions run on Linux kernel 4.4 or newer.
>
> That is from 2016 - not ancient.
>
> And far ahead of various Linux server distros. RHEL 7 is
> still on 3.10 and I believe SUSE 12 is still on 3.12.

Oh, it has a lot to do with reality, it's just that you never venture into that universe.

Android Version |API Level |Linux Kernel in AOSP
----------------------------------------------------
1.5 Cupcake |3 |2.6.27
1.6 Donut |4 |2.6.29
2.0/1 Eclair |5-7 |2.6.29
2.2.x Froyo |8 |2.6.32
2.3.x Gingerbread |9, 10 |2.6.35
3.x.x Honeycomb |11-13 |2.6.36
4.0.x Ice Cream San|14, 15 |3.0.1
4.1.x Jelly Bean |16 |3.0.31
4.2.x Jelly Bean |17 |3.4.0
4.3 Jelly Bean |18 |3.4.39
4.4 Kit Kat |19, 20 |3.10
5.x Lollipop |21, 22 |3.16.1
6.0 Marshmallow |23 |3.18.10
7.0 Nougat |24 |4.4.1
7.1 Nougat |25 |4.4.1
8.0 Oreo |26 |4.10

https://www.walmart.com/search/?query=rca%20viking%20pro%2010.1%202-in-1%20tablet%2032gb%20quad%20core&typeahead=rca
Wamart selling RCA tablets en-masse to parents for school kids running Marshmellow now but no way to actually upgrade. The ones sold last year had much older version.

https://www.walmart.com/ip/Refurbished-Samsung-Galaxy-Tab-3-Lite-with-WiFi-7-Touchscreen-Tablet-PC-Featuring-Android-4-2-Jelly-Bean-Operating-System/54203939
Galaxy Tablets still for sale running Jelly Bean

https://arstechnica.com/gadgets/2014/12/android-2-3-gingerbread-four-years-later-the-os-just-wont-die/
Good article about all of the Gingerbread devices still out there.

A 2016 article about how only 7.5% of Android devices were running Marshmellow
https://www.theverge.com/circuitbreaker/2016/5/4/11589630/android-6-marshmallow-os-distribution-statistics

https://www.themobileindian.com/news/android-80-oreo-only-running-on-03-percent-of-devices-marshmallow-still-dominant-19828
November 2017 article showing Oreo with only a 0.3 percent adoption rate.

For most devices there is no OS upgrade path. As explained in so many articles around the Web, the hardware requirements make flashing a new OS impossible for many devices.

Hey, let's not leave eBay out. Refurbished Android Donut phones are for sale.
https://www.ebay.com/itm/Sony-Ericsson-Xperia-X10-mini-E10-E10i-Android-Phone-2-5-TouchScreen-3G-GPS-5MP/162811778604?epid=1900379113&hash=item25e856962c:m:m5Zts85a4lexg2Rusf9ZtoQ

And Garmin phones.
https://www.ebay.com/itm/Garmin-Asus-Garminfone-A50-Black-T-Mobile-GPS-CELL-PHONE/222912321433?hash=item33e69c1799:g:lpcAAOSwnklauIZY

As I scroll through the search results I see hundreds of these things for sale. Hard to get an accurate count since many have "more than 10 available" in their listing.

Instead of existing in the useless academic world postulating "Consider a spherical cow" why not venture out into reality? You could learn a lot.

https://en.wikipedia.org/wiki/Spherical_cow

This "oh they have to upgrade to the latest and greatest" is a completely fraudulent position. The people in this market are just buying a phone or tablet. They don't have money for forced hardware upgrades due to colleges turning out incompetent script kiddies hacking on the fly without any real plan and calling it AGILE.

Most of them have learned the really cheap Consumer Cellular Doro flip phones don't take a lot of abuse. As of right now they can get a Sonim XP3410 Strike for $10 with free shipping on eBay.

https://www.ebay.com/itm/Sonim-XP3410-Strike-Sprint-Waterproof-Rugged-PTT-Cell-Phone/273012733525?hash=item3f90d3b655:g:o28AAOSwODFaT926:sc:USPSFirstClass!60959!US!-1

Then they can get a pay as you go SIM card and have what they wanted, A BASIC PHONE. You will note that seller makes no mention of the OS, so a buyer would have to be tech savy enough to look that up elsewhere. Not generally, the people in this market.

If they are willing to drop $20 they can get a rugged Sonim XP1520 Bolt.

https://www.ebay.com/itm/UNLOCKED-SONIM-XP1520-BOLT-SPRINT-CELL-PHONE-GPS-BLUETOOTH-BLACK-SCORCHING/323205438894?epid=12017974194&hash=item4b408b9dae:g:05IAAOSwjp5az6u~

Personally, I picked one of these up and a just over $30 4G bigger brother. When AT&T gets around to shutting down their 3G service to make room for 5G I can move my SIM to the 4G phone without issue.

Reality: Many people in this market gave up their rotary phone when the phone company knocked on their door to install a touch-tone phone. It isn't a computer to them, IT'S A PHONE. They use it to make phone calls. To them it is not a wowsy woo-woo tech toy compelling them to spend relentless amounts of money getting the latest and greatest.

Reality: Academia has failed the human species.

They churn out worthless graduates who churn out bug riddled basic services devices which have no idiot proof upgrade path and Keller MBAs push such things onto the market.

Reality: many aunts, uncles and grandparents inherit this old tech from their young relatives. Others are forced into buying it because they only have $50 to spend for both the phone and the service.

Reality: The best selling phones with the largest installed bases aren't idiot phones. Here's two of the top phones:

https://www.consumercellular.com/Products?flip

and here is the other

https://www.jitterbugdirect.com/

Basically, the phones associated with AARP plans.
http://www.cellularphoneplansforseniors.com/2015/06/aarp-cell-phone-service.html

Unless there is a plague or another weaponized flu strain, by 2030 the last of the baby boomers will hit 65.
https://www.ioaging.org/aging-in-america

The over 50 crowd isn't a "get me the latest toy to play with" crowd. Most don't think of an idiot phone as anything other than a phone, certainly not a computer.

Universities are committing a crime against the human species by churning out worthless script kiddies and even more worthless Keller MBAs, teaching all to look no farther ahead than the end of the current AGILE sprint.

[seasoned_geek]

On Sunday, April 8, 2018 at 11:59:32 AM UTC-5, DaveFroble wrote:
>
> All I can say is that it's working quite well with many transactions per second.
>

I suspect that is because you are using the $QIO interface and I'm using the C library.

[DaveFroble]

Then, why are you doing that?

You need QIO examples, just ask ...

[seasoned_geek]

On Sunday, April 22, 2018 at 4:13:51 PM UTC-5, DaveFroble wrote:
> seasoned_geek wrote:
> > On Sunday, April 8, 2018 at 11:59:32 AM UTC-5, DaveFroble wrote:
> >> All I can say is that it's working quite well with many transactions per second.
> >>
> >
> > I suspect that is because you are using the $QIO interface and I'm using the C library.
>
> Then, why are you doing that?
>
> You need QIO examples, just ask ...
>

LOL . . . Because the C API is ___supposed___ to work and $QIO is ___supposed___ to be a no-no for TCP/IP. Everything has been working for a while now, just waiting on a final blessing.

[Robert A. Brooks]

What does "...$QIO is supposed to be a no-no for TCP/IP." mean?

Is that documented some place?

--
-- Rob

[DaveFroble]

seasoned_geek wrote:
> On Sunday, April 22, 2018 at 4:13:51 PM UTC-5, DaveFroble wrote:
>> seasoned_geek wrote:
>>> On Sunday, April 8, 2018 at 11:59:32 AM UTC-5, DaveFroble wrote:
>>>> All I can say is that it's working quite well with many transactions per second.
>>>>
>>> I suspect that is because you are using the $QIO interface and I'm using the C library.
>> Then, why are you doing that?
>>
>> You need QIO examples, just ask ...
>>
>
> LOL . . . Because the C API is ___supposed___ to work and $QIO is ___supposed___ to be a no-no for TCP/IP. Everything has been working for a while now, just waiting on a final blessing.

It's my understanding that the C API is implemented using the QIO interface.
So, why would you want to clutter things up with the C API as an extra layer of
overhead?

[seasoned_geek]

On Sunday, April 22, 2018 at 9:31:03 PM UTC-5, DaveFroble wrote:
>
> It's my understanding that the C API is implemented using the QIO interface.
> So, why would you want to clutter things up with the C API as an extra layer of
> overhead?

Because the entire program is in C so utilizing $QIO directly would be cluttering things up. Had it been COBOL or BASIC, then $QIO would be the primary choice if one didn't want to jump through the hoops of calling a C library from those languages.

[seasoned_geek]

On Sunday, April 22, 2018 at 6:56:27 PM UTC-5, Robert A. Brooks wrote:
>
> What does "...$QIO is supposed to be a no-no for TCP/IP." mean?
>
> Is that documented some place?

When writing programs in C/C++ which could be ported to other platforms utilizing platform specific calls is a no-no. It's the same no-no as including inline assembly and a host of other things. There are many many posts and books written on the topic. Here is one well received post:

https://www.codeproject.com/articles/5587/writing-portable-code-in-c

There are an entire slew of regular C/C++ coding practices which are no-nos from this perspective. One of the most common and simple examples is the sizeof() compiler directive. You will find oceans of non-portable C code which do the following:

int x = sizeof(something);

An int will kinda-sortof work on many platforms, but one is supposed to use size_t for the data type because using an int won't always work and it leads to some very difficult to track down bugs.

Another simple example one will find all over the place is

char *ptr = 0;
char *ptr2 = NULL;

For a very long time we _had_ to do this. Now it is bad practice and later C standards introduced nullptr. Why? Because a 0 didn't always work on all platforms and the NULL macro had various definitions over the years.

https://stackoverflow.com/questions/18781514/correct-way-of-defining-null-and-null-pointer

That link is probably not the best one, but I didn't put a lot of time into the search. The comment with an up-count of 4 must have been made by someone older than the kids normally on stack overflow. When people "knew" NULL was defined to be 0 they would code things like:

char c = NULL;

to get a zero value character. When that code was compiled on a compiler which defined NULL as a void * 0 it would "sometimes" work but not if the platform didn't have a special value for NULL. If you wish to go down the rabbit hole,

https://retrocomputing.stackexchange.com/questions/5671/the-history-of-the-null-pointer

Not a bad discussion. Pay close attention to the comments about IBM mainframes and big endian machines. Some platforms were only capable of even boundary addressing, so a NULL was an add address which would throw a TRAP or other exception if utilized. Such a TRAP would occur no matter what priv level the program was being executed under.

I don't personally know/have proof about 0, but, if you are executing on VMS with the privs of a God not yet born you can thump values into memory waaaaaaaaaaaaaaay outside of your program space and get nary a complaint from the OS.

Sorry for the long winded response, but I was in writing mode this morning and still haven't spun out of it completely.

Do I know if there is "official" VMS prohibition documented in the doc, release note, customer letter, or comment in a header file in SYS$EXAMPLES? No. There is documentation in the C programming world about utilizing platform specific APIs which are not cordoned off in a wrapper if you wish to have any prayer of porting.

Maybe Dave is correct and the standard C API really is a wrapper for the $QIO stuff and it is poorly done causing our different experiences? I don't know.

Is the $QIO API for TCP/IP going to survive in the x86 port of VMS? I don't know.

Is the C API for TCP/IP going to survive in the x86 port of VMS? Has to otherwise a world of code written for many platforms could never be migrated to VMS.

Just my 0.000002 cents.

[Stephen Hoffman]

In the VSI OpenVMS docs? No. Of course not.

For developers and particularly those folks who have to contend with
anything from the remote possibility of to the likelihood that the
source code under development will need to be cross-platform and/or
will need to be ported, $qio and $io_perform usage is rather less than
desirable and — when its usage is necessary — something that's best
isolated in the source code.

The morass that is the OpenVMS implementation of C (including the
utterly inexplicable and on-going division between OpenVMS and IP) and
the RMS I/O mapping on OpenVMS, in aggregate effectively either
encourages or various requires the use of "extensions" or the use of
knobs such as the decc$ logical names or the use of $qio / $io_perform
and KP threads or ASTs and other platform-specific APIs. That's
irrespective of any discussions of conflicting motivations and
incentives. There are obvious incentives to VSI to continue to provide
and to continue to encourage platform-specific API usage among
developers, too.

There've been chunks of that TCP/IP Services $qio API and examples that
have been less-than-robustly documented, too. (I've not tried
$io_perform with that API, nor have I encountered any apps using that
"new" I/O API with TCP/IP Services API.) And most (all?) network
connections will want either TLS or IPsec.

Then there's the whole discussion of frameworks and higher-level
abstractions and APIs and docs for networking, and discussions of the
utter and unmitigated joy of mixing $qio or $io_perform with TLS. Or
$qio and IPv6. As for docs...
http://h41379.www4.hpe.com/doc/83final/ba554_90007/ch04s03.html —
ponder the lack of error handling in that, or the lack of certificate
pinning and certificate verification, or other related details of a
client-server design that were ignored. That, and how much work is
involved, and how many bugs can be introduced given the low-level
nature of that API. Want to add new platform-specific APIs and
frameworks that might interest developers? Make writing secure apps
far easier, with compiler and tool support that makes finding and
fixing flaws easier, and with run-time support that seeks to isolate
and constrain the damage from potential vulnerabilities. (These
approaches and tools and frameworks are not fiction I'm discussing
here, either. These all already exist, and are already in use
elsewhere.)

Then there's that the whole API design and documentation
design-philosophical discussion; around how all that is now utterly
backwards around IPv6. IPv6 is and should be the default and preferred
path for most currently-maintained apps and for most new work on
OpenVMS, and the doc and APIs and examples all have that effectively
reversed with the "IO$M_EXTEND" implementation. IPv4 has become the
"constrained" path, whether it's $qio or $io_perform or the socket
libraries or otherwise.

The upcoming VSI IP fork of Multinet will address some of these issues.
Others will remain. And there'll undoubtedly be some churn porting
apps to VSI IP fork of Multinet, too.





--
Pure Personal Opinion | HoffmanLabs LLC

[seasoned_geek]

LOL

It's nice to see you get in touch with your "inner Bill" once in a while Hoff.

No, not any Bill here. A cranky old guy I worked with on a project out in the land that even Canada wouldn't take. I kept telling him "if I wanted to work with an angry cussing sailor I would have stayed at home with my dad."

Yes, IPv6 probably "should" be a default, but on at least one recent program I did it with IPv4 because it wasn't worth swimming through the septic tank to make IPv6 work. There was a legitimate reason, but I would have to look at the code to remember.

[Arne Vajhøj]

On 4/23/2018 11:43 AM, seasoned_geek wrote:
> char *ptr2 = NULL;
>
> For a very long time we _had_ to do this. Now it is bad practice and later C standards introduced nullptr.

The later C standard called C++ 11?

:-)

Arne

[seasoned_geek]

Obviously you haven't written C on OpenVMS lately. The current C compiler is a downgrade to what I had installed. This version has pieces of C99 stubbed out, without reserving words which were stubbed. Other segments aren't touched at all while a token few portions of the standard were actually implemented.

Had the current C compiler been placed in a charred oak barrel upon its release, it would be some mighty fine sipping whiskey by now.

Not that I read every message in here, but the last blurb I read about the C compiler for the x86 port is that it "might" finish off the C99 standard, leaving C11 __still__ a later standard which means the new style for() loop which mimics the Qt foreach() loop [sans the object copy] will be out of reach for years to come.

[John Reagan]

Can you tell me what parts that the compiler is missing? My understanding is that the compiler conforms. The RTL on the other hand is missing some headers (stdint.h in particular), a bunch of things are missing from inttypes.h, and there are missing printf/scanf options. Plus a bunch of bugs...

Since we're using clang as the C++ compiler on x86, you should be able to run clang in C11 mode to get yourself a nice C11 compiler. We'll have to do further work on the RTLs of course.

[seasoned_geek]

When you read through the header files and find the comments of all the things which are stubbed and missing it is really difficult to say the compiler is complete. At a minimum it should be throwing compilation warnings rather than just merrily NOP the missing stuff leaving it for a developer to debug _into_ the RTL to find out what is wrong.

At this point I wish I had kept a list because I ran into at least half a dozen things which compiled clean and successfully linked to a pile of nothing needlessly extending development time.

If the same approach is being taken with clang on the x86, it too will be a downgrade. It is far better to have a __complete__ compiler at a lower level than have something with lots of stuff stubbed out introducing errors in the program. In short your clang compiler has to know about everything which isn't actually implemented and throw warnings/errors if used.

[John Reagan]

This is news to me. You will easily notice the lack of <stdint.h> or any of the C99 macros missing from <inttypes.h> like INT32_C, PRI prefix macros, etc at compile-time. The only things I know if are the missing printf/scanf modifiers that will be unrecognized by the RTL and ignored/flagged. I've slogged through most of the CRTL in the past several years looking at things for planning. I don't remember anything stubbed out (doesn't mean things aren't totally missing).

Our internal tables have a "is_C99" flag the RTL knows which routines (like many floating routines) were "Digital extensions to C89 but turned into standard for C99". Depending on the setting of /STANDARD=C89 vs /STANDARD=C99, the headers will define them as appropriate.

Besides a whole raft of bugs in the RTL (not adhering to POSIX or other defacto standards, filename issues, missing interfaces, more versions of stat() can you can count, etc), I don't know of many C99-related issues beyond the ones I mentioned.

So if you ever find your notes, I'd appreciate seeing them.

[seasoned_geek]

On Thursday, May 3, 2018 at 12:23:23 PM UTC-5, John Reagan wrote:

>
> So if you ever find your notes, I'd appreciate seeing them.

There were over half a dozen, but I'm working on another platform and that machine is turned off.

One of the huge issues is the string library doesn't treat signed and unsigned char pointers as the same, but I forget if that is 99 or 11.

With much luck I won't have to use that compiler again for a loooooooooooooooooong time, if ever.

[Arne Vajhøj]

On 5/2/2018 5:37 PM, seasoned_geek wrote:
> On Sunday, April 29, 2018 at 7:56:12 PM UTC-5, Arne Vajhøj wrote:
>> On 4/23/2018 11:43 AM, seasoned_geek wrote:
>>> char *ptr2 = NULL;
>>>
>>> For a very long time we _had_ to do this. Now it is bad practice and later C standards introduced nullptr.
>>
>> The later C standard called C++ 11?
>>
>> :-)
>>
>
> Obviously you haven't written C on OpenVMS lately.

December.

> The current C compiler is a downgrade to what I had installed. This
> version has pieces of C99 stubbed out, without reserving words which
> were stubbed. Other segments aren't touched at all while a token few
> portions of the standard were actually implemented.
>
> Had the current C compiler been placed in a charred oak barrel upon
> its release, it would be some mighty fine sipping whiskey by now.

It is not up to latest standard. Hopefully it will eventually get there.

But I don't see what relevance when I last used C on VMS and the state
of current VMS C compiler has for the point:

nullptr is a C++ thing - not a C thing

Arne

[Arne Vajhøj]

On 4/23/2018 6:32 PM, seasoned_geek wrote:
> Yes, IPv6 probably "should" be a default, but on at least one recent
> program I did it with IPv4 because it wasn't worth swimming through
> the septic tank to make IPv6 work. There was a legitimate reason, but
> I would have to look at the code to remember.

Good socket code work with both IPv4 and IPv6 without changes.

Arne

[seasoned_geek]

Arne = know nothing yet speak profusely.

[Stephen Hoffman]

Ayup. That works fine across IPv4 and IPv6. TLS and DTLS above that
gets gnarly, in terms of the complexity of the APIs and the sorts of
examples available, and given the problematic implementation of TLS and
certificates on OpenVMS.

[seasoned_geek]

Correct. when you are at the academic "consider a spherical cow" stage of development

https://en.wikipedia.org/wiki/File:Spot_the_cow.gif

it's all pure and wonderful. If OpenVMS implemented a TCPIP Software Appliance like IBM and Unisys appear to be doing, one wouldn't even know.

The baby goes out with the bathwater as soon as you start having to needlessly shoehorn transport layer security WITH RETRY and RECONNECT logic because now you have to carry an awful lot of luggage. The vintage of the C compiler adds insult to injury.

[Hans Vlems]

I do wish you’d stop that. The statement is not true
and reduces all your other comments to the same
quality level. Besides, this is c.o.v. And such conduct is not appreciated.
Hans

[Bill Gunshannon]

There is an answer. Killfile him and return sanity to the group.

And Dave thinks I am a troll.

bill

[seasoned_geek]

I will ass-u-me you were talking to me but you didn't quote anything, so I have to ask, which statement is not true?

When one is at the academic "consider a spherical cow" stage of development IPv4 and IPv6 is all unicorns and rainbows.

https://en.wikipedia.org/wiki/File:Spot_the_cow.gif

When you have to needlessly shoehorn in transport layer security WITH RETRY and RECONNECT logic, you end up carrying an enormous amount of luggage around. Information from configuration files which should only exist at startup has to be saved within the application and re-used repeatedly.

The vintage of the C compiler does add insult to injury. All of the examples you can find from other platforms use features you don't have. In a recent project I had to thieve many GNU strutil source files and spend a few days getting them to both compile and work in this environment just to have the "basic" string functionality needed for a project.

Or were you doubting Hoff who has ported/written far more IP code than anyone I know? If so, don't take his or my word for it. You can explore that particular mystery of life yourself.

https://github.com/rsyslog/rsyslog

There's the repo for rsyslog. Try pulling it down and porting it to VMS. Allocate way more than two months of your time and don't cheat by coding it for IPv6 only. After you get to the two month mark you will find they use an unbelievably large amount of GNU code to do transport layer stuff so that has to be ported too. Guess what? It relies on a lot of those string utilities we don't have.

If you want to have a much more effective complaint tell Arne to never respond to any of my messages or threads. I've told him myself and he doesn't listen. I've seen him here for years. He always tries to veer a discussion off into some academic weeds which have absolutely ___nothing___ to do with the actual topic of discussion. Personally and professionally I have less than zero respect for him.

[Stephen Hoffman]

On 2018-05-04 18:41:51 +0000, seasoned_geek said:

> When you have to needlessly shoehorn in transport layer security WITH
> RETRY and RECONNECT logic, you end up carrying an enormous amount of
> luggage around.

Most folks are already using IPv4 and IPv6 everywhere, it's the old
code that's not caught up yet.

As compared with IPsec et al, TLS and DTLS and the whole certificate
mess exists for a reason. If everybody is running IPsec-capable
end-points and the rest and if the links can be pre-defined, then sure,
point-to-point host-to-trusted-host connections will work.

I'm only rarely working in that world anymore, and the few times I have
those pre-defined links I also have ad-hoc links around and which means
that TLS and DTLS might as well be used everywhere.

I'm also finding it less desirable to trust the whole host or to trust
the whole app for that matter, but that's a trend and a preference
that's not yet commonly arrived on OpenVMS; containers and sandboxing,
Intel SGX support, etc. Within a few years after the x86-64 port is
available and stable, some OpenVMS folks will begin to realize they
don't trust some of the hosts they're now running their OpenVMS apps on.

Related:
https://asylo.dev/blog/2018/announcing-asylo.html
https://github.com/intel/intel-sgx-ssl

But again, most of the apps aren't in a world where all end-points are
known, or where links can be pre-established, or where everybody has
IPsec-capable end-points. For those cases that are, bully. Where the
links are not pre-defined, TLS and DLTS are what we have. Which could
be and should be better of course, whether its an OpenVMS framework
atop OpenSSL (descriptors, ease of use, etc) or if it's libtls and
jackets, or otherwise.

> Information from configuration files which should only exist at startup
> has to be saved within the application and re-used repeatedly.

The OpenVMS implementation of application configuration files is not
competitive. The contents and processing of the config files are
inherently app-specific.

As a specific example of the problem with OpenVMS apps and
configuration data, may I present...

http://h41379.www4.hpe.com/doc/732final/5763/5763pro_004.html
Mail and DEC notes and AUTHORIZE and a whole pile of other OpenVMS apps, too.

That's far from the only example, and other OpenVMS and LP and ISV and
customer apps all have their own bespoke designs, and there's the
endemic use of logical names for purposes exceedingly ill-suited.

Tools such as yaml configuration data stores and serialization, and
stores such as ldap are our friends now, whether the yaml processing
and ldap are all running entirely locally and/or app-specific, or if
ldap is running multi-host. I'll leave aside discussions of the image
activator and of app bundles and packaging.

> The vintage of the C compiler does add insult to injury. All of the
> examples you can find from other platforms use features you don't have.
> In a recent project I had to thieve many GNU strutil source files and
> spend a few days getting them to both compile and work in this
> environment just to have the "basic" string functionality needed for a
> project.

Yeah, the open-source clang port will help with C support. Porting
and then replacing and then retiring the existing C RTL will help, too.
Whether it's based on llvm libc or musl libc or otherwise, or some
newly-constructed environment built from the wreckage of the existing C
RTL. And we're long past when it's reasonable that the IP API be
separately partitioned and installed. select() has been broken for
decades.

JR is already aware of various missing string routines.

[DaveFroble]

Only because you keep claiming things without any proof, or facts, or ...

If it's opinion, say so. That's fine.

[DaveFroble]

Well, if you didn't make the mistake of using C ....

:-)

[Arne Vajhøj]

On 5/4/2018 12:06 PM, Stephen Hoffman wrote:
> On 2018-05-04 01:38:00 +0000, Arne Vajh j said:
>> On 4/23/2018 6:32 PM, seasoned_geek wrote:
>>> Yes, IPv6 probably "should" be a default, but on at least one recent
>>> program I did it with IPv4 because it wasn't worth swimming through
>>> the septic tank to make IPv6 work. There was a legitimate reason, but
>>> I would have to look at the code to remember.
>> Good socket code work with both IPv4 and IPv6 without changes.
>
> Ayup.  That works fine across IPv4 and IPv6.

Which was my point.

>   TLS and DTLS above that
> gets gnarly, in terms of the complexity of the APIs and the sorts of
> examples available, and given the problematic implementation of TLS and
> certificates on OpenVMS.

[speaking only about TLS as I have never looked into DTLS]

I think it somewhat depends on the language.

Java is relative OK as javax.net.ssl.SSLSocket extends
java.net.Socket, so you can just give whatever code that
expects a Socket a SslSocket and it will work.

And if a good DI framework is used then setting it all up
becomes configuration not code.

.NET is doing something similar just at a different place
as System.Net.Security.SslStream and System.Net.Sockets.NetworkStream
both extends System.IO.Stream. Of course .NET is not available for VMS.

C has a problem as standard socket API and OpenSSL SSL functions are
all different.

OpenSSL does have a go forward solution as BIO functions provide an
abstraction for both plain sockets and SSL sockets, but no old code
will be using that.

And I do not even want to think about how Pascal/Basic/Fortran/Cobol
would do SSL via SYS$QIO(W).

Arne

[Arne Vajhøj]

On 5/6/2018 9:18 PM, Arne Vajhøj wrote:
> On 5/4/2018 12:06 PM, Stephen Hoffman wrote:
>>                                              TLS and DTLS above that
>> gets gnarly, in terms of the complexity of the APIs and the sorts of
>> examples available, and given the problematic implementation of TLS
>> and certificates on OpenVMS.
>
> [speaking only about TLS as I have never looked into DTLS]
>
> I think it somewhat depends on the language.
>
> Java is relative OK as javax.net.ssl.SSLSocket extends
> java.net.Socket, so you can just give whatever code that
> expects a Socket a SslSocket and it will work.
>
> And if a good DI framework is used then setting it all up
> becomes configuration not code.

And to elaborate a bit.

If you have code like:

public void doSomething(Socket s) {
...
}
...
Socket s = new Socket("somehost", 12345);
doSomething(s);

then switching to SSL is just:

public void doSomething(Socket s) {
...
}
...
SSLContext sslctx = SSLContext.getInstance("TLSv12");
sslctx.init(null, new X509TrustManager[] { someTrustManager }, null);
SSLSocket s = (SSLSocket)
sslctx.getSocketFactory().createSocket("somehost", 12345);
s.setEnabledProtocols(new String[] { "TLSv12" });
doSomething(s);

no changes in the doSomething code.

And when changing the code then the smarter version is:

public void doSomething(Socket s) {
...
}
...
ApplicationContext ctx = new FileSystemXmlApplicationContext("testdi.xml");
Socket s = (Socket)ctx.getBean("mysocket");
doSomething(s);

and then use testdi.xml to define whether to use plain
or SSL sockets.

<?xml version = "1.0" encoding = "UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.
xsd">
<bean id="mysocket" class="dk.vajhoej.di.PlainSocketFactoryBean">
<property name="host" value="somehost"/>
<property name="port" value="12345"/>
</bean>
</beans>

vs:

<?xml version = "1.0" encoding = "UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.
xsd">
<bean id="mysocket" class="dk.vajhoej.di.SslSocketFactoryBean">
<property name="host" value="somehost"/>
<property name="port" value="12345"/>
<property name="protocol" value="TLSv1.2"/>
<property name="trustManager" ref="TrustAll"/>
</bean>
<bean id="TrustAll" class="dk.vajhoej.di.TrustAllTrustManager"/>
</beans>

And there is not much magic in the dk.vajhoej.di classes - they
are total trivial - see fragments below.

Arne

public class PlainSocketFactoryBean implements FactoryBean<Socket> {
private String host;
private int port;
public String getHost() {
return host;
}
public void setHost(String host) {
this.host = host;
}
public int getPort() {
return port;
}
public void setPort(int port) {
this.port = port;
}
@Override
public Socket getObject() throws Exception {
return new Socket(host, port);
}
@Override
public Class<?> getObjectType() {
return Socket.class;
}
@Override
public boolean isSingleton() {
return false;
}
}

public class SslSocketFactoryBean implements FactoryBean<Socket> {
private String host;
private int port;
private String protocol;
private X509TrustManager trustManager;
public String getHost() {
return host;
}
public void setHost(String host) {
this.host = host;
}
public int getPort() {
return port;
}
public void setPort(int port) {
this.port = port;
}
public String getProtocol() {
return protocol;
}
public void setProtocol(String protocol) {
this.protocol = protocol;
}
public X509TrustManager getTrustManager() {
return trustManager;
}
public void setTrustManager(X509TrustManager trustManager) {
this.trustManager = trustManager;
}
@Override
public Socket getObject() throws Exception {
SSLContext sslctx = SSLContext.getInstance(protocol);
sslctx.init(null, new X509TrustManager[] { trustManager }, null);
SSLSocket s = (SSLSocket) sslctx.getSocketFactory().createSocket(host,
port);
s.setEnabledProtocols(new String[] { protocol });
return s;
}
@Override
public Class<?> getObjectType() {
return Socket.class;
}
@Override
public boolean isSingleton() {
return false;
}
}

public class TrustAllTrustManager implements X509TrustManager
{
public void checkClientTrusted(X509Certificate[] chain, String
authType) {
}
public void checkServerTrusted(X509Certificate[] chain, String
authType) {
}
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
}