So? Can OpenInsight 3.7 and the new LH NLM be used with a netware 5 server running pure IP? Some articles I've seen say that you can, others say you can't.

We are planning to run data access over a WAN, and the improvement in performance Pure IP will give us over IPX is very significant. It will also give us better performance over our proposed VPN.

Is the jLH package an absolute requirement in order for us to set this up?

Nick.

The direct answer is yes, the beta version of jLH v2.0 uses the tcp/ip protocol aad operates well with in the Novell 5.0 JVM, we have also conducted successful testing on JVM's in the following environments -

NT 4.0, Solaris, Linux (Red Hat 5.1).

Where the confusion may come from is that we only support the IPX/SPX protocol in the Revelation NLM version 5.0. This was decided to provide both our Arev and OI customers an upgrade path.

Please remember that only OI at the 3.7 level is now supported with jLH.

Also please note, the NT Service 2.0, now in beta provides both Named Pipes and TCP/IP support, DOS clients such as Arev will default to Named Pipes use, OI can use either.

Hereunder is some further discussion of the TCP/IP issue from and earlier thread -

Since there is no standard socket implementation available as part of DOS, we are unable to provide a version of the LH/TCPIP driver for Arev.

                  The support and certification of the Revelation NLM with IPX support assures that Arev users have an upgrade path.

                   There are three possible ways that Advanced Revelation and OpenInsight can utilize TCP/IP:

                  1. The Operating System file services (int 21h) can be mapped to a Network File System; in

                  these cases, the file I/O requests are handled by a VxD whose only job is to communicate the

                  request to (and the result from) a "file server". If the work-station is communicating with that

                  server via TCP/IP, then these I/O requests will be transmitted between the workstation and the

                  server (and potentially routers etc. in between) using the TCP/IP protocol. This is all "behind the

                  scenes" as the application (for example, the NPP using its "local mode") will not know or care

                  that these requests are being transmitted via TCP/IP.

                  2. Some higher-level communications protocols are not transport protocols, and therefore require

                  a lower-level protocol such as TCP/IP in order to communicate between two computers. In our

                  case, we see this when using Microsoft's proprietary Named Pipes protocol to communicate

                  between the NPP driver and the LH/NT Service. Again, this may use the TCP/IP protocol

                  "behind the scenes" and the driver neither knows or cares.

                  3. There is a standard Application Programming Interface for TCP/IP called sockets. (TCP/IP

                  itself is not a programming interface -- it is just a data transfer specification.) Sockets are a fairly

                  low-level means to use TCP/IP to communicate between (or among) processes and machines.

                  We do use the sockets API (called WinSock) from the new LH/TCPIP driver in order to

                  communicate with the new version of the LH/NT Service and the brand new jLH/Server. In this

                  case, the driver does know that it is using the TCP/IP protocol ... and it is using it as directly as is

                  possible. The WinSock API used by the LH/TCPIP driver is available as a standard part of all

                  contemporary versions of the Windows Operating Systems. Our Windows product, OpenInsight,

                  required slight (but very deep) modifications in order to use the LH/TCPIP driver due to the

                  architecture of the WinSock library. Unfortunately, we cannot easily port these changes back to

                  previous versions, so the LH/TCPIP driver will only work with OpenInsight vers

                  ions 3.7 and later. Furthermore, since there is no standard socket implementation available as part

                  of DOS, we are unable to provide a version of the LH/TCPIP driver for Arev.

                  Hope this helps

The questions previously posed are my questions too. And from the response I'm still confused (not trying to say that RevSoft aren't helpful).

I have a client running Novell 4.1 and planning migration to Novell 5.0. The site has LH.NLM v1.5 and is running OI 3.7 plus legacy AREV systems. OK I know I need to upgrade NLM for Novell 5.0 to protect my AREV investment till it is turned off. BUT ideally we want to jump to IP. Particularly we want to move OI to IP. What I here is that the updated NLM is still IPX and understand the AREV / DOS reasons for this. But wll the client ALSO have to invest in comperable JLH service to achieve OI on IP?

Regards

Richard Bright

View this thread on the forum...