IMHO the most serious problems with REXX are:
1. The behavior of SIGNAL inside a do block or procedure.
2. The similarity to PL/I that leads people to expect PL/I
semantics for things that are very different in REXX.
FWIW, I don't normally run with NOVALUE active, but that might be best for
people who are not yet thoroughly familiar with REXX semantics. Also,
introductory and training material really ought to lay more stress on trace I;
it's amazing how many bugs become obvious when you look at the trace output.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of
Hobart Spitz <orexx...@gmail.com>
Sent: Wednesday, June 13, 2018 4:07 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX calling bpxwunix when SIGNAL NOVALUE active
Bruce;
I'm not sure whether you are asking for help, reporting a problem in a
sample, or offering a solution.
Since you haven't said which line failed, I'm just be guessing.
I think you need to quote StdErr. . That should allow you to turn NOVALUE
back on. I prefer to use it most of the time also.
My typical NOVALUE handler looks like this:
*novalue:say condition() condition("c") condition("d") "in line"
sigl"."parse source Sourcesay Source /* in case we are a few levels down in
external modules */exit -889*
I'd also recommend against TRACE OFF. A typo can turn a REXX instruction
into a host command, and those problem can be hard to find. (The proper
way to write TRACE is to omit the quotes; they imply VALUE, which takes a
few extra machine instructions.
Seymour, your suggestion is good. If anything is wrong with REXX, it's
that it's such an easy language to write, people just jump in without
really understanding it.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Wed, Jun 13, 2018 at 2:18 PM, Seymour J Metz <sme...@gmu.edu> wrote:
> IMHO examples of REXX calls in any documentation should include both
> quoted stem names and variable containing the stem name, with appropriate
> comments. The descriptions should make it clear that normal REXX expression
> syntax applies, and the manuals should not make incorrect statements in the
> name of simplicity.
>
> FWIW, similar considerations apply to descriptions of the JCL for various
> programs; all too many manuals make incorrect statements in an effort to
> avoid either an accurate description or a reference to the JCL Reference
> manual.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ________________________________________
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
> of Peter Hunkeler <p...@gmx.ch>
> Sent: Wednesday, June 13, 2018 9:00 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: AW: REXX calling bpxwunix when SIGNAL NOVALUE active
>
> >call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr.
>
>
> The FM manual describes the parameters to be "the name of a compound
> variable". If you don't quote, REXX will try to dereference the variables,
> does not find them, and raises NOVALUE if activated. If not, those which
> were initialized (unsorted_data & sorted_data) are replace by a blank.
>
>
> I think the examples in the doc should be updated to quote any and all of
> the parameters which denote a stem variable.
> --
> Peter Hunkeler
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
