Quick tour
Online demonstration
Downloads
Frequently Asked Questions

   How does ComNet compare to ICE from Insession?
What's the difference between protocol encapsulation and protocol conversion?
How long does it take to install ComNet?
What do you mean by a loopback capability?
How can ComNet convert communications protocols without actually using physical communications ports?
How would ComNet be used to provide TCP/IP capability to our legacy application which is running X25?
We're a Base24 site; how could ComNet be of benefit to us?
Why would I use ComNet to provide comm's handling for our application when our application already has this, or can be licensed from the application's vendor?
We are updating our application to use TCP/IP as a standard comm's protocol but we still have many devices using legacy protocols such as SNA, X.25, etc. Why should we consider ComNet, which is a software protocol conversion solution, instead of the many hardware protocol converters which are available?
Is ComNet efficient?

How does ComNet compare to ICE from Insession?
ComNet and ICE have some overlap in terms of 'connecting' legacy and TCP/IP protocols; however, each has a very different approach.

ICE accomplishes this by using protocol encapsulation. For example, ICE offers product components such as ICE DLSw and ICE XOT which enable you to use SNA and X25 sessions (respectively) over the top of an IP backbone. Furthermore, these ICE components are very specific in offering X25 and SNA over IP; no other combination is possible.

ComNet accomplishes this by using protocol conversion. This means that one protocol is actually terminated and truly converted into the new protocol, which is then used to deliver messages to the destination. ComNet offers an any-to-any supported protocol conversion configuration.


What's the difference between protocol encapsulation and protocol conversion?
Protocol Encapsulation means that you are transmitting one protocol over the top of another; typically a legacy protocol, such as SNA or X25, over an IP network. This means that all the legacy protocol's header information and protocol handling is still being performed, in addition to the underlying IP protocol. Apart from being less efficient than protocol conversion, any investment in this approach only increases your investment in legacy-related communications.

Protocol Conversion means that one protocol is actually terminated and truly converted before messages are forwarded. This is the approach taken by ComNet. The benefits of protocol conversion are that it is more efficient and that your investment in this approach is directed toward true migration toward TCP/IP.


How long does it take to install ComNet?
ComNet is very easy to set up. You define your Session(s) in a text configuration file and then start ComNet, or warmboot it if it's already running.

Sample configuration files are provided to make this even easier.

Here is a sample configuration of a Session called "Sess001" which defines an X25 connection being converted to TCP/IP:

SESSION Sess001 (
         X25  (
               SU $x25e.#su001
               SVC WAIT
               )

    TCP  (
          POLARITY client
          LOCAL 1450
          REMOTE 132.33.128.12:3722
          )
    )

We would expect that any competent technical person could download and install ComNet easily within the hour.

What do you mean by a loopback capability?
A loopback simply means the capability of connecting one connection to another without actually having to transmit across an actual network. Some protocols and subsystems support this in software (such as the inbuilt TCP/IP loopback at 127.0.0.1); or in hardware, such as using a modem eliminator which is a device which connects 2 physical communications ports.

ComNet provides loopback capability by providing communications Access Method emulation.

ComNet goes further than conventional loopback capability (in which both protocols must be the same) because it can provide a loopback connection between any 2 supported protocols. For example, you may want to prototype a connection between an X25 enabled application and a TCP/IP enabled application. ComNet can provide the X25 to TCP connection without the need for any physical communication ports or connections.

Click here for more information.

How can ComNet convert communications protocols without actually using physical communications ports?
This is accomplished by Access Method emulation.

For example, a ComNet session can be configured to appear as an X25 subdevice. Let's say we name this subdevice within ComNet as #SU23, and the ComNet process name is $CNET. Your application would therefore open $CNET.#SU23 and it would find that this connection would respond in a compatible manner to X25AM.
Note: ComNet allows any combination of connection types to be configured within a ComNet process; whether they use real communications or perform Access Method emulation.

How would ComNet be used to provide TCP/IP capability to our legacy application which is running X25?
You could do this in two ways:
  1. You could configure ComNet for X25AM Access Method emulation to receive messages from your application. ComNet would then forward these messages to a configured TCP/IP connection.
  2. You could connect your application's current X25 port to a modem eliminator which would be connected to another X25 port which is configured under ComNet. ComNet would then perform real X25 communication with your application and forward messages to a configured TCP/IP connection.
We're a Base24 site; how could ComNet be of benefit to us?
ComNet can be used to provide additional protocols (or substitute existing ones) for your Base24 application.

For example, if you wanted to provide TCP/IP communications for your Base24 application, you could use one of your existing protocols to connect to ComNet, and ComNet would provide the TCP/IP handling.

