Re: BRMS Retain Object Detail - *LIB vs *OBJ

[Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>]

Any restores are done by me.


On Fri, Jan 11, 2013 at 3:13 PM, Paul Fenstermacher <
PFenstermacher@xxxxxxxxxxxxx> wrote:

> Who does your restores when necessary?  In my previous life at the biggest
> bait store in the land our restores were done by less than experienced
> operators and it was much easier for them to take a couple options on BRMS
> menus than it was for them to properly use the RSTOBJ command.  We captured
> *OBJ information just for that reason.
>
>
> Paul Fenstermacher | Sys/NW Admin,Sr  | Corporate Systems - POWER Systems
> Administration | Jack Henry & Associates, Inc.(r)
> 663 West Highway 60 | Monett, MO 65708 | Ph. 417.235.6652 | x177389 |
> pfenstermacher@xxxxxxxxxxxxx
>
>
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
> midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Crosby
> Sent: Friday, January 11, 2013 2:00 PM
> To: Midrange Systems Technical Discussion
> Subject: BRMS Retain Object Detail - *LIB vs *OBJ
>
> 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.
>
> NOTICE: This electronic mail message and any files transmitted with it are
> intended
> exclusively for the individual or entity to which it is addressed. The
> message,
> together with any attachment, may contain confidential and/or privileged
> information.
> Any unauthorized review, use, printing, saving, copying, disclosure or
> distribution
> is strictly prohibited. If you have received this message in error, please
> immediately advise the sender by reply email and delete all copies.
>
> --
> 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.