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

[David Froble]

Simon Clubley wrote:
> On 2013-04-12, Paul Sture <nospam at sture.ch> wrote:
>> From
>>
>> http://h71000.www7.hp.com/doc/731final/6489/6489pro_046.html#exch_58
>>
>> "If the system fails while your batch job is executing, your job does 
>> not complete. When the system recovers and the queue is restarted, your 
>> job is aborted and the next job in the queue is executed."
>>
>> Which makes your incident sound like a bug.  The information that the 
>> job was running didn't make it back to disk so that the job could be 
>> aborted on the queue restart.
>>
> 
> Combined with the submit from the first job been lost, the not writing
> back to disk scenario is the only viable thing I can think of at the moment.
> 
>> I am slightly wondering that if you had had restart checkpoints built 
>> into your procedure that might have forced some write back to the queue 
>> manager database, but a check_queues job doesn't sound like a lengthy 
>> procedure to me.
>>
> 
> The elapsed time of the first run was 2.56 seconds according to the
> log file.
> 
> _If_ the queue manager is caching on disk updates for even 30-60 seconds
> that job could easily start, submit a new job, and complete without any
> on disk queue manager database updates before power failure.
> 
> Simon.
> 

And doesn't this just lead us back to the discussions years ago, before 
VMS had the caching, about how fast other systems were, and how slow VMS 
was because of it insisted to write everything to disk ????

The rant Steve quoted (Jeff Bonwick) was one of the best things I've 
read in a while.  I think similar things could be written about other 
things, Microsoft comes to mind ....

Then there was David Mathog who didn't care about writing to disk, he 
just wanted super fast number crunching.

Not sure what any of this means ....