From:	BI1::JEH          "Jamie Hanrahan"  2-FEB-1989 15:33
To:	VN%"system@infopiz.UUCP",JEH         
Subj:	RE: Miscelaneous UUCP User/Administrator Programs

> 	UUNAME.C	- Implements Unix UUNAME functionality for VMSNET
> 			  i.e. names either the local system, and/or it's 
> 			  immediate neighbors.  This program should optionally
> 			  be installed to allow the general user this 
> 			  functionality, based on a particular site's desires.

I don't really understand the point of this.  

> 	UULOG.C		- Implements the Unix UULOG stuff for VMSNET
> 			  i.e. selectively displays parts of the log file
> 			  based on either or specific usernames, or hosts.
> 			  UUCP administrator program only, do not install.

One of the reasons I fiddled with the logfile format was to make it possible
use lowly old SEARCH for this (and to make it easier for humans to read).  
Here's a sample:

p:uucp -- h:-       [02/02-11:31:34-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-11:46:35-0000010f]   Waiting        (15 minutes) u:-       
p:uucp ?> h:infopiz [02/02-11:56:54-0000010f] * Port busy      (ttb1:) u:-       
p:uucp ?> h:infopiz [02/02-11:56:54-0000010f] * No ports       (ACU) u:-       
p:uucp -- h:-       [02/02-11:56:55-0000010f]   Waiting        (15 minutes) u:-       
p:uucp ?> h:infopiz [02/02-12:04:48-0000010f]   Calling on     (ttb1:) u:-       
p:uucp => h:infopiz [02/02-12:05:12-0000010f]   Dialed         (ttb1: 2400) u:-       
p:uucp => h:infopiz [02/02-12:05:19-0000010f]   Login ok       (ttb1: 2400) u:-       
p:uucp => h:infopiz [02/02-12:05:39-0000010f]   Startup ok     (g) u:-       
p:uucp >> h:infopiz [02/02-12:05:40-0000010f]   We want to send (S D.simpactA0279 D.simpactA0279 jeh - D.simpactA0279 0666 ) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:03-0000010f]   File sent ok   (1473 bytes, 21 secs) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:04-0000010f]   We want to send (S B.simpactA0279 X.simpactA0279 jeh - B.simpactA0279 0666 ) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:08-0000010f]   File sent ok   (61 bytes, 3 secs) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:08-0000010f]   We want to send (S D.simpactA0280 D.simpactA0280 jeh - D.simpactA0280 0666 ) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:17-0000010f]   File sent ok   (392 bytes, 7 secs) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:17-0000010f]   We want to send (S B.simpactA0280 X.simpactA0280 jeh - B.simpactA0280 0666 ) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:21-0000010f]   File sent ok   (61 bytes, 2 secs) u:jeh     
p:uucp >> h:infopiz [02/02-12:06:25-0000010f]   End of call    (complete) u:jeh     
p:uucp -- h:-       [02/02-12:06:31-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-12:21:34-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-12:36:36-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-12:51:38-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-13:06:40-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-13:21:42-0000010f]   Waiting        (15 minutes) u:-       
p:uucp    h:-       [02/02-13:23:06-00000208]  STARTUP         (Version simpact-1.30) u:-       
p:uucp -< h:-       [02/02-13:23:07-00000208]   Incoming       (_VTA66:) u:-       
p:uucp -< h:infopiz [02/02-13:23:08-00000208]   Call from      (infopiz) u:-       
p:uucp << h:infopiz [02/02-13:23:11-00000208]   Startup ok     (g) u:-       
p:uucp << h:infopiz [02/02-13:23:14-00000208]   They want to send (S D.infopizA0508 D.infopizA0508 system - D.infopizA0508 0666) u:system  
p:uucp << h:infopiz [02/02-13:23:29-00000208]   File rcvd ok   (1178 bytes, 14 secs) u:system  
p:uucp << h:infopiz [02/02-13:23:30-00000208]   They want to send (S B.infopizA0508 X.infopizA0508 system - B.infopizA0508 0666) u:system  
p:uucp << h:infopiz [02/02-13:23:34-00000208]   File rcvd ok   (63 bytes, 3 secs) u:system  
p:uucp << h:infopiz [02/02-13:23:35-00000208]   Uuxqt started  () u:system  
p:uucp << h:infopiz [02/02-13:23:39-00000208]   End of call    (complete) u:system  
p:uxqt ?< h:-       [02/02-13:23:40-0000020e]  STARTUP         (Version simpact-1.30) u:-       
p:uxqt =< h:infopiz [02/02-13:23:43-0000020e]   Rmail          (jeh) u:-       
p:uxqt << h:infopiz [02/02-13:23:43-0000020e]   Executing      (rmail jeh < vmsnet_spool:D.infopiz_A0508 > NL:) u:-       
p:uxqt ?< h:-       [02/02-13:23:54-0000020e]   No more work   (hibernating) u:-       
p:uucp -- h:-       [02/02-13:36:44-0000010f]   Waiting        (15 minutes) u:-       
p:uucp -- h:-       [02/02-13:51:50-0000010f]   Waiting        (15 minutes) u:-       

