Re: NO queries in QGPL please!! -- MIDRANGE-L

Paul wrote:

John Earl wrote:
If you don't want someone to do something on the AS/400, you secure against that event. Then it's done, end of hassle.
No new batch processes to manage or monitor. No confused, angry or hurt users, and no arguement. If the rules for your system are that no user objects belong in QGPL, then use OS/400's security to enforce those rules.
Better to take preventative action and prohibit users placing objects in the library in the first place by removing their *ADD authority to the library. The users get immediate feedback, the queries get put somewhere else, and you don't have another IS overhead process to babysit.

This is precisely what I'd like to do, but other subscribers of this list have cautioned me against it - Dean warned me: "Of course, this will cause you other problems --
QAUTOCFG device message queues cannot be created, for one."

Dean is a smart guy, but he's wrong on this point. First off, message queues for devices are created in QUSRSYS, not QGPL, so there will be no conflict with users doing their own autoconfig

Second, If you did the same thing to QUSRSYS that I proposed to QGPL, (limit users ability to add objects to it), the only thing that wouild be disabled is end-users ability to autoconfig devices. This is not a bad thing. Autoconfig is a handy tool for IS staff, but good security practices would counsel against leaving it on all the time.

Third, and this one really gets me, is the general notion that something bad (we don't know what, but we're sure it's bad) might happen if you tighten down security. I'm not picking on Dean, because I hear this from many sources. And I know that this comes from the (percieved) limited ability to test security changes, especially ones like this that affect IBM objects . Many people have nightmares about the time that they changed some security value and ended up disabling hundreds of people.

But just as with any other change on your system, you should test security changes on a small scale before you roll out a massive change. When you can't create a separate test envirnoment (like this QGPL change), you can pick a small group of users, tell them what you're doing, and make the change effective for just those users. You can then determine whether the change has any adverse affect (I'd be shocked if you found one in this instance).

jte

--
John Earl Lighthouse Software Inc.
8514 71st NW Gig Harbor, WA 98335
253-858-7388 johnearl@lns400.com

Without Lighthouse Network Security/400, your AS/400 is wide open.
--