An NJE network provides a flat, closed namespace within which every system on the network must know how to reach every other. This presents problems when systems that are not running NJE must be accommodated. When large external networks are involved true gateway facilities must be used to reach them. Using PMDF to provide and access such facilities is described in subsequent sections of this document.

However, if only a few non-NJE systems are to be made accessible to the NJE world, it is possible to actually enter these systems into the NJE namespace even though they are not running an implementation of NJE. PMDF then acts as the routing element that takes messages from NJE and routes them to the non-NJE systems. The non-NJE systems can be any type of system with which PMDF is capable of communicating.

This trick depends on modifying Jnet's internal router and only provides mail access (sending files and interactive messages is not possible), so it is not a complete substitute for actually connecting systems directly to NJE. This technique is not applicable to ANJE.

The following steps must be taken to provide a route from the NJE network to a non-NJE system:

1. The non-NJE system must be established in the routing tables of ALL the systems on the NJE network. Messages to the non-NJE system should be routed to the system running both Jnet and PMDF that is going to act as the bridge between NJE and whatever network the non-NJE system uses.
2. A modified version of mfsdisp.exe (the message routing component of Jnet) must be installed on the bridge system. mfsdisp.exe is invoked when a system name is encountered that does not correspond to a known route or link. This module is intended to be customizable, so FORTRAN source for mfsdisp.exe is provided in the file JAN_ROOT:[lib]mfsdisp.for . A command file to rebuild mfsdisp.exe is provided as JAN_ROOT:[lib]buildmfsdisp.com .
   The portion of mfsdisp.for that must be modified is the legality check for the destination system name. In Jnet 3.2 the code for this check is:

   ! Check to see if it was for this site or this cluster ELSEIF ((HOST .NE. TO_NODE) .AND. (CLUSTER .NE. TO_NODE)) THEN RECEIVE = .TRUE. RECEIVE_USER = DEAD_USER NOTIFY = .FALSE.

   This essentially says that if the destination system TO_NODE is unknown the message is sent to DEAD_USER (usually the local postmaster). This check must be modified to accommodate the non-NJE system as a legal local system. For example, suppose the name of the non-NJE system is placed in the CHARACTER*8 variable SPECIAL_NODE. Then the check could be modified to read:

   ! Check to see if it was for this site or this cluster ELSEIF ((HOST .NE. TO_NODE) .AND. 1 (CLUSTER .NE. TO_NODE) .AND. 2 (SPECIAL_NODE .NE. TO_NODE)) THEN RECEIVE = .TRUE. RECEIVE_USER = DEAD_USER NOTIFY = .FALSE.

   Note that the continuation lines must begin with tabs and not with spaces. Be sure to incorporate a value for SPECIAL_NODE into mfsdisp.for by defining it as a character variable:

   CHARACTER*8 SPECIAL_NODE /'NONJE'/

   Here NONJE is, of course, the name the non-NJE system is known by in the NJE world.
   An additional change to mfsdisp.for can be necessary if the system being added supports usernames longer than 8 characters. Jnet will expand usernames in the message envelope using the local host's system authorization file unless you tell it not to. This can be avoided by adding code such as the following to mfsdisp.for . This code should be inserted after the point where mfsdisp.for has decided to handle the file as a mail message:

   ! Try to get just the first 8 char user_id on ! the received line so that PMDF will use the ! original ID as the envelope passed to the ! remote system for the pseudo BITNET host hack. IF ((SPECIAL_NODE .EQ. TO_NODE) THEN USERNAME = TO_USER END_IF

   This code resets the expanded username to be used in the Received: line back to the original userid from the file tag.
   Once the modifications are made, mfsdisp.exe must be rebuilt by running buildmfsdisp.com . After mfsdisp.exe has been rebuilt, it must be activated by shutting down and restarting the local Jnet server. (This is described in the section above on installing PMDF's local mail delivery agent.)
   Note that this example only shows a very simplistic way to add a single system to mfsdisp . This technique is only suitable for adding a limited number of systems. If a lot of systems are to be attached in this manner mfsdisp should be modified to consult some sort of database of systems reachable via PMDF.

3. PMDF's local mail delivery agent will now be activated to process messages sent to the non-NJE system. The name used by NJE for this system must be defined in PMDF's configuration file. Note that since dotted domain names are not supported by NJE, the name must be a simple dotless shortform name. Of course, PMDF's configuration file can map the shortform name into a full domain name if desired.
4. At this point it should be possible to send messages from the NJE network to the non-NJE system. In order for these messages to be repliable the non-NJE system must be configured to forward all messages headed to the NJE network to the bridge system. The manner in which this is done will depend on the type of non-NJE system involved.

It should be emphasized once again that this trick of placing non-NJE systems within the NJE namespace does not provide full NJE functionality, nor does it provide the expandability that a true gateway should provide. However, this technique can prove useful when only small heterogeneous networks are involved.