It seems the symptoms have led me to draw wrong conclusions. The fact that ISPF reports the PDSE *in use* the moment I stepped over remove() in the debugger led me to believe that remove() was causing the PDSE to be locked and the following fopen() to fail. But some experimentation shows that it at this point I skip the remove() altogether, the fopen() still fails. So maybe remove() just upgraded a shared-read lock (ENQ?) to an exclusive lock (EXC?) and the real problem is the presence of this shared-read lock. So by way of experiment I placed a remove() plus fopen() at the start of the program, and lo, the fopen does not fail! So I think I must conclude that remove() is not causing this lock, but something else. So I will now place remove() + fopen() pairs along the execution path in my code, until the point where fopen starts failing. Between the last successful fopen and the first unsuccessful one, there I should (hopefully) find the cause...
Thanks for thinking with me about this problem, I have learned a lot about ENQ's and latches now :-) Etienne ---------------------------------------------------------------------- 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
