Front-End SQL Settings Downloads
			   Sept. 29, 2000
			 Updated May 16, 2001
			  Dennis J. Nicklaus

  Instructions for using the new freetds-based method for downloading
                settings and alarm blocks to the front end

I have implemented a new method for downloading settings and alarm blocks (and
VMDI tell devices) to a VxWorks front end.  This method is more under the
control of the front-end computer.  The front-end computer issues SQL queries
directly to the database to retrieve the settings, etc.  The queries are
issued, and data retrieved using the freetds (www.freetds.org) libraries. (TDS
is a protocol for communicating with Sybase databases.)

You must do the following on the front-end computer. 
1) Use the newest version of Mooc (3.0 or later).

2) On the front-end, have the Mooc and Errorlog objects downloaded
and have called errorlogInit.

3) Issue the following front-end commands, for instance in the startup script:
3.a) Add the accdb and appdb hosts to the host table, currently:
	-> hostAdd "quasar.fnal.gov","131.225.121.117"
     	Quasar serves both accdb and appdb.
    	Discourage the database people from changing the quasar node ever.
    	quasar.fnal.gov is set as the default accdb and appdb hosts in the
	download code.  If necessary, it can be changed with the
	global (char *) variables:
		sybase_host_settings
		sybase_host_vmdi

3.b) Download the tds-based download code.
	-> ld <$PRODUCTS_MODDIR/dbdown.out
3.c) Install the alternate dowload method:
	-> install_alt_download_function (dbdownload)

Those commands must be repeated each time the front-end is rebooted.

Now, the next (or first, if you do this before the mooc/slam are initialized)
time the alarms/settings are downloaded, this new method will be used.


			What Else is Different?
A few other things are different, and these are still under consideration
as to how to best construct things.

1.) A log file (such as [vtevatron.log]miscboot.log) is no longer
generated.  The front-end error logger is used to issue warning
messages whenever any of the settings return an error code.  Run a
logClient to display/file these messages.  However, this is
problematic because the download error log messages typically come
pretty soon after a reboot and the networked logClient may not have
had time to reconnect with the front-end.  To get around this,
you can currently (May 2001) use  the "logClient -p" option on
the host and logClientAdd on the front-end.

IMHO,  this isn't really an ideal solution. But I think it is the
best option until a better one gets implemented.

2) The settings and alarm blocks will not get forwarded to the
Settings History (viewed through D54). Never, ever.  They usually
don't under the AERBOOT mechanism unless the analog alarm type
was 0 (zero) in the database and the front-end adjusted it based
on the device's driver software.  Under AERBOOT/slam, when that
adjustment took place, the new setting, with analog alarm type,
was forwarded back to update the database.  Forwarding isn't possible
with this TDS method of downloading.

3) Occasionally, the connection established with the Sybase server may get
broken in such a fashion that the Sybase server believes it still has an open
connection to that front-end, persisting even after the front-end has been
rebooted or turned off.  This can be bad for several reasons, including:

	Enough of these dead connections could eventually take up
	all the allowed connection slots to the database.
	
	Having such a dead connection makes it more difficult for
	the same front-end to connect to the server.  I have found that
	with one such dead connection, the first attempt (after reboot)
	by the front-end to connect to the server will fail, then the
	first retry will succeed.  With several (about 7) such dead
	connections hanging about, it may be even more difficult.
 


			Building details
I checked out the most current version of freetds from their cvs 
repository on Sept 28, 2000. I made few modifications to the code
to get it to build under vxworks.

Below are the configuration commands I used to build each version
of it.  In between each architecture change, you must do:

	rm config.cache
	make clean

Then select the proper environment, then run the configure command below, 
then run :
	make
	make install
After that go to the install directory and copy :
	% cp lib/* $PRODUCTS_LIBDIR/tds
	% cp include/*  $PRODUCTS_INCDIR/tds


env2_ppc604

LDFLAGS="-n -r" ac_cv_prog_cc_cross=yes ac_cv_c_bigendian=yes CC=ccppc CFLAGS="-B/usr/local/vxworks/ppc_2.0/host/sun4-solaris2/lib/gcc-lib/ -O2 -I$WIND_BASE/target/h -ansi -nostdinc -DCPU=PPC603" AR=arppc CPU=PPC604 TOOL=gnu ./configure --with-tdsver=4.2 --prefix=/home/nicklaus/ft2 --target=PPC603-vxWorks --enable-shared=no

env2_68020

LDFLAGS="-n -r" ac_cv_prog_cc_cross=yes ac_cv_c_bigendian=yes CC=cc68k CFLAGS="-B/usr/local/vxworks/68k_2.0/host/sun4-solaris2/lib/gcc-lib/ -m68030 -msoft-float -O -I$WIND_BASE/target/h -ansi -nostdinc -DCPU=MC68020" AR=ar68k CPU=MC68020 TOOL=gnu ./configure --with-tdsver=4.2 --prefix=/home/nicklaus/ft68020 --target=MC68020-vxWorks --enable-shared=no

env2_68k

LDFLAGS="-n -r" ac_cv_prog_cc_cross=yes ac_cv_c_bigendian=yes CC=cc68k CFLAGS="-B/usr/local/vxworks/68k_2.0/host/sun4-solaris2/lib/gcc-lib/ -m68040  -O -I$WIND_BASE/target/h -ansi -nostdinc -DCPU=MC68040" AR=ar68k CPU=MC68040 TOOL=gnu ./configure --with-tdsver=4.2 --prefix=/home/nicklaus/ft68k --target=MC68040-vxWorks --enable-shared=no



This is how I had to compile/link it on the Sun in order to be able to look
inside the dblib and tds libraries with the debugger.
gcc -g -DHW_BIG_ENDIAN -DTDS50 -o dbtest dbtest.o ../src/tds/*.o ../src/dblib/*.o  -lsocket -lnsl