|
|
CC ... -lsysadm -lvtcl -ltclx -ltcl -lsocket -lgen -lm#include <scoadmin/osaStdDef.h>
void OFBinding(errStatusPtr, className, attributes, attributeCount, groups, groupCount, operations, operationCount, requestProcessor, osaDataPtr)
struct OSAAttr_t { attributeName_pt name; attributeToken_t token; char *validOperations; filterToken_t validFilters; OSACheckBit_t dataType; }These describe each attribute that can be accessed by this class. The fields in the OSAAttr_t are defined in the following way. attributeName_pt name is the name by which the users of the OSA will identify the attribute. The attributeToken_t token is an integer by which the OSA itself will identify the attribute when it gets or returns data to or from the SCOadmin services library. The char *validOperations is an string list of all the operations (besides create) which are allowed to work on this attribute. create is always allowed to work on any attribute (have that attribute include in the command line passed from the client). The filterToken_t validFilters is a union of all the valid filter operations that are allowed to reference this attribute. The filterToken_ts are defined in the <scoadmin/osaStdDef.h> file. The OSACheckBit_t dataType is a union of either ATTR_SINGLE or ATTR_SET and ATTR_LONG, ATTR_DOUBLE, or ATTR_STRING. This describes the type of data that the attribute contains.
struct OSAGroup_t { attributeName_pt name; char *assocAttrs; }These described the all the attribute groups that can be accessed by users of the class being bound. Any of the attributes listed in the OSAAttr_t table can be grouped together and referenced as one for convince sake. Only the Get and Replace-with-default actions can work on grouped attributes. The two fields in the OSAGroup_t arrays are as follows. The attributeName_pt name field represents what the users of the OSA will access the group of attributes by. The char *assocAttrs is a list of attributes found in the OSAAttr_t table which the SCOadmin services library will substitute the group name for before calling any OSA functions.
struct OSAOp_t { operationName_pt name; executionProcedure_fpt executionProcedure; OSACheckBit_t callPerAttribute; }This table defines all the operations that users of the class can call on. Each operations must list how it is to be called by the user (operationName_pt name), what C/C++ function the SCOadmin services library should call when the operation is to be performed (executionProcedure_fpt executionProcedure), and in what synchronization the procedure should be called (OSACheckBit_t callPerAttribute, which should contain either OP_PER_ATTR or OP_PER_OBJECT).
The OFBinding routine also allows the OSA to specify an request processor to handle incoming BMIP requests. If the OSA needs to perform such specialized functions as containment, synchronization, scoping or first pass validation; then it should provide a request processor and point to its location with this parameter.
The OFBinding routine also allows the OSA to attach a void pointer with every declared class. This pointer can point to anything, and is a useful way for multiple classes that are identical in function but not in data to be created. Simply call OFBinding once for each class, with the osaDataPtr pointing to different data storage areas. This variable is never examined by the SCO services library, and is forwarded to all functions in the OSA called by the library.