Re: Does a thread = a Pick process?

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.

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.
- 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.

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

HTH,
Tony

"Peter Kenyon" <[EMAIL PROTECTED]> wrote:

>
>"Steven S" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> In D3NT the process that initiates the trigger is part of the logon user
>> name, so you can use the WHO statement to parse out who caused the calling
>> trigger. See sample code below:
>>
>> Example LU statement where the trigger is running on port 1 and port 97
>> caused the trigger.
>>
>> pib# user.......... udate utime account.......... mdate mtime
>> location.......
>>
>>    1 S$97$          11/24 20:16 PM.PROGRAMS       11/24 20:16
>CUSTOMER.ENTRY
>>
>>
>> * D3NT. Parse who statement out.
>>   WHO=OCONV("","U50BB")
>>   TEMP.USER=FIELD(WHO," ",2)
>>   TEMP.PORT=FIELD(TEMP.USER,"$",2)
>>   TEMP.USER=FIELD(TEMP.USER,"$",1)
>>   TEMP.ACCT=FIELD(WHO," ",3)
>>   WHO=TEMP.PORT:" ":TEMP.USER:" ":TEMP.ACCT
>>   PORT=TRIM(TEMP.PORT)
>>   IF PORT="" THEN RETURN
>>
>> Steve
>
>
>Which version of D3 are you using? On ours, which is 7.2.1, the trigger
>hangs if it executes WHO.
>
>It seems strange that every attempt to find out information about the
>calling process (port number, pib, PCB etc) causes this hang. This suggests
>that the trigger is not really executing in a workspace at all. Yet the
>trigger is able to read named commons and output to the terminal of the
>calling process, so they can't be completely isolated from each other.
>
>Peter
>