Re: SDSF finally coughs up the ICH408I (sort of)
On 8/11/2005 8:41 AM, Thomas Conley wrote: Not really doable. Hundreds of automation execs broadcast commands throughout the system, and the client can't afford not to route the commands (minor things like varying tape drives offline and online, no big deal ;-) I would strongly suggest that you come up with a way to deal with the FRACINT abends so that you can support ACF2 to RACF conversions (that is in IBM's best interest, is it not?) Unfortunately, the processing of operator commands requires that -no- I/O take place during the authorization checking. If I/O can occur, then there are cases during error recovery where the authorization check will hang, leading to the command not functioning, which then leads to error recovery being impossible. Therefore, unless ACF2 could provide a complete ACEE, in the exact format that RACF uses, we cannot satisfy that requirement. And they cannot do that, due to the way they handle groups (for one) and due to the fact that RACF has some proprietary data in an ACEE extension that (a) we do not disclose to the other vendors and (b) they probably could not support/duplicate even if we told them the format. At one point we did do some experiments where we said, OK, so we can't do any I/O, but maybe we could take the ACEE that ACF2 sends us (or the UTOKEN that should also come across the interface) and build a phony ACEE without doing any I/O. It could have the user ID, and perhaps have the current connect group, but it would lack any of the user's other groups. Lacking the complete group list, some commands might fail (for example, if the administrator had used one of those alternate groups to grant authority via the permissions in an OPERCMDS profile) but this would avoid the abend, and perhaps the administrators would accept having to administer things differently for this case. Unfortunately, we discovered that the ACEE/UTOKEN we were receiving from ACF2 did not even have sufficient information to do that, so the experiment failed. And we are busy enough with other things that we have not continued experimenting. Thus, at this point (and for the foreseeable future) we have no solution for your problem. In a sysplex with a mix of security products, operator command security will fail, with an abend, if an ACF2 (or Top Secret, probably) system sends a command to a RACF system. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SDSF finally coughs up the ICH408I (sort of)
Walt, Thanks to Dennis Trojak and Tom Schmidt, I turned on the SDSF trace facility for 0080 SAF events and viola! I saw an OPERCMDS call for JES2.CANCEL.somethingorother. You may remember about 2 months ago that we had to disable OPERCMDS in order to prevent those unsightly 483 FRACINT abends for remote commands from ACF2. So we either get abends on remote commands or SDSF doesn't work. Heckuva choice Right now we're having fun trying to figure out how to modificate the ISFUSER exit to allow these to go through even if OPERCMDS is inactive. Do you have any better ideas? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF finally coughs up the ICH408I (sort of)
On Wed, 10 Aug 2005 15:02:33 -0400, Thomas Conley wrote: Thanks to Dennis Trojak and Tom Schmidt, I turned on the SDSF trace facility for 0080 SAF events and viola! I saw an OPERCMDS call for JES2.CANCEL.somethingorother. You may remember about 2 months ago that we had to disable OPERCMDS in order to prevent those unsightly 483 FRACINT abends for remote commands from ACF2. So we either get abends on remote commands or SDSF doesn't work. Heckuva choice Right now we're having fun trying to figure out how to modificate the ISFUSER exit to allow these to go through even if OPERCMDS is inactive. Do you have any better ideas? Tom, ACF2? Are you maybe running ACF2 and RACF (mixed) in a sysplex? There may be a zap you may apply to avoid the abends in that case. Then you can reenable OPERCMDS ... and maybe we can crack open a cold one at SCIDS in Boston? -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF finally coughs up the ICH408I (sort of)
- Original Message - From: Tom Schmidt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, August 10, 2005 3:15 PM Subject: Re: SDSF finally coughs up the ICH408I (sort of) On Wed, 10 Aug 2005 15:02:33 -0400, Thomas Conley wrote: Thanks to Dennis Trojak and Tom Schmidt, I turned on the SDSF trace facility for 0080 SAF events and viola! I saw an OPERCMDS call for JES2.CANCEL.somethingorother. You may remember about 2 months ago that we had to disable OPERCMDS in order to prevent those unsightly 483 FRACINT abends for remote commands from ACF2. So we either get abends on remote commands or SDSF doesn't work. Heckuva choice Right now we're having fun trying to figure out how to modificate the ISFUSER exit to allow these to go through even if OPERCMDS is inactive. Do you have any better ideas? Tom, ACF2? Are you maybe running ACF2 and RACF (mixed) in a sysplex? There may be a zap you may apply to avoid the abends in that case. Then you can reenable OPERCMDS ... and maybe we can crack open a cold one at SCIDS in Boston? Tom, If you missed my first post, I am doing an ACF2 to RACF conversion. We are mixed in the SYSPLEX, so turning off OPERCMDS in RACF was our only real option. Unfortunately, that makes SDSF non-functional, and I got 50 users saying, Why can't I purge my jobs, change INIT classes, change SRVCLASS?, etc. I've been trying to figure out why SDSF wasn't working for weeks here. We had some problems with their ISFUSER exit, but we fixed those and ran right into this OPERCMDS issue, which I've been working on for well over a week. It would have been so much @#$%^$# easier if SDSF had issued a message like OPERCMDS IS INACTIVE, YOU SCHMUCK, but I guess that's asking too much. The unsupported zap of which you speak is a non-starter here, unless IBM wants to step up to the plate. We're trying to figure out if we can code ISFUSER to let us slide on OPERCMDS if it's inactive. Ice it up, baby, I'm there. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF finally coughs up the ICH408I (sort of)
Why can't I purge my jobs, change INIT classes, change SRVCLASS? ... There's only one on that list I would allow. Purging my jobs. Who in their right mind allows users to do the latter? Your performance capacity people set up a config for a good reason! -teD In God we Trust! All others bring data! -- W. Edwards Deming -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF finally coughs up the ICH408I (sort of)
On 8/10/2005 3:02 PM, Thomas Conley wrote: Thanks to Dennis Trojak and Tom Schmidt, I turned on the SDSF trace facility for 0080 SAF events and viola! I saw an OPERCMDS call for JES2.CANCEL.somethingorother. You may remember about 2 months ago that we had to disable OPERCMDS in order to prevent those unsightly 483 FRACINT abends for remote commands from ACF2. So we either get abends on remote commands or SDSF doesn't work. Heckuva choice Right now we're having fun trying to figure out how to modificate the ISFUSER exit to allow these to go through even if OPERCMDS is inactive. Do you have any better ideas? I'm afraid my best suggestion is that you accept that you cannot route commands from an ACF2 system to a RACF system, revise your operational procedures so you don't do such routing, and reenable OPERCMDS on the RACF system. I will, though, wish you the best of luck in your attempt to get ISFUSER to work for you. I don't know enough about SDSF to offer any help there, but perhaps someone else on the list with more SDSF knowledge than I have will have some suggestions in that area. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
