Discussion:
OpenVMS Development Annoyances
(too old to reply)
Stephen Hoffman
2019-02-08 16:08:30 UTC
Permalink
Things about developing for OpenVMS that have annoyed me (again) this month:

There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.

There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.

There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons. And the system service API follows the usual OpenVMS
model of glorious flexibility at the cost of simplicity and ease of use
for common tasks.

Itemlists. Did I mention itemlists? I dislike itemlists. Passing
arguments in hand-rolled data structures is far too reminiscent of
writing assembler code. And about as tedious and as voluminous. And
then there's the lack of a parser. And the lack of language support.
Descriptor support is only marginally better than itemlist support,
outside of BASIC and whichever other languages where it's been
integrated. But itemlists haven't been integrated anywhere.

Logging. Like storing preferences, there's no single way to do this,
and which means that everybody does it differently. And there's bupkis
for collecting logging data and app crash data from multiple OpenVMS
servers. Yes, I know from syslog, syslog-ng, and ilk.

On-going grumbles including inadequate development tooling and
inadequate compilers and crash-handling and patch-handling also all
apply.

The results of these limits for app developers? App tooling that is a
fraction of what it can and should be, and apps that tend to be
brittle, and apps that take longer than they should to develop and to
test.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2019-02-08 18:52:54 UTC
Permalink
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
That's ok. Just create your own application specific logical name table
and keep all the logicals together in one location. :-)

In some ways, using a custom logical name table is just like creating
a preferences file. :-)

On a more serious note, I agree. This is exactly the kind of thing which
is missing from VMS and it's also the kind of thing which is easy to
backport to older VMS versions to encourage quicker uptake.
Post by Stephen Hoffman
There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.
What exactly do you need from a job scheduler ?

This is something that can cover a wide range of functionality.

To put it another way, if you were trying to solve whatever your current
problem is on Linux, exactly what Linux based job scheduler tool would
you use and why ?
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons. And the system service API follows the usual OpenVMS
model of glorious flexibility at the cost of simplicity and ease of use
for common tasks.
What do you need here ? Is it purely a single flow of execution type
situation with manual polling of lock state changes or do you need
some type of async event based notification mechanism ?

If the latter, this should be something more generic if possible as
there are other possible uses for async event notification such as
timer expiry.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2019-02-08 21:58:02 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
That's ok. Just create your own application specific logical name table
and keep all the logicals together in one location. :-)
My preferred goal would be to avoid creating ever-larger piles of
manure, and app designs using logical names for the storage of
configuration data are usually some of the more fragrant designs
available.
Post by Simon Clubley
In some ways, using a custom logical name table is just like creating a
preferences file. :-)
If by "in some ways" you mean "not at all", sure.
Post by Simon Clubley
On a more serious note, I agree. This is exactly the kind of thing
which is missing from VMS and it's also the kind of thing which is easy
to backport to older VMS versions to encourage quicker uptake.
For file-based settings, yes. And it might be back-portable with
minimal effort, though I'd rather see VSI go for a somewhat faster
release cycle and to not encourage sitting on older releases. SaaS, et
al.

There are add-on libraries that can be useful for configuration data,
if I want to roll in another dependency. (And if I want to back-port
the tools to older C and C++ standards.) These preferences and related
support APIs and commands are baked into other platforms I work with.

Some other obvious parts of the work involved here are not going to
backport that easily though, and particularly if modifications to the
image activator and the linker are involved and as would be the case
for a replacement for those blasted DECC$ logical names. That for
storing and reading the settings, if they're image-embedded or are
stored in a parallel file. This all eventually and inevitably also
gets twisted together with cryptographically-signed images and related
details.
Post by Simon Clubley
Post by Stephen Hoffman
There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.
What exactly do you need from a job scheduler ?
I'd like to have a way to register an app for startup, and to register
callbacks when the app tips over, to automatically try a few restarts
but avoid a crash-loop, to collect failure-related data, and a way to
check if a certain app is running via API and via shell. And I'd
prefer to not to poll process names. Fairly standard stuff. Is it
running? Why not? Can it restart? Can I get a notification when some
part of production tips over? Where do I send my run-time logs, and my
error-, failure-, and event-related logging?
Post by Simon Clubley
This is something that can cover a wide range of functionality.
To put it another way, if you were trying to solve whatever your
current problem is on Linux, exactly what Linux based job scheduler
tool would you use and why ?
DECscheduler was a decent choice, though the command interface was a
little weird.

On macOS, launchd and XPC, most likely. Which are limited and the
launchd plist user interface is all kinds of ugly, but it's still
better than what I'm dealing with on OpenVMS.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/Introduction.html#//apple_ref/doc/uid/10000172i-SW1-SW1


I don't need something of the scale of JobScheduler.

That tools like cron and periodic might be equivalent and sometimes
superior to what OpenVMS offers is... troubling.
Post by Simon Clubley
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons. And the system service API follows the usual OpenVMS
model of glorious flexibility at the cost of simplicity and ease of use
for common tasks.
What do you need here ? Is it purely a single flow of execution type
situation with manual polling of lock state changes or do you need some
type of async event based notification mechanism ?
I'd preferably be looking for a way to register an app startup and
preferably without having to edit some startup file somewhere, and
synch / polling checks for process existence from DCL and with an app
API, and asynch notifications of failed processes that can trigger
specific and configurable actions, and an
intentionally-limited-to-avoid-looping effort to restart a failed app.
And again, I'd rather not scan for process names to detect when a
process fails.
Post by Simon Clubley
If the latter, this should be something more generic if possible as
there are other possible uses for async event notification such as
timer expiry.
I can do all of this using locks and executables and custom DCL of
course, and as I keep getting told. There are additional requirements
involved across non-clustered hosts, though.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2019-02-08 22:04:47 UTC
Permalink
Post by Stephen Hoffman
There's no preferences file API.
There are add-on libraries that can be useful for configuration data, if
I want to roll in another dependency.  (And if I want to back-port the
tools to older C and C++ standards.)  These preferences and related
support APIs and commands are baked into other platforms I work with.
But then you've just added another dependency, in this case an entire
platform. Or in other words, how well do your .plist files from macOS
work on Windows or Linux?
Stephen Hoffman
2019-02-08 22:15:23 UTC
Permalink
Post by Stephen Hoffman
There are add-on libraries that can be useful for configuration data,
if I want to roll in another dependency.  (And if I want to back-port
the tools to older C and C++ standards.) 
Because my alternative is the wonderful task of writing stripped-down
and limited versions of modern APIs and tools—piecemeal—atop atop what
little OpenVMS provides, and using old versions and limited tools for
the task.
Post by Stephen Hoffman
These preferences and related support APIs and commands are baked into
other platforms I work with.
But then you've just added another dependency, in this case an entire platform.
Yes, because my alternative is the wonderful task of writing modern
APIs piecemeal atop atop what little OpenVMS provides, and using
ancient versions and bad tools for the task.
Or in other words, how well do your .plist files from macOS work on
Windows or Linux?
About as well as OpenVMS system services port elsewhere.

But porting launchd and plist support to OpenVMS—or porting one of the
other and more portable preferences-related tools to OpenVMS—would
still be better than what I have on OpenVMS, and as limited and
problematic as such ports would be.

The OpenVMS app and development APIs and tooling is really stuck a
couple of decades back, unfortunately. And it shows.
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2019-02-09 00:35:02 UTC
Permalink
Post by Stephen Hoffman
Post by Stephen Hoffman
There are add-on libraries that can be useful for configuration data,
if I want to roll in another dependency.  (And if I want to back-port
the tools to older C and C++ standards.)
Because my alternative is the wonderful task of writing stripped-down
and limited versions of modern APIs and tools—piecemeal—atop atop what
little OpenVMS provides, and using old versions and limited tools for
the task.
Post by Stephen Hoffman
These preferences and related support APIs and commands are baked
into other platforms I work with.
But then you've just added another dependency, in this case an entire platform.
Yes, because my alternative is the wonderful task of writing modern APIs
piecemeal atop atop what little OpenVMS provides, and using ancient
versions and bad tools for the task.
Or in other words, how well do your .plist files from macOS work on
Windows or Linux?
About as well as OpenVMS system services port elsewhere.
But porting launchd and plist support to OpenVMS—or porting one of the
other and more portable preferences-related tools to OpenVMS—would still
be better than what I have on OpenVMS, and as limited and problematic as
such ports would be.
The OpenVMS app and development APIs and tooling is really stuck a
couple of decades back, unfortunately.  And it shows.
I'm mostly with you on that. Yesterday I had to (once again) create an
stdint.h for a project that assumes it exists for any C99-compliant
environment (specifically __STDC_VERSION__ >= 199901L). In celebration
of the 20th anniversary of C99, I see an item on the VSI roadmap for C99
support improvements in the CRTL sometime next quarter. Can't wait, but
it's a good thing I haven't been holding my breath these last couple of
decades.

But on the subject of preferences APIs, I'm not sure VMS is well-served
by inventing yet another platform-specific solution. java.util.prefs
has been around for ages (since Java 1.4), uses the registry on Windows,
the .plist dictionaries on macOS, and an XML schema on Unix/Linux. Not
sure what it uses on VMS, but since it's part of Java core, there must
be some implementation. Various folks have reimplemented it in C/C++,
so it could form the basis of something more general for non-Java users,
which would of course require a wrapper supporting string descriptors,
which HLL users shouldn't ever see directly.

There is also something to be said for the human readability and
simplicity of ye olde INI file format:

<https://en.wikipedia.org/wiki/INI_file>.

For which there are various portable implementations. As well as things
based on YAML, JSON, etc.

So there are options for VMS, including resurrecting the VMS Registry
facility which no one seems to have ever actually used. Or adopting
something where someone else has already done the hard work. I thought
this one looked interesting and, though I've never used it:

