FTP Mysterium V7R1

[Fuerchau]

Nun ja, im Passivmodus wird der Get nicht vom Client ausgeführt sondern als Put vom Server.
Der Aktivmodus (SENDPASV 0) wird aber ggf. vom Server abgelehnt.

Nun meldet der Server ggf. den Get als erledigt aber er kann einen neuen Befehl noch nicht verarbeiten.
Da die AS/400 aber wohl schneller geworden ist, kann die den Get bereits absetzen bevor der Server auch tatsächlich im Empfangsmodus für neue Befehle ist.
Je nach Serverauslastung kann der mal schneller oder auch langsamer sein.
Ist der schnell genug, klappts, wenn nicht, klappts nicht.
Durch deinen DLY gibst du dem Server nun ausreichend Zeit.

Warum kannst du keinen "mget *.xml" absetzen?
Dies würde dann vom Server automatisch in einen "mput" übersetzt werden.
Allerdings gilt auch hier, dass bei mehreren mget's der Server vielleicht zu langsam ist.

Ursache könnte sein, dass die AS/400 nun auch mit Threading im FTP arbeitet.

[Zerberus77]

Hallo Wolfgang,

PM ist unterwegs.

MFG Zerberus

[wolfgang.w]

@Zerberus
Du hast Post.

@Fuerchau
Ich habe das mit dem "mget *.xml" mal ausprobiert. Leider mit dem gleichen Ergebnis. Nach der 2. Dateiübertragung kommen die gleichen Fehlermeldungen und der Job bricht ab.

Da die AS/400 aber wohl schneller geworden ist, kann die den Get bereits absetzen bevor der Server auch tatsächlich im Empfangsmodus für neue Befehle ist.

Sollte der Client mit dem nächsten Get bzw. Port-Befehl nicht warten bis der Server die Abschlussmeldung des vorherigen Get gesandt hat? Wenn ja, dann ist der Server doch in jedem Fall wieder empfangsbereit - oder nicht?

Ursache könnte sein, dass die AS/400 nun auch mit Threading im FTP arbeitet.

Dazu habe ich keine Dokumentationen gefunden.

[Fuerchau]

Auch der FTP-Server wird wohl mit Threads arbeiten.
Wenn also der Sendethread seine Fertigmeldung abgibt, kann der Client eigentlich den nächsten Befehl senden.
Der Sendethread muss sich aber noch beenden und dem Listener für die Kommandos sein Ende mitteilen.
Wenn das u.U. länger dauert als die AS/400 nun den nächsten Befehl sendet kommt es zum Konflikt.

Da ich nun nicht weiß, wie ein mget implementiert ist kann ich auch hier nur raten.
Ggf. ist mget ein interner Befehl, der die Dateinamen vom Server abholt und dann eben automatisch mehrere get's generiert.
Wenn der Server aus dem mget selber einen mput machen kann wäre das eigentlich kein Problem.

Wer weiß, sobald meine Kunden auch auf V7 umsteigen, komme ich vielleicht in die selben Probleme da ich häufig mit mget arbeite.

Hier habe ich noch eine Doku:
Introduction to FTP

Interessant ist "SENDPASV 1", also einschalten des Modus.

When PASV mode is used, the client sends a command to the server informing the server of its intent to use PASV mode, and the server responds with a TCP port. The client then initiates a connection to the server on this port and the server begins transferring data.
In general, it is usually better to use PASV mode.

[BenderD]

... schnell hin, schnell her: wenn ein FTP Transfer mittendrin abkackt, ist das entweder ein Transportproblem, oder ein Bug im OS (ich tippe mal auf letzteres.
Was die Multithreading Diskussion angeht, müsste Multithreading das eher heilen als verschärfen; ob das in multiple Threads ablaufen könnte, müsste man mal die FTP Spezifikation zu Rate ziehen.

D*B

[Zerberus77]

Hallo Wolfgang,

also der Trace sieht gut aus. Was ich dir mit 99.9% Sicherheit sagen kann ist, dass es kein Fehler seitens der iSeries ist.

Der Trace/die Kommunikation sieht im Groben so aus:

*) Client sendet ein SYN Packet
*) Server antwortet mit SYN ACK
*) Anmeldung und 'cd' werden gemacht
*) Client sendet seinen PASV command
*) Datenverbindung (SYN - SYN ACK) wird hergestellt
*) Server sendet seine Daten und schickt ein 'Transfer completed successfully'
*) Server schickt den FIN mit dem letzten Datenpacket für die Datenleitung
*) Client sendet sein FIN auf der Datenleitung
*) Client sendet sein neues PASV
*) Server antwortet mit dem bekannten Fehler

