COMMENT ⊗   VALID 00017 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	May 24/77
C00003 00003	June 1/ 77
C00005 00004	June 16/77
C00007 00005	June 22/77
C00008 00006	June 24/77
C00010 00007	June 26/77
C00011 00008	June 27/77
C00012 00009	June 30/77
C00013 00010	July 6/77
C00014 00011	November 1/77
C00016 00012	December 12/77
C00018 00013	March 6, 1978
C00019 00014	June 1, 1978
C00020 00015	August 19/78
C00022 00016	March 1979
C00024 00017	July 26, 1979
C00025 ENDMK
C⊗;
May 24/77

Changes being made:

   - deleted spurious address for O.R.

   - working on AUTOBURP feature (fairly difficult)

   - still haven't put in the 88888 feature

   - also want to add a feature which causes short labels to be printed on
	the XGP whenever SEND is used
June 1/ 77

Things to work on:
  
   - fix up the `delete' in some way, so that anyone with orders still
	outstanding (i.e., in the `orders.xxx' file, isn't deleted
	(or, at least, has his orders deleted).  The problem crops
	up when a new addition is assigned the same hash code.  If 
	there are still reports to be sent to the hash code, of course,
	the new person gets them, which can cause problems.
	[June 15-- I looked at the problem; it's not worth it to pu
	 in a fix.  Vicki knows about it, so everything's OK]

   - speak to Scott about what's required to shrink the labels
	enought to allow printing on the Printronix.
June 16/77

Vicki found a potential bug in the system.  If a single user requests
more than 30 reports in a SEND, the system fails.  This actually happened
in one of her test runs.  I explained to her, and she won't try it
again.  The system should also be patched, so that it prints an error
message, and recovers gracefully. 
[June 26 -- the system now prints an error message, and breaks out of
  the loop in the natural way.  So, the user has the option of making up
  another order if he still wants to send reports to the same customer]

Another peculiar hitch -- three names seem to have disappeared from the
address file quite recently.  I'll try to figure exactly when they were
clobbered, using DART.
[June 17 -- It turns out that the three names were deleted on June 6.
 I restored the version of June 5 to disk, and copied the three entries
 into ADDFIL.DSK.  I'm not sure how they were deleted -- possibly
 thru some sort of crash]
[June 24 -- I tried to duplicate the glitch, using exactly the same
 commands, and was unsuccessful.  Connie remembers that Jeff Rubin
 helped her out at some point in the past, when something bombed;
 possibly it was that run]
June 22/77

It turns out that putting those three names directly back into the file
was the wrong thing to do; the slots for their serial numbers had already
been allocated to new entries. Thus, when the system was loaded, the new
entries were bumped from the file.  I restored them to the file, by
using INSERT, and gave the dialogue to Vicki.
June 24/77

Vicki repeated a request she had made earlier -- we need some way to sort
the ONHAND.DSK file so that the entries are in order (i.e., can be located
quickly).  Currently, the file is in more-or-less random order.  The sorting
should only have to be done once;  all new entries are entered into the
file in the correct order.

We also discussed the work involved in issuing a new bibliography.  There
are some difficulties -- especially, no-one is sure where the original tapes 
have gone.  We can probably get by with sending copies of the old
bibliography (we have about 500 hardcopies left), and including a short
(~10 pages) update.
June 26/77

Added a new labels file, for reports that are SENDed.  The addresses are
written into the file (called SNDLAB.TMP) exactly the same as for LABELS.TMP.
However, there is typically such a small load for SEND that it's not
worth putting on the label forms. So, this file can be XSPooled, cut, and pasted.

The documentation has been updated to reflect this addition.
June 27/77

The page of the documentation describing the label-printing process
has been modified, to make things clearer.
June 30/77

I wrote an auxillary routine SORT, which sorts the ONHAND.DSK file according
to report number.  The program itself is fairly simple -- based on Knuth's
quicksort description.  The code is in SORT.SAI[USE,CSR].  When Vicki gets
all the back reports entered in the file (next week or two), we'll sort it,
and that should finish it.
July 6/77

Sorted the ONHAND.DSK file, using the SORT program.  Vicki sent me a 
note this afternoon saying that she had completed her additions.  The sorting
seemed to go properly -- I ran the output through the REPORT program, and
everything seemed okay.

I modified the NEW_REPORT part of the program, so that whenever the user
enters a new report, he is prompted whether there is an alternate name
(e.g., AIM, CS). Fairly straightforward.
November 1/77
	
	The mailing list is now full (i.e., 1600 names).  There's no problem
in recompiling the REPORT program to handle more people, but some question as
to whether we really want this big a list.
	Vicki would prefer to trim the list instead, by deleting all customers
who haven't ordered anything for, say, the past year.  This should be quite
easy -- I'll have to write a program which makes two passes through the
address file.  The first one will indicate how many customers haven't ordered
since all dates (grouped according to mailing periods).  The second will
permit me or Vicki to delete whichever batch we choose.
	I'll have to find the time to do this -- probably within the next two
weeks or so.

	Vicki would like to have another meeting of the committee, to discuss
charging for people on the mailing list.  This'll probably happen at the
beginning of December.
December 12/77

	There was some trouble last week with the program.  It seems to
stem from the fact that the mailing list is now up to 1600 names -- the
maximum that the program is designed for.  What happened was that some
pointers evidently got screwed up, and the address file was garbaged.
Since Vicki finished the program cleanly, this meant that the garbaged
version was written out, and the previous version destroyed.  I restored
an older version from tape, but Vicki still has to do some working to
make up for the work she lost in the last run.
	I corrected this by revising the file handling, so that the previous
version of the file will be saved in ADDFIL.BKP.  This won't eliminate the
lossage on the final run, but it will mean that safe versions can be retrieved
without having to go thru tape (a losing procedure at SAIL).  The backup file
is maintained thru the obvious hack of writing a new file, and shuffling.
	At the meeting this Friday, we'll discuss what to do about the
full mailing list.
March 6, 1978

	Updated the FORM.DAT file, to account for Vicki's leaving, by
putting in Suzanne's name.
June 1, 1978

	Updated FORM.DAT, to reflect Suzanne's leaving, by putting
in Connie's name.  Also made minor changes to the invoice format, to
	a) stress the fact that payment must be made in $U.S., and
	b) make sure that cheques are made payable to Stanford CSD,
	    instead of the current secretary
