How to code "between" test

[Bill Ashton]

Hello!

Is there a short way to code an If test for a value bwtween two values?

For example, if the test variable has the value 25, and I want to test if
it is between 20 and 45, I would like to code something like;
If 20 <= test <= 45

However, this does not work, as it processes the equal priority commands
linearly:
1. 20 <= test gives a result of 1 (true)
2. 1 <= 45 is also true, so the end result is true.

I could code If ((test >= 20) & (test <= 45)).... but I have a number of
fields I am testing, and the field "test" is really a Substring based on a
LastPos and Pos and Length all in a single line, and I was trying to keep
my coding short and simple.

Thanks, guys!

--
Thank you and best regards,
*Billy Ashton*

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

[Vitonis, Tony]

IF InRange(test, 20, 45) THEN ...

InRange:
PROCEDURE
PARSE ARG Candidate, Minimum, Maximum
RETURN (Minimum <= Candidate) & (Candidate <= Maximum)

[Brenton, Ren]

If the range (in your example 20 - 45) is the same for all your "number of fields";then

valid_entries = ' 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 '


If Pos(' 'test1' ',valid_entries) > 0;Then .....
If Pos(' 'test2' ',valid_entries) > 0;Then .....
If Pos(' 'test3' ',valid_entries) > 0;Then .....
...
If Pos(' 'test9' ',valid_entries) > 0;Then .....


And if there was some sort of consistency in the naming of your "test" variables (as shown above), you could do something like:

Do i = 1 to number_of_fields

If Pos(' 'Value(test||i)' ',valid_entries) > 0;Then ...

End


For example:

number_of_fields = 3
test1 = 23
test2 = 11
test3 = 46

Do i = 1 to number_of_fields

If Pos(' 'Value(test||i)' ',valid_entries) > 0;Then Say 'good'
Else Say 'bad'

End

Which yields:

good
bad
bad

This might or might not be simpler depending on your actual data elements. Just something to think about.

Enjoy,

Ren

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bill Ashton
Sent: Monday, April 09, 2012 12:19 PM
To: TSO-...@VM.MARIST.EDU

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Bill Turner, WB4ALM]

cute! Never thought of doing it that way.
Tony, Thank you for the example!

/s/ Bill Turner, wb4alm

On 04/09/2012 12:33 PM, Vitonis, Tony wrote:
> IF InRange(test, 20, 45) THEN ...
>
> InRange:
> PROCEDURE
> PARSE ARG Candidate, Minimum, Maximum
> RETURN (Minimum<= Candidate)& (Candidate<= Maximum)
>
>

[Bob Bridges]

An epiphany has just broken upon me. I've been writing in REXX for almost
twenty years, and it's only exceptionally that I use PROCEDURE; normally I
do without, but stick it in where it seems to be needed. Of course, that
way I have to deal with the occasional need to think about the names I use
inside functions and subroutines, and sometimes I forget and have to figure
out why my program isn't working right.

But suddenly I'm not sure why I've been doing it that way. Ok, sure, it
makes it easier to access main-routine variables, but EXPOSE can do that
with minimum difficulty. I'm minded to change my habits.

But hasn't there been some discussion here about the PROCEDURE statement?
Someone tell me why I SHOULDN'T start using it, please. The reasons needn't
be persuasive; I just want to hear the down side before changing over.

---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313

/* The proverbial German phenomenon of the "verb-at-the-end", about which
droll tales of absentminded professors who would begin a sentence, ramble on
for an entire lecture, and then finish up by rattling off a string of verbs
by which their audience, for whom the stack had long since lost its
coherence, would be totally nonplussed, are told, is an excellent example of
linguistic pushing and popping. The confusion among the audience that
out-of-order popping from the stack, onto which the professor's verbs had
been pushed, is amusing to imagine, could engender. -from _Gödel, Escher,
Bach: An Eternal Golden Braid_ by Douglas R Hofstadter */

-----Original Message-----
From: Vitonis, Tony
Sent: Monday, April 9, 2012 12:33

IF InRange(test, 20, 45) THEN ...

InRange:
PROCEDURE
PARSE ARG Candidate, Minimum, Maximum
RETURN (Minimum <= Candidate) & (Candidate <= Maximum)

[Vitonis, Tony]

