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 [email protected] with the message: INFO IBM-MAIN
