On 7/4/2018 6:38 AM, Rob Scott wrote:
Barbara,
From the SDSF z/OS 2.3 Operation and Customization Guide :
"As of z/OS V2R3, SDSF requires the SDSF and SDSFAUX address spaces to be
active for full functionality. The SDSF address space manages connections,
processes ISFPRMxx statements, handles operator commands, and starts and
stops SDSFAUX. The SDSFAUX address space is used for data gathering
requests.
When a user accesses SDSF, the SDSF client program attempts to connect to the
SDSF address space. To connect to the SDSF server, the user must have READ
access to the ISF.CONNECT.system resource in the SDSF class."
SDSF for z/OS 2.3 relies more heavily on SDSF server provided functionality and services, whereas
in z/OS 2.1 and 2.2 the SDSF client code was loosely coupled to the SDSFAUX address space for new
functionality only (eg the "DEV" or "LNK" commands).
By granting READ access to ISF.CONNECT.system, a user or group is a valid user
of SDSF server functionality however the user or group can still be restricted
from SDSF commands using the normal ISFCMD profiles.
If you feel strongly that SDSF should have a customization option to suppress
the ICH408I for ISF.CONNECT.system, please raise an RFE as this will help the
development team prioritise the request.
Rob Scott
Rocket Software
Rob,
All due respect, you guys cheated on the migration actions required for
this to happen. Just like when I reported the ISFTABL message that his
now issued under V2R3. If you needed ISFTABL for SDSF to work, you
should have had that as a migration item.
Regards,
Tom Conley
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
