Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Build a Call List in REXX?

1 view
Skip to first unread message

Edward Konig

unread,
Nov 10, 2004, 8:54:40 PM11/10/04
to
I am designing an application in REXX that has alternate paths from start to
finish.

At first I designed

LOOPA: DO WHILE RC < 8 & ^is_FATAL_ERROR
Call PROCESS_PANELA
If RC ^< 8 Then Leave
lOOPB: DO WHILE RC < 8 & ^is_FATAL_ERROR
Call PROCESS_PANELB
If RC ^< 8 Then Leave

...


End /* LOOPB */
End /*LOOPA */

Then I realized that for certain values of the parameters, I would want to
"skip a loop" in this, and go to the
next deeper nested loop.

I also want to be able to backtrack up along the path taken down, skipping
the same calls as were skipped on the path down.

Nested PROCS would handle this, if the branching logic was inside the PROC.
But I want to call the PROCs independently as well, which rules this out.

So, it appears that what I need is a "tree structure"
level# = 1
CALL_LIST.level# = PROCESS_PANELA
Interpret "Call" CALL_LIST.1
level# = level# + 1
If VAR1 = "A"
Then
CALL_LIST.level#= PROCESS_PANELB
Else
CALL_LIST.level# = PROCES_PANELC
Interpret "Call" CALL_LIST.2

...

And, on return (PF3 pressed), backchain...

CALL_LIST.level# = ""
level# = level# - 1
Interpret "Call" CALL_LIST.level#

...

Is this appropriate or stupid?

Is there a better way to implement this in REXX?

Thanks
Ed K
...

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

Hamilton, Robert L

unread,
Nov 11, 2004, 6:47:56 AM11/11/04
to
What is it you are trying to do? Is the function being done now,
somehow?
You can both ITERATE and LEAVE a loop.

bobh

Robert Zenuk

unread,
Nov 11, 2004, 7:43:21 AM11/11/04
to
In a message dated 11/11/2004 5:43:08 AM Central Standard Time,
rob...@UTDALLAS.EDU writes:

You can both ITERATE and LEAVE a loop.


Additionally, if you change your do loop to include an iteration variable,
you can leave a particular loop within the nested loop hierarchy by using leave
x.

bignum = 1000000
do a=1 to bignum
if cond1 = 'YES' then leave
do b=1 to bignum
if cond2 = 'YES' then leave
do c=1 to bignum
if cond3 = 'YES' then leave
if cond4 = 'YES' then leave b
if cond5 = 'YES' then iterate
if cond6 = 'YES' then interate b
do d=1 to bignum
if cond7 = 'YES' then leave
if cond8 = 'YES' then leave c
if cond9 = 'YES' then iterate a
do e=1 to bignum
if cond10 = 'YES' then leave a
end
end
end
end
end

Rob

Gardiner, Roy

unread,
Nov 11, 2004, 7:51:59 AM11/11/04
to
> From: Robert Zenuk [SMTP:Robz...@AOL.COM]

>
> Additionally, if you change your do loop to include an iteration variable,
> you can leave a particular loop within the nested loop hierarchy by using
> leave
> x.
>
Why didn't Mike allow 'leave <label>' where <label> is a label in
front of the DO keyword? It seems daft, yet Mike knows more about language
design than some/most/all of us here.


The Royal Bank of Scotland plc, Registered in Scotland No. 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB

The Royal Bank of Scotland plc is authorised and regulated by the Financial Services Authority and represents The Royal Bank of Scotland Marketing Group. The Bank sells life policies, collective investment schemes and pension products and advises only on the Marketing Group's range of these products and on a With-Profit Bond produced by Norwich Union Life (RBS) Limited.

This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate.

Ryerse, Robin

unread,
Nov 11, 2004, 9:26:18 AM11/11/04
to
I would avoid interpret if at all possible. My suggestion to divorce the
display of the panels from the routines that process its contents. In the
following, "re_panela" and "re_panelb" are defined explicitly for their
associated "iterate" (and "leave") but they do not require further looping
operands. I don't know whether your requirements are for "iterate" or
"leave" but the concept is the same.

'DISPLAY PANEL(PANELA)'
do re_panela while rc < 8 & \fatal_error
necessary = 0
call process_panela_contents
if necessary then iterate re_panela
'DISPLAY PANEL(PANELB)'
do re_panelb while rc < 8 & \fatal_error
necessary = 0
call process_panelb_contents
if necessary then iterate re_panelb
'DISPLAY PANEL(PANELB)'
end
'DISPLAY PANEL(PANELA)
end


-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU]On Behalf
Of Edward Konig
Sent: Wednesday, November 10, 2004 8:55 PM
To: TSO-...@VM.MARIST.EDU
Subject: Build a Call List in REXX?


I am designing an application in REXX that has alternate paths from start to
finish.

At first I designed

LOOPA: DO WHILE RC < 8 & ^is_FATAL_ERROR
Call PROCESS_PANELA
If RC ^< 8 Then Leave
lOOPB: DO WHILE RC < 8 & ^is_FATAL_ERROR
Call PROCESS_PANELB
If RC ^< 8 Then Leave

...


End /* LOOPB */
End /*LOOPA */

----------------------------------------------------------------------

Phil Smith III

unread,
Nov 11, 2004, 11:18:25 AM11/11/04
to
*shudder* That looks like COBOL! OK, ok, I know, "Not that there's anything
wrong with that..."

As a general Rexx coding style suggestion, I'd code that loop something more
like:

do while RC < 8
if Process_PanelA() < 8 then call LOOPB /* Only of course I'd rename
LOOPB */
end

and I'd have a centralized error handler deal with whatever would set
"is_FATAL_ERROR". But I digress.

Your actual issue may be better handled by something like this:

