Here is the agenda for the POD meeting for next week (Tues, May 2 at
10:00 in the MCC Conference room):
1. Richard will present results of debugging a problem on iocin4
focussing on the techniques he uses for debugging on the ioc. Anyone who
has software on-call duties should attend at least this portion of the
meeting.
2. A proposal for speeding up database loads has been made. The
attachment describes this proposal. Please review, assess the impact on
non-standard database make/installs (if you are using a non-standard
method), and come prepared to raise any relevant issues or propose
alternatives, enhancements, etc.
3. John Hansknecht has requested that iocpl1 be upgraded to R3.13. We
will begin planning for this upgrade. This portion will involve only
people who have applications on iocpl1 (currently the list includes D.
Wetherholt, A. Hofler, P. Kjeldsen, M. Keesee, and S. Higgins). Please
plan to stay for this portion of the discussion if you have an
application on iocpl1 and I have left you off the list.
--
==============================================================================
Sally Schaffner, Computer Scientist, TJNAF
e-mail: sally@jlab.org
==============================================================================
Speeding up EPICS Database Loads
This document describes a method to speed up the database loading
process on an ioc which will:
* Allow us to use the EPICS tool (dbst) which strips out
default fields before the load.
* Allow us to keep track of which version of cebafApp was used
to do this.
* Ensure that the version of cebafApp being loaded on an ioc
is consistent with the version that was used to strip the fields.
* Has very low impact on the our current tools and methods of
making and installing databases.
This idea goes back to some discussions we had about a year and a half
ago about setting up a "record reconciler" to track versions of custom
record support. This document deals only with cebafApp but the methods
may be adaptable to custom records in general.
Here is an outline of the process:
The database makefiles are already set up to make for a particular
ioc. We could modify these makefiles to look at the config file for an
ioc and get the version of cebafApp that is being loaded on that
ioc. It could then set up the correct path for the dbst tool which
needs the cebafApp.dbd file. We could make this process use the
current config file for an ioc by default but have an option to use an
alternate config file if necessary.
We could make running dbst part of the install procedure and add an
additional process which inserts a special record in the database for
each ioc as it is made. The record would be called appVer where app is
the application name. The version number of cebafApp that was used in
the dbst process could be encoded in the INP or OUT field of the
record depending on what type of record we decide to use.
The install procedure also performs the following steps. Before
installing, it makes a subdirectory in $PROD_DIR/db based on the
cebafApp version (e.g., cebafapp_2-1 or something). It places the .db
files for the ioc in this subdirectory. When linkmaker is run, it
modifies the startup scripts for each application with a database to
insert the extra subdirectory in the path for any dbLoadRecords
commands it finds in there. This way you could run the install with a
config file name other than the default. Then, when you run linkmaker,
it automatically sets up your startup script to load the correct set
of databases for that particular ioc based on the cebafApp version.
When cebafApp gets loaded (it always goes first since it is called
from startup.epics), we will have to write some kind of function that
knows what version of cebafApp is being loaded and writes it to some
kind of global variable on the ioc.
The special records that get loaded with each application would have
device support written that strips out the cebafApp version number and
compares it with the cebafApp version number in the global
variable. If they don't match, we could have it print out an error
message which presumably would be seen if someone is watching at boot
up time. It could also be logged or set an alarm or something.
We then remove the loading of cebafApp.dbd from all app.dbd files and
only allow cebafApp itself to load cebafApp.dbd.
This would have very low impact on all the developers and would only
require a small amount of code to be written to support it. It would
then give us back some of the functionality we lost when we moved to
313 and couldn't use the default.sdrSum check anymore.