Es kommt also zu keiner Überschneidung im Gegenteil, der 'Transfer completed successfully' kommt, obwohl noch nicht alle Daten am Client angekommen sind. Der Client wartet aber bis er sein letztes Datenpacket bekommen hat und vom Server das FIN erhalten hat. Erst dann wird die nächste Datei angefordert. Ein wenig stutzig macht mich die Reihenfolge, wie die Daten kommen. Das Problem mit dem 'frühzeitigen' 'Transfer completed successfully' habe ich nur bei grösseren Files gesehen, deine sind so 3-4 kb groß. Irgendwas im Netz dazwischen, oder der Server selbst dürfte da nicht ganz nachkommen.

Du sagst, das kam nach der Umstellung auf V7R1. Was mir da im Bereich TCPIP einfallen würde ist, das sich die Defaultwerte des SND und RCV Buffers geändert hat. Diese waren bis incl. V6R1M1 8192. Prüfe mal mit CHGTCPA - PF4 was bei dir da steht. Wenns grösser ist, ändere es mal auf 8192. Wenns dann geht, gibts definitiv ein Problem im Netzwerk. Normalerweise sollte ein Wert von 65535 drinnenstehen.

Ich denke, das die neue Maschine mit dem neuen OS jetzt für den Server 'zu schnell' ist. Möglicherweise ist ja jetzt auch ein GB Anschluss und vorher wars ein 100MB, das kann sich auch mal so 'negativ' auswirken. Ich habe jetzt nicht geprüft, ob die Version vom FTP Server aktuell ist, aber ich würd das auch mal prüfen lassen.

Wie schon gesagt, anhand der Tracedaten kann ich mit 99.9%iger Sicherheit sagen, dass es kein Fehler der FTP Client Software oder der iSeries ist.

MFG Zerberus

[wolfgang.w]

Hallo Zerberus

Vielen Dank für Deine Arbeit und Deine Unterstützung. Schade, dass man nichts eindeutiges ermitteln konnte, dann hätte man einen Aufhänger gehabt!

Die Pufferwerte in CHGTCPA habe ich vorher schon mal auf die 8192 (wie er auf der alten 520'er V5R3 Maschine war) runtergeschraubt. Ich habe es jetzt sicherheitshalber nochmals gemacht und einen Test durchgeführt. Leider war das Ergebnis immer noch das Gleiche!

Betreffend PTF ist die Maschine auf dem neuesten Stand (13037). Die Hyper habe ich noch nicht alle durchgesehen, aber auf die Schnelle habe ich nichts gefunden was dieses Problem betreffen könnte.

Summa Sumarum immer noch keine Lösung! Weiss jemand wie man so ein Problem am einfachsten der IBM meldet?

[TARASIK]

Hallo,
ich würde diese 1000 Ptf installieren.

IBM i Support: PTF Cover Letter: SI49734

[Zerberus77]

Hallo Tarasik,

ich glaube nicht, dass das PTF hier hilft, aber schaden tut's auch nicht.

@Wolfgang,

bei der IBM melden bringt sicher auch nix, da das Problem am FTP Server ist und der ja eine Windows Kiste ist.
Ich würde mal Testhalber einen FTP Server im Netz installieren und mit diesem so einen Filetransfer nachstellen. Du wirst sehen, alles funktioniert ohne Probleme.

MFG Zerberus

[wolfgang.w]

@Tarasik
Ja, dieses PTF habe ich auch schon gesehen, ist jedoch für meinen Fall nicht relevant, da es sich beim APAR um einen ganz anderen Sachverhalt handelt.

... da das Problem am FTP Server ist und der ja eine Windows Kiste ist.

Das ist meiner Meinung nach nicht ganz korrekt weil

- mit dem alten 520'er V5R3 System funktioniert es (testeshalber immer noch) einwandfrei

- vom neuen System aus bei einem anderen Kunden ebenfalls Bestellungen per FTP abgeholt werden und da das genau gleiche Problem auch auftritt (ist natürlich auch eine Windows Kiste).

Somit kann, zumindest aus meiner Sicht, behauptet werden, dass es nicht an den FTP-Servern liegen kann.

[TARASIK]

Hallo,
auf eine Aparbeschreibung würde ich mich nicht verlassen, dieses Ptf ersetzt einige andere Ptfs aus dem FTP Bereich.
Ich würde es trotzdem installieren.

[TARASIK]

Hallo,
vermutlich liegt es an Deinem Script, denn da ein Sprung von R530 nach R710 gemacht wurde, beachtete man nicht die Änderung mit R540.

Hier aus dem Memo von R540:
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. If you have FTP scripts that are expecting the
250 reply code, you should change the scripts to expect a 226 reply code
for a successful data transfer.