REXX calling bpxwunix when SIGNAL NOVALUE active

[Bruce Hewson]

I thought I would try out using "bpxwunix" in REXX.

The sample code worked fine.

But, I normally code with SIGNAL NOVALUE active.

Then the sample did not work. It took me a little while to work out.

This does work:-

/*REXX****************************************************************/
Trace 'o'
Signal on Syntax /* for unexpected results. */
/*===================================================================*/
unsorted_data. =
unsorted_data.0=5
unsorted_data.1="KIJJ"
unsorted_data.2="KQWR"
unsorted_data.3="ADGF"
unsorted_data.4="OEPE"
unsorted_data.5="VNVV"

sorted_data. =
sorted_data.0=0

cmd="sort"

call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr.

say "sorted_data:"
say "======="
do i=1 to sorted_data.0
say sorted_data.i
end

say "stderr:"
say "======="
do i=1 to stderr.0
say stderr.i
end
Return
/*===================================================================*/

I have not listed the diagnostic section for the SIGNAL processes.

Note the quoted stem names. This is required.

Regards
Bruce Hewson

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Peter Hunkeler]

Post by Bruce Hewson
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.

[Seymour J Metz]

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-***@listserv.ua.edu> on behalf of Peter Hunkeler <***@GMX.CH>
Sent: Wednesday, June 13, 2018 9:00 AM
To: IBM-***@listserv.ua.edu
Subject: AW: REXX calling bpxwunix when SIGNAL NOVALUE active

Post by Bruce Hewson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Hobart Spitz]

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.

Post by Seymour J Metz
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
________________________________________
Sent: Wednesday, June 13, 2018 9:00 AM
Subject: AW: REXX calling bpxwunix when SIGNAL NOVALUE active

Post by Bruce Hewson
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Seymour J Metz]

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-***@listserv.ua.edu> on behalf of Hobart Spitz <***@GMAIL.COM>
Sent: Wednesday, June 13, 2018 4:07 PM
To: IBM-***@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.

Post by Seymour J Metz
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
________________________________________
Sent: Wednesday, June 13, 2018 9:00 AM
Subject: AW: REXX calling bpxwunix when SIGNAL NOVALUE active

Post by Bruce Hewson
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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

Post by Peter Hunkeler

Post by Bruce Hewson
call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr.

...
I think the examples in the doc should be updated to quote any and all of the parameters which denote a stem variable.

+1
The same should apply to names of simple variables. (Are there any such?
Generally they appear proberly quoted in SYSCALL command examples.)

Also, I see:
... stdout is the number of lines output by the command.
Should be:
... stdout.0 is the number of lines output by the command.
(It has stdin.0 and stderr.0 correctly.)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Paul Gilmartin]

Post by Hobart Spitz
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.
...
Note the quoted stem names. This is required.
...
cmd="sort"
call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr.
....

I don't code a handler. If NOVALUE is caught I consider it a coding
error and fix the code. It might be a typo spelling a symbol. How
would I recover from that?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Bruce Hewson]

Hi,

Well, of course, as soon as I posted I then spotted that I had not corrected quoted the stderr. stem varname.

Actually, the sample code did not come from IBM but from:-

https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/bpxwunix_z_os_best_kept_secret10?lang=en

A very good blog update from Mr Packer.

The code below does work. My tests prior to quoting the stem variables did fail.

Tracing did show they were being set to blanks. It took a little while longer to interpret and understand the trace.

IBM examples are do not quote the stem variables, and are relying on the default STEM variable behaviour:-

To trap output from the ls command and display it:
call bpxwunix ’ls -l’,,out.
do i=1 to out.0
say out.i
end
To send output from the previous example to word count and print the byte count:
call bpxwunix ’wc’,out.,bc.
parse var bc.1 . . count
say ’byte count is’ count

To trap output on stack and feed it to word count:
if bpxwunix(’ls -l’,,stack)=0 then
call bpxwunix ’wc’,stack

ref: Using REXX and z/OS UNIX System Services SA23-2283-30

The post was to put in archives to remind that using quoted stem vars are better when calling bpxwunix.

Post by Bruce Hewson
I thought I would try out using "bpxwunix" in REXX.
The sample code worked fine.
But, I normally code with SIGNAL NOVALUE active.
Then the sample did not work. It took me a little while to work out.
This does work:-
/*REXX****************************************************************/
Trace 'o'
Signal on Syntax /* for unexpected results. */
/*===================================================================*/
unsorted_data. =
unsorted_data.0=5
unsorted_data.1="KIJJ"
unsorted_data.2="KQWR"
unsorted_data.3="ADGF"
unsorted_data.4="OEPE"
unsorted_data.5="VNVV"
sorted_data. =
sorted_data.0=0
cmd="sort"
call bpxwunix cmd,"unsorted_data.","sorted_data.",stderr.
say "sorted_data:"
say "======="
do i=1 to sorted_data.0
say sorted_data.i
end
say "stderr:"
say "======="
do i=1 to stderr.0
say stderr.i
end
Return
/*===================================================================*/
I have not listed the diagnostic section for the SIGNAL processes.
Note the quoted stem names. This is required.

Regards
Bruce Hewson

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Bruce Hewson]

Hello Hobart,

here are my NOVALUE and SYNTAX handlers:-

Signal on Novalue /* Clean diagnostics */
Signal on Syntax /* for unexpected results. */



/*===================================================================*/
Syntax:
Say "SYNTAX raised in line" sigl". rc="rc "("errortext(rc)")."
zsigl = sigl /* Number of sourceline in error */
Parse Version impl langlevel . /* Look at language level */
Signal Common /* continue with common code */

NoValue:
Say "NOVALUE raised at line" sigl
zsigl = sigl /* Number of sourceline in error */
Parse Version impl langlevel . /* Look at language level */
If langlevel > 3.45 Then Do /* Condition BIF is supported */
Say "Then referenced variable is" "CONDITION"('D')
End
Signal Common /* continue with common code */

Common: /* Common error handling */
Trace 'o' /* Ensure no tracing */
If sourceline() <> 0 Then Do /* Source lines available */
Say '"'CompleteSource(zsigl)'"'/* Show the line in error */
End
If Left(impl,5) <> "REXXC" Then Do /* NOT running a compiled program*/
Say "You can look around now..." /* Tell user what they can do */
Trace ?R /* interactive tracing */
Nop
End
Exit

CompleteSource: Procedure
Parse Arg linenum
If Datatype(linenum) <> "NUM" Then linenum=1
line = Strip(SourceLine(linenum))

Do While (( Right(line,1) = ",") & (linenum <= SourceLine()))
linenum = linenum + 1
line = Left(line,(length(line)-1)) Strip(SourceLine(linenum))
End

Return line

Post by Hobart Spitz
Bruce;

<snip>

Post by Hobart Spitz
*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.

<snip>

Regards
Bruce

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN