I don't know whether ot has been considered by the folks who own the failing application or not. I will pass the suggestion to them.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Stracka, James (GTI) > Sent: Monday, December 31, 2007 7:39 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FTP Append > > Have you considered using CONNECT:Direct? > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Schuh, Richard > Sent: Friday, December 28, 2007 1:11 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FTP Append > > > Alan, > > > > > You mean your VM systems? > > I meant MVS systems. We only have VM at one location. TRACERTE is > disabled between the network where VM resides and the non-MVS systems at > the centers where the FTPs originate, so I substituted the MVS system > in the center in question. Not a perfect fit, but it is about the best > that I can do. I figured that, since it is a private network and was in > a period of low activity, it would be a good approximation of the > reverse of the route taken by the FTP. > > > > > For a minidisk, the APPEND request causes the FTP server to set the > file > > pointer to the end of the file. It doesn't actually "open" the file. > When > > the data connection is established, and the data arrives, the writes > are > > done starting at EOF. In theory, an error on the data connection > can't > > corrupt anything. It would be educational to know if the same problem > > > would occur if you used the SFS server instead of minidisk. > > > > > Actually, there is a third question: Which component(s) do I open > the > > PMR(s) > > > against? > > > > Open it against the FTP server; it's the only thing that touches the > > files. Right? You don't have MW minidisks or something else that > sneaks > > in and steals the minidisk from the FTP server? > > As stated originally, the target already is, and always has been, an SFS > directory, not a minidisk. Besides, you can only have null files in SFS. > We already have two components that touch the files. Thus the question, > "which component?" > > > > Alan Altmark > > z/VM Development > > IBM Endicott > > I am looking at changing things after our holiday season freeze is > lifted. I may update the FTP server to allow FTP to reader files and > have the client code revised, at least for the problem center, to send > the files to be appended to a service machine's reader queue. The > service machine could then do the append independently of the FTP > process. > > Another question, is there any time in the append process where, by > design, the record count appears to be zero for even the briefest of > periods? In other words, is there a window that has a crack in it? > > > Richard Schuh > -------------------------------------------------------- > > This message w/attachments (message) may be privileged, confidential or > proprietary, and if you are not an intended recipient, please notify the > sender, do not use or share it and delete it. Unless specifically > indicated, this message is not an offer to sell or a solicitation of any > investment products or other financial product or service, an official > confirmation of any transaction, or an official statement of Merrill > Lynch. Subject to applicable law, Merrill Lynch may monitor, review and > retain e-communications (EC) traveling through its networks/systems. The > laws of the country of each sender/recipient may impact the handling of > EC, and EC may be archived, supervised and produced in countries other > than the country in which you are located. This message cannot be > guaranteed to be secure or error-free. This message is subject to terms > available at the following link: http://www.ml.com/e- > communications_terms/. By messaging with Merrill Lynch you consent to the > foregoing. > --------------------------------------------------------
