Re: REXX Error (Was: "action" in UK33496)

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 04/23/2008
   at 12:04 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>LEAVE & ITERATE only manage the current level.

Hogwash!
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/21/2008
   at 09:18 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>Reference to an uninitialized variable is a failure.

Only if NOVALUE is enabled. The classic behavior with NOVALUE disabled is
useful.

>I have _never_ coded a SIGNAL.  Partly hangover from the 3 decades ago
>"GOTO considered harmful" days; partly from needing to read and
>sometimes maintain spaghetti code from programmers who branch around
>their programs using SIGNAL with wild abandon,

SIGNAL is not GOTO; those who code as though it is will inevitably shoot
themselves in the foot, but may take you down with them. Please not that
some people can code FORTRAN in any language.

>And SIGNAL mixes with CALL and DO like oil and water.

Not if you use it only for its intended purpose.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Ted MacNEIL]

>Languages like REXX and Structured HLASM provide LEAVE and ITERATE as a means 
>of reducing program complexity. 
>Both statements allow for the specification of which of several nested 
>constructs is to be exited or 
iterated.
>This facility is important and, when used appropriately, will reduce program 
>complexity significantly.

Of course, multiple levels of nesting also increases programme complexity, as 
well.
When I get 'too' deep, I consider procedures.
Which introduces the other construct: RETURN.


-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Edward Jaffe]

Ted MacNEIL wrote:

I should have said:
"LEAVE & ITERATE should only be used to manage the current level."

Use flags/semiphores to continue to exit.
At least, that way you know what you have.
  


The intent of structured programming techniques, since their need was 
recognized 40 years ago, has been to improve software reliability by 
reducing program complexity.


Languages like REXX and Structured HLASM provide LEAVE and ITERATE as a 
means of reducing program complexity. Both statements allow for the 
specification of which of several nested constructs is to be exited or 
iterated. This facility is important and, when used appropriately, will 
reduce program complexity significantly.


Arbitrary avoidance of this capability will necessarily lead to 
scenarios in which the programmer must define, set, and test additional 
return codes, flags, or other program indicators, when exiting an inner 
construct, in order to cause some outer construct to be exited or 
iterated. If the nesting is quite deep, this extra handling will be 
required at every intermediate level until the "target" level is finally 
reached. While such programs can be said to "work", they are much more 
fragile than programs written to exploit LEAVE and ITERATE as the 
language allows.


I recommend a ranking system in which the inner-most, of several nested 
constructs, is the most preferential target for exit/iterate and the 
outermost such construct is the least preferential; the remaining 
constructs ranked, as expected, according to nesting level. I view this 
as a practical approach because experience with "world class" software 
(  O:-) ) has shown that it's better to exit/iterate an outer construct 
than to introduce gratuitous program complexity to prove a point.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Edward Jaffe]

Paul Gilmartin wrote:

Consider:

/* I do this all the time... */

do phonyblock = 1 for 1
...
if Bailout then leave phonyblock
...
end phonyblock

o I put a "name = 1 for 1" on all my large blocks, and use a
  matching "end name"
  - the interpreter checks that my "end"s match my "do"s.
  - but it's a kludge because I can't name the "end" nor the
"leave" without introducing a phony control variable.
  


Structured HLASM provides a "simple" DO for this need. For example:

|  
|  * Program Main Line*
|  
|DO ,
|  JAS   R14,Routine1
|  DOEXIT LTR,R15,R15,NZ
|  JAS   R14,Routine2
|  DOEXIT LTR,R15,R15,NZ
|  .
|  . (more routine calls)
|  .
|ENDDO ,

These can, of course, be named and nested -- no dummy control variable 
required:


|DO LABEL=ThisIsTheNameOfMyOuterDo
|  DO LABEL=ThisIsTheNameOfMyInnerDo
|.
|.
|LEAVE   ThisIsTheNameOfMyOuterDo
|.
|.
|  ENDDO , ThisIsTheNameOfMyInnerDo
|  .
|  . More logic here
|  .
|ENDDO , ThisIsTheNameOfMyOuterDo

