On 11-Dec-2013 10:16 -0800, Stone, Joel wrote:
Is JOTSTP new in V6 or V7? Or is this a "hidden entry"?
The timestamp has existed a very long time, to replace the two
columns JODATE and JOTIME. But as Output File (OUTFILE) support goes,
the means to introduce a change may not be solely via a new column to a
previously defined\existing model file; i.e. the enhancement may be
provided, only in newer model output files.
I don't see that field in my DSPJRN output.
In the case of Display Journal (DSPJRN) OutFile support, there are
multiple Outfile Format (OUTFILFMT) choices, *TYPE1 as the original and
then *TYPE2 through *TYPE5 available by v5r3, each with its own model
file; i.e. QADSPJRN for the original and QADSPJR2 through QADSPJR5. The
TIMESTAMP field JOTSTP was introduced in the 3rd file QADSPJR3 for
*TYPE3, and would be expected to be used in every newer model output
file since then.
If the system date/time can be "backspaced", is there a bullet-proof
method to ensure the PGM is finding the oldest and newest entry? Add
the journal receiver name into the MIN()? Is that even available in
the *OUTFILE of DSPJRN?
While I hate to say it... the Relative Record Number (RRN) could be
used for a refreshed Output Member (OUTMBR); i.e. per
OUTMBR((the_mbr)(*REPLACE)) /* the extra but inoccuous parentheses
merely to prevent linewrap */ because of course there would be no
deleted rows nor other I\O that could vitiate the intended meaning for
and utilization of the RRN in that scenario.
Surely a query could be composed to find the proper rows, but it will
be necessarily more complicated than the query used presently. Another
option is to just process the data sequentially via the arrival access
path [of a refreshed Output Member; see above], and /massage/ the data
to be compatible with the existing query. Yet having done that, the
same code could just as well be changed to also or instead, actually
produce the desired output *instead* of the query. Depending on how
that output file is used again\elsewhere, modifying the data may have
some value to the processes.? Of course a separate query could be used
merely to detect any conditions of either backward time[stamp] values or
reset sequence numbers, used to notify the need for a manual exception
process as intervention, or perhaps only until an automated resolution
[e.g. by modifying the data for the upcoming query] is integrated into
the process.
So for both the timestamp and sequence numbers which could be set to
an earlier value, there is potential for a pre-pass of the data, e.g.
using arrival sequence, that could be used to modify the data to be
compatible with the upcoming query; modifying the data only if any such
instances were found. Other than a dependence on the data to reveal the
condition, reliance could be on an *assumption* that neither the time
was set back spanning the entries being output to the file nor that a
sequence number was reset; having plans in place, hoping to ensure
neither reset transpires. And while there are some means to detect
either of those reset actions had taken place spanning that same period
of real-time, there is another *assumption* that the indications of
those changes would not be lost\missed [e.g. due to deletion, such as an
audit entry or a history log entry, or a message queue entry]. As such,
the data is the true and final arbiter for knowing if the condition
exists. The most conspicuous, only for sequence numbers, is the
existence of a J-PR entry with [AFaIK, even with hidden\internal
entries, will always be] JOSEQN=1 to indicate the effect of a successful
CHGJRN SEQOPT(*RESET).
midrange.com
