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



Rob,

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

Paul

-----Original Message-----
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.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





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?

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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.