Discussion:
ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
Add Reply
Dunlap, Curtis L
2018-10-09 15:11:56 UTC
Reply
Permalink
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-)

I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message opening SDSF:
ISF452E SDSFAUX communications failed, return code 0x00000008,
reason code 0x00370801, function "connect". SDSFAUX not available
or function not supported
I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers to expedite the OS upgrade and am now receiving this message when SDSF is executed from TSO, ISPF or batch. I've struck out doing searches on the webernets (and IBM as well) for this particular scenario, but from what I've read, I should still be able to use SDSF w/o the servers running. Anybody out there have any good ideas short of converting?

Thanks in advance.
Curt.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Matt Hogstrom
2018-10-09 16:41:46 UTC
Reply
Permalink
If its the same problem I had you have to make the SDSF class Raclistable.

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/RACF_SDSF_RACLIST_V2R3.htm

Matt Hogstrom
***@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270

I just read a book on Stockholm Syndrome,
it was pretty bad at first, but, by the end I kind of liked it.
Post by Dunlap, Curtis L
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-)
ISF452E SDSFAUX communications failed, return code 0x00000008,
reason code 0x00370801, function "connect". SDSFAUX not available
or function not supported
I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers to expedite the OS upgrade and am now receiving this message when SDSF is executed from TSO, ISPF or batch. I've struck out doing searches on the webernets (and IBM as well) for this particular scenario, but from what I've read, I should still be able to use SDSF w/o the servers running. Anybody out there have any good ideas short of converting?
Thanks in advance.
Curt.
----------------------------------------------------------------------
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
Dunlap, Curtis L
2018-10-09 18:02:57 UTC
Reply
Permalink
Thanks, but I've checked with our ACF2 admin and he says SDSF class is not activated.

Curt


________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Matt Hogstrom <***@HOGSTROM.ORG>
Sent: Tuesday, October 9, 2018 12:41:33 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.

If its the same problem I had you have to make the SDSF class Raclistable.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.e0zm100%2FRACF_SDSF_RACLIST_V2R3.htm&amp;data=02%7C01%7Ccvd5215%40psu.edu%7Cda65b2162df147bfd81b08d62e061953%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636747001061519191&amp;sdata=2quGdN73OfTEDoV19It4aVdP6eLytIl%2BN2UC6WGlH5g%3D&amp;reserved=0

Matt Hogstrom
***@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270

I just read a book on Stockholm Syndrome,
it was pretty bad at first, but, by the end I kind of liked it.
Post by Dunlap, Curtis L
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-)
ISF452E SDSFAUX communications failed, return code 0x00000008,
reason code 0x00370801, function "connect". SDSFAUX not available
or function not supported
I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers to expedite the OS upgrade and am now receiving this message when SDSF is executed from TSO, ISPF or batch. I've struck out doing searches on the webernets (and IBM as well) for this particular scenario, but from what I've read, I should still be able to use SDSF w/o the servers running. Anybody out there have any good ideas short of converting?
Thanks in advance.
Curt.
----------------------------------------------------------------------
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Matthew Stitt
2018-10-09 20:08:07 UTC
Reply
Permalink
Find the SDSFAUX sample JCL and copy it to your system PROCLIB. Create a user id and started task profile for it in your security product.

SDSF will automatically start the new address space when it starts.

Everything should be happy.

That's all I remember I had to do when I started playing with z/OS V2R3.
Post by Dunlap, Curtis L
Thanks, but I've checked with our ACF2 admin and he says SDSF class is not activated.
Curt
________________________________
Sent: Tuesday, October 9, 2018 12:41:33 PM
Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
If its the same problem I had you have to make the SDSF class Raclistable.
Matt Hogstrom
+1-919-656-0564
PGP Key: 0x90ECB270
Post by Dunlap, Curtis L
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-)
ISF452E SDSFAUX communications failed, return code 0x00000008,
reason code 0x00370801, function "connect". SDSFAUX not available
or function not supported
I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF* servers to expedite the OS upgrade and am now receiving this message when SDSF is executed from TSO, ISPF or batch. I've struck out doing searches on the webernets (and IBM as well) for this particular scenario, but from what I've read, I should still be able to use SDSF w/o the servers running. Anybody out there have any good ideas short of converting?
Thanks in advance.
Curt.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Shashi Kumar
2018-10-09 20:15:33 UTC
Reply
Permalink
Hello,

