Menu
  • ABOUT US
  • WHAT WE DO
  • OUR WORK
    • Close
  • NEWS
  • BLOG
  • CONTACT

Getting More Out of Oracle Tuxedo Part Three: The TMIB

So, the last time around, I talked about TXRPT, and how you can get detailed performance statistics out of Tuxedo. As the last topic in this three parter, I wanted to talk about the TMIB. If you’ll forgive the 90s flashback, the TMIB is kind of like The Matrix for Tuxedo. Everything you do, every change you make via administration tools, every command you use to bring back the current status of something, goes through the .TMIB service. It underpins everything.

By design, Tuxedo shows you a limited subset of the information available on any object in tmadmin, even in verbose mode. There’s a whole other set of object properties that aren’t shown. Some are useful, some aren’t. This information is organised into Management Information Bases, or MIBs. Each MIB defines a number of classes, and each class has a series of available properties. You can find the list of MIBs available for Tuxedo 11.1.1.3 here.

There are two primary uses you can put this knowledge to – using the information in the MIB to create your own monitoring to pull back specific properties, or to create scripts that perform dynamic configuration. Both of these rely on the .TMIB service, which can be invoked by the ud32 utility. There’s actually two versions of the utility – a 16 bit and 32 bit version, but it’s pretty rare that you’d use the 16 bit version, given the limits around the number of fields and amount of data that can be passed around.

Using ud32

So how do you use ud32? It actually started life as an FML (field manipulation language) testing client, and can still be used for that. We’re going to use it to invoke the .TMIB service, which uses FML. So we’ll need to set some FML environment variables before doing anything else. Assuming that TUXDIR has already been set, the following command will do the job:

export FLDTBLDIR32=$TUXDIR/udataobj
export FIELDTBLS32=tpadm,Usysfl32

FLDTBLDIR32 sets the list of directories Tuxedo will look in for FML field table files. At the moment, we just want it to look in the udataobj directory underneath our Tuxedo installation.

FIELDTBLS32 sets the list of actual files to look for.

Once we’ve done that, we need an input file to send to ud32. Let’s say we want to get back information on all defined servers. We need to specify the following fields:

  • TA_CLASS – the specific MIB class we’re going to interact with
  • TA_OPERATION – what are we going to try to do? (this can be GET, GETNEXT or SET)
  • SRVCNM – the service we’re calling, which will always be ‘.TMIB’ for TMIB operations

We put this information into a file with a very specific format – tab-delimited, with a blank line at the end of the file. The order of the individual fields in the file is unimportant, as they’ll all go into an FML request buffer, which is like a hashmap, so it’s unordered. For my very simple Tuxedo simpapp application that I’m running, I use the following input file:

TA_CLASS<tab>T_SERVER
TA_OPERATION<tab>GET
SRVCNM<tab>.TMIB
<blank line>

And that gets me back all properties on all existing services. I’ve cropped the output, but here’s a sample:

SENT pkt(1) is :
SRVCNM .TMIB
TA_CLASS T_SERVER
TA_OPERATION GET

RTN pkt(1) is :
TA_ERROR 0
TA_MORE 0
TA_OCCURS 5
TA_BASESRVID 1
TA_BASESRVID 30001
TA_BASESRVID 30002
TA_BASESRVID 30003
TA_BASESRVID 0
TA_GENERATION 1
TA_GENERATION 1
TA_GENERATION 1
TA_GENERATION 1
TA_GENERATION 1
TA_GRACE 86400
TA_GRACE 0
TA_GRACE 0
TA_GRACE 0
TA_GRACE 0
TA_GRPNO 1
TA_GRPNO 1
TA_GRPNO 1
TA_GRPNO 1
TA_GRPNO 30002
TA_MAX 1
TA_MAX 1
TA_MAX 1
TA_MAX 1
TA_MAX 1
TA_MAXGEN 1
TA_MAXGEN 0
TA_MAXGEN 0
TA_MAXGEN 0
TA_MAXGEN 0

In displaying output, ud32 lists all instances of a particular field, then the next field, and so on. You match up data for a particular server instance by using field values at the same position. In the output above, the second instance of TA_BASESRVID provides information for the same server that the second instance of TA_MAXGEN does. By grabbing all field values at a particular index, you get a complete picture for that particular server. That’s probably the most confusing part of dealing with ud32.

Getting selective with TA_FILTER

