In D3,
.L
at the tcl prompt shows your recently issued commands.

You might want to capture this in a program, as
EXECUTE ".L" CAPTURING REPLY

but that gives an error message about tcl stack depth exceeded.
Or, just leaves you at the debug prompt with no error message.

{do END at the **************** prompt to get out of that situation, btw}


The workaround is to EXECUTE ".LL" CAPTURING REPLY
in your program, and copy your MD .L
item to MD .LL

It is mainly attractive to run .L instead of reading your tcl-stack file item
because .L has really elegant code to figure out which of the last two words of
WHO / user exit U50BB
is your userid -- they swap when r83.setup is in effect.
Your userid is the item id to look at in tcl-stack.

OPEN "TS" TO ts THEN
READ UserTS from TS,@user then crt UserTS
END

"Frank Winans" wrote:
It's not "elegant code". There are many ways to identify your user,
account, port, etc. Run the following code. Someone should be logged
into port2 for the last couple lines to show any data:

user1 = @user
user2 = @who
user3 = oconv('u','u50bb')
account1 = @account
account2 = @logname
account3 = oconv('a','u50bb')
port1 = @pib
port2 = oconv('p','u50bb')
crt "user ":user1, user2, user3
crt "acct ":account1, account2, account3
crt "port "ort1, port2

original.who = system(29)
execute "who (c" capturing out
execute "who" capturing who1
crt "'who' in r83 mode (":system(29):") = ":who1
execute "who (a" capturing out
execute "who" capturing who2
crt "'who' in D3 mode (":system(29):") = ":who2
* see if we need to reset who verb to R83 mode
if original.who = 1 then execute "who (c" capturing out

crt "user,acct on port 2 is ":
crt oconv('u%2','u50bb'):","conv('a%2','u50bb')

for completeness, don't forget about the "charge-to" side-effect...
which suffixes both an asterisk and text to each user id. eg.
"charge-to client1" will cause a user logged into "user" to be seen as
"user*client1" vs "user" in each of your code examples.

ie. if you truly want the "pure" user name, you must always perform the
equivalent of \field(oconv('u%2','u50bb'),"*",1)\

although seldom used these days "charge-to" feature (which also ties
into the logon accounting option ('a'-option) on tracking user
statistics)... will cause unwanted side-effects to many-a-application
logic not allowing for it.



Tony Gravagno wrote:

so i don't get hammered... obviously my example is for user on pib2,
and assumes you can extrapolate.

Also could add port3 = system(22).
The "u" "a" "p" options for the u50bb user exit have been around since
ap (7.0 or so?) - really handy since they don't depend on which flavor
of "who" is in effect. See "help u50bb" if you have ref installed.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Tony Gravagno wrote:

"dzigray" wrote
recent commands is kept in item id same as your user id normally,
but an "i" on a9 of your users item makes the item id be your port
number instead. I've never seen a client use this "i", but was once
unamused to find charge-to in use during a new client conversion to d3.

Looks like the dm,bp, "." (dot) program uses the (undocumented?) user
exit "u6e" to test whether your tcl-stack is kept by port or user-id:

024 who = Oconv('','u50bb');* [05]
025 If Oconv('','u6e') = 1 Then
026 user = Field(who,' ',1);* [05] users i-option set, use pib
number
027 End Else
028 user = Field(who," ",2+System(29));* [02] [05]
029 End

/Scott Ballinger

Frank Winans wrote:

Two more minor points.

Back in the early '80's I worked at a service bureau which charged
clients using data like CPU ticks used and pages printed in our
office. That was on an Ultimate. I don't believe those stats have
been accurate in D3 for many years.

While Dave is absolutely right about the charge-to factor, there could
be times where you DO want to know the know the user is doing a
charge-to, so you may not want to pick off that data element. I doubt
seriously anyone would care about that, considering the way systems
are used these days. Howevah!! D3 does have a weird habit of
affixing "fsi:" onto some account names when you do a logto within
code. We see this in flashconnect all the time and it's a real PITA
sometimes to ensure that when we're checking the current account that
we strip that text before reading against an account table. They
might have addressed this in v7.5, dunno.

HTH
T

"dzigray" wrote: