× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 01-Oct-2015 13:36 -0600, Steinmetz, Paul wrote:
I'm using PRTRPTBRM, dumping to an outfile, then sorting, to identify
my largest and longest objects during a save.
I'm seeing two entries for every library saved, the second one being
from my auto dup immediately following the save.

I reran PRTRPTBRM, changing the end date/time hoping to NOT include
the auto dup.
SBMJOB CMD(PRTRPTBRM PERIOD((180000 092915) (201600 092915))
OUTPUT(*OUTFILE) OUTFILE(QGPL/PRTRPTBRM) OUTMBR(*FIRST *REPLACE))

I'm still seeing two entries.
The entry from the auto dup, 204132, is still appearing, even though
it was after the end/date time, 201600.

Any thoughts from the group?

10/01/15 15:16:23 Pencor06 Save Summary
Library Size in Total Volume Number Nbr Start End Control
Name MB SavTim Used Objs Not time stamp time stamp Group
---------- ------- Minutes ------ Saved Saved CYYMMDDHHMMSS CYYMMDDHHMMSS -------
ICOMRSTGEN 117,013 10 001045 18,031 0 1150929181532 1150929182550 SAVCHOB
ICOMRSTGEN 117,013 10 001158 18,031 0 1150929203118 1150929204132 SAVCHOB
ICOM827GEN 116,084 7 001045 18,538 0 1150929182915 1150929183712 SAVCHOB
ICOM827GEN 116,084 10 001158 18,538 0 1150929204147 1150929205236 SAVCHOB
PTDGEN3 19,464 1 001045 8,842 0 1150929183846 1150929184015 SAVCHOB
PTDGEN3 19,464 1 001158 8,842 0 1150929205252 1150929205451 SAVCHOB



Seems the specified PERIOD() value did not effect proper selection for the data that was generated\placed-in the specified Output File (OUTFILE) and member. Seems likely that the output was generated by an SQL request [insert into qgpl/prtrptbrm select ... from qusrbrm/... where ...], and that SQL request would be visible via Database SQL features such as a detail monitor or SQL statement cache or possibly even Print SQL Information (PRTSQLINF) of the BRMS program that eventually generates the report. A SWAG is that the predicate(s) in the WHERE clause presumably were not properly converted into the format of the data stored in the file in the QUSRBRM library, and probably the same form CYYMMDDHHMMSS as the corresponding field in the OUTFILE that was created from the "file QA1ABS in library QBRM with the format name QA1ABS".

I found no relevant APARs with the following symptoms [nor with fewer tokens, repeated searches, each with last token dropped]:
BRM APAR PRTRPTBRM PERIOD INCORROUT OUTFILE

Seems already [per a followup reply] that the issue was circumvented by implementing proper predicate(s) against the generated data, to properly pare the records of interest to the desired PERIOD().


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.