One downside is that you have to be mindful of which variables you want to share between routines, and put up with error messages when you don't get them right. I say that half in jest, of course; it's a best practice to be mindful of such things.

Here's a rewrite without PROCEDURE, but with its benefits:

InRange: RETURN (ARG(2) <= ARG(1)) & (ARG(1) <= ARG(3))

Of course, you lose the self-documentation.

-----Original Message-----
From: Bob Bridges

An epiphany has just broken upon me. I've been writing in REXX for almost
twenty years, and it's only exceptionally that I use PROCEDURE; normally I
do without, but stick it in where it seems to be needed. Of course, that
way I have to deal with the occasional need to think about the names I use
inside functions and subroutines, and sometimes I forget and have to figure
out why my program isn't working right.

But suddenly I'm not sure why I've been doing it that way. Ok, sure, it
makes it easier to access main-routine variables, but EXPOSE can do that
with minimum difficulty. I'm minded to change my habits.

But hasn't there been some discussion here about the PROCEDURE statement?
Someone tell me why I SHOULDN'T start using it, please. The reasons needn't
be persuasive; I just want to hear the down side before changing over.

[Walter Pachl]

if inrange(test,20,45) Then
---- Bill Ashton <bill00...@GMAIL.COM> schrieb:

[Davis, James [E] , NIH/CIT]

On rare occasions I won't use Procedure. One example is referring to a bunch of variables from the caller - by name - with Value(). I usually feel guilty on these occasions. Probably ought to use a stem and Expose.

James Davis
National Institutes of Health

-----Original Message-----
From: Bob Bridges [mailto:rhb...@ATTGLOBAL.NET]
Sent: Monday, April 09, 2012 1:16 PM
To: TSO-...@VM.MARIST.EDU

[Bill Turner, WB4ALM]

Bob, Under REXX one of the "problems" with procedure is that it DOES
isolate the varables....

There is a minor problem when using nesting procedures, and when an
innermost procedure needs to have access to a varable in the mainline
which called the outermost procedure. Remember that "expose" gives the
inner procedure access to any variables defined in the calling routine.
If the calling routine is also a procedure, then you do not have access
to variables defined outside the calling routine.

Read o n, my explanation might not be real clear, but I have a way
around that "problem"...


if you have a procedure (ProcA) that calls another procedure (ProcB) and
neither needs access to external variables, then all is fine.

But it "ProcB" needs access to "VarC", then "VarC" has to be exposed in
BOTH procedure statements.


Varc = 300
abc = ProcA(some parms)
.
.
.

ProcA: Procedure expose VarC
.
somevalue = ProcB(some parms).

Return somevalue /**** return from ProcA ***/



ProcB: Procedure expose VarC
.
.
VarC = VarC + 1

return somevalue /**** return from ProcA ***/

= = = = =

I get around this problem by using a set of "standard" stems...

A lot of my code passes runtime "options" into various procedures....

so I have a standard stem called "options." which is exposed in each
procedure.

I also have another trick for naming the "tails" to those stems.

Lets say that I have an Option called "debug" and another option called
"thingy"

using a rexx programming trick I can prefix these two names with a zero
(0) and create the following two compound variable names:

OPTIONS.0debug
OPTIONS.0thingy

if the mainline sets the values as:

OPTIONS. = 0 /*** create a
default value ***/
OPTIONS.0debug = 1 /*** set the value to a
logic "TRUE" ***/
OPTIONS.0thingy = "some text value" /**** set the value to someting ****/

then if each Procedure is coded as
procz: Procedure expose options. /*** note the period after
"options" ***/


Then every procedure has access to ANY value added (or modified) to the
stem "options."
the "0xxxx" trick provides instant documentation.

Tjhis process minimizes the NUMBER of variables which must be coded on
all of the intermediate Procedures...

-----

hopefully this makes sense, if not, ask questions.

/s/ Bill Turner, wb4alm

[Walter Pachl]

