<<We've been directed to restrict programming staff's access to
production data to read-only if possible.  The only method which makes
sense to me - sure it's brute force, but it should work - is to create a
separate account for them and allow Read and Lock access to the
production accounts and selected groups within those accounts.>>
 
You probably want to have your security fences up for the production
account anyway; with inbound ftp, you can inadvertently have a lot more
people with write access than you had planned. Typically, you set the
access to
 R,L,X:ANY;W,A:AC
 
on the production account. Alternatively, you can control access at the
group level, but it's a lot more work if you have a lot of groups in the
account. You'll also find that there are good reasons to use a similar
access set for all of your frequently-used accounts; it's a real drag
when a user inadvertently (or maliciously-it happens) deletes, from some
other account, the only readily-accessible copy of the source for your
application.
 
<<This would allow them to open databases and files in shared- or
exclusive-read mode, but would prevent write-mode access.  ACD's are also
an option, but this can probably be done safely at the group level.
 Certain applications would not be available to them because the opens
are done in shared-write mode only, but this is not a serious drawback as
most support functions require access via other utilities.
 
Can anyone shoot holes in this scheme?  Please feel free to do so, but
only if you can offer a reasonable alternative!   :) :)     Thanks!!>>
 
Since it's what we use, it must be OK ;-)
 
There are some other issues:
1)  If you use any of the Dictionary-based products (VPLUS, Transact,
INFORM, COBOL), you need to create a separate account (like "DICT") to
hold the dictionary if you turn off cross-account write access for the
development account. Since your production users need write access to the
dictionary to store their INFORM report definitions, and the developers
need write access to it for several reasons, it is much safer to put it
in a dedicated account that doesn't have the write fences up; that way,
you can protect the other accounts.
2)  Don't forget that users with SM capability get write access to
everywhere, including non-current accounts that have W:AC. You'll
probably want to limit the number of users that have SM capability.
 
Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]