Sppg Code Of Practice

[Benita Vandervoort]

Thanksfor the suggestion. Do these things work in compiled Rexx?

I understand it fails undefined labels in the compilation step.Of course, my further wish is to be able to generate a stack

trace-back and continue processing. No hope, I suspect.Thanks again,

I have benchmarked my REXX framework with and without the diagnostic code to

see if the "light-weight" code is really that much faster. I only saw a 5%

difference. When the difference is only 5 percent, I don't see the value

and risk in running without the safety net... This is reminiscent of our

thread on comment style a few years ago .If this was still the mid-1980's with 308x boxes, I might be singing a

different tune, but today, 5 percent is the cost of doing business.RobIn a message dated 9/21/2007 7:30:24 AM US Mountain Standard Time,

Frank....@NATIONALCITY.COM writes:But on the other hand, in another life was a consultant and knowing a

large percentage of the individual's taking over the code would make the

common mistakes that are talked about on this list-server. I would try

to ease their pain in debugging when they would have to modify the code.

Being out of consulting for 7 years I still receive emails and calls

from former clients asking for advice. I have never known a piece a

code that didn't have to be modified during its life cycle.Frank

>

> SIGNAL ON NOVALUE is a debugging aid. It should never be included in a

> productive exec. Once set, it degrades the performance of the routine

> and at best helps identify a coding error. A thouroughly tested exec can

> never raise a NOVALUE condition. For those who would say "what about

> INTERPRET?", I suggest that the routine must be tested for all data it

> is supposed to handle as well as all logic paths. If an INTERPRET fails

> on NOVALUE it is a user error not a program error.

>

I view SIGNAL ON NOVALUE as akin to a circuit breaker in hardware. Once

installed, the circuit breaker degrades preformance of the system by

whatever impedance it adds to the power supply. A thoroughly tested

electrical system can never malfunction, so once the designer is satisfied

that all tests have been passed, the circuit breakers should be removed

from the system.

(1) the analogy assumes that none of the internal components (resistors,

capacitors, etc) can fail. We all know that this sometimes happens, and

the presence of a fuse/circuit breaker is necessary to protect the

safety of those operating the hardware(2) software is subject to frequent changes. If your hardware had

sockets of some sort for plug-in accessories which could come from a

third party, wouldn't you include the fuse/circuit breaker because you

could lose control of the conditions in the machine?(3) What if your device were used in an environment where the external

conditions (quality of power, signal timing, etc) might change in the

future? Wouldn't prudence dictate the provision of fuses to guard

against fires or other disastrous side effects?Most of these points have been made before. To sum it up, it seems to

me that the basic argument against SIGNAL ON SYNTAX has been that

"perfect" REXX can be produced. This is possible (but not guaranteed)

only for the most trivial programs. Furthermore, external factors (the

operating environment and modification by others) could cause a

"perfect" program to fail. Often, the preconditions promised by

potential users turn out to be incomplete, inaccurate, or just plain

wrong. Finally, I rarely see circumstances that permit enough time to

code and test to perfection.The worst possible outcome from a program with an undefined variable but

without SIGNAL ON NOVALUE isn't really bad output, its bad output which

can be mistaken for good!While SIGNAL ON NOVALUE does not guarantee a correct program, it helps

weed out the incorrect ones. I'll gladly pay the small penalty for

that.

> productive exec. Once set, it degrades the performance of the routine

> and at best helps identify a coding error. A thouroughly tested exec

> can never raise a NOVALUE condition. For those who would say "what

> about INTERPRET?", I suggest that the routine must be tested for all

> data it is supposed to handle as well as all logic paths. If an

> INTERPRET fails on NOVALUE it is a user error not a program error.

>

> Date: Fri, 21 Sep 2007 09:30:00 -0400

>

> - People will change my code after I have debugged it, and introduce new

> errors.

>

Alas, the second thing such a revisionist is apt to do is to delete the

pesky SIGNAL ON NOVALUE that caused the line of code he just added

to fail.> While I have not benchmarked the difference between running with and without

> SIGNAL ON NOVALUE, I doubt that it introduces overhead in the "normal" case,

> where the variable HAS a value. In the exceptional case, where the variable

> does not exist, it must run through my error handler, yes, that is more

> overhead, as the program writes out diagnostics and terminates.

>

Makes sense. If the test for SIGNAL enabled is in the branch where the

