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

On 3/16/11 7:58 PM, Joe Pluta wrote:

<<SNIP>>

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.

<ed: additional text was snipped>

Your conclusion would be incorrect, Chuck. You're assuming the
contents of the journal receivers are the same and the command is
different. Both are bad assumptions.

The DSPJRN commands are exactly the same. I am comparing the results
of a completely unfiltered DSPJRN from yesterday and the same command
executed today.

The content of the receivers is different. These receivers are
detached and deleted regularly and only a finite span of time is
available in the journal at any point in time. It's quite possible
that the large entry was available in yesterday's receivers and not
today's.

In any case, the situation is gone. I will monitor it and if it
occurs again I will try to see what caused the entry. Until then,
since the entry causing the problem is gone, there is no way to do
any further analysis.

Actually the conclusion would not be wrong, apparently just misunderstood by the reader. A "completely unfiltered DSPJRN" is implicitly a different range being displayed whenever the data in the receiver has changed, than the range for the identical request made prior to the data changing. Thus the situation is covered by "the same range is not being displayed" because for any change [given that the only method is add\send] at least one new sequence number would be available to the request.

FWiW I encountered a possibly similar oddity many years ago, but the incorrect output was IIRC, after each page-down in DSPJRN output to the display, the same data was being presented even though many entries had not yet been displayed. Regardless of what the actual symptom was, as soon as any new entry was added, even if by CHGJRN *GEN to log that the new receiver was generated, the issue no longer would recreate; or so it seemed. As as I recall, as soon as the to-entry or the to-time parameter was modified to match the original recreate where the from-entry and from-time remained the same for the unchanged *CURRENT receiver, the problem suddenly re-appeared except when the current receiver changed. I wrote up the scenario in a REXX script as recreate materials and sent that to the journal team to investigate and correct the problem, which they did.

Regards, Chuck