10-APR-1990 00:10:05  - notes on FT_1 AMIMESS (aka AMIRTR)

1. Status: It works. Debugging code is in transition, some is conditionalized
	on DEBUG_LEVEL, some isn't. 

- Known bug in logical name translation. Do not mix real and logical node 
names - use one or the other throughout. Best to define RTR$NODE=node::task
for all links. Fix is known, just not in place. 

2. To use: 
	a) Install AMIRTR
	b) make sure GROUP GLOBALS exist for group under which it runs
	c) Define RTR$LOG_FILE=NL: (or some tt: or file)
	d) RUN it 
3. Single-node testing
	It is possible now to run two routers on a single node. Do step 2
	above for first router. For second:
	
	a) Install AMIRTR with another name (e.g., ALTRTR)
	b) create group globals for different group than in 2 above
	c) run ALTRTR/UIC=[gg,mmm] 

	d) define RTR$FOO (foo is fake node name) = node::ALTRTR, where 
		node is real local node. 
	e) send messages to FOO::taskname. The message will go to AMIRTR,
	which will open link to FOO::. However, by translating RTR$FOO, AMIRTR
	will realize the link really goes to DRAGON::ALTRTR (or whatever), and 
	open a link to that. Message now goes over decnet to ALTRTR, who does
	with it what is needed. When reply comes back, it comes addressed to 
	DRAGON::taskname, but with router of ALTRTR, thus completely reversing
	the path. 

	With this setup, anything addressed to DRAGON:: goes to AMIRTR by 
	default (or straigt to destination task), while anything for FOO::
	goes thru AMIRTR to ALTRTR and then out to destination. 

4. Debug Output
	If you send debug output to the same tt: that runs SENDER, be SURE
	to set the Delay parameter of sender to about 5 seconds. Do NOT 
	attempt to send both router's debug to the same tt! They get very 
	garbled, and result is useless. If you change RTR$LOG_FILE and/or
	RTR$DEBUG_FILE from NL: to TTx: between running AMIRTR and ALTRTR,
	you get one or the other debug. Or, define differently in the two
	group tables. 

	You need the delay in SENDER to allow the message to float around and 
	the router to produce it's full debug output. Otherwise, the READ
	statement from SENDER gets in the way, and the screen becomes very
	hard to read. 

	Those with windows would do well to use them! 

5. SENDER
	The SENDER.TSK in [MESSAGE] has been munged to work with AMIRTR
	type messaging. New commands:
	
	B (body) - set the body part of the message
	H (header) - set the header of the message
	S (send) - send the message
	P (pause) - STOP sender - use UNS SENDER to resume
	D (delay) - insert a n-second (you're asked) delay between sending
		the message and receiving any incomming. Gives other tasks
		a window to put output to the screen. 

	Bugs: In Header, you must use UPPER CASE, and you must change BOTH
		task name and node name - the <return> defaulting is broken. 
	
6. MSLOOP
	In [message]. This is a task to loop back TEXT messages to the sender.
	It works with any message type which is ALL text, but has only been 
	tested with type=39 (comment). If logical MSLOOP$LOG_FILE is defined,
	a copy of the message header and text are written to the specified
	device (file or TT:). If MSLOOP$LOG_FILE is *NOT* defined, I believe
	that any packet would be looped successfully. Could be fixed to 
	notice packet type and not print binary packets. 

7. MSSEND, MSRCVR
	In [MESSAGE]. Source and sink for messages. Basically, MSSEND is not
	too useful - use SENDER instead. MSRCVR is again intended for text
	packet contents. Might be useful. Coding examples, if nothing else. 

8. EFNs
	AMIRTR uses f90 as shutdown-request, f91 for event notification.
	MSLOOP uses f92, f93 in same way. Don't fool with f91 or f93. Set 
	f90 and/or f92 to kill off AMIRTR, MSLOOP respectively. 

9. PASUTIL usage:
	These all use P3UTIL, version last insert 20-SEP-1989. This is, I 
	believe, vanilla AMI P3UTIL. 

10. REBUILDING
	SENDER is OK to fool with. Re-compile/link others at your own risk, 
	as there is work-in-progress, especially in AMIRTR. I'd say the stuff
	in [DECNET] and [MESSAGE] is pretty stable, AMIRTR is definitely not. 

11. Futures:
	Other than fixing the DEBUG code, and a couple of other things, the
	control packet area needs work. Also, the DIRECTORY will become a
	separate task - possibly called from AMIRTR - rather than a procedure
	in AMIRTR itself. Main reason is I don't want to either hold up AMIRTR
	doing directory function *OR* complicate the control flow any more 
	than it	already is! 

	I see the directory function as a service accessed by messages - like
	any other. You send a message for a node::task pair (node may be 
	wildcarded), and you get back a message containing up to, say, 10 
	node::task pairs where the task was found. Implementation is via a 
	GIN$ subfunction. I don't want to keep a list of all tasks, because
	I don't want to sort out the 'illegal' ones (DCL, MCR..., etc.). 
	Might be possible to do a group or uic search, tho. As I recall the
	GIN subfunction is pretty general. 

	Have only scratched the surface of VMS implementation - much in my 
	head. However, this won't be too bad. As you can see, the majority
	of this stuff is vanilla Pascal, and I won't need any MACRO-32
	(sigh) to do the network links.