Using TSSSIM to check resource access does not seem to honor the SYSID specified in the Permission.

Products

• Cleanup
• Datacom
• DATACOM - AD
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware
• Top Secret
• Top Secret - LDAP
• Top Secret - VSE

Issue/Introduction

Question:

When I use TSSSIM to simulate an access via a certain CPU, the result does not agree with the existing Permission.

For example: (pertaining parms set in fat printing)

I submit this TSSSIM test on CPU SYS1:

==> LOGON ACID(MYACID) FAC(BATCH) MODE(FAIL) CPU(SYS2) TRACE
==> ACID    = MYACID     NAME    = MY ACID
==> REG15   = 00         FDB-RC  = 00      FDB-DRC = 00
==> SECURITY OVERRIDES:  <NONE>

And I get this response, showing an access denial:

==> TSS8370I SIMULATED SESSION SUCCESSFULLY ESTABLISHED.
  
==> $DSN('SYS1.PARMLIB') ACCESS(UPDATE)
==> TSS7228E Dataset Not Available From This System
==> TSS7230E DSN: SYS1.PARMLIB
==> TSS8381I RESOURCE ACCESS DENIED
==> REG15   = 08               FDB-RC  = 08          FDB-DRC = 7B
==> REQUEST = 6000             ALLOWED = 6000        VOLUME  = 1000
==> REASON  = PERMITTED        *USER*                RULE #    12
==> VOL-FLG = 00-00-00-00                            SUB-FLG = 80-00-01-00-01

However, the pertaining permission looks like this:

XAUTH    = SYS1.PARMLIB               ACID(MYACID)
ACCESS   = UPDATE                                                       
ADMIN BY = BY(DEPTSYS)  SMFID(SYS2)   ON(02/12/2009)  AT(16:30:44)
SYSID    = SYS2

so that the TSSSIM access should actually be allowed, not denied.

What is wrong?

Answer:

The CPU operand that you supplied is used simply at LOGON to see if you are allowed access to that resource. It existed long before IBM even had a SYSID source and is in no way related to SYSID resource.

The cause of the problem is that TSSSIM does not actually process the SYSID parameter.

When the CPU(SYS2) parameter was entered, it was not regarded as a SYSID from which the simulation should take place.

The actual simulation in TSSSIM is always done from the SYSID where the ACID doing the simulation is currently logged on.

In the above example, the simulation was done from the system SYS1, and therefore the access was denied, in accordance to the permission that shows SYSID = SYS2.

If the TSSSIM execution were done from system SYS2, the access would have been permitted.

Environment

Release: TOPSEC00200-15-Top Secret-Security
Component: