Clarification on User Modelling when invoked from a Partial Security Exit

Document ID : KB000029152
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

This document provides some guidelines when user modelling is implemented. It is a common way to create a new user without any definition in UAMS (User Access Maintenance Services) dataset.

Solution:

User Modelling is a facility to automatically create a new user not already defined in UAMS dataset based on a model. The benefit is to maintain the list of active users without the need to :
  1. predefine those who are never logged on
  2. keep those who are inactive or left for a long time
 
There are different types of Partial Security exit :
1. NMSAF    : more than one model can be specified in SXPARMS member through a list of models.
2. PARTSAF or User_load_module_name : only one model can be specified through SYSPARM MODLUSER.
 
The model is referenced through any existing definition in UAMS under two types of definitions :
  •  USER
  •  GROUP
 
In order to simplify the user administration, it is possible to reference another Group from any UAMS definition.
This allows a global change for all users attached to this group, instead of an individual change, with immediate effect for any new user logon.
 
There is one restriction to be noticed :
 
  • If a group definition is referencing another group, then the reference group is not inherited, i.e : all definitions in the reference group are ignored.
  • If a user definition is referencing a group, then the reference group is inherited, i.e : all definitions from the reference group are imported.
 
It results in the following and particular case :
 
A model user references a Group definition GRP1 without any privilege and access.
The Group GRP1 references a Group Id GRP2 with a minimum of privilege.
At the first connection, the end user is getting a panel to enter the name, phone and location. When he presses PF03 to save and quit, he is connected to the region with U.M (CAS Messages) instead of M (MAI Menu).
The &LOGON has 'M' as user data (for MAI access).
The reason is due to no privilege access derived from GRP1. Only User Services is configured and allowed. Thus, 'M' is wrongly executed.
When the user  logs off and logs on again, everything works fine, because the model has been used to create the new user in UAMS with record type 'U', the Group Id GRP2 is correctly addressed on the second logon.