× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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
______________________________________________________________________

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.