"p:", "h:", and "u:" stand for program, host, and user; these prefixes make
it possible to search for "h:infopiz" and just catch entries where infopiz
was the host name, and not get matches where "infopiz" shows up, say, in a 
filename.  I really liked your "=>", etc., codes, and copied them into the
log file, with slightly changed meanings.  The first character is always
the state (? means looking for work, - means dialing, = means login and 
protocol startup, < or > means protocol running), and the second character is 
always the direction of the call; if you are interested in inbound calls
(only) from putz you can search for "< h:putz".  I reversed the meanings of
- and < because when an inbound call is up and running (which is the 
state it's in most of the time), it looks better to see the procname as
me << host instead of me -< host.  I got rid of the "error" indication
(formerly ?) because it's so transient -- you'd never see it in a process
name, it'd be changed to something else right away.  

Similarly, the time-and-pid string is bounded by square brackets, because
nothing else in the log file is bounded by square brackets, and this makes
searches for pid "10E]" unambiguous without having to type the eight-character
PID.  

The "*" between the pid and the text is an error indication.  A 
search for " * " will pull out all error messages.  Searching for
" * ","< h:infopiz"/match=and will get all error messages associated with
inbound calls from infopiz, and " * ","10e]"/match=and, all error messages
associated with a particular process on your machine (useful for finding
everything written by the local uucp daemon, ie all outbound calls).  
Hmm, maybe another character identifying log messages written by the daemon
would be a good idea.  

All of this lets me get rid of a lot of text.  We no longer have to say "failed
outbound", because "outbound" is denoted by the ">" and "failed" by the "*",
so the text can just say WHY it failed.  Unless you're interested in the 
S and R command contents or in usernames an 80-column display tells you
everything you need to know about what's been happening.  

I've also needed to look for everything written after a particular date/time
(when I start testing a new version); search does it with

	SEARCH file "02/01-10:25" /window=(0,99999)

There is obviously a limit to what you can do with SEARCH but so far this has 
really proved helpful to me, and I've needed to look at the logs a lot more 
than the typical system manager ever will.  

I also changed some of the messages to be more meaningful.  e.g., when the
old log said "REQUEST" vs. "REQUESTED", it is far from obvious which message
is sent in slave mode and which in master, and unless you know how to interpret
the S and R commands it's not apparent which way the file's going either.  
(An S can mean one direction or the other, depending on who is master!)
So instead I write "We want to send", "They want to send", "We want to 
receive", or "They want to receive", as shown above.  Clear and unambiguous.  

> 	UUMISC.NEW	- New routine 'verify_system' which does just that
> 			  to determine if a particular system exists in
> 			  the systems file.

I did that too, and use it when the system file is read for incoming calls.
There are now several separate routines, open_sysfile, get_sysentry (gets
the next entry, dealing with all the continuation line stuff, and parses 
it to boot), close_sysfile, and find_sysentry (which calls open and then
calls get repeatedly until it finds a match).  Get_sysentry is now being
broken up so that it in turn calls get_entry - which is also called by
get_dialerentry.  

I'm quoting all these names from memory, they might not be exactly right. 

> 	SYSDEP.NEW	- New routines 'getredirection' and 'getopt' which
> 			  are used by these commands and others which are
> 			  still to come.
> NOTE:	I have extended the routine 'getredirection' to also handle command
> 	line style "UNIX pipes".  This works well for 'filter' type of programs
> 	(i.e. those that take input from standard in, and write to standard
> 	out).  Only the 'early' 'commands' in the pipe chain need to call
> 	this routine for things to work; for example:

I really like the piping stuff!  Did I understand you to say that it
would work for an indefinitely long series of commands, given only that
the FIRST command's image knows about piping?!?  (If not, it seems possible 
to do.)  Did you consider that you could write a trivial program (called pipe, 
for instance) which does nothing but copy its input to its output, but which 
understands piping, and then use it apply piping to ANY foreign command, 
whether or not those commands had the redirection/piping stuff in them?  
as in

	pipe <infile | prog1 | prog 2 ...

