|
Last week, I downloaded Scott Klement's FTPAPI routines, and I just went to look at the source - looks like he's checking for both 226 and 250 in most places. But for me, that's neither here nor there - mainly we use FTP to talk to non-AS/400 boxes, anyway. Francis Lapeyre IS Dept. Programmer/Analyst Stewart Enterprises, Inc. E-mail: flapeyre@xxxxxxxx -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx Sent: Tuesday, January 31, 2006 10:23 AM To: Midrange Systems Technical Discussion Subject: RE: V5R4 ftp anomaly Good point. "Real coders" should already be used to coding for both (and perhaps more) anyway, right? But who has the time to read RFC's? Don't we all just copy existing code, or just test something and then change our code to fall within that test criteria? Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Ingvaldson, Scott" <SIngvaldson@xxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 01/31/2006 10:56 AM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To <midrange-l@xxxxxxxxxxxx> cc Fax to Subject RE: V5R4 ftp anomaly Doesn't that message get sent from the Target Server? We get a 250 response from our M/F FTPs but a 226 response from a server that identifies itself as "Microsoft FTP Service (Version 4.0)" Regards, Scott Ingvaldson iSeries System Administrator GuideOne Insurance Group -----Original Message----- date: Tue, 31 Jan 2006 07:34:21 -0800 from: "Tim Kredlo" <TKredlo@xxxxxxxxxxxxxxxx> subject: RE: V5R4 ftp anomaly I passed along this info along to the guy who deals with FTP here. He says that he has come across both the '226' and the '250' messages previously. He does not have any idea what the differences are, but that this is not new. Tim Kredlo Exterior Wood, Inc -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx Sent: Tuesday, January 31, 2006 6:53 AM To: midrange-l@xxxxxxxxxxxx Subject: V5R4 ftp anomaly This is a reply from one vendor regarding a V5R4 ftp issue: It would appear that IBM has changed something with FTP transfers in V5R4. FTP does not give us errors so we have to read the FTP log and interpret it. We are coded to look for: "250 File transfer completed successfully." but V5R4 is issuing "226 File transfer completed successfully." This may be considered a bug in V5R4 as the FTP standard defines what these status codes ought to be...... or IBM may have just decided to change to use a different code for successful completion. I am going to enter a fix for <(our package)> so that we look for both of these codes when reporting on a successful completion. ************ Rob's notes: What I think happened in V5R4 FTP server is that they changed from 250 to 226 to match what most unix servers show. ************ ************ IBM's reply: In the next V5R4 MTU update, there should be a section added to chapter 4 (Licensed programs) for product 5722-TC1 (TCP/IP Connectivity Utilities for i5/OS) and the following entry added to that section: FTP reply code changed For V5R4, the FTP server was changed to return a reply code of 226 instead of 250, when a successful data transfer has been completed. This made the FTP server compliant with RFC 959 which states that if the data transfer connection is closed after a successful data transfer, the reply code should be 226. Customers or business partners who have FTP scripts that are expecting the 250 reply code should change their scripts to expect back a 226 reply code for a successful data transfer. ************ Rob Berendt
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.