well, I was only second :-(
second thought:
/** REXX */
x=5
If inrange('x',10,20) Then
Say 'ok'
x=33
If inrange('x',10,20) Then
Say 'ok'
x=15
If inrange('x',10,20) Then
Say 'ok'
Exit
inrange:
r___=0
Parse arg v___,lo,hi
vval=value(v___)
Select
When vval<lo Then
Say v___ '('vval') is less than' lo
When vval>hi Then
Say v___ '('vval') is larger than' hi
Otherwise
r___=1
End
Return r___

Walter
---- Walter Pachl <christel....@CHELLO.AT> schrieb:

[Vitonis, Tony]

Sometimes I'll share via a stem, to ease the pain of repeating the list of variables to pass around.

[Vitonis, Tony]

I'm not sure what you're saying "no" to. What problem does this solve?

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Adrian Stern
Sent: Monday, April 09, 2012 2:13 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: PROCEDURE

Well no since:

Foobar: procedure
Arg test, 20, 45

Solves that problem (if called as a function)

Foobar: procedure
Arg test 20 45

If called as a sub-routine

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of

[Horacio Villa]

Once I used a var listing all the vars I was exposing.
Initially, exposeList = ''
Then, when needed (supose you want to expose variable varA) , exposeList
= exposeList 'varA'
Or you may initalize all the values in advance, from the beginning.

procedure expose (exposeList)

[Bob Bridges]

Your point is well taken, Adrian, but personally I stopped having much
trouble with loop indices since I abandoned one-letter names for short-term
variables. I used to name indices i, j, k and so forth, and would
frequently use x, y and z for values that I saved over no more than a line
or two. But one day I discovered that 'x' isn't a great idea because
sometimes I have to use it up against a string constant and then REXX thinks
I'm specifying a hex constant instead. So I started using two-letter
variable names, usually v-something instead of x, y and z and i-something
for my indices.

That worked great in REXX - REXX doesn't care if my loop uses 'is', 'if' or
'it' for an index - but it doesn't work so well in VBS and other languages,
so I switched to j-something. After that I didn't have to think about it
any more.

For me the problem is in other standard names. If I'm writing a REXX to
manipulate ACF2 data then LID and/or TYP are very likely to be used in the
main routine and in subroutines. If I'm not thinking about it, I may use
LID in the main routine and then supply an argument to a function that
accepts one of its parms as LID, too; voilą, my main program is confused.
When I think about it I add some sort of kludgy prefix to all the names in
the subroutine, but it's long past time I got into the habit of using
PROCEDURE by reflex and making NOT using it the exception.

---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313

/* "I will tell you what I say", answered Ransom, jumping to his feet. "Of
course good came of it. Is Maleldil a beast that we can stop His path, or a
leaf that we can twist His shape? Whatever you do, He will make good of it.
But not the good He had prepared for you if you had obeyed Him. That is
lost forever. The first King and first Mother of our world did the
forbidden thing; and He brought good of it in the end. But what they did
was not good; and what they lost we have not seen." -from Pelelandra by C S
Lewis */

-----Original Message-----
From: Adrian Stern
Sent: Monday, April 9, 2012 13:26

There is no down side and if you're as lazy as I am you should use it so
that the favourite variable i ( do i=) can be used over and over without
problems and without having to find another letter - passing variables and
expose for stems solve any isolation problems.

-----Original Message-----
From: Bob Bridges

Sent: den 9 april 2012 19:16

An epiphany has just broken upon me. I've been writing in REXX for almost
twenty years, and it's only exceptionally that I use PROCEDURE; normally I
do without, but stick it in where it seems to be needed. Of course, that
way I have to deal with the occasional need to think about the names I use
inside functions and subroutines, and sometimes I forget and have to figure
out why my program isn't working right.

But suddenly I'm not sure why I've been doing it that way. Ok, sure, it
makes it easier to access main-routine variables, but EXPOSE can do that
with minimum difficulty. I'm minded to change my habits.

But hasn't there been some discussion here about the PROCEDURE statement?
Someone tell me why I SHOULDN'T start using it, please. The reasons needn't
be persuasive; I just want to hear the down side before changing over.

[Paul Gilmartin]

On Apr 9, 2012, at 11:16, Bob Bridges wrote:
>
> But hasn't there been some discussion here about the PROCEDURE statement?
> Someone tell me why I SHOULDN'T start using it, please. The reasons needn't
> be persuasive; I just want to hear the down side before changing over.

On Apr 4, 2012, at 09:43, Rob Zenuk wrote:
>
> While PROCEDURE is nice, I did find it was easier to support my framework
> approach if I abandon PROCEDURE and kept all my subroutines internal. I am
> not saying this is right or wrong, just what I evolved into to solve the
> problem I wanted to solve. This did require a lot more attention to
> variable names to insure uniqueness and avoid unanticipated variable
> overlap. So, I have a subroutine variable naming convention that helps
> avoid problems.
>
Whereas I use PROCEDURE a lot. Rob, with your scheme, how
do you avoid conflicts with local variable names? Prefixing?

My habit is to use the stem "G." (for "Global") for variables
generally to be shared, then "procedure expose G.". Mostly,
everything else is private.

One fly in the ointment is "SYSCALLS( 'ON' )", which sets
dozens of simple variables. I must either EXPOSE them as
needed down any call chain, or add a redundant
"SYSCALLS( 'ON' )" in any leaf routine that needs some of
them.

I'm inclined to whine on MVS-OE.

-- gil

[Leslie Turriff]

Gil,
Where is SYSCALLS() documented? It's not in the Rexx Language Reference.

Leslie

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin
Sent: Monday, April 09, 2012 4:14 PM
To: TSO-...@VM.MARIST.EDU

Subject: Re: [TSO-REXX] PROCEDURE


One fly in the ointment is "SYSCALLS( 'ON' )", which sets
dozens of simple variables. I must either EXPOSE them as
needed down any call chain, or add a redundant
"SYSCALLS( 'ON' )" in any leaf routine that needs some of
them.

I'm inclined to whine on MVS-OE.

-- gil

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

Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.

[Rob Zenuk]

Mostly prefixing and/or unique stems used by a subroutine...

Since I keep subroutines in a separate PDS used by my @REFRESH edit macro, I
can quickly search the PDS to see if a new variable name will cause a
conflict.

I admit it does require some extra steps to insure I do not shoot myself in
the foot. If I was to start over (or ever get the chance to focus only on
REXX and rewrite everything), I might do it differently now...

Rob

[Vitonis, Tony]

This post is awaiting moderation on MVS-OE. I think it's relevant here, so:

CALL SetSyscalls
CALL SyscallVarUser

SetSyscalls:
PROCEDURE EXPOSE SyscallStem.

CALL SYSCALLS "ON"
/* Use the handy-dandy RXVARS() to get a list of created variables */
/* Iterate through defined variables, assigning them to SyscallStem.<varname> */

RETURN

SyscallVarUser:
PROCEDURE EXPOSE SyscallStem.

/* Use SyscallStem.<varname> ... */

RETURN

=)