<http://libprf1.tigris.org>
John Reagan
2019-02-09 13:54:13 UTC
Permalink
Post by Craig A. Berry
Post by Stephen Hoffman
Post by Stephen Hoffman
There are add-on libraries that can be useful for configuration data,
if I want to roll in another dependency.  (And if I want to back-port
the tools to older C and C++ standards.)
Because my alternative is the wonderful task of writing stripped-down
and limited versions of modern APIs and tools—piecemeal—atop atop what
little OpenVMS provides, and using old versions and limited tools for
the task.
Post by Stephen Hoffman
These preferences and related support APIs and commands are baked
into other platforms I work with.
But then you've just added another dependency, in this case an entire platform.
Yes, because my alternative is the wonderful task of writing modern APIs
piecemeal atop atop what little OpenVMS provides, and using ancient
versions and bad tools for the task.
Or in other words, how well do your .plist files from macOS work on
Windows or Linux?
About as well as OpenVMS system services port elsewhere.
But porting launchd and plist support to OpenVMS—or porting one of the
other and more portable preferences-related tools to OpenVMS—would still
be better than what I have on OpenVMS, and as limited and problematic as
such ports would be.
The OpenVMS app and development APIs and tooling is really stuck a
couple of decades back, unfortunately.  And it shows.
I'm mostly with you on that. Yesterday I had to (once again) create an
stdint.h for a project that assumes it exists for any C99-compliant
environment (specifically __STDC_VERSION__ >= 199901L). In celebration
of the 20th anniversary of C99, I see an item on the VSI roadmap for C99
support improvements in the CRTL sometime next quarter. Can't wait, but
it's a good thing I haven't been holding my breath these last couple of
decades.
status: I have finished stdint.h, reshuffled inttypes.h, better math.h, fp.h, and float.h in my area. We added support in print/scan for the remaining C99 modifiers (I think hex float isn't there yet). I have somebody working on the required MATH routines (ie, llround, nearbyint, rint, scalbn, scalbln, etc.) Those are the ones that if you try to use today, the compiler will say "I recognize those as C99 routines but the RTLs are missing support". My first cut accidentally introduced C99 names even if you compiled /STANDARD=ANSI (aka C89) so we needed more work.
John Reagan
2019-02-09 14:02:06 UTC
Permalink
Post by Craig A. Berry
But on the subject of preferences APIs, I'm not sure VMS is well-served
by inventing yet another platform-specific solution. java.util.prefs
has been around for ages (since Java 1.4), uses the registry on Windows,
the .plist dictionaries on macOS, and an XML schema on Unix/Linux. Not
sure what it uses on VMS, but since it's part of Java core, there must
be some implementation. Various folks have reimplemented it in C/C++,
so it could form the basis of something more general for non-Java users,
which would of course require a wrapper supporting string descriptors,
which HLL users shouldn't ever see directly.
There is also something to be said for the human readability and
<https://en.wikipedia.org/wiki/INI_file>.
For which there are various portable implementations. As well as things
based on YAML, JSON, etc.
So there are options for VMS, including resurrecting the VMS Registry
facility which no one seems to have ever actually used. Or adopting
something where someone else has already done the hard work. I thought
<http://libprf1.tigris.org>
Lots of utilities already have support for "xxx$INIT" files. I use them with LSE, SHOW CLUSTER, and the like. Not everywhere however.

On my Linux box, I always get confused with the difference in .profile, .bashrc, and .bash_profile.

We've also had requests to add compiler options files to change defaults, but I've resisted that since it just adds "another place" that you have to look besides COM files and makefiles to see how the program is compiled. It is even worse on systems without listing files that record the final command line (on some platforms, you can record that command line inside an ELF .note section - we'll pick up that with LLVM)
Bill Gunshannon
2019-02-09 18:03:01 UTC
Permalink
Post by John Reagan
Post by Craig A. Berry
But on the subject of preferences APIs, I'm not sure VMS is well-served
by inventing yet another platform-specific solution. java.util.prefs
has been around for ages (since Java 1.4), uses the registry on Windows,
the .plist dictionaries on macOS, and an XML schema on Unix/Linux. Not
sure what it uses on VMS, but since it's part of Java core, there must
be some implementation. Various folks have reimplemented it in C/C++,
so it could form the basis of something more general for non-Java users,
which would of course require a wrapper supporting string descriptors,
which HLL users shouldn't ever see directly.
There is also something to be said for the human readability and
<https://en.wikipedia.org/wiki/INI_file>.
For which there are various portable implementations. As well as things
based on YAML, JSON, etc.
So there are options for VMS, including resurrecting the VMS Registry
facility which no one seems to have ever actually used. Or adopting
something where someone else has already done the hard work. I thought
<http://libprf1.tigris.org>
Lots of utilities already have support for "xxx$INIT" files. I use them with LSE, SHOW CLUSTER, and the like. Not everywhere however.
On my Linux box, I always get confused with the difference in .profile, .bashrc, and .bash_profile.
The solution to that is to stop using bash. :-)

Those who do not understand UNIX are condemned to reinvent it -- badly.
Henry Spencer

bill
Stephen Hoffman
2019-02-09 18:04:59 UTC
Permalink
Post by John Reagan
Lots of utilities already have support for "xxx$INIT" files.
How many of those tools did not already have a command parser implemented?

And for those apps that might or would want to allow the user or the
run-time code to apply defaults or change the preferences, how many of
those tools can or do modify the contents of those initialization files?

And how many of those apps with initialization share any consistency in
the syntax and handling of the saved data?

I'd wager the answers to those three questions to be... Zero.
Zero. And.... Zero.

Switching among operating systems doing development work, working on
OpenVMS increasingly reminds me of dropping back to working on RSX-11M
from VAX/VMS, or dropping back to programming in VAX Macro32 assembler
from BASIC or Fortran or C. Sure, it's possible to do what's
necessary, but it's so much more work and more code or more complex
code to get there. Or the resulting OpenVMS apps are so much less than
they can or should be. But I digress.

There's no consistency across these initialization files. And there's
no leveraging of the development effort involved. And for each
re-duplication of effort with these initialization files or other
common tasks developers encounter, what does get developed is a "good
enough" solution that's limited to the immediate problem.

And so we perpetuate hard-coded or hand-rolled or all-around bad
solutions like non-path-related configuration data in logical names.

And logical names got their start to help with these hard-coded
filename path cases. Logical name file redirection is a problem from
the 1970s, and it's a solution that still works for that case. But
it's limited to what's been embedded in RMS and the I/O system, and
dependent on developers knowing how to use default names and filenames
"correctly". And you have to load and manage the logical names—the
underlying key-value store—from somewhere else. It's out-of-band. And
this particular key-value store is volatile.

In this millennium, we're managing apps with various app-specific
configuration data well beyond file paths. Network addresses and
ports, host names when not using the canonical names, network
controllers to be used, control of embedded debugging support, logging
servers, digital certificates and keys and passwords—and the lack of a
keystore for sensitive data is another issue—and other sorts of
app-specific configuration and control data that many of us are now
dealing with. Those that aren't either using the command line and
embedding that in a DCL, or that haven't written a full-on
command-parser, or that haven't, or hardcoding the settings in the apps
and recompiling.

BTW and on the subject of hardcoding stuff into tools and build
procedures, Fortran doesn't seem to have a way to access and control
its preprocessor from the command line, other than semi-related the
/D_LINE stuff. There's no analog to the C and C++ /DEFINE support that
I can locate, short of tweaking that via logical names and include
files or ilk. Or am I missing something here?
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2019-02-09 18:19:39 UTC
Permalink
Post by Stephen Hoffman
BTW and on the subject of hardcoding stuff into tools and build
procedures, Fortran doesn't seem to have a way to access and control
its preprocessor from the command line, other than semi-related the
/D_LINE stuff. There's no analog to the C and C++ /DEFINE support that
I can locate, short of tweaking that via logical names and include
files or ilk. Or am I missing something here?
Not that I can see.
Arne Vajhøj
2019-02-10 01:27:25 UTC
Permalink
Post by John Reagan
Post by Craig A. Berry
But on the subject of preferences APIs, I'm not sure VMS is
well-served by inventing yet another platform-specific solution.
java.util.prefs has been around for ages (since Java 1.4), uses the
registry on Windows, the .plist dictionaries on macOS, and an XML
schema on Unix/Linux. Not sure what it uses on VMS, but since it's
part of Java core, there must be some implementation. Various
folks have reimplemented it in C/C++, so it could form the basis of
something more general for non-Java users, which would of course
require a wrapper supporting string descriptors, which HLL users
shouldn't ever see directly.
There is also something to be said for the human readability and
<https://en.wikipedia.org/wiki/INI_file>.
For which there are various portable implementations. As well as
things based on YAML, JSON, etc.
So there are options for VMS, including resurrecting the VMS
Registry facility which no one seems to have ever actually used.
Or adopting something where someone else has already done the hard
work. I thought this one looked interesting and, though I've never
<http://libprf1.tigris.org>
Lots of utilities already have support for "xxx$INIT" files. I use
them with LSE, SHOW CLUSTER, and the like. Not everywhere however.
I do not consider those doing the same as a preference framework.

VMS INIT files contains commands in application specific
language and the application load and execute those commands
before starting processing whatever it needs to process.

A preference framework allow applications to retrieve
single primitive values (usually with hierarchical key structure
and usually in a type safe way) and then the application
code use those values to do whatever.

Arne
Craig A. Berry
2019-02-10 03:08:11 UTC
Permalink
Post by Arne Vajhøj
Post by Craig A. Berry
But on the subject of preferences APIs, I'm not sure VMS is
well-served by inventing yet another platform-specific solution.
java.util.prefs has been around for ages (since Java 1.4), uses the
registry on Windows, the .plist dictionaries on macOS, and an XML
schema on Unix/Linux.  Not sure what it uses on VMS, but since it's
part of Java core, there must be some implementation.  Various
folks have reimplemented it in C/C++, so it could form the basis of
something more general for non-Java users, which would of course
require a wrapper supporting string descriptors, which HLL users
shouldn't ever see directly.
There is also something to be said for the human readability and
<https://en.wikipedia.org/wiki/INI_file>.
For which there are various portable implementations.  As well as
things based on YAML, JSON, etc.
So there are options for VMS, including resurrecting the VMS
Registry facility which no one seems to have ever actually used.
Or adopting something where someone else has already done the hard
work.  I thought this one looked interesting and, though I've never
<http://libprf1.tigris.org>
Lots of utilities already have support for "xxx$INIT" files.  I use
them with LSE, SHOW CLUSTER, and the like.  Not everywhere however.
I do not consider those doing the same as a preference framework.
VMS INIT files contains commands in application specific
language and the application load and execute those commands
before starting processing whatever it needs to process.
Yep. Initialization scripts and preferences files have gotten conflated
in this discussion, and they really aren't the same thing. If you are
initializing bash, then write some bash commands, and if you are
initializing TPU, then write some TPU commands; these are language
implementations and writing your own start-up code in that language
makes perfect sense. That has nothing to do with a generalizable
preferences system that ideally would work across languages and
platforms and provide any application using it with a tree-structured
set of reference data.
Post by Arne Vajhøj
A preference framework allow applications to retrieve
single primitive values (usually with hierarchical key structure
and usually in a type safe way) and then the application
code use those values to do whatever.
Arne
Lorin Ricker
2019-03-21 22:10:31 UTC
Permalink
Post by John Reagan
...
On my Linux box, I always get confused with the difference in .profile, .bashrc, and .bash_profile.
...
Join the club... Methinks that, except in the hearts and minds of a few rabid Unix gurus, it's devolved to a set of distinctions without a difference. Pax, my Unix friends. Although (AFAIR) I've got cross-references in my .profile and .bash_profile to .bashrc, I largely make use of and rely on .bashrc for most of my session setup. I'm ignorant/unappreciative of the nuances, but they don't seem to matter much, at least for me.
Bill Gunshannon
2019-03-22 00:22:58 UTC
Permalink
Post by Lorin Ricker
Post by John Reagan
...
On my Linux box, I always get confused with the difference in .profile, .bashrc, and .bash_profile.
...
Join the club... Methinks that, except in the hearts and minds of a few rabid Unix gurus, it's devolved to a set of distinctions without a difference. Pax, my Unix friends. Although (AFAIR) I've got cross-references in my .profile and .bash_profile to .bashrc, I largely make use of and rely on .bashrc for most of my session setup. I'm ignorant/unappreciative of the nuances, but they don't seem to matter much, at least for me.
BASH is a Linux thing, not a Unix thing. Real Unix "gurus" use
a real Unix shell like "The Bourne Shell", "The C_Shell" and for
later aficionados "The Korn Shell".

:-)

bill
Steven Schweda
2019-03-22 02:18:50 UTC
Permalink
BASH is a Linux thing, not a Unix thing. [...]
No, it's a GNU thing. https://www.gnu.org/software/bash/
I use it on all my UNIX systems (AIX, HP-UX, Solaris, Tru64).
And on my GNU/Linux systems.

Arne Vajhøj
2019-02-10 01:23:05 UTC
Permalink
Post by Craig A. Berry
But on the subject of preferences APIs, I'm not sure VMS is well-served
by inventing yet another platform-specific solution.  java.util.prefs
has been around for ages (since Java 1.4), uses the registry on Windows,
the .plist dictionaries on macOS, and an XML schema on Unix/Linux.  Not
sure what it uses on VMS, but since it's part of Java core, there must
be some implementation.
There is also something to be said for the human readability and
Java on VMS use the same XML format as *nix for preferences.

But I would like to point out that it is just the default
preferences storage.

It is possible to plugin other storages.

Example:

$ type [.demo]prefsdemo.java
package demo;

import java.util.prefs.Preferences;

public class PrefsDemo {
public static void main(String[] args) {
Preferences prefs = Preferences.userRoot();
int a = prefs.node("demo").getInt("a", 0);
String b = prefs.node("demo").get("b", "");
System.out.println(a + " " + b);
System.out.println(prefs.node("demo").get("src", "**** problem
****"));
System.out.println(prefs.getClass().getName());
}
}
$ javac "demo/PrefsDemo.java"
$ type [arne._java._userprefs.demo]prefs.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map SYSTEM "http://java.sun.com/dtd/preferences.dtd">
<map MAP_XML_VERSION="1.0">
<entry key="a" value="123"/>
<entry key="b" value="ABC"/>
<entry key="src" value="XML-file"/>
</map>
$ java -cp . "demo.PrefsDemo"
123 ABC
XML-file
java.util.prefs.FileSystemPreferences
$ type [arne]userprefs.ini
[demo]
a = 123
b = ABC
src = INI-file
$ java -
-cp .:ini4j-0_5_4.jar -
"-Djava.util.prefs.PreferencesFactory=org.ini4j.IniPreferencesFactory" -
"-Dorg.ini4j.prefs.user=file:///disk2/arne/userprefs.ini" -
"demo.PrefsDemo"
123 ABC
INI-file
org.ini4j.IniPreferences
$

I would probably stick to the default storage.

Arne
Arne Vajhøj
2019-02-10 01:18:26 UTC
Permalink
Post by Stephen Hoffman
Or in other words, how well do your .plist files from macOS work on
Windows or Linux?
About as well as OpenVMS system services port elsewhere.
But porting launchd and plist support to OpenVMS—or porting one of the
other and more portable preferences-related tools to OpenVMS—would still
be better than what I have on OpenVMS, and as limited and problematic as
such ports would be.
If preferences are to be done right then preferences API
and storage need to be separated.

Arne
Dave Froble
2019-02-08 23:41:24 UTC
Permalink
Post by Stephen Hoffman
I'd like to have a way to register an app for startup, and to register
callbacks when the app tips over, to automatically try a few restarts
but avoid a crash-loop, to collect failure-related data, and a way to
check if a certain app is running via API and via shell. And I'd prefer
to not to poll process names. Fairly standard stuff. Is it running?
Why not? Can it restart? Can I get a notification when some part of
production tips over? Where do I send my run-time logs, and my error-,
failure-, and event-related logging?
I like the concept.

My first concern would be, if it does so much, will it be perhaps a bit
rigid, forcing users to use it in ways they don't want to.

We use BATCH for some of this, but have a "bespoke" method of
notification of any problems. Nor is as much information as you might
be thinking of as available as it might be. An easy to use tool is a
decent idea.

Our determination whether an app is running is rather crude. Or custom.
Something better would be nice.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2019-02-08 23:28:31 UTC
Permalink
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
Post by Stephen Hoffman
There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.
What percentages of OSs include a job scheduler?
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager.
Now,that's just a downright shame, not letting DCL use one of the best
parts of VMS. We need to gather a rope, tar, some feathers, and show
our displeasure.

:-)
Post by Stephen Hoffman
Yes, I'm aware of the
add-ons. And the system service API follows the usual OpenVMS model of
glorious flexibility at the cost of simplicity and ease of use for
common tasks.
I do like flexibility ....
Post by Stephen Hoffman
Itemlists. Did I mention itemlists? I dislike itemlists. Passing
arguments in hand-rolled data structures is far too reminiscent of
writing assembler code. And about as tedious and as voluminous. And
then there's the lack of a parser. And the lack of language support.
Descriptor support is only marginally better than itemlist support,
outside of BASIC and whichever other languages where it's been
integrated. But itemlists haven't been integrated anywhere.
Ooops, perhaps your favorite rant. But, at the risk of encountering
your use of "bespoke" similar to the way others use "legacy", perhaps
there is some support for building item lists. Consider:

Record SockOpt ! Socket options
Word ReuseAdrLen%
Word ReuseAdrType%
Long ReuseAdrAdr%
Word ReusePortLen%
Word ReusePortType%
Long ReusePortAdr%
Word ShareLen%
Word ShareType%
Long ShareAdr%
End Record

The RECORD construct in Basic appears to be a decent solution, wouldn't
you say?

Of course, one has to be advanced enough to actually USE Basic ....
Post by Stephen Hoffman
Logging. Like storing preferences, there's no single way to do this,
and which means that everybody does it differently. And there's bupkis
for collecting logging data and app crash data from multiple OpenVMS
servers. Yes, I know from syslog, syslog-ng, and ilk.
On-going grumbles including inadequate development tooling and
inadequate compilers and crash-handling and patch-handling also all apply.
The results of these limits for app developers? App tooling that is a
fraction of what it can and should be, and apps that tend to be brittle,
and apps that take longer than they should to develop and to test.
Ok, I'll stop baiting you and agree, things could be better.
--
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
2019-02-09 19:14:25 UTC
Permalink
Post by Dave Froble
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
It's a spot where an app can read and write and store configuration
settings. IP addresses, ports, host names, debugging-related settings,
certificate files, site-specific display or server-specific
customizations, whatever. Most non-trivial apps have a few of these.
These are the sorts of settings that many apps have and maintain,
though that either through a home-grown parser and—where
needed—generator and a custom API, or through logical names—and
maintaining those logical names somewhere else in the installation and
startup environment—or through porting some preferences or
configuration file open-source code, embedding the customizations in
the associated DCL, or—as happens far too often—by embedding the
customizations directly in the source code—and rebuilding the app or
the DCL as needed.
Post by Dave Froble
Post by Stephen Hoffman
There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.
What percentages of OSs include a job scheduler?
I'm sure somebody here can find some operating system that's worse, or
can find some horridly-implemented scheduler.

Job schedulers are available for or are directly integrated with other
major platforms, though.

A central pillar of OpenVMS is clustering and reliability.

What does clustering involve if not job scheduling and load balancing
and fail-over and recovery?

What we have on OpenVMS is either batch or worse, or a very few
commercial apps, the occasional cron port, or ilk.
Post by Dave Froble
Post by Stephen Hoffman
Itemlists. Did I mention itemlists? I dislike itemlists. Passing
arguments in hand-rolled data structures is far too reminiscent of
writing assembler code. And about as tedious and as voluminous. And
then there's the lack of a parser. And the lack of language support.
Descriptor support is only marginally better than itemlist support,
outside of BASIC and whichever other languages where it's been
integrated. But itemlists haven't been integrated anywhere.
Ooops, perhaps your favorite rant. But, at the risk of encountering
your use of "bespoke" similar to the way others use "legacy", perhaps
Record SockOpt ! Socket options
Word ReuseAdrLen%
Word ReuseAdrType%
Long ReuseAdrAdr%
Word ReusePortLen%
Word ReusePortType%
Long ReusePortAdr%
Word ShareLen%
Word ShareType%
Long ShareAdr%
End Record
The RECORD construct in Basic appears to be a decent solution, wouldn't
you say?
Of course, one has to be advanced enough to actually USE Basic ....
Pragmatically, I'd expect a variable declaration, and a call to set or
retrieve a key. The amount of glue code necessary around system
service calls is just absurd.

BASIC is useful, but still limited in this regard. Descriptor support
in BASIC is particularly limited, as it's largely (entirely?) strings.
It's closer to what it should be, though. That descriptor support is
something that could be generalized into something much more powerful.
And it'd be an excellent platform for more tools-related work for
developers, to make BASIC (and OpenVMS) interesting to folks that don't
want to slog through the old system service APIs and the rest of the
baggage.
Post by Dave Froble
Post by Stephen Hoffman
Logging. Like storing preferences, there's no single way to do this,
and which means that everybody does it differently. And there's bupkis
for collecting logging data and app crash data from multiple OpenVMS
servers. Yes, I know from syslog, syslog-ng, and ilk.
On-going grumbles including inadequate development tooling and
inadequate compilers and crash-handling and patch-handling also all apply.
The results of these limits for app developers? App tooling that is a
fraction of what it can and should be, and apps that tend to be
brittle, and apps that take longer than they should to develop and to
test.
Ok, I'll stop baiting you and agree, things could be better.
And it's not going to be easy to catch up. VSI needs newer folks and
newer apps and newer to offset the inevitable losses. Both around
apps, and around the folks that have worked with OpenVMS through their
careers and are now moving on or are retiring. And the newer
developers and newer ISV folks are going to be accustomed to current
environments and tools; to IDEs and recent platforms and frameworks and
open-source options, and commercial packages and databases and the rest.
--
Pure Personal Opinion | HoffmanLabs LLC
gérard Calliet
2019-02-09 19:42:44 UTC
Permalink
And it's not going to be easy to catch up.  VSI needs newer folks and
newer apps and newer to offset the inevitable losses.  Both around apps,
and around the folks that have worked with OpenVMS through their careers
and are now moving on or are retiring.  And the newer developers and
newer ISV folks are going to be accustomed to current environments and
tools; to IDEs and recent platforms and frameworks and open-source
options, and commercial packages and databases and the rest.
How can you help? :)
Stephen Hoffman
2019-02-11 19:11:50 UTC
Permalink
Post by gérard Calliet
And it's not going to be easy to catch up.  VSI needs newer folks and
newer apps and newer to offset the inevitable losses.  Both around
apps, and around the folks that have worked with OpenVMS through their
careers and are now moving on or are retiring.  And the newer
developers and newer ISV folks are going to be accustomed to current
environments and tools; to IDEs and recent platforms and frameworks and
open-source options, and commercial packages and databases and the rest.
How can you help? :)
🤦🏾‍♀️
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-02-09 22:55:26 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of
code from elsewhere, or rolling my own and supporting my own
state-machine parser and generator. Or as happens far too often,
explicit in-line code that's less than wonderful to maintain and test
and extend. And no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
It's a spot where an app can read and write and store configuration
settings. IP addresses, ports, host names, debugging-related settings,
certificate files, site-specific display or server-specific
customizations, whatever. Most non-trivial apps have a few of these.
These are the sorts of settings that many apps have and maintain, though
that either through a home-grown parser and—where needed—generator and a
custom API, or through logical names—and maintaining those logical names
somewhere else in the installation and startup environment—or through
porting some preferences or configuration file open-source code,
embedding the customizations in the associated DCL, or—as happens far
too often—by embedding the customizations directly in the source
code—and rebuilding the app or the DCL as needed.
I've followed this topic a bit, and am led to believe that what's being
discussed is similar to the "ini" files used in WEENDOZE. Or perhaps I
still don't have a clue. (Familiar territory for me.)

