Hello Good Folks

My application uses UniVerse (version 10.1 on Windows XP) and
UniObjects for Java.

The application has a number of UniVerse processes that are associated
with UniObjects Session instances that my code creates. When I do LISTU
I get entries with Terminal No values like uvcs:1234 (as opposed to
telnet:9876 for example) representing these processes.

Normally, I can use the LOGOUT command to "kill" processes. For
example, if a process has a Terminal No of telnet:9876 I can LOGOUT
9876 and it works perfectly.

Unfortunately, I cannot figure out a way to do this for the UniObject
Session related processes. Thus, if a process has a Terminal No of
uvcs:1234 then I login to Universe using telnet and type LOGOUT 1234
nothing happens. The command completes silently (with no error
messages) but when I type LISTU the entry for uvcs:1234 is still there.

Do you possibly know if it is possible to "kill" such processes in
Universe and how to acheive it?

Thanks you very much
Anthony

Using the UniAdmin "Users" screen should work just fine.

Martin Phillips, Ladybridge Systems.

Martin:

I'm not sure this works. I've tried it numerous times with UniData and
MV.NET and it never worked...I always had to restart UniData.

Bill

P.S. I learned what was going on with MV.NET and was able to disconnect by
using their tools.

"None" <MartinPhillips (AT) ladybridge (DOT) com> wrote

Thanks for the hint - alas, I already tried it and it doesn't work
either :-(

Cheers
Anthony

These 'Users' will timeout and go away by themselves in apx 30 minutes.
I have the same problem. IBM is 'working' on it now.



In article <XIadnYFgIKZF-EzZnZ2dnUVZ_vWdnZ2d (AT) comcast (DOT) com>,
you (AT) notreally (DOT) com says...

Bill H wrote:

What I have had to do until now is first kill the process from within
the windows task manager and then LOGOUT pid within Universe.
Frustrating that I cannot do it in a single step.

Anthony

Are you confusing socket port with PID/port? I believe Universe on
Windows identifies the port as the Windows process ID. It looks like
you're trying to LOGOUT on the socket port.

HTH
T

"Anthony Lauder" wrote:

Tony:

I don't think so. Here's what an "LU" gives:

These are the UniVerse users presently sharing the system.

uid User No User Name Terminal No Login Time
0 2968 NT AUTHORITY\system uvdlock:2968 Aug 2 22:06
* 0 776 ASIBILL\wphaskett telnet:776 Aug 3 17:29

There are currently 2 users logged on the system.

One usually needs to logoff the UserNo. On UniData this is different:

1 Intel (0)-> LU

Licensed(UDT+CP)/Effective UdtSqliPhtmPooledTotal

( 10 + 0 ) / 10 10001

UDTNO USRNBR UID USRNAME USRTYPE TTY IP-ADDRESS TIME DATE
1 3216 197615 wphaskett udt pts/1 192.168.1.51 17:31:25 Aug 03
2006

2 2588 197615 wphaskett phantom pts/2 Console 19:53:45 Aug 02
2006

One should log off the UsrNbr. Hope this helps.

Bill

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

One thing I learned on Friday about this problem.
The sessions do complete and disappear immediately when you are using a
winform app. It appears to only be when you are linking in from a web
page that they hang around. The IBM Rep had me run one of the samples
that came with UniDK and it worked perfectly. It was doing nothing
differently than I was in my web app, 'cept mine was a web app.






In article <s7udnZcYrfnBC0_ZnZ2dnUVZ_oednZ2d (AT) comcast (DOT) com>,
you (AT) notreally (DOT) com says...

Curt wrote:
Oh boy, here is a dump of thoughts, hope it makes sense.

A thick client usually makes a persistent connection for one user, and
goes through a nice wrapup process when the user closes the app.
A thin client needs to hit and run much faster than a thin client.

Theory #1 is that if you are trying to instantiate and then terminate
a session within a single web session, that there isn't enough time
for the close to occur before the client destructs. That could leave
the server trying to close a connection without a client, and leave it
in a hung state.

Theory #2: the fact that your connection seems to wrap itself up in 30
minutes reminds me of the TIME_WAIT condition of sockets. This is a
perfectly normal condition but some people (and programs) insist on
trying to brutally terminate a process if it doesn't go from LISTENING
or ESTABLISHED to dead within some number of seconds. I'm guessing
that the code is not wrapping itself up for some reason and that it's
remaining in a TIME_WAIT condition.

Theory #3: If you're using ASP or ASP.NET then _where_ and _when_ you
instantiate, store, and destroy your connection objects is critical.
Some people instantiate a new DBMS connection on every transaction,
which (per theories 1 and 2) will eventually leave the server in a
wierd state. Some people handle everything in Session State, others
in Application State. There are trade-offs for both.

Theory #4: Curt, you didn't say so, but if you are using VB6 with ASP,
for example, objects don't clean up their own memory, and if you just
null a DBMS object (for whatever reason), you might be leaving a
memory reference hanging. In .NET, most objects are cleaned up
properly through garbage collection, but there are some classes that
do not inherit from IDisposable which must be wrapped up manually -
otherwise you have the same hanging problem. A series of ASP.NET
transactions that instantiates objects without wrapping them up is
bound to result in issues like this. I have no idea if the classes of
UO.NET inherit from IDisposable. Even if your own code implements the
Dispose pattern and use class Destructors, garbage collection is not
guaranteed to happen immediately, thus leaving the possibility of
objects hanging around when they shouldn't, or not being properly
wrapped up when you expect.

Again, I just banged that out quickly and I hope it makes sense.

<ad>
FWIW, UO and UO.NET are free, but issues like this could cost you.
mv.NET is not free but it is priced very reasonably, and these sorts
of problems simply do not exist in this product. Contact me for more
info.
</ad>

Good luck.
Tony
TG@ removethisNebula-RnD.com