In a recent note, Kenneth E Tomiak said:
> Date: Sat, 5 May 2007 08:57:16 -0500
>
> The scarier part is someone suggested how to update an exclusively held
> member. The answer is, if you want to introduce data integrity problems to
> your system, please do not ask us for help. There is no good reason to try to
> get or put a member that is in use. z/OS 1.8 Communication Server comes
> with a REXX API to FTP. If you are using a dumb, or blind, script to transfer
> a
> file then you should upgrade and write some intelligent code to attempt the
> transfer, when you get the error that it is held, let logic dictate how long
> your
> code waits before trying again or giving up. A better design would have you
> figuring out who is editing a member you need to transfer. Something is wrong
> with your design.
>
I disagree.
> >You do realize that you are asking how to bypass data integrity
> >mechanismes? In other words, you might be able to read the member, but
> >it could be in half-updated/corrupted status.
>
Can we not assume that ISPF knows what it's doing? That it is competent
and prudent; that it will not allow me to read a member that is in
"half-updated/corrupted status"?
If I edit a PDS member in an ISPF session, then concurrently Browse or
View it from another session, the operation succeeds. This can't show
me a member in such an unfinished status unless ISPF edit performs
update-in-place. Does ISPF do this? Another contributor will likely
supply the answer; I don't know.
However, if I attempt to Edit the member from another session, I get:
MIM1088 CONTENTION WITH user OWNS EXCL ON LSTCYMVS
MIM1089 YOU NEED EXCL SPFEDIT data.set.name(TESTMEMB)
***
Obviously, we have MIM. Would GRS not do the same?
However, if I try to access the member with FTP, I get
ftp> get testmemb |cat
200 Port request OK.
550 data.set.name(TESTMEMB) used exclusively by someone else.
Is FTP exercising wise caution here, or is this a misunderstanding by the
TCP/IP designers? I suspect the latter.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
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
