On Mon, Feb 13, 2023 at 8:19 AM Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:

> Trace options (rexxref.pdf, 2.29 TRACE):
>
>    - prefixes: there is a ? prefix option; on mainframe Rexx (cf. e.g.
>    z/OS TSO/E REXX Reference:
>    <https://www.ibm.com/docs/en/zos/2.1.0?topic=trace-prefix-options>
>    <https://www.ibm.com/docs/en/zos/2.1.0?topic=trace-prefix-options>)
>    there is ! as a prefix option for C (commands); the letters ?, !, _ in Rexx
>    can be used in symbols like the alphabetic letters
>
>    - alphabetic options: there are the following options, where only the
>    first letter is taken, the rest ignored:
>
>    - All or A
>       - Commands or C
>       - Error or E
>       - Failure or F
>       - Intermediates or I
>       - Labels or L
>       - Normal or N
>       - Off or O
>       - Results or R
>
> Adding an option for activating multithreaded tracing could be in one of
> the following forms that adhere to the current logic:
>
>    - prefix: allow a letter like 'M' (for multithreading) as a prefix
>    like ? or !
>
>    - Mike would see this option option as a subsidiary option and
>       therefore it should not precede the alphabetic ("main") option and
>       therefore suggests to append it instead, making it postfix
>
>       - alphabetic option:
>
> I very much dislike the alphabetic option because of the way the options
have always been parsed. Many people think they are complete words and are
used to typing things like "Trace off" or "Trace results". It would seem
very astonishing to suddenly be using Trace MResults instread.



>
>    -
>    - Add an optional second option 'Multithreaded' following after a
>       blank the alphabetical option, hence the following two words need to be
>       given (only the first character of each word would be used):
>
>       - All Multithreaded or A M
>          - Commands Multithreaded or C M
>          - Error Multithreaded or E M
>          - Failure Multithreaded or F M
>          - Intermediates Multithreaded or I M
>          - Labels Multithreaded or L M
>          - Results Multithreaded or R M
>
> This is workable, but has some implications for the trace value form and
also how the additional keyword would be handled by the TRACE() bif. Still
workable, but this needs to be spelled out in the document. BTW, that needs
to be done regardless of how this is specified.


>
>    -
>          - postfix: following Mike's idea a trailing 'M' will activate
>    multithreaded tracing and if it is not supplied will stop multithreading
>    tracing:
>
>    - AM
>       - CM
>       - EM
>       - FM
>       - IM
>       - LM
>       - RM
>
>
I dislike this even more than the prefix because of the awkwardness of it.


>
>
> In theory the postfix notation could be implemented such, that the full
> name of an option may be given, but if the last letter is 'M' the
> programmer activates multithreading trace:
>
>    - AllM or All_M or Anything_however_the_last_letter_is_M ...
>    - CommandsM
>    - ErrorM
>    - FailureM
>    - IntermediatesM
>    - LabelsM
>    - NormalM
>    - OffM
>    - ResultsM
>
> Possibly less objectionable than the others, but one thing I don't like is
how the M setting is handled differently from the "?" prefix character.
When parsing the trace setting, there can be multiple occurrences of the
prefix character, e.g. "trace ???I" is the same as "Trace ?I" because each
occurrence flips the debug setting to the other state. Of course, the
prefix can be " M", which makes it the previous proposal.


>
>    -
>
> Ad postfix letter 'M': if not desiring an alphabetic letter, letters like
> ?, !, _ could be picked (can be part of a symbol). If so, the underscore
> may be error prone (can be easily overlooked), ? may be irritating as it is
> used already as a prefix. If wanting to use ! then the same is true if
> considering mainframe Rexx' use as a prefix. OTOH, if ! is not regarded to
> be a problem in ooRexx, then one could use that letter:
>
>    - A! or All!
>    - C! or Commands!
>    - E!  or Error!
>    - F!  or Failure!
>    - I!  or Intermediates!
>    - L! or Labels!
>    - R! or Results!
>
> The only combination that may be regarded to be a little bit problematic
> is 'I!' as it looks almost like 'II'.
>
I'm sure there will be members of the main-frame community who will scream
bloody murder if "!" is used. Although in the 35+ years since we did the
OS/ 2 version, I've not heard a single complaint about that option not
being included. I really believe nobody ever uses it.

There's one additional character available, the '.'. That might not be a
bad option, though my personal preference remains to make this automatic
rather than explicit.

>
> ---
>
> As this is a new feature of trace we could restrict activating the
> multithreaded output option to a two-letter trace option word where the
> last/second letter must be 'M'/'!' in order to activate it (if the last
> letter is not 'M'/'!' then it it is not activated or if currently active
> will be deactivated).
>
> Following Mike's idea of a postfix 'M' ('!') is probably the easiest to
> memorize for programmers, plays well as a companion to the trace prefix
> concept and keeps all the trace options intact.
>
> ---rony
>
> P.S.: Automatically triggering the multithreading trace output may cause
> surprise and also add too much information to the trace which in the usual
> case will not be needed. Multithreaded trace information will probably only
> be sought if a problem (deadlock) is experienced or for
> understanding/studying the dynamics of multithreaded execution.
>
I totally disagree here. Having had some experience with trying to use
trace in multi-threaded situations, it is almost always unusable,
particularly if you are using Trace Intermediates. It is almost impossible
to follow the order of operations when it is interleaved without
indicators. And I still disagree that any of the information other than the
thread identifier is of any use to the normal Rexx user. The activation
field makes no sense to me and the lock information is not complete enough
to really resolve deadlocks. It is possible to add debugging capabilities
for determining those sorts of things without cluttering trace up with a
lot of information that's not relevant to the task of tracing execution.

Rick



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