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

book

Article ID: 52954

calendar_today

Updated On:

Products

CA Cleanup CA Datacom - DB CA Datacom CA Datacom - AD CA Datacom - Server CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA Datacom/AD CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Top Secret CA Top Secret - LDAP CA 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: