Have enabled SSL on z/OS XCOM instance for ACF2 (SECURITY=ACF2) using certificates stored within the ACF2 keyring.
When attempting to initiate transfers getting the following error on the initiating side:
13:43:38 10.1.68.41 008850 IDSECURE XCOMM0811I STARTING SECURE TCP/IP CONNECTION TO PORT=08045, IP=xxx.xxx.xxx.xxx
13:43:38 10.1.68.41 008850 IDSECURE XCOMM0813I SECURE TCP/IP CONNECTION REQUESTED WITH DEST=**NONE**, PORT=08045, IP=xxx.xxx.xxx.xxx
13:43:38 10.1.68.41 008850 IDSECURE XCOMM0780E Txpi 319: IRRSDL00 USERID=<USER1 > KEYRING=<RINGNAME> SAF_RC=8 RACF_RC=8 RACF_RSN=8
13:43:38 10.1.68.41 008850 IDSECURE XCOMM0093E ERROR ACTIVATING SESSION - SESSION NOT ESTABLISHED
13:43:38 10.1.68.41 IPv4-SSL XCOMM0780E Txpi 319: IRRSDL00 USERID=<> KEYRING=<RINGNAME> SAF_RC=8 RACF_RC=8 RACF_RSN=8
13:43:38 10.1.68.41 IDSECURE XCOMM0818I SECURE TCP/IP CONNECTION ENDED WITH IP=xxx.xxx.xxx.xxx
13:43:38 10.1.68.41 IPv4-SSL XCOMM0818I SECURE TCP/IP CONNECTION ENDED WITH IP=xxx.xxx.xxx.xxx
Release : 12.0
Component : XCOM Data Transport for z/OS
This page for IRRSDL00 indicates RACF_RSN=8 (RACF Reason code 8) which means "Not RACF-authorized to use the requested service.": https://www.ibm.com/docs/en/zos/2.4.0?topic=library-return-reason-codes
The error is due to the fact that the keyring has been setup for the XCOM started task user but the batch logon user USER1 is being used to access it.
The root cause of that behaviour is unrelated to the actual SSL/keyring settings and rather it is due to the combination of the XCOM USEROVR and USERPRO parameter values being used. Currently USEROVR=NO and USERPRO=YES which means the transfer will ignore any LUSER parameter set and instead it will use the user id for the TYPE=SCHEDULE batch job.
To use different credentials, specify USEROVR=YES and USERPRO=YES and provide the appropriate LUSER/LPASS parameters for the required credentials for the transfer.