Lurker here... If I understand correctly, these thread numbers would be
from the underlying OS (UNIX, Windows, z/OS...)? If so, you should be aware
that on z/OS thread numbers are *huge*. What they've done under the covers
is obviously to encode other info (TCB address or something?) in the high
part of a 64-bit integer, so just looking at a random process on a system
here, the thread number in decimal is 1512391438145421314, which in hex is
04FD 1800 0000 0002, so the underlying thread is obviously 2. But that's
not an exposed interface, so you'd have to find space for at least 19
digits!

But perhaps I misunderstand, and you're mapping OS thread numbers into
local-to-REXX ones, which of course can be of a controlled size of your
choosing.

Tony H.

On Wed, 15 Feb 2023 at 14:00, Rick McGuire <object.r...@gmail.com> wrote:

> I’m in complete agreement with Mike on this. There are better ways to make
> this sort of information available than trying to force fit it   In to
> trace.
>
> Rick
>
> On Wed, Feb 15, 2023 at 12:58 PM Mike Cowlishaw <m...@speleotrove.com>
> wrote:
>
>> Thanks for the multiple examples!
>>
>> As for the 'spaced out' case (excerpt below) ... this really would not
>> work for me.   I often have 5-9 windows open when I'm programming and these
>> are 80 characters wide so I can minimise overlaps.  With the suggested
>> layout this would only work for programs less than ~40 characters wide!
>> Here's how the excerpt looks for me (and this example has very short lines
>> -- most of my programs use 72 or more characters per line for better
>> commentary):
>>
>> ---> mt91.rex_nr_1_via_JSR223
>> R1   T1   A1                    3 *-* t=.Test~new
>> R1   T1   A2    V1      1*     21 *-* say "arrived in:" .context~name
>> arrived in: INIT
>> R1   T1   A2    V1      1*     22 *-* counter=0
>> R1   T1   A1                      >>>   "a TEST"
>> R1   T1   A1                    4 *-* t~m1
>> R1   T1   A3    V1      1*     27 *-* counter+=1          -- increase
>> counter
>> R1   T1   A3    V1      1*     28 *-* say "arrived in:" .context~name
>> "before reply"
>>
>> Almost any line of any length will wrap.  That's why the trace headers in
>> Rexx are kept as short as feasible.  Adding an unexplained 27 characters on
>> the front of each line makes little sense, especially as the information is
>> the same on most lines, and as I mentioned before is not user-friendly
>> (here I mean 'user' as being a writer of Rexx programs, not someone who
>> runs a Rexx program without looking at it or caring which language it is
>> written in).
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>> Multithreading trace output activated:
>>
>> ---> mt91.rex_nr_1_via_JSR223
>> R1   T1   A1                    3 *-* t=.Test~new
>> R1   T1   A2    V1      1*     21 *-* say "arrived in:" .context~name
>> arrived in: INIT
>> R1   T1   A2    V1      1*     22 *-* counter=0
>> R1   T1   A1                      >>>   "a TEST"
>> R1   T1   A1                    4 *-* t~m1
>> R1   T1   A3    V1      1*     27 *-* counter+=1          -- increase counter
>> R1   T1   A3    V1      1*     28 *-* say "arrived in:" .context~name 
>> "before reply"
>>
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to