This wiki page describes how to create a new VMS hosted AIDA Data Provider.
See also the main page describing development of VMS hosted AIDA Data Providers, that page covers the overall architecture and revolving maintenance of data providers. This one covers only the process of creating the files which implement a brand new data provider.
To create a new data provider on SLC, we begin on an AFS unix node and use facilities in the Aida makefile system for creating the CORBA stubs and skeletons of a new Aida server. We then copy all the files so created over to VMS and continue real development there (where real developers work):
First, create a development directory on AFS unix, and cvs checkout aida:
| Code Block |
|---|
$ mkdir work2 $ cd work2 $ cvs co package/aida cvs checkout: Updating package/aida U package/aida/.classpath.... |
...
| Code Block |
|---|
$ cd package/aida/edu/stanford/slac/aida/dp/ |
Create a new Data Provider (dp) directory. Then copy an existing Makefile.sun4 from one of the existing dps, on which we'll base a new one.
| Code Block |
|---|
$ mkdir dpSlcMagnet $ cd dpSlcMagnet/ $ cp ../dpSlcModel/Makefile.sun4 . |
Modify the Makefile, replacing the PACKAGE, MODULE and INTERFACENAME values with values appropriate for your new data provider.
| Code Block |
|---|
$ emacs Makefile.sun4 <edit PACKAGE, MODULE and INTERFACENAME> |
Run the Makefile.sun4; this will create all client and server sides, except the _impl.java file. You will create an _impl.java file by hand later.Ignore the jidl complaint about not finding an idl file, it's not supposed to.
| Code Block |
|---|
$ gmake -f Makefile.sun4 jidl: couldn't open /u/cd/rdh/work2/package/aida/idl/dpSlcMagnet.idl sed -e 's/THIS/dpSlcMagnet/g' .... ... |
Go to VMS, and " create the usual 43 layers of Aida directory structure", to the .DP directory. Then create you new subdirectory underneath it.
| Code Block |
|---|
> set def [.work.package.aida.edu.stanford.slac.aida.dp] > create/dir [.dpslcmagnet] > set def [.dpslcmagnet] |
FTP the java files you created on AFS, to your VMS development directory. You can execute the ftp command unix or from VMS (in which case ftp to ftp.slac.stanford.edu). Here we have doen the ftp from unix:
| Code Block |
|---|
$ ftp mcc Connected to mcc-lavc.slac.stanford.edu. 220 mcc.slac.stanford.edu MultiNet FTP Server Process V4.4(16) at Fri 18-Aug-2006 4:11PM-PDT Name (mcc:xxx): 331 User name (xxx) ok. Password, please. Password: 230 User xxx logged into USER_DISK_SLC:[xxx] at Fri 18-Aug-2006 4:11PM-PDT, job 20281e16. Remote system type is VMS. ftp> cd user_disk_slc:[xxx.work.package.aida.edu.stanford.slac.aida.dp.dpslcmagnet] 250 Connected to USER_DISK_SLC:[xxx.WORK.PACKAGE.AIDA.EDU.STANFORD.SLAC.AIDA.DP.DPSLCMAGNET]. ftp> mput *.java |
Purloin a *server.java file from one of the existing VMS data providers (eg ref_aidashr:dpslcmodelserver.java). Copy it to your working directory and modify it. Also copy an existing *_impl.java file as a strating off point for your new server.
...
| Code Block |
|---|
define myjava$classpath [------] |
Compile all your java
| Code Block |
|---|
javac -g *.java |
Create the JNI prototypes for the native methods:
| Code Block |
|---|
MCCDEV> javah -o dpslcbpm_jni.h -classpath [------] "edu.stanford.slac.aida.dp.d pSlcBpm.DpSlcBpmI_impl" |
Create your JNI interface module (the C code that the java calls). By convention we call this module dp<servername>_jni.c. It must have the *ATTRIBUTES*=JNI at the top so cmp knows how to compile it, and it should include the output file from the step above. Eg:
| Code Block |
|---|
/*
**MEMBER**=SLCLIBS:AIDASHRLIB
**ATTRIBUTES**=JNI
*/
#include "dpslcbpm_jni.h"
|
Create the dp<servername>_jni_helper.c file. This is the module that defines the functions that access the control system. The names of the functions it *defines* must all be in upper-case (due to the compiling and linking configurations specified in slccom:compile.com and the build com files). But the functions that those function call (in the control system shareables), need not be in upper-case.
...
| Code Block |
|---|
MCCDEV> lib/create aidashr_devlib.olb MCCDEV> cinc *.c |
Create an aidashr_xfr_alpha.opt. Due to namemanging of JNI and VMS linking
namespace restrictions, it's important to do this with java$jni_example:scan_globals_for_option.com.
| Code Block |
|---|
MCCDEV> libr/extract=dpslcbpm_jni/output=dpslcbpm_jni aidashr_devlib MCCDEV> @java$jni_example:scan_globals_for_option *.obj aidashr_xfr_alpha.opt |
Link your aidashr, using the opt file created above. You may also need to use a locally modified version of AIDASHR_XFR_ALPHA.OPT if you are using shareables AIDA hasn't used before.
| Code Block |
|---|
MCCDEV> buildtest aidashr /default |
Run the server. The java command to run an AIDA server takes several arguments, to pass the values of
environment variables to the server at startup, so we have little .com files for each server. To override the default classpath (JAVA$CLASSPATH) which points to the aida.jar in slcimage, and the default AIDASHR (in SLCSHR), redefine the logicals before running the START<server>.COM file:
| Code Block |
|---|
MCCDEV> define myjava$classpath [------] MCCDEV> testshrx/define/default aidashr MCCDEV> @startdpslcbpm |
When development is complete on VMS side
When you're done, you can cvs release the unix side aida checkout. Note that you do not need to checkin any of the CORBA stubs and skeletons you created for the VMS server. The client side of aida sees the VMS server simply as an "aidaObject", it does not know it is specifically talking to a dpSlcMagnet server object, so there is no need to keep any of the files for a VMS server on the unix side.