Yes, the 213-13 abend is the solution, if you try to open a DCB for output when there is already an output DCB open for a PDS, it will cause the abend. I cannot see how corruption can occur if you can't have two DCBs open for output at the same time. The ENQ is only to avoid getting the abend.
>>> "Thompson, Steve" <steve_thomp...@stercomm.com> 12/7/2009 11:30 AM >>> -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, December 07, 2009 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IEC143I 213-30 On Mon, 7 Dec 2009 09:53:26 -0500, Scott Rowe wrote: >I don't believe that's true, Gil. It doesn't make sense given the changes that were made to the logic, and I can't create it here. Do you have a test case that shows this? > I believe SPFEDIT mostly protects you. To show the problem you'd need to have: o DSNTYPE=PDS o DISP=SHR o Update by a process other than ISPF EDIT, and which doesn't respect the SPFEDIT ENQ. I'll grant this is unlikely; I'd prefer not to try to create it. Perhaps Ted is thinking of something in addition. <SNIP> I've not been following this thread closely. But it seems that about this time last year I started dealing with a related issue. So if this is not germane to your discussions, just ignore it. Meanwhile, I had found an ABEND that happens when two tasks are trying to do STOW at the same time. In my situation, this was a race (or timing dependant) condition and it could be done within a single LPAR between two address spaces (and I think I was even able to get it within the same address space). I did this under z/OS V1R9. Since we did things to prevent it, I would have to break the code to recreate under z/OS V1R10/11. During design, we concluded that we had to use the "ISPF EDIT ENQUEUE". But during testing we found that if you are doing a STOW for member "X" while another task is attempting member "Y" at the same time, the "ISPF EDIT ENQUEUE" does not protect the directory from a simultaneous update situation, only from two tasks using the same member. In order to prevent this ABEND situation, we decided to use an ENQUEUE for the directory updates. The ENQUEUE actually protects from the problem within one address space or across two -- and only between uses of the product (which is still underdevelopment) since the ENQUEUE we came up with is "private". The STOW situation I ran into did not require a member write, only that you wish to update the directory entry. In my case, attempting to add the "ISPF" stats caused the ABEND. And because of race (or timing as you prefer) conditions I was getting two STOWs being done at the same time to the same directory. The system detected this and the arbitrary second updater got the ABEND. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html