SLC Database procedures:  DBTEST, DBGEN checkout, DBINSTALL
 
 
INTRODUCTION

The DBTEST, DBGEN checkout and DBINSTALL database procedures are performed primarily to ensure recent database updates do not affect any other places in the control system, and that recent changes are accurate, that they will not introduce new problems to the current database status.  These are performed online, and the test and checkout procedures are performed on the onsite development host computer and the installation is done on the production host.  Also there are microcomputers involved which are IPLed on the development host to ensure the software will normally run during the database install.

A request for a DBINSTALL comes usually when there are new devices which involve adding new units into the database files, when there is a new function which includes new functionality of a software program, or when someone from an authoritative figure wants one and we do not exactly know what the change is, or when it is simply planned on schedule. To start the process, a DBGEN is submitted as a batch process overnight.  The next day if there are no problems indicated on the logs from the batch process the DBGEN checkout follows, and again if all is well, the DBINSTALL happens the next day.
 
 

DBTEST

Part of the software database test procedure and before installaion, DBTEST is used and run by an independent application on the VMS,

        slcimage:dbtest.

The output shows status of different micros, which need devices turned on or offline.  It shows the CRTD mismatches and gives the expected CRTD mask bits for the crates to contain.  See 'slchelp primary CSTR'  to see what the crates contain.

A change into the database for instance requires hexadecimal values changed according to the assigned bits set.  Changes may be to turn on or offline, the devices like crates, magnet SAMs, TOROs, PDUs.  The database person then computes the hexadecimal values, noting the appropriate hardware bits, the crate and module to go along with the change in the database file.  Usually the XOR operator is used to calculate the next hexadecimal value or bit pattern for the needed change in CSTR.DBS database file, and this requires an edit into CMS,  using 'editdbs cstr.dbs'.

After the database change, DBTEST is run again, to confirm that the expected bits for turning on/off the devices no longer appear on the list of micros which need the bits to be set. This is used to ensure that for instance the hardware status (HSTA) changes made in the database have been properly set.   For the change to take effect, the micro involved will need to be IPLed by someone in the control room.

DBGEN CHECKOUT

The DBGEN checkout is a series of tests for the newly updated database. See Ken Underwood's document, "DBGEN checklist", for the complete list of steps to follow for the checkout.  The first series of tests are done on the development host where the SCP panel is invoked.  The LI31 and LI34 micros are reserved for the entire session.  From SCP, the MP01 and LI31 micros are booted under the network index panel. The checkout list includes checking the magnets, the LI31 triggers, the digital and analog status, and the display summary screen in which several devices of micros are displayed.
The next series of tests are the IPL of micros.   This is again done on the development host, and while LI31 and LI34 are still being reserved.  The tester opens a SCP panel, but in the test area nearest the LI31 and LI34 micros  for eaiser access to changing the addresses on LI31 and LI34.  As the micros are IPLed, their database software are exercised.  The tester looks at the error messages from the ERRDSP application, to see that there are not any database software errors, such as database timeout errors, or "list too short" error messages. For this checkout, most of the hardware related messages from ERRDSP at this checkout are ignored, and are considered normal messages in the IPL, such as lines with CAMAC and 'X' messages.  In a normal IPL, the following error messges are expected:   "data received from TIMEX", or "IPLed successfully at your service".  An unsuccessful IPL might have a  "Database IPL timed out on LI00" message for the microcomputer LI00.  This may imply that the memory of the micro being used for IPL is not enough to run the software, i.e. may need an 8 megabyte or the next higher capacity of memory board than the current one being used for LI31.
There are a number of micros in the IPL list, including the PEPII micros.  Each micro is IPLed, in order to exercise the related software which include the new database updates.   Particular attention is focused on a micro which had more database changes, and that micro is added to the IPL list at the checkout procedure.
Currently, the following micro computers are IPLed on LI31 with an 8 megabyte memory board:  LI00, MC00, CB00, CB01, CB02, CL01, DR12, AB01, PI00, PI11, TA01, TA02, LI12, LI28 and LI30.  The following PEP region  micros are IPLed on LI34's EPC board:   PR02, PR04, PR06, PR08, PR10 and PR12.  At times, LI34 uses TCP/IP communications and the IPLs need to be done on SLCnet.  A special program to initialize the global section on the development machine must be run, to read a microname.dat file that has special setups which allows the LI34 micro to be like the PRxx micros.  When done, the program must be run again, to read the production version of miconame.dat.
After the checkout, any errors are reported to the persons responsible.  If for instance error found might be "list too short", this is a critical error message, which indicates the need for modifying software parameters.  Any software database errors caught or new messages are prompted to the database expert, or to the proper person responsible for the update, so the errors can be promptly resolved before the DBINSTALL procedure.  Also, the LI31 and LI34 micros need to be unreserved, to make them available for the next tester.

DBINSTALL

Once the checkout proves successful, the DBINSTALL is performed. This involves moving all the database files and related updates, from the development host into the production host computer.  See Ken Underwood's document, "DBINSTALL checklist".

NLC SPECIFIC FUNCTIONS

A new switch has been installed so hexadecimal numbers are thumb-switched instead of the the previous way of toggling the 8 binary-bit addresses.  This is an improvement, but for NLC we need to go a step further, which means more automation in order to lessen the time involved to IPL micros at the checkout.  Currently the average time do the checkout is about an hour.  Switching from the 8 binary-bit toggles to the hexadecimal-bit thumb switches saved about half an hour.  We need to automate to IPL many more micros.  For improvement for the NLC, perhaps one can device the test micros so that one can IPL from a remote machine, and the tester will not need to be right at the "test closet", to switch the different addresses of the micros.  One should be able to program the micro to change addresses.

While the current SLC requires critical database error messages in ERRLOG to be eye-balled on screen, perhaps NLC database error messages can  be separated from hardware and software database error messages.  Critical software database errors could be channeled into a separate file.

The database installation process is an expert system, where the tester, the installer and the database experts together pay attention to the detail and the errors.  The database expert follows through with the appropriate person who would be able to resolve and fix problems if there are any, and altogether each person contributes to a smooth process.
 
 

September 1999
Joan A. Paz