When TSSSIM is used to simulate an access via a certain CPU, the result does not agree with the existing permit.
For example: (pertaining parameters set in bold)
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 the following response is issued, showing access denied:
==> 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 the TSSSIM access should actually be allowed, not denied. What is wrong?
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.