Re: Library Authority

I realize all of that, but in this case we are doing this because we have
users browsing the database and asking "What is ACMASTP for?" and all around
using Crystal Reports to query files that they have no business looking
into. We just want to give them a library for only the files, fields and
records they are allowed to query. There is a business reason to allow the
queries so we can't just cut the cord on it. These logicals are NOT mission
critical and are not backed up in the daily backup. The source is backed up
and can be recreated easily upon DR (only a several thosand records in each
file).

I do think that this information is really needed in this thread so future
people looking at doing this know the impact of what they are looking at
doing. I don't want to discount what you have said, but in my case it is a
non-issue.

-- 
Mike Wills
Midrange Programmer/Analyst

Sick of corporate radio and hungry for something new?
http://thenextgenerationofradio.com
Stalking me? http://twitter.com/MikeWills | http://friendfeed.com/mikewills


On Mon, Aug 18, 2008 at 10:50 AM, CRPence <CRPbottle-/[email protected]> wrote:

>   Such a response ignores the true potential for stress that might be
> involved.  The noted processing may be unacceptable to businesses for DR
> with large files, since doing so could add several tens of hours for
> access path recovery time.  Without proper planning, applications may be
> unavailable for days while critical activity competes with rebuilds for
> CPU time, or while rebuilds are given dedicated time thus preventing
> activation of other processing that is critical to the business.  While
> it may be workable for your situation, that does not make it generally
> applicable to others.  Many will never even test DR to find out that
> they will be SOL when the time comes for a real DR, so implying it is
> acceptable without emphasizing the potential caveat will leave them
> disgusted with the OS and possibly with the /advice/ they were given.
>
>   The IBM i Operating System 6.1 offers some new techniques which
> enable spanning libraries without access path rebuilds, but only with
> explicit modifications to the DR processing.
>
> Regards, Chuck
>
> [email protected] wrote:
> > Personally I don't find the separate library thing such a big hassle.
> >  1 - Name the LF library higher in the alphabet than the pf library.
> > So if your PF library was MYLIBF then name your lf library MYLIBFLF.
> > Then in a complete unload/reload the PF's will all be there.
> >  2 - If someone violates this, or if they do stuff like have a LF in
> > LIBA pointing to a PF in LIBB and a LF in LIBB pointing to a PF in
> > LIBA then I still wouldn't stress out. When restoring I simply do a
> > second RSTLIB *NONSYS with the OPTION(*NEW).  There's even some
> > obscure reference to this in the Backup and Recovery Guide.  Having
> > done an unload/reload within the last month it was no problem.
> >
> > I've got real issues to get stressed over instead of being concerned
> > with cross library logicals.
> >
> > Hey, if my boss found that easy solution, and he hasn't written a
> > program in way over a decade...
> _______________________________________________
> This is the Security Administration on the AS400 / iSeries (Security400)
> mailing list
> To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/security400
> or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/security400.
>
>
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.