RE: PRTRPTBRM issue

After more research, I did find this.

1) PRTRPTBRM to spool file has duration accurate to the second.
PRTRPTBRM to an outfile is ignoring the seconds, only down to the minute.
Not sure if this is WAD or a defect.
Open a PMR for this.

2) What tool, if any will show detail of the IFS part of the save?

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, October 01, 2015 4:41 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: PRTRPTBRM issue

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

--
Regards, Chuck

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.