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.
Exclusive ENQ on complete MVS Library for transfer of one member
Re: Exclusive ENQ on complete MVS Library for transfer of one member
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.
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.
Re: Exclusive ENQ on complete MVS Library for transfer of one member
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.
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.
Re: Exclusive ENQ on complete MVS Library for transfer of one member
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
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
Re: Exclusive ENQ on complete MVS Library for transfer of one member
Oh, thanks,
that's really easy - and it works!
that's really easy - and it works!