Re: DSPJRN OUTPUT(*OUTFILE) and resulting record length

I guess you are saying the reported length is kind of like the
flashing cursors and other screen effects seen when querying files
containing hexadecimal data in character fields that is outside of
what would normally be displayed. Maybe that's the cause.

Just as an FYI - I wasn't presupposing any removal of entries; Joe
stated quite clearly that he was looking at a different range of
journal entries (or I at least understood it quite clearly no matter
what it was he actually said.. :) )

HA software will quite often deposit user entries in the journal. it
doesn't need to delete or remove them because the intent is that they
act as some kind of boundary or operational marker. For instance,
commands to run on the remote (HA) system can be deposited into the
journal and then run on the HA system when the target system reads
them. This allows for operations on the HA target to be effected when
the database is at a certain processing point but can effectively be
used by the HA software for anything.

For example I've seen Vision used to signal the commencement of a
library copy or nomax used to signal backup processing on the HA
target.

If this truly was the cause of the issue which Joe suggested as a
possibility, it's reasonable to assume that such an entry might have a
different Journal Code, Like U for a User Journal entry.

My comment was just a suggestion as to how Joe might verify if this
was indeed the issue ( It still seems a possibility to me)

On Thu, Mar 17, 2011 at 2:45 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 3/16/11 4:18 PM, Evan Harris wrote:

If you compared the journal types from yesterday to today you might
be able to narrow the search to the entry they created presuming that
was the issue (sounds quite possible). Might be just a matter of
excluding certain Journal entry types when dumping journal
transactions to a file.

Does the HA software provide any indication of which journal entries
are for their use ?

On Thu, Mar 17, 2011 at 3:14 AM, Joe
Pluta<joepluta@xxxxxxxxxxxxxxxxx>  wrote:

An anomaly as in we updated our HA software and they may have put
a placeholder entry into the journal.

  A "placeholder entry" seems questionable as a conclusion, given that
there is only the one method of send\write for the journal entry via the
journal into the attached journal receiver.?  That conclusion would have
to suppose there was either a change-entry or remove-entry method,
either of which would be problematic for the supposed integrity of the
journal feature as a means to implement security auditing.?

  That is to say, if there was a large entry that existed in the prior
DSPJRN, and the same range of sequence numbers were displayed again, one
should expect the same results should be seen.  I would conclude more
likely that either the same range is not being displayed, some entries
are being excluded from that range in the newer requests, or if the
request is indeed identical each time then there was more probably a
defect encountered that for some reason is no longer being exhibited.

  For instance... Given a code path which might somehow have caused the
DSPJRN processing to incorrectly read EBCDIC character data as the entry
length when spinning through the entries that should be included by the
specified range, the probability is high that most data interpreted as
*UINT2 would reflect a large decimal value; a x'4040' gets half-way to
the max record length, but any alpha character in the first byte always
exceeds maximum.  I would consider an anomaly like that to be more
likely than the possibility of a temporary journal entry.  And although
I would expect more likely that the later requests function only because
whatever is the last sequence is not specified, such that the problem
may only ever exist when the ending sequence and\or ending time are left
unspecified, ensuring the identical request in sequence\range might
recreate the issue.  If the former, the origin of whatever was seen
might only ever occur within a very narrow scope of environmental
parameters.

Regards, Chuck
--