You may find yourself in the situation
where you have a DOS Scanner talking happily to a set of DOS client
machines, and merely want to add a Windows client to this system.
This is not an easy thing to do and may not even be possible at
all, depending on your network architecture. Typically, networked
Citect for DOS systems use IPX based datagram communications.
Citect for Windows however uses a NetBIOS session based method.
Therefore to connect a Windows client you have to install a NetBIOS
interface on your Scanner. This can be achieved in two ways. You
can switch all your DOS client machines to NetBEUI, establish
NETBEUI (remove IPX) on the Scanner and therefore run your network
over one protocol only. This may not be suitable for some network
systems, as NetBEUI is not routable. The other option is to install
the Novell NetBIOS emulator on the scanner to allow the Windows
client to talk it using NetBIOS over IPX. This is fraught with
peril as the emulator is considered extremely flaky under load,
frequently giving rise to abnormal end events. The previously
mentioned "AbEnd" message indicates just this sort of problem. The
trick here is not to mix network products too much. Loading IPX
alongside NetBEUI on the Scanner just doesn't seem to work. They
appear to tread on each other's toes somehow and the combination
just doesn't agree with the Scanner. Running the Scanner under
Windows offers reasonable performance in some circumstances but
also seems unreliable.
Also, when you define the units in the Citect for Windows
project, ensure the Port field is left blank for IO devices which
are derived from the Scanner. If the ports field is not blank then
Citect will assume that the I/O Server is a Windows I/O Server.
Citect will try to find this Windows I/O Server and when it cannot
be found you will get the hardware error '<name> NetBIOS
server name not found'.
In general, it would be preferable to use a Citect for Windows
IO Server to service both your Windows and your DOS clients.
|