Discussion:
ISF.CONNECT.*
(too old to reply)
Barbara Nitz
2018-07-04 08:47:16 UTC
Permalink
Raw Message
Something has changed with SDSFAUX between z/OS 2.1 and z/OS 2.3.

Under z/OS 2.3, each and every user gets a RACF Message when they access their part of SDSF (that's the primary RACF panel). That missing right is for ISF.CONNECT.system, which is described as access to SDSFAUX. None of those users have any need to execute function provided by SDSFAUX, so I see no reason to give them read in that profile. This did not happen under 2.1.
These users can work normally with SDSF after the ICH408I. The RACF error is mostly irritating to them and ugly.

Why is the check for that right not 'silent' like all the others?

Short of granting the right, is there any way to make the RACF message go away?

Regards, Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2018-07-04 10:38:29 UTC
Permalink
Raw Message
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



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz
Sent: Wednesday, July 4, 2018 9:47 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: ISF.CONNECT.*

Something has changed with SDSFAUX between z/OS 2.1 and z/OS 2.3.

Under z/OS 2.3, each and every user gets a RACF Message when they access their part of SDSF (that's the primary RACF panel). That missing right is for ISF.CONNECT.system, which is described as access to SDSFAUX. None of those users have any need to execute function provided by SDSFAUX, so I see no reason to give them read in that profile. This did not happen under 2.1.
These users can work normally with SDSF after the ICH408I. The RACF error is mostly irritating to them and ugly.

Why is the check for that right not 'silent' like all the others?

Short of granting the right, is there any way to make the RACF message go away?

Regards, Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Conley
2018-07-04 15:02:29 UTC
Permalink
Raw Message
Post by Rob Scott
Barbara,
"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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2018-07-04 15:23:17 UTC
Permalink
Raw Message
Tom,

I think "cheated" is a bit strong.

If migration actions were omitted it was not by design or with intention to deceive, it was most likely because it got missed due to human error.

Rob Scott
Rocket Software.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Conley
Sent: Wednesday, July 4, 2018 4:02 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ISF.CONNECT.*
Post by Rob Scott
Barbara,
"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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Conley
2018-07-04 16:00:47 UTC
Permalink
Raw Message
Post by Rob Scott
Tom,
I think "cheated" is a bit strong.
If migration actions were omitted it was not by design or with intention to deceive, it was most likely because it got missed due to human error.
Rob Scott
Rocket Software.
Rob,

When I asked why the ISFTABL message wasn't a migration action, I was
told flat out "It's not". I suspect Barbara got the same when asking
about the ISF.CONNECT profile.

Tom

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2018-07-04 16:22:58 UTC
Permalink
Raw Message
Tom,

I think the "ISF.CONNECT.system" issue should have been a migration action and I will see if I can get the documentation updated.

Rob Scott
Rocket Software
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Conley
Sent: Wednesday, July 4, 2018 5:01 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ISF.CONNECT.*
Post by Rob Scott
Tom,
I think "cheated" is a bit strong.
If migration actions were omitted it was not by design or with intention to deceive, it was most likely because it got missed due to human error.
Rob Scott
Rocket Software.
Rob,

When I asked why the ISFTABL message wasn't a migration action, I was told flat out "It's not". I suspect Barbara got the same when asking about the ISF.CONNECT profile.

Tom

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2018-07-04 16:13:13 UTC
Permalink
Raw Message
For the record, you do not need ISFTABL to be allocated for SDSF to function and, in fact, I run without ISFTABL on many of the systems that I use.

If ISFTABL is not found, SDSF retrieves and stores system commands in the ISPF profile dataset and in this mode the user can store up to 50 commands.

ISFTABL is only required if the user wants to store more than 50 commands.

The reason that SDSF does this is that there is an internal limit to the max size of a ISPF profile member (64K-ish), and SDSF would very quickly exceed that size if hundreds of z/OS system commands were stored using standard VPUT processing. For this reason, it was chosen that we would store the system commands in an ISPF table instead.

From what I can tell, this new feature was documented, but not in the migration section as maybe it was deemed an enhancement and not a change to existing behaviour.

Rob Scott
Rocket Software



================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Conley
2018-07-04 17:55:46 UTC
Permalink
Raw Message
Post by Rob Scott
For the record, you do not need ISFTABL to be allocated for SDSF to function and, in fact, I run without ISFTABL on many of the systems that I use.
If ISFTABL is not found, SDSF retrieves and stores system commands in the ISPF profile dataset and in this mode the user can store up to 50 commands.
ISFTABL is only required if the user wants to store more than 50 commands.
The reason that SDSF does this is that there is an internal limit to the max size of a ISPF profile member (64K-ish), and SDSF would very quickly exceed that size if hundreds of z/OS system commands were stored using standard VPUT processing. For this reason, it was chosen that we would store the system commands in an ISPF table instead.
From what I can tell, this new feature was documented, but not in the migration section as maybe it was deemed an enhancement and not a change to existing behaviour.
Rob Scott
Rocket Software
Rob,

If this was a new feature and not a migration action, then you have to
make it work as before, and not issue the message by default (turn off
the limit option that the message references). The users noticed the
new behavior, since SDSF decided to enable the new limit by default, but
did not follow up with a migration action for the rest of it. Yes, I'm
being anal retentive, but I've taken more than a few support calls for
this one.

Tom

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Barbara Nitz
2018-07-05 05:54:54 UTC
Permalink
Raw Message
I am curious: Why is Rocket Software defending missing SDSF actions and bad documentation??? Has IBM 'outsourced' the SDSFAUX server?

I am annoyed with the ISFTABL thing (which we addressed in our logon procedure), too, because that message was irritating all of us.

The ISF.CONNECT thing is much more irritating: When you customize SDSF, quite clearly the users only saw in the functions they were entitled to use. That was true up to z/OS 2.1. (Can't speak for 2.2 since we went straight to 2.3.)

I feel strongly that issuing the ICH408I for *every* user is not an RFE thing, it is a blatant error since we do NOT get ICH408I for all the other functions that the users are not entitled to. Besides, the message is bogus, since the not priviledged users all can work and do the same things that they always could.

Rob, in case you are not aware: From a RACF point of view, users should ONLY see what they have to see. That is not only corporate mandate where I work, it is also a general principle that all banks in Germany are forced to obey. So needlessly allowing users to see/access things that they cannot use because the RACF test for ISF.CONNECT does not follow SDSF standards is against all usual practices. We have taken more than our share of calls because of that.

Since you cited the SDSF customization Guide: I went through it. And the wording 'SDSF SERVER' isn't clear at all, because that encompasses both the SDSF address space itself *and* SDSFAUX. The rest of the occurences for that profile name are all as a second mandatory access right when some function located in SDSFAUX is used. That is also the way the ptfs I installed in 2.1 (that gave us SDSFAUX) worked.

Given the reaction here (and since this is obviously a Rocket Software thing), I will not waste my time opening an RFE. I will just define that profile and then tell the auditors to take this up with IBM by showing the documentation.

Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Scott
2018-07-05 08:23:21 UTC
Permalink
Raw Message
Barbara,

Rocket Software partnered with IBM to enhance SDSF a couple of years ago - the initial result of this work was the SDSFAUX server and the new commands in SPEs for 2.1 and 2.2.

SDSF users should only see menu options enabled for commands that they have ISFCMD SAF authority to, this has not changed in SDSF 2.3.

Access to ISF.CONNECT only allows the user to use SDSF server provided facilities, it does not grant access to any command and it does not override ISFCMD SAF authority.

The access check to ISF.CONNECT was introduced in the SPE that introduced the SDSFAUX server, however "where" the check was made has changed in SDSF 2.3.

You are correct in that the meaning of "SDSF Server" really means both the SDSF and SDSFAUX address spaces in z/OS 2.3.

As stated in another reply, I am working to get the migration documentation updated.

Rob



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz
Sent: Thursday, July 5, 2018 6:55 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ISF.CONNECT.*

I am curious: Why is Rocket Software defending missing SDSF actions and bad documentation??? Has IBM 'outsourced' the SDSFAUX server?

I am annoyed with the ISFTABL thing (which we addressed in our logon procedure), too, because that message was irritating all of us.

The ISF.CONNECT thing is much more irritating: When you customize SDSF, quite clearly the users only saw in the functions they were entitled to use. That was true up to z/OS 2.1. (Can't speak for 2.2 since we went straight to 2.3.)

I feel strongly that issuing the ICH408I for *every* user is not an RFE thing, it is a blatant error since we do NOT get ICH408I for all the other functions that the users are not entitled to. Besides, the message is bogus, since the not priviledged users all can work and do the same things that they always could.

Rob, in case you are not aware: From a RACF point of view, users should ONLY see what they have to see. That is not only corporate mandate where I work, it is also a general principle that all banks in Germany are forced to obey. So needlessly allowing users to see/access things that they cannot use because the RACF test for ISF.CONNECT does not follow SDSF standards is against all usual practices. We have taken more than our share of calls because of that.

Since you cited the SDSF customization Guide: I went through it. And the wording 'SDSF SERVER' isn't clear at all, because that encompasses both the SDSF address space itself *and* SDSFAUX. The rest of the occurences for that profile name are all as a second mandatory access right when some function located in SDSFAUX is used. That is also the way the ptfs I installed in 2.1 (that gave us SDSFAUX) worked.

Given the reaction here (and since this is obviously a Rocket Software thing), I will not waste my time opening an RFE. I will just define that profile and then tell the auditors to take this up with IBM by showing the documentation.

Barbara

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mick Graley
2018-07-05 17:40:40 UTC
Permalink
Raw Message
I believe turning off "write to programmer" messages with TSO PROFILE
NOWTPMSG will hide the ICH408I but you might miss something else you want
to see.
Cheers,
Mick.
Post by Barbara Nitz
Something has changed with SDSFAUX between z/OS 2.1 and z/OS 2.3.
Under z/OS 2.3, each and every user gets a RACF Message when they access
their part of SDSF (that's the primary RACF panel). That missing right is
for ISF.CONNECT.system, which is described as access to SDSFAUX. None of
those users have any need to execute function provided by SDSFAUX, so I see
no reason to give them read in that profile. This did not happen under 2.1.
These users can work normally with SDSF after the ICH408I. The RACF error
is mostly irritating to them and ugly.
Why is the check for that right not 'silent' like all the others?
Short of granting the right, is there any way to make the RACF message go away?
Regards, Barbara
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...