FTP Mysterium V7R1

[wolfgang.w]

Zuerst einmal Danke für Eure Anteilnahme und Eure Antworten.

@Fuerchau
Mit den Parametern habe ich schon sämtliche mögliche Kombinationen durchgespielt, immer mit dem gleichen Resultat!

@Anton Gombkötö
An der Firewall kann es insofern nicht liegen, da es auf dem alten System mit V5R3 jahrelang tadellos funktioniert hat. In der ganzen Umgebung wurde "nur" das System selbst gewechselt. Alles andere wie Firewall, Switches etc. blieb wie es vorher auch war.

Das wäre zumindest eine Erklärung, warum's mal geht und mal nicht.

Leider geht es immer nur 1x oder 2x. Danach kommt immer zuerst diese 500'er Fehlermeldung und dann ist schluss. Wenn es an der Firewall liegen würde, dann müsste es dann und wann auch das erste mal nicht gehen. Ist jedoch nicht der Fall.

Zwischenzeitlich hat sich herausgestellt, dass das Problem bei einem anderen Kunden, bei welchen auch via FTP Bestelldaten abgeholt werden, ebenfalls auftritt. Bei diesem Kunden ist es jedoch nicht so problematisch, da selten mehr als 2 Dateien pro Lauf abzuholen sind. Aus diesem Grund ist es auch noch nicht aufgefallen.

Seit der Umstellung mit den Pausen dazwischen läuft es immer tadellosund fehlerfrei. Nachfolgend ein Log:

> lcd /idoc
Das lokale Arbeitsverzeichnis ist /idoc
Einen FTP-Unterbefehl eingeben.
> get 20130919024210534_00061284.xml
227 Entering Passive Mode (193,222,64,82,149,70)
150-Starting Transfer
150-Downloading
150-Checking file
150 Starting Transfer
226 Transfer Complete
 16483 Byte in 0.021 Sekunden übertragen. Übertragungsgeschwindigkeit 767.209
 KB/s.
Einen FTP-Unterbefehl eingeben.
> SYSCMD DLYJOB DLY(0001)
Einen FTP-Unterbefehl eingeben.
> get 20130919024243896_00061285.xml
227 Entering Passive Mode (193,222,64,82,169,40)
150-Starting Transfer
150-Downloading
150-Checking file
150 Starting Transfer
226 Transfer Complete
8619 Byte in 0.009 Sekunden übertragen. Übertragungsgeschwindigkeit 980.651
KB/s.
Einen FTP-Unterbefehl eingeben.
> SYSCMD DLYJOB DLY(0001)
Einen FTP-Unterbefehl eingeben.
> get 20130919024446085_00061286.xml
227 Entering Passive Mode (193,222,64,82,128,130)
150-Starting Transfer
150-Downloading
150-Checking file
150 Starting Transfer
226 Transfer Complete
 10213 Byte in 0.005 Sekunden übertragen. Übertragungsgeschwindigkeit 2091.622
 KB/s.
Einen FTP-Unterbefehl eingeben.
> SYSCMD DLYJOB DLY(0001)
Einen FTP-Unterbefehl eingeben.
> get 20130919024544364_00061287.xml
227 Entering Passive Mode (193,222,64,82,139,99)
150-Starting Transfer
150-Downloading
150-Checking file
150 Starting Transfer
226 Transfer Complete
3083 Byte in 0.002 Sekunden übertragen. Übertragungsgeschwindigkeit 1578.496
KB/s.
Einen FTP-Unterbefehl eingeben.
> SYSCMD DLYJOB DLY(0001)
Einen FTP-Unterbefehl eingeben.
> close
221 Good-Bye 
Einen FTP-Unterbefehl eingeben.
> QUIT

Wer hat sonst noch eine Idee? Wahrscheinlich werde ich dieses Problem mal an IBM weiterleiten müssen!

[Zerberus77]

Hallo Wolfgang,

wenn du willst, würde ich mir einen TRCCNN ansehen.
Habe jetzt den Befehl nicht bei der Hand, aber folgende Parameter müssen gesetzt werden:

TRCCNN - F4
Modus *ON
Type *IP
Tracetabellenname FTP
Anzahl der Einheiten 128
Maßeinheit *MB
2.Seite
Ferne IP Adresse <Adresse des FTP Servers>
Enter

Problem nachstellen

Wenn der Fehler aufgetreten ist
TRCCNN - F4
Modus *OFF
Tracetabellenname FTP
Ausgabe *PRINT

In WRKSPLF findest du dann eine QSYSPRT mit BenDaten TRCCNN. Wenn du mir die dann zukommen lassen kannst, würd ich sie mir mal ansehen.

Mail Adresse kann ich per PM schicken.

Du könntest noch ein DEBUG 100 in der FTP Sitzung einbauen, dann wird die FTP Client Seite getraced. Im WRKSPLF des Benutzers, der den FTP gestartet hat, findest du dann ein oder mehrere QTFTPTRC oder so ähnlich (bin mir mit dem Namen grad gar nicht sicher, findest die aber schon)

Wenn der FTP Server auch eine AS400 ist, könnte man dort ein TRCTCPAPP *FTP machen.

MFG Zerberus

[Fuerchau]

Da frage ich mich, wie das Script aufgebaut ist.
Gibst du mehrere Get's direkt hintereinander ab?
Vielleicht ist das neue System da einfach schneller und der 2. get wird ausgelöst bevor der erste fertig ist!
Mit dem DLY umgehst du halt die Schnelligkeit des Systems.

Warum klappt mget nicht?

[wolfgang.w]

@Fuerchau
Das Script ohne Pausen ist nichts anderes als viele get-Zeilen nacheinander.

z.B.
get 20130924035807706_00061469.xml
get 20130924043211675_00061470.xml
get 20130925063354322_00061471.xml
get 20130925063426180_00061472.xml
get 20130925063519055_00061473.xml
get 20130925063625997_00061474.xml
get 20130925063724171_00061475.xml
etc.

Und genau das ist der Krux an der ganzen Sache. Mehrere get (wie auch der mget, was ja nichts anderes ist) nacheinander funktionieren nicht. Baue ich hingegen eine Pause zwischen jedem Get ein dann klappt es! Die Symptomatik ist wie du sagst, dass der 2. get ausgelöst wird bevor der 1 beendet ist. Aber wie kann das sein?

@Zerberus77
Vielen Dank für Dein Angebot. Ich habe mal einen Testlauf gemacht und die Ausgabe bereit gestellt. Wo soll ich Sie hinschicken?

[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