August 19/78

Various changes made.

	Connie reported that she ran into trouble when the ONHAND.DSK file
became full.  The program didn't print any message -- just refused to 
allow any more entries to be made into the file via SEND or ADJUST.  I put
in an inform message, so that the program now tells the user why it burps.
Some trickery is necessary, since two entries can be made via on report, 
if the `SAME' feature is used. Also, I raised the size limit (macro `bsize')
from 1000 to 1300, which should hold for at least 6 months.

	Also, I made a minor change to the limits on the number of customers
which can be handled in a single use of ORDER.  The number should be kept down,
since the entire array must b loaded for CHANGE.  Formerly, it was represented
numerically (as 700) in three places; this has been replaced by a macro `csize',
which has been set to 700.
March 1979

	Two changes made:

	First, I added a new line to the invoices.  This prints
`REFERENCE CUSTOMER #:', followed by hash code.  This is for the benefits
of cretins out there who can't read the line `It is important that this
invoice be returned with your payment'.  Maybe they're bright enough to
read the hash code off the invoice, and reference it with their payment.

	Second, there's a new category, for `automatic microfiche', i.e.,
libraries who want to get everything we print, but in microfiche.  This
has category `B' (remember, C is for cost, F for Free, M for ARPA,
N for ONR, and A for automatic, or something like that).  There's nothing
in the new category now, but there might be a few later on.
July 26, 1979

A minor hack put in:  the invoices for mailings will now have the reports
grouped according to hardcopy and fiche, and sorted numerically within
each category.  Previously, the numeric sort was the only one used, and
hardcopy and fiche were intermingled.  This is done to simplify things
for the people stuffing the envelopes -- they can now do hardcopy and
fiche separately.

The change only involved changing a FOR loop, to make two traversals of the
reports list, doing odd (hardcopy) first, and even (fiche) later.