Article

(View Disclaimer)

It is well known that the IDM driver cache files (#####.TAO) in the eDirectory DIB directory are named by the driver's object id number in eDirectory in decimal. The easiest way to get from a driver object to its associated #####.TAO file is to find the object in iMonitor, walk the replica ring to get to the server where the driver is running, and get the object id from there. This will be in hexadecimal like 000080A8. Now convert that to decimal (32936) and append a .TAO to it, and you will find that in the DIB directory, there is a 32936.TAO file.

This is easy enough to do, once, but gets to be a pain when you have to do it more than a few times, or when you are in a hurry. It is easy to check in the DIB directory to see if any of the cache files have grown to hold more events than should be there, but just because you can see one cache file is backed up, how do you quickly and easily figure out which driver that cache file goes to?

As part of my IDM project documentation, I have been maintaining a list of #####.TAO files along with the names of the drivers that they go with. That makes it somewhat faster and a little easier to notice that 32936.TAO is getting larger than default, and to map that back to the driver that this cache file goes with. But it's still a matter of looking at the name, looking it up in the list, then looking across to get to the driver name.

A long time ago, back in the bad old days of MSDOS, I used an alternate command shell that replaced command.com with something far more powerful. This was 4DOS. It did everything that command.com did, but it added many new features and functionality to make command line life a lot less unpleasant. One feature I found helpful for situations like this was its ability to describe various files in a directory. It was possible to use this to store limited text descriptions of the files. Then, in a directory listing, it would show the descriptive text along with the other file information.

Sadly, none of the popular Linux shells seem to have acquired this particular feature. But that's ok, because every Linux problem can be solved with one more pipeline.

Save the following script as 'describe'. I put it in ~/bin, which I have available on my path when I log in.

#!/bin/sh

while read input ; do
 NAME=`echo $input | awk '{ print $8 }'`
 if [ "$NAME" != "" ]
 then
   DESCR=`grep -h $NAME ~/.description | sed 's/[A-Za-z0-9.]* //'`
   if [ "$DESCR" == "" ]
   then
     echo "$input"
   else
     echo -e "$input \t<- $DESCR"
   fi
 fi
done

Now you will have to do some preparatory setup work. Go through all of your drivers, using iMonitor, and get the Entry ID (aka Object ID) for each one of them. Convert the hex values to decimal. Then create a ~/.description file containing the name of the file, and the descriptive text you want to display with it (like the driver name). it should look like:

32936.TAO eDir Driver 1
32944.TAO eDir Driver 2
46225.TAO eDir Driver 3

Now, when you change your current working directory to your DIB directory, you can use a command line like this:

user1@fs1:/var/nds/dib> ls -ltr *.TAO | describe
-rw-------  1 root root     72 2009-07-30 15:20 32936.TAO 	<- eDir Driver 1
-rw-------  1 root root     72 2009-07-30 15:20 32944.TAO 	<- eDir Driver 2
-rw-------  1 root root     72 2009-07-30 15:20 46225.TAO 	<- eDir Driver 3
-rw-------  1 root root     72 2009-09-06 19:32 32940.TAO 	<- WorkOrder
-rw-------  1 root root     72 2009-09-07 19:46 32943.TAO 	<- UserApp (UA351)
-rw-------  1 root root     72 2009-09-07 19:46 32931.TAO 	<- PeopleSoft HR
-rw-------  1 root root     72 2009-09-07 19:46 165746.TAO 	<- PeopleSoft Output
-rw-------  1 root root     72 2009-09-07 23:40 247952.TAO 	<- Java Heap Stats
-rw-------  1 root root     72 2009-09-07 23:40 32933.TAO 	<- Utilities
-rw-------  1 root root 281821 2009-09-07 23:40 32928.TAO 	<- eDir Driver (S3)
-rw-------  1 root root     72 2009-09-07 23:40 32917.TAO 	<- Active Directory

This will show the driver cache files, along with their size, and the descriptions you set up in the file. As you can see, eDir Driver (S3) is badly behind in event processing. The other drivers shown here are all caught up (72 byte cache files are the default now, with nothing in them).

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

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, test, test before you do anything drastic with it.