Adding a new TSO user to MVS3.8J (TK3)
STEP1 - Ensure a new usercatalog ALIAS for the user is created BEFORE adding the user
Before the new user can be permitted to logon you MUST create a user catalog alias for the user to ensure all datasets created by the user with their own userid prefix appear in the correct user catalog. If you fail to perform that step all datasets created with the userid prefix will attempt to be catalogued into the master catalog. On TK3 withour RAKF this will result in password prompts on the system consoles needing replies which will eventually time out (or be rejected by operators) and on sytem with RAKF access will simply be denies to the master catalog, both resulting in uncatalogued datasets being created.
If you have not documented your catalog structure, to display what usercatalogs you have been wildly creating that may exist on your system, the following will work on TK3 and TK4+ which use a master catalog sys1.vmastcat on the mvsres volume. The JCL will list all user catalogs and the prefixes that are managed by those catalogs.
//MARKJ JOB (0),'LIST USERCATS',CLASS=A,MSGCLASS=T //LISTCAT EXEC PGM=IDCAMS,REGION=1024K //SYSPRINT DD SYSOUT=* //DISK0 DD UNIT=3350,VOL=SER=MVSRES //SYSIN DD * LISTCAT UCAT ALL CAT(SYS1.VMASTCAT) /* //
Both TK3 and TK4- seem to use sys1.ucat.tso on volser pub000 for tso user aliases,
on my system (if you have cloned my live or container environment) you will see I
prefer to use sys9.ucat.tsomid on volume mdtso1 as I decided to keep all general
purpose tso activity confined to one volume.
For TK3 to add a new alias, for example a userid of FRED
//MARKJ JOB (0),'ADD USER ALIAS',CLASS=A,MSGCLASS=T //LISTCAT EXEC PGM=IDCAMS,REGION=4096K //SYSPRINT DD SYSOUT=* //DISK0 DD UNIT=3350,VOL=SER=PUB000 //ASMDUMP DD DUMMY //SYSIN DD * DEFINE ALIAS ( NAME(FRED) RELATE(SYS1.UCAT.TSO) ) /* //
STEP2 - Add the new TSO user using ACCOUNT
If a user is not defined using ACCOUNT attempting to logon to TSO will result in an error USER XXXX NOT PERMITTED TO USE TSO and you will be repeatedly prompted for a valid userid.
From the TSO ready prompt use "account".
For normal users use the below syntax
ADD (USERID PASSWORD * PROCNAME) NOLIM NOOPPER NOACCT JCL MOUNT NOPERFORM UNIT(TSO))
The default is NOMOUNT, I believe mount is required for a user to be able to use tapes even though it has wider implications and nomount should definately be used if users are not expected to use tapes.
For admin users use one of the two entries below.
ADD (USERID PASSWORD * PROCNAME) NOLIM OPPER NOACCT JCL MOUNT USERDATA(0000) NOPERFORM UNIT(SYSDA) ADD (USERID PASSWORD * PROCNAME) NOLIM OPPER ACCT JCL MOUNT USERDATA(0000) NOPERFORM
If unit is left blank it defaults to none, use that or sysda for admin users so they can logon even it all the volumes in the TSO group are offline.
The ACCT facility should only be given to users you want to be able to add/delete users, and
all admin users should have the OPER facility.
Note: the * in the braces for account details in the account-number assigned to the user if you are using accounts
The PROCNAME must be a valid TSO procedure in one of the linklisted system procedure libraries.
The PROCNAME used/supplied in TK4-/TK3 is TSOLOGON execs clist USRLOGON in sys1.cmdproc, if you
are on an unmodified TK3 system you should use that as the PROCNAME.
For TK4ROB from teh 20220914 release use ISPLOGON, also note for systems with Wallys ISPF
installed such as that one when adding a user you must also on the account line use "SIZE(8192)",
although I suppose you could code a region of that on the logon proc also [note: 4096 is not
enough to stop abends for RPF on that release].
After adding from account you can "list (userid)" to see if it was correctly added and "delete (userid)" to remove it and then re-add it fixing any parameters you missed.
Note: if at a later point in time you wish to permanently delete a user remember that as well as deleting the user using "account" you must locate and delete all the user datasets (both cataloged and uncataloged) plus delete the user alias from the usercatalog.
If you are using native TK3 you can now logon with the new user using the password you set for the user and have completed the task of adding a new TSO user. But if you have RAKF installed read on.
STEP3 - Defining the new user to RAKF on systems that use RAKF
If you have installed RAKF onto TK3 or are using TK4- which has RAKF already installed there are additional steps. Trying to logon with just the account entry created will result in an error being logged to the console "RAKF0004 INVALID ATTEMPT TO ACCESS SYSTEM: USER:XXXX"
RAKF users and resource rules are configured in SYS1.SECURE.CNTL, and it is important to note that all control members must have all data entries in alphabetical order.
Review member PROFILES which defines that dataset access rules, if you intend to add the new user to a brand
new group you will need to add rules for that new group if you wish to give it more access than the default
access granted to datasets.
At a minimum you will have to create a profile rule for the userid prefix to permit the new user to create datasets,
unless you have wisely implemented a group userid naming policy of naming all users with XXX* prefixes depending
on the group they are assigned to and have a profile rule for access on dataset prefix XXX*, and that people is why
on mvs systems userids for people in the same group start with the same prefix as it avoids the need to mess about with
the individual user dataset access rules when a user is added.
In member USERS you must at a minimum define the new userid, the group they are in, and a password for the user.
The password defined here replaces the one defined in the TSO ACCOUNT database. Also the Y/N flag you
will see near the end of the entry defines whether the user can change there own RAKF password using the
normal tso "logon userid password/newpassword" syntax.
It is critical that if you make changes to either the USERS or PROFILES members you test them from a console session with the started procedures S RAKFUSER or S RAKFPROF before your next IPL to detect any errors such as entries out of order, which if not fixed will prevent anyone logging on.
You should also refer to RAKF documentation on how to have a user in multiple groups. For example my personal userid is in admin/install/rakfadm groups and the actual system admin userid is only in admin/rakfadm groups as that should not be playing with install files.
Additional notes for RAKF systems
RAKF does not actually support DASDVOL or ALLOCAT rules, so there is no way of actually stopping a user creating datasets on any volume they want. If you have errant users you may want to look at my program which searches for datasets on incorrect volumes and migrates them to the correct ones.