Also,I can only comment based upon my perspectives, whatever they are.

So with that caviet ...

I've hard coded some things in VB programs, and if there is "ini file"
overrides, then use the overrides. Makes development and testing
perhaps a bit easier, don't need the ini file at that stage, and
production usage more flexible.

Regardless, I still must write code to read the ini file. Yes, there is
things such as "AppPath" to help find an ini file, but, that's basically
a "logical name" as far as usage is concerned. Hmmm.... perhaps
logical names aren't so bad after all?

So, WEENDOZE and VB have provided the equivalent of logical names, and a
programmer setting up to read parameters from some external data store.
Actually, I've been doing that on VMS since the late 1970s. The need
for user specified parameters was recognized, and addressed, long ago.
So, what's new here?

Actually, our solution used a single data store, you know, sort of like
a database, rather than a separate text file for each program. I guess
the only problem with our long time and still working well solution is
that it, wait for it, "bespoke". Oh, no, we are DOOMED, it's "BESPOKE"!

Sorry for the sarcasm ....

I just don't "get it". It's still work.
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.
What percentages of OSs include a job scheduler?
I'm sure somebody here can find some operating system that's worse, or
can find some horridly-implemented scheduler.
Job schedulers are available for or are directly integrated with other
major platforms, though.
A central pillar of OpenVMS is clustering and reliability.
What does clustering involve if not job scheduling and load balancing
and fail-over and recovery?
What we have on OpenVMS is either batch or worse, or a very few
commercial apps, the occasional cron port, or ilk.
Many things can easily be done with DCL and BATCH. Not everything. Too
often when things go South, it requires manual intervention. Note, I'm
not at all sure that is a bad thing.

The only thing wrong with that comment is that I'm a developer, I've
never been associated with running a production environment. Perhaps
I'm not qualified to copmment.
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
Itemlists. Did I mention itemlists? I dislike itemlists. Passing
arguments in hand-rolled data structures is far too reminiscent of
writing assembler code. And about as tedious and as voluminous. And
then there's the lack of a parser. And the lack of language support.
Descriptor support is only marginally better than itemlist support,
outside of BASIC and whichever other languages where it's been
integrated. But itemlists haven't been integrated anywhere.
Ooops, perhaps your favorite rant. But, at the risk of encountering
your use of "bespoke" similar to the way others use "legacy", perhaps
Record SockOpt ! Socket options
Word ReuseAdrLen%
Word ReuseAdrType%
Long ReuseAdrAdr%
Word ReusePortLen%
Word ReusePortType%
Long ReusePortAdr%
Word ShareLen%
Word ShareType%
Long ShareAdr%
End Record
The RECORD construct in Basic appears to be a decent solution,
wouldn't you say?
Of course, one has to be advanced enough to actually USE Basic ....
Pragmatically, I'd expect a variable declaration, and a call to set or
retrieve a key. The amount of glue code necessary around system
service calls is just absurd.
The problem with that argument is that there are so many ways to use
QIO. And perhaps that itself is a problem. Perhaps there should be
many system services to replace QIO. Each will have different argument
requirements. Or perhaps a bunch of wrappers. Not that I'm an advocate
of wrappers, just more to do, for no processing benefit, though lots of
ease of use benefits.

One could call item lists generic parameter lists. That's all they are,
and the lack of easy to use methods to build the item lists is the real
problem. Not sure I see any easy solutions.
Post by Stephen Hoffman
BASIC is useful, but still limited in this regard. Descriptor support
in BASIC is particularly limited, as it's largely (entirely?) strings.
It's closer to what it should be, though. That descriptor support is
something that could be generalized into something much more powerful.
And it'd be an excellent platform for more tools-related work for
developers, to make BASIC (and OpenVMS) interesting to folks that don't
want to slog through the old system service APIs and the rest of the
baggage.
I'm not sure "descriptor support in Basic" is the correct term.
Descriptors are a VMS thing, not a Basic thing. It's just that Basic is
one of the few users of this VMS capability. Now, why that is might be
a good question.

Note, not often, but I have used descriptors for other than strings.
Please don't ask why, because the only valid response would be "item lists".

:-)
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
Logging. Like storing preferences, there's no single way to do this,
and which means that everybody does it differently. And there's
bupkis for collecting logging data and app crash data from multiple
OpenVMS servers. Yes, I know from syslog, syslog-ng, and ilk.
On-going grumbles including inadequate development tooling and
inadequate compilers and crash-handling and patch-handling also all apply.
The results of these limits for app developers? App tooling that is
a fraction of what it can and should be, and apps that tend to be
brittle, and apps that take longer than they should to develop and to
test.
Ok, I'll stop baiting you and agree, things could be better.
And it's not going to be easy to catch up. VSI needs newer folks and
newer apps and newer to offset the inevitable losses. Both around apps,
and around the folks that have worked with OpenVMS through their careers
and are now moving on or are retiring. And the newer developers and
newer ISV folks are going to be accustomed to current environments and
tools; to IDEs and recent platforms and frameworks and open-source
options, and commercial packages and databases and the rest.
As I have no experience there, I guess I cannot comment.
--
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
2019-02-09 23:51:47 UTC
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
It's a spot where an app can read and write and store configuration
settings. IP addresses, ports, host names, debugging-related settings,
certificate files, site-specific display or server-specific
customizations, whatever. Most non-trivial apps have a few of these.
These are the sorts of settings that many apps have and maintain,
though that either through a home-grown parser and—where
needed—generator and a custom API, or through logical names—and
maintaining those logical names somewhere else in the installation and
startup environment—or through porting some preferences or
configuration file open-source code, embedding the customizations in
the associated DCL, or—as happens far too often—by embedding the
customizations directly in the source code—and rebuilding the app or
the DCL as needed.
I've followed this topic a bit, and am led to believe that what's being
discussed is similar to the "ini" files used in WEENDOZE.
A generation or two past that scheme, and with the ability to read and
write settings, and to be notified when settings change.
Post by Dave Froble
The problem with that argument is that there are so many ways to use
QIO. And perhaps that itself is a problem. Perhaps there should be
many system services to replace QIO. Each will have different argument
requirements. Or perhaps a bunch of wrappers. Not that I'm an
advocate of wrappers, just more to do, for no processing benefit,
though lots of ease of use benefits.
One could call item lists generic parameter lists. That's all they
are, and the lack of easy to use methods to build the item lists is the
real problem. Not sure I see any easy solutions.
The itemlists *themselves* are the problem...

Itemlists are a 1970s-era solution to API upward-compatibility, and
they push more than a little of the compatibility work into the purview
of the developer of the called API, and more than a little into the
purview of the developer working on the calling app.

We've learned a few things since the 1970s, too.
Post by Dave Froble
Post by Stephen Hoffman
BASIC is useful, but still limited in this regard. Descriptor support
in BASIC is particularly limited, as it's largely (entirely?) strings.
It's closer to what it should be, though. That descriptor support is
something that could be generalized into something much more powerful.
And it'd be an excellent platform for more tools-related work for
developers, to make BASIC (and OpenVMS) interesting to folks that don't
want to slog through the old system service APIs and the rest of the
baggage.
I'm not sure "descriptor support in Basic" is the correct term.
Descriptors are a VMS thing, not a Basic thing. It's just that Basic
is one of the few users of this VMS capability. Now, why that is might
be a good question.
Note, not often, but I have used descriptors for other than strings.
Please don't ask why, because the only valid response would be "item lists".
How about a "descriptor" that can reference any sort of data, string,
integer or array or whatever. That keeps track of what that data.
That keeps track of the encoding and the language associated with text
strings. That can return the number of bytes in the string. And the
number of glyphs that will be displayed when the string is shown to a
user.

Now ponder what that looks like, when you don't have to use itemlists
or other code to access that data referenced by the "descriptor". You
set or get or modify the data, or copy or allocate or deallocate, and
need only declare the associated string or integer or array variables.
Not all the baggage OpenVMS expects developers to declare.

Now further ponder what this all might look like, when that same
"descriptor" can also reference executable code. This code all akin
to how existing OpenVMS app code can invoke lib$find_image_symbol and
can find and invoke entry points in a shareable image. Where you can
tell the "descriptor" to return the string as an integer, for instance.
And the code in that "shareable image" that performs many of these
transformations already exists. Where you get much of the
compatibility that's provided by use of shareable images, too.

A descendent of what OpenVMS uses descriptors for is quite commonly
used for references to code and to data, and for the cross-version
compatibility provided by itemlists.

This is not fiction. These designs exist now. They're in common use
on some other platforms. And it'd all fit nicely into what OpenVMS
BASIC presents developers, too.

I can understand the confusion around what I'm writing here, too. I
was once quite contented to get so little out of so much development
effort, and had never noticed how many different and incomplete
implementations exist around OpenVMS and its apps, and around how hard
it is to use OpenVMS. And I know how to use and develop for OpenVMS.
I thought they were quite elegant and great for compatibility, and
hadn't recognized the problems with itemlists. Around having to define
logical names somewhere else in the system, and either completely
unrelated to the app, or involved from a manually-edited file
elsewhere. Not until another vendor was going to some effort to remove
the related code from what the developers needed to write. And to
package the app code together. Then... light dawned.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-02-10 02:31:55 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of
code from elsewhere, or rolling my own and supporting my own
state-machine parser and generator. Or as happens far too often,
explicit in-line code that's less than wonderful to maintain and
test and extend. And no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
It's a spot where an app can read and write and store configuration
settings. IP addresses, ports, host names, debugging-related
settings, certificate files, site-specific display or server-specific
customizations, whatever. Most non-trivial apps have a few of these.
These are the sorts of settings that many apps have and maintain,
though that either through a home-grown parser and—where
needed—generator and a custom API, or through logical names—and
maintaining those logical names somewhere else in the installation
and startup environment—or through porting some preferences or
configuration file open-source code, embedding the customizations in
the associated DCL, or—as happens far too often—by embedding the
customizations directly in the source code—and rebuilding the app or
the DCL as needed.
I've followed this topic a bit, and am led to believe that what's
being discussed is similar to the "ini" files used in WEENDOZE.
A generation or two past that scheme, and with the ability to read and
write settings, and to be notified when settings change.
I can see that, if the app design requires it. I've never had to write
back to the parameter storage. I can imagine shared data, where part 1
tells part 2 the status of the processing. And perhaps for other
things. But, I'd consider that part of the app design.
Post by Stephen Hoffman
Post by Dave Froble
The problem with that argument is that there are so many ways to use
QIO. And perhaps that itself is a problem. Perhaps there should be
many system services to replace QIO. Each will have different
argument requirements. Or perhaps a bunch of wrappers. Not that I'm
an advocate of wrappers, just more to do, for no processing benefit,
though lots of ease of use benefits.
One could call item lists generic parameter lists. That's all they
are, and the lack of easy to use methods to build the item lists is
the real problem. Not sure I see any easy solutions.
The itemlists *themselves* are the problem...
Again, let's use QIO for the discussion. As I've written, perhaps QIO
is too much of a "jack of all trades". But it's what exists now, and if
using it, the parameters passed to it differ greatly based upon the
operation. Quite frankly, I never would have designed such a thing.

So, what else would allow the number and type of data in parameters to
be used with this example. Again, perhaps such routines are a poor
design, more so that the use of item lists.

There are system services that are a lot more specific, and where the
sue of item lists really isn't required.

While discussing parameter passing, I'll mention one thing I've done.
Define a Basic Record with all the pieces of data desired to pass, load
the record, and call a subroutine with the address of the record as an
argument. The Subroutine also has the record definition, and therefore
has the data.

Ok, tell me that I've just invented "item lists", but, specifying the
data is much easier.
Post by Stephen Hoffman
Itemlists are a 1970s-era solution to API upward-compatibility, and they
push more than a little of the compatibility work into the purview of
the developer of the called API, and more than a little into the purview
of the developer working on the calling app.
We've learned a few things since the 1970s, too.
Post by Dave Froble
Post by Stephen Hoffman
BASIC is useful, but still limited in this regard. Descriptor
support in BASIC is particularly limited, as it's largely (entirely?)
strings. It's closer to what it should be, though. That descriptor
support is something that could be generalized into something much
more powerful. And it'd be an excellent platform for more
tools-related work for developers, to make BASIC (and OpenVMS)
interesting to folks that don't want to slog through the old system
service APIs and the rest of the baggage.
I'm not sure "descriptor support in Basic" is the correct term.
Descriptors are a VMS thing, not a Basic thing. It's just that Basic
is one of the few users of this VMS capability. Now, why that is
might be a good question.
Note, not often, but I have used descriptors for other than strings.
Please don't ask why, because the only valid response would be "item lists".
How about a "descriptor" that can reference any sort of data, string,
integer or array or whatever. That keeps track of what that data. That
keeps track of the encoding and the language associated with text
strings. That can return the number of bytes in the string. And the
number of glyphs that will be displayed when the string is shown to a user.
The "concept" of "descriptor" could be considered rather broad. One
could contain all kind of information about the data that it points to.
Having the information in a descriptor modified by the called routine
would be possible. Not saying VMS descriptors have gone that far, but
it could be implemented.
Post by Stephen Hoffman
Now ponder what that looks like, when you don't have to use itemlists or
other code to access that data referenced by the "descriptor". You set
or get or modify the data, or copy or allocate or deallocate, and need
only declare the associated string or integer or array variables. Not
all the baggage OpenVMS expects developers to declare.
Ok, I don't see everything, I can be easily confused. But, to perform a
particular action, you're still going to have to specify the requierd
data, and, I'm wondering if you're talking about something just as
difficult as item lists.
Post by Stephen Hoffman
Now further ponder what this all might look like, when that same
"descriptor" can also reference executable code. This code all akin to
how existing OpenVMS app code can invoke lib$find_image_symbol and can
find and invoke entry points in a shareable image. Where you can tell
the "descriptor" to return the string as an integer, for instance. And
the code in that "shareable image" that performs many of these
transformations already exists. Where you get much of the
compatibility that's provided by use of shareable images, too.
That went a bit too far for me.

