A WBS (Work Breakdown Structure) is a valuable planning tool which is often overlooked in the rush to create a project schedule. A WBS is a tool defined in the PMBOK. It is a structured decomposition of the entire scope of the project. PRINCE2 also defines a similar planning mechanism…
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 184.108.40.206 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.
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:
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:
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 :
RTN pkt(1) is :
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
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:
Which then returns:
SENT pkt(1) is :
RTN pkt(1) is :
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)
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.