Does determining which TAO file goes with which driver object on which server cause you grief? Let’s work on that a little bit.
Here’s a quickie for all of you who are on a real OS. For those stuck on windows you’ll need to find a decent command-line calculator to have the same fun. For everybody everywhere you can always use any calculator app (gcalctool, kcalc, calc (windows), bc (this example), etc.).
So what we’re going to learn today is how to interpret those pesky TAO files. If you don’t know already each driver has a TAO file which stores events from the engine that are pending for that driver. For example if a user’s given name changes it needs to be sent to the eDirectory and microsoft active directory (MAD) systems. If the driver is busy doing something else that event is written to the TAO file to prevent it from getting lost (technically I think it’s written there regardless but I’m making a point here). As the engine gets finished the new event is read from the TAO file, processed, and eventually removed (various algorithms exist across IDM versions for when the TAO file is rewritten).
So the problem many administrators find quickly is determining which TAO file goes with which driver. They are all in the eDirectory DIB directory and they all have decimal-number names which don’t go with the object name at all. Several TIDs explain that the TAO file name is actually the eDirectory object’s Entry ID (EID) converted from hexadecimal to decimal (base 16 to base 10). This conversion is trivial in a calculator but having one open and then comparing them with the EIDs in iMonitor just makes for a lot of steps. To do the conversion in one less window a simple script can be whipped up. SLED/SLES come with `bc` which is ‘An arbitrary precision calculator language’ according to its man page.
Create a new file (‘d2h’ will be my file’s name) in a part of the filesystem that is in your user’s path. This could be the ‘bin’ directory in your user’s home directory or it could be something as universal as /usr/bin or /usr/local/bin (you’ll need ‘root’ rights to do this in a univeral path). Make the file executable (`chmod +x /path/to/theFileYouCreated`) and then edit it placing the following line inside the file:
echo “obase=16;$1″ | bc
Save the file and now test it:
Tada… you gave the command-line file a parameter (the TAO file name was 45050.TAO) and it gave you the EID to find in iMonitor. From here all kinds of fun things can happen. First let’s get the reverse down just in case it’s useful (it’s a little more-tricky):
New file again, called h2d (hex to decimal) with the following contents:
echo “obase=10; ibase=16; $1″ | bc
So now we do the opposite of the command above:
Wonderful, so we have the basic conversion licked. Playing with ‘bc’ on your own time can be a very rewarding experience so I recommend it. It is important at this point to note that EIDs are server-specific (unlike GUIDs which are universally-unique) so if you have drivers on multiple servers (one active, one dormant) they will probably have a different EID on every server. Also two drivers on different servers (whether the same driver object or not) could have the same EID between those two servers. Just make sure you realize that the EID is only unique on that one server. When using iMonitor to view the EID of the driver object be sure you have pointed iMonitor to the server on which you are viewing the TAO file (in case multiple servers have the driver as mentioned above) or you’ll pull your hair out trying to figure out why the values don’t match up.
For somebody who is a scripting wizard it wouldn’t be too difficult to write something like ‘lstao’ that, when it found a file like 45050.TAO, automatically converted it to the hex number while leaving the other data behind. I may work on this but it’s late so not tonight.