I'm wondering if you're considering an expanded role for descriptors, or
whatever, more than representing data.
Post by Stephen Hoffman
A descendent of what OpenVMS uses descriptors for is quite commonly used
for references to code and to data, and for the cross-version
compatibility provided by itemlists.
This is not fiction. These designs exist now. They're in common use on
some other platforms. And it'd all fit nicely into what OpenVMS BASIC
presents developers, too.
Anything can be improved, even Basic. But that would be difficult.

:-)
Post by Stephen Hoffman
I can understand the confusion around what I'm writing here, too. I was
once quite contented to get so little out of so much development effort,
and had never noticed how many different and incomplete implementations
exist around OpenVMS and its apps, and around how hard it is to use
OpenVMS. And I know how to use and develop for OpenVMS. I thought they
were quite elegant and great for compatibility, and hadn't recognized
the problems with itemlists. Around having to define logical names
somewhere else in the system, and either completely unrelated to the
app, or involved from a manually-edited file elsewhere. Not until
another vendor was going to some effort to remove the related code from
what the developers needed to write. And to package the app code
together. Then... light dawned.
I'm not going to claim that the VMS way is the best way. At least I
know better than to do that. But I usually get back to TANSTAAFL and
that to perform some task, there will be some work involved.

Yeah, to some extent, I'm confused. I'm trying, and I think some things
are becoming clearer. Some things.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-10 01:41:00 UTC
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
There's no preferences file API.  Which means downloading a wad of
code from elsewhere, or rolling my own and supporting my own
state-machine parser and generator.  Or as happens far too often,
explicit in-line code that's less than wonderful to maintain and test
and extend.   And no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
It's a spot where an app can read and write and store configuration
settings.  IP addresses, ports, host names, debugging-related settings,
certificate files, site-specific display or server-specific
customizations, whatever.  Most non-trivial apps have a few of these.
These are the sorts of settings that many apps have and maintain, though
that either through a home-grown parser and—where needed—generator and a
custom API, or through logical names—and maintaining those logical names
somewhere else in the installation and startup environment—or through
porting some preferences or configuration file open-source code,
embedding the customizations in the associated DCL, or—as happens far
too often—by embedding the customizations directly in the source
code—and rebuilding the app or the DCL as needed.
I've followed this topic a bit, and am led to believe that what's being
discussed is similar to the "ini" files used in WEENDOZE.  Or perhaps I
still don't have a clue.  (Familiar territory for me.)
INI files are a primitive preferences framework.
Post by Dave Froble
I've hard coded some things in VB programs, and if there is "ini file"
overrides, then use the overrides.  Makes development and testing
perhaps a bit easier, don't need the ini file at that stage, and
production usage more flexible.
That can be baked into the preferences API.

Java prefs api use:

sometype variable = prefs.getSometype("somekey", defaultvalueifkeynotfound);
Post by Dave Froble
Regardless, I still must write code to read the ini file.  Yes, there is
things such as "AppPath" to help find an ini file, but, that's basically
a "logical name" as far as usage is concerned.  Hmmm....  perhaps
logical names aren't so bad after all?
So, WEENDOZE and VB have provided the equivalent of logical names, and a
programmer setting up to read parameters from some external data store.
 Actually, I've been doing that on VMS since the late 1970s.  The need
for user specified parameters was recognized, and addressed, long ago.
So, what's new here?
I don't think anyone is claiming anything to be new.

The claim is that a preferences framework and API are useful.

For two reasons:
* it requires less work for application developers compared to when
they need to create their own
* it strongly encourages all applications to use the same framework -
that makes life a bit easier for running systems with applications
from many vendors
Post by Dave Froble
Actually, our solution used a single data store, you know, sort of like
a database, rather than a separate text file for each program.  I guess
the only problem with our long time and still working well solution is
that it, wait for it, "bespoke".  Oh, no, we are DOOMED, it's "BESPOKE"!
One per applications vs central is an ongoing debate.

MS started with one per application with INI files, then switched
to central with registry and switched back to one per application
with .NET app config files.

There are pro and con for both.

Arne
Dave Froble
2019-02-10 02:41:25 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of
code from elsewhere, or rolling my own and supporting my own
state-machine parser and generator. Or as happens far too often,
explicit in-line code that's less than wonderful to maintain and test
and extend. And no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
It's a spot where an app can read and write and store configuration
settings. IP addresses, ports, host names, debugging-related settings,
certificate files, site-specific display or server-specific
customizations, whatever. Most non-trivial apps have a few of these.
These are the sorts of settings that many apps have and maintain, though
that either through a home-grown parser and—where needed—generator and a
custom API, or through logical names—and maintaining those logical names
somewhere else in the installation and startup environment—or through
porting some preferences or configuration file open-source code,
embedding the customizations in the associated DCL, or—as happens far
too often—by embedding the customizations directly in the source
code—and rebuilding the app or the DCL as needed.
I've followed this topic a bit, and am led to believe that what's
being discussed is similar to the "ini" files used in WEENDOZE. Or
perhaps I still don't have a clue. (Familiar territory for me.)
INI files are a primitive preferences framework.
At least I got a feel for what is being discussed. I really hate it
when people re-name things. Very confusing. Microsoft is a prime culprit.
Post by Arne Vajhøj
Post by Dave Froble
I've hard coded some things in VB programs, and if there is "ini file"
overrides, then use the overrides. Makes development and testing
perhaps a bit easier, don't need the ini file at that stage, and
production usage more flexible.
That can be baked into the preferences API.
sometype variable = prefs.getSometype("somekey",
defaultvalueifkeynotfound);
Post by Dave Froble
Regardless, I still must write code to read the ini file. Yes, there
is things such as "AppPath" to help find an ini file, but, that's
basically a "logical name" as far as usage is concerned. Hmmm....
perhaps logical names aren't so bad after all?
So, WEENDOZE and VB have provided the equivalent of logical names, and
a programmer setting up to read parameters from some external data
store. Actually, I've been doing that on VMS since the late 1970s.
The need for user specified parameters was recognized, and addressed,
long ago. So, what's new here?
I don't think anyone is claiming anything to be new.
I hope not, cause the usage is rather ancient. For me at least.
Post by Arne Vajhøj
The claim is that a preferences framework and API are useful.
To me, the terms framework and API seem to be more than a bit of
overkill for this tactic.
Post by Arne Vajhøj
* it requires less work for application developers compared to when
they need to create their own
* it strongly encourages all applications to use the same framework -
that makes life a bit easier for running systems with applications
from many vendors
Post by Dave Froble
Actually, our solution used a single data store, you know, sort of
like a database, rather than a separate text file for each program. I
guess the only problem with our long time and still working well
solution is that it, wait for it, "bespoke". Oh, no, we are DOOMED,
it's "BESPOKE"!
One per applications vs central is an ongoing debate.
The only thing I see here is that I and others are already doing these
things, and then along come others who want us to use different tools.

If a tool is flexible enough to handle all requirements, why should
anyone take up another tool?
Post by Arne Vajhøj
MS started with one per application with INI files, then switched
to central with registry and switched back to one per application
with .NET app config files.
There are pro and con for both.
Well, if the registry wasn't such a clusterfuck, perhaps a central
repository would not be a bad idea. I prefer central, so it's available
no matter what you're developing.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
p***@gmail.com
2019-02-10 03:16:24 UTC
Permalink
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
Phil

but how do you type an underscore on an iPad?
Arne Vajhøj
2019-02-10 03:28:21 UTC
Permalink
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
I do. And I also think somebody else already mentioned it briefly.

I don't see people lined up to use that solution.

But of course it can be said that something exists - just
not part of base VMS.

Arne
p***@gmail.com
2019-02-10 04:05:56 UTC
Permalink
Yes but one would think Stephen could have used it if he wanted,
but maybe it never made it to Itanium?

I don't see people queueing up to use VMS in any shape or form
(except in this newsgroup)

The only hope for VSI is getting to a point where you can rent a 5 node cluster for $99 a month
running in the cloud (Amazon, Microsoft, Google, IBM, Oracle) or your own private cloud if you
still insist in having your own hardware.

Itanium is dead and VSI don't make X86-64 servers so there's nothing stopping them!
Phil
Dave Froble
2019-02-10 06:14:12 UTC
Permalink
Post by p***@gmail.com
Yes but one would think Stephen could have used it if he wanted,
but maybe it never made it to Itanium?
I don't see people queueing up to use VMS in any shape or form
(except in this newsgroup)
The only hope for VSI is getting to a point where you can rent a 5 node cluster for $99 a month
running in the cloud (Amazon, Microsoft, Google, IBM, Oracle) or your own private cloud if you
still insist in having your own hardware.
Itanium is dead and VSI don't make X86-64 servers so there's nothing stopping them!
Phil
I wonder, is any OS vendors making any money from use of their product
in "the cloud"? Some of those cloud vendors might just "roll their own"
before paying any significant money to OS vendors. Then again, several
in that list are OS vendors.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-10 14:34:01 UTC
Permalink
Post by Dave Froble
I wonder, is any OS vendors making any money from use of their product
in "the cloud"?  Some of those cloud vendors might just "roll their own"
before paying any significant money to OS vendors.  Then again, several
in that list are OS vendors.
(I will assume a broad definition os OS vendor to include
companies supporting Linux like Redhat to be included)

As a starting point then cloud does not really impact
the OS vendors.

The customer buys an OS license for either a one time
payment or an annual payment.

The OS vendor does not really care whether that
OS license is installed on physical HW or on a VM in
customers private cloud or on a VM in public cloud.

A dollar is a dollar.

That said then the cloud world does create
some new requirements for licensing.

If we say that the two big benefits of cloud
are:
* lower cost due to better HW utilization
* the flexibility to scale up and scale down (add
or remove nodes) at short notice

Then the first put even more price pressure on.

And the second really demand more flexible
licensing.

If you want to spin up 50 nodes for a week
then paying for "forever" licenses for the OS
probably do not make financial sense.

Annual license fee is a bit better. But
still not optimal.

The cloud customer would really be looking for
an hourly license fee.

They pay for the VM by the hour, so they want
to pay for the OS by the hour.

Arne
Dave Froble
2019-02-10 17:30:49 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
I wonder, is any OS vendors making any money from use of their product
in "the cloud"? Some of those cloud vendors might just "roll their
own" before paying any significant money to OS vendors. Then again,
several in that list are OS vendors.
(I will assume a broad definition os OS vendor to include
companies supporting Linux like Redhat to be included)
As a starting point then cloud does not really impact
the OS vendors.
The customer buys an OS license for either a one time
payment or an annual payment.
The OS vendor does not really care whether that
OS license is installed on physical HW or on a VM in
customers private cloud or on a VM in public cloud.
A dollar is a dollar.
That said then the cloud world does create
some new requirements for licensing.
If we say that the two big benefits of cloud
* lower cost due to better HW utilization
* the flexibility to scale up and scale down (add
or remove nodes) at short notice
Then the first put even more price pressure on.
And the second really demand more flexible
licensing.
If you want to spin up 50 nodes for a week
then paying for "forever" licenses for the OS
probably do not make financial sense.
Annual license fee is a bit better. But
still not optimal.
The cloud customer would really be looking for
an hourly license fee.
They pay for the VM by the hour, so they want
to pay for the OS by the hour.
Arne
I think most are aware that certain types in management of a business
look very hard for cost savings. Not a bad concept, unless taken too
far. There can be real savings, and, there can be the perception of
savings.

There is a practice that I'm aware of. In order to save costs,
sometimes multiple people go together to purchase an aircraft and share
the costs of maintaining the aircraft. For example, with 4 partners,
the cost to each would be 25% of what it would cost only one owner.

Such partnerships can have various methods for sharing, from scheduling
time, to if one shows up and the aircraft is in the hangar then it's
available. However, if the aircraft is already scheduled, or is not in
the hangar, when one of the partners wants to fly, then he doesn't fly
that day, or time. Obviously, this doesn't work so well when there is
the need for always available.

Which brings me to ask, when a company depends on their computer systems
to be always available, is it wise to enter into partnerships where
perhaps the time will come when the computer systems might not be "in
the hangar"?

Got to wonder just what savings actually happen when the cloud isn't
available. Yeah, yeah, you're going to say "that never happens". Well,
in my experience, when someone says "that never happens", I tend to
suspect that it indeed will happen.

But back on topic. Are there cloud services available where the cloud
provider provides the OS? If so, won't they (the cloud providers) be
looking to "save costs", perhaps to the detriment of the OS vendors?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
j***@yahoo.co.uk
2019-02-10 17:51:56 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
I wonder, is any OS vendors making any money from use of their product
in "the cloud"? Some of those cloud vendors might just "roll their
own" before paying any significant money to OS vendors. Then again,
several in that list are OS vendors.
(I will assume a broad definition os OS vendor to include
companies supporting Linux like Redhat to be included)
As a starting point then cloud does not really impact
the OS vendors.
The customer buys an OS license for either a one time
payment or an annual payment.
The OS vendor does not really care whether that
OS license is installed on physical HW or on a VM in
customers private cloud or on a VM in public cloud.
A dollar is a dollar.
That said then the cloud world does create
some new requirements for licensing.
If we say that the two big benefits of cloud
* lower cost due to better HW utilization
* the flexibility to scale up and scale down (add
or remove nodes) at short notice
Then the first put even more price pressure on.
And the second really demand more flexible
licensing.
If you want to spin up 50 nodes for a week
then paying for "forever" licenses for the OS
probably do not make financial sense.
Annual license fee is a bit better. But
still not optimal.
The cloud customer would really be looking for
an hourly license fee.
They pay for the VM by the hour, so they want
to pay for the OS by the hour.
Arne
I think most are aware that certain types in management of a business
look very hard for cost savings. Not a bad concept, unless taken too
far. There can be real savings, and, there can be the perception of
savings.
There is a practice that I'm aware of. In order to save costs,
sometimes multiple people go together to purchase an aircraft and share
the costs of maintaining the aircraft. For example, with 4 partners,
the cost to each would be 25% of what it would cost only one owner.
Such partnerships can have various methods for sharing, from scheduling
time, to if one shows up and the aircraft is in the hangar then it's
available. However, if the aircraft is already scheduled, or is not in
the hangar, when one of the partners wants to fly, then he doesn't fly
that day, or time. Obviously, this doesn't work so well when there is
the need for always available.
Which brings me to ask, when a company depends on their computer systems
to be always available, is it wise to enter into partnerships where
perhaps the time will come when the computer systems might not be "in
the hangar"?
Got to wonder just what savings actually happen when the cloud isn't
available. Yeah, yeah, you're going to say "that never happens". Well,
in my experience, when someone says "that never happens", I tend to
suspect that it indeed will happen.
But back on topic. Are there cloud services available where the cloud
provider provides the OS? If so, won't they (the cloud providers) be
looking to "save costs", perhaps to the detriment of the OS vendors?
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave, you're such an unbeliever. And on that basis...