level# = 1
CALL_LIST.level# = PROCESS_PANELA

rc = CallWhoever(CALL_LIST.1)
level# = level# + 1CallWhoever()
...

CallWhoever:
arg callee
signal value callee


That lets you do a symbolic function call: LOOPB (or whatever "label" is set
to) can just do a RETURN and wind up back where you want it to.

Does this help?

...phsiii


-----Original Message-----
Date: Wed, 10 Nov 2004 20:54:41 -0500
From: Edward Konig <kon...@WORLDNET.ATT.NET>
Subject: Build a Call List in REXX?

I am designing an application in REXX that has alternate paths from start to
finish.

At first I designed

LOOPA: DO WHILE RC < 8 & ^is_FATAL_ERROR
Call PROCESS_PANELA
If RC ^< 8 Then Leave
lOOPB: DO WHILE RC < 8 & ^is_FATAL_ERROR
Call PROCESS_PANELB
If RC ^< 8 Then Leave

...


End /* LOOPB */
End /*LOOPA */

Then I realized that for certain values of the parameters, I would want to

...

...

Thanks
Ed K
...

----------------------------------------------------------------------


For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

------------------------------

End of TSO-REXX Digest - 9 Nov 2004 to 10 Nov 2004 (#2004-237)
**************************************************************

Stephen E. Bacher

unread,
Nov 11, 2004, 12:34:12 PM11/11/04
to
Here's a section of a REXX ISPF dialog I coded not long ago:

/*------------------------------------------------------------------*/

do forever
call display_first_panel
select
when result = "END" then leave
when result = "SHOW" then call doshow showpanel1
when result = "REDO" then iterate
when result = "GO" then do
do forever
call display_second_panel
select
when result = "END" then leave
when result = "SHOW" then call doshow showpanel2
when result = "REDO" then iterate
when result = "GO" then do
do forever
call display_third_panel
select
when result = "END" then leave
when result = "SHOW" then call doshow showpanel3
when result = "REDO" then iterate
when result = "GO" then do
do forever
call display_fourth_panel
select
when result = "END" then leave
when result = "SHOW" then call doshow showpanel4
when result = "REDO" then iterate
when result = "GO" then do
do forever
call display_member_list_or_process_member
select
when result = "END" then leave
when result = "SHOW" then call doshow showpanel5
when result = "REDO" then iterate
when result = "GO" then iterate


end
end
end
end
end
end
end
end
end
end

end
end
end
end

/*------------------------------------------------------------------*/

....and as an example, here is one of the procedures called:

/*------------------------------------------------------------------*/

display_third_panel:

temp = xxbk
if skip <> "NO" then call ispf "CONTROL NONDISPL" skip
call display_ispf_panel "X4COL3"; if result > 0 then return "END"
if temp = "YES" & xxbk = "NO" then do
call ispf "DISPLAY PANEL(X4BKERR)"
return "REDO"
end

call set_compiler_parameters; if result = "BAD" then return "REDO"

if skip = "NO" then do
call create_dollardd; if result = "BAD" then return "REDO"
end

if zcmd = "SHOW" then return "SHOW"
else return "GO"

/* ------------------------------------------------------------------ */

The idea is that each display function can return one of several
return values, indicating whether to go forward, go back, redisplay,
or start over from the beginning. (SHOW is a special debugging function
which can be invoked from any panel.)

As far as skipping panel displays in the normal sequence, which is
what I think Ed is really asking about:

I followed the ISPF paradigm, which is that it really processes every
panel invisibly, whether you see it or not. In this case, a skip flag
is interrogated and non-display mode set if it is on. I didn't allow
for skipping the same panels in reverse; that's not normally how ISPF
native dialogs work, anyway.

- seb

---------------------------------------------------------------------

Jeremy C B Nicoll

unread,
Nov 11, 2004, 1:20:55 PM11/11/04
to
In article <LPBBJOMFIGCDJGBOG...@worldnet.att.net>,

Edward Konig <kon...@WORLDNET.ATT.NET> wrote:
> I am designing an application in REXX that has alternate paths from
> start to finish.

> At first I designed

> LOOPA: DO WHILE RC < 8 & ^is_FATAL_ERROR
> Call PROCESS_PANELA
> If RC ^< 8 Then Leave

> lOOPB: DO WHILE RC < 8 & ^is_FATAL_ERROR
> Call PROCESS_PANELB
> If RC ^< 8 Then Leave

> ...


> End /* LOOPB */
> End /*LOOPA */

Rather than deeply nesting things I'd write each separate level of the
process as a single-level loop in a procedure which you can call and
will return a result indicating whether the code should go on, or fall
back,or if it went fatally wrong.

Your mainline could be something like:

section = 1 /* start with section 1 of the code */
do while no_reason_to_stop
select
when section == 1 then nextaction = process1()
when section == 2 then nextaction = process2()
...
end
if nextaction == "error" then do
say "failure"
leave
end

/* if what happens next is simple you could get away with */
/* adding 1 or subtracting 1 from session: */

if nextaction == "forward" then section = section + 1
else section = section - 1

if section = 99 then leave /* we've done all needed sections */
end

Deeply nesting is error-prone - you're better to think of a sequence of
independent actions.

> Then I realized that for certain values of the parameters, I would
> want to "skip a loop" in this, and go to the next deeper nested loop.

> I also want to be able to backtrack up along the path taken down,
> skipping the same calls as were skipped on the path down.

If you want to be able to visit sections in an arbitrary order and
allow the user to reverse that order, add the name of the section you
are in to a list of sections visited as you start the section. If you
need to go back a level knock off the name that records what session
you are in now, then remove the name that describes where you were
before and go there.

--
Jeremy C B Nicoll - my opinions are my own.

0 new messages