Re: ICH13005I
John Eells wrote: >Whether it's a bug or a doc error vs. a feature depends on exactly what >weirdness you saw and whether it's expectedly or unexpectedly weird. That's a >question for Level 2 or RACF-L. But as I understand it, some of the weird >things derive from commands against a class that shares a POSIT with another >being implicitly (and, I am told, intentionally) driven against both classes. >Sometimes the command does not apply to the second class, and apparent errors >ensue. >Much or all of this is documented in the RACF SAG. My simple-minded approach >to life since learning about this not too long ago is to *never* share a POSIT >value. Well, yeah, "Don't share a POSIT" is wise. But when there's no easy way to see what POSITs are in use, that's a semi-weak suggestion, I'm afraid. LISTCDT works, but telling a customer who is having a problem that they need to download and run a program from a website (even from IBM) doesn't go over very well. They have to get there (firewalls), download the XMITBIN, upload that as binary correctly, RECEIVE it, copy or upload the JCL, tailor it...by that time they're pretty irritated, and I don't blame them! Why isn't LISTCDT part of the product? It's clearly needed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
Smith III, Phil , HPE Data Security Voltage wrote: John Eells wrote: OK, not related to the problem for which we took the APARs. Was the POSIT shared with another class? Weird Things Happen when you do that. That was my guess, and what led me to suggest they change it. But I don't know. Still seems like a bug, or at least a doc error, no? Whether it's a bug or a doc error vs. a feature depends on exactly what weirdness you saw and whether it's expectedly or unexpectedly weird. That's a question for Level 2 or RACF-L. But as I understand it, some of the weird things derive from commands against a class that shares a POSIT with another being implicitly (and, I am told, intentionally) driven against both classes. Sometimes the command does not apply to the second class, and apparent errors ensue. Much or all of this is documented in the RACF SAG. My simple-minded approach to life since learning about this not too long ago is to *never* share a POSIT value. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
Tom Conley wrote: John, There's no way to know without tearing apart ICHCRCDE. RACF, in its infinite wisdom, provides no report showing POSIT. If it's a Dynamic CDT entry, RLIST CDT name CDTINFO will show POSIT: CDTINFO INFORMATION --- CASE = UPPER DEFAULTRC = 004 DEFAULTUACC = NONE FIRST = ALPHA NUMERIC GENLIST = DISALLOWED GENERIC = ALLOWED GROUP = KEYQUALIFIERS = 00 MACPROCESSING = NORMAL MAXLENGTH = 008 MAXLENX = NONE MEMBER = OPERATIONS = NO OTHER = ALPHA NATIONAL NUMERIC SPECIAL POSIT = 000250 PROFILESALLOWED = YES RACLIST = REQUIRED SECLABELSREQUIRED = NO SIGNAL = NO A POSIT of 19 is outside the IBM range, so I assumed (perhaps incorrectly) that they used a Dynamic CDT entry. I would expect one could SR NOMASK CLASS(CDT) and then look at the likely suspects, though that could be a bit tedious if there are a lot of them if done manually. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
Have you checked out the LISTCDT utility - https://www-03.ibm.com/systems/z/os/zos/features/racf/downloads/listcdt.html Haven't run it for sometime but I am sure the report it produces lists off the POSIT values Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
On 8/23/2017 7:10 PM, John Eells wrote: Smith III, Phil , HPE Data Security Voltage wrote: John Eells wrote: Phil, there are plenty of people left on the RACF team in POK to read whatever you send in. Good. But may I ask what the POSIT was? There could be a relevant APAR or two. 019. P.S. Lizette, thanks - I meant to post to RACF-L as well originally, forgot! Have done so now. OK, not related to the problem for which we took the APARs. Was the POSIT shared with another class? Weird Things Happen when you do that. John, There's no way to know without tearing apart ICHCRCDE. RACF, in its infinite wisdom, provides no report showing POSIT. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
John Eells wrote: >OK, not related to the problem for which we took the APARs. >Was the POSIT shared with another class? Weird Things Happen when you do that. That was my guess, and what led me to suggest they change it. But I don't know. Still seems like a bug, or at least a doc error, no? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
Smith III, Phil , HPE Data Security Voltage wrote: John Eells wrote: Phil, there are plenty of people left on the RACF team in POK to read whatever you send in. Good. But may I ask what the POSIT was? There could be a relevant APAR or two. 019. P.S. Lizette, thanks - I meant to post to RACF-L as well originally, forgot! Have done so now. OK, not related to the problem for which we took the APARs. Was the POSIT shared with another class? Weird Things Happen when you do that. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
John Eells wrote: >Phil, there are plenty of people left on the RACF team in POK to read whatever >you send in. Good. >But may I ask what the POSIT was? There could be a relevant APAR or two. 019. P.S. Lizette, thanks - I meant to post to RACF-L as well originally, forgot! Have done so now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
Smith III, Phil , HPE Data Security Voltage wrote: A customer was getting: ICH13005I RESGROUP DOES NOT APPLY TO CDT CLASS ENTITIES; OPERAND IGNORED on an RDEFINE command. Some tinkering and a SWAG led me to ask him to change the POSIT, and the problem went away. Googling ICH13005I gets a grand total of 13 hits, none of them very helpful. The doc all says this message is supposed to come from an RLIST, not an RDEFINE. Besides being a typically opaque RACF error message, am I missing something obvious, or is this just wrong? I'd RCF it but I doubt there's anybody left in POK to read it... Phil, there are plenty of people left on the RACF team in POK to read whatever you send in. But may I ask what the POSIT was? There could be a relevant APAR or two. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICH13005I
If you were not aware, there is a RACF list that may be able to help To join, if you have not done so, Use this URL RACFhttp://www.listserv.uga.edu/archives/racf-l.html Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Smith III, Phil (HPE Data Security (Voltage)) > Sent: Tuesday, August 22, 2017 11:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ICH13005I > > A customer was getting: > ICH13005I RESGROUP DOES NOT APPLY TO CDT CLASS ENTITIES; OPERAND IGNORED on > an RDEFINE command. Some tinkering and a SWAG led me to ask him to change the > POSIT, and the problem went away. > > Googling ICH13005I gets a grand total of 13 hits, none of them very helpful. > The doc all says this message is supposed to come from an RLIST, not an > RDEFINE. Besides being a typically opaque RACF error message, am I missing > something obvious, or is this just wrong? I'd RCF it but I doubt there's > anybody left in POK to read it... > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
ICH13005I
A customer was getting: ICH13005I RESGROUP DOES NOT APPLY TO CDT CLASS ENTITIES; OPERAND IGNORED on an RDEFINE command. Some tinkering and a SWAG led me to ask him to change the POSIT, and the problem went away. Googling ICH13005I gets a grand total of 13 hits, none of them very helpful. The doc all says this message is supposed to come from an RLIST, not an RDEFINE. Besides being a typically opaque RACF error message, am I missing something obvious, or is this just wrong? I'd RCF it but I doubt there's anybody left in POK to read it... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
