|
|
|
|
|
|
TM_MIB(5)
Name
TM_MIB—Management Information Base for core BEA Tuxedo system
Synopsis
#include <fml32.h>
#include <tpadm.h>
Description
The BEA Tuxedo System MIB defines the set of classes through which the fundamental aspects of an application can be configured and managed. This includes management of machines, servers, networking.
TM_MIB(5) should be used in combination with the generic MIB reference page MIB(5) to format administrative requests and interpret administrative replies. Requests formatted as described in MIB(5) using classes and attributes described in this reference page may be used to request an administrative service using any one of a number of existing ATMI interfaces in an active application. Inactive applications may also be administered using the tpadmcall() function interface. For additional information pertaining to all TM_MIB(5) class definitions, see TM_MIB(5) Additional Information.
TM_MIB(5) consists of the following classes.
Each class description consists of four sections:
Attribute Table Format
Each class that is a part of this MIB is defined in four parts in sections that follow. One of the four parts is the attribute table. The attribute table is a reference guide to the attributes within a class and how they may used by administrators, operators, and general users to interface with an application.
There are five columns for each attribute described in an attribute table: name, type, permissions, values, and default. Each of these components is discussed in MIB(5).
TA_FLAGS Values
MIB(5) defines the generic TA_FLAGS attribute, which is a long containing both generic and component MIB specific flag values. The following are the TM_MIB(5) specific flag values supported. These flag values should be or'd with any generic MIB flags.
FML32 Field Tables
The field table for the attributes described in this reference page is found in the file udataobj/tpadm relative to the root directory of the BEA Tuxedo system software installed on the system. The directory ${TUXDIR}/udataobj should be included by the application in the colon-separated list specified by the FLDTBLDIR environment variable, and the field table name tpadm should be included in the comma-separated list specified by the FIELDTBLS environment variable.
Limitations
Access to the header files and field tables for this MIB is being provided only on BEA Tuxedo release 6.1 sites and later, both native and Workstation.
Workstation access to this MIB is limited to runtime only access; the function tpadmcall(3c) is not supported on workstations.
For the purpose of preimage processing (MIB_PREIMAGE flag bit set), local attributes for classes that have global attributes are not considered. Additionally, indexed fields and the indexes that go with them are not considered, for example, T_TLOG class, TA_TLOGCOUNT, TA_TLOGINDEX, TA_GRPNO, TA_TLOGDATA attributes.
T_BRIDGE Class Definition
Overview
The T_BRIDGE class represents run-time attributes pertaining to connectivity between logical machines making up an application. These attribute values represent connection status and statistics.
Attribute Table
1All attributes in Class T_BRIDGE are local attributes.
2The TA_LMID attribute must be fully specified for SET operations, that is, LMID1,LMID2.
3SET operation may only use TA_NETGROUP DEFAULTNET in BEA Tuxedo release 6.4. GET operation may use any TA_NETGROUP defined for both LMID values.
4TA_SUSPTIME may be SET only if the TA_STATE is currently SUSPENDED or is being SET to SUSPENDED.
5The link-level encryption value of 40 bits is provided for backward compatibility.
Attribute Semantics
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Limitations
None.
T_CLIENT Class Definition
Overview
The T_CLIENT class represents run-time attributes of active clients within an application. These attribute values identify and track the activity of clients within a running application.
Attribute Table
1All attributes in Class T_CLIENT are local attributes.
2The link-level encryption value of 40 bits is provided for backward compatibility.
Attribute Semantics
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Note: Some port numbers may be reserved for the underlying transport protocols (such as TCP/IP) used by your system. Check the documentation for your transport protocols to find out which numbers, if any, are reserved on your system.
Limitations
None.
T_CONN Class Definition
Overview
The T_CONN class represents run-time attributes of active conversations within an application.
Attribute Table
1All attributes in Class T_CONN are local attributes.
Attribute Semantics
|
ACTive |
The object returned reflects one or both sides of an active conversation within the application. |
Limitations
None.
T_DEVICE Class Definition
Overview
The T_DEVICE class represents configuration and run-time attributes of raw disk slices or UNIX system files being used to store BEA Tuxedo system device lists. This class allows for the creation and deletion of device list entries within a raw disk slice or UNIX system file.
Attribute Table
1All attributes in Class T_DEVICE are local attributes.
2TA_DEVINDEX is required for SET operations to identify the particular device list entry except when setting the state to NEW for the purpose of creating a new device list entry. In the latter case, TA_DEVINDEX must not be set; a value will be assigned by the system and returned after a successful creation.
3TA_DEVSIZE may only be SET on object creation.
Attribute Semantics
|
VALid |
The BEA Tuxedo filesystem indicated by TA_CFGDEVICE exists and contains a valid device list. TA_DEVICE is a valid device within that filesystem with the device index telnet lchome3. |
Limitations
None.
T_DOMAIN Class Definition
Overview
The T_DOMAIN class represents global application attributes. These attribute values serve to identify, customize, size, secure, and tune a BEA Tuxedo system application. Many of the attribute values represented here serve as application defaults for other classes represented in this MIB.
There is exactly one object of the T_DOMAIN class for each application. Because of this, there are no key fields defined for this class. A GET operation on this class will always return information representing this single object. Likewise, a SET operation will update it. GETNEXT is not permitted with this class.
Attribute Table
1UID and GID as known to the UNIX system
2num must be a multiple of 5
3Specify num so that num times TA_SCANUNIT is approximately "Default"
Attribute Semantics
|
ACTive |
T_DOMAIN object defined and the master machine is active. |
|
INActive |
T_DOMAIN object defined and application is inactive. |
Note: The SIGNAL notification method is not available for MS-DOS clients.
(2) Setting TA_SYSTEM_ACCESS to PROTECTED may not be effective for multithreaded servers because it is possible that while one thread is executing BEA Tuxedo code, which means it is attached to the bulletin board, another thread might be executing user code. The BEA Tuxedo system cannot prevent such situations.
Note: If the NO_AA value is enabled in the TA_OPTIONS parameter, the security parameters NONE, APP_PW, and USER_AUTH will continue to work properly—except that no authorization or auditing will take place. The remaining modes of security, ACL and MANDATORY_ACL will continue to work properly—but will only use the default BEA security mechanism.
Limitations
Many attributes of this class are tunable only when the application is inactive. Therefore, use of the ATMI interface routines to administer the application is not possible. The function tpadmcall() is being provided as a means of configuring or reconfiguring an unbooted application. This interface may only be used for configuration (SET operations) in an inactive application and only on the site being configured as the master site for the application. Once an initial configuration is created and activated, administration is available through the standard ATMI interfaces as described in MIB(5).
T_FACTORY MIB
Overview
The T_FACTORY MIB class represents occurrences of factories registered with the FactoryFinder. The available factories for the application are reflected in this MIB and can be shown to the administrator via the Administration Console or command-line tools. The scope is global.
Attribute Table
The following state indicates the meaning of a TA_STATE returned in response to a GET request:
|
ACTive |
The T_FACTORY object is registered with the FactoryFinder. |
T_GROUP Class Definition
Overview
The T_GROUP class represents application attributes pertaining to a particular server group. These attribute values represent group identification, location, and DTP information.
Attribute Table
Attribute Semantics
OPENINFO = "TUXEDO/QM:qmconfig:qspace"
OPENINFO = "TUXEDO/QM:qmconfig;qspace"
OPENINFO = "TUXEDO/QM:qmconfig;qspace"
OPENINFO = "TUXEDO/QM,[a.b.c]qmconfig,qspace"
Limitations
None.
T_IFQUEUE Class
Overview
The T_IFQUEUE MIB class represents run-time attributes of an interface as it pertains to a particular server queue (T_QUEUE) in a CORBA environment. This is primarily a read-only class providing access to the inherited configuration attributes of an interface as well as statistics relating to the interface on the queue. Additionally, this class gives administrators finer granularity in suspending and activating interfaces. This class provides the link between an interface name and the server processes capable of processing method invocations on the interface, that is, TA_RQADDR can be used as a key search field on the T_SERVER class.
Attribute Table
T_INTERFACE Class
Overview
The T_INTERFACE MIB class represents configuration and runtime attributes of CORBA interfaces at both the domain and server group levels.
A domain-level T_INTERFACE object is one that is not associated with a Server Group. Its TA_SRVGRP attribute contains a NULL string (string of length 0, "").
A server group level T_INTERFACE object is one that has an associated server group (i.e., its TA_SRVGRP attribute contains a valid server group name for the domain). This Server Group level representation of an interface also provides a container for managing interface state (TA_STATE) and for collecting accumulated statistics.
An associated server group level T_INTERFACE object must exist for any CORBA Interfaces that are activated in a server. The activation of interfaces in a server is controlled by the state of a T_IFQUEUE object for the interface. Activation of a T_IFQUEUE object causes its attributes to be initialized with the values specified for the associated server group level T_INTERFACE object. If such an object does not exist, then one will be dynamically created. This dynamically-created server group level T_INTERFACE object will be initialized with the attributes of the domain level T_INTERFACE object for the interface if one exists. If an associated domain level T_INTERFACE object does not exist, system specified default configuration values will be applied. Once activated, interfaces are always associated with a server group level T_INTERFACE object.
The specification of configuration attributes for interfaces at any level is completely optional, system defined defaults will be provided and run-time server group level T_INTERFACE objects will be created. Interfaces to be offered by a server are identified via the ICF file used to generate server skeletons and advertised automatically by the system at server activation time.
Attribute Table
Implementation Hint
The T_INTERFACE MIB is a mapping from an interface to a BEA Tuxedo service. The MIB server can implement some of the get/set operations for an interface by calling the existing logic for the associated T_SERVICE object.
T_MACHINE Class Definition
Overview
The T_MACHINE class represents application attributes pertaining to a particular machine. These attribute values represent machine characteristics, per-machine sizing, statistics, customization options, and UNIX system filenames.
Attribute Table
1TA_LMID and TA_PMID must each be unique within this class. Only one of these fields is required as a key field for a SET operation. If both are specified, then they must match the same object.
2Default is same as value set for this attribute in Class T_DOMAIN.
3Default is TA_APPDIR for this machine followed by /ULOG.
4The link-level encryption value of 40 bits is provided for backward compatibility.
Attribute Semantics
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Limitations
SHM mode (see T_DOMAIN:TA_MODEL) applications can have only one T_MACHINE object. MP mode (see T_DOMAIN:TA_MODEL) applications with the LAN option set (see T_DOMAIN:TA_OPTIONS) may have up to the maximum number of configurable T_MACHINE objects as defined by the T_DOMAIN:TA_MAXMACHINES attribute. Many attributes of this class are tunable only when the application is inactive on the site. Since the master machine at least must be active in a minimumly active application, the use of the ATMI interface routines to administer the application is not possible with respect to the master machine object. The function tpadmcall() is being provided as a means configuring an unbooted application and may be used to set these attributes for the master machine.
T_MSG Class Definition
Overview
The T_MSG class represents run-time attributes of the BEA Tuxedo system managed UNIX system message queues.
Attribute Table
1All attributes in Class T_MSG are local attributes.
Attribute Semantics
|
ACTive |
T_MSG object active. This corresponds exactly to the related T_MACHINE object being active. |
Limitations
This class is UNIX system-specific and may not be supported in non-UNIX implementations of BEA Tuxedo system.
T_NETGROUP Class Definition
Overview
The T_NETGROUP class represents application attributes of network groups. Network groups are groups of LMIDs which can communicate over the TA_NADDR network addresses defined in the T_NETMAP class.
Attribute Table
Attribute Semantics
|
VALid |
T_NETGROUP object is defined and inactive. Note that this is the only valid state for this class. NETGROUPs are never ACTive. |
Limitations
None.
T_NETMAP Class Definition
Overview
The T_NETMAP class associates TA_LMIDs from the T_MACHINE class in the TM_MIB to a TA_NETGROUP object from the T_NETGROUP class. In other words, this class contains assignments of logical machines to network groups. A TA_LMID may be included in many TA_NETGROUP groups. When one LMID connects to another LMID, the BRIDGE process determines the subset of network groups to which the two LMIDs belong. When the pair of LMIDs are in several common groups, they are sorted in descending TA_NETPRIO order (TA_NETGRPNO is the secondary sort key). The Network groups with the same TA_NETPRIO will flow network data in parallel. Should a networking error prevent data from flowing through all the highest priority group(s), only then the next lower priority network group(s) are used for network traffic (failover). All network groups with a higher priority than the ones flowing data are retried periodically. Once a network connection is established with a higher TA_NETPRIO value, no further data is scheduled for the lower priority one. Once the lower priority connection is drained, it is disconnected in an orderly fashion (failback).
Attribute Table
1 The link-level encryption value of 40 bits is provided for backward compatibility.
Attribute Semantics
|
VALid |
T_NETMAP object is defined. Note that this is the only valid state for this class. Network mappings are never ACTive. |
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Limitations
None.
T_QUEUE Class Definition
Overview
The T_QUEUE class represents run-time attributes of queues in an application. These attribute values identify and characterize allocated BEA Tuxedo system request queues associated with servers in a running application. They also track statistics related to application workloads associated with each queue object.
Note that when a GET operation with the MIB_LOCAL flag is performed in a multi-machine application, multiple objects will be returned for each active queue—one object for each logical machine where local attribute values are collected.
Attribute Table
Attribute Semantics
Limitations
None.
T_ROUTING Class Definition
Overview
The T_ROUTING class represents configuration attributes of routing specifications for an application. These attribute values identify and characterize application data-dependent routing criteria with respect to field names, buffer types, and routing definitions.
Attribute Table
1TA_BUFTYPE only applies to ATMI data-dependent routing criteria. TA_FIELDTYPE only applies to CORBA factory-based routing criteria. The specified u (uniqueness) permission applies only in the relevant case. That is: the combination of TA_ROUTINGNAME, TA_TYPE and TA_BUFTYPE must be unique for TA_TYPE=SERVICE, and TA_ROUTINGNAME, TA_TYPE and TA_FIELD must be unique for TA_TYPE=FACTORY.
The TA_TYPE attribute determines the permissible attributes for the TA_ROUTING object. TYPE=SERVICE corresponds to ATMI data-dependent routing criteria. TYPE=FACTORY corresponds to CORBA factory-based routing. The default is SERVICE. SET operations are assumed to be for data-dependent routing if no TA_TYPE is specified. Specification of TA_FIELDTYPE is invalid for data-dependent routing. Specification of TA_BUFTYPE is invalid for factory-based routing.
Attribute Semantics
"root_element[/child_element][/child_element][/. . .][/@attribute_name]"
Limitations
None.
T_SERVER Class Definition
Overview
The T_SERVER class represents configuration and run-time attributes of servers within an application. These attribute values identify and characterize configured servers as well as provide run-time tracking of statistics and resources associated with each server object. Information returned will always include fields that are common among all contexts of a server. In addition, for those servers that are not defined to the system as multicontexted (that is, those for which the value of TA_MAXDISPATCHTHREADS is 1), this class includes information about the server's context. For those servers that are defined to the system as multicontexted, placeholder values are reported for per-context attributes. Per-context attributes can always be found as part of the T_SERVERCTXT class. The T_SERVERCTXT class is defined even for single-contexted servers.
The TA_CLTLMID, TA_CLTPID, TA_CLTREPLY, TA_CMTRET, TA_CURCONV, TA_CURREQ, TA_CURRSERVICE, TA_LASTGRP, TA_SVCTIMEOUT, TA_TIMELEFT, and TA_TRANLEV attributes are specific to each server dispatch context. All other attributes are common to all server dispatch contexts.
Attribute Table
1Defaults to value set for this attribute in Class T_DOMAIN
Attribute Semantics
SUSpended | PARtitioned | DEAd}
Note: If you choose to do redirection or piping on a Windows 2000 system, you must use one of the following methods:
Note: If you choose to do redirection or piping on a Windows 2000 system, you must use one of the methods listed in the description of the TA_RCMD attribute.
Note: If you choose to do redirection or piping on a Windows 2000 system, you must use one of the methods listed in the description of the TA_RCMD attribute.
Limitations
None.
T_SERVERCTXT Class Definition
Overview
The T_SERVERCTXT class represents configuration and run-time attributes of individual server dispatch contexts within an application. This class is defined for both single-context and multi-context servers. For single-context servers, the values in this class are repeated as part of the T_SERVER class. The attributes in the T_SERVERCTXT class are read-only.
These attribute values provide run-time tracking of statistics and resources associated with each server dispatch context.
Attribute Table
1All attributes in Class T_SERVERCTXT are local attributes.
Attribute Semantics
Limitations
None.
T_SERVICE Class Definition
Overview
The T_SERVICE class represents configuration attributes of services within an application. These attribute values identify and characterize configured services. A T_SERVICE object provides activation time configuration attributes for services not specifically configured as part of the T_SVCGRP class. Run-time information about services active in the application is provided solely through the T_SVCGRP class. Run-time updates to the T_SERVICE class are usually not reflected in active T_SVCGRP objects (TA_ROUTINGNAME is the exception).
Both the T_SERVICE class and the T_SVCGRP class define activation time attribute settings for service names within the application. When a new service is activated (advertised), either due to initial activation of a server or due to a call to tpadvertise(), the following hierarchy exists for determining the attribute values to be used at service startup time.
The specification of configuration attributes for application services is completely optional, that is, services advertised by servers as they are activated will take on the established default service attribute values if configured values are not available (see above for a description of how attribute values are identified at service activation time). Service names to be offered by a server are built in at run time (see buildserver(1)) and may be overridden by the command-line options specified for a server object (see T_SERVER:TA_CLOPT and servopts(5)).
Attribute Table
Attribute Semantics
Limitations
None.
T_SVCGRP Class Definition
Overview
The T_SVCGRP class represents configuration and run-time attributes of services/groups within an application. These attribute values identify and characterize configured services/groups, and provide run-time tracking of statistics and resources associated with each object.
Both the T_SERVICE class and the T_SVCGRP class define activation time attribute settings for service names within the application. When a new service is activated (advertised), either due to initial activation of a server or due to a call to tpadvertise(), the following hierarchy exists for determining the attribute values to be used at service startup time.
The specification of configuration attributes for application services is completely optional, that is, services advertised by servers as they are activated will take on the established default service attribute values if configured values are not available (see above for a description of how attribute values are identified at service activation time). Service names to be offered by a server are built in at run time (see buildserver(1)) and may be overridden by the command-line options specified for a server object (see T_SERVER:TA_CLOPT and servopts(5)).
Once a T_SVCGRP object is active, it is represented solely by the T_SVCGRP class. A particular service name/group name combination may have more than one associated T_SVCGRP class at run time if there are multiple servers within the group offering the service.
Attribute Table
1SET operations on this class must specify sufficient key fields to uniquely identify the object being addressed. If the object is active, then it may be necessary to augment the TA_SERVICENAME and TA_SRVGRP key fields with either TA_RQADDR or TA_SRVID. Modifications to an active object will affect that object and the related configuration record but not other active objects that may have derived their run-time attributes from the same configuration record.
2If nothing is specified for this attribute, it defaults to TA_SERVICENAME.
Attribute Semantics
Limitations
None.
T_TLISTEN Class Definition
Overview
The T_TLISTEN class represents run-time attributes of the BEA Tuxedo system listener processes for a distributed application.
Attribute Table
Attribute Semantics
|
INActive |
T_TLISTEN object not active. |
|
ACTive |
T_TLISTEN object active. |
Limitations
This class is not available through the tpadmcall() interface.
T_TLOG Class Definition
Overview
The T_TLOG class represents configuration and run-time attributes of transaction logs. This class allows the user to manipulate logs within an application, that is, create, destroy, migrate, and so on.
Attribute Table
1All attributes in Class T_TLOG are local attributes
2One or more TA_GRPNO and TA_TLOGDATA attribute values may be returned with each object of the T_TLOG class. The attribute values for each of these attributes belonging to the particular object are the TA_TLOGCOUNT number of occurrences beginning with the TA_TLOGINDEX.
Attribute Semantics
Limitations
None
T_TRANSACTION Class Definition
Overview
The T_TRANSACTION class represents run-time attributes of active transactions within the application.
Attribute Table
1All attributes in Class T_TRANSACTION are local attributes.
2One or more TA_GRPNO and TA_GSTATE attribute values may be returned with each object of the T_TRANSACTION class. The attribute values for each of these attributes belonging to the particular object are the TA_GRPCOUNT number of occurrences beginning with the TA_GRPINDEX.
Attribute Semantics
SUSpended}
Limitations
None.
T_ULOG Class Definition
Overview
The T_ULOG class represents run-time attributes of userlog() files within an application.
Attribute Table
1All attributes in Class T_ULOG are local attributes.
2TA_LMID is a required field used by the system to determine which application log file should be accessed. It is not used to restrict returned records to only those generated from processes running on the indicated machine. In cases where multiple machines share a log file via a networked filesystem, multiple TA_LMID values may be returned even though a specific value has been provided as a key field. For the same reasons, TA_PMID is not considered in directing the request to a particular machine, but is used in determining which records should be returned. In this capacity, it may be useful to leverage TA_PMID as a regular expression key field.
Attribute Semantics
|
ACTive |
The object returned reflects an existing user log file on the indicated logical machine. |
Limitations
Retrievals may be done only if the associated T_MACHINE object is also ACTive.
Retrievals for this class must be directed, that is, the TA_LMID attribute must be specified. Retrievals of log records written by Workstation clients are available only if the log file used by the client is shared with one of the machines defined in the T_MACHINE class for the application. Otherwise, these log records are unavailable through this class.
Retrievals on this class which cannot be completely satisfied will always return a TA_MORE value of 1 indicating only that more information may be available for the originating request.
TM_MIB(5) Additional Information
Diagnostics
There are two general types of errors that may be returned to the user when interfacing with TM_MIB(5). First, any of the three ATMI verbs ( tpcall(), tpgetrply(), and tpdequeue()) used to retrieve responses to administrative requests may return any error defined for them. These errors should be interpreted as described on the appropriate reference pages.
If, however, the request is successfully routed to a system service capable of satisfying the request and that service determines that there is a problem handling the request, then failure may be returned in the form of an application level service failure. In these cases, tpcall() and tpcall() will return an error with tpgetrply() set to TPESVCFAIL and return a reply message containing the original request along with TA_ERROR, TA_STATUS, and TA_BADFLD fields further qualifying the error as described below. When a service failure occurs for a request forwarded to the system through the TMQFORWARD(5) server, the failure reply message will be enqueued to the failure queue identified on the original request (assuming the -d option was specified for TMQFORWARD).
When a service failure occurs during processing of an administrative request, the FML32 field TA_STATUS is set to a textual description of the failure, and the FML32 field TA_ERROR is set to indicate the cause of the failure as indicated below. All error codes are guaranteed to be negative.
The following diagnostic codes are returned in TA_ERROR to indicate successful completion of an administrative request. These codes are guaranteed to be non-negative.
Interoperability
The header files and field tables defined in this reference page are available on BEA Tuxedo release 6.1 and later. Fields defined in these headers and tables will not be changed from release to release. New fields may be added which are not defined on the older release site. Access to the AdminAPI is available from any site with the header files and field tables necessary to build a request.
If sites of differing releases, both greater than or equal to BEA Tuxedo release 6.1, are interoperating, then information on the older site is available for access and update as defined in the MIB reference page for that release and may be a subset of the information available in the later release.
Portability
The existing FML32 and ATMI functions necessary to support administrative interaction with BEA Tuxedo system MIBs, as well as the header file and field table defined in this reference page, are available on all supported native and workstation platforms.
Examples
This section contains a sequence of code fragments that configure, activate, query, and deactivate a two node application using both tpadmcall() and tpcall(). Variable names are used in places where reasonable values for a local environment are required, for example, TUXCONFIG is a two element array of character pointers with each element identifying the full pathname of the TUXCONFIG file on that machine.
Field Tables
The field table tpadm must be available in the environment to have access to attribute field identifiers. This can be done at the shell level as follows:
$ FIELDTBLS=tpadm
$ FLDTBLDIR=${TUXDIR}/udataobj
$ export FIELDTBLS FLDTBLDIR
Header Files
The following header files are included.
#include <atmi.h>
#include <fml32.h>
#include <tpadm.h>
Libraries
${TUXDIR}/lib/libtmib.a, ${TUXDIR}/lib/libqm.a,
${TUXDIR}/lib/libtmib.so.<rel>, ${TUXDIR}/lib/libqm.so.<rel>,
${TUXDIR}/lib/libtmib.libThe libraries must be linked manually when using buildclient. The user must use: -L${TUXDIR}/lib -ltmib -lqm
Initial Configuration
The following code creates and populates an FML32 buffer that is then passed to tpadmcall() for processing. This example also shows interpretation of tpadmcall() return codes. The request shown creates the initial configuration for the application.
/* Allocate and initialize the buffer */
ibuf = (FBFR32 *)tpal loc("FML32", NULL, 4000);
obuf = (FBFR32 *)tpalloc("FML32", NULL, 4000);
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
/* Set TM_MIB(5) attributes to be set in T_DOMAIN class object */
Fchg32(ibuf, TA_OPTIONS, 0, "LAN,MIGRATE", 0);
Fchg32(ibuf, TA_IPCKEY, 0, (char *)&ipckey, 0);
Fchg32(ibuf, TA_MASTER, 0, "LMID1", 0);
Fchg32(ibuf, TA_MODEL, 0, "MP", 0);
/* Set TM_MIB(5) attributes for TA_MASTER T_MACHINE class object */
Fchg32(ibuf, TA_LMID, 0, "LMID1", 0);
Fchg32(ibuf, TA_PMID, 0, pmid[0], 0);
Fchg32(ibuf, TA_TUXCONFIG, 0, tuxconfig[0], 0);
Fchg32(ibuf, TA_TUXDIR, 0, tuxdir[0], 0);
Fchg32(ibuf, TA_APPDIR, 0, appdir[0], 0);
Fchg32(ibuf, TA_ENVFILE, 0, envfile[0], 0);
Fchg32(ibuf, TA_ULOGPFX, 0, ulogpfx[0], 0);
Fchg32(ibuf, TA_BRIDGE, 0, "/dev/tcp", 0);
Fchg32(ibuf, TA_NADDR, 0, naddr[0], 0);
Fchg32(ibuf, TA_NLSADDR, 0, nlsaddr[0], 0);
/* Perform the action via tpadmcall() */
if (tpadmcall(ibuf, obuf, 0) 0) {
fprintf(stderr, "tpadmcall failed: %s\n", tpstrerror(tperrno));
/* Additional error case processing */
}
Add Second Machine
The following code reuses the buffers allocated in the previous section to build a request buffer. The request shown below adds a second machine to the configuration established earlier.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_MACHINE", 0);
Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
/* Set TM_MIB(5) attributes to be set in T_MACHINE class object */
Fchg32(ibuf, TA_LMID, 0, "LMID2", 0);
Fchg32(ibuf, TA_PMID, 0, pmid[1], 0);
Fchg32(ibuf, TA_TUXCONFIG, 0, tuxconfig[1], 0);
Fchg32(ibuf, TA_TUXDIR, 0, tuxdir[1], 0);
Fchg32(ibuf, TA_APPDIR, 0, appdir[1], 0);
Fchg32(ibuf, TA_ENVFILE, 0, envfile[1], 0);
Fchg32(ibuf, TA_ULOGPFX, 0, ulogpfx[1], 0);
Fchg32(ibuf, TA_BRIDGE, 0, "/dev/tcp", 0);
Fchg32(ibuf, TA_NADDR, 0, naddr[1], 0);
Fchg32(ibuf, TA_NLSADDR, 0, nlsaddr[1], 0);
tpadmcall(...) /* See earlier example for detailed error processing */
Make Second Machine Backup Master
The existing buffers are again reused to identify the newly configured second machine as the backup master site for this application.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
/* Set TM_MIB(5) T_DOMAIN attributes changing *
Fchg32(ibuf, TA_MASTER, 0, "LMID1,LMID2", 0);
tpadmcall(...); /* See earlier example for detailed error processing */
Add Two Server Groups
Reuse the buffers to generate two requests, each adding one server group to the configured application. Note how the second request simply modifies the necessary fields in the existing input buffer.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_GROUP", 0);
Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
/* Set TM_MIB(5) attributes defining first group */
Fchg32(ibuf, TA_SRVGRP, 0, "GRP1", 0);
Fchg32(ibuf, TA_GRPNO, 0, (char *)&grpno[0], 0);
Fchg32(ibuf, TA_LMID, 0, "LMID1,LMID2", 0);
tpadmcall(...); /* See earlier example for detailed error processing */
/* Set TM_MIB(5) attributes defining second group */
Fchg32(ibuf, TA_SRVGRP, 0, "GRP2", 0);
Fchg32(ibuf, TA_GRPNO, 0, (char *)&grpno[1], 0);
Fchg32(ibuf, TA_LMID, 0, "LMID2,LMID1", 0);
tpadmcall(...); /* See earlier example for detailed error processing */
Add One Server Per Group
Reuse the allocated buffers to add one server per group to the configured application.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_SERVER", 0);
Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
/* Set TM_MIB(5) attributes defining first server */
Fchg32(ibuf, TA_SRVGRP, 0, "GRP1", 0);
Fchg32(ibuf, TA_SRVID, 0, (char *)&srvid[0], 0);
Fchg32(ibuf, TA_SERVERNAME, 0, "ECHO", 0)
tpadmcall(...); /* See earlier example for detailed error processing */
/* Set TM_MIB(5) attributes defining second server */
Fchg32(ibuf, TA_SRVGRP, 0, "GRP2", 0);
Fchg32(ibuf, TA_SRVID, 0, (char *)&srvid[1], 0);
tpadmcall(...); /* See earlier example for detailed error processing */
Add Routing Criteria
Add a routing criteria definition. Note that routing criteria may be dynamically added to a running application using a similar operation via the tpcall() interface.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_ROUTING", 0);
Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
/* Set TM_MIB(5) attributes defining routing criteria */
Fchg32(ibuf, TA_ROUTINGNAME, 0, "ECHOROUTE", 0);
Fchg32(ibuf, TA_BUFTYPE, 0, "FML", 0);
Fchg32(ibuf, TA_FIELD, 0, "LONG_DATA", 0);
Fchg32(ibuf, TA_RANGES, 0, "MIN-100:GRP1,100-MAX:GRP2", 26);
tpadmcall(...); /* See earlier example for detailed error processing */
Add Service Definition
Define a service object that maps the advertised service name to the routing criteria defined above.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_SERVICE", 0);
Fchg32(ibuf, TA_STATE, 0, "NEW", 0);
/* Set TM_MIB(5) attributes defining service entry */
Fchg32(ibuf, TA_SERVICENAME, 0, "ECHO", 0);
Fchg32(ibuf, TA_ROUTINGNAME, 0, "ECHOROUTE", 0);
tpadmcall(...); /* See earlier example for detailed error processing */
Activate Master Site Admin
Activate the master site administrative processes (DBBL, BBL, BRIDGE) by setting the T_DOMAIN class object state to ACTIVE.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
Fchg32(ibuf, TA_STATE, 0, "ACT", 0);
tpadmcall(...); /* See earlier example for detailed error processing */
Switch to Active Application Administration
Now that the application is active, we need to join the application and make our AdminAPI requests via the tpcall() interface.
/* Now that the system is active, join it as the administrator */ tpinfo = (TPINIT *)tpalloc("TPINIT", NULL, TPINITNEED(0));
sprintf(tpinfo->usrname, "appadmin");
sprintf(tpinfo->cltname, "tpsysadm");
if (tpinit(tpinfo) < 0) {
fprintf(stderr, "tpinit() failed: %s\n", tpstrerror(tperrno));
/* Additional error case processing */
}
/* Reinitialize buffers as typed buffers */
Finit32(ibuf, Fsizeof32(ibuf));
Finit32(obuf, Fsizeof32(obuf));Activate Rest of Application
Activate the remaining portions of the application. Note that the administrative user may request unsolicited notification messages be sent just before and just after the attempted boot of each server by setting the TMIB_NOTIFY flag in the TA_FLAGS attribute of the request. This example shows handling of an error return from tpcall().
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_MACHINE", 0);
Fchg32(ibuf, TA_STATE, 0, "RAC", 0);
/* Set TM_MIB(5) attributes identifying machine */
Fchg32(ibuf, TA_LMID, 0, "LMID1", 0);
/* Invoke the /AdminAPI and interpret results */
if (tpcall(".TMIB", (char *)ibuf, 0, (char **)&obuf, &olen, 0) < 0) {
fprintf(stderr, "tpcall failed: %s\n", tpstrerror(tperrno));
if (tperrno == TPESVCFAIL) {
Fget32(obuf,TA_ERROR,0,(char *)&ta_error,NULL);
ta_status = Ffind32(obuf, TA_STATUS, 0, NULL);
fprintf(stderr, "Failure: %ld, %s\n",
ta_error, ta_status);
/* Additional error case processing */
}
Query Server Status
Generate a query on the status of one of the activated servers.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "GET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_SERVER", 0);
flags = MIB_LOCAL;
Fchg32(ibuf, TA_FLAGS, 0, (char *)&flags, 0);
/* Set TM_MIB(5) attributes identifying machine */
Fchg32(ibuf, TA_SRVGRP, 0, "GRP1", 0);
Fchg32(ibuf, TA_SRVID, 0, (char *)&srvid[0], 0);
tpcall(...); /* See earlier example for detailed error processing */
Deactivate Application
Deactivate the application by setting the state of each machine to INACTIVE. Note that the TMIB_NOTIFY flag could be used with this operation also.
/* Clear the request buffer */ Finit32(ibuf, Fsizeof32(ibuf));
/* Shutdown Remote Machine First */
/* Set MIB(5) attributes defining request type */
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_MACHINE", 0);
Fchg32(ibuf, TA_LMID, 0, "LMID2", 0);
Fchg32(ibuf, TA_STATE, 0, "INA", 0);
tpcall(....); /* See earlier example for detailed error processing */
/* And now application servers on master machine *
flags = TMIB_APPONLY;
Fchg32(ibuf, TA_FLAGS, 0, (char *)&flags, 0);
Fchg32(ibuf, TA_LMID, 0, "LMID1", 0);
tpcall(...); /* See earlier example for detailed error processing */
/* Terminate active application access */
tpterm();
/* Finally, shutdown the master admin processes */
Finit32(ibuf, Fsizeof32(ibuf));
Fchg32(ibuf, TA_OPERATION, 0, "SET", 0);
Fchg32(ibuf, TA_CLASS, 0, "T_DOMAIN", 0);
Fchg32(ibuf, TA_STATE, 0, "INA", 0);
tpadmcall(...); /* See earlier example for detailed error processing */
Files
${TUXDIR}/include/tpadm.h, ${TUXDIR}/udataobj/tpadmSee Also
tpacall(3c), tpalloc(3c), tpcall(3c), tpdequeue(3c), tpenqueue(3c), tpgetrply(3c), tprealloc(3c), Introduction to FML Functions, Fadd, Fadd32(3fml), Fchg, Fchg32(3fml), Ffind, Ffind32(3fml), MIB(5), WS_MIB(5)
Setting Up a BEA Tuxedo Application
Administering a BEA Tuxedo Application at Run Time
Programming BEA Tuxedo ATMI Applications Using C
Programming BEA Tuxedo ATMI Applications Using FML
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|