Mass Loader hangs due to incorrect DB address return from XT

I am using Tamino on Windows Server 2000.
I have a batch file that invokes inoxmld.exe to load and unload data from Tamino database.
I have XTS trace enable.
When I execute the batch file from a DOS windows, the process completes within seconds.
Looking at the XTS trace log, I can see the XTS service lookup and return the correct database address defined in xtsurl.cfg file (XTSaccess.Tamino:DBname.tcpip//hostname:3210 ), which is the XML XTS port for the requested database.
When I run an ‘asp’ application, which then calls the same batch file, the whole process takes longer than 10 minutes to complete. Looking at the XTS trace log, XTS kept returning the admin port address of the requested database (XTSaccess.TaminoI:DBname.tcpip//hostname:3298 ) instead the correct XML XTS port 3210. The process got stuck in this loop for a while before XTS finally select and return the correct port address 3210 to the requestor.
Would someone please explain why XTSaccess.TaminoI entry was selected instead of XTSaccess.Tamino entry ? and how to resolve this problem ?

The XTS traces that returns the admin port address was probably generated from different requests during this same windows. I now realized that I was perused via the Tamino Manager during this time frame also, so that’s probably where those traces came from. Please ignore this remark.
But my original problem still persists, which is running inoxmld.exe via shell command takes a second or two; Running inoxmld from ‘asp’ program within IIS was delayed up to 10, 15minutes.