Another practice from the commodity travel industry which is
afaik also used in the 'public cloud' business is overbooking,
ie cloud appears 'cheap' because most folks won't notice (and/or
won't care) if their important work slows down because everyone
who's paid for capacity wants to use it at the same time, and
consequently there's not enough to go down. Obviously from time
to time some people may actually care about getting what they
thought they'd paid for, at which point the real fun will start.

As for "it's a once in a hundred year probability", anyone
noticed how those things often seem to come in threes (or
more), and a lot sooner than a hundred years from the first
set of marketing announcements? Statistics can be intersting
like that sometimes, as are domino effects.
Arne Vajhøj
2019-02-10 18:34:37 UTC
Permalink
Post by j***@yahoo.co.uk
Another practice from the commodity travel industry which is
afaik also used in the 'public cloud' business is overbooking,
ie cloud appears 'cheap' because most folks won't notice (and/or
won't care) if their important work slows down because everyone
who's paid for capacity wants to use it at the same time, and
consequently there's not enough to go down. Obviously from time
to time some people may actually care about getting what they
thought they'd paid for, at which point the real fun will start.
I cannot see that happen for one of the big cloud providers.
Post by j***@yahoo.co.uk
As for "it's a once in a hundred year probability",
It is not anything like that.

For a cloud provider having millions of VM's the
probability of a a large part of them spiking at
the same time is extremely low.

Example

Assumptions:

cloud has 10 million VM's
VM's consist of groups of 100 VM's
load within group follow each other perfect
load between groups are independent

Probability (per Wolfram Alfa) that more than 70%
of VM's will be about average at the same time:

6.5 x 10**-3577

10**-3577 is a very small number.

If we look at 1 minute intervals that leads to an
expected number of occurrences in 100 years of:

1.2 x 10**-3570

Of course the assumptions can be varied a lot.

But 1 per 100 year is way off.

Arne
Dave Froble
2019-02-10 19:35:49 UTC
Permalink
Post by Arne Vajhøj
Post by j***@yahoo.co.uk
Another practice from the commodity travel industry which is
afaik also used in the 'public cloud' business is overbooking,
ie cloud appears 'cheap' because most folks won't notice (and/or
won't care) if their important work slows down because everyone
who's paid for capacity wants to use it at the same time, and
consequently there's not enough to go down. Obviously from time
to time some people may actually care about getting what they
thought they'd paid for, at which point the real fun will start.
I cannot see that happen for one of the big cloud providers.
Post by j***@yahoo.co.uk
As for "it's a once in a hundred year probability",
It is not anything like that.
For a cloud provider having millions of VM's the
probability of a a large part of them spiking at
the same time is extremely low.
Example
cloud has 10 million VM's
VM's consist of groups of 100 VM's
load within group follow each other perfect
load between groups are independent
Probability (per Wolfram Alfa) that more than 70%
6.5 x 10**-3577
10**-3577 is a very small number.
If we look at 1 minute intervals that leads to an
1.2 x 10**-3570
Of course the assumptions can be varied a lot.
But 1 per 100 year is way off.
Arne
And what if that one year in 100 is next year, or this year?

But, let's make it a bit more personal.

Let's define a circumstance, perhaps a bit far out today, but perhaps
not so in the future.

You have a medical problem, and the only treatment is computer
controlled surgery. If things do not go flawlessly, for whatever
reason, then you die.

So, will you accept that computer control from some cloud, or perhaps a
local dedicated system, or perhaps a disaster tolerant cluster where a
dozen systems must fail to fail the surgery.

So, Ok, your life, you choose, and I won't even make any suggestions,
nor fault you on an improper choice.

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-11 01:49:09 UTC
Permalink
Post by Dave Froble
But, let's make it a bit more personal.
Let's define a circumstance, perhaps a bit far out today, but perhaps
not so in the future.
You have a medical problem, and the only treatment is computer
controlled surgery.  If things do not go flawlessly, for whatever
reason, then you die.
So, will you accept that computer control from some cloud, or perhaps a
local dedicated system, or perhaps a disaster tolerant cluster where a
dozen systems must fail to fail the surgery.
So, Ok, your life, you choose, and I won't even make any suggestions,
nor fault you on an improper choice.
:-)
I think the example is a bit off track.

I think we are looking at 3 different types of systems:

A) An on-premise general purpose OS business grade
application connectivity via general internal network.
B) An in-cloud general purpose OS business grade
application connectivity via internet and general
internal network.
C) An embedded real time OS life dependent application
connectivity via dedicated wire.

The discussion was about #A vs #B.

Only #C would work for the scenario you describe.

And I don't think anyone want to move such a scenario
to cloud.

The same hospital will likely run their patient records, planning,
billing, email, web, directory etc. on either #A or #B.

I would not expect any difference in server reliability
for #A vs #B.

And I will also question whether there is much of a difference
in network reliability.

If #A have one data center serving multiple hospitals,
then it is the same WAN problem as #B.

And even truly on location, then there would be
connectivity requirements for insurance systems,
financial systems etc..

We live in a very connected world.

Caveat: I know relative little about what hospital IT departments
actually do.

Arne
j***@yahoo.co.uk
2019-02-10 19:49:16 UTC
Permalink
Post by Arne Vajhøj
Post by j***@yahoo.co.uk
Another practice from the commodity travel industry which is
afaik also used in the 'public cloud' business is overbooking,
ie cloud appears 'cheap' because most folks won't notice (and/or
won't care) if their important work slows down because everyone
who's paid for capacity wants to use it at the same time, and
consequently there's not enough to go down. Obviously from time
to time some people may actually care about getting what they
thought they'd paid for, at which point the real fun will start.
I cannot see that happen for one of the big cloud providers.
Post by j***@yahoo.co.uk
As for "it's a once in a hundred year probability",
It is not anything like that.
For a cloud provider having millions of VM's the
probability of a a large part of them spiking at
the same time is extremely low.
Example
cloud has 10 million VM's
VM's consist of groups of 100 VM's
load within group follow each other perfect
load between groups are independent
Probability (per Wolfram Alfa) that more than 70%
6.5 x 10**-3577
10**-3577 is a very small number.
If we look at 1 minute intervals that leads to an
1.2 x 10**-3570
Of course the assumptions can be varied a lot.
But 1 per 100 year is way off.
Arne
You may want to look a bit more closely at the ways
interconnected systems fail.

The problem of lots of cloud systems all *independently*,
*randomly* spiking at the same time may indeed be small,
maybe even negligible for some purposes.