One nice feature is that any "labels" you choose are actually exposed -- 
as coded -- within the HLASM name space. This means you can use them to 
produce the most efficient code possible for frequently-executed 
routines. Consider this example, using TRE, I posted in another thread:


|LM   R14,R15,0(R1)Load string ptr and its length
|LA   R1,TRTSCRUB  Ptr to translation table
|XR   R0,R0Set stop char = x'00'
|DO INFDo for translate
|  TRE   R14,R1  Translate the string
|  DOEXIT Z  Exit if no more data
|  IF O  If iterate needed
|ITERATE , Process more data
|  ENDIF ,   EndIf
|  MVC   0(1,R14),0(R1)  Translate x'00' to whatever
|  LAR14,1(,R14) Advance past stop character
|  AHI   R15,-1  Decrement length remaining
|  DOEXIT NP Exit if no more data
|ENDDO ,   EndDo for translate

It should run slightly faster if I expose a DO label and code instead:

|LM   R14,R15,0(R1)Load string ptr and its length
|LA   R1,TRTSCRUB  Ptr to translation table
|XR   R0,R0Set stop char = x'00'
|DO INF,LABEL=TreLoop  Do for translate
|  TRE   R14,R1  Translate the string
|  DOEXIT Z  Exit if no more data
|  JOTreLoop Branch if another segment
|  MVC   0(1,R14),0(R1)  Translate x'00' to whatever
|  LAR14,1(,R14) Advance past stop character
|  AHI   R15,-1  Decrement length remaining
|  DOEXIT NP Exit if no more data
|ENDDO ,   EndDo for translate

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Patrick O'Keefe]

On Wed, 23 Apr 2008 00:15:59 +, Ted MacNEIL 
<[EMAIL PROTECTED]> wrote:

>...
> Of course, being 51 may have something to do with it.
>...

Ah.  I see.   Your mind is still too young and unruly.
Well, don't worry.  You'll grow out of it.

Pat O'Keefe 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: 'action' in UK33496)

[Gary Green]

re  Of course, being 51 may have something to do with it.

Or as we say, C.R.S ;)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Paul Gilmartin]

On Tue, 22 Apr 2008 18:18:14 -0500, Patrick O'Keefe wrote:

>On Tue, 22 Apr 2008 22:41:49 +, Ted MacNEIL
><[EMAIL PROTECTED]> wrote:
>
>>>I think abuse of ITERATE and LEAVE to be a much milder crime.
>>
>>I don't know what you mean by abuse, but when I studied
>modular/structured programming at the University of Waterloo, these
>were considered valid constructs.
>>...
>
>I absolutely agree.  Even when absolutes aren't appropriate.
>
Consider:

/* I do this all the time... */

do phonyblock = 1 for 1
...
if Bailout then leave phonyblock
...
end phonyblock

o I put a "name = 1 for 1" on all my large blocks, and use a
  matching "end name"
  - the interpreter checks that my "end"s match my "do"s.
  - but it's a kludge because I can't name the "end" nor the
"leave" without introducing a phony control variable.
  - but using "leave" insted of "signal" allows me to nest
it all within a larger block.

o I always put a name on the "leave" and "iterate", even when
  they refer to then innermost block (and I have no qualms
  about multi-level "iterate" and "leave", which are possible
  if one names the control variable).
  - It's documentation.
  - It protects against unexpected results if one introduces
another inner nesting level.

You're entitled to say that if I'm doing that, I should modularize
to smaller blocks.

I can see where someone not expecting this could consider it
"leave" abuse.

>I may have misunderstood Paul, but I assume he was describing
>such convoluted logic that use of SIGNAL might have actually
>made more understandable code.  I was trying to say the even then
>I would consider use of ITERATE and LEAVE preferable to SIGNAL.
>
Where I'd code:

if X then do
call B
call C
end;  else do
call A
call C
end

My nemesis has coded:

if X then signal B

A:  /* unnecessary label for comparison with above.  */
/* some stuff */
signal C

