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:
mfsdisp.exe(the message routing component of Jnet) must be installed on the bridge system.
mfsdisp.exeis 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.exeis provided in the file
JAN_ROOT:[lib]mfsdisp.for. A command file to rebuild
mfsdisp.exeis provided as
mfsdisp.forthat 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.
TO_NODEis 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
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.
mfsdisp.forby defining it as a character variable:
CHARACTER*8 SPECIAL_NODE /'NONJE'/
mfsdisp.forcan 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.forhas 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
Received:line back to the original userid from the file tag.
mfsdisp.exemust be rebuilt by running
mfsdisp.exehas 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.)
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
mfsdispshould be modified to consult some sort of database of systems reachable via PMDF.
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.