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

Resubmit job automatically for next day

 
Sumant M Kumar
Frequent Advisor

Resubmit job automatically for next day

I have created a com file that i ran now and its submitted a same job for tomorrow at 8pm.Now how the job will submit after that what should i do.

$submit/queue=node_batch/notify/norpint/user=system/log=dka0:[tmp]x.log dka0:[tmp]x.com/after="tomorrow+20:00"

Type x.com
Regards,
Sumant
15 REPLIES 15
Joseph Huber_1
Honored Contributor

Re: Resubmit job automatically for next day

I don't understand the question: the submit command does exactly that, execute x.com next day at 20:000h.

So what is Your question really ?
http://www.mpp.mpg.de/~huber
Sumant M Kumar
Frequent Advisor

Re: Resubmit job automatically for next day

The job should be submitted automatically every day at 8pm.So for that i want to write dcl script.

Regards,
Sumant
Joseph Huber_1
Honored Contributor

Re: Resubmit job automatically for next day

Yes, and the submit command does it, just put it at the begin or end of x.com.
(at begin, it will submit always, even if it does not execute successfull;
at the end, it will resubmit only if everything in front iof it has passed).

And avoid hardcoding queue and file location, insert this code fragment instead of the submit command:

$ this = f$environment("PROCEDURE")
$ this = this - f$parse(this,,,"VERSION")
$ qname = f$getqui("DISPLAY_QUEUE", "QUEUE_NAME","*","THIS_JOB")
$ submit 'this'/que='qname'/after=("TOMORROW+20:00")

and submit x.com ONCE from the interactive command line.
http://www.mpp.mpg.de/~huber
Jon Pinkley
Honored Contributor

Re: Resubmit job automatically for next day

Using advanced forum search for "submit daily" in the OpenVMS Forum returns quite a few relevant topics: Here are a few.

Learning to use seach tools will in general get you results much quicker than asking.

Advance search is at the top right of the page you are on.


how to submit a daily job?

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=960315

batch job to run every day automatically

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1297541

how to schedule a batch file

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1068452

Batchjob

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1133518
it depends
John Gillings
Honored Contributor

Re: Resubmit job automatically for next day

re: Joseph,

> $ this = f$environment("PROCEDURE")
> $ this = this - f$parse(this,,,"VERSION")

1+ for this sequence (and theoretically more correct, since it leaves all file specification manipulations in the hands of F$PARSE)

$ this=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))
A crucible of informative mistakes
Steven Schweda
Honored Contributor

Re: Resubmit job automatically for next day

> [...] (and theoretically more correct,
> since it leaves all file specification
> manipulations in the hands of F$PARSE)

Oh, no, it doesn't. Thanks to the wonders of
ODS5 extended file names, for a
guaranteed-correct result, you need to do
more work than "-". For example:

alp $ type a^;2.com
$ this_proc = f$environment("PROCEDURE")
$ write sys$output "t_p (orig): "+ this_proc
$ this_proc_vers = f$parse( this_proc, , , "version")
$ write sys$output "t_p (mod): "+ this_proc- this_proc_vers

alp $ @ a^;2.com
t_p (orig): DKA100:[sms]a^;2.com;2
t_p (mod): DKA100:[sms]a^.com;2

To guarantee the desired result, a different
(more complicated) method may be needed. For
example:

alp $ @ a^;3.com;3
t_p (orig): DKA100:[sms]a^;3.com;3
t_p (mod): DKA100:[sms]a^.com;3
t_p (mod2): DKA100:[sms]a^;3.com

alp $ type a^;3.com
$ this_proc = f$environment("PROCEDURE")
$ write sys$output "t_p (orig): "+ this_proc
$ this_proc_vers = f$parse( this_proc, , , "version")
$ write sys$output "t_p (mod): "+ this_proc- this_proc_vers
$ this_proc_novers = f$parse( this_proc, , , "device")+ -
f$parse( this_proc, , , "directory")+ -
f$parse( this_proc, , , "name")+ -
f$parse( this_proc, , , "type")
$ write sys$output "t_p (mod2): "+ this_proc_novers


