John, I know it doesn't help you, but the rest of us are kinda glad that you didn't find any short blocks. That's because PK16110 was supposed to fix that problem; otherwise we'd all be in trouble. I sincerely hope you can nail this one.
. . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] IBM Mainframe Discussion List <[email protected]> wrote on 03/01/2006 01:44:35 PM: > > -----Original Message----- > > From: IBM Mainframe Discussion List On Behalf Of Patrick O'Keefe > > > > On Wed, 1 Mar 2006 14:03:15 -0600, Chase, John wrote: > > > > >... > > >regular production FTP job gives a corrupted ASCII file about 40% of > > >the time. > > > > > >This is going to be one of those "fun" problems to document.... :-( > > >... > > > > Can you run a packet trace during every transfer until you've > > traced a failure? It sure sounds like you might have a bug > > in the the client or server or TCP/IP stack, and it's a good > > bet that the bug makes itself felt during exceptional > > conditions - retransmissions, duplicate ACKs, etc. The file > > would not be corrupted unless you ran into one of those > > exceptional conditions. > > It's beginning to look like that. We've "played with" FTP-ing the file > about a dozen times today, all without corruption. Of course the > Production job runs just before midnight.... > > Oh, BTW, using the JCL suggested by Brian Peterson I found that the > subject file did not have any embedded short blocks. > > > I don't know of any way to trap this except to have the > > packet trace of each transmission. > > That's probably what we'll end up having to do, unless I can "get lucky" > during the day. ---------------------------------------------------------------------- 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
