On 05/21/2010 11:59 AM, Edward Jaffe wrote: > Hunkeler Peter (KIUP 4) wrote: >> Ed: How happy would you be if your automated ftp process successfully >> replaces the member someone else is editing at >> the same time. A single SAVE and your successfull ftp isn't >> worth a dime anymore. >> > > That is a different scenario entirely. My situation is not a remote PUT. > Rather, my situation is a remote GET that fails simply because someone, > perhaps even someone without UPDATE/SAVE access to the library, decided > to bring the member up under ISPF EDIT. > > Unless I'm missing something, it seems like any "Joe Blow" goofing > around and/or with malicious intent can exploit this behavior to "break" > any process involving remote FTP GET. >
So how is MVS supposed to distinguish between an instance of someone who shouldn't be editing the data or has no intention of saving vs. someone who is editing critical changes that must be saved before the next remote GET should be allowed to proceed to avoid sending the remote user erroneous data? If it is more important that the GET have minimal possibility of failure than to get the absolutely latest update, the best option may be to make a mirror copy of the data at an agreed on point in time into a dataset with restricted READ access and use that for the actual FTP transfer. -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- 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
