Re: SSA Group Authority

Hi

Summary of post:
Your difficulties are not unusual.  Many other companies have faced similar
trade-offs.
Here I share several that I have been involved with.

Check http://archive.midrange.com/bpcs-l because variations on your
question have come up before & there are lots of useful tips out there.
Query/400 directory access for users who have BPCS menu access only.
Query/400 that pre-exist over confidential data.
Query/400 performance problems when run on-line.
Files that contain both public data (any employee may access) and
confidential data.
Nosy co-workers and internal counter espionage.

Warning, if your users can access the 400 via PCs then software on PCs can
over-ride a lot of 400 security settings such as user profile "Limit
capabilities" (LMTCPB) = *YES. The user doesn't have access to the command
line in the 5250 sense, but PC access is much more powerful.  You need to
be studying the IBM manuals and popular 400 press on what to do about that
reality, then asking questions on general 400 forums.  Midrange_L does have
a forum that is specific to 400 Security tips.

We have a menu option which has RUNQRY and the user keys in the name of the
query they want to run.
We have a menu option which displays a directory of our queries, made
possible by an *OUTFILE of *QRYDFN and a corporate standard by the people
who create queries that our text descriptions be such that people can list
queries available by major application categories.

So, except for people who run the same query every time, for whom there is
a menu option with that already filled in, they run the option to get list
of queries available, see which they want, then run the option to RUNQRY in
which they key in whatever query name they going to run.  This means that
our people, to whom we have not granted command line authority, may run any
query/400 that we have created.

Another benefit of this is that for people who are authorized to create
queries, they can see what pre-exists, not re-invent the wheel, and can
more easily plagarize query techniques from each other, although I do have
a BPCSDOC directory of techniques that our people have figured out, with
example queries that use each.

For those employees whom you want to be doing WRKQRY as part of their
duties, but you still want to block command line access to DFU SQL and
other dangerous tools, WRKQRY can be on a menu option.

Perhaps some companies do not want employees to be able to run any query,
because some might be over confidential files.  This has come up with us,
and I said simple solution is to have several libraries to hold the
queries.  Put the confidential queries in library OTHER than the public
library.  If your department has a query that you do not want just anyone
in the whole company to be able to run, then it does not belong in the
library of queries open to anyone to run.  We have also used this approach
for people who are self-conscious about their learning curve.  They not
want other people to be watching them struggle to learn query 400 BPCS etc.
so they can do their learning in a private library.

The RUNQRY, fill in which one solution, is on-line, which has performance
implications.

We have had the entire 400 get locked up when someone tried to run a poorly
designed query that accesses several large files like inventory history and
cost master.
In the short term those tasks need to be:
WRKQRY change defaults then send it to JOBQ;
Study query and try to redesign it;
Candidate for making an RPG program to do this task.

Incidentally for those queries that do not need users to be mucking with
the selection criteria at time of run (which items, date range, etc.) we
have the RUNQRY in a CL, and another CL which sends the first one to JOBQ,
so someone takes the second CL from a menu option.  This lowers performance
drain.

There are security options that work at different versions of BPCS.  I was
waiting for someone on your version to reply with specifics, or you could
check the BPCS_L archives at http://archive.midrange.com/bpcs-l because
variations on this question have come up before. V6 security is much more
sophisticated than V4, closing many loopholes.

A related topic is when people are authorized access to some FILES which
contain some DATA that they are not authorized access to.  Sometimes
companies not want people to see figures on costs and profit margins,
performance figures on co-workers.  There are other ERP than BPCS that do a
good job managing security at the FIELD level, but I did see a thread on
MIDRANGE-L where data can be secured at the level of stream of data going
to 5250 screens, so that what actually shows up on standard program
interactive screen is censored if user-id not authorized to see certain
fields.  You need heavy duty programming staff to make this a reality.

I aint, so if & when we have reality of people need to use ABC300 but
management not want them to see some field of ABC300, then I create a
modification of the RPG program that blocks that field, then in the CL
stream from user-id determine which RPG version that person actually runs.

When we were on an earlier version of BPCS than our current 405 CD,
management was upset that some people were accessing data outside their
area of responsibility and misinterpreting and misusing the data in gossip,
such as credit card bills for business trips, and legal expenses in the
General Ledger.   I have wondered about people giving notice they leaving,
but first generating some printouts of customer and vendor data bases.  We
also had an episode where someone saw some payroll and HR print outs and
shared information on executive salaries with the union.   Our "solution"
involved setting certain files to be logged, so that any time anyone
accessed them, the log captured WHO and by what program, such as query or
DFU or whatever.  Then we had another program that looked at the log.

Tons of BPCS programs legitimately access files like the General Ledger Master.
For example, someone keying in payable invoices - the program checks GL to
make sure of some valid account that the invoice summary will eventually
make it into the GL.  This is invisible to the user.

So the program that looked at the log basically ignored entries that were
legitimate BPCS programs and also ignored accounting users who were
authorized for GL application, then listed all cases of OTHER people
accessing GL files by some means OTHER than legitimate BPCS programs.

That approach means that management can have a chat with the perpetrators
after they got caught with their hands in the cookie jar, which is Ok if
the only people using your computer network are your insiders, and you are
Ok with the performance hit for legitimate access to the files you
logging.  This might not be a good solution if you hurting for disk space.

You might check with your corporate lawyer advice before you start such a
program because the laws have evolved greatly regarding need for companies
to warn employees about what data usage is subject to monitoring.

I think it is simpler to TELL your work force that certain types of data is
OFF LIMITS TO YOU then hire trustworthy people, and provide sufficient pay
that disloyalty is not encouraged.  That way you not stuck with stumbling
over stupid careless intrusions then figuring out how to react, and not
knowing about intruders who are smart enough to cover their tracks.

Al Mac

>Hi,
>
>Why don't you set the user profile with "Limit capabilities" (LMTCPB) =
>*YES. Then the user doesn't have access to the command line., and cannot
>run queries. (And those queries you want them to run you need to build in
>the user menu).
>
>Klara


>Hi ...
>
>Due to BPCS files having group profile of SSA, is there a method to
>restrict  users accessing certain  sensitive data files via query?
>
>We are using BPCS version 6.1
>
>Thanks in Advance
>
>Gehan Jayasundera
>Hella Australia
>
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/bpcs-l.
>

-
Al Macintyre (macwheel99@sigecom.net via Eudora)