On Tue, 27 Jul 2010 08:47:30 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:
>On Tue, 27 Jul 2010 19:02:19 +0800, David Crayford wrote: > >>Etienne Thijsse wrote: >>> >>> Thanks for responding, Gil. There is no other stream. When I run under the >>> debugger, the PDSE remains accessible with ISPF right up to the remove() >>> statement; when I step over it, it is locked. >>> >It's yet possible that there's an outstanding ENQ SHR due ta another >stream, or even an allocation in another job step. remove() upgrades >this to EXC (bad design of C RTL; as you say, SAS (RIP) does better). >Then there's no way to downgrade it to SHR (bad design of GRS). > >(BTW, what happens if you attempt the remove() while a different job >holds ENQ SHR on the DSN?) > >>What is a real shame is that ISPF LMM services were not built on top of >>a services layer. In the 21st century the last >>thing a programmer wants to do is hack about with assembler macros. >>SAS/C has a nice BSAM low-level layer >>which has an osstow() function which is just what we need on z/OS. >>Unfortunately, it's time to RYO. >> >I thougnt ISPF services were available from Rexx "address ISPEXEC" >and various other languages via CALL. > That may well be true. At this moment however, I know nothing about ISPF services or how to call them from C. I'll keep this in mind as a lost resort, if all else fails. At the moment I am contemplating creating a separate executable, DELMBR, that will use remove() to delete it, thereby locking the PDSE, but when it finishes, the PDSE is unlocked. If I use system() to call this program then maybe the PDSE won't be locked when DELMBR finishes and fopen() succeeds... hopefully. Thanks, Etienne ---------------------------------------------------------------------- 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