It may be more work than it's worth (and I
even left out "NODE"), but _this_ method
actually _does_ leave all the work to
f$parse(). (So it actually does work.) It's
not the only way, but it may be simpler than
some others.

Sloppy code may be adequate, but it's good to
remember its limitations.
Steven Schweda
Honored Contributor

Re: Resubmit job automatically for next day

> $ this=F$PARSE(";",F$ENVIRONMENT("PROCEDURE"))

And if I could read, I might be dangerous.
(Or less so.)

On the other hand, it is different:

alp $ @ a^;4.com
t_p (orig): DKA100:[sms]a^;4.com;4
t_p (mod): DKA100:[sms]a^.com;4
t_p (mod2): DKA100:[sms]a^;4.com
t_p (mod3): DKA100:[sms]a^;4.com;

The trailing semi-colon may matter little,
and using the default file spec is certainly
simpler than building the whole from all the
pieces.

alp $ type a^;4.com
$ this_proc = f$environment("PROCEDURE")
$ write sys$output "t_p (orig): "+ this_proc
$ this_proc_vers = f$parse( this_proc, , , "version")
$ write sys$output "t_p (mod): "+ this_proc- this_proc_vers
$ this_proc_novers = f$parse( this_proc, , , "device")+ -
f$parse( this_proc, , , "directory")+ -
f$parse( this_proc, , , "name")+ -
f$parse( this_proc, , , "type")
$ write sys$output "t_p (mod2): "+ this_proc_novers
$ this_proc_simple = f$parse(";",f$environment("procedure"))
$ write sys$output "t_p (mod3): "+ this_proc_simple
John Gillings
Honored Contributor

Re: Resubmit job automatically for next day

Steven,

>The trailing semi-colon may matter little,

On the contrary, it matters a LOT. The trailing semi colon is an explicit "most recent version number". Whereas if it's missing, the version is unspecified, and can be therefore be inherited from somewhere else.

Consider (using your symbol names):

$ newfile1= F$PARSE("NEWFILE", this_proc_novers, some_other_filespec)
$ newfile2= F$PARSE("NEWFILE", this_proc_simple, some_other_filespec)

newfile1 will always map to the latest version of NEWFILE, whereas newfile2 can pick up a version number from some_other_filespec, which may result in a filespec which doesn't exist.

Most of the time it doesn't make sense to inherit version numbers between file specifications, so it's better to use an explcit ";" than remove the version number altogether.


FYI: I've put logged a request with OpenVMS engineering for F$PARSE to be enhanced to allow multiple fields to be returned together (there are precedents for this type of syntax in other lexical functions). It's a bit silly having to invoke $PARSE multiple times, when each instance has the complete set of fields available. If they ever action my request, this:

$ this_proc_novers = f$parse( this_proc, , , "device")+ -
f$parse( this_proc, , , "directory")+ -
f$parse( this_proc, , , "name")+ -
f$parse( this_proc, , , "type")

could become:

$ this_proc_novers = f$parse(this_proc, , , "device,directory,name,type")

which would make this kind of filename manipulation much simpler.

(though my perception of OpenVMS engineering at the moment is, unfortunately, they seem far to scared to change anything, so I'm not optimistic of ever seeing it happen).
A crucible of informative mistakes
David Jones_21
Trusted Contributor

Re: Resubmit job automatically for next day

If you assume that version will always be the last syntactic element, you can strip it via truncation:

$ this_proc = f$environment("PROCEDURE")
$ this_proc_vers = f$parse( this_proc, , ,- "version")
$ this_proc_novers = f$extract(0,-
f$length(this_proc)-f$length(this_proc_vers),-
this_proc)
I'm looking for marbles all day long.
Steven Schweda
Honored Contributor

Re: Resubmit job automatically for next day

> >The trailing semi-colon may matter little,
>
> On the contrary, it matters a LOT. [...]

Depends on what you're doing. It may matter
a LOT, or it may matter little. In a SUBMIT
command (or anyplace else without some
strange default file spec), it's closer to
"little". But I'll gladly admit that (with
available DCL features) your scheme is much
cuter than mine.

