Be sure to see the General installation notes.

Fame Specific Installation Notes

The Fame server has two somewhat distinct uses which will be discussed separately below. The first usage is to supply data to several users' client programs from databases which are available for many users to access (typically in a read only mode). The second usage is to provide a mechanism for a single user to pass data from one program to another by writing it to a database and then retrieving it.

The server runs as a background process. It opens and closes databases for each request. (This insures that the databases are current and does not seem to add much overhead compared to leaving them open.) When the server receives a terminate signal (kill -15) it exits.

The server can take arguments: -h, for help and -l file, to specify a log file. The default log file is padi_fame.log.

Local Mode Server

The script fame.server starts, as a background process, a server (padi_fame.local) which opens databases on request. The script takes as an argument the name of a default Fame database which is opened, but the database may be empty and is created if it does not already exist. The script returns a process id (of the script which started the server). This should be passed as an argument to the script cleanup.fame.server, which should be used to terminate the server. The server waits for requests and runs until it receives a terminate signal from the cleanup.fame.server script. These script can be called from within other applications which need access to Fame data. (See the S client for an example.)

The function getpadi as implemented in fame_svc.c opens the database in Fame mode HRMODE (read mode) and closes the database after reading the time series. The function putpadi attempts to open the database in Fame mode HSMODE and if that fails it trys HCMODE. After writing the time series the database is closed.

Public Mode Server

For this usage it is suggested that the server be run under an account id which does not have write privileges on the database files, unless it is truely intended that some users be allowed to write to the database with this mechanism. The server attempts to control read/write privileges according to rules which are passed to the server, but the operating system read/write privileges will be those of the uid of the server process, not those of the uid of the client process!

The Fame server program (padi_fame.public) expects an argument which is the name of a Fame database. This database gives the names of data bases that the server will access, and gives information about how formulae and functions should be resolved. This database will be referred to as the object database and the name "object" is use in the test programs and in examples below. This indicates the Fame database object.db.

The object database can be generated with the help of script programs, add.readdb.to.server, add.dependencies.to.server, and add.function.to.server. (Also, add.writedb.to.server is available for a mix of read and write databases.) These scripts use Fame procedures which will be compiled by make. Examples can be found in the scripts test.public.mode.fame.server and start.ets

The script add.readdb.to.server is for adding Fame databases to the list of primary databases which the server will access. The script takes two arguments, the first indicating the name of a database to be accessed and the second the name of the object database which is being built.
example:
add.db.to.server object ets
adds the database ets.db to the object database object.db.

The script add.dependencies.to.server is for adding information about how the server will resolve any formulae or functions in the primary databases, and may thus add secondary databases which the server will access. The script takes two arguments, the first indicating a database where the relationships are defined (sys.db below) and the second indicating the object databases which is being built. The sys.db contains case series indicating how dependencies are to be resolved. An example is generated by the script mk.sysdb which is used for generating a test example.
example:
add.dependencies.to.server object sysdb/sys
adds the relationships indicated in sysdb/sys.db to object.db.

The script add.function.to.server is for adding the location of any locally defined functions the server may need in order to resolve formulae or functions in the primary databases. It takes 11 arguments. The first is the name of the object database.
example:
add.function.to.server object COMPARE_F5_FUNC1 padi test function compare SHARE SERIES ANNUAL PRECISION COMPARE.F5.ANNUAL FUNCTION local/compare

For serving a large number of Fame databases (40 or more), especially if Fame formulae are used, it may be necessary to increase the number of files which the process can open (the Unix Borne shell ulimit). See additional notes in the example script start.ets

The make Utility

The makefile should first be generated using the configure script. The make utility will compile a local mode server (padi_fame.local) and a public mode server (padi_fame.public), and the fame procedures (.pro files). The FAME environment variable should be set to point to the appropriate Fame libraries. For example:

FAME=/.../fame75r6s

and the LD_LIBRARY_PATH should include the location of Fame hli code:

LD_LIBRARY_PATH=...:$FAME/hli

To test the system

Files to test the server are placed by make in the directory $PADI_HOME/tests. The script run.tests in the directory fame.server will cd to $PADI_HOME/tests and run a test of the local mode server and two tests of the public mode server. The scripts print information at various steps. In particular watch for ...ok indicated when each of the three tests completes successfully. The tests are run using calls to the generic.client programs getpadi and putpadi. The scripts start.user and start.ets are also installed by make into $PADI_HOME/tests. These will not work as the data is assumed to already exist, however, they might be examined for reference.

