v1.1.0-beta-01: TRACE N behaves like TRACE E instead of TRACE F

[RossPatterson]

Martin Scheffler reported this on the h390-vm list:

I have installed the binary distribution via VMARC on the MECAFF user. There is a change how REXX tracing works which is disturbing EENEW's internal machinery. My workaround is to begin all REXX programs with "TRACE 'Off'".

TRACE 'Negative' behaves the same as TRACE 'Errors' but these should differ. The new bREXX has changed in the way, that TRACE 'Negative' does trace host commands with a positive return code but these should not be traced by TRACE 'Negative'.

I have checked this on SDFVM's VM/SP5 .

[RossPatterson]

TRACE 'Negative' behaves the same as TRACE 'Errors' but these should differ. The new bREXX has changed in the way, that TRACE 'Negative' does trace host commands with a positive return code but these should not be traced by TRACE 'Negative'.

I did indeed change stuff in the area of host command return code processing, because Cowlishaw's Rexx separates SIGNAL ON FAILURE (negative RC) from SIGNAL ON ERROR (non-zero RC). I wasn't aware of TRACE NEGATIVE, and in fact it isn't documented in The Rexx Language 2nd ed. (TRL2) or in the ANSI Rexx Standard. Both of those have TRACE NORMAL, and since they both say to only test the first character (i.e., "N"), TRACE NEGATIVE is legal. TRL2 documents TRACE NORMAL as the same as TRACE FAILURE - i.e., display commands with negative return codes.

So, yes, you're right, TRACE N should behave the same as TRACE F, not like TRACE E.

[RossPatterson]

Fix is complete and will be part of v1.1.0-beta-02.