B:
/* some other stuff */

C:
/* final stuff  */

... perhaps all within a loop that needs to be implemented with
SIGNAL because of the interior SIGNALs.

>In fact, I'm not sure that I would ever use SIGNAL to break out of a
>complex nested loop structure even if it DID greatly simplify the
>logic.   In fact, I don't even like named LEAVE; I leave each level
>seperately.  (And that is probably even more pig-headed than
>religiously avoiding SIGNAL.)
>
But you have to do that with CALLs.  There's no construct for
leaving multiply nested procedures.  Except for my nemesis's
using SIGNAL until the stack overflows.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Ted MacNEIL]

>> LEAVE & ITERATE only manage the current level.
>   

>LEAVE and ITERATE are for whichever level you specify. The default, if no 
>operand is specified, is the current level.

You're correct, and I realised it as soon as I sent the message. I have never 
supplied an operand, so I forgot. Of course, being 51 may have something to do 
with it.

I should have said:
"LEAVE & ITERATE should only be used to manage the current level."

Use flags/semiphores to continue to exit.
At least, that way you know what you have.
With SIGNAL, who knows where you are?
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Edward Jaffe]

Ted MacNEIL wrote:

LEAVE & ITERATE only manage the current level.
  


LEAVE and ITERATE are for whichever level you specify. The default, if 
no operand is specified, is the current level.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Ted MacNEIL]

>In fact, I'm not sure that I would ever use SIGNAL to break out of a complex 
>nested loop structure even if it DID greatly simplify the logic.

It doesn't necessarily. You can end up with indeterminate results.


>In fact, I don't even like named LEAVE; I leave each level seperately.

LEAVE & ITERATE only manage the current level.
Again, if it allowed for more, what would your state be?
I have no problem with managing them with flags, but a single one should only 
manage one construct.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Patrick O'Keefe]

On Tue, 22 Apr 2008 22:41:49 +, Ted MacNEIL 
<[EMAIL PROTECTED]> wrote:

>>I think abuse of ITERATE and LEAVE to be a much milder crime.
>
>I don't know what you mean by abuse, but when I studied 
modular/structured programming at the University of Waterloo, these 
were considered valid constructs.
>...

I absolutely agree.  Even when absolutes aren't appropriate.

I may have misunderstood Paul, but I assume he was describing 
such convoluted logic that use of SIGNAL might have actually
made more understandable code.  I was trying to say the even then
I would consider use of ITERATE and LEAVE preferable to SIGNAL.

In fact, I'm not sure that I would ever use SIGNAL to break out of a
complex nested loop structure even if it DID greatly simplify the
logic.   In fact, I don't even like named LEAVE; I leave each level
seperately.  (And that is probably even more pig-headed than
religiously avoiding SIGNAL.)

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Ted MacNEIL]

>I think abuse of ITERATE and LEAVE to be a much milder crime.

I don't know what you mean by abuse, but when I studied modular/structured 
programming at the University of Waterloo, these were considered valid 
constructs.

Sometimes, you've done all you can with the data, so you have to either restart 
or exit from that piece of logic.
And, ITERATE & LEAVE are understandable.

-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Patrick O'Keefe]

On Mon, 21 Apr 2008 21:18:17 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:

>...
>My technique for picking up the pieces after a failure is to
>improve the code so that it no longer fails.  A nonzero return
>code is not a failure.  Reference to an uninitialized variable
>is a failure.

I couldn't agree more (as if anybody cares).  And trapping and error
can assist in that (but obviously not with techniques like you quote
later in your posting.)

>...

>I have _never_ coded a SIGNAL.  Partly hangover from the 3 decades
>ago "GOTO considered harmful" days; ...

I think abuse of ITERATE and LEAVE to be a much milder crime.
But that maybe from my  also shunning SIGNAL.  I've used SIGNAL
only for condition trapping.

