🚀 go-pugleaf

Frank Clarke wrote:

> I've seen several code examples here and elsewhere which begin:
>
>   /* REXX  .... */
>   trace O
>   ...
>
> and I'm beginning to wonder why anyone would engage in this practice.
> Do you do this?   Why?

Yes, I do.

In a *well* tested support function, it is frequenctly *not* necessary to
clutter up an application trace with information not directly useful.

It is also very difficult (as you know) to establish a standardized
"trace" option or parameter on the command line of all Exec's unless the
mechanism was designed before most of that shops rexx code was
implemented. As a result, some execs will support this years standard,
and others will either support last years standard or no standard at all.

The mechanism you specify will not work in all circumstances, but if
standardized within a single application, can be made to work.
I will also agree that a standardized approach is required when the
application uses many compilied Rexx Execs...

/s/ Bill Turner, wb4alm.

"Bill Turner, WB4ALM" <wb4alm@gte.net> wrote:

>Frank Clarke wrote:

>> I've seen several code examples here and elsewhere which begin:
>>
>>   /* REXX  .... */
>>   trace O
>>   ...
>>
>> and I'm beginning to wonder why anyone would engage in this practice.
>> Do you do this?   Why?

>Yes, I do.

>.... *not* necessary to
>clutter up an application trace with information not directly useful.
<...snip...>

It's been a week, no one else has questioned this, and I'm still
confused, so....

"trace O" is the default, no?   I don't see how specifying it will
provide any special value, but I've missed subtleties before.  Perhaps
I've done so again.

If the expectation is that it will summarily shut off the "trace ?r"
which results from "EXECUTIL TS", someone is in for a rude surprise.
Only a keystroked "trace o" will do so, and only for the then-current
routine.  (Watching a 'trace o' go galloping by while in that mode
actually provoked the original question.)

P.s.: you're not the only one who does this.  I found an example in
IBM-supplied code while diagnosing a failure (in SMTPNOTE).  Curiouser
and curiouser....

Frank Clarke
Tampa Area REXX Programmers' Alliance
Member of the REXX Language Association
Join us at http://www.rexxla.org
(Remove the currency symbol before replying.)

In article <696jhm$akf@camel15.mindspring.com>,
Frank Clarke <nisus$@mindspring.com> wrote:

% "trace O" is the default, no?   I don't see how specifying it will
% provide any special value, but I've missed subtleties before.  Perhaps
% I've done so again.

If you have a working script and you call it from another script, which
isn't working, you don't want to trace the working script. So if you have
 trace 'O'
at the top of a script, it won't be traced if it's called from some other
script. I think that's what the first response was getting at.

I had the impression when I was at IBM in the mid eighties that a lot of
people would just automatically put
 trace 'O'
at the top of the script, and change the O to something else if they
wanted to do some tracing, then change it back when they didn't any more.
I don't know if you'd call that laziness or just a convention.
--

Patrick TJ McPhee
East York  Canada
ptjm@interlog.com

ptjm@interlog.com (Patrick TJ McPhee) wrote:

>If you have a working script and you call it from another script, which
>isn't working, you don't want to trace the working script. So if you have
> trace 'O'
>at the top of a script, it won't be traced if it's called from some other
>script. I think that's what the first response was getting at.

...but an external routine does not inherit the trace-mode of its
caller.  Externals awake in 'trace O' (unless EXECUTIL TS).

>I had the impression when I was at IBM in the mid eighties that a lot of
>people would just automatically put
> trace 'O'
>at the top of the script, and change the O to something else if they
>wanted to do some tracing, then change it back when they didn't any more.
>I don't know if you'd call that laziness or just a convention.

It's something else, but I'm not sure what it's called.  (Yes, I am,
but I won't say it here.)

They _change_ a failing module in order to _diagnose_ it?  I wonder
how many of us have uttered the words: "All I changed was a comment!"
My teachers always stressed that after you change a module, it isn't
the same module anymore.  That's why my diagnostic routines are
"built-in, not bolted on" allowing me to use them (or not) as I
please.

Frank Clarke
Tampa Area REXX Programmers' Alliance
Member of the REXX Language Association
Join us at http://www.rexxla.org
(Remove the currency symbol before replying.)

Frank Clarke wrote:
> 
> I've seen several code examples here and elsewhere which begin:
> 
>   /* REXX  .... */
>   trace O
>   ...
> 
> and I'm beginning to wonder why anyone would engage in this practice.
> Do you do this?   Why?
> 
> I'll volunteer that all of my code begins...
>   /* REXX ... */
>   arg parms "((" opts
>   opts = Strip( opts , "T" , ")" )   /* lose trailing banana */
>   parse var opts "TRACE" tv .        /* tv=tracevalue      */
>   parse value tv "O"  with  tv  .    /* defaults to Off   */
>   rc = Trace(tv)          /* sometimes it's "O", sometimes not */
> ...which allows me to invoke all of my code in any trace-mode I care
> to specify.... without first changing it.
> 

FWIW, I routinely put TRACE(N) at the beginning of every routine, i.e.,
any callable entity. I don't have a reference here at home, so I'll do
my best from memory. TRACE(O) turns tracing OFF, period. TRACE(N)
indicates no tracing; however, if something goes wrong internally REXX
will show you.

Bill Lynch

> Frank Clarke
> Tampa Area REXX Programmers' Alliance
> Member of the REXX Language Association
> Join us at http://www.rexxla.org
> (Remove the currency symbol before replying.)

In article <696jhm$akf@camel15.mindspring.com>, nisus$@mindspring.com wrote:
>It's been a week, no one else has questioned this, and I'm still
>confused, so....

>"trace O" is the default, no?   I don't see how specifying it will
>provide any special value, but I've missed subtleties before.

No, the default is "trace N", which causes (possibly unwanted) trace output
if a command fails.  I may be misremembering but I think that in the Olden
Days[TM] "trace N" was the same as "trace E" since "trace F" didn't exist,
so even a simple thing like

address cms "STATE" fn ft fm

to see whether a file exists would produce unwanted trace output if it
didn't.
-- 
---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including REXX section):
------ http://www.comlab.ox.ac.uk/oucl/users/ian.collier/imc.html