Cons up a GC'er for areas.  Need to reclaim string space etc...
queue dir in particular gets big.

don't let various header-relevant commands work if header is being
quoted?

implement tenex style of queueing, ie store info in directory, but
store text on user's directory (or COM)?

new option for recipient, wherein he gets a "TO:" field including
his name on every message (or at least most). Perhaps this should
just be something saying, "use tenex-style header".

renew efforts at user-interface to NAMES, via qmail.

have qsend CLI directly.

Want a bit in OPTION var such that system will kill job (and
thus free any locked switches) when hit by a top-level fatal
class 1 interrupt; all class 2 can be enabled and shunted off
into error handler, but class 1 will leave corpse helpless in
system, with locked switch so that no more comsats get started.
Parity error in job is probably main danger.

Need to re-do the file opening stuff, error recovery is still
sadly kludgy. (eg have lost on file-locked for mail file)
  Perhaps distinction should be on scale of
permanentness, i.e. assign number to each code indicating
tmemporary or permanent or something in between.

Think about making some pages pure, advantages are
protection against accidental buggy write, and improved swapping?

Have macro in comsat for simple message sending, especially to
maintainer, of form:
	BUGMSG [NASA-Houston][..like FWRITE stuff...]
or
	SNDMSG [recipient][fwrite-style msg]
Probably should limit to local mail only.  But if equivalence out to
other sites?  Sigh. Want to be able to send such msgs in
middle of sending something else.  Probably need several classes of
routines.

**improve SCAN.  Hack output and input specifying, also try to restore
breaktable routines and dispatch sets.

  Make COMSAT routines use breaktable scheme on input.
  Can then more easily analyze internal text

    Get info out of network input.  Use when possible to condense notifications,
    or optionally store in condensed form.

    hack MAILA?

*hack up general string matcher with various options, primarily
for use in host-name matching but hopefully more general.
  Use string-matcher for HSTNIC stuff in QMAIL, TELNET, COMSAT, FTPU, FTPS.
  Code in FAIL for benefit of FTPU/FTPS.  Implement therein.

*Options for condensation of CLI info?  Possible elimination of mail-write for
some cases? RMS wants MAIL TO FOO@BAR at <time> FAILD: <returned err msg>
<text of msg>...
***QSEND: if recipient not online locally, THEN hack the EQV-list for sending.
If online anywhere, simply send. If not online anywhere, give error msg unless
send-or-mail option specified; in this case hack EQV-list and mail as for normal msg.
Option of send-and-mail would do second step regardless of outcome of first.
	Problems: if sending and mailing, person gets both sent msg and
notification of mail arrival.  Want to suppress notification.
Current "fix": SENDs to everything including psuedonames and expanded list.

Option to force ordering of rcpts in header?

Consider more general search UUO (for list hacking) where some
nodes are specified, some wild-carded, and one value (or list of values) asked
for.

Consider standard mode of area to be q-reg like? keep count and ptrs etc; might
be better than to have string-vals in list.  Or can have various strings not
on any list but using stringspace like SAIL routines do.

Change receipt options for duration of login session, perhaps via :SEND?

----------------
Think about PLAN, REMIND adaptation.  Also .MSGS.

allow erroroneous msgsg to be alt-I'd easily, perhaps have special error file,
perhaps have OUTGO.MSG file...

*stuff more info into HSTINF?

*Set up storage data base for message ID's (preliminary will have
PLANs and REMINDers and outbound-net-mail loops stoppers.)

would be nice to do error hacking without worrying about the
PDL.  currently no good way of jumping out, or returning
errors (skipping is a little painful) with automatic restoration of
registers to right values.  perhaps implement some special
calls (macros or UUOS) which interface between levels of routines...
If PL/1 can do it etc.  (Moon sez is possible, but still think CATCH and
THROW are pretty bulky to use)