There’s a lot of fields in there, and chances are we’re only interested in a limited number of them. That’s where TA_FILTER comes in. If we’re only interested in the server name, server ID, and process ID, then we can specify three different TA_FILTER values in our request – the field IDs for each of these fields. The easiest way to find the individual field IDs is to grep for the field name in the $TUXDIR/include directory. It’s the number in bold that we’re interested in:

[email protected]:/opt/tuxedo11gR1/include$ grep TA_PID *
tpadm.h:#define TA_PID ((FLDID32)33560784) /* number: 6352 type: long */

So with the three relevant field IDs in our input buffer, it now looks like:

TA_CLASS<tab>T_SERVER
TA_OPERATION<tab>GET
SRVCNM<tab>.TMIB
TA_FILTER<tab>33560784
TA_FILTER<tab>167778539
TA_FILTER<tab>33561135
<blank line>

Which then returns:

SENT pkt(1) is :
TA_FILTER 33560784
TA_FILTER 167778539
TA_FILTER 33561135
SRVCNM .TMIB
TA_CLASS T_SERVER
TA_OPERATION GET

RTN pkt(1) is :
TA_ERROR 0
TA_MORE 0
TA_OCCURS 5
TA_PID 21948
TA_PID 21945
TA_PID 21946
TA_PID 21947
TA_PID 21941
TA_SRVID 1
TA_SRVID 30001
TA_SRVID 30002
TA_SRVID 30003
TA_SRVID 0
TA_CLASS T_SERVER
TA_SERVERNAME /opt/tuxedo11gR1/samples/atmi/simpapp/simpserv
TA_SERVERNAME /opt/tuxedo11gR1/bin/TMS
TA_SERVERNAME /opt/tuxedo11gR1/bin/TMS
TA_SERVERNAME /opt/tuxedo11gR1/bin/TMS
TA_SERVERNAME /opt/tuxedo11gR1/bin/BBL

The basics of using the .TMIB service to pull information back are pretty straightforward. It then becomes a matter of combing through the MIBs to find classes that are relevant to you.

Ch-ch-ch-changes (to your configuration at runtime)

It’s also possible to use the .TMIB service to perform dynamic configuration. It’s the same principle as using tmconfig, but without the unfriendly interactive interface. Let’s say for example that we’ve underestimated the volume of load on a given service, and we need to create additional server instances to deal with client load. We’ve already evaluated downstream performance for the services called by our server (remember the call graph in our first post on Tuxedo?) and we’re not going to cause a problem.

We could use the following command to change the TA_MAX setting for a T_SERVER entry, defining another two slots for servers: (assuming that TA_MAX was previously set to 1, as per the output from commands we ran earlier)

TA_CLASS<tab>T_SERVER
TA_OPERATION<tab>SET
SRVCNM<tab>.TMIB
TA_SRVID<tab>30003
TA_GRPNO<tab>1
TA_MAX<tab>3
<blank line>

This one’s a little trickier, too – as you’ll need to authenticate as the tpsysadm user in order to make configuration changes. If you don’t have authentication configured, it’s as straightforward as specifying the client name with ud32:

ud32 -C tpsysadm < setTAMax.ud32

Incidentally, this is why it’s a good idea to leave space in your ubbconfig server ID allocation scheme. Tuxedo assumes that servers will have sequential server IDs from the number supplied (TA_BASESRVID) up to the TA_MAX set, and it doesn’t deal well with conflicting server IDs.

So that’s the TMIB for you. Because dynamic configuration carries its own change control risks, we try to avoid it where possible, so the .TMIB service tends to get used more for making a series of administrative changes (like cycling servers or groups) or for monitoring. But it’s always nice to have options.

And that’s it for Tuxedo for now. if you’ve got questions around anything Tuxedo-related, or you’d like to see more examples, hit me up in the comments. If all goes to plan, I’ll be talking next week about getting performance statistics for HTTP-based services from OSB next week.

2 Comments

  • Bob says:

    FML32 buffer fields and MIBs, very nice start. Add in event brokers, usr or sys, and the administrative/monitoring/alert capabilities of Tuxedo are well on the way to be understood. Get skilled on the Tuxedo TSAM product and your are there. 

  • JB says:

    Kevin — I’ve been writing Tuxedo services for about a year; however I haven’t learned much about all the goodies Tuxedo has to offer — yet. I found your Tuxedo series really informative. I would love to see you put more educational goodies up if you have the chance.

Leave a Reply