SLAC ESD Software Engineering Group
AIDA

# "New Labour" development cheat-sheet

 SLAC Detailed SLAC Computing ESD Software AIDA

This page is a programmer's cheat-sheet for working on the "New Labour" AIDA development branch. As such this is a temporary page; it is envisaged that New Labour will soon be merged into the primary AIDA development, and so items from this page will supplant those in exiting AIDA web pages.

## Checkout and Build Development AIDA

This section describes how to check AIDA out of CVS, make a change to some source file, compile and build your development version, commit it back to CVS, and so rebuild the production version.

To "CVS CHECKOUT" and  "make" AIDA New Labour:

NewLabour is in the CD_SOFT cvs area, not the old slac/package area.

• Source ENVS.csh if you have not already done so:
•  source /afs/slac/g/cd/soft/dev/script/ENVS.csh
• Check aida out of CVS. At present aida is not a CVS module, so you have to give the path of aida from CVSROOT. The following checks out all of aida into the working directory, in a directory named "package" which will contain "aida" and its subtree:
•  cvs co package/aida
• To make it, set your AIDADEVROOT appropriately, (to point to the project root - ie the directory containing edu/). The following script sets AIDADEVROOT and defines aidamake, used below. The first argument specifies which Aida Directory Service for which the environment will be set up. The choices are DEV, PROD, LCLSDEV, LCLS. The default is PROD. If you choose DEV or PROD, this will also specify the AIDA network any Aida servers started in this session should join. If you choose LCLSDEV or LCLS, you're only specifying the database that Directory Service management tools like add_IA refer to (ie LCLSDEV = MCCQA, LCLS = MCCO), since SLAC public network (ie AFS) aida clients can't access the AIDALCLS network. The second argument is the name of the Aida "package root", that is, where a directory named "edu" can be found. Note, this same script is run without the argument to build the production Aida in $AIDAROOT. E.g.: source$CD_SCRIPT/aidaSetEnvDev.csh [DEV|PROD|LCLSDEV|LCLS] /u/cd/greg/dev/nbuser33/projects/package/aida
• To make all of aida in the directory tree whose root was specified in the previous step. aidamake with no args builds builds only the core aida software.  With the "all" arg, build all the code, testsuite, javadoc, and jar file:
aidamake [all]
You may give a target to aidamake too, so that it only builds some part of aida, e.g.:
aidamake daNameServer
will build only daNameServer, see MakefileAida.sun for list of targets.
• To clean-up class files (does not delete generated java files)
aidamake ACTION=clean
• To add compiler arguments, use DEBUG macro
aidamake DEBUG=-g
• To make the test suite
aidamake testsuite
• To "release" changes back to CVS: cd back to your working dir (the one containing package/aida). Then check whether someone has put stuff into CVS since you checked it out. See CVS Manual 10.2 and 10.3 about how to interpret the results of the cvs update command. You can update a single file, or everything that was checked out (the example below):

cvs update package/aida
When all conflicts have been resolved, proceed to cvs commit and update the reference dir.
cvs commit

## Build the Production Aida code

• If code has been changed, make Aida and update the production javadoc. Use aidaSetEnvDev.csh DEV, with no 2nd arg to reset AIDADEVROOT to point to released code, then run aidamakes. Recall the "DEV" arg only specifies the network, not what source code is to use, but it's a required argument. The add/removeUserRefWrite are necessary to allow you to install production build products into the software group's release directories (this is at present only strictly necessary for releasing dpChads). If you changed scripts those also need to be released:

kinit
source /afs/slac/g/cd/soft/dev/script/ENVS.csh

The test suite for java is located in $CD_SOFT/ref/package/aida/test/java/. The following runs all the tests in Test.java, which exercises various API facilities. You may choose to run only some of these. At the time of writing tests 12 to 16 are performance tests which exercise 1000 round trips, so they take a little more time. aidatest daAIDATest 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Note: tests 11 and 13 request history data for the following PV's. It is assumed that the AIDA database is set up to request data from service id 41, TestHist for those PV's. HR81:CAV1:VACM//HIST HR23:CAV1:VACM//HIST There are additionally test programs for each data provider.The test running java Class is named daDp<dataprovider-name>Test.java. The tests themselves are in source files named Dp<dataprovider-name>Tests.java. To Run the Channel Access DP Test Suite aidatest daDpCaTest 1 2 3 ... To run the SLC Db DP Test Suite aidatest daDpSlcTest 1 2 3 ... Note that not all of the tests will be successful on both aida networks, for instance daDpCaTest 2, which gets an HB60 Epics variable, which is not available from the host on which the Dev DpCaServer runs, results in an exception when accessed from a Aida client running on the Dev Aida network, it's only available to the Prod DpCaServer, so it's only available to a Prod client. ### Run Test Instances of the Aida Servers Set the basic environment, optionally using a development AIDADEVROOT (dir containing edu/). You can skip this stage also, of course, if you've already done this to make the test version. eg source /afs/slac/g/cd/soft/dev/script/ENVS.csh source$CD_SCRIPT/aidaSetEnvDev.csh dev
[/u/cd/greg/dev/nbuser33/projects/package/aida ]

