Pre-Installation Information

NJESERV Daemon

The njeServer or njeserv.exe runs as a daemon on the OS/2 server and implements the NJE protocol rules for a SNA LU0 peer connection (LU0: Logical Unit of type zero). The njeServer initializes and manages as many links as are configured and supported by the underlying hardware. The njeServer includes the code to complete the initial logon protocol with the peer NJE implementation. SYSIN or SYSOUT data objects are received or sent via client applications using the NJE API library. The TCP/IP transport layer allows communication between the njeServer and its clients. The njeServer supports up to seven transmitters and receivers for each of the stream types (SYSIN/SYSOUT) to each connected node.

Two implementations of the njeServer are available. One executes under OS/2 Version 2.1 or later using the Communication Manager/2 Version 1.1 or later and the TCP/IP basic package from IBM. The other implementation is available with EP/IX 2.1 or later.

		NJE API: A program library for implementing NJE client applications. The library provides the functions necessary to send or receive NJE API data streams, messages, or commands to/from the njeServer. The NJE API data objects are defined by the two header files njeapi.h and njeRecords.h.
		NJE Queue Files: Specially formatted SYSIN/SYSOUT files written to a spool directory and queued for processing by the queue manager. The format consists of header records in keyword-value format followed by user data.
		njeInitiator: The NJE client program for sending an NJE queue file to a node in the NJE network that is accessible via the njeServer. The NJE queue files can be created by shell scripts, user programs, or the njesend command. The njeInitiator receives its work from the queue manager (daemon).
		njeResponder: The NJE client program that receives NJE data objects from the njeServer. It is a daemon capable of serving any number of streams and nodes. The NJE data objects are converted into NJE queue files and queued for further processing using the facilities of the queue manager. The queues are configurable objects to the njeResponder and queue manager.
		njesend: The NJE end-user command for sending a job, output file, or any other data object to a destination node. njesend creates an NJE queue file and adds the file to a queue for processing. This is normally a queue served by the njeInitiator and associated with a particular destination.
		njePrint: An NJE daemon used to process NJE queue files of type SYSOUT. njePrint reformats the NJE queue files and either requeues the file as mail or sends the data to a command or shell script via a pipe for final disposition processing. A configuration file describes the operation to be performed by njePrint depending on a match of regular expressions with the most common NJE field values such as file type, destination node, class,... For some conversions you may use the njeconvert filter.
		njeconvert: An NJE command/filter for performing numerous conversions used to remap UNIX system files or NJE queue files. In particular, this filter is able to process objects formatted as NETDATA files (refer to VM/CMS sendfile command).
		njeCmd or njecmd.exe: An administrator command for issuing commands to the njeServer daemon.

The njeServer attempts to open a stream to the SNA software and initializes a TCP/IP port to accept client connections. As soon as the links are available and initialized, the NJE sign-on procedure is executed. The peer application with a node name higher in the EBCDIC collating sequence than the other application initiates the signon procedure. Once the sign-on procedure is successful, the transfer of NJE SYSOUT/SYSIN objects can begin. njeServer is designed to operate without assistance from the operator. If link failures are detected, the error condition is logged, and the link is drained and restarted.

The state of all SNA connection and TCP/IP clients can be inspected with the command njeCmd. This command is also used to drain or shut down the daemon. The same can be achieved using the kill command and the signals SIGTERM to drain, and SIGHUP or SIGINT to shut down. The drain procedure allows the completion of all active file transfers. If shut down is used, the njeServer terminates without delay.

The njeServer invokes the transmit function as soon as a client application (see njeInitiator(1M)) requests the transfer of a SYSOUT or SYSIN object to a specific NJE node connected to this njeServer. If the transmit function fails, the client application is informed to retry at a later time.

After the sign-on procedure is complete, the receive function may by activated by a peer node requesting a new stream to transfer a SYSIN/SYSOUT object. The stream allocation request is granted when a client application has an open TCP/IP connection ready to receive a NJE stream.

If the njeServer has no free stream available, the remote stream allocation request is rejected. If this condition is met, it is possible that the link appears to hang and no more files are received from remote nodes. This is particularly true for JES2 and RSCS since both of these NJE implementations stop transmitting data when a stream reject is received. The operator must restart the queue to reactivate the transmit function. This situation can be avoided when the number of streams are equal on both sides (a configuration option).

The njeServer accepts at any time nodal messages and commands. Messages and commands from a remote NJE node are forwarded to the client process that has an open path for the addressed destination node. In any case, a log entry is created.

Options

-C filename: File from which to read the configuration parameters. If the option is not coded, the configuration data is read from the /usr/var/nje/njeServer.cf file.

-d level: Provides additional debugging information. Level is an integer number greater or equal to zero. If the level is greater than zero, the default, the njeServer is running under the shell where the command is entered.

-h: Provides help information.

-l: Enable parallel writing of the log to the opened window.

---

Note - Scrolling in an OS/2 window is slow. If you have a lot of system activity, you degrade the performance of the NJE server with this option.

---

-L filename: Specifies the path and file to receive the log records. By default the log is written to stdout.

-t: Enables data tracing. This option should be used only for problem determination.

-T trace_file_name: A valid file name to receive the data trace.

Configuration Information

