On Thu, 20 May 2010 11:50:43 -0500, McKown, John wrote:
>> -----Original Message-----
>> [mailto:[email protected]] On Behalf Of Edward Jaffe
>>
>> Did you know that z/OS ftp GET is blocked by ISPF EDIT? =-O
>>
>> This is a little scary since we use ftp all over the place in our
>> automated processes!
>>
>> ftp> get istinclm istinclm.jcltxt
>> 125-FTP Server unable to obtain SHARED use of
>> SYS2.MVSMODS.CNTL(ISTINCLM) which
>> is held by: 008F EDJXADM EXCL on SPFEDIT
>
I don't know that I feel too bad about this. I can rationalize it
as due prudence. Suppose:
ISPF user does:
EDIT; change a few lines; SAVE
FTP user attempts:
GET, but member is in an invalid state.
ISPF user does:
Change some more lines; END
(Only now is content of member valid.)
This is safe only if ISPF user never SAVEs until all changes are made,
and FTP server has no way to determine this.
>Yeap, I've run into that a number of time. Editting a JCL member, do a SAVE,
>then want to ftp it to my desktop. the ftp fails.
>
The behavior is the same even before the SAVE, by experiment. Would
anyone care to submit a Requirement that ISPF defer requesting the
EXCL SPFEDIT until the first SAVE? Would this still preserve
integrity? What if there's a SHR ENQ outstanding from another job?
z/OS NFS server apparently does EXCL SPFEDIT ENQ on write; no ENQ
that I can detect on read. Is this better?
Could it be made better for PDSE members, since they have a sort of
LUW encapsulation?
And, truly annoying:
/bin/cp /what/ever "//'SYS2.MVSMODS.CNTL(ISTINCLM)'"
requests EXCL SYSDSN ENQ. I think this misspecification is
inherent in the C RTL.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