We are also able to provide you with a Base24 CTS interface to ComNet upon request.

You may ask "Why use ComNet to provide protocol handling instead of just licensing the protocol from the Base24 vendor?". There are several reasons: To begin with, ComNet is significantly lower cost. Another reason is that you may have a short term/temporary need for a protocol which you don't have a license for under Base24. Other reasons are that ComNet provides other benefits, such as backup connection rotaries for high session availability and loopback capabilities.

Why would I use ComNet to provide comm's handling for our application when our application already has this, or can be licensed from the application's vendor?
You should consider at least these factors:
  • Is cost a factor?
    Some applications may support the protocol you need but can be unreasonably expensive. ComNet provides a fast, reliable and cost-effective alternative.

  • Is timing a factor?
    You may need additional protocol handlers or converters for a short time only; such as for a migration or stress test. Some vendors may not be able to provide you with this short term capability or at a reasonable cost. ComNet can be leased for as short as one month.

  • Is high availability important?
    ComNet supports backup connections. This means that if a connection fails, it will automatically reconnect on another port defined in a rotary. ComNet also supports alternate rotaries; which means that you can separately configure connections to an alternate site. In the event of a site failure, ComNet will then automatically switch to the alternate rotary which will route communications to the alternate site.

  • Is systems management important?
    The ComNet user interface provides you with a single system-wide view of all sessions configured under it. Detailed status, statistics and control capability is provided. Dynamic configuration is also supported.


We are updating our application to use TCP/IP as a standard comm's protocol but we still have many legacy devices using protocols such as SNA, X.25, etc. Why should we consider ComNet, which is a software protocol conversion solution, instead of the many hardware protocol converters which are available?
There are many important considerations here:
  • Protect your investment
    The fact that you are currently supporting your legacy devices on your NonStop platform means that you have already invested in proven, first class, fault-tolerant hardware (the NonStop hardware). Why throw this away and spend a considerable amount of money in replacement hardware whose only purpose is to support legacy devices/protocols? In other words, what you're really doing is unnecessarily increasing your investment in additional legacy hardware.

    ComNet is very cost-effective and can be licensed on a short term or long term basis.

  • Hardware integrity
    If you introduce new hardware into your infrastructure or network, do you really know how reliable it will be in your implementation?

    ComNet does not require you to make changes to your legacy hardware configuration.

  • Installation, Maintenance and Service costs
    If you were to install a hardware protocol converter at each device, how much would it cost? What would be the ongoing maintenance and support costs of this remote hardware?

    If you were to install an array of protocol conversion hardware in your computer room, what would this involve? Would this mean numerous networked racks of PC's and protocol cards? What would it cost to install, service and maintain such a configuration?

    ComNet is fast, easy and inexpensive to install and maintain.

  • Backout options
    After you install your hardware protocol conversion option, how difficult would it be if for some reason you had to back out? What would this cost in terms of time, labour and outage?

    ComNet provides a software solution and supports dynamic configuration. There should have been no physical configuration changes to your legacy communications infrastructure needed when you installed ComNet.

  • Manageability
    What level of online status, management and control is provided with the hardware protocol conversion implementation? Hardware protocol converters installed at each device may be difficult to monitor or control. A hardware protocol conversion infrastructure of networked PC's may not provide you with a single system-wide view to the operator; you may need to separately logon to several different subsystems in order to query or control all of your hardware protocol converters.

    ComNet provides a single, seamless, system-wide view and control of all its sessions, regardless of the number of protocol conversion processes it is running. ComNet also maintains statistics and connection information for all of its sessions.

  • Fail-over processing
    Will the hardware protocol conversion implementation support some form of fail-over connection processing? For example, if a node at your application fails, will the affected sessions be re-established to another node?

    ComNet offers connection rotaries. If a connection fails then ComNet will attempt to re-establish the session on another connection. ComNet also offers an Alternate rotary configuration such that if all connections on a rotary fail (say, due to a site failure), then ComNet can switch to another site using the Alternate rotary (either automatically or manually).

Click here for further information on using ComNet for migration support.

Is ComNet efficient?
ComNet is being introduced into the message path and so this does consume some processing time and resources; however, this is usually a small portion of the overall transaction cost and may not be noticeable. This does not account for any additional processing performed by communications Access Methods.

If, however, you are using ComNet to emulate an Access Method (appear as a communications port to your application), then you may find that ComNet is faster and more efficient than the Access Method it is emulating. This is because ComNet does not need to do any of the actual protocol handling which an Access Method must do with a physical communications port.