topic Re: batch in Operating System - OpenVMS

batch

Martin Kubes — Mon, 20 Jun 2005 03:15:21 GMT

hi, I have the following problem : there is a batch job running on Alpha server and it invokes a command procedure every day, but sometimes the batch job fails, the command procedure is not started and message "Error opening primary input file SYS$INPUT, file not found" is written to log file. The command procedure is submitted this way :
$SUBMIT 'name' /AFTER="TOMORROW+23:30"/NOPRINT/KEEP/PARAMETERS=("''p1'")/LOG='logdir'
unfortunately, it happens irregularly...
thank you for any help

Re: batch

Marc Van den Broeck — Mon, 20 Jun 2005 03:24:38 GMT

Hi Martin,

can it be that it happens when you or someone else modifies the command file and purges the old version?

When you modify the file, you have to resubmit (version nr has changed and the submitted file no longer exists).

Rgds
Marc

Re: batch

Antoniov. — Mon, 20 Jun 2005 03:26:18 GMT

Martin,
in batch job SYS$INPUT is command file itself; it appears like submitted file is deleted.
Do you issue periodically purge command?

Antonio Vigliotti

P.S.
Martin, don't forget assign point in your old question :-)

Re: batch

Karl Rohwedder — Mon, 20 Jun 2005 03:27:16 GMT

Martin,

may be you edited the submitted procedure and purged the old version away? The queuing systems knows the file-id of the submitted command file and tries to invoke exactly that version.

After editing you have to resubmit it. Or, if
edits are occuring quite often, submit an wrapper routine, which just calls the 'real' routine. Then you may edit all the way.

regards Kalle

Re: batch

labadie_1 — Mon, 20 Jun 2005 03:32:30 GMT

as Marc has said, it seems that somebody created a new version after submitting it and deleted the .com submitted. Test it yourself, create a file a.com with just "$ sh time", submit it with $ subm/after=later, edit your com file, modify it or not, but EXIT from your favorite editor, release your batch job, you will have your error message. Now if you do the same, but after editing, do $ copy/overlay a.com;2 a.com;1 , it will work fine.

Re: batch

labadie_1 — Mon, 20 Jun 2005 03:33:17 GMT

I forgot to say, after exiting from the editor, delete the a.com;1

Re: batch

Wim Van den Wyngaert — Mon, 20 Jun 2005 04:56:35 GMT

Note that the file number is taken by submit, not the file name. So, if you delete and recreate the file (with same version number) the job will still fail. Rename is however allowed bevause that doesn't change the file number.

Wim

Re: batch

Jan van den Ende — Mon, 20 Jun 2005 05:59:26 GMT

Gerard,

I forgot to say, after exiting from the editor, delete the a.com;1

Undoubtably, you mean, DELETE the ;2 version!
After all, your whole intent is to have the original file ID with the new content.

Wim,

Note that the file number is taken by submit, not the file name. So, if you delete and recreate the file (with same version number) the job will still fail. Rename is however allowed bevause that doesn't change the file number.

Sorry, but I have to disagree!
SUBMIT stores the file-ID, not anything related with the name. Renaming to the old version does _NOT_ help!
OTOH, if you RENAME a submitted file to something completely different after SUBMITting, the job will still run.

fwiw

Proost.

Have one on me.

jpe

Re: batch

Edwin Gersbach_2 — Tue, 21 Jun 2005 00:59:06 GMT

Another common problem in this area is that may procedures resubmit themself using

SUBMIT/... F$ENVIRONMENT("PROCEDURE")

which ignores new versions if present. It is better to omit the version and have it to default to the highest one

SUBMIT/... F$ENVIRONMENT("PROCEDURE") - F$PARSE(F$ENVIRONMENT("PROCEDURE"),,,"VERSION")

A purge can then be done after the job has resubmittet itself.

Edwin

Re: batch

John Gillings — Tue, 21 Jun 2005 01:02:42 GMT

Martin,

As has been noted, the system uses the file ID, not the file name to locate a submitted command procedure for execution.

If you have a batch job with a procedure that's edited regularly, it may be better to nest it inside another procedure (which never changes). Put the resubmission stuff in the outer procedure. Something like this:

