[Info-vax] Workload manager for VMS, Should it come with one? (or at least a Scheduler?)

[Stephen Hoffman]

On 2017-07-29 21:26:24 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of IanD
>> via Info-vax
>> Sent: July 29, 2017 8:34 AM
>> To: info-vax at rbnsn.com
>> Cc: IanD <iloveopenvms at gmail.com>
>> Subject: [Info-vax] Workload manager for VMS, Should it come with
>> one? (or at least a Scheduler?)
>> 
>> In the stone age we started with the VMS batch subsystem
>> 
> Again, job schedulers and batch subsystems are two different components.

Sure.   That's kinda the point of the comment.    A distributed 
scheduler provides a way to sequence jobs and to set appropriate 
process and resource access priorities.   Oddly enough, that subset of 
processing also known as batch.  Typically using a distributed database 
and some sort of replication.   Which means that a distributed 
scheduler is a superset of batch.   And if batch isn't enough...

>> The batch job entries are individualistic in nature, they are not 
>> associated with other entries and/or cannot be rolled up into separate 
>> classes etc making their management even more painful.
>> 
>> Should an OS like VMS come with a workload management system or at 
>> least a scheduler system that supports inter job dependencies and other 
>> such goodies?

Ayup.    The batch implementation and cron and the rest are really 
limited.   Which means porting code. purchasing a commercial package — 
DECscheduler et al was certainly nice, for its time — or porting some 
existing package over.   Or dealing with the error cases and the 
expenses of what we've written or what we've ported.

> You are asking if VSI should develop a native offering that would 
> replace a commercial product offering. ISV's really , really hate this.

Ayup.  But that's also inherent with and fundamental to competition in 
the computing business.   In an active and thriving commercial market — 
the sorts of markets that can be profitable, and that ISVs are 
interested in — competitors can and should and do arise.   Yes, even 
competition for and from the platforms folks.     It means that the 
incumbents have to continually improve their offerings, or lower their 
prices, better marketing, patents, build new offerings or new 
integration, or other such.

Discussions of adding at least limited relational database support, of 
fully integrating IP networking and which should have happened in the 
1990s, and a whole pile of other now-part-of-the-operating-system 
details all lurk here, too.

This whole scheduling discussion also ties back into clustering and the 
issues with managing and configuring that environment, and the wealth 
of potential future work to adopt expected and common tools, too.  One 
of the central reasons for clustering is to operate and to coordinate 
processes across one or more hosts, and one or more clusters, after 
all.  Making that installation and operation and scheduling easier to 
install and manage, easier for ISVs to integrate with, and more secure 
and more reliable, is better for the long-term health of OpenVMS.

I'd have commented that the current distributed scheduling situation on 
OpenVMS is almost Kafkaesque, but some might miss the joke.





-- 
Pure Personal Opinion | HoffmanLabs LLC