RE: NO queries in QGPL please!!

Paul,

There's absolutely NO reason to be disappointed with AS/400 security
here.  There are many ways you can control access to a library - but
this is basically a user created problem - or non-problem.
So they store queries in QGPL, I could ask "so what ?".  Admittedly it
may be easier to manage if they were placed in a separate library, but
the fact they are in QGPL isn't really going to cause any problems,
release upgrades or otherwise.  IBM doesn't mess with user objects in
QGPL during release updates.  Now if you had changed a subsystem
desciption in QGPL that would be a different story, but you should
either make a copy of the changed object or have a CL program to rerun
after updates to reapply your changes.

Of course you could tell the users that is it the Garbage Pail Library,
and the truck comes around once a week and empties it !     :-)



Neil Palmer                                AS/400~~~~~      
NxTrend Technology - Canada   ____________          ___  ~     
Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=   
Phone: (905) 731-9000  x238   |__________|_|______|_|______)   
Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\   
Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
mailto:NPalmer@NxTrend.com    AS/400  The Ultimate Business Server      
http://www.NxTrend.com

> -----Original Message-----
> From: Paul [SMTP:kdcma@ix.netcom.com]
> Sent: Thursday, March 19, 1998 9:24 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: NO queries in QGPL please!!
> 
> Hi Walden.
> 
> FYI: The original request to keep queries out of QGPL was indeed to
> keep the
> library pure. I just upgrade from CISC to RISC and it was a pain to
> get my
> queries up without overwriting anything in QGPL on the RISC system.
> Obviously I
> couldn't chance letting any system stuff from the CISC's QGPL library
> coming
> over.
> 
> I think I'm going to follow your advice and move them.
> 
> I'm disappointed in AS/400 security though, that there isn't some
> simple way to
> secure the library without giving me other problems.
> 
> Paul
> 
> Walden Leverich wrote:
> 
> > While I agree that this does not stop users from putting queries in
> the QGPL
> > library, I think the delete approach is too harsh. I'm one that
> believes
> > that the system belongs to the users. We (IT, IS, MIS, DP, whatever)
> are
> > just here to act as enablers for the users.
> >
> > I don't know why the original request was made to not store queries
> in the
> > QGPL library, but I would guess that there was a desire to keep the
> library
> > "pure" to avoid any possible upgrade problems. ( Yes, I know there
> shouldn't
> > be any, but if I don't use the lib I know there will be no
> problems.) By
> > moving the queries into the correct library I allow the users to
> keep their
> > hard work and still accomplish my goal. Besides, after a couple of
> weeks of
> > saving to QGPL and having to remember that the query was then moved
> to
> > library xxx the users will simply start using library xxx.
> >
> > -Walden
> >
> > -----Original Message-----
> > From: owner-midrange-l@midrange.com
> > [mailto:owner-midrange-l@midrange.com]On Behalf Of Terry Herrin
> > Sent: Monday, March 16, 1998 8:00 PM
> > To: MIDRANGE-L@midrange.com
> > Subject: Re: NO queries in QGPL please!!
> >
> > Walden Leverich wrote:
> > >Terry,
> > >
> > >A bit harsh, no? How about modifying your nightly process to move
> the
> > >queries into the library of your preference?
> > >
> > >-Walden
> >
> > I agree it's harsh, but how would moving the queries to another
> > library stop the users from continuing to put their queries into
> QGPL?
> > Yes, your move process would move the queries out of QGPL every day,
> > but you haven't solved the problem, you've simply put a band-aid on
> > it.  Give the users plenty of warnings that the queries will no
> longer
> > be kept in QGPL and that they will lose them if they put them there.
> > Set a date as to when the delete will be going into place, give the
> > users a reminder as the date nears, then put the delete in place.
> If
> > after all that they still lose a query then it's their own fault.
> > Once they know their queries will be lost if they put them there, I
> > guarantee they'll stop doing it.
> >
> > Terry Herrin
> > Sr. Programmer/Analyst
> > New Hanover Regional Medical Center
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> > david@midrange.com
> > +---
> >
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> 
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---