[Info-vax] Are queue manager updates written to disk immediately ?

[Simon Clubley]

On 2013-04-12, Johnny Billquist <bqt at softjar.se> wrote:
> On 2013-04-12 16:50, Paul Sture wrote:
>> In article <kk95l8$lqt$1 at news.albasani.net>,
>>   Jan-Erik Soderholm <jan-erik.soderholm at telia.com> wrote:
>>
>>> And it wasn't as simple as an extra submit of the job
>>> from the startup scripts? Do you have any log files
>>> with the startup/console output ?
>>
>> Not likely because it had the same job entry number.
>
> Since it had the same job number that would imply that indeed it was 
> rerunning the same job. Is the job set to restart?
>

No; if a random job fails my policy is for it to be examined manually
first before restart just to be safe.

The 24/7 jobs OTOH are started at system startup and are designed to be
restartable at any time.

> There is a delicate race condition in batch in general, when it itself 
> submits the next run, in that you can end up with two jobs if the job 
> manage to do the submit, but don't manage to finish. This requires some 
> careful thinking and design to at least minimize.
> I know I've had a similar issue under RSX with my backup jobs.
>

On VMS, if the system fails during execution of a /NORESTART (the default)
batch job, then when the system restarts the job is marked as "system
failed during execution" and is not restarted.

> However, the one really strange thing I see in all this is that the log 
> file seems to have confirmed that your first run did submit a job, but 
> that job seemingly disappeared into thin air.
> That is the one thing I can't account for.
>

Neither can I, unless the queue manager does not write updates to disk
immediately.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world