Re: Does a thread = a Pick process?

"Tony Gravagno" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Steve's code is accurate.  A Trigger does run in a separate workspace
> from the PIB that executed the trigger.  You have to identify the
> original process from it's auto-generated user ID because there are no
> environment variables that point back to it.  In one line:
> port = field( oconv('u','u50bb') , "$", 2 )
>
> There are special environment variables for triggers like
> @ClientProcess, @ClientThread, @LogName, etc, which are mostly
> useless, and standard @PIB, @User, etc which aren't available in a
> trigger, but nothing for the port of the triggering process.  I'd say
> this is a good candidate for an action item enhancement request.  Now
> if the process that updates a file is actually a VB module or some SQL
> statement coming in via ODBC, I don't know what you'd expect the
> "port" to be, especially for non-persistent connections.  Be prepared
> for less than 100% accuracy as your clients become more diversified.
>

That would be fine- even if the port was returned as a null, that would
still be enough to distinguish them from the updating process, which will
always be executing as a phantom on a known port.

> As far as the code hanging, I'd say you have a bug.  The u50bb exit
> should work as of D3NT 7.3 and above.  Sounds like you're a candidate
> for a patch/upgrade:
> - make sure you're flash compiling with the 'o' option.
> - make sure you logoff after changing your trigger and that no users
> have the trigged file open while you're in development.
> - make sure you're using full pathing to the trigger or that you're
> using the domain catalogue.

Done all of these

> - for grins, try changing your CallX to a CallR or other special
> trigger to see if the trigger type is prompting the hang or if any
> trigger will hang.  I'm guessing if one type hangs all of them will (I
> don't have any insight there) but it's good info for Support.
> - try this in a different FSI account on an FSI file and make sure the
> hang occurs in an isolated environment, there might be something
> special in your development account.
>

Haven't tried these yet, but I will check them out.

> Despite the bug, I think this is a better approach to identifying "who
> done it" than tracking threads.
>

I've just tried Steve's code on a machine running 7.3.1 and it does work on
that. It looks as though the answer is to upgrade if I want to be able to
track port numbers.

Interestingly, after executing the trigger I was able to see the dummy
trigger user by doing a LIST-USERS. I don't see it on my development
machine. I'm guessing that RD must have changed the implementation of
triggers between 7.2 and 7.3.

Thanks to everyone who responded.

Peter