OpenVMS Job Scheduler - Recomendations

[John T. Farmer]

I'm a new member of the I.T. staff at my company. The Alpha/OpenVMS 7.2-1 system has been running in a bare-bones mode for the last 6 years. By that, I mean it has the O/S (7.2-1), a COBOL compiler and network connectivity, and that's about it.

I am proposing adding a job scheduler to the mix. Besides the several promient commercial offerings, most freeware searches lead to Cron (and/or Kronos). Is this a recommended solution to pursue for job scheduling? Is this any better than the current use of the VMS Submit command? Does this require "Installation" on OpenVMS? Can someone point me to how-to documentation? I am a developer/analyst by trade, but trying to help establish operations standards in the dept.

No amount of information/suggestions will go un-appreciated. I am starting from the ground up in many areas in I.T. In most of my previous employement, these "infrastructure & tool" decisions had already been made and implemented. I just had to follow the rules. Here, we are needing to establish those rules.

Thanks,

John Farmer

[Robert Gezelter · Accepted solution]

John,

Installation on OpenVMS means different things to different people. In the systems sense, it generally means moving files into various systems directories. Your earlier comments in a different thread inquired about PCSI kits. PCSI (if memory serves, originally named PolyCenter Software Installation) is a OpenVMS component for packaging and distributing software and updates. The "installing" user uses the PRODUCT INSTALL command, with a supplied file (a PCSI file) as implicit input (the names are formulaic based upon architecture and product name).

PCSI kits can also be generated. All of the components and utilities need to generate the kits are present on a normal OpenVMS system (the utilities are documented in the OpenVMS documentation set, accessible at http://www.hp.com/go/openvms ).

Depending upon how the applications on your site are organized, adopting a job scheduling product can be easy or a major product, there is no way to determine this without a careful look at your activities. Some organizations have implemented their own job scheduling, others have not.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

Yup. A lot can be done using plain-old
SUBMIT, and even more with command procedures
which re-SUBMIT themselves.

On the other hand, a pre-fab tool which can
run something on the last Thursday of every
month can save some DCL effort.

It all depends on your actual requirements.
One method of attack might be to try to write
the DCL to do what you need. If/when that
gets cumbersome and/or frustrating, you'll
have a better idea of what to look for in a
fancy scheduling tool.

[Thomas Ritter]

John, Steve comments are similar to those I would have said 5 years ago when working for this big corporate customer. However Batch sceduling has become so complicated and would not really want to run with out our Scheduler.
We run the CA Scheduler in Server mode on all four production nodes.

$> sch
Unicenter Job Management V3.0
(C) 2002, Computer Associates International, Inc. All Rights Reserved.

SCHEDULE>

This version 3.0 is okay. The prevsion had realy problems with waited DIO being generated and some bugs when shadow merges were in progress.

I do not endorse the product, but it services us satisfactorily.

[Karl Rohwedder]

We use a port of CRON on our VMS systems (I packaged it, so I also use it :-)).
It runs o.k. and frees us from the burden to program some DCL to specify more complex scheduling requirements. If you have dependancies between jobs, esp. for jobs on other systems, a commercial product may be better suited.
CRON uses the standard batch system for actually running the jobs and is clusterware, in that a CRON daemon runs on every node (you specify), synchronized via a lock, and one of them doing the work.

You find the PCSI kit for CRON on the actual freeware disk.

regards Kalle

[Peter Barkas]

It depends on the complexity of your requirements.

I use a slightly modified version of resubmit.com and a separate routine resubmit_date.com for calculating the resubmit date which copes with 'every_week' and 'third Monday of the month' etc. See http://dcl.openvms.org/

[Malcolm Dunn]

John, I work for XuiS (www.xuis.com) and we market XS-EnterpriseSCHEDULE (known as EnterpriseSCHEDULE in the USA). So this is a fully featured commercial job scheduling product. Multi-platform, full server & client running on a variety of platforms including VMS (VAX, Alpha, Itanium), HP platforms, Windows, etc. On VMS the product gives you a whole layer of batch job management that sits on top of the cluster wide batch queue system. If you're not after a commercial product then I won't trouble you any further but if you're interested, take a look at our web site or email me at mdunn@xuis.com Cheers, Malcolm Dunn

