Notes from ASG meeting of July 8

B. Sahr reported on procurement status.  The toolsets have arrived, sort of.
That is, the documentation for the proper release has arrived, but the
code was a revision behind.  The proper revision is being sent from
Europe.  The simulation software has arrived, but is not installed pending
the receipt of hardware on which it will run.

B. Clark says that it is still unclear to him how we should do code walk
throughs.  (When in the process they should be done, how complete they
should be.)  It is clear that they are too time consming to do in the
ASG meetings; special arrangements will be required.  He has a set of
routines for flash memory management that he would like to walk through
in a couple of weeks.  T. Morgan has code for initializing correlator
backend processes which he could walk through on a similar timescale.
B. Sahr will look into organizing a talk or workshop by Al Stavely to
tell us how to do it.

B. Sahr and R. Moeser have circulated a document (on the evla-sw-discuss
exploder) with remarks on the system architecture and communications.
They are preparing an extension discussing how various items left out
of that document can be incorporated.  Chief among these are monitor data
logging, flag generation, and checker message generation and handling.
B. Clark is preparing a response to the document.

There is some confusion about the use of the word "logging".  We need to
distinguish between monitor data logging, the machine generated record of
what the VLA is doing, and various human generated logs - information for
observers, technician record keeping, array activities, etc.  All need
to be provided in some reasonably integrated fashion.  Current VLA practice
is that observer information is generated in a spreadsheet run on a Mac,
and sent to the observer when his observation segment is over.  It is
also (eventually) archived and printed for general accessibility.  Array
activity is kept track of by bits of paper in the control room.  Technician
activity can to some extent be tracked through Mainsaver; otherwise they
roll their own.  A remark from P. Hicks (relayed via P. Van Buskirk) is
that learning to manage the logs is a very substantial part of new operator
training.

P. Van Buskirk raised the question of database use in the EVLA.  B. Clark
opines that databases are a bad way to store monitor data - the services
they supply are not worth the considerable overhead (both machine and human)
they entail.  B. Sahr says a formal, memory resident database may be useful,
especially for storing the various observing parameters.

B. Clark asks about whether we do not have by now things it would be useful
to store under CVS control.  K. Ryan (on vacation today) has done initial
work on this, including setting up a base directory.  We should proceed to
a working system.