This section provides reference information on configuring your PROFS channel on the server and client end. It helps ensure that the parameters are configured correctly on the server and the client to permit email transactions:

		Install SIMS using the setup or setup-tty installation program. For details, refer to the Sun Internet Mail Server (SIMS) 3.2 Installation Guide.
		Check the box provided for installing SMCS during installation.
		Start the Administration Console on the mail server.
		In order to create an SMCS channel, click on the IMTA icon seen on the main Administration Console screen.
		For detailed information on each channel, refer to other relevant chapters in this manual (the Sun Messaging Connectivity Services PROFS Channel Configuration Guide).
		The entries marked in BOLD in the tables are important, and it is essential to make sure that these entries match both on the client as well as the server side.
		Pay particular attention to the entries marked with an asterisk. The asterisk indicates that the information you need to provide for these entries must be derived.

---

Note - If you are not sure what the value should be, you can retain the default values, if a default is provided.

---

NJE/PROFS Configuration

To configure a PROFS channel successfully the following parameters need to be addressed. TABLE A-1 lists the fields that need to match on the server and the client side. If your input does not match, the connection between the client and the server will fail.

TABLE  A-1   PROFS Required Matching Entries on the Server and the Client

Server-Side Entries	Client-Side Entries
NJE Server Port	Server TCP Port
NJE Host Name	Local Node
NJE Peer Name	Remote Node, Remote LU Name
LU Name	Local LU Name
NJE Buffer Size	NJE Buffer Size

TABLE A-2 and TABLE A-3 list the significance of the server and client parameters, their possible values, and examples. Parameters that need to match on both the server and client sides are shown in boldface type. They provides a worksheet to enable you to compile configuration information prior to beginning your installation session (that is the last column of the table is left blank so that you may fill in the parameter that applies to your configuration).

To use this worksheet, copy it and fill in each blank with the parameter specific to your site. When all pages are complete, use the information to configure each screen as presented by the Administration Console or the Client installation software.

TABLE  A-2   PROFS Server Configuration Parameters and Worksheet

Server-Side Parameters	Description	Example	Your Parameter
Restart Automatically	If selected, it starts the channel on SMCS startup. If you do not select this option, you have to manually start the channel from the Administration Console.	3	Indicate your setting in the provided checkbox: o
Retain Processed Messages	Messages are normally deleted from queues after they are handled. Checking this parameter keeps a copy of each message in the queue even after the message has been delivered. Since processed messages may be deleted every night, selecting this parameter helps preserve the messages to enable you to go back to them in order to troubleshoot any problems.	3	Indicate your setting in the provided checkbox: o
Lookup Addresses in Directory	If this parameter is checked, the addresses in messages processed by this channel will be looked up in the directory. Without the directory lookup facility all the messages must contain fully qualified SMCS addresses in order to be delivered.	3	Indicate your setting in the provided checkbox: o
Poll Interval (in minutes)	This indicates how often you want the MS-Mail client to check for messages. The value entered indicated in minutes.	1	Choose your poll interval from the pull down menu.
Alias User Name Format	This controls the format of the user name alias automatically generated when a new user is added to the directory. The rule is formed using strings and variables which represent name attributes stored in the directory. $g Given Name $i Initials $s Surname $q Generation Qualifier	$+1g&+7s	Fill in your response in the provided text field.
Header Style	The header styles control the placement of headers within a message; whether at the top or at the bottom. To view different values click on the box right next to the Header Styles label. The default style is All at Top, None at Bottom.	All at Top, None at Bottom	Choose your header style from the pull down menu.
Gateway Node	The gateway node indicates the name of the PROFS gateway node used by SMCS. THis must be added on the PROFS system.	Check with the PROFS system admin to find out the name of the post office	Fill in your response in the provided text field.
NJE host name	The NJE name for the virtual NJE node.	SUN1	Fill in your response in the provided text field.
NJE peer name	The NJE name for adjacent IBM system.	FAILUREA	Fill in your response in the provided text field.
NJE server name	The TCP/IP domain name for OS/2 system.	13.pclan.eng. alpha.com	Fill in your response in the provided text field.
NJE server port	The TCP port number that the OS/2 system is using to track NJE service requests.	5109	Fill in your response in the provided text field.
Directory Synchronization	None--This indicates that you do not want this channel to participate in any directory synchronization processes. Full--The very first time you create and configure a channel, choose this option to participate in a thorough, complete directory synchronization process. Since this is a comprehensive synchronization procedure, it is time consuming. Full Foreign--This option helps resynchronize channels apart from the current channel. For instance, though your MS-Mail channel may already be synchronized, your cc:Mail, NJE/PROFS, or ldap channels may not be. By choosing this option, the directory information for the other channels will also be synchronized. Incremental--After your channel participates in a full directory synchronization process, to register any subsequent directory changes, choose this option. It helps incorporate your directory changes and resynchronize the directory information.	Full	Indicate your directory synchronization choice from the pull down menu.
Client Address	Enter the client address. This will be of the form: user@node.channel.host	admin@node. channel.host	Fill in your response in the provided text field.
Propagation of New/Deleted Entries in Directory	When the directories are synchronized, both parameters specify how the propagation of new or deleted entries flow to and from the directory. To select an option, click on the box next to propagation label.	Bi-Directional	Choose to propagate new/deleted entries in the directory from the pull down menu. Retain the default values if you are unsure.
Propagation of Modified Entries in Directory	When the directories are synchronized, this parameters specifies how the propagation of modified entries flow to and from the directory.	To Central Directory	Choose to propagate modified entries in the directory from the pull down menu. To select an option, click on the box next to propagation label. Retain the default values if you are unsure.