Re: Command Line Access & SSA group

>From Al Macintyre

About 1/3 of our users have command line authority - everyone who was on the 
original Y2K project team & some people trained by them who were given 
command line authority by request of the team member who trained them.  New 
users are not granted command line authority.  

We have given *SPLCTL to SSA, so that everyone can do anything they please 
with anyone's reports.  This is because a lot of report management crosses 
departmental lines - one person does some work - someone else aligns the 
forms for the special report.  However, we also have users whose menus are 
extremely restrictive.

Our command line authority is not provided through SSA, rather it is through 
OS/400 security & SYS600, so it can be granted or withdrawn on an individual 
person basis.

I rarely have to remind anyone anymore that 100% of our reports are "public." 
 Once upon a time we had people doing silly things like locking the computer 
room door when they were printing reports they did not want anyone to see & I 
would tell them "If you do not want anyone to see them, then do not put them 
on the spool file, when other people are signed onto the system."

I have been tempted to put *SPLCTL in a separate secondary user group for 
those users who are involved in the report generation & obtaining, but 
multiple user groups has a performance hit, so I will leave the reports 
public until there is a business case to make any of them private.

> Subj:  Re: Command Line Access
>  From:        Ata510@aol.com
>  
>  jonleroi@napanet.net writes:
>  
>  > Command Line Access via BPCS is not something I would want to give to
>  >  Users. When you have command line access through BPCS 
>  > you are executing at the SSA group level; the adopted authority. 
>  > On our machine that is almost as powerful as QSECOFR. 

In our environment it is like QSECOFR only for the BPCS files in the sign-on 
users's library list.  Basically the company is trusting the employees not to 
be crooks or careless, and we are trusting in our backup policy so that if 
something gets corrupted we discover that fact before all backups containing 
a clean original get recycled through the Monday Tues Wed etc. tapes.

I have only had to restore from backup tapes once in the last year - a 
document got deleted off of DOC & I am assuming it was by accident - since it 
takes only one keystroke oops to wipe one out.  That was a learning 
experience - how to restore just one member of one file in one library.

During Y2K conversion we were restoring all the time because we did not have 
enough disk space to have all pieces of the conversion on-line at the same 
time.

Prior to that I only had to restore from a business backup twice in 10 years 
--- someone was doing end-of-month work from several work station sessions & 
got confused where which session was on which check list.  The other time was 
recovery from a hard disk crash.  There were some times on S/36 where we 
managed to get index keys corrupted & the easy solution was move file 
off-line then back on line again.

Prior to BPCS we had to restore from MAPICS backups several times a month.  
Same people, same oops, same hardware infrastructure, but MAPICS is not as 
robust as BPCS.

I believe that trusting the employees is a good corporate strategy only so 
long as we are not connected to the internet, and are able to figure out 
through OS/400 tools when something goes wrong - our re-education is not yet 
to the point that this is as easy as it was on S/36.

>  > The AS/400 is such a friendly machine that a user
>  >  can prompt to their hearts desire and locate all sorts of interesting
>  >  commands such as DLTF, PWRDWNSYS, CHGSYSVAL .... 

Or F16 to GO MAJOR & wander down menus by subject or verb.

But when SSA group is a *USER and the USER is a USER, there are a lot of 
OS/400 system commands that will not cooperate - they can look at WRKSYSVAL 
settings & read interesting help text, but it will not let them change the 
values.

>  Most sites would do well to keep user 'SSA' with only 
>  normal OS/400 authority (*USER) and no way to sign on via this profile
>  by making the password *NONE. 
> 
>  That is the way the release is shipped.

That is not the way 405 was shipped to us, however that is a dead issue.  I 
have opted out of using SSA's XRF on 405 CD because the only way to get it to 
work is to change user 'SSA' to master security officer then sign on as SSA & 
do the 'XRF' analysis.  I specifically asked SSA help line on this point & 
they confirmed that is the only way to get it to work.  User 'SSA' is *USER & 
I use IBM's X-Ref when I want an X-Ref.

We no longer use SSA to make changes to SYS600.

Al
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---