-----Original Message-----
From: Paul Gilmartin

One fly in the ointment is "SYSCALLS( 'ON' )", which sets
dozens of simple variables. I must either EXPOSE them as
needed down any call chain, or add a redundant
"SYSCALLS( 'ON' )" in any leaf routine that needs some of
them.

I'm inclined to whine on MVS-OE.

[Vitonis, Tony]

Using REXX and z/OS UNIX System Services
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb600%2Fbpxzb6a003.htm

-----Original Message-----
From: Leslie Turriff

Where is SYSCALLS() documented? It's not in the Rexx Language Reference.

-----Original Message-----
From: Paul Gilmartin

One fly in the ointment is "SYSCALLS( 'ON' )", which sets dozens of simple variables. I must either EXPOSE them as needed down any call chain, or add a redundant "SYSCALLS( 'ON' )" in any leaf routine that needs some of them.

I'm inclined to whine on MVS-OE.

[Paul Gilmartin]

On Apr 9, 2012, at 16:04, Leslie Turriff wrote:
>
> Where is SYSCALLS() documented? It's not in the Rexx Language Reference.
>

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb6a0/1.2.2

Ooooh! We could have a turf war here. Some subscribers
are unduly (IMO) fussy about exactly which Rexxen are
mentioned in this forum.

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin
> Sent: Monday, April 09, 2012 4:14 PM
>

> One fly in the ointment is "SYSCALLS( 'ON' )", which sets
> dozens of simple variables. I must either EXPOSE them as
> needed down any call chain, or add a redundant
> "SYSCALLS( 'ON' )" in any leaf routine that needs some of
> them.
>
> I'm inclined to whine on MVS-OE.
>

(I did.)

[Paul Gilmartin]

On Apr 9, 2012, at 16:12, Vitonis, Tony wrote:
>
> /* Use the handy-dandy RXVARS() to get a list of created variables */
>

Perhaps. But when I tried to get the handy-dandy RXVARS()
to play with, Rapidshare told me:

