batch

[Martin Kubes]

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

[Marc Van den Broeck]

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

[Antoniov.]

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 :-)

[Karl Rohwedder]

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

[labadie_1]

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.

[labadie_1]

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

[Wim Van den Wyngaert · Accepted solution]

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

[Jan van den Ende]

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

[Edwin Gersbach_2]

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

[John Gillings]

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.

[Antoniov.]

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

[Martin Kubes]

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

[Bojan Nemec]

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

[Jan van den Ende]

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

[Antoniov.]

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

[Jan van den Ende]

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

[Antoniov.]

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

[Robert_Boyd]

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

[Martin Kubes]

discovered a solution to a problem