Message record is defined in terms of the SENDER of the message. 
That is, Source_xxx is the sending task, and Destxxx fields reference
the receiving task. 

The ROUTER field *ALWAYS* contains the name of the task which actually
sent the message - either the router or the source task itself. The
Src_Task field always indicates the original sender. Thus, to reply
to a message, simply exchange the Src_Task/Src_Node pair with 
Dest_Task/Dest_Node, and send it back out. 

There are several ways to handle message size. First, one can set the 
Text_size field manually (to anything, essentially), and disable auto
size calculation by clearing the MSG_AUTO_SIZE flag in FLAGS. Function
MSSIZE will do a reasonable (never too small) size determination basis
the msg_id and Sub_id fields. For some - especially the STRxx - fields,
the actual size is calculated.

The Auto_size bit in FLAGS will, if set, cause MSSIZE to be called just
prior to each and every send directive. Although this is obviously an 
easy way to keep the size updated, it is relatively quite costly in terms
of overhead and speed. This feature should be used only after consideration
of the need and cost of doing so. 

.hl 1 LOGICAL ROUTING (FORWARDING) 
 
 Several features have been incorporated into the message system to support
re-direction (forwarding) of messages. These features are implemented using
logical names, and appear at both the user task and router levels. 
 Before delving into the gory details of these facilities, a brief functional
description may help. 
 Task_level forwarding is intended to allow an application to specify the 
destination task without knowing the node name, or the possibly special 
routing task to be used. For example, a network-wide event logger, which 
uses a routing task reserved for event and error logging messages. 
With task-level forwarding, a logical name is translated by the application
task, giving a destination node name and router task. Coupled with the 
destination task name, these three items specify the message routing. 
 Router-level forwarding is intended to allow logical redirection of an 
entire node's traffic to an alternate node. The obvious use of router
forwarding is for re-configuration following a node failure. It could
also be used to define 'pseudo-nodes', which would at runtime be 
translated into actual nodes. Router tasks translate destination node
names, yielding a possibly different destination node and the name of 
the router task at the destination.

.hl 2 Task Forwarding 
 When the user program calls MSINIT, that routine attempts to translate a 
'task' logical name. This logical is of the form 'MSG$tnam', where 'tnam' 
is the name of the destination task. Task forwarding is intended to allow
logical names to identify network-wide facilities.  For example, a net-wide
event logging task. This task, call it LOGGER, may run on any node in the
net, and collects and logs event messages from throughout the net. Programs
would be written to specify LOGGER as the destination task name, and would
not worry about the node. 
 The translation of MSG$LOGGER will be in the form 'node::task' - supplying
both the actual destination node and ROUTER task through which the message
should be sent. [ The node may be later redirected at the router level - 
see below. ] Continuing the example, MSG$LOGGER might translate into 
LOG::EVENTS. 
 When MSINIT successfully translates MSG$LOGGER, it has two task names and
one node name: the destination task name (LOGGER); the destination node
name from the logical translation (LOG::); and the router task name 
(EVENTS) also from the logical translation.  Note that the destination node
name supplied as a parameter to the MSINIT procedure is in this case 
overridden by the node from the logical name translation. 
 It is quite possible that the translated node name will be that of the 
local node. If so, the message does not require a router for delivery. 
MSINIT will thus copy the destination task name to the router task name,
and drop the router name. 
 If the local and destination node names differ, the translated router name
will be used as the immediate destination of the message (e.g., in the 
router task field). 
 Should the logical translation fail, or the subsequent translation not
be of the proper form, defaults will be used: For equal source and destination
nodes, the destination task name and router will be the same; for differing
nodes, the default router "AMIRTR" name will be used. 
.hl 2 Router Forwarding
 When a router task receives a message, it attempts to locate an active
network link to the destination node. Failing that, it compares the 
destination node name with list of known nodes. If no match is found, the
router attempts tranlation of a logical "RTR$node". This translation will
yield a node name, which is entered into the known node list along with the
destination node specified in the message header. Also, the translated node
name replaces the original one in the message header. Thus, the message no
longer references the 'pseudo-node', but now references the real node instead.
 The significance of this is that, should this message be returned by the
destination task (via a MSREPLY, for example), it will carry the actual
remote node name, not the 'pseudo-node'. If the originator contiues to 
use this message, most of the router address processing will be circumvented,
because the actual node name will be in the message, and will be found in 
the active link scan. 
 Router level forwarding thus provides a mechanism which is both extremely
flexible, and (used properly) highly efficient. Note that efficiency with
router level forwarding is only possible if a) it is not used (no logical
name defined); or b) the messages are continually re-used, so that
the translated node name is propagated and repeated translation and look-up
are avoided. 

.hl 2 Summary
 Together, the two forwarding techniquies allow considerable flexibility in 
handling destination task, node, and routing task assignments at runtime, 
rather than compile time. In addition, the user can always modify the message
header after (or instead of) MSINIT, allowing even greater flexibility. 
Rather than attempt to describe all the possibilities, and their 
ramifications, a summary of indended uses will be presented. 

 Establish the content of the message, especially the packet id, and 
sub-id, then call MSINIT, which will call MSLEN to get the actual 
in-use length. 

 If repeated traffic with another task is expected, dedicate a message to 
that task, to avoid the overhead of repeated initialization and forwarding. 
This is especially important if one or both methods of forwarding are in use. 

 Use task-level forwarding to locate services (tasks) on a node-independent,
network-wide basis. Task-level forwarding also allows various routing
schemes based upon task, group, or system logicals. This is also the only
automatic method of employing multiple router tasks on a given node. 
 
 Reserve router-level forwarding for either re-configuration or