ooRexx - how to manage initial syntax errors?

I'm experimenting with ooRexx under Windows XP. My test exec (I know
there's a syntax error in the "parse arg" statement) contains:

/* REXX */

signal on syntax
signal on any

parse args alla
parse source implsyst invokdby srcefile rests
parse version langname langlevl langdate

say "args: '"alla"'"
say

say "source: implementation/system '"implsyst"'"
say " invoked by '"invokdby"'"
say " sourcefile '"srcefile"'"
say " (rest) '"rests"'"
say

say "version: language name '"langname"'"
say " language level '"langlevl"'"
say " language release date '"langdate"'"
say

say "***" ; parse pull waste
exit

any:
say "any error"
parse pull waste
exit

syntax:
say "syntax error"
parse pull waste
exit


Of course when I run it within an already-open command window I get the
pre-execution syntax message displayed:


C:\Documents and Settings\Laptop>c:\parsesysetc
6 *-* parse args alla
Error 25 running c:\ParseSysetc.rex line 6: Invalid subkeyword found
Error 25.12: PARSE must be followed by one of the keywords ARG, ...

- which is how I found out what was wrong. But if I just double click the
exec, a command window opens, ooRexx attempts to run the exec, fails, the
window shuts, and I don't see any error message.


How is one meant to trap/manage the sorts of syntax problems that are
reported before the exec starts to run?

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

Lots of ways come to mind and what works best for you will depend on how
you develop your Rexx programs. Many of us use an editor called
SlickEdit to write our programs and we have "customized" it to permit us
to run the REXXC utility on the program we are writing. That will catch
the typos like the one you experienced. If you are using an editor that
doesn't support running build-like commands, you could open a command
window and run REXXC <program-name> after you save the file in your
editor. Automating that process so you can do it via drag-and-drop
should also be possible I would guess. Finally, there are two other
programs that invoke the ooRexx interpreter that might be of some
assistance: REXXHIDE and REXXPAWS. The first runs the interpreter
without opening a command window - useful for ooDialog or other GUI
programs - and the second will leave the command window open after the
interpreter completes so you can read the messages on the screen. Hope
that gives you some ideas...

Jeremy Nicoll - news posts wrote:
> I'm experimenting with ooRexx under Windows XP. My test exec (I know
> there's a syntax error in the "parse arg" statement) contains:
>
> /* REXX */
>
> signal on syntax
> signal on any
>
> parse args alla
> parse source implsyst invokdby srcefile rests
> parse version langname langlevl langdate
>
> say "args: '"alla"'"
> say
>
> say "source: implementation/system '"implsyst"'"
> say " invoked by '"invokdby"'"
> say " sourcefile '"srcefile"'"
> say " (rest) '"rests"'"
> say
>
> say "version: language name '"langname"'"
> say " language level '"langlevl"'"
> say " language release date '"langdate"'"
> say
>
> say "***" ; parse pull waste
> exit
>
> any:
> say "any error"
> parse pull waste
> exit
>
> syntax:
> say "syntax error"
> parse pull waste
> exit
>
>
> Of course when I run it within an already-open command window I get the
> pre-execution syntax message displayed:
>
>
> C:\Documents and Settings\Laptop>c:\parsesysetc
> 6 *-* parse args alla
> Error 25 running c:\ParseSysetc.rex line 6: Invalid subkeyword found
> Error 25.12: PARSE must be followed by one of the keywords ARG, ...
>
> - which is how I found out what was wrong. But if I just double click the
> exec, a command window opens, ooRexx attempts to run the exec, fails, the
> window shuts, and I don't see any error message.
>
>
> How is one meant to trap/manage the sorts of syntax problems that are
> reported before the exec starts to run?
>

"news.nep.net" <gil_b@bellsouth.net> wrote:

> Lots of ways come to mind and what works best for you will depend on how
> you develop your Rexx programs. Many of us use an editor called
> SlickEdit to write our programs and we have "customized" it to permit us
> to run the REXXC utility on the program we are writing. That will catch
> the typos like the one you experienced....

Thanks; I'm using Kedit, which can have macros written in KEXX (which is of
course mainly Rexx), and I'll be able to write something that will do this.

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

Jeremy Nicoll - news posts wrote:
> How is one meant to trap/manage the sorts of syntax problems that are
> reported before the exec starts to run?

Excellent question!

I stuffed the core of your example into the ObjectCUR 3.5 class library... which I was specifically trying to make that an *exceptional* version of the class library. Indeed "speling" arg wrong (args)
causes the exception handlers to not take affect!

I was hoping my running the main() code inside of an object and so forth would be sufficient padding to make ooRexx rely on the exception handlers instead of it taking matters into its own hands.

So I second this question.

Following is a test run - fail, then success:

mdlueck@aleks:~/Desktop/test$ rexx ArvHelloWorld.rex
79 *-* parse args alla
REX0025E: Error 25 running /home/mdlueck/Desktop/test/ArvHelloWorld.rex line 79: Invalid subkeyword found
REX0296E: Error 25.12: PARSE must be followed by one of the keywords ARG, LINEIN, PULL, SOURCE, VALUE, VAR, or VERSION; found "ARGS"
mdlueck@aleks:~/Desktop/test$ rexx ArvHelloWorld.rex
args: 'PARMCHECK'

source: implementation/system 'LINUX'
invoked by 'METHOD'
sourcefile '/home/mdlueck/Desktop/test/ArvHelloWorld.rex'
(rest) ''

version: language name 'REXX-ooRexx_3.2.0(MT)'
language level '6.02'
language release date '30 Oct 2007'

***

mdlueck@aleks:~/Desktop/test$

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

By the way... I just tracked down why ObjectCUR 3.5 was having a hard time running that posted test code. This following bit was making ObjectCUR very unhappy. (Commented out the offending lines.)

It was objecting to parsing arg spelled correctly. Is that because running in this method there is no arg set, or...???

Perhaps I would turn on specific signals and not use the blanket "any"???

/*----------------------------------------------------------------------------------------------------------*/
/* Main */
::method Main
RxExceptionScript=self~ArvExceptionScript /* Fetch Exception Script */
signal on any name RxException /* General Exception Handling */

use arg ParmCheck /* Receive ParmCheck */

/*-------------------------------------------------------------------------------------------------------*/
/* Begin Your Program Here... */
--parse arg alla
parse source implsyst invokdby srcefile rests
parse version langname langlevl langdate

--say "args: '"alla"'"
say

say "source: implementation/system '"implsyst"'"
say " invoked by '"invokdby"'"
say " sourcefile '"srcefile"'"
say " (rest) '"rests"'"
say

say "version: language name '"langname"'"
say " language level '"langlevl"'"
say " language release date '"langdate"'"
say

say "***"
/* End Your Program Here w/ a Normal Exit Code... */
/*-------------------------------------------------------------------------------------------------------*/
return 0

RxException:
interpret RxExceptionScript /* Standard Info to Logs */
return 1 /* Enough, return in error */
/*----------------------------------------------------------------------------------------------------------*/


--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

I changed...

Michael Lueck wrote:
> signal on any name

to "signal on syntax name..." and I discovered that my exception handler routine / scriptlet was not robust enough to handle custom object types having been passed in with arg.

I will check into how to make it more robust.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

Michael Lueck wrote:

> I stuffed the core of your example into the ObjectCUR 3.5 class
> library... which I was specifically trying to make that an *exceptional*
> version of the class library. Indeed "speling" arg wrong (args) causes
> the exception handlers to not take affect!

After considering this, I guess using something like rexxc to check for errors is sufficient to catch the error.

"It was bad enough" that rexx refuses to even try running the program.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/