#698 Enhance support in debugging Rexx programs via .context and in the TRACE keyword statement (TID, RIID)

[Rony G. Flatscher]

When trying to debug multithreaded Rexx programs it would be of extremely helpful if it was possible to get the current thread id (TID) from Rexx on all of its operating systems in the same way. Currently, one is not able to retrieve the TID on Unix using the sysutil function SysQueryProcess().

Also, the TID usually is not a "human centric/friendly" value, but some very difficult to read (and to spot) hexadecimal value. Hence, there should be an option to get a more human like representation of the current TID, numbered from 1 and up. TID-1, TID-2, ...

The Rexx programmer should be able to retrieve the current TID using .context, where
.context~tid returns the hexadecimal value and
.context~tidh (trailing "h" for "human")

Alternatively, .context~tid could return a "RexxThread" object which allows for retrieving both, the hexadeicmal and the "human-friendly" value.

---

A very important debugging feature in Rexx is the TRACE keyword statement. This RFE asks for adding the option to display the TID in "human-friendly" form for each trace ouput. For this the alphabetical character "T" for "ThreadId" is suggested.

---

In addition for debugging Rexx programs in a multiple Rexx interpreter environment querying a Rexx instance id (RIID) should become possible.

As in the suggestion with TID above the RIID should be a hexadecimal value, but it should also become possible to fetch a "human-friendly" value of the current Rexx instance. A suggestion would be: RIID-1, RIID-2, ...

The Rexx programmer should be able to retrieve the current RIID using .context, where
.context~riid returns the hexadecimal value and
.context~riidh (trailing "h" for "human")

Alternatively, .context~riid could return a "RexxInstance" object which allows for retrieving both, the hexadecimal and the "human-friendly" value.

Also in this case the RFE asks for a possibility to optionally add the human-friendly RIID to TRACE outputs, which becomes important in environments where multiple Rexx interpreters are executing.

E.g. if debugging complex ooRexx GUI applications using JavaFX. In this case each GUI described by a declarative XML file will get Rexx handlers assigned that get managed by proper Rexx interpreter instances (one RI per XML file). Tracing the Rexx handlers with the RIID option activated would allow to distinguish which trace output comes from which RI, ie. from which Rexx handler.

[Anonymous]

Ad TRACE: maybe - to save space - activating to show thread id on trace output should also always show the Rexx instance id. To save space then such output could be shown like R1T1, R1T3 in the first column.