[Info-vax] Restrict the use of SUBMIT/USER= to one particular user.

[Stephen Hoffman]

On 2016-11-10 19:35:18 +0000, David Froble said:

> Stephen Hoffman wrote:
> 
>> and we all end up writing our own requeuing and resubmission tools, 
>> duplicate job prevention and detection, and other such, and then 
>> there's the lack of provision in OpenVMS for scheduling jobs across 
>> clusters, and then there's that the queue manager system service API 
>> is... baroque... at best, and very limited in what it provides.
> 
> This is the part that I'd like to address.  Just what's wrong with 
> people designing and implementing their own solutions?

Nothing.  If you want to spend a whole lot of time and effort doing 
something unique — like writing a custom database, for instance — have 
at.

If you'd like to use a language that requires a whole lot of effort to 
do some comparatively simple things — such as traditional C or BASIC or 
Fortran environments on OpenVMS, for that matter — good on you.

On the other hand, you'd rather utilize existing code — 
vendor-provided, or third-party or vendor-ported open source packages 
involving OS-integrated RTL services, libraries, frameworks or 
otherwise — and specifically utilizing code that has already been 
tested and debugged, and to correspondingly dedicate more of your time 
and effort and staff on the specific features and capabilities unique 
to your product, that too is your choice.

Migrations are an effort, whether it's a language migration or a 
framework migration or a platform migration, or learning new tools and 
new approaches.   Folks selecting new platforms for new deployments 
aren't selecting OpenVMS, and folks migrating existing applications off 
of OpenVMS aren't coming back any time soon.   Folks that are not 
learning new tools aren't getting the advantages of those tools, either.

> I'm not going to believe that only the OS developers can do well with 
> this task, nor that they understand everyone's requirements.

The fun here is that these capabilities are already integrated with 
other platforms, or already available with add-on frameworks.   Just 
not on OpenVMS.   Which adds to the effort of selecting and using 
OpenVMS.

> Yes, things can be improved, and they should be improved.

Ayup.    We get reports here of IoT vulnerabilities, but no comments on 
patching the local printers to avoid vulnerabilities.   We get 
discussions around running secure services and processes and access 
delegation — and which here have devolved into installing a copy of 
SUBMIT.EXE for no particularly obvious benefit to system security.   Of 
the lack of TLS or IP or web services integration.     All of these 
little problems and these little omissions tend to pile up.  Which one 
is the proverbial straw for a particular project or product?  Donno.   
I can tell you that spending a few years working on other platforms or 
with newer tools or such is a real eye-opener — sometimes due to the 
screw ups and the omissions and the problems on that platform or the 
tools, and sometimes due to the advantages and capabilities available 
on the other platform or the tools.

> But I don't expect any OS to include for example, Accounts Payable, 
> Accounts Receivable, Inventory control, General Ledger, Order 
> processing, Orbital mechanics, FTL navigation, Web Server, Email, 
> Browser, ....  (Add your apps)

I agree with about most of your list, though you're utterly and 
completely wrong about web servers and email servers, and also wrong 
about browser-related libraries and APIs.   Those areas — as well as 
distributed security — are absolutely an essential and foundational 
parts of any modern server.   HTTPS, REST and related libraries and 
services, both as clients and as servers, are basic capabilities of 
modern servers.

> And if it did, most likely the apps would not fit everyone's needs.
> 
> So, where do you draw the line?

Where?  Look at the core pieces folks are using and seeking on other 
platforms.   Capabilities that are either optional or unavailable on 
OpenVMS, but that's a part of an increasing number of applications on 
OpenVMS and particularly on other platforms where I might peel off a 
few new customers or dissuade a few existing customers from migrating.

I'd also be looking to simplify the platform, and to reduce the need to 
specifically deal with the piles of choices and site-local integration 
steps and dependency chains that OpenVMS is so fond of.   OpenVMS is 
far too fond of forcing the system manager or the developer to deal 
with utterly unnecessary choices, and to write reams of unnecessary 
glue code to get anything done.   I'd originally used a word far 
stronger than "unnecessary" there, but I'm feeling polite today.

How?  If I were sitting at VSI, I'd be looking at my 
effectively-a-rounding-error development budget, at the day-to-day 
winds and around what the existing customers will seek to hold sales 
"hostage" for, around getting the web site and sales channels and 
related going, and — longer term — at the contents of the bug tracking 
system and specific customer requirements, and firmly trying to find a 
way to bend the existing customer trend porting off the platform, and 
working on whatever I can get developed or ported and then tested and 
shipped.   The port is clearly saturating most of what VSI does have 
for staff and schedule, too.   Beyond that, I'd be particularly looking 
at areas and services that existing and new applications are 
increasingly using and depending on, which includes web services, REST 
and related communications, distributed security, Unicode, and the 
various topics I've mentioned in this and previous postings.

> Regardless of where, one size will not fit all.

Never has.  But BASIC or C or C++ or Fortran or and existing RTL calls 
and existing TLS and existing job scheduling are hilariously bad, and — 
if I'm going to be looking at OpenVMS now, or looking at OpenVMS for 
some new project in 2021 or 2026 — I may well do much better selecting 
and using another platform.  Both for features, as well as available 
staff familiarity and a host of other factors.

> What an OS can attempt to do is provide some generic capabilities, and 
> tools for users to develop their own requirements.  But even then, such 
> isn't really part of the OS.

We all need to learn that many of the approaches and foundations and 
tools that many of us presently use and assume and depend on with 
OpenVMS are not going to attract new users to the platform.   They 
haven't, they aren't, and they won't.    Times change, tools and 
frameworks and assumptions evolve.    VSI is certainly working to 
change that, but they can't get those changes out fast enough.  Some of 
the changes that OpenVMS desperately needs and that VSI will be faced 
with working on are almost certainly going to require effort and code 
changes within the existing customer and application base, too.


TL;DR: I can spend hours implementing various commonly-used operations 
on other platforms and with a fair assurance that the resulting 
(concise) code will work, or days or weeks to implement the same on 
OpenVMS with the distinct possibility or likelihood of acquiring 
dependencies and/or ongoing maintenance of the underlying code.   Not a 
good ratio, whether we're looking at the quantity of source code 
developers are maintaining, or at the delta in the differing effort 
involved across the available platform choices.


-- 
Pure Personal Opinion | HoffmanLabs LLC