I guess I have not read this part of the fine manual for many years.
I see that the ON condition statements can contain either SIGNAL 
or CALL.   I guess you can CALL the condition-handling routine and
return past the failing statement.  Sort of a REXX ESTAE.  I'm not 
sure I would want to try that in most cases.  (CALL ON HALT could
be down right mean!  Maybe those are the situations where HE
will kill and exec but HI will not.)

>...
>But a "SIGNAL ERROR" with no handler would provide much the
>traceback and termination I desire.  I'd just have to accept
>no longer being able to say "I have never coded a SIGNAL."

Ah!  THERE is what I wasn't seeing - the ability to raise a condition
when you aren't using a condition handling block.  Yup, that's tough
to do without a way to programmatically raise the condition.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: REXX Error (Was: "action" in UK33496)

[Paul Gilmartin]

On Mon, 21 Apr 2008 15:44:20 -0500, Patrick O'Keefe wrote:
>
>Maybe I misunderstand what you would want REXX to do.
>
>If you're talking about some way of invoking an On-condition block,
>REXX obviously has it: you SIGNAL or CALL the block's label.
>
>If you want to verify an exec's ability to handle an abend condition
>if you haven't included an exception routine, uh, well, maybe you
>should include the routine rather than determining how to pick
>up the pieces after a failure.
>
My technique for picking up the pieces after a failure is to
improve the code so that it no longer fails.  A nonzero return
code is not a failure.  Reference to an uninitialized variable
is a failure.

>If you want to determine which Error/Failure/Halt/Noalue/Syntax
>conditions is raised by a particular miscoded statement you still have
>to execute the miscoded statement (or reread the doc).
>
>I think I've missed what you want.
>
Thanks.  Perhaps I need to moderate some of my ancient compulsions:

I have _never_ coded a SIGNAL.  Partly hangover from the 3 decades
ago "GOTO considered harmful" days; partly from needing to read
and sometimes maintain spaghetti code from programmers who branch
around their programs using SIGNAL with wild abandon, including
one who used SIGNAL for early exit from a deeply nested subroutine,
and came to me for assistance when his data set grew to the point
that the stack overflowed.  (Conversely, I use, perhaps overuse
ITERATE and LEAVE to some of the same ends that they abuse SIGNAL.)

And SIGNAL mixes with CALL and DO like oil and water.

I have rarely coded an On-condition block, partly from resentment
of the technique of one of the above programmers who always codes,
roughly:

signal on syntax
...
syntax:
say 'Syntax error at line' sigl
exit 99

... thereby providing less diagnostic information than the
default Rexx traceback.  But he believed that it was necessary
to code a handler for every possible exception condition.

I start every Rexx EXEC with "SIGNAL ON NOVALUE"; I never
code a NOVALUE handler.  I understand that nowadays there
are instructions I can use in the handler to diagnose better
and identify which variable caused the problem.  I need to
master those.

But a "SIGNAL ERROR" with no handler would provide much the
traceback and termination I desire.  I'd just have to accept
no longer being able to say "I have never coded a SIGNAL."

(I also wish I could generate a Rexx traceback at some point,
but continue execution.)

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

REXX Error (Was: "action" in UK33496)

[Patrick O'Keefe]

On Mon, 21 Apr 2008 11:15:05 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:

>...
>Every well-designed language, application, programming system 
should
>have a way to force an error.  IDCAMS has such; HLASM has MNOTE;
>zSeries has x'00'.  Rexx lacks such; I resort to dividing by zero
>or accessing an uninitialized variable to force an error.
>...

Maybe I misunderstand what you would want REXX to do.

If you're talking about some way of invoking an On-condition block, 
REXX obviously has it: you SIGNAL or CALL the block's label.

If you want to verify an exec's ability to handle an abend condition
if you haven't included an exception routine, uh, well, maybe you 
should include the routine rather than determining how to pick 
up the pieces after a failure.

If you want to determine which Error/Failure/Halt/Noalue/Syntax
conditions is raised by a particular miscoded statement you still have
to execute the miscoded statement (or reread the doc).

I think I've missed what you want.

Pat O'Keefe


  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html