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

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