responses below
It sounds like nothing has changed. From what you're posted so far. Is
that correct?
pretty much, we added etherchannel to the aix system but its been
running fine for several months, since the issue started we have changed
our app to add better logging but no major changes to the code
I guess you've confirmed this is not file corrupt issue with the UV
files being accessed?
yes we have scanned all our files and have not found an issue
It appears your VB application is read/writing directly to UV files
directly and this is where you're having issues? Is it corrupting your
UV file in the process?
at one point we were seeing corrupt data but that turns out to be
related to the 10.2 uniobjects dll we installed
You vaguely mention you have rebooted your AIX server. Is that correct?
yes twice
Do you use dynamic files?
yes, lots of em
What version of AIX, UV and UniDK are using?
aix = 5.2.6
uv = 10.1
unidk = 3.5.2
It seems like you've already checked the UniObjects and Unirpcd logs -
have you check the UV errlog too? Anything interesting in that?
are they different?
I have tons of uvapi.log_<pid> which are uniobjects logs is it possible
to log the uvrpc daemon?
Do you have separate server for testing/development or DR that you can:
1) test this same client software & your UV application/UniObjects?
2) restore (using your backups of your DB, source & object code + *very
importantly* the UV home directory) your production data to and re-test
the UniObjects-based app?
we have tested against our dev system and seem to get the same error at
Objective: determine if the issue is 1) client application is at fault,
regardless of the target server it is communicating with or 2) database
or application issue (rather than a client one).
Other things to try:
1) write a simple UniObjects app (Win32 or Java versions) to read/write
to the same file
2) a *completely clean* install the VB6/UniObjects app. This should be a
clean PC which has never ever had the client application or UniObjects
installed before. If you site has a "standard desktop configuration",
then you should be using that or perhaps use a PC that is
"non-standard". Have you rolled a new firewall or VPN client or similar
network-invasive type application recently?
we completely reloaded a term server that we have users login to (they
run the app from here) and are still seeing the issue(s)
Objective: 1) determine if it is UniObjects issue or not 2) determine if
the problem is desktop PC or not (the latter by using a non-standard
build PC).
we have tried restoring PC(s) to a date BEFORE we started having
problems (using windows system restore) and still they are failing
I have seen strange things happen with the U2 API before. So capturing
the output from your UniObject sessions is a good one. If you have the
code to your VB application - you can get it to turn on a COMO file.
Given it a unique name for each session or user-ID (maybe the UNIX
process ID too - eg., myuserid-date-PID.como)
I will recommand that we try this
If your VB code is calling (directly or indirectly or dependent on some
initialisation code) host-based BASIC subroutines (or indeed any
cataloged referenced program) check if these have changed and re-catalog
them all, regardless. I have seen "go away" after re-cataloging code -
both at TCL invocation level and via the APIs.
Good luck!
thanks!
dougc
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