$ SUBMIT 'F$ENVIRONMENT("PROCEDURE") - /AFTER="TOMORROW+23:30"-
/NOPRINT/KEEP-
/PARAMETERS=("''p1'")/LOG=LOGDIR:
$ @

Since the "@" command is referencing the target file by name, not by file ID, it will always execute the latest version.

Re: batch

Antoniov. — Tue, 21 Jun 2005 01:22:12 GMT

Mhm,
there are many people here had trouble with submition and purging files :-)
Another trouble, I remember, when a batch job is execute more times every day is version of logdir become 32767.

Antonio Vigliotti

Re: batch

Martin Kubes — Tue, 21 Jun 2005 02:16:51 GMT

Thanks all,
the submitted command file has been under development for some time, so it has been edited very often, now it has been finished, resubmitted and running ok. I have used this construction :

.
.
.
$ < logdir definition >
$ name = f$environment("PROCEDURE")
$ goto 'f$mode()'
$ INTERACTIVE:
$ SUBMIT 'name' -
/AFTER="23:30" -
/NOPRINT/KEEP -
/PARAMETERS=("''p1'") -
/LOG='logdir'
$ exit
$ BATCH:
$ SUBMIT 'name' -
/AFTER="TOMORROW+23:30" -
/NOPRINT/KEEP -
/PARAMETERS=("''p1'") -
/LOG='logdir'
.
. < procedure body >
.
$ exit

To omit the problem with version number of log files the /VERSION_LIMIT=n qualifier has been set up for logdir.
Rgds, Martin

Re: batch

Bojan Nemec — Tue, 21 Jun 2005 02:31:37 GMT

Martin,

/VERSION_LIMIT will not resolve the version number limit. Maybe, you get more troubles with it. For example if you have version limit 2 and run 3 batch jobs, the third will terminate complaining that it can not open primary output.

Bojan

Re: batch

Jan van den Ende — Tue, 21 Jun 2005 02:44:49 GMT

Martin,

/VERSION_LIM=n does NOT help in preventing the version number growing to 32767!

It is intended to prevent too many LOG-files, which might consume a lot of disk space.

You can best consider it as implementing an automatic PURGE/KEEP=n.

Any hew logfile keeps getting the next higher version number.
If you have one logfile per day, than you will have to do something about that in about 90 years time, so no immedeate need to worry.
If you have one logfile every, say, 5 minutes, then you better have the procedure itself test the logfile version numbers, and after some threshold rename them down.

fwiw

Proost.

Have one on me.

jpe

Re: batch

Antoniov. — Tue, 21 Jun 2005 02:59:48 GMT

If you have one logfile every, say, 5 minutes, then you better have the procedure itself test the logfile version numbers, and after some threshold rename them down.

It's true just Jan forgets to say "external" procedure.
Running batch can't rename logfile version by itself because it's in use :-(

Antonio Vigliotti

Re: batch

Jan van den Ende — Tue, 21 Jun 2005 04:44:21 GMT

Antonio,

A running batch job is perfectly able to rename its own logfile!

If mode eq batch, our SYS$SYLOGIN checks IF logging is specified, and so, if the logfile TYPE is implicitly or explicitly ".LOG".
In those cases, it is renamed to .LOG_
In this works, at least since VMS 6.2 Vax/Alpha, until VMS7.3-2

No problem there!

Proost.

Have one on me.

jpe

Re: batch

Antoniov. — Tue, 21 Jun 2005 09:34:26 GMT

Jan,
every day I discover some news here :-)
You are right, running batch is able to rename its log file!
I have to change some of my batch commands.
Thank you for informations.

Antonio Vigliotti

Re: batch

Robert_Boyd — Tue, 21 Jun 2005 11:29:08 GMT

Here's a command procedure that I've been using for quite a while to let a batch job clean up its own log files. It also works for jobs in network and detached mode but depends on the freeware PPF or Process Permanent File utility.

Robert

Re: batch

Martin Kubes — Wed, 22 Jun 2005 02:03:59 GMT

discovered a solution to a problem