Fantastic -- we could even pull the redirection stuff out of compress!  

Speaking of which, why is wildcard expansion turned off when you use
redirection for compress's input?

--------------------

Since you are working on outbound news forwarding, let me describe the
correct order of things.  You probably know this already.

	1.  Create the B. and D. files as temp files, and close them.
	2.  Rename them  to B.x and D.x.
	3.  Create the C. file as a temp file, and close it.
	4.  Rename it to C.x.

The point is that we want to take no chances of gnuucp finding the C file
before everything else is done.  Obvious, right?  I didn't get it right
the first time...

Make sure that case is consistent between the S line in the C file 
and the contents of the B file.  The file name letter should be 
upper case, the system name in lower, the priority letter in upper,
and the uniquifier is of course digits.  I suppose that later we might
want to make the uniquifier a digit/hex string, a la HoneyDanBer.  

--------------------

We don't need to write a DECnet object to collect stuff written to
VMSNET_REQUESTS.  The other nodes can simply define VMSNET_REQUESTS
like this:

	$ DEFINE/etc. VMSNET_REQUESTS uucp_node::VMSNET_REQUESTS:

The mailbox is a shareable device and world writable, after all, so 
FAL has no problems writing to it!  

--------------------

Yes, I'm doing the script-file-driven dialer.  Why?  And why all these
other changes when I'm supposed to be working on windows?  Because I 
got VERY damn frustrated trying to do windowing when I wasn't all that 
comfortable with C.  So I tore into the code, making lots of seemingly 
trivial enhancements, and also changing it so that it made more sense 
to me (for instance, all extern variables have their first letter 
uppercased; things read from the controlfile are called Ctl_xxx, ....) , 
and then made it all work again, partly to make the code easier to deal 
with and partly as a learning exercise.  

I'm now to the point where I can write moderately complex stuff (involving, 
among other things, an array of structs each of which included a pointer to char

	(did you know that, in VAX C V2.3, you have to say things like

	struct structtype structname={ ... &"string" ... } 

	when initializing that pointer?  Otherwise the compiler stores the 
	string itself in the struct!  Doubleplus ungood!)

, and a struct containing a pointer to a function, and it works on maybe the 
second try after I get rid of the syntax errors.  AND, because of my naming 
conventions, it doesn't break other parts of the code either (something that 
was a real problem before).  

Now I'm doing the dialer, 'cause it's kind of like a little tiny protocol 
package, and I can test it without depending on other systems, and anyway 
I've gotten about eight requests for enhancments to the dialer.  (You can't 
see CD on LAT ports, for example...)  When that's done -- another day or 
two -- I'll look at windowing again.  

It is still not a shining example of C code.  For example, I got a book 
called "C Traps and Pitfalls", and learned that for every "extern int" we 
oughta have an "int" -- according to standard C, "extern int" allocates no 
storage.  Works fine in VAX C, but...  I also want to go through and make
typedefs for all the things like channel numbers and VMS status codes and
etc. that we're blithely storing in shorts and longs, and write function
prototypes for everything, so the compiler can do a better job of catching
mismatches.  

But all of THAT will wait until after the next release.  I promise.  

	--- Jamie