Re: what are the duties of QSYSOPR & QSCOFR?

Our users have their own PERSONAL sign ons with whatever security is relevant 
for their duties.  We access QSYSOPR & QSECOFR to do stuff that it is 
convenient to do with them that we do not want in the security of an 
individual user ALL THE TIME.

Several of us have multiple sign-ons for various combinations of work.
I have one for doing some security work then testing that it was setup right, 
then I revert to the sign on that is safe for me to have on a work station 
when I walk away from it still signed on.

If you use multiple sessions, the first sign-on owns your message list & from 
that one F6 gets you to QSYSOPR.  Many people manage their own reports & the 
printer messages are replicated to QSYSOPR vs. WRKSPLF WRKOUTQ WRKWTR etc (I 
always key that wrong vs WRKWRT because of S/36 memories)

When a job is in trouble, IS folks are in the WRK*JOB screens & GO CMDLCK & 
other tools looking at the job, not at QSYSOPR overall picture.

I have added a menu CALL NITE that we use for backups & other stuff outside 
the normal daily applications.  On it is a DSPMSG QSYSMSG to see if we got 
any serious things needing fixing, like sessions disabled for too many 
password guesses.  I also have a DSPLOG option that is looking for certain 
types of very bad things that can happen, like if PCs get added to the 
network outside the IS staff which can lead to QPDAV0001 address which can 
lead to BPCS being corrupted.

We have what I call SYSTEM HELPERS.
These are people who are POWER USERS of our applications.
They are not programmers or IS, just people in user departments whose 
business analysis skills & understanding of the total systems are such that 
none of the jokes about uers apply to them.
They know enough to help other users who are struggling.

I have setup secondary security groups for categories of activities that 
various power users might be authorized to do.

Who should have security clearance to kill other people's sessions?
Who should be able to kill other people's reports?
Who should be able to view confidential information in other people reports?
Who should be able to look inside of what another person job is doing, and be 
expected to understand the job log?
Who should be permitted to mess with the hardware configuration?
Who should be able to make changes to data files, outside of BPCS audit 
trails?
Who is allowed to second guess the corporate business rules?
Who is allowed to create a new query definition?
Who outside IS is granted sufficient authority to create the CL to run a 
query by those individuals who are not granted command line authority?
Who should be allowed to copy a query definition between two environments - 
the one you normally using & the one outside your library list?
Who is authorized to alter menus?
Who should be allowed to do screen copy?
Who should be allowed into the test environment?

By phrasing questions like that you can rapidly focus on what risks you want 
opened up for which users.

When we identify people who should have these privileges, we just add the 
relevant secondary group security to their user profile.  The secondary group 
has already figured out what is needed to let them into this stuff.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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
+---