Hello Baanboard,

We have a problem where one user is getting a delayed response when opening a common session. We've plugged her into different segments of the network and other users are not having the problem. It doesn't make a difference if somebody different logs into her computer or baan.

The session is tdinv1550m000 Display Planned Inventory Transactions by Item.

Does anyone know what may be causing this? Also are there any tables in baan or HP-UX that shows the user connections and associated mac-addresses? Is there a way to clear it?

Thanks

Is this session customized in your environment?
Have u tried debug (with profiling or not)?
Maybe could be something related to that user in the program...

Check the Authorization sessions for this user..The user must be having some sort of restrictions or in other words "conditions" defined for the inv or itm sessions or tables...If the session opens fine for other user but not for this particular user, then it can only mean that there are some conditions running behind for this user when the so called session is opened.

If not, then someone must have applied some black magic to her username..:D .. Try deleting and creating the username again...

sk

Thanks for the replies!

This session is not custom.
If I login with the superuser account there's still about a 12 second delay to open the session only on this computer.

Thanks,

Try replacing the NIC with another one. If it happens only on this PC, might be a hardware issue. If that doesnt solve the problem then uninstall baan on this PC(delete all the baan related files in the baan folder to make sure no baan files exists after the uninstallation). Re-install it and see if there is any difference...

sk

Relpacing the NIC is a temporary workaround but the problem looks to be happening what a lot more of our users. I've checked the NIC brand and driver versions and there's no consistency.

I've done a packet sniff on the users having problems and I'm seeing TCP-Retransmissions because BaaN says the Checksum is Incorrect. Our other employees who performe the exact same function do not get this error. The delay for the packet retranmissions is the exact same delay time it takes to open the session.

Do you know why BaaN or HP-UX would think the checksum is incorrect and asking for retransmissions for certain people?

Since it appears for only some users, whats the major hardware and software differences between the users who dont face this problem and those who does...

sk

All of our desktop and laptops are standard Dell issue and it's happening to both groups of users. The person I originally generated the Post for has a Dell laptop with a Broadcom NetExtreme 57xx NIC. I put a wireless card in her laptop and she is fine for now.

Today I had another person call about the problem on their Dell desktop. I did a packet sniff, and sure enough, they were getting the error "TCP Retransmission, CHECKSUM INCORRECT". They had an Intel Pro 1000 MT NIC and I replaced it with a Reltek 10/100 card and it fixed the errors

It seems that a different MAC address fixes it's communication with BaaN. Is there something in BaaN or HP-UX that stores MAC sessions? Maybe this is becoming corrupted or stale?

Thanks!

UPDATE: When I had initially entered this post, I fixed the user who was having trouble opening "Display Planned Inventory Transactions by Item", by putting in a wireless card and disabling the onboard Broadcom NetExtreme 57xx NIC.

We that person just called today complaining of a similar issue on her wireless. I verified that the wireless was behaving the same way with the TCP CHECKSUM INCORRECT, so I disabled it and plugged her back into the orignal NIC, and VIOLA the problem has corrected itself! No more CHECKSUM ERRORS.

This behavior is one thing that seems to be consistent in all my testing. Some people just deal with it a couple weeks until it resolves itself.

I personally dont think Baan stores any addresses once a user logs out. Since i am not familiar with HP-UX, i cant suggest anything. Although i should add, this sort of behaviour is pointing towards your server and client connection. Are you using static or dynamic ip? Are the server side nic clashing with the client side ones? You didnt mention anything about the server side hardware config(especially the nic)..

Faced somewhat same problem as yours with Outlook quite some time back. It wouldnt connect to the exchange server untill i pressed the retry button twice while outlook was opening. I changed the nic to the same manufacturer as the server nic and everything started working normally...

Could it be the same?

sk

The server has a static IP and the clients are all dynamic. From all my testing it seems the findings are pointing to the server. I haven't tested anything from the server-side yet and I'm unsure of the exact hardware because it's managed by our "Systems" group. I'll gather all my findings and present to them shortly...