variable has already been found to be uninitialized, correct code will

never execute it. May we neglect the I/O bandwidth to read the extra

line, and the cost of parsing it?> I don't really like the REXX feature where "uninitialized variables get a

> default value of their own name in upper case". In my code, uninitialized

> variables are typographical errors.

>

Me too (and I'd prefer case ASIS for the Q&D). And that should apply likewise

to uninitialized variables in compound tails.> I think more code SHOULD use SIGNAL ON NOVALUE. The only place I don't use

> it is in my "RexxTry", because there I am just doing quick and dirty

> experiments and can afford to be a bit crufty.

>

I have something similar, in which I also omit SIGNAL ON NOVALUE.For the performance-obsessed, a colleague once found empirically that

IF RC==0 is detectably faster than IF RC=0 (intuitively reasonable).

I wonder how many programmers exploit this optimization?

I do trap some errors, but I trap them by testing for the expected values, and branching to an error routine. I find this forces those coming in behind me to do the same. It is the same reason I put a comment on every line of code. That way, someone adding code will feel a need to do the same. It has been my experience that, at the VERY best, external documentation is only valid the day a program goes live. People RARELY in ever go back and update external docs for each change, but internal documentation they will, if you code in such a way as to make it obvious who did NOT comment his/her code :)Mickey

What I have posted is the QA test routine that I use to test fixes to

RXERROR. It has a copy of RXERROR in it. This will allow people to play

around with it to see how it works in various situations.There is DOC in RXERROR itself that explains how to use it.RXERROR is pasted in by my RXCOPY edit macro, which will surely be the topic

of some other thread. Suffice it to say that I have no problems managing

pieces of internal subroutines pasted into REXX execs anymore.Someone else asked if the routine can be external. Parts of it cannot, such

as calls to sourceline() and references to variables such as RC. I have an

internal/external pair of error handlers that I use in ooRexx/ObjREXX, where

the external portion is loaded from a requires file, while the internal

version is pasted in by my windows version of RXCOPY. You could do a similar

scheme in TSO/REXX, by passing all of the required bits to an external

routine that did all the formatting. I just never really needed to do that.Regards,Bob StarkProTech - When you're serious about Systems Management

Consulting, Software, and Training for z/OS, UNIX and Internet

www.protechtraining.com 800-373-9188 x150 412-445-8072

>SIGNAL ON NOVALUE is a debugging aid. It should never be

>included in a

>productive exec. Once set, it degrades the performance of

>the routine

>and at best helps identify a coding error. A thouroughly

>tested exec can

>never raise a NOVALUE condition.

This reminds me so much of the people who want array

range checking in (Cobol? Pl/1?) programs turned off in

production.1. In modern processors, performance is not usually a big

issue.2. It's most often better to get an abend than to get

wrong output that you don't know is wrong. Once the wrong

output *is* noticed, how many days (months, years) worth of

reruns does it take to wipe out whatever minimal

performance gain was saved by not performing a

verification?

--

I cannot receive mail at the address this was sent from.

To reply directly, send to ar23hur "at" intergate "dot" com

2. It's most often better to get an abend than to get wrong output that you

don't know is wrong. Once the wrong output *is* noticed, how many days

(months, years) worth of reruns does it take to wipe out whatever minimal

performance gain was saved by not performing a verification?

>Depends on what you mean. If you're saying "when you test for no-value,

>the condition will cause the program to abend rather than put out bad

>information" then I agree. But that's what Arthur said, and it sounds to

>me like you were trying to disagree with Arthur, so I suspect you meant to

>say "a no-value condition, if you don't trap it, won't produce bad data;

>it'll just blow up, which is a good thing".

>

>It's true that blowing up is better than producing bad data that isn't

>obviously bad. But it isn't true that an uninitialized and untrapped

>variable can do only the former, not the latter; it isn't even very

>unlikely.

But don't we, as programmers, spend most of our time contemplating the 'worst

case scenario'? The 80-20 rule says that we write 20% of our code to handle 80%

of the data, and the other 80% of the code to handle the remaining 20% of the

data.If a variable has a value I don't know about/expect, oh, pleaseplease let the

routine blow up. It's better that it blows up in test so I can correct it, but

in a pinch I'll accept a blow-up in production at 2am...

(change Arabic number to Roman numeral to email)

3a8082e126