Re: MIDRANGE-L Digest, Vol 5, Issue 1295

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Writes to the journal are usually synchronous - the job has to wait 
until they are written before any other changes can be made. There is 
a PRPQ for batch journal caching - now option 42 since V5R2, that 
caches changes and returns control to the program. Here is a little 
bit from the readme for the product that might help explain system behavior.
===========================================
If journal caching is disabled (system default behavior without this 
PRPQ) when an add, update, or delete database operation is requested, 
the application job must wait until the corresponding journal entry 
is written to the disk. Because the application is waiting, obviously 
the application cannot make changes to another record in the database 
or other non-journaled object until the journal entry has been 
written to disk.

On the other hand, if journal caching is enabled with this PRPQ when 
an add, update, or delete database operation is requested, the 
application does not wait for the journal entry to be written to the 
disk. Therefore, the application will be allowed to make changes to 
other records or non-journaled objects before the journal entry is 
written to disk. Eventually the cache becomes full and the lingering 
journal entries are finally written to disk. If the system crashes 
before the cache is emptied, neither the journal change nor the 
change to the database record will have been written to disk.
=========================================

There are risks of losing some data, although a very small window of 
vulnerability.

BTW, you get some of the same benefits simply by turning on 
commitment control, even if you do not actively use it. Because that 
turns on a bit of caching for the journal writes. This makes 
performance with  journaling to be almost the same as without 
journaling, simply by adding a STRJRNPF/ENDJRNPF pairing to your code.

HTH
Vern

At 04:58 PM 6/27/2006, you wrote:

> > message: 8
> > date: Tue, 27 Jun 2006 15:26:19 -0400
> > from: "John Candidi" <jacandidi@xxxxxxxxxxxxxxxxxxxx>
> > subject: RE: Journal records written to disk.
> >
> > Qaudfrclvl system value?
> >
>
>
> Isn't that only for the system auditing journal?  I'm looking for
> what 'trigger' (perhaps a poor term) the journal record still in
> memory to be staged to the journal receiver?  Would the same scenerio
> happen as Sql Server?  That is,  say I coded the FRCRATIO on my table
> to be 3.  Before the three records are written to my PF, the journal
> images would be written to the receiver?
> What it you didn't specify the FRCRATIO on the table?  What then?  Or
> if you had more than one table journaled to the same receiver?
>
> Did a quick scan through some docs but didn't find anything..
>
> Had to go back to class.  Maybe the 'PaperClip' will show us how to
> normalize the database.. ;)
>
> Mike.
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.