-----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
