Novell Cool Solutions

4 – Tao Files and Drivers


October 1, 2007 6:07 pm





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:

>d2h 45050

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:

>h2d AFFA

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.

Good luck.

1 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 5 (1 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.

Categories: GroupWise


Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:Flyingguy

    Ohhh you mean a REAL (N)OS like NetWare?

    Linux FanBoys! Enjoy your ride at the company that NetWare built sonny boy.

    Sheesh, and people that *I* wrote flame bait.

  2. By:Flyingguy

    Ohhh and it would have been just *TO* difficult to give the file name something that resembles the driver source, yet still provides a unique name. Then again I guess you programmers that only use *REAL* OS’s never really learned that putting a bit of information in the file name would actually make life simpler. Ohh wait I forgot you *REAL* OS users *prefer* things convoluted and hidden so you can justify your pithy blog entries about using pipes and obscure little programs.

  3. By:Paul

    bc is available on windows as well.
    You just need to install unix-utils available from

    Ah the power of real tools on windows.

    Only question I have is can i get the EID using an LDAP query?

  4. By:Aaron Burgemeister

    Wow! This is the biggest response I’ve ever had. So I’ll respond to both of you right quick…

    While a bit off-topic, a NOS like NetWare can do all this as well and in fact ‘bc’ has been ported to NetWare on your OES boxes so I think the entire thing will still work (maybe create an NCF to do the work, but the pieces are all there. While I enjoy Novell and my “ride” there I don’t think I can give complete credit for Linux to Novell…. at least not yet.

    On your second comment (you were really on a roll!) nine minutes later the name was an example, and in fact I said “my file’s name” which hopefully made it clear that it was my choice. I happen to have a good memory, and there are a LOT of conversion tools out there written in this same format. dec2hex or decimal2hexadecimal would have worked, but why type it out? I’m even an above-average typist but come on… I’m in the business of solutions, not typing.

    Paul, thank-you for that update. Good to know I can put ‘bc’ on windows. I usually throw Cygwin on there but haven’t even checked to see if that comes with ‘bc’ but your post will help even those out there without Cygwin. In response to your query, yes you can get the EID directly (and in decimal form as it turns out). All you need to do is use ldapsearch (or whatever), specify the filter to find your driver(s), and then request just the localentryid attribute.

    For example to get my admin user’s EID from one box:

    ab@abbox:~> ldapsearch -h -p 389 -D cn=admin,dc=user,dc=system -x -W cn=admin localentryid
    Enter LDAP Password:
    # extended LDIF
    # LDAPv3
    # base with scope subtree
    # filter: cn=admin
    # requesting: localentryid

    # admin, user.system
    dn: cn=admin,dc=user,dc=system
    localEntryID: 32880

    Thanks to you all.

  5. By:Aaron Burgemeister

    In good new news I have managed to get some permission for sharing good future news. The Identity Manager 3.6 plugins for iManager will actually show you the TAO file name in two places:

    1. Driver Statistics dialog (new to the IDM 3.6 plugins and requires the IDM 3.5.1 engine)

    2. Driver Cache Inspector property page. You can get to this page by editing the properties of a driver object.

    So there you go. This should make life a bit nicer once this version is available for those who would rather use iManager.

    Good luck.

  6. By:Paul

    Thanks Aaron,

    I knew about the dec2hex for drivers i just wasnt sure i could get the EID.
    Good to see someone knows the LDAP side of edir enough to respond so quickly.


  7. By:Paul

    So now i am confused.
    Why is isconverted to hex at all if the id is in decimal?
    Ah well not a big issue just curious.

    This makes it even easier to identify the driver.


  8. By:pvl

    Come now flyingguy — many of us miss the heady days of Netware dominance. But the reality is Novell killed its own products. And continues doing so today. The one shred of hope for a once-proud company is to finally fully realize that OSS is the future. Until/unless that realization occurs, the company will continue to struggle. I think even IDM and GW will fall prey to those who cling to the “glorious” Netware proprietary delusion.

    If the company does not go OSS all the way .. then the only chance for survival, is to be purchased by private equity. IMHO