Re: Does a thread = a Pick process?

Low tech solution .....

Why not use your line number, read the PIBS record (assuming you don't
have your own "status" file somewhere), and if you are "logged on",
then you are a "real user", so run the trigger code ?

OR MAYBE SOMETHING LIKE THE FOLLOWING SUBROUTINE IN YOUR LOGON
PARAGRAPH

SUBROUTINE ONLINEUSER
COMMON /ONLINEUSER/ IAMANONLINEUSER
IAMANONLINEUSER = 1
RETURN


Include this COMMON in your trigger, and 

IF ASSIGNED(IAMANONLINEUSER) THEN <do your online code>

HTH


Ross Ferris
Stamina Software
Visage - an Evolution in Software Development


"Peter Kenyon" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> "Tony Gravagno" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > I'm hesitent to equate the word Process to equate to a D3NT user here.
> > In this context, one D3NT Windows Process (d3vme.exe) consists of many
> > Threads representing multiple D3 Users.
> >
> > When you boot there are around 10 base threads, regardless of the
> > number of PIBS vs Phantoms.  The first user that logs in may consume 3
> > new threads, but after that the number of threads is only 1 or 2 per
> > user.  To answer your question, once a thread is assigned to a given
> > process I don't believe it ever changes, but the problem is knowing
> > which one out of 2-3 threads to use to identify a user connection.  (I
> > know that's not "definitive" but I'd stake Kevin's life on it.  :)   )
> >
> > Isn't port number adequate enough for identifying users?  Thread IDs
> > are just as transient as port numbers if you're deciding which process
> > to isolate at runtime.
> >
> > Can you give us an example of what you're trying to do?  I'm curious
> > about how you'd apply this, and secondarily there may be a better way
> > to do it.
> >
> 
> Hi Tony,
> 
> Here is the code I am using:'
> 
> ! Check whether we are being called in context of the updating agent
> read agentinfo from log.entries.fv, 'agentinfo' then
>   agentthread = agentinfo<2>
>   if agentthread = '' then acnt = 0 else acnt = dcount(agentthread, @vm)
>   for i = 1 to acnt
>     if agentthread<1,i> = %GetCurrentThreadId() then return
>   next i
> end
> 
> The so-called "updating agent" is a phantom process which updates items in
> Pick files in response to changes in an SQL Server database. We want the
> trigger to RETURN if it is called as a result of that process's changes, but
> to execute for everything else.
> Checking the port number would be fine, and that is what we originally
> planned to do. However I haven't found any way to do this from within a
> trigger.
> 
> The %GetCurrentThreadId() calls a user-defined c function. Obviously this
> won't be a reliable way to determine the calling context if as you say a
> single process can be associated with more than one thread. Is there any
> other way? None of the usual methods such as 'who', system(22) or the user
> exit U50BB seem to work from within triggers.
> 
> Peter