The best way to write a server from scratch is probably by using the TINE server wizard. The next best way is to make a copy of a working server and then make modifications to suite the needed functionality. To this end it is instructive to follow the Build Recipe outlined below. Note that the build instructions apply to Solaris, HP-UX, SGI, OSF, Linux, FreeBSD.

1. Make a directory on your machine called tine. This could be /home/joe/tine for instance.
   If you also intend on developing TINE servers and clients for your UNIX machine as well as VxWorks, you may want to differentiate between the two platforms by making the directory /home/joe/tine-vxw. Although the *.c and *.h source files are identical for all platforms, the “project.def” include file is platform specific. Hence the libraries will also be platform specific.
2. Locate the TINE distribution, and via ftp copy all files in kernel/source to the tine directory. For example:

cd /home/joe/tine
ftp mkinthera1
ftp> cd hera/kernel/source
ftp> prompt
ftp> asc
ftp> mget *

1. Go to Platform/VxWorks in the TINE distribution. From there you should get all make files you see. You’ll end up with the following make files:

• tineLib.mak which makes a library with all TINE modules bound together except the application specific modules, and
• fec.mak, a client-server example which uses the library made from the tineLib.mak file.
  

You will also get a copy of “project.def” for VxWorks. For example (same ftp session as above):

ftp> cd platform/vxworks
ftp> mget *

1. Go the source/example directory in the TINE distribution and get all of the example source modules you see:

ftp> cd ../../example
ftp> mget *

1. Get out of ftp and make the library. Note that you may have to modify the compile switches to suit your target platform. Also note that the switch #define INTEL needs to be introduced into the project.def file if the target platform is an INTEL CPU.

make –f tineLib.mak

1. Now, copy all headers and the project.def file to a designated include subdirectory, for instance /usr/include/tine:

cp *.h /usr/include/tine
cp project.def /usr/include/tine

1. Make a working directory for your server (or client). For example “/home/joe/rpcserv”. Copy the files rpcserv.c, sinsrv.c and fec.mak as well as all .csv files from the ‘tine’ directory to this directory:

cp /home/joe/tine/rpcserv.c ~/rpcserv/
cp /home/joe/tine /sinsrv.c ~/rpcserv/
cp /home/joe/tine /fec.mak ~/rpcserv/
cp /home/joe/tine /*.csv ~/rpcserv/

1. Edit the make file fec.mak so that the paths shown for the LIBS and INCL symbols reflect the location you chose for your include directory, and make the fec.mak file:

make –f fec.mak

1. Edit the file fecid.csv and give your server a more meaningful (albeit unique) server name than “MYFEC”
2. Edit the file exports.csv and make sure all references to “MYSINE” are likewise changed to something more meaningful (but nonetheless system-wide unique).
3. Load the freshly created modules libTine.o and rpcsrv.o into VxWorks (in that order). Then spawn the RPC server task by typing

sp “RPCServer”

at the VxWorks prompt. If an equipment name-server (ENS) is configured and running, this server will automatically plug itself into the system-wide database. If an ENS is not running, then you will have to modify database entries by hand to include the address and name information pertaining to your server. It is strongly suggested to maintain an equipment name server.

1. You have full control over the contents of the files copied to the working directory (in this example) /home/joe/rpcserv. In particular, you will probably want to edit (in not change the module name) sinsrv.c to meet your needs. You may not have to touch rpcserv.c at all, but you can if you need to add something to the main loop.

Comments:

The above example assumes you have the VxWorks development environment set up on your machine, namely that the environment variables WIND_BASE and WIND_HOST_TYPE are defined and that the VxWorks distribution files are available, etc. Note that in VxWorks you do not make an executable, but instead make modules which are loaded into VxWorks. You then “spawn” the tasks which are to run. You can have as many equipment modules as you like (in this example sinsrv.o) and load them in any order. You can only have one libTine.o module. In this respect, VxWorks is like MS-DOS. There is only one address space and only one server process.

The above is a step-by-step recipe for getting the example server and client programs to run. You may prefer to work with the server wizard to produce your first working example of a TINE server.