Adding this, you need to connect the sdsfaux on to sdsf proc. And get the
required RACF or security access to it. Thanks
Post by Matthew Stitt
Find the SDSFAUX sample JCL and copy it to your system PROCLIB. Create a
user id and started task profile for it in your security product.
SDSF will automatically start the new address space when it starts.
Everything should be happy.
That's all I remember I had to do when I started playing with z/OS V2R3.
Post by Dunlap, Curtis L
Thanks, but I've checked with our ACF2 admin and he says SDSF class is
not activated.
Post by Dunlap, Curtis L
Curt
________________________________
Sent: Tuesday, October 9, 2018 12:41:33 PM
Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
If its the same problem I had you have to make the SDSF class Raclistable.
Matt Hogstrom
+1-919-656-0564
PGP Key: 0x90ECB270
Post by Dunlap, Curtis L
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-)
I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message
ISF452E SDSFAUX communications failed, return code 0x00000008,
reason code 0x00370801, function "connect". SDSFAUX not available
or function not supported
I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF*
servers to expedite the OS upgrade and am now receiving this message when
SDSF is executed from TSO, ISPF or batch. I've struck out doing searches
on the webernets (and IBM as well) for this particular scenario, but from
what I've read, I should still be able to use SDSF w/o the servers
running. Anybody out there have any good ideas short of converting?
Post by Dunlap, Curtis L
Post by Dunlap, Curtis L
Thanks in advance.
Curt.
----------------------------------------------------------------------
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
Dunlap, Curtis L
2018-10-10 10:36:34 UTC
Reply
Permalink
Thanks Shashi, but the assembled ISFPARMS table does not use the SDSF address spaces and in fact are documented to be used as a backup in the event that the SDSF address spaces are not available.

________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Shashi Kumar <***@GMAIL.COM>
Sent: Tuesday, October 9, 2018 4:15:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.

Hello,

Adding this, you need to connect the sdsfaux on to sdsf proc. And get the
required RACF or security access to it. Thanks
Post by Matthew Stitt
Find the SDSFAUX sample JCL and copy it to your system PROCLIB. Create a
user id and started task profile for it in your security product.
SDSF will automatically start the new address space when it starts.
Everything should be happy.
That's all I remember I had to do when I started playing with z/OS V2R3.
Post by Dunlap, Curtis L
Thanks, but I've checked with our ACF2 admin and he says SDSF class is
not activated.
Post by Dunlap, Curtis L
Curt
________________________________
Sent: Tuesday, October 9, 2018 12:41:33 PM
Subject: Re: ISF452E on SDSF using MACRO ISFPARMS only on z/OS V2.3.
If its the same problem I had you have to make the SDSF class Raclistable.
Matt Hogstrom
+1-919-656-0564
PGP Key: 0x90ECB270
Post by Dunlap, Curtis L
Hi IBM-MAIN Mainframers! Long time listener, first time caller. :-)
I'm upgrading from z/OS V2.1 to V2.3 and I'm receiving this message
ISF452E SDSFAUX communications failed, return code 0x00000008,
reason code 0x00370801, function "connect". SDSFAUX not available
or function not supported
I tried to implement SDSF with the ISFPARMS USERMOD table w/o SDSF*
servers to expedite the OS upgrade and am now receiving this message when
SDSF is executed from TSO, ISPF or batch. I've struck out doing searches
on the webernets (and IBM as well) for this particular scenario, but from
what I've read, I should still be able to use SDSF w/o the servers
running. Anybody out there have any good ideas short of converting?
Post by Dunlap, Curtis L
Post by Dunlap, Curtis L
Thanks in advance.
Curt.
----------------------------------------------------------------------
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-10-10 12:09:50 UTC
Reply
Permalink
Post by Dunlap, Curtis L
Thanks, but I've checked with our ACF2 admin and he says SDSF class is not activated.
Did you read the append from Rob Scott yesterday on a related thread?
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian France
2018-10-10 12:37:01 UTC
Reply
Permalink
Howdy Tom,

     Yes we did. That was my thread as we both posted thinking the
