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