MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » December 2013

Re: journal record reduction issue using SQL



fixed

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).






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact