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



Takes @ 4 minutes to reach restricted state.

Total save time is @ 61 minutes, of which 1.5 minutes is QUSRBRM.

Time from "Subsystem QCTL in library QSYS starting." to "BRMS console
monitor is now active" (the last message in QSYSOPR relating to restarting
things) is @ 7 minutes.

So the actual save is the bulk of the time. What I wasn't sure about was
if Retain Detail *OBJ was making this actual save time longer and by how
much.

And yes, I like being able to see the object detail when I want. I think
I'll keep it the way it is.


On Fri, Jan 11, 2013 at 3:09 PM, <rob@xxxxxxxxx> wrote:

Is it important for you to be able to do a
WRKOBJBRM MYLIB/MYFILE
to see what tapes and when it was saved? Or is
WRKLIBBRM MYLIB
good enough?

QUSRBRM can get a byte or two in it
ODLBNM SUMLIB
#MXJRN 1,912,810,639,360
QGPL 369,684,475,904
GDIDIVF08 179,423,801,344
ERPLXF 168,973,004,800
ROUTINES 120,952,487,936
ERPLXFBK 84,211,118,080
ERPMRP 78,273,454,080
GDIDIVF 76,949,880,832
ERPLXUSRF 44,237,602,816
GDITOLF 38,707,965,952
ERPLXSAVF 37,237,932,032
ROB 21,921,136,640
QMPGDATA 20,959,854,592
ERPLXARCF 20,770,013,184
MGR1499099 18,257,580,032
QUSRBRM 16,891,650,048
...

Is your backup running 10 minutes? Just the actual save time; not all
that bringing the system in/out of restricted state stuff. Is it worth
losing the granularity to shave off some time? It may be. Just saying
that the actual save may not be the bulk of your save outage. See
DSPLOGBRM *BKU to break it down.

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: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 01/11/2013 02:59 PM
Subject: BRMS Retain Object Detail - *LIB vs *OBJ
Sent by: midrange-l-bounces@xxxxxxxxxxxx



It's amazing what you can stumble upon.

I've always used *OBJ. The manual says:

"We recommend that you be selective with retaining object-level
information
because it increases your disk storage considerably and affects your save
and
restore times. Unless you are constantly restoring individual objects from
a
library, there is no need to keep object-level information. Remember that
you
can always restore an individual object even without keeping object-level
information as long as you know the library in which the object was
stored."

Disk space isn't an issue as we have gobs of it. Save time? I don't know
how much of an effect it has there. Experiences, anyone?

I don't use multi-member physical files other than source physical files.
Can I still restore an individual source member if needed?

I seldom need to restore anything. Usually it's because someone asks me a
question about why something happened a week after the fact. I'll pull in
a couple of files to see what they looked like at the time.


--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.


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