> FYI: I've put logged a request [...]

I seem to recall a discussion somewhere.
I'll just hold my breath.

> [...] my perception of OpenVMS engineering
> at the moment [...]

Probably wise. You should see some of the
Google searches from x.hp.com and y.hp.net
which get to my Web server. Scary.
Joseph Huber_1
Honored Contributor

Re: Resubmit job automatically for next day

Wow!
I thought being a tolerant person,
but never could imagine VMS programmers being pervert enough to use the version number as part of the file name.

On the other hand: why bother ?
We are not talking about some unspecified file names, parsed by some other program,
but command files parsing their own file specification: if a programmer chooses such a name, then he is shooting in his own knee.
http://www.mpp.mpg.de/~huber
Steven Schweda
Honored Contributor

Re: Resubmit job automatically for next day

> [...] but never could imagine [...]

I have a good imagination (for some things).

As I said, sloppy code may be adequate. It
depends on how careful you wish to be. (Or
need to be.)

Working on the Info-ZIP code (among other
things) tends to make me more sensitive to
the possible problems which ODS5 extended
file names can cause. (The remaining bugs
may be gone in Zip 3.1, but I won't bet on
it.)

It's not only a VMS problem. Hardly a month
goes by when someone doesn't ask on an HP-UX
(or Linux) forum how to delete a file with a
space in its name, or what to do about a
semi-colon in a file name on a CD-ROM. Shell
scripts trip over UNIX-funny file names, too.

For real fun, think about copying this VMS file to a UNIX system:

a^/b.;1

Everything's complicated.

But I digress...
Jon Pinkley
Honored Contributor

Re: Resubmit job automatically for next day

I think David's example had a line that got unwrapped

"$ this_proc_vers = f$parse( this_proc, , ,- "version")"

should be

$ this_proc_vers = f$parse( this_proc, , , "version")

(There was an embedded "-" which I am guessing was a continuation character.

John's request
------
If they ever action my request, this:

$ this_proc_novers = f$parse( this_proc, , , "device")+ -
f$parse( this_proc, , , "directory")+ -
f$parse( this_proc, , , "name")+ -
f$parse( this_proc, , , "type")

could become:

$ this_proc_novers = f$parse(this_proc, , , "device,directory,name,type")
-------

If we are asking for a change, why not include negated values, for example

$ this_proc_novers = f$parse(this_proc, , , "noversion")

I was disappointed that f$parse wasn't enhanced at the time that ODS5 was released, because the supported method of splitting the parts using multiple f$parse calls and pasting the parts back together is so cumbersome that it is rarely used.

Jon
it depends
Hoff
Honored Contributor

Re: Resubmit job automatically for next day

If you have support, please submit an enhancement request to HP to either provide this capability in OpenVMS V8.next, or to update the V8.4 documentation to describe how to roll your own SUBMIT command for these sequence, or both.

In the interim, see the previous discussions cited here and elsewhere, and look to get yourself a scheduling package rather than rolling your own. There are open-source and commercial scheduling alternatives for OpenVMS.
Sumant M Kumar
Frequent Advisor

Re: Resubmit job automatically for next day

Hi All,

Thanks for your all assistance ,just to inform you that with help of my one team member created below script.Its doing his job.

$ set noon
$ tod=f$cvtime("",,"weekday")
$ today=f$edit(tod,"UPCASE")
$ IF TODAY .EQS. "SUNDAY" THEN GOTO RESUBMIT
$ SET DEF CDB_DAT
$ sftp "-B" get-bb.com user-id@ip address
$ sho sym $status
$ RESUBMIT:
$SUBMIT/KEEP/USER=system/AFTER="TOMORROW+19:50" SYS$LOGIN:sftp-get-ib
$ PURGE SYS$LOGIN:SFTP-GET-ib.LOG/KEEP=31
$ EXIT

Regards,
Sumant