The Cassandra Project banner
by Darryl Bond <>

#  Copyright (c) 2000 NRG Gladstone Operating Services.               |
#                       All Rights Reserved.                          |
#                                                                     |
#                                                                     |
#  This is free software; you can redistribute it and/or modify it    |
#  under the terms of the GNU General Public License as published by  |
#  the Free Software Foundation; either version 2 of the License, or  |
#  (at your option) any later version.                                |
#                                                                     |
#  This software is distributed in the hope that it will be useful,   |
#  but WITHOUT ANY WARRANTY; without even the implied warranty of     |
#  merchantability or fitness for a particular purpose. See the GNU   |
#  General Public License for more details.                           |
#                                                                     |
#  To obtain the GNU General Public License, write to:                |
#                                                                     |
#      Free Software Foundation, Inc.                                 |
#      59 Temple Place - Suite 330                                    |
#      Boston, MA  02111-1307                                         |
#      USA                                                            |

# $Log: README,v $
# Revision 1.2  2000/08/30 05:50:04  dbond
# Updated notes for use with AIM* historian.
# Change submitted by JMarkham (8/16/00)
# Revision 1.1  2000/03/19 22:07:43  dbond
# Initial revision
# $Id: README,v 1.2 2000/08/30 05:50:04 dbond Exp $

What it does:

This program allow Object Manager(OM) variables to be accessed in a similar way to omget/omset. Unlike omset/omget it does not broadcast for the data for each variable on each request. The PSAP address for each variable is found for the first request and stored in a database for subsequent requests. It does not use OM lists to minimise the continuous load on the CP OM lists.

How it works:

The server program (multisvc) runs on a Foxboro Sun Box and listens for Remote Procedure Call requests from the client program (omrd/omwr) which can run on a Foxboro box, a non-Foxboro Sun box or a Linux box. The server program forks a copy to service each request for data from the client.


gcc (Not tested with Sun CC)
GNU make
Foxboro OM libraries and headers (Foxboro AW or AP)


compressed source code and documentation (32 KB)

To Build:

Solaris Foxboro computer:

  1. Edit the Makefile to select the correct LDFLAGS line.
  2. Make the server.
    $ make multisvc
  3. Make the client.
    $ make omrd
  4. If there is no debugging to be done.
    $ make strip
  5. copy the client and server where required (/usr/local/bin/).
  6. Optionally clear all the object files etc.
    $ make clean
    If the software is to be built on Linux as well then you must do a 'make clean'

Linux (Tested on RedHat6.1 ...)

  1. Edit the Makefile to select the correct LDFLAGS line. Note that different LDFLAGS lines are used for the original historian and for the AIM* historian.
  2. Make the client.
    $ make omrd
  3. If there is no debugging to be done.
    $ make strip
  4. copy the client where required (/usr/local/bin/).
  5. Optionally clear all the object files etc.
    $ make clean

To Use:

  1. Can OM Variables be modified?

    The omrd will write (modify OM variables) if called omwr and multisvc is running as root. The Foxboro system will not allow OM modifiers to succeed if running as another user.

  2. Sizing in-memory point database

    By default, multisvc keeps an in-memory database of 500 points. If this is exceeded then multisvc will broadcast for the data. Therefore care must be taken when choosing the size of the database.

    This can be increased by giving an integer as an argument, ie.:

    # multisvc 5000&

    This will hold a database of up to 5000 points in memory. More points allocated use more RAM so this size should be optimal.

  3. What should run where?

    The multisvc program is started on a Foxboro box (AW/WP/AP) at startup but can be started anytime. The omrd program is the client and works similar to omget but with different syntax.

    A multisvc program running on each Foxboro node would be best to minimise traffic on other nodes.


          /usr/local/bin/multisvc [pointsize]&

    to a startup script.

To Test:

      omrd [AW/WP/AP running multisvc] C:B.P


will return (in my case)


Use of the client programs:

The client programs (omrd/omwr) can take up to 100 variables at a time and can read the data from the command line or from a file.

  1. omrd

    Typing omrd without arguments produces:

          usage: omrd host cbp cbp cbp cbp etc
          or omrd host -f 
          or omrd host -f - (for stdin)
          file format C:B.P whitespace or line delimited
  2. omwr

    Typing omwr without arguments produces:

          usage: omwr host [datatype] cbp value cbp value cbp valueetc
          or omwr host -f 
          or omwr host -f - (for stdin)
          file format datatype C:B.P value whitespace or line delimited

    datatypes may be used anywhere within the file to change to a new type. Types are +INT +FLOAT +STRING +BOOL +OM_BOOL +PKD_BOOL +PKD_LONG

    Due to poor command line parsing it is best, when sending different data types, to use a file or stdin. This part needs work to make better.

    This has problems:

          omwr [AW] +INT C:B.P value +FLOAT C:B.P value

    This works:

          echo '+INT C:B.P value +FLOAT C:B.P value' | omwr [AW] -f -

There is also some html files (rpc_client.html & rpc_server.html) which give a discription of the internal workings of the code.

Note: The included binaries will work only on an AW/WP running the legacy historian (or no historian - I think). For any other situation you will need to recompile. (jmarkham 8/16/00)


Darryl Bond <>
Specialist Computer Support
NRG Gladstone Operating Services

Copyright 2000 The Cassandra Project. All rights reserved.
web posted: 15 March 2000
last updated: 30 August 2000
Contact the webmaster for comments and/or questions.