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

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 10-Nov-16 10:28 AM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Restrict the use of SUBMIT/USER= to one
> particular user.
> 
> On 2016-11-10 14:38:04 +0000,   VAXman-  @SendSpamHere.ORG
> said:
> 
> > In article <nvvd2h$ro8$1 at dont-email.me>, Stephen Hoffman
> > <seaohveh at hoffmanlabs.invalid> writes:
> >> On 2016-11-07 09:52:45 +0000, Joe said:
> >>
> >>> We have a set of application users who submit some
> application
> >>> batches on a specific user with the command
> SUBMIT/USER=APP$MGR...
> >> OpenVMS is just hilariously bad at this sort of stuff. ...
> >
> > Yeah, the batch mode processing in *ix is so much better.
> 
> This problem goes far past the rather sorry state of batch and
> print queue management on OpenVMS.
> 
> I really don't care about specific bad designs or problems on
> specific other platforms — save as something to avoid, to rethink
> or replace, if
> design is my current project portfolio.    Or as fodder for
> counter-marketing if marketing is part of my portfolio, of course.
> 
> Unfortunately for these "but {Windows, Linux, Unix, macOS,
> whatever} is worse" replies y'all are fond of, too many folks use
> the bad designs of others as an excuse for their own ineptitude
> and misfeatures or their
> own product inattention.   To many people make that
> comparison, and
> then stop.    That competitive inattention works fine for a while.
> Sometimes.   For a while.  Maybe.   Then you get competitively
> clobbered.
> 
> As for scheduling on Unix, it's not via batch.   Available tools and
> scheduling packages deal with these cases much better —
> OpenVMS is probably roughly at the same level of cron in terms
> of its in-built intra-cluster-scale scheduling — whether the add-on
> is something akin to JAMS or CA whatsit (née DECscheduler), or
> closer to what Apache Storm & Kafka & Zookeeper provide or
> what Apache Mesos & Chronos can provide for various differing
> requirements, or the OpenStack DistributedScheduler, or Quartz
> Job Scheduler, or other such add-ons for Unix and other systems
> — but OpenVMS is very limited, 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.
> 
> OpenVMS can do better than its cron-level abilities.   If the
> OpenVMS
> operating system product is to be viable and interesting to folks
> beyond the installed base — 2021 or 2026 or beyond —
> OpenVMS has to do much better, and in many areas.  This is one
> of many.
> 

While I am all for improving the scheduling / batch capabilities within OpenVMS (especially features like batch check-pointing, improved batch auditing), we also need to remember to keep in mind what Customers are actually doing these days.

Customers are not looking or deciding on future platforms based on that platforms scheduling capabilities because they are implementing cross-platform commercial schedulers that are supported on all of their platforms. The last thing they need are different schedulers in place for every platform.

Hence, while some batch/scheduler improvements are warranted, I would also suggest working closely with the various top 5 or 10 vendor scheduler products to ensure they continue to support current and future OpenVMS platforms.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com