ALL XCOM users must have an OMVS segment, even in the case where only 'standard' MVS datasets are being transferred.
The answer was thought to be 1) unreasonable - it is the XCOM server that is performing the transfer after all, and 2) creates a major security risk locally as providing users with an OMVS segment will allow them to use other mainframe products that we do not want them to have access to.
XCOM is the preferred method of file transfer locally but the requirement for every XCOM user to have an OMVS segment could be seen to be an issue. The question asked was "Is there is any way to remove the requirement for XCOM users to have an OMVS segment?".
Release : 12.0
Component : CA XCOM Data Transport for z/OS
The following are cases where an OMVS segment is absolutely required:
- If SECURITY=SAF is configured for the server, an OMVS segment with UID(0) is required for the XCOM server address space. (This is an IBM requirement. See the IBM z/OS UNIX Security Fundamentals Redpaper for more details on z/OS UNIX Security.)
- Other USERIDs accessing an XCOM server configured with SECURITY=SAF must have an OMVS segment. For these IDs, the UID(0) is not required.
- If any USS files are to be transferred
- If any SSL/TLS encryption is to be used
--- The configssl.cnf (for OpenSSL) and configsystemssl.cnf (for System SSL) files reside in USS, and therefore require an OMVS segment to access them.
--- OpenSSL stores its certificates in USS.
---If System SSL certificates are kept in the System SSL Keystore database, it resides in USS.
- Standard TCP/IP transfers access "/etc/hosts” if the SYSTCPD DD statement is not present in the JCL.
- Standard TCP/IP socket passing logic uses “process ID” which is obtained by doing a “DUB” of the subtasks as being USS-capable. This impacts all users of TCP/IP connections to an XCOM partner.
The decision to require OMVS segments was reached around 2011 due to the fact that nearly all of the XCOM Data Transport for z/OS customers require it for at least one of the above reasons.