But suppose there's some kind of unwelcome "chain reaction"
effect. (There always will be, in a "cheap" setup, it's part
of why they're cheao).

Then your Wolfram peseudo-random statistics are basically
useless. Just ask anyone who has followed the way electricity
supply grids collapse following a minor fault which leads
to a wide area domino effect. Just ask anyone who's watched
authentication on a massive wide area network collapse under
load following a loss of connectivity (e.g. a single point
of failure which some external supplier had said could never
happen) and then everyone reconnecting at the same time.
Plenty of other examples.

Business: "But you promised it would never happen"
Cloud: "Never mind, here's three months service credit,
as agreed in the SLA."
Business: "But we'll be out of business in three months
because of your incompetence"
Cloud: "No, you'll be out of business because of YOUR
failure to understand how important these services are
to your operation, and YOUR failure to understand how
unimportant you are to our operation."


Yes there are risks with keeping stuff on premises. And
those risks can, on a good day, be identified and maybe
even mitigated if appropriate. Planning mitigation in
advance may have a cost.

There may also be a financial impact of the organisations
inability to do routine business (but when that day
inevitably comes, that cost is probably paid for out of a
different budget).

Just look at the recent downtime history of Office 365.
Well, recent since e.g. 2013:
https://redmondmag.com/articles/2013/11/21/windows-azure-outages.aspx
http://social.dnsmadeeasy.com/blog/microsoft-fiasco-and-why-big-companies-should-outsource-their-dns/

(same through 2016 and beyond)

And here we are in 2019: Microsoft's worldwide public cloud
downtime blamed on outsourced DNS provider
(CenturyLink?). Ooops.

Well, double oops, actually, because similar issues were
also blamed on CenturyLink in late 2018. (And probably
before. "Lessons will be learned, in line with the
company's policy of continuous product and service
de-improvement."

One size probably doesn't fit all.

There is no immediate correlation between cost/size and
competence. It's frequently competence that really matters,
whereas it's frequently cost that drives beancounters.

All good fun. Maybe.
Dave Froble
2019-02-10 21:49:13 UTC
Permalink
Post by j***@yahoo.co.uk
Business: "But you promised it would never happen"
Cloud: "Never mind, here's three months service credit,
as agreed in the SLA."
Business: "But we'll be out of business in three months
because of your incompetence"
Cloud: "No, you'll be out of business because of YOUR
failure to understand how important these services are
to your operation, and YOUR failure to understand how
unimportant you are to our operation."
Now, that sort of says it all.

Perhaps that paragraph should be a critical part of every business school.

Perhaps not, as it just might compel the students to actually think.

There just might come a day when external compute resources will be a
reasonable, perhaps even the only reasonable, choice.

But, as some real world examples have shown, "today is not that day".
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2019-02-11 03:21:01 UTC
Permalink
Post by j***@yahoo.co.uk
Another practice from the commodity travel industry which is
afaik also used in the 'public cloud' business is overbooking,
ie cloud appears 'cheap' because most folks won't notice (and/or
won't care) if their important work slows down because everyone
who's paid for capacity wants to use it at the same time, and
consequently there's not enough to go down. Obviously from time
to time some people may actually care about getting what they
thought they'd paid for, at which point the real fun will start.
This is not exactly how it works, at least not with AWS. It's not that
they overbook and can't deliver, it's that they severely throttle you
when you have expended your accrued cpu credits. There are various ways
to accrue credits, and if money is no object it is certainly possible to
pay enough such that you never run out. But for affordable systems,
even systems that are called "large" instances, you can be running along
just fine until you have just enough sustained usage that pushes you
over a threshold and everything suddenly becomes an order of magnitude
slower. And stays that way as long as the system is under load. You
only get full access to the capabilities of the underlying hardware if
you don't really need them except for short periods.
Arne Vajhøj
2019-02-10 18:05:03 UTC
Permalink
But back on topic.  Are there cloud services available where the cloud
provider provides the OS?  If so, won't they (the cloud providers) be
looking to "save costs", perhaps to the detriment of the OS vendors?
AWS has delas with MS:

https://aws.amazon.com/windows/resources/licensing/

and Redhat:

https://aws.amazon.com/partners/redhat/faqs/

but I don't know much about how it works.

Arne
Arne Vajhøj
2019-02-10 18:13:48 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
If we say that the two big benefits of cloud
* lower cost due to better HW utilization
* the flexibility to scale up and scale down (add
   or remove nodes) at short notice
I think most are aware that certain types in management of a business
look very hard for cost savings.  Not a bad concept, unless taken too
far.  There can be real savings, and, there can be the perception of
savings.
There is a practice that I'm aware of.  In order to save costs,
sometimes multiple people go together to purchase an aircraft and share
the costs of maintaining the aircraft.  For example, with 4 partners,
the cost to each would be 25% of what it would cost only one owner.
Such partnerships can have various methods for sharing, from scheduling
time, to if one shows up and the aircraft is in the hangar then it's
available.  However, if the aircraft is already scheduled, or is not in
the hangar, when one of the partners wants to fly, then he doesn't fly
that day, or time.  Obviously, this doesn't work so well when there is
the need for always available.
Which brings me to ask, when a company depends on their computer systems
to be always available, is it wise to enter into partnerships where
perhaps the time will come when the computer systems might not be "in
the hangar"?
Got to wonder just what savings actually happen when the cloud isn't
available.  Yeah, yeah, you're going to say "that never happens".  Well,
in my experience, when someone says "that never happens", I tend to
suspect that it indeed will happen.
Computers in cloud can go down. So can dedicated computers.

The public cloud providers provide redundancy options. Not choosing
one comes with a risk. So does not having redundancy for an
on premise solution.

Even with redundancy something can go wrong with failover.
It happens with cloud . It happens with on premise.

It cloud overall more risky than on premise?

That is a good question. My non-scientific gut feeling
is that it depends a lot on the quality of the IT
org doing the on premise.

Regarding capacity, then that should not be a problem with
the big public cloud providers.

At the scale they operate then demand is very predictable.

If you run thousands of VM's then they could all need more
power at the same time.

But if you run millions of VM's then load evens out.

Arne
Dave Froble
2019-02-10 19:38:53 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
If we say that the two big benefits of cloud
* lower cost due to better HW utilization
* the flexibility to scale up and scale down (add
or remove nodes) at short notice
I think most are aware that certain types in management of a business
look very hard for cost savings. Not a bad concept, unless taken too
far. There can be real savings, and, there can be the perception of
savings.
There is a practice that I'm aware of. In order to save costs,
sometimes multiple people go together to purchase an aircraft and
share the costs of maintaining the aircraft. For example, with 4
partners, the cost to each would be 25% of what it would cost only one
owner.
Such partnerships can have various methods for sharing, from
scheduling time, to if one shows up and the aircraft is in the hangar
then it's available. However, if the aircraft is already scheduled,
or is not in the hangar, when one of the partners wants to fly, then
he doesn't fly that day, or time. Obviously, this doesn't work so
well when there is the need for always available.
Which brings me to ask, when a company depends on their computer
systems to be always available, is it wise to enter into partnerships
where perhaps the time will come when the computer systems might not
be "in the hangar"?
Got to wonder just what savings actually happen when the cloud isn't
available. Yeah, yeah, you're going to say "that never happens".
Well, in my experience, when someone says "that never happens", I tend
to suspect that it indeed will happen.
Computers in cloud can go down. So can dedicated computers.
The public cloud providers provide redundancy options. Not choosing
one comes with a risk. So does not having redundancy for an
on premise solution.
Even with redundancy something can go wrong with failover.
It happens with cloud . It happens with on premise.
It cloud overall more risky than on premise?
That is a good question. My non-scientific gut feeling
is that it depends a lot on the quality of the IT
org doing the on premise.
Regarding capacity, then that should not be a problem with
the big public cloud providers.
At the scale they operate then demand is very predictable.
If you run thousands of VM's then they could all need more
power at the same time.
But if you run millions of VM's then load evens out.
Arne
There is one thing you always fail to mention.

In house, I got a wire.

With the cloud, you got a communication system you have no control over.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-11 01:32:44 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
Got to wonder just what savings actually happen when the cloud isn't
available.  Yeah, yeah, you're going to say "that never happens".
Well, in my experience, when someone says "that never happens", I tend
to suspect that it indeed will happen.
Computers in cloud can go down. So can dedicated computers.
The public cloud providers provide redundancy options. Not choosing
one comes with a risk. So does not having redundancy for an
on premise solution.
Even with redundancy something can go wrong with failover.
It happens with cloud . It happens with on premise.
It cloud overall more risky than on premise?
That is a good question. My non-scientific gut feeling
is that it depends a lot on the quality of the IT
org doing the on premise.
Regarding capacity, then that should not be a problem with
the big public cloud providers.
At the scale they operate then demand is very predictable.
If you run thousands of VM's then they could all need more
power at the same time.
But if you run millions of VM's then load evens out.
There is one thing you always fail to mention.
In house, I got a wire.
With the cloud, you got a communication system you have no control over.
Relevant argument.

If the on-premise solution does not rely on external
networking:
* not exposing any services to external parties (B2C or B2B)
* not consuming any external B2B services
* single location

Then on-premise should have fewer network problems
than the equivalent cloud solution, because the network
is much simpler.

Arne
Craig A. Berry
2019-02-10 15:02:17 UTC
Permalink
Post by Arne Vajhøj
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
I do. And I also think somebody else already mentioned it briefly.
I don't see people lined up to use that solution.
But of course it can be said that something exists - just
not part of base VMS.
Try HELP SYSTEM_SERV $REGISTRY. Or start at page SYS-292 of the doc
currently still residing at:

<https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623201>


The fact that it's a documented system service does give the impression
that it's part of base VMS. But it involves event flags,
item lists, and IOSBs. Paths are specified and returned in UCS-4, or at
least I think that's what they must mean when they say they are Unicode
strings and "A Unicode character is 4 bytes long." Which I guess means
you have to build them as arrays of integers. It involves either having
SYSPRV or supplying "an NT access token," whatever that means.

There is some more information about how to use it here:

http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/6539/6539pro_004.html

but the management utility documented there seems not to exist on V8.4-2L1:

$ RUN SYS$SYSTEM:REG$CP
%DCL-W-ACTIMAGE, error activating image SYS$SYSTEM:REG$CP
-CLI-E-IMAGEFNF, image file not found
$2$DKA7:[SYS0.SYSCOMMON.][SYSEXE]REG$CP.EXE;

So maybe one does have to install additional components from the NT
Affinity era to actually use the registry. I don't know and can't tell
from the long-abandoned docs what is available or required.

So for many reasons, it would actually be less painful to just find and
port some preferences library and bundle it with your app.
Arne Vajhøj
2019-02-10 15:26:40 UTC
Permalink
Post by Arne Vajhøj
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
I do. And I also think somebody else already mentioned it briefly.
I don't see people lined up to use that solution.
But of course it can be said that something exists - just
not part of base VMS.
Try HELP SYSTEM_SERV $REGISTRY.  Or start at page SYS-292 of the doc
<https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623201>
The fact that it's a documented system service does give the impression
that it's part of base VMS.  But it involves event flags,
item lists, and IOSBs.  Paths are specified and returned in UCS-4, or at
least I think that's what they must mean when they say they are Unicode
strings and "A Unicode character is 4 bytes long."  Which I guess means
you have to build them as arrays of integers.  It involves either having
SYSPRV or supplying "an NT access token," whatever that means.
http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/6539/6539pro_004.html
$ RUN SYS$SYSTEM:REG$CP
%DCL-W-ACTIMAGE, error activating image SYS$SYSTEM:REG$CP
-CLI-E-IMAGEFNF, image file not found
$2$DKA7:[SYS0.SYSCOMMON.][SYSEXE]REG$CP.EXE;
So maybe one does have to install additional components from the NT
Affinity era to actually use the registry.  I don't know and can't tell
from the long-abandoned docs what is available or required.
8.4 Alpha has the image, but:

$ RUN SYS$SYSTEM:REG$CP
%DCL-W-ACTIMAGE, error activating image NTA$SECSHRP
-CLI-E-IMGNAME, image file
ARNE1$DKA0:[SYS0.SYSCOMMON.][SYSLIB]NTA$SECSHRP.EXE;1
-SYSTEM-F-PROTINSTALL, protected images must be installed

But I suspect that error would go away if I did a:

$ @sys$startup:reg$startup.com

So it seems to be part of base for Alpha.

Arne
j***@yahoo.co.uk
2019-02-10 17:30:53 UTC
Permalink
Post by Craig A. Berry
Post by Arne Vajhøj
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
I do. And I also think somebody else already mentioned it briefly.
I don't see people lined up to use that solution.
But of course it can be said that something exists - just
not part of base VMS.
Try HELP SYSTEM_SERV $REGISTRY. Or start at page SYS-292 of the doc
<https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623201>
The fact that it's a documented system service does give the impression
that it's part of base VMS. But it involves event flags,
item lists, and IOSBs. Paths are specified and returned in UCS-4, or at
least I think that's what they must mean when they say they are Unicode
strings and "A Unicode character is 4 bytes long." Which I guess means
you have to build them as arrays of integers. It involves either having
SYSPRV or supplying "an NT access token," whatever that means.
http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/6539/6539pro_004.html
$ RUN SYS$SYSTEM:REG$CP
%DCL-W-ACTIMAGE, error activating image SYS$SYSTEM:REG$CP
-CLI-E-IMAGEFNF, image file not found
$2$DKA7:[SYS0.SYSCOMMON.][SYSEXE]REG$CP.EXE;
So maybe one does have to install additional components from the NT
Affinity era to actually use the registry. I don't know and can't tell
from the long-abandoned docs what is available or required.
So for many reasons, it would actually be less painful to just find and
port some preferences library and bundle it with your app.
TL;DR: how many wheels really need reinventing?

Thank you for reminding folk that initialisation scripts and
preferences stores aren't quite the same, and that much of
this stuff already exists out there, even if it is not blessed
by the One True Faith merchants (One True OS, One True
Programming Language, One True Alphabet, etc).

For the very reason you mentioned in an earlier post, let's
also put initialisation scripts to one side, for now.

I entirely accept that a DIY-per-app approach, subject to
licencing etc, "could actually be less painful, to just find
and port some preferences library and bundle it with your
app."

Would there be more return on investment for some circumstances
if (e.g.) relevant bits of something like Qt [0] were to be
reborn on VSIVMS?

Why Qt? No particular reason, except it's something which exists
and is in use today (albeit maybe not on today's VSIVMS, but Qt
was built with platform independence in mind, and it did even
exist in a VMS flavour for a while).

E.g. for a preferences store maybe there's the Qsettings class
which may or may not map on to what's being called "preferences"
in this discussion.

If not (e.g.) Qt, fair enough (it's total overkill just for
settings), then what else might come close?

And who would have to develop+support it for it to be widely
acceptable in the (VMS?) marketplace?

Have a lot of fun.


[0] https://en.wikipedia.org/wiki/Qt_(software)
Arne Vajhøj
2019-02-10 18:00:02 UTC
Permalink
Post by j***@yahoo.co.uk
Would there be more return on investment for some circumstances
if (e.g.) relevant bits of something like Qt [0] were to be
reborn on VSIVMS?
Why Qt? No particular reason, except it's something which exists
and is in use today (albeit maybe not on today's VSIVMS, but Qt
was built with platform independence in mind, and it did even
exist in a VMS flavour for a while).
E.g. for a preferences store maybe there's the Qsettings class
which may or may not map on to what's being called "preferences"
in this discussion.
If not (e.g.) Qt, fair enough (it's total overkill just for
settings), then what else might come close?
And who would have to develop+support it for it to be widely
acceptable in the (VMS?) marketplace?
Having Qt on VMS would be great.

But I don't think it would solve a general problem.

Qt is very much its own.

It is C++ and it a very specific way of C++.

Arne
Paul Hardy
2019-02-10 08:34:37 UTC
Permalink
Post by p***@gmail.com
but how do you type an underscore on an iPad?
Hit 123 then #+= to get keyboard with graphic characters like _ (typed on
iPad).
--
Paul at the paulhardy.net domain
Stephen Hoffman
2019-02-11 20:49:05 UTC
Permalink
On 2019-02-10 03:16:24 +0000, ***@gmail.com said:

There's also an X Window API for reading configuration data around.

Not so good for storing it, though.

Please don't ask what that X API routine name might be, as it's been
over a decade since I've last used it.

There are almost certainly other alternatives in arcane corners, for
for reading in configuration data though not for writing it.

Which means folks create the VMS MAIL database, various $INIT files,
and other sorts of app-specific schemes.
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Can't say I'm all that enamored of the command-line syntax, but... whatever.

$ RUN SYS$SYSTEM:REG$CP
CREATE VALUE/NAME=REGISTRY$LOCAL_MACHINE/TYPE=DWORD/DATA=%D1000000 {etc}

...And it's system-wide.

...And I don't even want to think about having to manage access into
that, particularly in the absence of COM and/or in the absence whatever
undoubtedly-now-ancient NT authentication support might be implemented
here.

...And I'm not inclined to build my own wrappers around the $registry
system service API.
Post by p***@gmail.com
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
Something akin to COM is probably where OpenVMS is headed, but that's
fodder for another discussion or three, and a decade of development
effort.
Post by p***@gmail.com
There was a registry-server process and system services $REGISTRY and
$REGISTRYW all cluster aware, with automatic failover.
https://www.itec.suny.edu/scsys/vms/OVMSDOC0731/731final/6539/6539pro_010.html#oreg_intro_c


If I'm headed in that direction and with that $registry system service
API and with the creation of my own wrappers, I'd likely use RMS. Or
port an existing scheme, or just create my own scheme, following the
usual divergent-and-bespoke approach.

And I can use subsystem identifiers and/or file protections and/or
installed images to manage access to configuration data in an RMS file.

And for the adventurous wag that might well be considering offering it
as an alternative to the registry API, no, LDAP isn't a good fit here.

As for the Objective C code, I'll see about posting up some example
code, around what folks are accustomed to working with elsewhere.
Though that code posting will likely not be happening for the next day
or three.
Post by p***@gmail.com
but how do you type an underscore on an iPad?
On iOS 12 on an iPad... Press the [.?123] key. The underscore is on
the "secondary" keyboard view. Another reply here suggested [123] and
then [#+=], and that's more typical of the condensed keyboard used on
iPhone and a "tertiary" keyboard view

The keyboard layouts vary by device.

There are add-on mechanical keyboards available, and various ways to
connect with those.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2019-02-11 23:06:33 UTC
Permalink
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
Phil
but how do you type an underscore on an iPad?
You borrow your buddy's Andriod.
Mark Berryman
2019-02-11 23:49:03 UTC
Permalink
Post by Bob Koehler
Post by p***@gmail.com
The code for a vms registry has already been written (for good or bad)
Doesn't anyone remember "Advanced Server" and "COM for OpenVMS"
There was a registry-server process and system services $REGISTRY and $REGISTRYW
all cluster aware, with automatic failover.
Phil
but how do you type an underscore on an iPad?
You borrow your buddy's Andriod.
I just press the underscore key.
Arne Vajhøj
2019-02-10 03:25:09 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Regardless, I still must write code to read the ini file.  Yes, there
is things such as "AppPath" to help find an ini file, but, that's
basically a "logical name" as far as usage is concerned.  Hmmm....
perhaps logical names aren't so bad after all?
So, WEENDOZE and VB have provided the equivalent of logical names, and
a programmer setting up to read parameters from some external data
store.   Actually, I've been doing that on VMS since the late 1970s.
The need for user specified parameters was recognized, and addressed,
long ago. So, what's new here?
I don't think anyone is claiming anything to be new.
I hope not, cause the usage is rather ancient.  For me at least.
Post by Arne Vajhøj
The claim is that a preferences framework and API are useful.
To me, the terms framework and API seem to be more than a bit of
overkill for this tactic.
It is what is being asked for:
* a standard API used by all applications
* using a framework (= library + guidelines on usage)
Post by Arne Vajhøj
* it requires less work for application developers compared to when
   they need to create their own
* it strongly encourages all applications to use the same framework -
   that makes life a bit easier for running systems with applications
   from many vendors
Post by Dave Froble
Actually, our solution used a single data store, you know, sort of
like a database, rather than a separate text file for each program.  I
guess the only problem with our long time and still working well
solution is that it, wait for it, "bespoke".  Oh, no, we are DOOMED,
it's "BESPOKE"!
One per applications vs central is an ongoing debate.
The only thing I see here is that I and others are already doing these
things, and then along come others who want us to use different tools.
If a tool is flexible enough to handle all requirements, why should
anyone take up another tool?
There is no high level dedicated tool today.

There are multiple low level constructs that require
people to write their own wrappers.

Which is unnecessary work.

And worse - we end up with different frameworks - like one per
vendor.

Arne
Arne Vajhøj
2019-02-10 04:15:10 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Actually, our solution used a single data store, you know, sort of
like a database, rather than a separate text file for each program.  I
guess the only problem with our long time and still working well
solution is that it, wait for it, "bespoke".  Oh, no, we are DOOMED,
it's "BESPOKE"!
One per applications vs central is an ongoing debate.
There are pro and con for both.
Database is certainly also a possibility.

There are also a few Java prefs implementation for
database, but if one does not like them, then one
can easily create ones own.

$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 5.1.46-log Source distribution

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.

mysql> use test;
Database changed
mysql> select * from prefs;
+------+------+------+----------+
| tree | app | pkey | pvalue |
+------+------+------+----------+
| arne | demo | a | 123 |
| arne | demo | b | ABC |
| arne | demo | src | Database |
+------+------+------+----------+
3 rows in set (0.00 sec)

mysql> exit
Bye
$
$ type
[.demo]databasepreferencesfactory.java,[.demo]databasepreferences.java
package demo;

import java.util.prefs.Preferences;
import java.util.prefs.PreferencesFactory;

public class DatabasePreferencesFactory implements PreferencesFactory {
public Preferences systemRoot() {
return new DatabasePreferences(null, "", "-");
}
public Preferences userRoot() {
return new DatabasePreferences(null, "",
System.getProperty("user.name"));
}
}

DISK2:[ARNE.DEMO]DATABASEPREFERENCES.JAVA;1

package demo;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;
import java.util.prefs.AbstractPreferences;
import java.util.prefs.BackingStoreException;

public class DatabasePreferences extends AbstractPreferences {
private String tree;
private String name;
private String url;
private String user;
private String password;
private void update(String sql, String... params) {
try {
Connection con = DriverManager.getConnection(url, user,
password);
PreparedStatement pstmt = con.prepareStatement(sql) ;
for(int i = 0; i < params.length; i++) {
pstmt.setString(i + 1, params[i]);
}
pstmt.executeUpdate();
pstmt.close();
con.close();
} catch (SQLException e) {
throw new RuntimeException("SQL exception", e);
}
}
private String[] query(String sql, String... params) {
try {
List<String> res = new ArrayList<String>();
Connection con = DriverManager.getConnection(url, user,
password);
PreparedStatement pstmt = con.prepareStatement(sql) ;
for(int i = 0; i < params.length; i++) {
pstmt.setString(i + 1, params[i]);
}
ResultSet rs = pstmt.executeQuery();
while(rs.next()) {
res.add(rs.getString(1));
}
pstmt.close();
con.close();
return res.toArray(new String[res.size()]);
} catch (SQLException e) {
throw new RuntimeException("SQL exception", e);
}
}
public DatabasePreferences(AbstractPreferences parent, String name,
String tree) {
super(parent, name);
this.tree = tree;
this.name = name;
url = System.getProperty("dbp.url");
user = System.getProperty("dbp.user");
password = System.getProperty("dbp.password");
try {
Class.forName(System.getProperty("dbp.driver"));
} catch (ClassNotFoundException e) {
throw new RuntimeException("Database driver not found");
}
}
@Override
protected void putSpi(String key, String value) {
if(!name.equals("")) {
update("INSERT INTO prefs(tree,app,pkey,pvalue) VALUES
(?,?,?,?)", tree, name, key, value);
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected String getSpi(String key) {
if(!name.equals("")) {
String[] res = query("SELECT pvalue FROM prefs WHERE tree =
? AND app = ? AND pkey = ?", tree, name, key);
if(res.length > 0) {
return res[0];
} else {
return null;
}
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected void removeSpi(String key) {
if(!name.equals("")) {
update("DELETE FROM prefs WHERE tree = ? AND app = ? AND
pkey = ?", tree, name, key);
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected void removeNodeSpi() throws BackingStoreException {
if(!name.equals("")) {
update("DELETE FROM prefs WHERE tree = ? AND app = ?",
tree, name);
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected String[] keysSpi() throws BackingStoreException {
if(!name.equals("")) {
return query("SELECT pkey FROM prefs WHERE tree = ? AND app
= ?", tree, name);
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected String[] childrenNamesSpi() throws BackingStoreException {
if(!name.equals("")) {
return query("SELECT DISTINCT app FROM prefs WHERE tree =
?", tree);
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected AbstractPreferences childSpi(String name) {
if(this.name.equals("")) {
return new DatabasePreferences(this, name, tree);
} else {
throw new RuntimeException("Only two level keys supported");
}
}
@Override
protected void syncSpi() throws BackingStoreException {
// nothing
}
@Override
protected void flushSpi() throws BackingStoreException {
// nothing
}
}
$ javac "demo/DatabasePreferencesFactory.java"
"demo/DatabasePreferences.java"
$ java -
-cp .:mysql-connector-java-5_1_36-bin.jar -
"-Djava.util.prefs.PreferencesFactory=demo.DatabasePreferencesFactory" -
"-Ddbp.driver=com.mysql.jdbc.Driver" -
"-Ddbp.url=jdbc:mysql://localhost/Test" -
"-Ddbp.user=root" -
"-Ddbp.password=xxxxxx" -
"demo.PrefsDemo"
123 ABC
Database
demo.DatabasePreferences
$

Arne
Arne Vajhøj
2019-02-10 01:32:05 UTC
Permalink
Post by Dave Froble
There's no preferences file API.  Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator.  Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend.   And
no, logical names are not a preferences API.
Got to ask, what is a "preferences file API" ???
A standardized way to store values for keys.

Usually with hierarchical keys and type safe access to values.
Post by Dave Froble
Itemlists.  Did I mention itemlists?  I dislike itemlists.  Passing
arguments in hand-rolled data structures is far too reminiscent of
writing assembler code.  And about as tedious and as voluminous.  And
then there's the lack of a parser.  And the lack of language support.
Descriptor support is only marginally better than itemlist support,
outside of BASIC and whichever other languages where it's been
integrated. But itemlists haven't been integrated anywhere.
Ooops, perhaps your favorite rant.  But, at the risk of encountering
your use of "bespoke" similar to the way others use "legacy", perhaps
        Record SockOpt                                  !  Socket options
                Word    ReuseAdrLen%
                Word    ReuseAdrType%
                Long    ReuseAdrAdr%
                Word    ReusePortLen%
                Word    ReusePortType%
                Long    ReusePortAdr%
                Word    ShareLen%
                Word    ShareType%
                Long    ShareAdr%
        End Record
The RECORD construct in Basic appears to be a decent solution, wouldn't
you say?
I won't.

That sort of data structures are too couple with the implementation.

If the implementation changes in a way that require the data structure
to be changed then everything breaks.

Modern OO is way better to encapsulate such things.

Arne
Carl Friedberg
2019-02-09 13:43:38 UTC
Permalink
Hoff, thanks for the list of futures. We used to have something at VAX
Magic, but sadly this is all history from decades ago. Now, I hope the
folks in Bolton are listening. I hope they will take up a list of 10 most
important new features. Alas, there's no DECUS, and the Bootcamp thing
doesn't get the widespread audience we need for this. Even the Bootcamp has
been in holding mode. Thanks again for your feature list.

Carl

On Fri, Feb 8, 2019 at 12:15 PM Stephen Hoffman via Info-vax <
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
There's no job scheduler. Yes, I'm aware of the add-ons. No, batch
isn't a scheduler. Batch was good enough and was useful for what we
were doing back in the early VAX era, but our needs have changed.
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons. And the system service API follows the usual OpenVMS
model of glorious flexibility at the cost of simplicity and ease of use
for common tasks.
Itemlists. Did I mention itemlists? I dislike itemlists. Passing
arguments in hand-rolled data structures is far too reminiscent of
writing assembler code. And about as tedious and as voluminous. And
then there's the lack of a parser. And the lack of language support.
Descriptor support is only marginally better than itemlist support,
outside of BASIC and whichever other languages where it's been
integrated. But itemlists haven't been integrated anywhere.
Logging. Like storing preferences, there's no single way to do this,
and which means that everybody does it differently. And there's bupkis
for collecting logging data and app crash data from multiple OpenVMS
servers. Yes, I know from syslog, syslog-ng, and ilk.
On-going grumbles including inadequate development tooling and
inadequate compilers and crash-handling and patch-handling also all
apply.
The results of these limits for app developers? App tooling that is a
fraction of what it can and should be, and apps that tend to be
brittle, and apps that take longer than they should to develop and to
test.
--
Pure Personal Opinion | HoffmanLabs LLC
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
--
www.comets.com
Arne Vajhøj
2019-02-10 01:15:35 UTC
Permalink
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of the
add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.

Arne
Dave Froble
2019-02-10 02:45:56 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2019-02-10 03:10:20 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.

bill
Dave Froble
2019-02-10 05:55:47 UTC
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
Which perhaps might have nothing to do with apps. How about
sycronization of tasks, for just one thing?
--
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
2019-02-11 13:16:04 UTC
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured

People write entire applications in Python...

Now, if DCL was as capable as Python...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Jan-Erik Söderholm
2019-02-11 13:24:33 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
Simon.
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.

Python is a programming language. Of course there are applications
written in it, just as in any other programming language.

DCL will never be, and doesn't need to be as capable as, a
programming language. It can be used to embedd and run Python
applications, that is what we are doing.
Dave Froble
2019-02-11 14:09:04 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
Simon.
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Post by Jan-Erik Söderholm
DCL will never be, and doesn't need to be as capable as, a
programming language. It can be used to embedd and run Python
applications, that is what we are doing.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-11 14:56:50 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
No. Yes. Likely.

No - standard Python language does not come with DLM API.

Yes - it is possible to extend CPython implementation with OS
specific modules implemented in C and JFP's VMS port of CPython
has a vms.newstarlet.enqw function, which I expect to call
SYS$ENQW.

Likely - I don't know how to call it and a few tests all
gave me SS$_INSFARG, but given that the return code makes
sense then I assume that it actually does work.

Arne
Arne Vajhøj
2019-02-12 02:34:56 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Jan-Erik Söderholm
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
No. Yes. Likely.
No - standard Python language does not come with DLM API.
Yes - it is possible to extend CPython implementation with OS
specific modules implemented in C and JFP's VMS port of CPython
has a vms.newstarlet.enqw function, which I expect to call
SYS$ENQW.
Likely - I don't know how to call it and a few tests all
gave me SS$_INSFARG, but given that the return code makes
sense then I assume that it actually does work.
Jython with my VMS call library does work.

$ jython
Jython 2.5.4rc1 (2.5:723492dbab02, Feb 8 2013, 10:13:55)
[Fast VM (Hewlett-Packard Company)] on java1.5.0
Type "help", "copyright", "credits" or "license" for more information.
Post by Arne Vajhøj
Post by Dave Froble
Post by Jan-Erik Söderholm
from vms import *
lckid = syssrv.SYS__ENQW('TESTLOCK','EXMODE').result
syssrv.SYS__DEQ(lckid).status
1

Does what it looks like it does.

(yes - I like simple API's)

Arne
Jan-Erik Söderholm
2019-02-11 15:25:22 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does.  I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
Simon.
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the works,
let me ask, can the DLM be used in a program written with Python?
Yes, indirectly. If you use any tool that used the DLM. Such as
the Rdb interface. Or as mentioned by Arne, the ENQ system calls.

But I have a very hard time seeing Python use direct DLM calls.
If there are such, I have no knowledge of calling DLM directly.
Not something I'd expect an application programmer doing (today).
Arne Vajhøj
2019-02-11 16:17:47 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Yes, indirectly. If you use any tool that used the DLM. Such as
the Rdb interface. Or as mentioned by Arne, the ENQ system calls.
But I have a very hard time seeing Python use direct DLM calls.
If there are such, I have no knowledge of calling DLM directly.
As I wrote it seems to be possible.
Post by Jan-Erik Söderholm
Not something I'd expect an application programmer doing (today).
The typical business application programmer would not need it as
the typical business application would use some platform software
or framework that provides the necessary cluster capabilities.

But the programmers developing those platform software and
frameworks certainly need to.

Databases, application servers, memory grids etc..

Arne
Dave Froble
2019-02-11 18:17:52 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
Simon.
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Yes, indirectly. If you use any tool that used the DLM. Such as
the Rdb interface. Or as mentioned by Arne, the ENQ system calls.
But I have a very hard time seeing Python use direct DLM calls.
If there are such, I have no knowledge of calling DLM directly.
Not something I'd expect an application programmer doing (today).
Oh, come now, you've never had to sequence anything?

Had 2 or more tasks that needed to know what each was doing?

Never needed to wait on some other task?

Well, I have, and on other than VMS, it's not so pretty.

I should not mention inter-process communications, because I'd use
something else for that, but, it's possible, using the lock value block.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2019-02-11 20:00:38 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Simon Clubley
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does.  I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
Simon.
DCL is a tool to manage applications runs in batch and some
other simpler scripting tasks.
Python is a programming language. Of course there are applications
written in it, just as in any other programming language.
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Yes, indirectly. If you use any tool that used the DLM. Such as
the Rdb interface. Or as mentioned by Arne, the ENQ system calls.
But I have a very hard time seeing Python use direct DLM calls.
If there are such, I have no knowledge of calling DLM directly.
Not something I'd expect an application programmer doing (today).
Oh, come now, you've never had to sequence anything?
Had 2 or more tasks that needed to know what each was doing?
Never needed to wait on some other task?
No, not really. We have some IPC, but that uses mailboxes.
And besides of that, some tables in the database syncronize
work over the system between processes and applications.

But anyway, we are not talkning about DCL here anymore.
Post by Dave Froble
Well, I have, and on other than VMS, it's not so pretty.
I should not mention inter-process communications, because I'd use
something else for that, but, it's possible, using the lock value block.
Bob Koehler
2019-02-11 23:14:38 UTC
Permalink
Post by Dave Froble
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Every implementation of python that I've ever seen uses files. At
the very least the python program file, and the python source file.
And on VMS, that means you're using the DLM. Even if you're not
clustered.
Dave Froble
2019-02-12 01:45:07 UTC
Permalink
Post by Bob Koehler
Post by Dave Froble
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Every implementation of python that I've ever seen uses files. At
the very least the python program file, and the python source file.
And on VMS, that means you're using the DLM. Even if you're not
clustered.
If you are using RMS files, or any file system that uses the DLM.

However, that wasn't what I asked. The DLM can be used for more than
file locking.

I believe that Arne mentioned a VMS specific routine (I guess) in Python
that invoked the DLM.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bob Koehler
2019-02-12 22:21:34 UTC
Permalink
Post by Dave Froble
Post by Bob Koehler
Post by Dave Froble
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Every implementation of python that I've ever seen uses files. At
the very least the python program file, and the python source file.
And on VMS, that means you're using the DLM. Even if you're not
clustered.
If you are using RMS files, or any file system that uses the DLM.
ODS-2 and ODS-5 use the DML, even if you're not using RMS.
Post by Dave Froble
However, that wasn't what I asked. The DLM can be used for more than
file locking.
Yes, and beats the hell out of trying to use files as locks.
Arne Vajhøj
2019-02-12 01:52:14 UTC
Permalink
Post by Bob Koehler
Post by Dave Froble
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Every implementation of python that I've ever seen uses files. At
the very least the python program file, and the python source file.
And on VMS, that means you're using the DLM. Even if you're not
clustered.
Same argument applies for DCL.

And this all started with the premise that DCL did not have
a way to interact with DLM.

Which sort of implies that it was direct explicit interaction
being asked for.

Arne
Stephen Hoffman
2019-02-13 16:07:50 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Every implementation of python that I've ever seen uses files. At the
very least the python program file, and the python source file. And on
VMS, that means you're using the DLM. Even if you're not clustered.
Same argument applies for DCL.
And this all started with the premise that DCL did not have a way to
interact with DLM.
Which sort of implies that it was direct explicit interaction being asked for.
I'd prefer to be able to sequence tasks through some built-in means,
which on OpenVMS would likely be the lock manager. And maybe a job
scheduler past batch.

I'd prefer to avoid sequencing tasks with certain mechanisms, not the
least of which includes SYNCHRONIZE and lock files.

I really don't care about Python and the DLM in this particular current
context and which is why I specified DCL. Not Python, nor Java, nor
Ada, nor Pascal, nor languages other than DCL. Hence my reference to
DCL.

Though I'd fully expect Python can already interact more directly with
the DLM, or that'd it'd be feasible to add that with the available
source code. Open source is like that, after all. OpenVMS, not so
much.

With OpenVMS, I'm writing ever-increasing hunks of code for features
that are increasingly provided on other platforms. We all are. Many of
us have been doing that incrementally for decades, too. With extensive
libraries.

The necessity of which makes for a bigger hurdle for newer adoptions.
Most of the existing bespoke-code and locally-added support is weaker
and less capable and often less secure than it should be, too.

Similar less-than-it-should-be situations have repeatedly arisen within
OpenVMS itself. But I digress.

And this makes for some unfortunate holes in DCL and the DLM and
clustering, for those of us with existing apps.

But for now, I'm using lock files. And cleaning up lock files.

Or I'm rolling another and larger hunk of code to provide bespoke
sequencing via DLM. Which inevitably means another trip down itemlist
lane, too.

Ah, fun.

Aren't compromises and trade-offs wonderful?
--
Pure Personal Opinion | HoffmanLabs LLC
a***@yahoo.com
2019-02-13 16:19:13 UTC
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Post by Dave Froble
So, sitting here, wondering how I can throw another wrench into the
works, let me ask, can the DLM be used in a program written with Python?
Every implementation of python that I've ever seen uses files. At the
very least the python program file, and the python source file. And on
VMS, that means you're using the DLM. Even if you're not clustered.
Same argument applies for DCL.
And this all started with the premise that DCL did not have a way to
interact with DLM.
Which sort of implies that it was direct explicit interaction being asked for.
I'd prefer to be able to sequence tasks through some built-in means,
which on OpenVMS would likely be the lock manager. And maybe a job
scheduler past batch.
I'd prefer to avoid sequencing tasks with certain mechanisms, not the
least of which includes SYNCHRONIZE and lock files.
I really don't care about Python and the DLM in this particular current
context and which is why I specified DCL. Not Python, nor Java, nor
Ada, nor Pascal, nor languages other than DCL. Hence my reference to
DCL.
Though I'd fully expect Python can already interact more directly with
the DLM, or that'd it'd be feasible to add that with the available
source code. Open source is like that, after all. OpenVMS, not so
much.
With OpenVMS, I'm writing ever-increasing hunks of code for features
that are increasingly provided on other platforms. We all are. Many of
us have been doing that incrementally for decades, too. With extensive
libraries.
The necessity of which makes for a bigger hurdle for newer adoptions.
Most of the existing bespoke-code and locally-added support is weaker
and less capable and often less secure than it should be, too.
Similar less-than-it-should-be situations have repeatedly arisen within
OpenVMS itself. But I digress.
And this makes for some unfortunate holes in DCL and the DLM and
clustering, for those of us with existing apps.
But for now, I'm using lock files. And cleaning up lock files.
Or I'm rolling another and larger hunk of code to provide bespoke
sequencing via DLM. Which inevitably means another trip down itemlist
lane, too.
Ah, fun.
Aren't compromises and trade-offs wonderful?
--
Pure Personal Opinion | HoffmanLabs LLC
Small OT question.
Why do you continue to prefix "VMS" with "Open" ?
Or should I ask why nobody except you prefixes VMS with "Open" ?
Stephen Hoffman
2019-02-13 17:13:00 UTC
Permalink
Post by a***@yahoo.com
Why do you continue to prefix "VMS" with "Open" ?
Or should I ask why nobody except you prefixes VMS with "Open" ?
Having dealt with various ™ and ℠ and logo requirements over the years,
the owners of the marks and logos tend to get cranky about misuse of
marks and logos.

The official product name was still "OpenVMS", when last I checked.

I'll use VAX/VMS and MicroVMS, when I'm specifically referring to those
products.

The same holds for references to Arm and Db2 and Microsoft Windows and
other products, for that matter.

And beyond the official product and service names and far more
pragmatically, OpenVMS is a whole lot easier to search for than is VMS.

Though entertainingly, some folks did recently launch an entirely
unrelated "OpenVMS" software product. http://openvms.team
--
Pure Personal Opinion | HoffmanLabs LLC
a***@yahoo.com
2019-02-13 17:26:53 UTC
Permalink
Post by Stephen Hoffman
Post by a***@yahoo.com
Why do you continue to prefix "VMS" with "Open" ?
Or should I ask why nobody except you prefixes VMS with "Open" ?
Having dealt with various ™ and ℠ and logo requirements over the years,
the owners of the marks and logos tend to get cranky about misuse of
marks and logos.
o.k.
Post by Stephen Hoffman
The official product name was still "OpenVMS", when last I checked.
I'll use VAX/VMS and MicroVMS, when I'm specifically referring to those
products.
The same holds for references to Arm and Db2 and Microsoft Windows and
other products, for that matter.
If you want to be pedantic, it's ARM rather than Arm.
Post by Stephen Hoffman
And beyond the official product and service names and far more
pragmatically, OpenVMS is a whole lot easier to search for than is VMS.
Sure, in general. Less important in this newsgroup.
Post by Stephen Hoffman
Though entertainingly, some folks did recently launch an entirely
unrelated "OpenVMS" software product. http://openvms.team
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2019-02-13 17:56:07 UTC
Permalink
Post by a***@yahoo.com
Post by Stephen Hoffman
The same holds for references to Arm and Db2 and Microsoft Windows and
other products, for that matter.
If you want to be pedantic, it's ARM rather than Arm.
https://www.arm.com/company/policies/trademarks
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-02-13 18:16:21 UTC
Permalink
Post by Stephen Hoffman
Post by a***@yahoo.com
Why do you continue to prefix "VMS" with "Open" ?
Or should I ask why nobody except you prefixes VMS with "Open" ?
One might guess that anyone who worked in VMS Engineering just might
have had that beaten into them, just a bit?
Post by Stephen Hoffman
Having dealt with various ™ and ℠ and logo requirements over the years,
the owners of the marks and logos tend to get cranky about misuse of
marks and logos.
The official product name was still "OpenVMS", when last I checked.
I'll use VAX/VMS and MicroVMS, when I'm specifically referring to those
products.
The same holds for references to Arm and Db2 and Microsoft Windows and
other products, for that matter.
And beyond the official product and service names and far more
pragmatically, OpenVMS is a whole lot easier to search for than is VMS.
Though entertainingly, some folks did recently launch an entirely
unrelated "OpenVMS" software product. http://openvms.team
Do you think they would have chosen that name if they were of an OS
named OpenVMS? I'd guess not. Disappointing ....
--
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
2019-02-13 18:59:52 UTC
Permalink
Post by Dave Froble
Post by a***@yahoo.com
Why do you continue to prefix "VMS" with "Open" ?
Or should I ask why nobody except you prefixes VMS with "Open" ?
One might guess that anyone who worked in VMS Engineering just might
have had that beaten into them, just a bit?
Proper mark and local usage is common training for the folks writing
docs and marketing materials, and working with and delivering
presentations, yes.

That whether the marks and brands are associated with the local
organization, or are references to those of other entities.

For the owners of the marks and logos, consistent and proper use helps
sustain and can help build the value of the brand.

Proper usage can also show attention to detail. Misspellings and brand
and logo misusage in a product or presentation, not so much.

And misuse of a ® can and has resulted in loss.

Properly using marks is also commonly intended to be respectful of the owners.

This even if an associated comment might be less than entirely complimentary.

Similar considerations apply to the usage of people's preferred
pronouns, and the names and nicknames we use to reference ourselves and
other humans. But I digress.

Depending on the usage or context, references can be be interpreted as
respectful, familiar, disconcerting, threatening, hostile, or
disrespectful.
--
Pure Personal Opinion | HoffmanLabs LLC
Bill Gunshannon
2019-02-11 13:50:21 UTC
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Arne
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
People here have claimed to have written entire applications in DCL,
as well. Just because someone did it doesn't make it right or a good
idea.

bill
Arne Vajhøj
2019-02-11 16:13:52 UTC
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Then you don't see just how useful the DLM can be.
I suspect he does.  I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
People here have claimed to have written entire applications in DCL,
as well.  Just because someone did it doesn't make it right or a good
idea.
I suspect that are some pretty large COM files out there.

Shall we make a little survey: how many lines in the biggest
COM file on your system?

Arne

PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
Robert A. Brooks
2019-02-11 16:25:10 UTC
Permalink
Post by Arne Vajhøj
Shall we make a little survey: how many lines in the biggest
COM file on your system?
Arne
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
AUTOGEN is over 7000 lines.

I'm not suggesting that AUTOGEN is a great example of DCL.

Now, the "real" AUTOGEN and "real" VMSINSTAL are a bit longer than that.

The versions that shipped have been run through the "DCLDIET" utility
that removes comments and what it views as unnecessary white space.

Some of us are not in love with DCLDIET, or at least the decisions it makes.
--
-- Rob
Arne Vajhøj
2019-02-11 17:27:45 UTC
Permalink
Post by Robert A. Brooks
Post by Arne Vajhøj
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
AUTOGEN is over 7000 lines.
Yuck.
Post by Robert A. Brooks
I'm not suggesting that AUTOGEN is a great example of DCL.
Now, the "real" AUTOGEN and "real" VMSINSTAL are a bit longer than that.
The versions that shipped have been run through the "DCLDIET" utility
that removes comments and what it views as unnecessary white space.
Some of us are not in love with DCLDIET, or at least the decisions it makes.
Buy why use it?

I assume that the main thing it does is to remove comments explaining
what the code does.

And that does not seem relevant to me.

The speed difference must be insignificant on todays HW.

And I do not see a big risk for IP theft - who would want to
steal VMSINSTALL and AUTOGEN??

Arne
Bill Gunshannon
2019-02-11 17:12:02 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Simon Clubley
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Then you don't see just how useful the DLM can be.
I suspect he does.  I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
People here have claimed to have written entire applications in DCL,
as well.  Just because someone did it doesn't make it right or a good
idea.
I suspect that are some pretty large COM files out there.
Shall we make a little survey: how many lines in the biggest
COM file on your system?
Arne
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
I don't think that qualifies as an application or has any need
for a DLM.

bill
Arne Vajhøj
2019-02-11 17:23:36 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
I don't think that qualifies as an application or has any need
for a DLM.
It certainly does not have a need for DLM.

I would be OK with it being called an install application.
Obvious YMMV.

But it is definitely an example of a pretty large COM file.

Arne
Dave Froble
2019-02-11 18:20:49 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Simon Clubley
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Then you don't see just how useful the DLM can be.
I suspect he does. I also suspect he sees just how wrong it is
to be writing applications serious enough to need it in DCL.
$ set response/mode=good_natured
People write entire applications in Python...
Now, if DCL was as capable as Python...
People here have claimed to have written entire applications in DCL,
as well. Just because someone did it doesn't make it right or a good
idea.
I suspect that are some pretty large COM files out there.
Shall we make a little survey: how many lines in the biggest
COM file on your system?
Arne
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
That is a "script" intended to perform multiple tasks, using DCL. I
don't think that say, a 3rd gen language would be at all appropriate.

I definitely would not call it a "program". At least that's how I see
things.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2019-02-11 18:39:40 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Simon Clubley
People write entire applications in Python...
Now, if DCL was as capable as Python...
People here have claimed to have written entire applications in DCL,
as well.  Just because someone did it doesn't make it right or a good
idea.
I suspect that are some pretty large COM files out there.
Shall we make a little survey: how many lines in the biggest
COM file on your system?
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
That is a "script" intended to perform multiple tasks, using DCL.  I
don't think that say, a 3rd gen language would be at all appropriate.
Well - the replacement seems to be so.

At least I assume that SYS$SYSTEM:PCSI$MAIN.EXE is written in
a 3 GL language.

Arne
Robert A. Brooks
2019-02-11 18:43:54 UTC
Permalink
Post by Arne Vajhøj
That is a "script" intended to perform multiple tasks, using DCL.  I don't think that say, a 3rd gen language would be at all appropriate.
Well - the replacement seems to be so.
At least I assume that SYS$SYSTEM:PCSI$MAIN.EXE is written in
a 3 GL language.
It's written in C.

I'd say that PCSI is a significant upgrade over VMSINSTAL (a low bar, admittedly) just for
the ability to remove software in a supported fashion.
--
-- Rob
Stephen Hoffman
2019-02-11 19:16:19 UTC
Permalink
Post by Robert A. Brooks
I'd say that PCSI is a significant upgrade over VMSINSTAL (a low bar,
admittedly) just for the ability to remove software in a supported
fashion.
Which PCSI really can't manage.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2019-02-11 19:11:50 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Simon Clubley
People write entire applications in Python...
Now, if DCL was as capable as Python...
People here have claimed to have written entire applications in DCL,
as well. Just because someone did it doesn't make it right or a good
idea.
I suspect that are some pretty large COM files out there.
Shall we make a little survey: how many lines in the biggest
COM file on your system?
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
That is a "script" intended to perform multiple tasks, using DCL. I
don't think that say, a 3rd gen language would be at all appropriate.
Well - the replacement seems to be so.
At least I assume that SYS$SYSTEM:PCSI$MAIN.EXE is written in
a 3 GL language.
But, I do not like the replacement. If something goes wrong, you're
stuck. With VMSINSTAL one can figure out what is wrong, and perhaps fix
it then, not when some bug gets fixed.

Yeah, yeah, we don't do that kind of stuff anymore. Just point, click,
and hope ....
--
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
2019-02-11 19:26:04 UTC
Permalink
Post by Dave Froble
But, I do not like the replacement. If something goes wrong, you're
stuck. With VMSINSTAL one can figure out what is wrong, and perhaps
fix it then, not when some bug gets fixed.
I've had "fun" figuring out what went wrong with VMSINSTAL
installations, given some DCL in some VMSINSTAL kits gets gnarly.

If the PCSI kit itself isn't corrupted, extract the PTF and PDF
files—and the rest of the kit files from the kit if needed—using
available PCSI commands, make the changes, and off you go.

VSI used a version of this approach work around kitting-related
platform dependencies, rather than updating PCSI and VMSINSTAL and LMF
to address the the reownershipping and the dependencies.

Rolling back PCSI installations is a mess, past the last couple of installs.

Reversing an install or rolling back VMSINSTAL is real work. It was
common to have files left around from failed VMSINSTAL attempts messing
up subsequent installations, too.

And none of what's available for OpenVMS with PCSI or VMSINSTAL can
verify what's installed is what was installed, or migrate what's
installed to a new system, etc.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2019-02-11 20:59:11 UTC
Permalink
Post by Arne Vajhøj
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
There are much larger .COM files out there.
Bill Gunshannon
2019-02-11 21:16:26 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
There are much larger .COM files out there.
Being a large .COM file does not make something an application.
We were talking about whether or not people should be using DCL
for real applications as opposed to real programming languages.
But, in this age of PERL, PHP, JavaScript, Python, etc. I
suppose DCL will continue to be used for things better done
differently.

bill
Arne Vajhøj
2019-02-12 01:54:34 UTC
Permalink
Post by Bill Gunshannon
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
PS: SYS$UPDATE:VMSINSTAL.COM is 3500 lines.
There are much larger .COM files out there.
Being a large .COM file does not make something an application.
We were talking about whether or not people should be using DCL
for real applications as opposed to real programming languages.
But, in this age of PERL, PHP, JavaScript, Python, etc. I
suppose DCL will continue to be used for things better done
differently.
What it should be used for and what it used for are probably
two very different things.

And I don't think large COM files is a new thing. But OK -
"the age of Perl" implies after 1987, so ...

:-)

Arne
Arne Vajhøj
2019-02-10 03:18:21 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Then you don't see just how useful the DLM can be.
I can definitely see that a DLM can be useful.

Both for OS internals and for applications.

That is a proven fact given that there are many implementations.

I just don't see the point in accessing it directly from DCL.

A clustered application written in DCL??

Arne
Dave Froble
2019-02-10 05:58:38 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Stephen Hoffman
There's no DCL CLI interface to the lock manager. Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock
manager as a widely needed feature.
Then you don't see just how useful the DLM can be.
I can definitely see that a DLM can be useful.
Both for OS internals and for applications.
That is a proven fact given that there are many implementations.
I just don't see the point in accessing it directly from DCL.
A clustered application written in DCL??
I don't believe in using DCL for apps, but for running the apps, for
sure, and as one example, sync of apps in a cluster?

The DLM is cluster aware, which is significant.

But,no, I've never wished for access to the DLM from DCL.
--
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
2019-02-11 16:52:08 UTC
Permalink
There's no DCL CLI interface to the lock manager.  Yes, I'm aware of
the add-ons.
With all due respect then I do not see DCL access to the lock manager
as a widely needed feature.
With a job scheduler with DCL integration, I'd be rather less
interested in access to locking from DCL.

But there are still uses for locking-related app coordination (well)
past what SYNCHRONIZE can provide.

Locking is one of the easiest ways to communicate state within a
cluster. And to manage counters via the lock value, for that matter.

Would I prefer to use DCL for what I often do use it for on OpenVMS?
Variously, no. But DCL is integrated.

Python, Perl, Lua and other scripting tools are each adding
dependencies. Dependencies that then need to be maintained by somebody.

Would those add-on packages be as much of an issue if there were
tooling to maintain and update ports akin to homebrew (https://brew.sh)
or such, and folks working on that tooling? No.

This is all related to and aspects to what's commonly involved when
doing app updates and app modernizations and new app development on
OpenVMS.

And to having new and different folks working on existing codebases.

And to having folks that haven't had the benefit of an incremental
introduction to the many design decisions and trade-offs inherent in an
operating system.

An aggregation of incremental decisions and trade-offs which are often
completely bizarre when viewed in their entirety. That whether
discussing a non-trivial and longstanding app, or an OS.

However that's trading off new users and new apps against existing
users and existing apps.

And trade-offs around how much code we have to design and write on
OpenVMS. Like rolling our own job scheduling and coordination. And our
own preferences and config persistence. And our own logging.

Or having to dig through the existing app designs and existing code for
coordination or persistence or logging. Or to find the flaws in that,
whether around security or race conditions or less-than-reliable app
designs.

Or to find the feature gaps and the competitive gaps.

This is all related, of course.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2019-02-11 22:59:33 UTC
Permalink
Post by Stephen Hoffman
There's no preferences file API. Which means downloading a wad of code
from elsewhere, or rolling my own and supporting my own state-machine
parser and generator. Or as happens far too often, explicit in-line
code that's less than wonderful to maintain and test and extend. And
no, logical names are not a preferences API.
Ugh, I hate references files, and applications that depend on them.
Loading...