On Mon, 7 Apr 2014 07:49:32 -0500, John McKown wrote: >On Sat, Apr 5, 2014 at 8:34 AM, Paul Gilmartin wrote: > >> On Fri, 4 Apr 2014 20:11:59 +0000, Chase, John wrote: >> > >> Sometimes source of similar problems: the C RTL updating a PDS >> member obtains ENQ EXC SYSDSN. C programs are pretty commonplace >> now; someone ought to submit a Requirement that the C RTL should >> use ISPF-style ENQs on PDS members, at least optionallly. > >Definitely optionally. What to do if the ENQ fails becomes a question as >well. Fail the fopen() with some sort of "in use" (EBUSY?) return? Do a >wait? If wait, then how long? Unlimited (well, an S522 is likely in this >case)? User specified? Hum, now we need to change the parameters to fopen() >or come up with a new fopen() function. How does this affect portability? > I believe that NFS server uses the same ENQ as ISPF. I can get on my Solaris terminal:
143$ { ( set -x; date; sleep 22; date ) 2>&1; } >foo ksh: foo: cannot create I think this is EPERM. >> More wishful: JCL should support a new DISP keyword to select ISPF-style >> ENQs on PDS members so any program could benefit from the facility >> with no code changes needed. >> > >My personal opinion is that the advantage of this is not worth the cost to >implement. And there are more questions. Is this a SHARED or EXCLUSIVE >enqueue? Oh, that would be the DISP-equivalent, I guess. Hum, when is the >ENQ issued? At start of job, like for SYSDSN, or at start of STEP? If this >is an exclusive ENQ, should there be two ENQs; one for the entire DSN & one >for the DSN+MEMBER? The DSN-only is what ISPF uses before it does a SAVE. >This is to serialize writing into a PDS (which is not needed for a PDSE) to >avoid "member data interleaving". > Is that SYSDSN? If so, that would upgrade any existing SHR ENQ to EXC. If on z/OS 2.1, will ISPF downgrade that ENQ to SHR afterward? With other tests, I get: MIM1038I Prefix contention with MVSNFS OWNS EXCL on MVS CN(INTERNAL) MIM1039I Prefix needs EXCL SPFEDIT Prefix.CLIST(FOO) CN(INTERNAL) *** And even (gasp!): ◊—————————————————————————————————————————————————————————————————————————————◊ ◊ A RESERVE has been issued for a volume for which a RESERVE has already been ◊ ◊ issued. Please wait a few seconds and retry. ◊ ◊—————————————————————————————————————————————————————————————————————————————◊ Does updating a PDS with a batch job with DISP=SHR while ISPF SAVEs a different member risk "member data interleaving"? (Doctor, it hurts when I do that.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN