Exclusive ENQ on complete MVS Library for transfer of one member

A discussion of Co:Z sftp, a port of OpenSSH sftp for z/OS
Post Reply
Bernhard
Posts: 13
Joined: Thu Jun 14, 2018 6:32 am

Exclusive ENQ on complete MVS Library for transfer of one member

Post by Bernhard » Thu Nov 28, 2019 4:32 am

Hello,

if the Co:Z SFTP client transfers data to a member of a library, it allocates the whole library with DISP=OLD:

ZosDataset: Opening dataset userid.MAIN.JCL(TEST8) for write with options: old
...

If anyone is browsing a member or displaying the member list in this library (having a shared ENQ), SFTP therefore terminates with a BPXWDYN message:

BPXWDYN allocation failed S99ERROR=0x0210 S99INFO=0x0000
BPXWDYN command was: "alloc fi(SYS00019) reuse msg(2) da('userid.MAIN.JCL(TEST8)') old"
...

saying it is not able to exclusive ENQ the dataset.

Because z/OS handles correctly writing to a member with only a shared ENQ in all other environments, in my opinion the allocation in SFTP should also be changed to DISP=SHR for MVS libraries in order to avoid unnecessary SFTP crashes.

dovetail
Site Admin
Posts: 1913
Joined: Thu Jul 29, 2004 12:12 pm

Re: Exclusive ENQ on complete MVS Library for transfer of one member

Post by dovetail » Fri Nov 29, 2019 3:08 pm

You are correct - when writing to PDS members, the DSN(MEMBER) is allocated with DISP=OLD by CO:Z SFTP.

We agree with your suggestion that we should enhance the product allow for DISP=SHR along with a ISPF-style enqueue using QNAME=SPFEDIT for both member and dsn integrity (see ISPF Planning and Customization for details). We already plan to do this in a future release.

Note: this is not really a "z/OS" feature, but it is something that ISPF does, and many other products simulate for compatibility. For example, if you write to a dataset(member) using JCL and IEBGENER, you will not have integrity without DISP=OLD.

Bernhard
Posts: 13
Joined: Thu Jun 14, 2018 6:32 am

Re: Exclusive ENQ on complete MVS Library for transfer of one member

Post by Bernhard » Tue Dec 03, 2019 10:53 am

Glad to hear that you are planning to change the behaviour.

Of course it might be an integrity issue if a SPFEDIT ENQ ist ignored, but for my purposes it would be enough if you make only a SHR ENQ on the DSName instead of a separate ENQ at member level - quite as z/OS does.

dovetail
Site Admin
Posts: 1913
Joined: Thu Jul 29, 2004 12:12 pm

Re: Exclusive ENQ on complete MVS Library for transfer of one member

Post by dovetail » Tue Dec 03, 2019 11:32 am

If you really want to bypass integrity (and risk clobbering your PDS), you can allocate an output PDS member with disp=shr two different ways:

1) Do this:

lzopts mode=text
lzopts disp=shr
get /remote/file //my.pds(mem)

2) Allocate the DSN(MEMBER) with a DD in your job with DISP=SHR, then you can do this in your batch job:

lzopts mode=text
get /remote/file //DD:MYDD

Bernhard
Posts: 13
Joined: Thu Jun 14, 2018 6:32 am

Re: Exclusive ENQ on complete MVS Library for transfer of one member

Post by Bernhard » Wed Dec 04, 2019 10:13 am

Oh, thanks,

that's really easy - and it works!

Post Reply