Kill the development instance of the server:

aidamanager DpCaServer kill dev

Run the process start statement in the st file of the Aida process you want to start. For java servers this will be an aidaproc statement. This will start the server in the process and on the machine on which you execute aidaproc (unlike using aidamanager, which determines the host on which to run the server from the production environment depending on the arguments you give it):

 st.DaNameServer aidaproc $AIDA_NAME_NAME$AIDA_NAME_DBGADDR sys.daNameServer.NameServer st.DaServer aidaproc $AIDA_DA_NAME$AIDA_DA_DBGADDR sys.daServer.DaServer st.DpCaServer aidaproc $AIDA_CA_NAME$AIDA_CA_DBGADDR dp.dpCa.DpCaServer st.DpTestHistServer aidaproc $AIDA_TSTH_NAME$AIDA_TSTH_DBGADDR dp.dpTestHist.DpTestHistServer st.DpTestServer aidaproc $AIDA_TST_NAME$AIDA_TST_DBGADDR dp.dpTest.DpTestServer

aidaproc passes on all arguments to it to the main, and all aida servers pass arguments to the main to the ORB.init(), so you can add for instance -ORBtrace_connections 3 to have the server trace all its Corba activity.

One should restart the DaServer after restarting NameServer (as of 13-Jun-08), especially on the production Aida network, because DaServer caches connections.
The production NameServer must be started under cddev, since only that can write the NameServerPROD.ior file.
aidamanager will restart the NameServer on the right host, e.g. "aidamanager $AIDA_NAME_NAME restart prod" To reinstate the "production" released server, kill the test one, and restart the released one. You can kill the test instance of the server with warmst as long as you run warmst on the host on which you started the test server with aidarun above; or you can just use kill. Eg, if you ran aidarun on slcs6, then you must run warmst to kill it on slcs6: warmst DpTstServer kill aidamanager DpTstServer restart dev aidamanager DaServer restart dev ## Basic Debugging You can use the jdb debugger for the simplest debugging. This is described below for servers and clients. ### Debugging a server When started with aidaproc (per above examples, and in the st files), the servers listen to the given debug port (eg AIDA_NAME_DBGADDR). So having followed the procedure in the above instructions for "Running test instances of the development servers" you can in fact attach a debugger to the running production server by starting jdb, and giving the port to which to attach to the server. Then set your break points as usual, and run a test client to exercise the server. See Sun jdb home page for use of jdb. See the following attaches a debugging session to the running NameServer, whose debug port is given by$AIDA_NAME_DBGADDR.

Eg:

[slcs2]:greg/dev/aida> jdb -sourcepath $AIDADEVROOT -attach$AIDA_NAME_DBGADDR
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
> stop in edu.stanford.slac.aida.sys.daNameServer.DaNameServerI_impl.GetObjRef

There is no need to "run" or anything after the stop instruction. Now when a client does "aidatest daAIDATest 1" for instance, the window in which the debugger has attached to the NameServer will give something like:

334             String objref = null;

name = "daServer"

When you have finished debugging, just enter "exit" in the debugger window. The server itself
will keep going.

### Debugging a server "directly"

One can also start the server under the debugger directly (not attaching to a running server, but more like the classical case of running an executable from the debugger). This is useful, for instance, if the problem is in the startup sequence of the server. To do so, use "aidadebug", which is just like "aidarun" except the java verb is replaced by jdb. Eg:

Initializing jdb ...
> stop in edu.stanford.slac.aida.sys.daNameServer.DaNameServerI_impl.initDB
Deferring breakpoint edu.stanford.slac.aida.sys.daNameServer.DaNameServerI_impl.initDB.
It will be set after the class is loaded.
> run

### Debugging a client

To debug a client, you don't attach to a process, you just start it under jdb directly. Aidatestdebug is just like aidatest except it replaces java with jdb.
aidatestdebug daAIDATest 1

## Logging and Viewing Exceptions

Author: Greg White 10-Aug-2002
Modified by:
3-Sep-02, Greg, Changed for new login script setup.