other wasn't. According to ACF2 doc and from what I see by dumping my
ACF2 logs calls are NOT being made to SERVER.NOPARM as ACF2 ignores them
by default. I even coded a SERVER.NOPARM rule to allow us access in case
I was missing something. And according to their doc they state the same
in that IF the call is ignored the fallback is to ISFPARMS data set. We
really don't want to go thru the whole SAF/ACF2 setup. I'm hoping
*MAYBE* we can just implement SDSF/SDSFAUX with the ISFPRMxx member
after we try the convert of our current ISFPARMS. Might be able to
activate in ACF2 just the SDSF piece and not the commands and such. Tho
having this work as documented would be nice.
Post by Tom Marchant
Post by Dunlap, Curtis L
Thanks, but I've checked with our ACF2 admin and he says SDSF class is not activated.
Did you read the append from Rob Scott yesterday on a related thread?
--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
***@psu.edu

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-10-10 12:52:24 UTC
Reply
Permalink
Post by Brian France
Yes we did. That was my thread as we both posted thinking the
other wasn't. According to ACF2 doc and from what I see by dumping my
ACF2 logs calls are NOT being made to SERVER.NOPARM as ACF2 ignores them
by default. I even coded a SERVER.NOPARM rule to allow us access in case
I was missing something. And according to their doc they state the same
in that IF the call is ignored the fallback is to ISFPARMS data set.
According to the ACF2 doc? Or the SDSF doc?
Post by Brian France
We
really don't want to go thru the whole SAF/ACF2 setup.
All I know about this is what I saw in Rob's post.
"The user must have READ access to the SERVER.NOPARM resource in the
SDSF class so that ISFPARMS can be used instead of ISFPRMxx."
That sounds pretty clear to me. I read "must" as a requirement.
Post by Brian France
I'm hoping
*MAYBE* we can just implement SDSF/SDSFAUX with the ISFPRMxx member
after we try the convert of our current ISFPARMS.
"To connect to the SDSF server, the user must have READ access to the
ISF.CONNECT.system resource in the SDSF class."
There is another pesky "must".
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian France
2018-10-10 13:07:52 UTC
Reply
Permalink
Post by Tom Marchant
Post by Brian France
Yes we did. That was my thread as we both posted thinking the
other wasn't. According to ACF2 doc and from what I see by dumping my
ACF2 logs calls are NOT being made to SERVER.NOPARM as ACF2 ignores them
by default. I even coded a SERVER.NOPARM rule to allow us access in case
I was missing something. And according to their doc they state the same
in that IF the call is ignored the fallback is to ISFPARMS data set.
According to the ACF2 doc? Or the SDSF doc?
           The ACF2 doc. So really both the SDSF doc AND the ACF2 doc
seem to indicate that IF no SDSF address space then fallback to ISFPARMS
data set.
Post by Tom Marchant
Post by Brian France
We
really don't want to go thru the whole SAF/ACF2 setup.
All I know about this is what I saw in Rob's post.
"The user must have READ access to the SERVER.NOPARM resource in the
SDSF class so that ISFPARMS can be used instead of ISFPRMxx."
That sounds pretty clear to me. I read "must" as a requirement.
    I agree. So possibly I do need to try to make that call active in
ACF2 land even tho their doc states not needed.
Post by Tom Marchant
Post by Brian France
I'm hoping
*MAYBE* we can just implement SDSF/SDSFAUX with the ISFPRMxx member
after we try the convert of our current ISFPARMS.
"To connect to the SDSF server, the user must have READ access to the
ISF.CONNECT.system resource in the SDSF class."
There is another pesky "must".
             Ya I saw that. Wonder how many more "pesky musts" will
rear their head. LOL...
--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
***@psu.edu

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian France
2018-10-11 18:03:25 UTC
Reply
Permalink
Update - We converted from ISFPARMS to ISFPRMxx.  SDSF and SDSFAUX
address spaces running. Message isf452e of course is no longer appearing
upon entry into sdsf. Well at least that version of it. There are quite
a few new commands that wont function. So we now get a version of
isf452e but with and 0806, query apf not authorized.

It's our opinion that if one was to remain with ISFPARMS then one would
have to live with the message. SDSF will work with the commands like
init, log, etc it's just that every initial entry into sdsf would
present that message of SDSFAUX not running cause indeed it's not.


Thanx all!!!!
Post by Brian France
Post by Tom Marchant
Post by Brian France
Yes we did. That was my thread as we both posted thinking the
other wasn't. According to ACF2 doc and from what I see by dumping my
ACF2 logs calls are NOT being made to SERVER.NOPARM as ACF2 ignores them
by default. I even coded a SERVER.NOPARM rule to allow us access in case
I was missing something. And according to their doc they state the same
in that IF the call is ignored the fallback is to ISFPARMS data set.
According to the ACF2 doc? Or the SDSF doc?
           The ACF2 doc. So really both the SDSF doc AND the ACF2 doc
seem to indicate that IF no SDSF address space then fallback to
ISFPARMS data set.
Post by Tom Marchant
Post by Brian France
We
really don't want to go thru the whole SAF/ACF2 setup.
All I know about this is what I saw in Rob's post.
"The user must have READ access to the SERVER.NOPARM resource in the
SDSF class so that ISFPARMS can be used instead of ISFPRMxx."
That sounds pretty clear to me. I read "must" as a requirement.
    I agree. So possibly I do need to try to make that call active in
ACF2 land even tho their doc states not needed.
Post by Tom Marchant
Post by Brian France
I'm hoping
*MAYBE* we can just implement SDSF/SDSFAUX with the ISFPRMxx member
after we try the convert of our current ISFPARMS.
"To connect to the SDSF server, the user must have READ access to the
ISF.CONNECT.system resource in the SDSF class."
There is another pesky "must".
             Ya I saw that. Wonder how many more "pesky musts" will
rear their head. LOL...
--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
***@psu.edu

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...