Re: OT - z/OS and ACF2 - OMVS id cancelled due to max violations
Given the name of the dataset, check in ACF2 for any generic protection type rules: NODE1.* or NOD* type rules. There may be no specific rule for the dataset, but some portion of the name may have been caught under a generic rule. Was it defined on a volume or group of volumes that is used by USS? -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ranga Nathan Sent: Tuesday, March 15, 2005 11:42 PM To: LINUX-390@VM.MARIST.EDU Subject: OT - z/OS and ACF2 - OMVS id cancelled due to max violations Though this is a z/VM mailing list, I hope someone will be able to shed some light on this bizarre problem that I have difficulty explaining. We defined a dataset that I think (!) we perhaps created as a HFS dataset. We did not do anything else (no read or update) with it. We had not set up any ACF2 rules for it. But somehow we are getting ACF2 violations on accesses from USS. When the violations exceeded the limit, USS id was cancelled by ACF2 causing all TCP/IP and USS dependent tasks to abend. We had to re-IPL the LPAR. We had to delete the dataset before re-IPLing for fear of another incident! I am guessing that because we set it up as a HFS (unintentionally), any access by backup jobs or via ISPF was considered as coming from USS. Since the ACF2 rules were not set up, it caused violations and the consequent results. We do not remember if we set it up as a normal or HFS dataset. That evidence is gone. But my theory is that it was set up as HFS with no ACF2 rules and any access to it was considered as coming from USS. This is bizarre. We are splitting hair to find out why and how it happened. Any clues welcome :-) __ Ranga Nathan / CSG Systems Programmer - Specialist; Technical Services; BAX Global Inc. Irvine-California Tel: 714-442-7591 Fax: 714-442-2840 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: OT - z/OS and ACF2 - OMVS id cancelled due to max violations
In ACF2, for it to actually check HFS(USS) data sets for access rules, you have to turn some options on. It by default does not check those types of data sets. That being said, it will report the access under the Open Edition events section. That access is by the traditional Unix attributes that are on the data set. ie - rwxrwxrwx or what ever they may be. I didn't think those violations would count towards a LID being suspended. I'm ass/u/me/ing that it was TCPIP that had the problems by what you've said. One thing to know is that you can restart your OMVS(USS) system WITHOUT an IPL. F OMVS,SHUTDOWN and then a F OMVS,START should take care of that. That should in theory give you back TCP access. I forget what level of z/OS that became available but know that it was at z/OS 1.3 and up. If you want to talk offline since this is not the correct list, please contact me off list. At 11:42 PM 3/15/2005, you wrote: Though this is a z/VM mailing list, I hope someone will be able to shed some light on this bizarre problem that I have difficulty explaining. We defined a dataset that I think (!) we perhaps created as a HFS dataset. We did not do anything else (no read or update) with it. We had not set up any ACF2 rules for it. But somehow we are getting ACF2 violations on accesses from USS. When the violations exceeded the limit, USS id was cancelled by ACF2 causing all TCP/IP and USS dependent tasks to abend. We had to re-IPL the LPAR. We had to delete the dataset before re-IPLing for fear of another incident! I am guessing that because we set it up as a HFS (unintentionally), any access by backup jobs or via ISPF was considered as coming from USS. Since the ACF2 rules were not set up, it caused violations and the consequent results. We do not remember if we set it up as a normal or HFS dataset. That evidence is gone. But my theory is that it was set up as HFS with no ACF2 rules and any access to it was considered as coming from USS. This is bizarre. We are splitting hair to find out why and how it happened. Any clues welcome :-) __ Ranga Nathan / CSG Systems Programmer - Specialist; Technical Services; BAX Global Inc. Irvine-California Tel: 714-442-7591 Fax: 714-442-2840 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 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 [EMAIL PROTECTED] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
OT - z/OS and ACF2 - OMVS id cancelled due to max violations
Though this is a z/VM mailing list, I hope someone will be able to shed some light on this bizarre problem that I have difficulty explaining. We defined a dataset that I think (!) we perhaps created as a HFS dataset. We did not do anything else (no read or update) with it. We had not set up any ACF2 rules for it. But somehow we are getting ACF2 violations on accesses from USS. When the violations exceeded the limit, USS id was cancelled by ACF2 causing all TCP/IP and USS dependent tasks to abend. We had to re-IPL the LPAR. We had to delete the dataset before re-IPLing for fear of another incident! I am guessing that because we set it up as a HFS (unintentionally), any access by backup jobs or via ISPF was considered as coming from USS. Since the ACF2 rules were not set up, it caused violations and the consequent results. We do not remember if we set it up as a normal or HFS dataset. That evidence is gone. But my theory is that it was set up as HFS with no ACF2 rules and any access to it was considered as coming from USS. This is bizarre. We are splitting hair to find out why and how it happened. Any clues welcome :-) __ Ranga Nathan / CSG Systems Programmer - Specialist; Technical Services; BAX Global Inc. Irvine-California Tel: 714-442-7591 Fax: 714-442-2840 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