Download not available
The following download is not available:
https://rapidshare.com/files/2156022311/rxvars.xmi | 0.00 MB

(which seems to be an unconventional paraphrase of "404".)

-- gil

[Lorne Dudley]

I have the following fragment of code that I would like to make more
general for reading fixed length binary records.

The problem is that my ooRexx on Windows insists that the second
parameter to charin must be numeric.

I would like to produce a routine with a call equivalent to
~charin(pos,lrecl) .

Does anyone have a clever method of achieving this ?

pos = 1
recl = 397 /* LRECL=397 */


do forever

line = inputobject~charin(pos,397)
pos = pos + recl

end

[Glenn Knickerbocker]

On 4/9/2012 9:51 PM, Lorne Dudley wrote:
> I would like to produce a routine with a call equivalent to
> ~charin(pos,lrecl) .
>
> Does anyone have a clever method of achieving this ?
>
> pos = 1
> recl = 397 /* LRECL=397 */

Is the problem just a typo? You set variable RECL but your example
above wants to reference variable LRECL.

ŹR

[Lorne Dudley]

Yes Glenn !

Thank you, a second set of eyes is helpful.

Regards

Lorne

[Vitonis, Tony]

I suggested ARG(n) as a workaround for one-line functions, if you don't like PROCEDURE everywhere. The downside of the approach is that you don't get to see variable names that [ideally] convey the sense of what's being done.

-----Original Message-----
From: Adrian Stern

He seemed to be complaining about no passed names, just arg(x)

[Phil Smith III]

Bob Bridges wrote about using PROCEDURE, asking if there was a downside, and various folks answered, mostly noting that variable isolation can be confusing if you have nested calls and need global access to variables.

I use a coding convention that global variables are all of the form: g._<actual stem>

The underscore keeps me from tripping over literal stems (yes, _XYZ is a valid variable, but it isn't tricky to just never set any of those).

So:

g._userid = userid()
...
call Something
...
Something: Procedure expose g.

All my PROCEDUREs have EXPOSE G. and so it Just Works. Occasionally, in very large Rexx programs (thousands of lines), I'll add more global stems--say, D. for data, or C. for configuration values, and add those to my PROCEDURE EXPOSE lists. The point is, by keeping them to known stems, they're easy to manage (and easy to add to those EXPOSE lists when I do add one, since I can find all the PROCEDURE EXPOSE and change them easily).

I'd also note that traditionally, in the Bad Old days of much slower machines, we avoided PROCEDURE because it's relatively expensive. Nowadays I'd say that cost is not significant enough to worry about.

...phsiii

[Leslie Turriff]

Thank you both.

Leslie

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Paul Gilmartin

Sent: Monday, April 09, 2012 5:29 PM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] PROCEDURE

Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.

[Paul Gilmartin]

On Apr 10, 2012, at 06:23, Phil Smith III wrote:
>
> I use a coding convention that global variables are all of the form: g._<actual stem>
>
> The underscore keeps me from tripping over literal stems (yes, _XYZ is a valid variable, but it isn't tricky to just never set any of those).
>

I use G.9<actual stem>. 9XYZ is not a valid variable name. I
believe that digits are the only characters valid in symbols,
but not as initial characters of variables.

z/OS Unix (USS) uses many names beginning with '_'.

-- gil

[Glenn Knickerbocker]

On 4/10/2012 11:18 AM, Paul Gilmartin wrote:
> believe that digits are the only characters valid in symbols,
> but not as initial characters of variables.

Also dots, but those of course can't occur in symbols in tails.

ŹR

[Glenn Knickerbocker]

On 4/9/2012 1:19 PM, Bob Bridges wrote:
> But hasn't there been some discussion here about the PROCEDURE statement?

There's a small performance penalty in creating the new variable
environment, 10-20% of the cost of calling the routine and returning.

(I was pretty sure I remembered this from ages ago, but when I first
tried it out in CMS REXX I somehow got results suggesting the opposite.
I wish I had saved the exec that did that, because I thought I had
recreated it exactly but now I see the same results as in TSO and
compiled REXX. There was some weirdness with an old test exec I had
left at the bottom following my test routines, not commented out, which
I didn't notice was active code until it caused my compile to fail.)

ŹR

[Glenn Knickerbocker]