[Jim_McKinney]

If commercial applications are considered, you should add JAMS to your list for investigation - http://www.mvpsi.com/ - my experiences with it were positive (fwiw).

[Jeffrey Goodwin]

We use JSS from Icam for scheduling and have been very happy with it.

http://h21007.www2.hp.com/dspp/mop/mop_PartnerDetails_IDX/1,2718,6308,00.html

[B Claremont]

Attached are a couple of DCL examples if you decide to try rolling your own. SUBMIT.COM is an example of how to submit a batch job with parameters.

[B Claremont]

Sorry for the incomplete previous post. It occured to me that virus scanners might not like an attachment with a .COM extension, so I combined both sample SUBMIT procedures into the attached text file. SUBMIT.COM provides an example of the DCL SUBMIT command passing a few parameters. AFTER_HOURS_BATCH_SETUP.COM is an example of a batch procedure that resubmits itself.

[Jan van den Ende]

John,

we essentially follow Steven's idea:
self re-submiiting batches.
To steer all kinds of scheduling, we wrote a DCL routine (made available at DCL.OPENVMS.ORG):

http://dcl.openvms.org/stories.php?story=04/10/15/8590853

@ with the scheduling wishes.

What can be specified, and the correct syntax for specifications, is documented in the header of the routine.


hth

Proost.

Have one on me.

jpe

[Thomas Ritter]

One of the main reasons we like the CA Scheduler is the GUI. It makes light work for Operations staff to place jobs on hold, change scheduled times, change dependancies, release jobs. We have a number of environments within the VMS cluster and during some environment outages some job streams have to be suspended. It is not the technical VMS staff which run the batch processing environments, but the Operators. This should be your focus. Who will ultimately have to manage the work flow ?

AUS 10 cents.

[Wim Van den Wyngaert]

We use JAMS from ARGENT.

Whatever you use be careful about side efects.

1) how does the system react when you abort the job ? (jams abort the schedule of e.g. every 15 minutes too).

2) how does the system react when you manually submit the job file ? (jams starts the schedule, even when it was already active).

3) can you prevent 2 jobs with the same name (and work files) from running simultaniously ?

4) Can the scheduler handle job names for which the logical name is not cluster wide defined and how does it react in cluster failover ?

5) How do you know that a job was NOT started ?

6) How does it react on time changes ?

7) how does it react after a cluster down time of a few hours ? (jams starts all jobs at the same time).

Wim

[William Webb_2]

I highly recommend JAMS.

We had over 20,000 batch jobs running per night at one of my former sites, and it ran like gangbusters.

We also did many system consolidations, and the ability to export a system's entire JAMS job and setup information, and then import it onto the target system saved us hundreds if not thousands of man-hours that keying all that stuff in would have involved.

Their tech support's great, too.

Wim is right about things you have to look out for, but most of those are going to be gotchas no matter which product you use.

WWWebb

[Thomas Ritter]

John, some really good information has been provided. Would you care to assign points ? If you feel a response is worthless assign zero points.

Years ago when we made our decision to buy a scheduler these forums were not available.

[John T. Farmer]

Ok, this may sound a little strange, but does anyone have a port of CRON/KRONOS for VMS done in COBOL? That is currently the only language we have on our Alpha with VMS7.2. I want to modify the Cron code a bit and have no access to C or Fortran (forgot which it is written in). Thanks for any ideas on this subject.

John
john dot farmer at genworth dot com

[Karl Rohwedder]

Perhaps you may use one of the testdrive systems (http://www.testdrive.hp.com) to modify the source to your needs. The CRON utility I packaged is written in C (http://www.the-rohwedders.de/downloads/index.html).

regards Kalle

[Dean McGorrill]

Hi John,
with so small amount of stuff on your
system, it might be a good time to upgrade
before you put too much on it (I'm stuck
at 7.2-1) for simple schduling I've always
just dcl'ed it. If I had 20000 jobs I wouldn't be using dcl! good luck -Dean