LISTSERV - HP3000-L Archives

HP3000-L Archives

May 2002, Week 2

HP3000-L@RAVEN.UTC.EDU

	LISTSERV Archives
	HP3000-L Home
	HP3000-L May 2002, Week 2

	Log In
	Register

	Subscribe or Unsubscribe

	Search Archives

Options:	Use Monospaced Font Show Text Part by Default Show All Mail Headers
Message:	[<< First] [< Prev] [Next >] [Last >>]
Topic:	[<< First] [< Prev] [Next >] [Last >>]
Author:	[<< First] [< Prev] [Next >] [Last >>]

Subject:	Re: IP address mapping to session number
From:	"PAUL,GUY (HP-Boise,ex1)" <[log in to unmask]>
Reply To:	PAUL,GUY (HP-Boise,ex1)
Date:	Thu, 9 May 2002 16:26:51 -0400
Content-Type:	text/plain
Parts/Attachments:	text/plain (68 lines)

ODBCLOG.ODBCSE may have some useful info for you. It will at least
tell you what dbe and the user.acct the client has to use to connect.

Guy (don't call me Paul) Paul :-}

-----Original Message-----
From: John Penney [mailto:[log in to unmask]]
Sent: Thursday, May 09, 2002 14:21
To: [log in to unmask]; [log in to unmask]
Subject: RE: IP address mapping to session number

Paul:

I do think you are correct: each Pin is a unique "thread" for that
particular SQL inquiry, no more and no less, and when it has completed, it's
'gone'-  in which case what I'm attempting to do is futile. The Pin I guess
simply identifies the process. Maybe I'll need to add some functionality to
the application login to help me track the users?

Back to you-all.

Thanks!

JP

>>> "PAUL,GUY (HP-Boise,ex1)" <[log in to unmask]> 05/09/02 12:31PM >>>
Since you are using an ODBC listener all you get will be
a PIN and IP address. The clients connecting to the listener
do not "logon" as in session.

Do a showconn job=job# of ODBCLNSE job.

To get rid of the offending process you should be able to use abortproc,
available with the right patches.

HTH

-----Original Message-----
From: John Penney [mailto:[log in to unmask]]
Sent: Thursday, May 09, 2002 12:08
To: [log in to unmask]
Subject: Re: IP address mapping to session number

Listers:

Thanks! to all of you who replied.

Now, I'll be a little more specific as your ideas, although sound, don't
address my situation:

I have 2 ODBC listeners jobs - MBFoster - running on our 3000. Occasionally,
like 7PM on a Wednesday evening, I get paged because one of the jobs has
'locked up' the system.

What I need is the ability to translate the Pin and IP address to a Session
# so that I can locate the rogue "SQL from Hell" that is beating the HP into
submission and call the offending Session. More info required?

TIA

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2

RAVEN.UTC.EDU