Writing a SCOadmin manager

Object call example

An example of a typical object call and its return value follows. This call gets the home directory for the user object charlesf:

   ObjectGet {sco user} {{{systemId colossus} charlesf}} pw_dir

It returns:

   {get {sco user} charlesf {{pw_dir /u/charlesf}} {} {} {}}

The return value consists of a Tcl list of responses (sometimes referred to as ``BMIP responses'') for each object. In this case there was only one object, charlesf. The return consists of seven fields, some of which are empty:

operation (get)
class of the object operated on ({sco user})
the hostname where the object is located (colossus)
name of the object (charlesf)
a list of attribute-value pairs belonging to the object ({{pw_dir /u/charlesf}})
- Only the attribute ``pw_dir'' was requested, and its value is ``/u/charlesf''
- If the ObjectGet had left out the {pw_dir} parameter, all of the attributes of the object would have been returned.
action type (only used for ObjectAction)
action data (only used for ObjectAction)
error information (there was no error)

Routines described in the Bmip(3tlib) manual page can be used in Tcl scripts to extract values of specific fields within BMIP responses.

The systemId attribute is the method by which networked object operations are performed under SCOadmin. The example object calls shown so far default to the local system in absence of the systemID attribute. When the objects to be managed are located elsewhere, the object designation must contain the systemId attribute along with the the name of the target system. This is often where the ``managed host name'' (defined at the very start of the manager) is used. We recommend that that all object calls include the systemId to ensure remote management capability.