The following recommendations are intended to reduce the amount of work
involved:
- Define transactions in the resource group class, GCICSTRN. This minimizes
the amount of effort needed to define and maintain transaction profiles and
their associated access lists, and also keeps down the size of in-storage
profiles. However, note that using resource groups only reduces the amount
of storage required if you avoid defining duplicate member names.
- Add users to the access list in groups rather than as individual users,
and define access as READ.
- Use generic profiles or member names wherever possible.
For example, the following RDEFINE and PERMIT commands illustrate some
payroll transactions, with access given to members of the payroll department:
RDEFINE GCICSTRN salarytrans
NOTIFY(pay_manager)
UACC(NONE) ADDMEM(Pay1, Pay2, Pay3,..., Payn)
PERMIT salarytrans CLASS(GCICSTRN)
ID(paydept_group_userid) ACCESS(READ)
In this example, you could instead define the members generically, such
as P* or Pay*.
However, before you define a generic profile you must issue the command:
SETROPTS GENERIC(TCICSTRN)
You cannot specify the GCICSTRN class, because you cannot group classes
with the SETROPTS GENERIC command.
If you have transactions that anyone can use, you can avoid maintaining access lists
for them by defining RACF transaction profiles for them with UACC(READ). For
example:
RDEFINE TCICSTRN tranid UACC(READ)
If you want to avoid defining any of your transactions to RACF, you can
specify universal access as follows:
RDEFINE TCICSTRN ** UACC(READ)
You then need to define to RACF only those transactions that require more
restrictive security.
Note: If you use a profile like that described above, define new
profiles to RACF before installing new CICS resources.