The short answer is yes. Caching can cause entries to not be picked up by DSPJRN.
From the CRTJRN help for parameter JRNCACHE() ...
Journal caching (JRNCACHE) - Help
*YES
Journal entries are written to main memory. When there are several
journal entries in main memory, then the journal entries are written
from main memory to disk. If the application performs large numbers
of changes, this may result in fewer synchronous disk writes
resulting in improved performance. However, it is not recommended to
use this option if it is unacceptable to lose even one recent change
in the event of a system failure where the contents of main memory
are not preserved. This type of journaling is directed primarily
toward batch jobs and may not be suitable for interactive
applications where single system recovery is the primary reason for
journaling.
Note: Applications using commitment control will likely see
less performance improvement because commitment control already
performs some journal caching.
Note: Entries that are in the cache are not displayable using
the Display Journal (DSPJRN) command, Receive Journal Entries
(RCVJRNE) command, Retrieve Journal Entries (RTVJRNE) command,
or the QjoRetrieveJournalEntries API. Also, entries that are in
the cache are not sent to a target system with remote journal.
However, these journal entries are included in the last journal
sequence number for the journal receiver returned via the
Display Journal Receiver Attributes (DSPJRNRCVA) command or
QjoRtvJrneReceiverInformation API.
WRKJRNA will show you if the journal is cached.
You can change the caching value to *NO with the CHGJRN command.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
Sent: Thursday, August 01, 2013 12:43 PM
To: 'Midrange Systems Technical Discussion'
Subject: DSPJRN date/time reliability
We have a production CL pgm run each evening after the EOD jobs which DSPJRN to an outfile for analysis.
We use DSPJRN FROMTIME(20130712 194218) TOTIME(20130715 194700) with other parms to an outfile.
DSPJRN apparently failed to select a handful of journal entries which were written (JODATE & JOTIME) at exactly 20130715 193856.
This is suspiciously close to the end of the time window 19:47:00 - it is 8 minutes from the end of the time window.
Another clue: we MIMIX these journal entries to a backup box. I ran the DSPJRN with the same time window against the backup box, and the journal entries DO exist properly. The ONLY source for these backup box journal entries is the production box journal.
Any idea what is occurring here? Can a journal entry be prepared in a buffer with the curr time and written to the actual journal several minutes later? Then the journal record would fall outside BOTH of my time windows?
Should I be selecting journal records using the starting and ending large sequence number (FROMENTLRG & TOENTLRG) for just this reason?
What would cause journal records to be time-stamped but delay their writing to the journal file? Commitment control? Something else?
Could it be some other issue that I am missing journal records?
PS I cant see the production journal entries as they are too old now and are gone from the prod box (although they are still available on the backup box).
Thanks
______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit
http://www.symanteccloud.com
______________________________________________________________________
midrange.com
