Operating System - OpenVMS
cancel
Showing results for
Did you mean:

## Submit After Question.

SOLVED
Go to solution
Occasional Visitor

## Submit After Question.

How do I submit a procedure to run each hour at the 20'th minute. It's running fine now each hour but the minutes float a few seconds each time. When it floats too much it conflicts with another procedure.

Thanks...
10 REPLIES 10
Honored Contributor

## Re: Submit After Question.

al,

use something like this at the beginning of your procedure :-
hh =f\$cvtime("","comparison","hour")
hh = hh + 1
submit/after="today+''hh':20"/etc ....

hope this helps
Honored Contributor

## Re: Submit After Question.

> submit/after="today+''hh':20"/etc ....

To span days

\$ if hh .ne. 23
\$ then
\$ submit/after="today+''hh':20"/etc ....
\$ else
\$ submit/after="tomorrow+0:20"/etc ....
\$ endif
Honored Contributor

## Re: Submit After Question.

You do NOT want add an hour to the hours.
Let DCL do the math.

Along the same lines, but midnite proof:

\$ write sys\$output -
f\$cvtime(f\$cvtime("",,"HOUR")+":20:00 +1:0:0")

Hein.

Esteemed Contributor
Solution

## Re: Submit After Question.

\$ runmin := 20 !Run at 20 minutes after hour
\$ next_hour = f\$cvtime("+0-1","ABSOLUTE")
\$ rundate = f\$cvtime(next_hour,"ABSOLUTE","DATE")
\$ runhour = f\$cvtime(next_hour,,"HOUR")
\$ runtime = rundate+":"+runhour+":"+runmin
\$ submit job /after='runtime'

Good luck
I have one, but it's personal.
Honored Contributor

## Re: Submit After Question.

A free-running SUBMIT /AFTER is unlikely to do exactly what you want for all cases, particularly if drifting a few minutes gets you into trouble with and into conflict with other jobs. (Even if this batch job is started correctly -- and there are examples of how to do that in this thread -- there can still be a blocking batch job, reboot, or other perturbations that can throw off the actual start time.)

Better to more explicitly coordinate the jobs, with either a commercial scheduling package (various are available), or something akin to the Kronos Freeware package.

OpenVMS itself lacks a scheduling package.

The brute-force approach is to coordinate the multiple jobs that need sequencing with SYNCHRONIZE and/or with use of a single-slot batch queues and/or other similar and more explicit techniques.

Rolling your own site-specific tailored scheduling package is probably a day of coding and a day or two of testing.

Honored Contributor

## Re: Submit After Question.

the trouble is with most all of the commercial packages is finding enough justification to persuade the bean counters to hand over the money as they tend not to be too cheap, as well as taking the risk assessment ride.
depends from company to company what they like to see as far as 'legitimate' software solutions ( gartner magic quadrant, turnover in excess of ...., OEM partner etc) goes.
if you're talking about vms specific functionality among the mainstream scheduling packages it can tend to be a bit patchy - ibm's tws uses a 3rd party agent from itheon, bmc's control-m agent for vms has'nt really been updated for years and lacks most of the functionality found in their other agents on more common platforms. certainly only a handful
actually run the server part of the app on vms whether the distributed or centralised model.
if it's freeware and the app is mission critical most places won't want to touch it without the 'safety net' of a support contract. fiddling with these things natively
in dcl or otherwise will often be tolerated to a degree as long as nothing goes wrong too badly too often.
anyway a few thoughts FWIW.

Honored Contributor

## Re: Submit After Question.

Mark, that's what makes enterprise computing such an interesting and involved effort; the vast accretions of administratium require equally vast sums of money and of staff effort to bypass the inherent deadlocks. This can be inefficient yes, but quite familiar.

Sometimes doing things as they've always been done is the political win.

Sometimes doing those same tasks more efficiently trumps the status quo.
Honored Contributor

## Re: Submit After Question.

hoff,

enterprise computings going to hell in a handcart at an increasing rate of knots ! being driven by technology for technologies sake.
everybody thinks they should have it,if they have got it, most of them don't really understand what they bought into in the first place and whether they actually needed it.
it's certainly getting harder to fight your way through the fud !

:-)
Occasional Visitor

## Re: Submit After Question.

Jess Goodman's suggestion is working very well. I'll know tomorrow if it continues to the next day. Thanks for all your help.

I was a VMS exprt for 15 years and did not even know all this still existed. I went off doing different stuff and now am back doing what I was born to do. It's all slowly coming back. I walk aroung the plant and see Dec equipment that I though was all in landfills by now.
Honored Contributor

## Re: Submit After Question.

As Hoff has pointed out, you can't rely on a job starting exactly AT the /AFTER time (that's why it's "/AFTER" not "/AT"). The only thing you can say for sure it it won't run BEFORE that time, though in a cluster with badly synchronized clocks, even that isn't necessarily a given!

An alternative to using /AFTER to schedule the time for a job is to let the job run "forever" in a loop with a WAIT calculated to delay until the next scheduled time. For your case, try:

\$ mins="20" ! must be a numeric string
\$ Loop: wait 'F\$CVTIME(F\$DELTA("",F\$CVTIME(F\$CVTIME("",,"HOUR")+":"+mins+":00+"+F\$STRING(F\$CVTIME("",,"MINUTE").GES.mins)+":0:0.0","ABSOLUTE")),,"TIME")
\$ ! It is now 20 minutes past the hour
\$ ! do your stuff
\$ GOTO Loop

Depending on how accurate you need the time, I've sometimes found I need to add 100th of a second to the wait time (replace the string +":0:0.0" with +":0:0.01" to make sure it doesn't trigger just before the target time - truncation in DCL date arithmetic.

All this costs you is a process slot.

To prevent conflicts with other jobs, check out the SYNCHRONIZE command.
A crucible of informative mistakes