Windows Zugriff auf das IFS langsam / unmöglich

[tdll]

Hallo zusammen,
Wir haben sporadische Probleme mit dem Zugriff auf das IFS von Windows Systemen. Mal funktioniert es reibungslos, oft ist es aber unmöglich im Windows Explorer etwas zu suchen. Reaktionszeiten > 10 Minuten sind möglich. Das ganze passiert unter Windows Vista und 7

Ich habe schon einige Problemlösungswege ausprobiert:
- Aktivieren / Deaktivieren des WebService Dienstes unter Windows
- Kennwörter nur kleingeschrieben
...

Wir haben das ganze einmal mitgesnifft. Das sieht dann so aus:
11 (46): (Client) TCP Session beginnt, Client SYN
21 (46): (Server) Malformed Packet von 172.17.0.1
24 (46): (Client) Create Request \QNTC
26 (74): (Server) NBSS keep-alive
28 (101): (Server) NBSS keep-alive
30 (108): (Client) TCP Session endet, Client RST nach 62 Sekunden
31 (108): (Client) Neue TCP Session
45 (108): (Client) Create Request \desktop.ini
47 (136): (Server) NBSS keep-alive
49 (163): (Server) NBSS keep-alive
51 (170): (Client) TCP Session endet, Client RST nach 62 Sekunden
52 (170): (CLient) Neue TCP Session
60 (170): (Client) Create Request \desktop.ini
62 (198): (Server) NBSS keep-alive
64 (225): (Server) NBSS keep-alive
66 (232): (Client) TCP Session endet, Client RST nach 62 Sekunden

Was könnte das noch sein, und wie könnten wir das Problem lösen.

Vielen Dank für Ideen!

TDLL

PS: Release V7R1

[Fuerchau]

Greift ihr etwa per Freigabe auf eine QNTC-Verknüpfung zu?
Dies solltet Ihr auf jeden Fall lassen und direkt mit der Serverfreigabe verbinden.
Die AS/400 versucht sich nämlich mit dem aktuellen Benutzer lokal mit dem QNTC-Server, also ohne Domäne, zu verbinden, was meistens nicht funktioniert.
Funktionieren kann das nur mit Benutzern, die auf dem QNTC-server auch lokal registriert sind, ansonsten wartet die AS/400 da auf einen Timeout (mach mal auf der AS/400 einen mkdir '/QNTC/Server/Freigabe' mit einem nicht registrierten Benutzer, dann merkst du das schon).

Desweiteren ist die Suche von Windows sowieso sehr langsam, wenn man auch Inhalte von Dateien suchen lässt und nicht nur Namen.
Netzlaufwerke können nicht indiziert werden, deshalb werden alle Dateien gelesen und gescannt.

Auch die (in Windows meist versteckte) desktop.ini ist ein Problem. Der Eigner ist immer der Ersteller und Public ist *exclude, also dem ersten gehört diese Datei.
Ich weiß nicht, wie lange Windows da auf den Zugriff ggf. wartet, zumal wenn die Datei ggf. von einem anderen Benutzer gerade gesperrt ist, die AS/400 wartet da nämlich per default 1 Minute.

Wie man Windows das Erstellen der Desktop.ini auf Freigaben verbieten kann, weiß ich auch nicht, zu finden ist da erst mal nichts.
Die Alternative ist ggf. in den Verzeichnissen jeweils eine eigene desktop.ini mit Eigner QSECOFR und Puplic *exclude einzurichten, dann kann windows nicht drauf zugreifen, keine Sperre setzen und ignoriert diese vielleicht.

[tdll]

Hallo,

Vielen Dank für die schnelle Antwort.
Wir greifen schon auf Dateifreigaben zu. (System i Navigator -> Dateisysteme -> Dateifreigaben
Freigabe: I5 Pfad: / \\i5\i5 (file://i5/i5)
Freigabe: As400 Pfad: \ \\i5\As400 (file://i5/As400)

Das Problem liegt auch nicht bei angeschlossenen Servern, sondern auch direkt bei Verzeichnissen innerhalb des IFS. Eine Suche innerhalb von Dateien probieren wir gar nicht erst aus. Das würde vermutlich noch häufiger zu Problemen führen.

Die Vermutung mit der Desktop.ini war interessant, allerdings habe ich auf dem Server keine gefunden (versteckte und Systemdateien werden natürlich angezeigt). Ansonsten vermute ich inzwischen auch eine Lock-Situation. Ich wüsste allerdings nicht, was sonst noch gelockt werden könnte. Oder kann es ggf. Probleme mit einer Anzahl von gleichzeitigen Zugriffen auf das IFS geben? Eine Maximalanzahl von Benutzern ist im Navigator nicht gepflegt.

Interessant ist, daß es bei manchen Benutzern erst massive Probleme gibt, dann funktioniert alles wieder hervorragend, und später wieder nichts mehr.

Viele Grüße,
TDLL

[Fuerchau]

Verantwortlich für den Service sind die QZLSFILE-Jobs.
Manchmal klappt ggf. das Aufräumen in diesen Job's nicht.
Da diese aber der Wiederverwendung unterliegen, werden Ressourcen u.U. länger als nötig geblockt.
Ähnliche Probleme hatte ich auch schon bei den QZDASOINIT-Jobs (ODBC/JDBC).
Mittels CHGPJE MAXUSE(1) kann man die Anzahl Verwendungen beeinflussen, damit die PJE's nicht in den Pool zurückgehen sondern beendet werden und alle Ressourcen freigeben.
Der Init eines solchen Job's geht trotzdem eigentlich sehr schnell und kann daher vernachlässigt werden. Man hat dann aber immer saubere Job's.

Ggf. sollte man auch mal dei JOBD's kontrollieren ob Threading erlaubt ist oder nicht und damit mal experimentieren.