Mail Archives: opendos/2003/12/10/08:43:51
On 2003-12-06, Gary Welles wrote:
> The following excerpt from a DV technote may explain why TCP/IP
> connection may or may not always work from TASKMGR.
>
>> ... As a general rule, loading non-DESQview specific network
>> shells within a window is not recommended. The reasons are that
>> network shells are actually interrupt arbitrators, re-directors,
>> and/or repeaters. Depending on the shell configuration (and the
>> application software) intended to run in the window, two primary
>> factors must be considered.
>>
>> 1. A packet may arrive for the workstation while this window
>> is not the current task. The network must retry sending
>> the packet, causing network performance degradation (or the
>> network may timeout and drop the work-station).
>>
>> 2. Only that window would be able to see the network. Loading
>> the network shell in more than one window can also confuse
>> the network unless the shell has been specifically written
>> for this purpose.
In regard to direct IPX/SPX calls issued under the task switcher,
there is a partial solution to this problem in the form of the
TASKID.COM/.MSG task identification program and the TBMI2.COM/.MSG
task buffering driver shipping with Personal Netware 1.0,
Novell DOS 7, and the "full" version of OpenDOS 7.01 or
DR-DOS 7.02/7.03.
You can get basic help on TASKID and TBMI2 in DOSBOOK if you
search for these keyboards. Somewhere, I have some extra
documents explaining all the details, but right now I could
only find the German version of one of these files, which
won't be of much help unless you'd understand German (I am
still attaching it, just in case). But, maybe, if you search
for these files as keywords in our list's archive or in Google,
this may reveal enough information in order to make good use
of them already.
In regard to packet drivers, I seem to remember, there was
a special packet driver (like PKTMUX or MUXPKT?) to address
this problem (originally for use with Windows 3.0), wasn't it?
But I have to admit, that it's eons ago, that I have used
packet drivers, so I guess, others will have much fresher
memory in regard to the details here. Anyone?
For the multitasker you may have to add a line to the [Drivers]
section of TASKMGR.INI in order to load the corresponding
virtual device driver, for example a line like:
vxd=c:\drdos.703\nwclient\vipx.386
vxd=c:\drdos.703\nwclient\vtcpip.386
vxd=c:\drdos.703\nwclient\vncomx.386
and increase the GlobalPages= values by some. (If you have
a corresponding .386 VxD driver for use under Windows 3.xx,
this will in many cases also work under the DR-DOS TASKMGR.
Just try it.)
Good luck,
Matthias
#########################################################################
TBMI2 Benutzerhandbuch
Copyright 1990 Novell, Inc. Alle Rechte vorbehalten
PUFFERVERWALTER FÜR PROZESSUMSCHALTUNGEN V2.0
----------------------------------------
Der Pufferverwalter für Prozeßumschaltungen V2.0 für IPX/SPX
(TBMI2) ist ein Programm, das in Multitasking-Umgebungen
verwendet wird, um das Umschalten zwischen
Peer-to-peer-Anwendungsprogrammen zu gestatten.
Die NetWare-Programmdatei TBMI2.COM sollte verwendet werden,
wenn ein DR DOS-Anwendungsprogramm, das direkte Aufrufe an IPX
oder SPX absetzt (das wird Peer-to-peer-Anwendung genannt),
unter NetWare in einer Multitasking-Umgebung (wie TaskMAX)
läuft.
TaskMAX erlaubt das Umschalten zwischen Anwendungsprogrammen (auch
Auslagern oder Swapping genannt). Jedes Anwendungsprogramm läuft
in einer eigenen DR DOS-Sitzung (manchmal auch als DR DOS-Prompt
bezeichnet) in 640 KByte Speicher. Ein Teil dieses Speichers (genannt
globaler Speicher) enthält Treiber und TSRs wie COMMAND.COM und,
wenn Sie NetWare verwenden, IPX.COM und NETx.COM. Der andere Teil
des Speichers (genannt der lokale Speicher) enthält das
Anwendungsprogramm und dessen Daten.
TaskMAX schaltet von einem DR DOS-Anwendungsprogramm zu einem anderen
um, indem es den Inhalt der aktuellen DR DOS-Sitzung aus dem
konventionellen Speicher auf die Platte verlagert und dann den Inhalt
der neuen DR DOS-Sitzung in den konventionellen Speicher lädt.
Nur der lokale Speicher wird umgeschaltet; der globale Speicher mit
seinen Treibern und TSRs bleibt intakt und wird mit der neuen Sitzung
weiterverwendet. Dies bedeutet, daß es verschiedene lokale
Speichersegmente (eins für jede DR DOS-Sitzung) gibt, während nur
ein globales Speichersegment existiert.
Die meisten DR DOS-Anwendungsprogramme unter NetWare mit TaskMAX
sprechen das Netzwerk vom lokalen Speicher (wo das Programm
liegt) aus über DR DOS-Aufrufe an die Netzwerk-Shell (NETx), die
im globalen Speicher liegt, an. Die Shell gibt den Aufruf an IPX
oder SPX weiter, die den Aufruf dann an das Netzwerk weitergeben.
Dieser Typ von Anwendungsprogrammen benötigt den Pufferverwalter
für Prozeßumschaltungen nicht, da die Weitergabe der Aufrufe vom lokalen
zum globalen Speicher zwischen dem Anwendungsprogramm und der Shell
auftritt.
Wenn ein Anwendungsprogramm (im lokalen Speicher), das auf IPX zugreift,
direkt mit dem Netzwerk kommunizieren möchte, setzt es einen direkten
Aufruf an IPX oder SPX (im globalen Speicher) unter Umgehung der
Shell ab. IPX oder SPX geben den Aufruf dann an das Netzwerk weiter.
Wird dann von dem Anwendungsprogramm auf ein anderes umgeschaltet,
verliert IPX oder SPX den Kontakt mit dem Programm und ist nicht
in der Lage, die Daten des Programms zu verwenden. Dieser Typ von
Anwendungsprogrammen benötigt den Pufferverwalter für Prozeßumschaltungen,
wenn das Programm in einer Umgebung mit Prozeßumschaltung ablaufen
soll.
Mit dem Pufferverwalter für Prozeßumschaltungen ruft das Anwendungsprogramm
(im lokalen Speicher) IPX auf. Der Aufruf wird jedoch vom
Pufferverwalter für Prozeßumschaltungen (im globalen Speicher) abgefangen
und an IPX oder SPX und dann an das Netzwerk weitergeleitet.
TBMI2 verwaltet einen Puffer im globalen Speicher, um
Aufrufe aus den verschiedenen lokalen Segmenten zu halten
und dann diesen Puffer auf die verschiedenen Sitzungen abzubilden,
wenn in diese umgeschaltet wird. TBMI2 (im globalen Speicher) erhält
auch ID-Informationen von TaskMAX, so daß es erkennt, welche Sitzung
die Aufrufe abgesetzt hat. Ohne TBMI2 kann aus dem Anwendungsprogramm
nicht auf ein anderes ohne die Gefahr eines Fehlers umgeschaltet werden.
Es besteht keine Notwendigkeit für die Verwendung von TBMI2
in DR DOS-Sitzungen, wenn Sie nicht zwischen Anwendungsprogrammen
umschalten müssen. Sie brauchen TBMI2 auch dann nicht, wenn
Ihre Anwendungsprogramme nicht direkt mit IPX kommunizieren.
Wenn Sie nicht sicher sind, ob Ihr Anwendungsprogramm direkte
Aufrufe an IPX absetzt, starten Sie TBMI2; es beeinflußt andere
Operationen in keiner Weise, außer daß es ein wenig Speicher
belegt. Nachdem das Anwendungsprogramm eine Zeit lang gelaufen ist,
geben Sie das Kommando TBMI2 /D ein und sehen sich den Wert an,
der mit dem Feld "Far Call Usage" verbunden ist. Dieser Wert gibt an,
wie oft TBMI2 tatsächlich Aufrufe abgesetzt hat. Ist der Wert gleich
Null, dann benutzt Ihr Anwendungsprogramm TBMI2 nicht; Sie können Ihr
Anwendungsprogramm also in Zukunft ohne TBMI2 sicher laufen lassen.
HINWEIS: Sie müssen IPX auf V3.02 aktualisieren, bevor Sie TBMI2
verwenden können.
TBMI2.COM
Dieses Programm stellt die Datenpuffer zur Verfügung, die
benötigt werden, um die Aufrufe eines in einer DR DOS-Sitzung
laufenden Anwendungsprogrammes an IPX und SPX zu virtualisieren.
Da diese Puffer angelegt werden müssen, bevor TaskMAX startet, muß
TBMI2 vor TaskMAX aufgerufen werden.
Es gibt folgende Kommandozeilenparameter:
/? oder /H Anzeigen von Hilfe- oder Benutzungsinformation.
/C=<dateiname> Laden von TBMI2 unter Verwendung dieser
Konfigurationsdatei.
Geben Sie z.B. "TBMI2 /C=TBMI2.CFG"
auf der Kommandozeile ein.
/D Anzeigen von Diagnoseinformationen und
aktuellen Belegungsgrenzen.
/I Anzeigen von Versionsinformationen.
/U Entfernen von TBMI2 aus dem Speicher nach
Beendigung von Windows.
Dieses Programm liest Konfigurations-Informationen aus einer
Konfigurationsdatei im aktuellen Verzeichnis. In jeder Zeile
der Konfigurationsdatei steht genau ein Parameter. Der Name der
Datei ist standardmäßig NET.CFG; ein anderer Name kann mit dem
Parameter /C in der Kommandozeile angegeben werden.
Es gibt folgende Parameter in der Konfigurationsdatei:
INT 64 Ist ähnlich zum Parameter der IPX-Konfiguration.
Gibt an, daß TBMI2 Interrupt-64h-Aufrufe an IPX
und SPX unterstützen soll. Sollte entweder auf
ON oder OFF gesetzt werden. Geben Sie z.B. die
Zeile "INT 64 = ON" in die Konfigurationsdatei
ein. Der Standardwert ist ON für maximale
Kompatibilität.
INT 7A Ist ähnlich zum Parameter der IPX-Konfiguration.
Gibt an, daß TBMI2 Interrupt-7Ah-Aufrufe an IPX
und SPX unterstützen soll. Sollte entweder auf
ON oder OFF gesetzt werden. Geben Sie z.B. die
Zeile "INT 7A = ON" in die Konfigurationsdatei
ein. Der Standardwert ist ON für maximale
Kompatibilität.
ECB COUNT Gibt an, wie viele nondata event control
blocks (ECBs) für die Benutzung durch DR DOS-
Programme, die Virtualisierung benötigen,
belegt werden. Diese ECBs gelten für die
meisten AES-Ereignisse. Wenn TBMI2 keine
weiteren nondata ECBs verfügbar hat, können
data ECBs belegt und verwendet werden.
Wenn keine ECBs aus der Menge der in TBMI2
angelegten ECBs belegt werden können, tritt
eine Fehlerbedingung ein, die einen Endekode
von FEh (oder -2) zurückliefert.
Der kleinste mögliche Wert für diesen Parameter
ist 10, der größte ist 255 und der Standardwert
ist 20. Geben Sie z.B. die Zeile "ECB COUNT = 20"
in die Konfigurationsdatei ein. Jeder angelegte
ECB belegt 52 Bytes Speicher; die 20 Standard-ECBs
benötigen also 1040 Bytes. Die maximale Anzahl
hängt auch vom verfügbaren Speicher ab. Die
Gesamtgröße aller ECBs muß kleiner als 64 KB sein,
wodurch die Anzahl der ECBs normalerweise auf unter
255 beschränkt wird. Verwenden Sie den
Kommandozeilenparameter /D, um sich die aktuellen
Werte anzusehen.
DATA ECB
COUNT Gibt an, wie viele data ECBs für die
Benutzung durch DR DOS-Programme, die
Virtualisierung benötigen, belegt werden.
Diese ECBs gelten für die meisten IPX- und
SPX-Sende-und-Empfangs-Pakete. Wenn ein nondata
ECB angefordert wird, und keiner zur Verfügung
steht, wird ein data ECB verwendet. Wenn keine
ECBs aus der Menge der in TBMI2 angelegten ECBs
belegt werden können, tritt eine Fehlerbedingung
ein, die einen Endekode von FEh (oder -2)
zurückliefert.
Der kleinste mögliche Wert für diesen Parameter
ist 10 und der Standardwert ist 60. Das theoretische
Maximum ist 255, aber die praktische Grenze liegt
bei 89. Geben Sie z.B. die Zeile "DATA ECB COUNT = 60"
in die Konfigurationsdatei ein. Jeder angelegte
data ECB belegt 628 Bytes Speicher; die 60 Standard-ECBs
benötigen also 37680 Bytes. Die maximale Anzahl
hängt auch vom verfügbaren Speicher ab. Die
Gesamtgröße aller ECBs muß kleiner als 64 KB sein,
wodurch die Anzahl der ECBs normalerweise auf unter
255 beschränkt wird. Verwenden Sie den
Kommandozeilenparameter /D, um sich die aktuellen
Werte anzusehen.
Verwendung von TBMI2
Sie starten TBMI2 folgendermaßen:
1. Starten Sie TBMI2 durch Eingabe von "TBMI2" auf der
Kommandozeile, gefolgt von den oben erwähnten optionalen
Kommandozeilenparametern.
2. Starten Sie das Programm TaskMAX wie gewohnt.
Fehlerbehebung in TBMI2
Wenn Sie Probleme feststellen, während Sie TBMI2 verwenden,
müssen Sie evtl. die TBMI2-Konfiguration auf Fehler prüfen.
Verwenden Sie den Kommandozeilenparameter /D, um sich
Diagnose-Informationen und aktuelle Belegungsgrenzen
anzusehen.
Prüfen Sie die mit "Max Buffers Used" verbundenen Werte,
die angeben, wieviele Puffer benutzt werden, und "Configured
Data ECBs", die angeben, wieviele verfügbar sind. Wenn
die Anzahl der benutzten Puffer nahe der Anzahl der verfügbaren
Puffer oder gleich dieser ist, sollten Sie die Anzahl der
verfügbaren Puffer mit den Parametern ECB COUNT und DATA ECB COUNT
in der Konfigurationsdatei erhöhen.
Wenn der "Unavail buffer count" einmal größer als Null ist, sollten
Sie ebenfalls die Anzahl der verfügbaren Puffer mit den Parametern
ECB COUNT und DATA ECB COUNT in der Konfigurationsdatei erhöhen.
Die Dienstprogramme COMCHECK und RCONSOLE verwenden zuviele Puffer
und können nicht mit TBMI2 verwendet werden.
###################################################################
--
<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
- Raw text -