Re: FTP Append (Update)
Yesterday and last night were busy, relatively speaking, for my 0 records detector. There were three occasions when it detected 0 record conditions as follows (times are GMT): 12/12 at 23:56:58 Detected 0 record log from location A (the trouble spot) 23:58:58 The file had records. 12/13 at 00:04:58 Detected 0 record log from location B 00:06:58 The file had records 14:08:59 Detected 0 record log from location A 14:10:59 The file had records The logs from location A were corrupted but not the one from location B. Before anyone suggests something odd about the two minute deltas, that is the interval that the pcs use when checking for data to be sent. Another item to note - each center has its own id that is used for logging in, even though the data is all being sent to the same file space. I think that this may create more questions than it answers. We have seen similar situations before. The corruption of files is almost universally unique to location A, and seems to always occur in conjunction with the file containing 0 records. However, there is not a one-one relationship between the 0 record files and the corruptions. There have been times when a file was not corrupted in conjunction with detection of the 0 record file. This has been the case with files from other centers and once from the problem child. Also, files from other centers are corrupted once in a great while - there have been none since I put in my 0 record detector, so I can draw no inference about any relationship there. Something else that may be of interest is that the center having the difficulty is the most remote of our centers. Regards, Richard Schuh
Re: FTP Append (Update)
Richard,
What about, just for diagnostic purposes, having location A FTP the file
three times.
1) FTP it to a discrete/unique file id (maybe with the filetype as rexx
time('S'), seconds since midnight with an 'A' suffix, like 12345A. Save
the 's'
2) FTP APPEND as you are now.
3) FTP again just list the first file, but obviously with a slightly
different ftype using the previous ftype using the previous 's' with a
'B' suffix, like: '12345B'.
When things go well, erase the 12345A/12345B files.
When things go south (why do we pick on the south?), you can examine the A
and B files later for more info.
The A file will show how many records should have been in the APPEND file,
and the B file should match the A file. If they don't match, you are a
step closer to the answer. If they do match, and have more than 0
records, then you're just as mystified, but with more information.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
Schuh, Richard [EMAIL PROTECTED]
Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
12/13/2007 11:33 AM
Please respond to
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: FTP Append (Update)
Yesterday and last night were busy, relatively speaking, for my 0
records detector. There were three occasions when it detected 0 record
conditions as follows (times are GMT):
12/12 at 23:56:58 Detected 0 record log from location A (the trouble
spot)
23:58:58 The file had records.
12/13 at 00:04:58 Detected 0 record log from location B
00:06:58 The file had records
14:08:59 Detected 0 record log from location A
14:10:59 The file had records
The logs from location A were corrupted but not the one from location B.
Before anyone suggests something odd about the two minute deltas, that
is the interval that the pcs use when checking for data to be sent.
Another item to note - each center has its own id that is used for
logging in, even though the data is all being sent to the same file
space.
I think that this may create more questions than it answers. We have
seen similar situations before. The corruption of files is almost
universally unique to location A, and seems to always occur in
conjunction with the file containing 0 records. However, there is not a
one-one relationship between the 0 record files and the corruptions.
There have been times when a file was not corrupted in conjunction with
detection of the 0 record file. This has been the case with files from
other centers and once from the problem child. Also, files from other
centers are corrupted once in a great while - there have been none since
I put in my 0 record detector, so I can draw no inference about any
relationship there.
Something else that may be of interest is that the center having the
difficulty is the most remote of our centers.
Regards,
Richard Schuh
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. Emails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by email.
Re: FTP Append (Update)
I was thinking that the SRVRFTPO CONFIG version of TIMESTAMP might actually apply to the FTPSERVE LOG file. I already use TERM TIMPSTMP ON for the console messages, so the question still stands. Is the documentation wrong (TIMESTAMP ON does not appear to be the default, as stated), or is there a program bug? Which do I report? While on the subject of the log files, they would be much handier if they were made date-specific. If the file type were the current date, perhaps Rexx date(S) format, instead of that totally uninformative LOG, it would make life much easier for me and, I suspect, for many others. This applies to all of those perpetually growing log files that seem assume that they have an infinitely large disk to use and try to use every bit of it. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Sunday, December 02, 2007 7:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Friday, 11/30/2007 at 06:45 EST, Schuh, Richard [EMAIL PROTECTED] wrote: There is no SRVRFTP CONFIG file, so everything about FTP is vanilla. The manual says that the default is TIMESTAMP ON. I have 30,000 lines of empirical evidence that this is not so. Do I report this as a program bug or is it a documentation problem? TIMESTAMP applies to actual FTP server messages, not to anonymous, uh, e-drivel the server puts on the console. I'd use CP TERMINAL TIMESTAMP ON instead. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
On Monday, 12/03/2007 at 11:55 EST, Schuh, Richard [EMAIL PROTECTED] wrote: I was thinking that the SRVRFTPO CONFIG version of TIMESTAMP might actually apply to the FTPSERVE LOG file. I already use TERM TIMPSTMP ON for the console messages, so the question still stands. Is the documentation wrong (TIMESTAMP ON does not appear to be the default, as stated), or is there a program bug? Which do I report? Without digging through code, I would guess that the FTP TIMESTAMP ON applies only to *messages*, not the, ummm, e-musings and trace output of the server. If there's a bug, it's that those e-musings are being displayed. While on the subject of the log files, they would be much handier if they were made date-specific. If the file type were the current date, perhaps Rexx date(S) format, instead of that totally uninformative LOG, it would make life much easier for me and, I suspect, for many others. This applies to all of those perpetually growing log files that seem assume that they have an infinitely large disk to use and try to use every bit of it. Again, use the exits we have provided if you want to build a real, live audit trail of what the server is doing. Then you can use SCIF to capture output of your choice and store it the way you want. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
On Friday, 11/30/2007 at 06:45 EST, Schuh, Richard [EMAIL PROTECTED] wrote: There is no SRVRFTP CONFIG file, so everything about FTP is vanilla. The manual says that the default is TIMESTAMP ON. I have 30,000 lines of empirical evidence that this is not so. Do I report this as a program bug or is it a documentation problem? TIMESTAMP applies to actual FTP server messages, not to anonymous, uh, e-drivel the server puts on the console. I'd use CP TERMINAL TIMESTAMP ON instead. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
Normally, there is no PUT. It has been, until yesterday, only an APPEND. If the file does not exist, it gets created by the first APPEND. The target is a file pool on VM. Data is sent from PC to VM. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, November 30, 2007 6:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) Hello Richard Schuh, This is a PUT and then APPEND to a PC based system, correct? And it use to work but now you are having a problem with just this one. If I have summary correct, then I would have to say that someone at the PC end has change security settings to allow read and write but not UPDATE. I know we have had this problem on UNIX based systems when the UNIX Administrator was reviewing his system and decide it was too open. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 29, 2007 6:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! The last message in the above list occurred only once on 12 July 2006 (at least it included a timestamp), so we can eliminate it from consideration. Which of the other messages raises a flag? More precisely, which of the others would have caused the file that already existed in SFS to be corrupted? (My favorite is the OK. It reminds me of Unix back in 1979 - the most frequent error message was a question mark, and it was displayed for any number of errors.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, November 29, 2007 3:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Thursday, 11/29/2007 at 05:55 EST, Schuh, Richard [EMAIL PROTECTED] wrote: This just in. The people overseas have found a message that gets displayed before the error. ERROR: Can not Append on VM3. Function = FtpAppend. FtpError = FTPDATACONN It appears that the overwrite happens on the next attempt to do the FTP APPEND after this error, whatever it is. There is no mention of ?FTPDATACONN? in the 5.2 TCP/IP bookshelf. That error message is from the PC client in response to a server error, not VM. You need to see the error generated by the VM FTP server. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
There is no SRVRFTP CONFIG file, so everything about FTP is vanilla. The manual says that the default is TIMESTAMP ON. I have 30,000 lines of empirical evidence that this is not so. Do I report this as a program bug or is it a documentation problem? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, November 30, 2007 10:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Thursday, 11/29/2007 at 07:09 EST, Schuh, Richard [EMAIL PROTECTED] wrote: I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. If you want a good log of who does what when, use the FTP server audit exit to record/display details. You could combine it with the general command exit to look for STOR and APPE commands. At least you could narrow down the place time. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! None of those are interesting in this context except to see their timestamps in relation to the audit records above. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
Alan, Would putting CP TERM TIMESTAMP ON in the PROFILE EXEC or if CP 5.3.0 in the DIRECTORY hurt TCPIP or FTPSERVE in any way? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, November 30, 2007 1:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Thursday, 11/29/2007 at 07:09 EST, Schuh, Richard [EMAIL PROTECTED] wrote: I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. If you want a good log of who does what when, use the FTP server audit exit to record/display details. You could combine it with the general command exit to look for STOR and APPE commands. At least you could narrow down the place time. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! None of those are interesting in this context except to see their timestamps in relation to the audit records above. Alan Altmark z/VM Development IBM Endicott 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.
Re: FTP Append (Update)
On Thursday, 11/29/2007 at 07:09 EST, Schuh, Richard [EMAIL PROTECTED] wrote: I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. If you want a good log of who does what when, use the FTP server audit exit to record/display details. You could combine it with the general command exit to look for STOR and APPE commands. At least you could narrow down the place time. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! None of those are interesting in this context except to see their timestamps in relation to the audit records above. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
Those messages occur over and over in the logs. Of the 10 listed messages, 2 were one-time messages; the no such connection message occurred about 10 times. There were 12 of the shut down messages, the last being in July of this year. The rest occur thousands of times, each. One interesting note: In 2004, I asked essentially the same question about the same message. At that time, we were seeing a null file in SFS. This is probably the same problem, except we have not seen the null file. That is probably a matter of timing - if we look before the next addition is appended, we would probably see it. There were no answers posted to my query back then. The problem was self-healing; it went away for over 3.5 years. We do have a circumvention. When the PC posts the DATACONN message, the whole file is sent using PUT instead of APPEND, insuring that no corrupted file lasts for a measurable period. This will increase the amount of data on the network, but it will prevent confusion and manual intervention. As for leaving a partial or corrupted files, isn't SFS supposed to handle that? Something about a commit, perhaps? If FTPSERVE is committing a corrupted file, I would hope that it does not have a way to tell SFS to abandon the rename process in the middle. Speaking of SFS, the last occurrence of this problem was about midway between two control data backups that were 10 hours apart, so that is not the source of the problem. There were no messages, as in none at all, on the file pool server's console log between the two backups. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, November 29, 2007 6:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) Foreign host aborted the connection No such connection Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable These messages could occur during transfer, which might leave a partial file or a corrupted block, but there would have to be a very tight race to get it committed. If this were minidisks (I think you said this is SFS), then you could conceivably get the server to think a partial file was successfully written and have it replace the original (the old write a new copy, close, delete old, rename new method), but that would require some very tricky timing.
Re: FTP Append (Update)
T does no harm. We have been running TCPIP and friends that way for a long time. The problem is that no useful information is logged on the console. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI) Sent: Friday, November 30, 2007 11:11 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) Alan, Would putting CP TERM TIMESTAMP ON in the PROFILE EXEC or if CP 5.3.0 in the DIRECTORY hurt TCPIP or FTPSERVE in any way? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, November 30, 2007 1:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Thursday, 11/29/2007 at 07:09 EST, Schuh, Richard [EMAIL PROTECTED] wrote: I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. If you want a good log of who does what when, use the FTP server audit exit to record/display details. You could combine it with the general command exit to look for STOR and APPE commands. At least you could narrow down the place time. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! None of those are interesting in this context except to see their timestamps in relation to the audit records above. Alan Altmark z/VM Development IBM Endicott 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.
Re: FTP Append (Update)
From time to time we send a large MICS file to SFS and get that Foreign host aborted the connection message. When we look at the SFS there is a partial file. We use VMFTP and check for RC=250 and stop processing. The point though is that SFS retains the partial file. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, November 30, 2007 12:49 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) Those messages occur over and over in the logs. Of the 10 listed messages, 2 were one-time messages; the no such connection message occurred about 10 times. There were 12 of the shut down messages, the last being in July of this year. The rest occur thousands of times, each. One interesting note: In 2004, I asked essentially the same question about the same message. At that time, we were seeing a null file in SFS. This is probably the same problem, except we have not seen the null file. That is probably a matter of timing - if we look before the next addition is appended, we would probably see it. There were no answers posted to my query back then. The problem was self-healing; it went away for over 3.5 years. We do have a circumvention. When the PC posts the DATACONN message, the whole file is sent using PUT instead of APPEND, insuring that no corrupted file lasts for a measurable period. This will increase the amount of data on the network, but it will prevent confusion and manual intervention. As for leaving a partial or corrupted files, isn't SFS supposed to handle that? Something about a commit, perhaps? If FTPSERVE is committing a corrupted file, I would hope that it does not have a way to tell SFS to abandon the rename process in the middle. Speaking of SFS, the last occurrence of this problem was about midway between two control data backups that were 10 hours apart, so that is not the source of the problem. There were no messages, as in none at all, on the file pool server's console log between the two backups. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, November 29, 2007 6:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) Foreign host aborted the connection No such connection Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable These messages could occur during transfer, which might leave a partial file or a corrupted block, but there would have to be a very tight race to get it committed. If this were minidisks (I think you said this is SFS), then you could conceivably get the server to think a partial file was successfully written and have it replace the original (the old write a new copy, close, delete old, rename new method), but that would require some very tricky timing. 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.
Re: FTP Append (Update)
Hello Richard Schuh, This is a PUT and then APPEND to a PC based system, correct? And it use to work but now you are having a problem with just this one. If I have summary correct, then I would have to say that someone at the PC end has change security settings to allow read and write but not UPDATE. I know we have had this problem on UNIX based systems when the UNIX Administrator was reviewing his system and decide it was too open. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 29, 2007 6:46 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! The last message in the above list occurred only once on 12 July 2006 (at least it included a timestamp), so we can eliminate it from consideration. Which of the other messages raises a flag? More precisely, which of the others would have caused the file that already existed in SFS to be corrupted? (My favorite is the OK. It reminds me of Unix back in 1979 - the most frequent error message was a question mark, and it was displayed for any number of errors.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, November 29, 2007 3:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Thursday, 11/29/2007 at 05:55 EST, Schuh, Richard [EMAIL PROTECTED] wrote: This just in. The people overseas have found a message that gets displayed before the error. ERROR: Can not Append on VM3. Function = FtpAppend. FtpError = FTPDATACONN It appears that the overwrite happens on the next attempt to do the FTP APPEND after this error, whatever it is. There is no mention of ?FTPDATACONN? in the 5.2 TCP/IP bookshelf. That error message is from the PC client in response to a server error, not VM. You need to see the error generated by the VM FTP server. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
On Thursday, 11/29/2007 at 05:55 EST, Schuh, Richard [EMAIL PROTECTED] wrote: This just in. The people overseas have found a message that gets displayed before the error. ERROR: Can not Append on VM3. Function = FtpAppend. FtpError = FTPDATACONN It appears that the overwrite happens on the next attempt to do the FTP APPEND after this error, whatever it is. There is no mention of ?FTPDATACONN? in the 5.2 TCP/IP bookshelf. That error message is from the PC client in response to a server error, not VM. You need to see the error generated by the VM FTP server. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
I would love to. Where is it hidden? I have looked in the console log ond the FTPSERVE LOG file. Unfortunatelt, the former, which contains timestamps due to the ability to set them on in CP, has no error messages, while the latter has no timestamps and very little, if any, in the way of information that ties any given message to a specific incident. In the 30,000 line FTPSERVS LOG, there are only 10 unique messages as follows: Foreign host aborted the connection Foreign host did not respond within OPEN timeout No such connection Foreign host rejected the open attempt Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable Foreign host disagreed on security or precedence OK Software error in TCP/IP! The last message in the above list occurred only once on 12 July 2006 (at least it included a timestamp), so we can eliminate it from consideration. Which of the other messages raises a flag? More precisely, which of the others would have caused the file that already existed in SFS to be corrupted? (My favorite is the OK. It reminds me of Unix back in 1979 - the most frequent error message was a question mark, and it was displayed for any number of errors.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, November 29, 2007 3:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Append (Update) On Thursday, 11/29/2007 at 05:55 EST, Schuh, Richard [EMAIL PROTECTED] wrote: This just in. The people overseas have found a message that gets displayed before the error. ERROR: Can not Append on VM3. Function = FtpAppend. FtpError = FTPDATACONN It appears that the overwrite happens on the next attempt to do the FTP APPEND after this error, whatever it is. There is no mention of ?FTPDATACONN? in the 5.2 TCP/IP bookshelf. That error message is from the PC client in response to a server error, not VM. You need to see the error generated by the VM FTP server. Alan Altmark z/VM Development IBM Endicott
Re: FTP Append (Update)
Foreign host aborted the connection No such connection Foreign host is no longer responding TCP/IP service is being shut down Destination network is unreachable These messages could occur during transfer, which might leave a partial file or a corrupted block, but there would have to be a very tight race to get it committed. If this were minidisks (I think you said this is SFS), then you could conceivably get the server to think a partial file was successfully written and have it replace the original (the old write a new copy, close, delete old, rename new method), but that would require some very tricky timing.
