Netware DOS Requester FIRST NETWORK DRIVE = F
Weiter kann man unter NW 3.1x auch folgendes eintragen, um die VLMs zu optimieren:
netware protocol = bind exclude vlm = nds.vlm exclude vlm = rsa.vlm exclude vlm = pnw.nlm exclude vlm = security.vlm
Sollte ein Fehler beim Laden der VLMs aufgetreten sein, kann man die VLMs mit dem Parameter /V4 aufrufen. Dabi werden ausführlichere Meldungen angezeigt. Aus der *.VLM, bei der der Ladevorgang abbricht, kann man Rückschlüsse ziehen, wo es klemmt.
Folgende Einstellungen können die Verarbeitungsgeschwindigkeit reduzieren:
load low conn=off | conn VLMs werden in den UMB geladen |
load low ipxncp=off | ipxncp VLMs werden in den UMB geladen |
average name length=8 | Summe der Länge der Namen aller Server, die per attach erreicht werden können: Standard = 48) |
auto large table=off | nur ON wenn Benutzername + Passwort >= 32 Zeichen |
Laut install.exe des OS/2 Requesters für den Eintrag "sessions=" im net.cfg sind bis zu 32 Serververbindungen konfigurierbar, der Defaultwert ist 8.
Auch unter DOS sind mehr als 8 Serververbindung möglich, allerdings nur mit den VLMs und dem CLient32. Dort heißt der Parameter "connections=.." und erlaubt maximal 50(!) Verbindungen.
Nur unter NETX sind maximal 8 Serverconnections möglich.
1252_UNI.001 1252_UNI.002 1252_UNI.003
Wer keine zusätzlichen Fremdsprachen benötigt, kann außer *.001 und *.049 alle anderen Dateien in SYS:LOGIN/NLS, SYS:PUBLIC/NLS und SYS:SYSTEM/NLS löschen.
ODI (Open Datalink Interface) beschreibt eine (bzw. mehrere) Stufen des ISO-OSI- Modells.
Novells Konzept der ODI Treiber sollte man vor allem dann benutzen, wenn man mit mehreren Protokollen gleichzeitig arbeitet, z.B. IPX und TCP/IP.
Außerdem wird die alte IPX.OBJ Version nicht mehr weitersupportet (letzte aktuelle Version 3.10). Die alte IPX wurde aus der IPX.OBJ, einer OBJ-Datei des Kartenherstellers und den Einstellungswerten mit einem speziellen Novell- Linker zusammengefügt. Bei einer Jumperänderung oder Update von einer der OBJ-Dateien mußte man den Treiber jedesmal neu zusammenlinken.
Der Hauptvorteil von ODI ist aber der, daß hier die eine Datei IPX.COM in drei Teile gesplittet wird und eine zusätzliche ASCII-Datei die Konfiguration stark vereinfacht. Wenn jetzt z.B. der Kartentreiber erneuert werden soll, tauscht man einfach die COM oder EXE des Herstellers aus, das wars. Ändert man wegen einer andern Karte den IRQ der Netzwerkkarte, trägt man den neuen Wert einfach in die NET.CFG ein und startet den Rechner neu.
Diese drei Teile sind:
LSL.COM NE2000.COM (bzw. Dein Kartentreiber) IPXODI.COM
wobei in der NET.CFG Einstellungen für alle drei Teile stehen und mit jedem ASCII-Editor geändert werden können.
Diese drei Teile verbrauchen zusammen zwar mehr Speicherplatz als die alte IPX, haben aber eine erweiterte Funktionalität und können durch die jeweils geringere Größe evtl. doch besser in der hohen Speicher geladen werden. Außerdem kann man diese Treiber durch den Parameter -U wieder entladen, was bei der IPX.COM nicht möglich war.
Zusätzlich benötigt man für den Zugriff auf Netware oder PNW Server natürlich immer noch die NETX oder alternativ die VLMs.
Es gibt eine OS/2-Version des System-Login-Scripts und auch des User-Login-Script. Diese werden mit der OS/2-Version des SYSCON angelegt. Weiterhin ist zu beachten, daß Novell für OS/2 keine SEARCH-Laufwerke im Requester implementiert hat und es werden alle Mappings wie ein "MAP ROOT" unter DOS behandelt.
Meine NETX Version (3.32) teilt an, daß sie unter MS-DOS 6.0
läuft, obwohl DOS 6.22 läuft.
Dann steht in der CONFIG.SYS die Zeile
DEVICE=<pfad>SETVER.EXE. Man muß entweder diesen Eintrag
entfernen oder falls er tatsächlich für ein anderes Programm
benötigt wird, den Eintrag der NETX.EXE aus SETVER entfernen.
Der im OS/2 Warp 4 enthaltene NetWare Client trägt die Version 2.11 inkl. einiger Korrekturen. Es gibt bei Novell allerdings bereits eine neuere Version 2.12.
Seit OS/2 Warp Connect wird die NetWare-Unterstuetzung per Default
über NDIS-Treiber in Verbindung mit dem "ODI2NDI" realisiert.
Die NDIS-Konfiguration erfolgt über das MPTS und die speziellen
Einstellungen des NetWare Clients ("Preferred Server" etc.) stehen in
der NET.CFG im Root-Verzeichnis auf der lokalen Festplatte. Im MPTS sind auch
in der "Unterstützung für NetWare Requester" die
verwendeten Frames anzugeben. Über den ersten aktivierten Frame wird der
Server gesucht. Sollte der nicht korrekt eingestellt sein, kommt evtl. die
Meldung: "Fehler! REQ0815: Das Programm kann die Verbindungs-ID
nicht ermitteln. Dann sollte man in der Konfiguration des
NetWare-Requester des MPTS die nicht zutreffenden Frames auf "NO"
setzen.
Der gleiche Fehler tritt auch beim Laden des NWDAEMON in der CONFIG.SYS
auf. Erst das Entfernen der LASTDRIVE-Einstellung aus der CONFIG.SYS hat
diesen Fehler behoben. (Eine Fehlermeldung, die nicht unbedingt auf eine
solche Lösung schließen läßt).
Da die Treiber des NetWare Requesters in der Ladefolge vor den NDIS-Treibern stehen, muß in der "Unterstützung für NetWare Requester" die MAC-Adresse der Netzwerkkarte eingetragen werden. I.d.R. erfolgt dies automatisch während der Installation.
Es empfiehlt sich, die Netzwerkanmeldung unter OS/2 wie unter DOS
über das LOGIN.EXE durchzuführen, damit eine zentrale
Administration durch den Netzwerkadministrator möglich ist. Dazu steht
im Verzeichnis \NetWare auf der lokalen Festplatte das LOGIN.EXE zur
Verfügung. Legt man ein Programmobjekt auf der Arbeitsoberfläche
(oder auch im Systemstart-Ordner) an, so kann dieses über
"Parameter" entweder direkt die notwendigen Angaben enthalten oder
bei Eintrag von "[Server/User]" wird der Anwender zu den
entsprechenden Angaben aufgefordert. Die Abmeldung vom Server erfolgt
automatisch durch den OS/2-Systemabschluss.
Dazu sollte man auch in der CONFIG.SYS unter SET RESTARTOBJECTS= den
Eintrag CONNECTIONS herausnehmen, um zu verhindern, daß nach dem Booten
immer die UserID und das Paßwort für den Netware Server abgefragt
werden.
Wenn man sich mit LOGIN.EXE in der Config.sys einloggt, produziert man einen Hänger, den man durch den Aufruf von NWSTART.EXE (aus R211FT.EXE) vor der LOGIN.EXE beheben kann:
CALL=C:\NETWARE\NWSTART.EXE CALL=C:\NETWARE\LOGIN.EXE
Wenn der Server down ist, meldet OS/2 beim Booten, daß der Server
nicht erreicht werden kann und bleibt dann bis zur Bestätigung stehen.
Wenn man die Zeile RUN=C:\NETWARE\NWDAEMON.EXE aus der CONFIG.SYS
entfernt und das Programm separat startet (z.B. STARTUP.CMD), dann ist das
Problem gelöst.
Alle Ausgaben während des Ladevorgangs der Netzwerktreiber werden beim Systemstart der Datei \IBMCOM\LANTRAN.LOG protokolliert. Auf diesem Wege wird auch die Fehleranalyse vereinfacht.
Für die Netzwerk-Unterstützung in DOS/Windows-Sessions hat Novell ein besonderes Feature in den OS/2-Netware-Requester eingebaut, das ich bisher in keinem anderen System gefunden habe. Die sinnvollerweise per Default als GLOBAL zu installierende NetWare-Unterstützung für DOS/Windows-Sessions führt in der Einstellung PRIVATE (NetWare_Resources der DOS-Sessions) dazu, das man sich mehrmals und vollkommen getrennt voneinander in verschiedenen Sitzungen auf mehreren Servern (oder auch dem gleichen Server) einloggen kann. Die Laufwerkszuordungen sind vollkommen unabhängig voneinander.
Hier noch ein paar Empfehlungen für die Einstellungen in den DOS-Settings in Verbindung mit NetWare:
# LASTDRIVE = E # in DOS-Sessions: IDLE_SENSITIVITY = 25 (oder kleiner) # in WinOS/2-Sessions: IDLE_SECONDS = 10 # INT_DURING_IO *muß* auf OFF stehen bleiben
Damit der nur für Windows-Sessions benötigte TBMI2.COM nicht unnötig Speicher verschwendet, empfiehlt es sich, für diese Sessions eine eigene Autoexec.Bat (z.B. als AUTO_WIN.BAT) anzulegen und deren Namen in den DOS-Settings unter "DOS_AUTOEXEC" einzutragen. Übrigens lassen sich auf diesem Wege auch speicherresidente Anwendungen unter OS/2 starten, ohne daß sich das Fenster automatisch wieder schließt.
Novell hat für OS/2 per Default die Laufwerksbuchstaben L: (Login) und P: (Public) reserviert und in die Config.Sys als Pfad mit L:\OS2; und P:\OS2; eingetragen. Daher empfiehlt es sich, diese beiden Laufwerksbuchstaben auch auf allen anderen Systemen wegen der Einheitlichkeit für die gleiche Zuordung zu verwenden. Da es unter OS/2 nur Root-Mappings gibt, gilt hier für DOS die gleiche Empfehlung, nämlich nur "MAP ROOT" zu verwenden. Das vereinfacht die Administration erheblich.
Wird eine NE-2000 Netzwerkkarte unter OS/2 verwendet, so kann dies zu Problemen bei der Installation und "Installation anpassen" führen. Ursache ist der Treiber/Sniffer MITFX001.ADD bzw. MITFX001.SNP, auf die die NE2000-Karte mit einem Systemhänger reagiert, wenn diese auf ihre I/O-Adresse zugreifen. Abhilfe schafft der folgende Eintrag (xxx durch I/O-Adresse ersetzen) als erste Zeile in der config.sys:
BASEDEV=RESERVE.SYS /IO:xxx,20
Je nach NetWare-Version sind auf dem Server einige PATCH-NLMs zu
installieren, um z.B. das Handling der EAs (Erweiterten Attribute) in der
NetWare zu korrigieren.
Da Novell inzwischen keine Einschränkungen bei den Patch-NLMs mehr
macht, verzichte ich hier auf die Angabe der einzelnen NLMs.
Zum Installieren von OS/2 Warp auf einem Novell Netware Server braucht man nur 1 oder 2 Disketten, alles andere geht vollautomatisch inklusive dem Installieren von CID-fähigen Programmen.
Hinweise zu lesen unter Disk1 oder Unterverzeichnis DISK_1 auf der CD in DiskIMG "readme.cid".
Bei dem aktuellen deutschen NT Client werden Login-Scrips nicht mehr verarbeitet "Login-Script <DEFAULT> nicht gefunden".
Der deutsche Client spricht bekanntlich deutsch, da heißt das Login-Script eben nicht mehr <DEFAULT>, sondern <STANDARD>.
Copyright © by Stefan Braunstein (sbraunst@POBoxes.com)
Letzte Aktualisierung am 1. Dezember 1997