Distribution Files

fame.server: script to start a background server. This is the script which would typically be run by an application to start a local mode server (padi_fame.local). It is intended primarily for a local mode server but optional arguments can be used to start a public mode server (padi_fame.public).
cleanup.fame.server: script to terminate a background server. This script which would typically be run by an application to terminate a local mode server (padi_fame.local). It takes as an argument the information returned by the script fame.server.
check.server: script to check if a server is running on a specified machine
killserver: script to terminate a server process
add.db.to.server: script to load databases into an object database for a public mode server
add.dependencies.to.server: script to load databases dependencies into an object database for a public mode server
add.exceptions.to.server: script to load exceptions into an object database for a public mode server
add.function.to.server: script to load location of local functions into an object database for a public mode server
add.readdb.to.server: script to load read databases into an object database for a public mode server
add.writedb.to.server: script to load write databases into an object database for a public mode server
famec: script to compile Fame procedures (.pro to .pc)
compare.pro: Fame procedure used by scripts
object.pro: Fame procedure used by scripts
sys.pro: Fame procedure used by scripts
target.pro: Fame procedure used by scripts
configure: script to build a makefile for a particular compiler.OS combination. (eg. to generate a makefile for the GNU compiler on Sun5 systems use: configure gnu.Sun5 )
make.add.*.*: compiler.OS specific instructions for make
makefile.base: common instructions for make
gmalloc.c: a link to ../protocol.code/gmalloc.c
padi.c: a link to ../protocol.code/padi.c
fame_svc.c: C source code for the server
run.tests: script to run all tests
test.local.mode.server: script to test the local mode server
test.local.mode.server.output.reference: test output for comparison
test.public.mode.server: script to test the public mode server
test.build.databases: script to build test databases for test2.public.mode.server
test.public.mode.server.output.reference: test output for comparison
test.clean: script to remove databases and directories created by tests
start.user: example script (will not actually work as the data is assumed to already exist)
start.ets: example of a script used to start a public mode server used internally at the BOC

Generated Files

$PADI/bin/*

the executable code, several scripts and compiled Fame procedure are copied to this directory

$PADI/tests/*

several testing scripts are copied to this directory

$PADI/bin/padi_fame.local

the local mode server executable code

$PADI/bin/padi_fame.public

the public mode server executable code

$PADI/bin/fame_svc.o

compiled C object code for producing executable

gmalloc.o

compiled C object code for producing executable

*.pc

compiled Fame procedures

Everything you wanted to know about the FAME Server object database but were afraid to ask

obj_sysdbpath: (scalar) path and name of database containing case series used for resolving formulas referencing other FAME databases
obj_dbdir: (scalar) path to databases being served by FAME server
obj_link.dbname: (case series) names of databases being served (must exist in obj_dbdir)
obj_link.access: (case series) access mode of corresponding database in
obj_link.dbname: (options are READ, SHARED or UPDATE) - NOTE: SHARED can give some very unpredicatable results if more than one client writing to the databases.
objectname.obj: (where 'objectname' is the name of an object appearing in the case series, obj.name). This is a scalar: - if value is 0, then objectname is not served, even though it exists in a database which is being served. This is referred to as an "exclusion". - if a value exists, it is an index into all the case series starting with "obj.". This could represent what is referred to as "exceptions". That is, the database in which this object is located is not served, but only a few objects are served in that database. It could also represent the logical name of a FAME function (its real name is found in the case series obj.fame_name and the path to the FAME procedure containing the function is found in "obj.fame_ldpath").
obj.name: name of corresponding object in "objectname" part of objectname.obj scalar
obj.class: resultant class of objectname
obj.type: resultant type of objectname
obj.freq: resultant frequency of objectname
obj.desc: description of objectname
obj.dbname: database where objectname is located (or location of objects required for function)
obj.access: access mode of obj.dbname (SHARED, READ or UPDATE)
obj.fame_name: actual function name or same as obj.name
obj.fame_class: actual class of objectname
obj.fame_ldpath: Load path for FAME procedure containing function
add.*: scripts to create the above FAME objects in the object database.

Status and Known Bugs

Fri May 24 1996.

If the server gives the message "GetSeries ERROR# 1002: attempt to open too many databases" and the client displays "Error Message: attempt to open too many databases" then it is necessary to increase the number of file handles for the process.

Go to Table of Contents