Using the TWS security file, it is possible to remove the ability for a subset of users from seeing any objects in the plan or database, except for those belonging to an agent, or set of agents, you designate. There are 2 elements to enabling this functionality:-
– The optman setting enListSecChk. Use optman chg enListSecChk = yes to enable it. This is a global setting, so only enable it once you’re happy all of your users have the LIST attribute assigned in the security file.
– The LIST attribute in the security file assigned to their position in the security file stanza. If a user does not have the LIST attribute, they will not be able to “see” an object in the plan or database.
In the example below, the user joebloggs has full control over the database definitions for agents prefixed SERVER and can make changes in the plan only if the agent name begins with SERVER. Despite there being other agents attached to the Master Domain Manager, he will not see them at all.
USER SERVERADMIN CPU=@+LOGON=joebloggs BEGIN USEROBJ CPU=SERVER@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,ALTPASS,UNLOCK JOB CPU=SERVER@ ACCESS=ADD,ADDDEP,ALTPRI,CANCEL,CONFIRM,DELDEP,DELETE,DISPLAY,KILL,MODIFY,RELEASE,REPLY,RERUN,SUBMIT,USE,LIST,UNLOCK,SUBMITDB SCHEDULE CPU=SERVER@ ACCESS=ADD,ADDDEP,ALTPRI,CANCEL,DELDEP,DELETE,DISPLAY,LIMIT,MODIFY,RELEASE,REPLY,SUBMIT,LIST,UNLOCK RESOURCE CPU=SERVER@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,RESOURCE,USE,LIST,UNLOCK PROMPT ACCESS=ADD,DELETE,DISPLAY,MODIFY,REPLY,USE,LIST,UNLOCK FILE NAME=@ ACCESS=BUILD,DELETE,DISPLAY,MODIFY,UNLOCK CPU CPU=SERVER@ ACCESS=ADD,CONSOLE,DELETE,DISPLAY,FENCE,LIMIT,LINK,MODIFY,SHUTDOWN,START,STOP,UNLINK,LIST,UNLOCK,RUN,RESETFTA PARAMETER CPU=SERVER@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,UNLOCK CALENDAR ACCESS=ADD,DELETE,DISPLAY,MODIFY,USE,UNLOCK REPORT NAME=@ ACCESS=DISPLAY EVENTRULE NAME=@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,LIST,UNLOCK ACTION PROVIDER=@ ACCESS=DISPLAY,SUBMIT,USE,LIST EVENT PROVIDER=@ ACCESS=USE VARTABLE NAME=@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,USE,LIST,UNLOCK END
Click the image to enlarge.
The only jobstreams joebloggs can see in the database are those that belong to SERVER1 and SERVER2
Similarly, despite there being other jobstreams in the plan belonging to other agents, this user can’t see them.
The above restrictions also apply if the user is using conman or composer rather than the Tivoli Dynamic Workload Console.
If you wish to restrict the visibility of TWS objects to a subset of agents, and you also only want that access to be read-only, an example security file stanza is below. Note the LIST attribute i
USER READONLY CPU=@+LOGON=joebloggs BEGIN USEROBJ CPU=SERVER@ ACCESS=DISPLAY JOB CPU=SERVER@ ACCESS=DISPLAY,LIST SCHEDULE CPU=SERVER@ ACCESS=DISPLAY,LIST RESOURCE CPU=SERVER@ ACCESS=DISPLAY,LIST PROMPT ACCESS=DISPLAY,LIST FILE NAME=@ ACCESS=DISPLAY CPU CPU=SERVER@ ACCESS=DISPLAY,LIST PARAMETER CPU=SERVER@ ACCESS=DISPLAY CALENDAR ACCESS=DISPLAY REPORT NAME=@ ACCESS=DISPLAY EVENTRULE NAME=@ ACCESS=DISPLAY,LIST ACTION PROVIDER=@ ACCESS=DISPLAY,LIST EVENT PROVIDER=@ ACCESS=USE VARTABLE NAME=@ ACCESS=DISPLAY,LIST END Mark Delaney SYSTEMSMANAGED Ltd
The only jobstreams joebloggs can see in the database are those that belong to SERVER1 and SERVER2
If there were other Workstations defined with SERVER123
SERVERABC SERVER1YZ
then these will also be available to joebloggs
regards Nige
That’s right. If you use a wildcard in the server name, it will pick up all variations of it. You can explicitly name each workstation (SERVER1,SERVER2) or you can use a combination of wildcards and exclusions to get what you’re after.