In order to see IFS object level detail, I think the save needs to specify Retain Object Detail *YES
Weekly Retain Save SWA
Backup List ASP Activity Object While Message Sync
Seq Items Type Device SMTWTFS Detail Active Queue ID
180 QALLUSRLNK *LNK *SYSBAS FFFFFFF *NO *YES QSYSOPR *NONE
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, October 02, 2015 4:35 PM
To: Midrange Systems Technical Discussion
Subject: RE: PRTRPTBRM issue
Well, if you explain your issue during the PMR perhaps they'll tell you the underlying tables to query.
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
Kendallville, IN 46755
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
Date: 10/02/2015 04:27 PM
Subject: RE: PRTRPTBRM issue
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
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?
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Sent: Thursday, October 01, 2015 4:41 PM
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
Name MB SavTim Used Objs Not time stamp time
---------- ------- Minutes ------ Saved Saved CYYMMDDHHMMSS
ICOMRSTGEN 117,013 10 001045 18,031 0 1150929181532
ICOMRSTGEN 117,013 10 001158 18,031 0 1150929203118
ICOM827GEN 116,084 7 001045 18,538 0 1150929182915
ICOM827GEN 116,084 10 001158 18,538 0 1150929204147
PTDGEN3 19,464 1 001045 8,842 0 1150929183846
PTDGEN3 19,464 1 001158 8,842 0 1150929205252
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().
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l