SLAC ESD Software Engineering Group
Stanford Linear Accelerator Center

"New Labour" development cheat-sheet


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.

Contents:   Checkout and Build Development Aida  Build Production Aida  Start Aida
See also: Aida CVS Guide, ESD CVS Guide, ESD CVS Cheat Sheet

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 $CD_SCRIPT/aidaSetEnvDev.csh [DEV|PROD|LCLSDEV|LCLS] /u/cd/greg/dev/nbuser33/projects/package/aida
 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.
 aidamake ACTION=clean
 aidamake DEBUG=-g
 aidamake testsuite
 aidamake javadoc
 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

you@SLAC.STANFORD.EDU's Password:
source /afs/slac/g/cd/soft/dev/script/ENVS.csh
source $AIDASCRIPT/aidaSetEnvDev.csh DEV
aidamake all
gmaketst package/aida/common/script
gmakedev package/aida/common/script
gmakenew package/aida/common/script

ssh lcls-builder -l softegr
cd /usr/local/lcls/physics/package/aida/lib
scp /afs/ to the current directory
scp /afs/ to the current directory

ssh lcls-daemon4 -l laci
cd /etc/init.d
./st.DaNameServer restart
./st.DaServer restart
./st.DpTestServer restart
./st.DpTestHistServer restart
./st.DpCaLclsServer restart
./st.DpModelServer restart
./st.DpRdbServer restart

 cvs release package/aida
cvs history -ao
rm -r package

After significant changes to aida, its jar file should be distributed to the "V" drive too (V:\cd\soft\ref\package\aida\lib\aida.jar), so that matlab PC users can take advantage of it.

Starting the AIDA Server Suite

This section describes the process of starting the system of server processes which constitute AIDA.


Start cmlog, to check messages generated by AIDA, log onto LCLS production (eg lcls-builder as softegr)

cmlogviewer &

To use the AIDA system management you need to log into Public AFS Solaris (tersk, flora etc). Set the basic environment, not for Aida itself but for the management scripts used below:

source $CD_SOFT/dev/script/ENVS.csh
source $CD_SOFT/dev/script/aidaSetEnv.csh

See What's Presently Running?

Check what AIDA processes are running in either development or production AIDA - if last arg isn't given, the DEV network is assumed:

aidamanager all show [{dev|prod}]

AIDALCLS is not known to aidamanager. To check what's running in AIDALCLS Unix, log into laci on lcls-daemon4:

pgrep -fl AIDA

To just check on the Error logging components (oocCosEventService and errClient):

errmanager all show

Start Aida

To start the Error logging components (oocCosEventService and errClient):

errmanager all restart

To start all unix hosted servers of Aida in one go, just issue:

aidamanager all restart [{dev|prod}]

Then start the specific DpChadsServers (pepii, nlcdev, pack). See for troubleshooting dpCa/dpCaLcls restart

To start or restart individual components of AIDADEV or AIDAPROD (eg restarting the dev or all instances, where most appropriate):

aidamanager DaNameServer restart [{dev|prod}]
aidamanager DaServer restart [{dev|prod}]
aidamanager DpCaServer restart [{dev|pepii}]
aidamanager DpCaLclsServer restart [{dev|prod}]
aidamanager DpTestServer restart [{dev|prod}]
aidamanager DpTestHistServer restart [{dev|prod}]
aidamanager DpChadsServer restart all [{dev|pepii|nlcdev|pack}]
aidamanager DpChadsLclsServer restart [{dev|prod}]

AIDALCLS servers must be restarted from their startup files.

To restart all VMS hosted servers, log into SLCSHR on MCCDEV (dev) or MCC (prod), and issue:

To start or restart individual VMS hosted components of AIDADEV and AIDAPROD on VMS:

warmslcx aida_dpslc /restart
warmslcx aida_dpslcmodel /restart
warmslcx aida_dpslchist /restart
warmslcx aida_dpslcbpm /restart
warmslcx aida_dpslcmgnt /restart
warmslcx aida_dpslcutil /restart
warmslcx aida_dpslcmosc /restart
warmslcx aida_dpslcklys /restart

To start or restart individual VMS hosted components of AIDALCLS on VMS (at the time of writing, there is no BPM service on AIDALCLS:

warmslcx aida_mosc_lcls /restart
warmslcx aida_hist_lcls /restart
warmslcx aida_mgnt_lcls /restart
warmslcx aida_modl_lcls /restart
warmslcx aida_util_lcls /restart
warmslcx aida_slc_slc /restart
warmslcx aida_klys_lcls /restart

Run Aida Test Suite

In some different login (for now), set up the Test Environment to run in the DEV Aida network.

source /afs/slac/g/cd/soft/dev/script/ENVS.csh
source $CD_SCRIPT/aidaSetEnvDev.csh DEV

The test suite for java is located in $CD_SOFT/ref/package/aida/test/java/. The following runs all the tests in, 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.

There are additionally test programs for each data provider.The test running java Class is named daDp<dataprovider-name> The tests themselves are in source files named Dp<dataprovider-name> 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):

aidaproc $AIDA_NAME_NAME $AIDA_NAME_DBGADDR sys.daNameServer.NameServer
aidaproc $AIDA_DA_NAME $AIDA_DA_DBGADDR sys.daServer.DaServer
aidaproc $AIDA_CA_NAME $AIDA_CA_DBGADDR dp.dpCa.DpCaServer
aidaproc $AIDA_TSTH_NAME $AIDA_TSTH_DBGADDR dp.dpTestHist.DpTestHistServer
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.


[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:

Breakpoint hit: "thread=ORBacus:Server:ReceiverThread", edu.stanford.slac.aida.sys.daNameServer.DaNameServerI_impl.GetObjRef(), line=334 bci=0
334             String objref = null;
ORBacus:Server:ReceiverThread[1] print name
 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:

aidadebug $AIDA_NAME_NAME sys.daNameServer.NameServer
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

[Aida Home Page][SLAC Controls Software Group][ SLAC Home Page]

Author: Greg White 10-Aug-2002
Modified by:
3-Sep-02, Greg, Changed for new login script setup.
30-Oct-2002, Greg, Changed for "grenaida" and added header.
28-Jan-2003, Ronm, Changed test history server dpTestHistServer from java to c++.
01-Mar-2003, Ronm, Changes to dpTestHist for Oracle vs file
11-Jan-2004, Greg, Changed for AIDA release support release into UCS
11-Sep-2006, Rdh, Added "errmanager all restart" to "Start Aida" section.
17-Sep-2007, Rdh, Added new Aida servers in "Start Aida" section.
30-Mar-2010, Rdh, Added a subsection for copying aida.jar and aidadp.jar Also added a subsection for restarting the Aida LCLS network Java processes.