Clarification on User Modeling when invoked from the Partial Security Exit
search cancel

Clarification on User Modeling when invoked from the Partial Security Exit

book

Article ID: 28817

calendar_today

Updated On:

Products

CMDB for z/OS NetSpy Network Performance NetMaster Network Automation SOLVE NetMaster Network Management for SNA NetMaster Network Management for TCP/IP NetMaster File Transfer Management SOLVE:Operations Automation SOLVE:Access Session Management SOLVE:FTS

Issue/Introduction

Clarification on User Modeling when invoked from the Partial Security Exit

Environment

Release: SLFTS.00200-12-SOLVE:FTS
Component:

Resolution

User  Modeling is a facility to automatically create a new User Definition not already defined in the User Access Maintenance Services (UAMS) dataset. The reference to a model can be done through a partial  security settings. The benefit is the ability to maintain the list of active user definitions without needing to:

- Predefine those who have never logged on before.

- Maintain user definitions that have become inactive.

 

The model can be applied through any existing UAMS definition which can be either of these two types:

- USER

- GROUP

 

In order to simplify user administration, a group can be used as a common reference to all users attached to it and may avoid redundancy in UAMS definitions.

The change in the Group definition takes immediate effect upon any user logon.

There is one restriction to be aware of when defining Groups with or without modeling :

  • The User definition may reference a Group, but a Group definition cannot reference another group due to inheritance of security settings not applicable between groups 

Failing this observation can cause a number of confusing problems on the first logon as in the following scenario :

A user is assigned a model Group definition, GRP1, without any privilege and access.

The GRP1 definition references another Group, GRP2, where the correct security settings reside.

At the first logon, the end user is presented with a panel to enter the name, phone and location. After entering the required information on the first panel followed by PF03, he gets an unexpected panel derived from GRP1 settings. The GRP2 group has no effect at this stage due to no inheritance as explained above. The new User UAMS record is created at this time and is effective on the next logon. 

On the subsequent logon, the user definition is working as expected.

This is why it is not recommended to use a Group definition for modeling, even though you have the capability to do it.