have qmail do the
update requesting to the comsat, which eats request file and
makes necessary changes to binary... should have ascii/
binary equivalents and format conversion routines.  
QMAIL should understand binary format
of equivalence file so it can read in immediately and show
person what he's doing.  qmail has to have ability to substitute
a name for actual to-list, display name or tolist as
commanded... might as well add subject line in this while at it.
perhaps use bin file as storage for sender specs also(like cc to
self? run job? attribute hacking.)
*******************
Must have way of deleting names from table as well as adding.
general way: have delete and add request types, when updating
just do a delete before an add.
strutcture it so can use fast search algorithm. important if many names.

INvestigte DEMON UUO's. especially communication
between sys and demon.  Might be good idea to finally set up with
already existing DM system calls.

get collection of all FTP reply codes/messages from
all possible sites and stuff as general info for ITS people.
Use BH type algorithm, but keep aware of things in this info.
Must get for: TENEX,SAIL,MULTICS,ITS,DEC,IBM

Prog to inspect queue and delete items?  command (CLI?) to
comsat to do so?

get doc on SAIL, SNDMSG, DMS mail programs so's as not to
overlook good stuff...

front end special TECO thingy.  Should eventually try to hack
better TECO interface.

**MSG device description.

Should be able to handle almost anything, in fact if it doesn't
handle everything things may become even more painful than
the pain of making it universal.  In particular, the network
unqueueing would use the device.

Random notes:
Probably best way to figure what sorts of things one will
want to specify, and then figure out ways to specify them and
get info out of the MSG device.  One idea is to have reasonable
options for standard DSK-style access, and have hairier options
available with a more sophisticated full duplex protocol on
the input/output channels.

MSG device should have interlocks, or relay such requests thru
COMSAT.  (have comunication page?)  Such locks mainly applicable for
disk-file access to the messages.  Would not be good to have everyone
held up while COMSAT wrestled with some obscure foreign host...

For writing:
how to specify multiple recipients?
how to specify sender options?
how to specify recipient? (ie dest. site)
how to modify data base?


For reading:
how to specify which messages?
  which attributes of messages?
recipient options?
how to read data base?



	To simulate normal DDT mail:
can write-open for MSG:<rcpt>;DDTML <something>
or DDTMLA  for MAILA.  can use
DDTSND for SEND.  Processing is quite simple.  With
no fn1 or fn2, default is DDTML.  could also
hack in way like
MSG:<rcpt> MAIL,
MSG:<rcpt> MAILA,
MSG:<rcpt> SEND

...now for multiple, network recpts and sender options.  Will
require a .CALL... 


for reading, MSG:<whatever>;<whatever> <#>
can retrieve the #th msg for that rcpt.  ">" gets most recent,
"<" gets most ancient, etc.  (can also hack things like
>-1, >-9999, <+2, etc.)
number would be unique to that rcpt only, pending system-wide
msg ID's.  upon arrival, # would be that ID # within system.

Master-list
	|
	|
       ID ----> attrib-list
	|
	|
	ID ----> attrib-list
	|
	...

attrib-list --->attrib--->attrib--->attrib--->...

	attrib ::= e.g. sender-name, type-of-msg, text, time-sent, exp-date...

--------------------
Other lists utilize master ID to refer to msgs
To avoid pain of updating every random list, non-ex ID
must be handled smoothly.

Remind-list
	|
	|
	reminder--> msg-ID --->time-next-due
	|			(may have other info, but masterlist should have
	|			all relevant info incl exp date)
	...


Sys-msg-list
	|
	|
	sysmsg--> msg-ID ---> time-created
	|			(again, like remind-list.  info kept directly on
	|			local list should be only for efficiency compromise)
	...

Plan-list
	|
	|
	plan-msg--> msg-ID --> uname
	|			(ditto...)
	|
	...

any others can be readily accomodated under this scheme.  In each case the main
idea is to utilize the msg-ID rather than stray random data; but some of
the data can of course be copied onto the list.  This is discouraged unless
such information will result in much greater efficiency than otherwise
possible by simply structuring the list. (for example, the remind-list can
have its items ordered like a clock queue with soonest item first)