Stems as associative memory (Was: Multi-dimensional arrays in REXX)

2009-03-19 Thread Arthur Fichtl
One sort of applying this technique of stems is to use the as 
associative memory - where the content of a storage location is used as 
an address. Ther rules for resolving elements of a stem variable state 
that all parts after the first part of a stem are subject to be resolved.
As shown in ISDA  (the small interactive disassembler in cbttape), which 
is completely written in Rexx, it works as folllows:


Consider a hexcode sequence containing the following (hex)-characters:
0E1A
this is resolved to:
MVCL R1,R10

Internally it is accomplished by looking for the symbolic representation 
of x'0E' :

OPCODE.0E.FORMAT = 'RR' ; OPCODE.0E.MNEMO = 'MVCL'

the Rexx-instructions are:
Inst_Form = getInstruction_Format(hexaopcod)
.
.
.
getInstruction_Format:
arg hxo /* hexadecimal Opcode */
oform = opcode.hxo.fomat
return oform  /*returns  'RR'*/

.
.
.
IMnemo = opcode.hxo.mnemo /* IMenmo = 'MVCL' */

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-19 Thread Paul Gilmartin
On Thu, 19 Mar 2009 01:11:23 -0400, Gerhard Postpischil wrote:

Ian S. Worthington wrote:
 I'm aware of the distinction, but have always felt that that's a fairly
 reasonable working definition of default, at least up until a reassignment.

I suspect that he considers the language assignment of the
upper-cased variable name to be the default, hence the distinction?

While that's true, it's the lesser concern.  Misusing default
to describe the universal assignment can mislead the reader to
believe that the construct merely defines a value to be used
for members otherwise undefined.  With this assumption, readers
of the following program:

/* Rexx */ signal on novalue;  /*
  Universal assignment is not a default value.
*/
trace R

X.42 = 'specific '
say symbol( 'X.42' ) value( 'X.42' )

X.42 = 'universal'
say symbol( 'X.42' ) value( 'X.42' )

drop X.42
say symbol( 'X.42' ) value( 'X.42' )

... may expect incorrect results from the second and/or third
say instructions.  This is more likely for readers with
some programming experience, who are likely to make incorrect
and oversimplified assumptions about the implementation
mechanism.  Even IBM developers have fallen victim: at one
point an attempt to optimize storage management caused Rexx
to give incorrect results for the third say instruction.
This appears to have been repaired by APAR.

--gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-19 Thread Ian S. Worthington
Paul --

What you say, viz:

Misusing default
to describe the universal assignment can mislead the reader to
believe that the construct merely defines a value to be used
for members otherwise undefined.

is absolutely true, but I would hazard a guess, based on my own 20+ years of
rexx experience, that the vast majority of programmers only use, if they use
at it at all, the construction

x. = 'something'

at the top of their programs, and then never change it. 

Is calling that a default strictly accurate?  Of course not.  But in the
context of the original discussion, does rexx support multi-dimensional
arrays? I think that to describe it otherwise in a list of additional
features which might be of interest to a newcomer would be a severe case of
TMI.

BTW, Unless I've misunderstood your point, I'm not sure that your sample
program demonstrates the language feature we're discussing.  (x. = 'universal'
perhaps?)

i

-- Original Message --
Received: Thu, 19 Mar 2009 06:55:22 AM COT
From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multi-dimensional arrays in REXX

 On Thu, 19 Mar 2009 01:11:23 -0400, Gerhard Postpischil wrote:
 
 Ian S. Worthington wrote:
  I'm aware of the distinction, but have always felt that that's a fairly
  reasonable working definition of default, at least up until a
reassignment.
 
 I suspect that he considers the language assignment of the
 upper-cased variable name to be the default, hence the distinction?
 
 While that's true, it's the lesser concern.  Misusing default
 to describe the universal assignment can mislead the reader to
 believe that the construct merely defines a value to be used
 for members otherwise undefined.  With this assumption, readers
 of the following program:
 
 /* Rexx */ signal on novalue;  /*
   Universal assignment is not a default value.
 */
 trace R
 
 X.42 = 'specific '
 say symbol( 'X.42' ) value( 'X.42' )
 
 X.42 = 'universal'
 say symbol( 'X.42' ) value( 'X.42' )
 
 drop X.42
 say symbol( 'X.42' ) value( 'X.42' )
 
 .. may expect incorrect results from the second and/or third
 say instructions.  This is more likely for readers with
 some programming experience, who are likely to make incorrect
 and oversimplified assumptions about the implementation
 mechanism.  Even IBM developers have fallen victim: at one
 point an attempt to optimize storage management caused Rexx
 to give incorrect results for the third say instruction.
 This appears to have been repaired by APAR.
 
 --gil
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Stems as associative memory (Was: Multi-dimensional arrays in REXX)

2009-03-19 Thread Ian S. Worthington
This is a really nice example of the use stems can be put to once one stops
thinking of them as arrays.

To my mind though it contains one potential bug -- it depends on FORMAT and
MNENO remaining uninitialized.  I would prefer to prefix such symbols with,
eg, a 0 to make sure they couldn't be, eg 0FORMAT and 0MNEMO.  Or, in programs
with more complex lookups, I would often be more explicit: 0Opcode2Mnemonic
and 0Opcode2Format, which helps me to remember what to put in as as well as
what (should) come out: useful as my memory fades...

i

-- Original Message --
Received: Thu, 19 Mar 2009 02:51:09 AM COT
From: Arthur Fichtl arthur_fic...@afisumag.de
To: IBM-MAIN@bama.ua.edu
Subject: Stems as associative memory (Was: Multi-dimensional arrays in REXX)

 One sort of applying this technique of stems is to use the as 
 associative memory - where the content of a storage location is used as 
 an address. Ther rules for resolving elements of a stem variable state 
 that all parts after the first part of a stem are subject to be resolved.
 As shown in ISDA  (the small interactive disassembler in cbttape), which 
 is completely written in Rexx, it works as folllows:
 
 Consider a hexcode sequence containing the following (hex)-characters:
 0E1A
 this is resolved to:
 MVCL R1,R10
 
 Internally it is accomplished by looking for the symbolic representation 
 of x'0E' :
 OPCODE.0E.FORMAT = 'RR' ; OPCODE.0E.MNEMO = 'MVCL'
 
 the Rexx-instructions are:
 Inst_Form = getInstruction_Format(hexaopcod)
 .
 .
 .
 getInstruction_Format:
 arg hxo /* hexadecimal Opcode */
 oform = opcode.hxo.fomat
 return oform  /*returns  'RR'*/
 
 .
 .
 .
 IMnemo = opcode.hxo.mnemo /* IMenmo = 'MVCL' */
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-19 Thread Paul Gilmartin
On Thu, 19 Mar 2009 07:37:08 -0500, Ian S. Worthington wrote:

Paul --

What you say, viz:

Misusing default
to describe the universal assignment can mislead the reader to
believe that the construct merely defines a value to be used
for members otherwise undefined.

is absolutely true, but I would hazard a guess, based on my own 20+ years of
rexx experience, that the vast majority of programmers only use, if they use
at it at all, the construction

x. = 'something'

at the top of their programs, and then never change it.

Is calling that a default strictly accurate?  Of course not.  But in the
context of the original discussion, does rexx support multi-dimensional
arrays? I think that to describe it otherwise in a list of additional
features which might be of interest to a newcomer would be a severe case of
TMI.

The infrequency of use of a facility fails to justify the incorrect
description.  Rather, it aggravates the astonishment factor when
the programmer encounters the behavior, perhaps inadvertently.
Suppose:

X. = 'something'
do I = 1 to 10; X.I = 'defined'; end
drop X.7
say  X.7

The description in the manual is correct; describing it with
the less specific term default might lead the programmer to
expect the program to say something rather than X.7, or
at least to be uncertain.

BTW, Unless I've misunderstood your point, I'm not sure that your sample
program demonstrates the language feature we're discussing.  (x. = 'universal'
perhaps?)

I stand corrected.  Lazy code copying and inadequate testing.  (When
corrected, the output is the same.)

BTW, the APAR I've mentioned is OA17169, closed SUG in 2006, then
The fix for this SUG APAR was shipped in the base for z/OS V1R9.
(IBM has lately updated FIN and SUG APARs when/if the fix is shipped.
Thanks, IBM.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-19 Thread Patrick O'Keefe
On Thu, 19 Mar 2009 09:21:12 -0500, Paul Gilmartin 
paulgboul...@aim.com wrote:

...
The infrequency of use of a facility fails to justify the incorrect
description.  Rather, it aggravates the astonishment factor when
the programmer encounters the behavior, perhaps inadvertently.
Suppose:

X. = 'something'
do I = 1 to 10; X.I = 'defined'; end
drop X.7
say  X.7

The description in the manual is correct; describing it with
the less specific term default might lead the programmer to
expect the program to say something rather than X.7, or
at least to be uncertain.
...

I agree, but I think the astonishment is aimed at the drop rather
than the stem assignment.  (At least MY astonishment is.)   That
behavior implies that the interpreter has to maintain both a list
of specifically assigned variables and a list of specifically dropped
variables (at least for stems that have been assigned).  I have no
idea how the interpreters actually support the behavior of stem 
initialization, but I'm quite sure they don't predefine and assign
every possible variable for the given stem.   They must, in fact,
treat the assigned value as a default to be used for each 
unassigned and undropped variable associated with the stem.

Including dropped variables in that behavior just adds work for the
interpreter.   

Collishaw books include a sample of this behavior so there is no
doubt he intended the language to work this way, but I am still
astonished.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-19 Thread P S
On Thu, Mar 19, 2009 at 3:26 PM, Patrick O'Keefe
patrick.oke...@wamu.net wrote:
 I agree, but I think the astonishment is aimed at the drop rather
 than the stem assignment.  (At least MY astonishment is.)   That
 behavior implies that the interpreter has to maintain both a list
 of specifically assigned variables and a list of specifically dropped
 variables (at least for stems that have been assigned).  I have no
 idea how the interpreters actually support the behavior of stem
 initialization, but I'm quite sure they don't predefine and assign
 every possible variable for the given stem.   They must, in fact,
 treat the assigned value as a default to be used for each
 unassigned and undropped variable associated with the stem.

 Including dropped variables in that behavior just adds work for the
 interpreter.

The key is to understand how the variables are maintained: in a
b-tree. So x.='foo' sets a node for x.. Once you explicitly set
x.banana, a new leaf is created for that. And when you drop a
variable, the leaf is maintained/created too.

Admittedly, the implementation isn't obvious, but it does allow for
arbitrary tails.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-19 Thread Paul Gilmartin
On Thu, 19 Mar 2009 14:26:53 -0500, Patrick O'Keefe wrote:

The description in the manual is correct; describing it with
the less specific term default might lead the programmer to
expect the program to say something rather than X.7, or
at least to be uncertain.
...

I agree, but I think the astonishment is aimed at the drop rather
than the stem assignment.  (At least MY astonishment is.)   That
behavior implies that the interpreter has to maintain both a list
of specifically assigned variables and a list of specifically dropped
variables (at least for stems that have been assigned).  I have no
idea how the interpreters actually support the behavior of stem
initialization, but I'm quite sure they don't predefine and assign
every possible variable for the given stem.   They must, in fact,
treat the assigned value as a default to be used for each
unassigned and undropped variable associated with the stem.

Including dropped variables in that behavior just adds work for the
interpreter.

Collishaw books include a sample of this behavior so there is no
doubt he intended the language to work this way, but I am still
astonished.

You have a pretty good description of how the misunderstanding
arises: journeyperson programmers attempt to infer an mechanism
of implementation, then erroneously assume the developers take
shortcuts because it's too complicated to do it right.

I confess I often do the same.  But then I test.  Sometimes
I'm plesantly surprised to find the implementation meets
the specification.  Other times, I find that the implementor
took the shortcut, and I submit a PMR.  This thoroughly
annoys the support people who argue that I should expect
that it would be implemented in the simple and obvious way,
not as specified.

I may not be able to do that much longer.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Ian S. Worthington
Terry --

Subtle language gotchas, as previously discussed, not withstanding, the
practical upshot is that yes, rexx *does* support multidimensional arrays, and
sparse ones with default values to boot.

It implements them as a conceptual subset of stems, and they are indexed with
strings rather than by integers which actually makes them rather more powerful
once one breaks out of the array mindset.

I've been using them for years without any problems.

i

-- Original Message --
Received: Tue, 17 Mar 2009 05:10:37 PM COT
From: Terry Sambrooks terry.sambro...@btclick.com
To: IBM-MAIN@bama.ua.edu
Subject: Multi-dimensional arrays in REXX

 Hi,
 
 I have done a search of the archives, and read the relevant REXX manuals
and
 am left with a need for a second opinion on my conclusion.
 
 The question I have been asked relates to whether REXX supports
 multi-dimensional arrays. There is a lot of discussion in the manuals about
 single dimension arrays a.k.a. STEM variables, but additional dimensions
are
 not covered which leads me to conclude that multi-dimensional arrays are
not
 supported.
 
 I know this question is better directed at the REXX New Group, but I feel
 sure that there is enough expertise available here to confirm my assessment
 or correct any erroneous view I may have formed.
 
 Kind regards - Terry
 
 
 Terry Sambrooks
 Director
 KMS-IT Limited
 228 Abbeydale Road South
 Dore, Sheffield, S17 3LA, UK
 
 Tel: +44 (0)114 262 0933
 WEB: www.legac-e.co.uk
 
 Company Reg: 3767263 at the above address
 
 All outgoing E-mail is scanned, but it remains the recipient's
 responsibility to ensure their system is protected from spy-ware, trojans,
 viruses, and worms.  
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Larry Dinwiddie
Larry
Terry

As stated before REXX STEM's are not arrays.  Each element is treated as
a string, not a number.

So:   names.john.sam.bill.1.sally='abc'   is legal and accepted.

Just like A.1.2.3.4.5=99 is accepted.  

REXX variables are restricted to storage and if assigned to a number
will also be restricted by the DIGITS command.

Many people I have talked with do not understand that a STEM in REXX
could be non-numeric.  They always associated STEM's with arrays, but
they are not.  The convention is that stem.0 or stem.x.0 contains the
number of elements in the STEM, but this is not enforced by REXX.  It is
just a standard.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Gerhard Postpischil

Ian S. Worthington wrote:

It implements them as a conceptual subset of stems, and they are indexed with
strings rather than by integers which actually makes them rather more powerful
once one breaks out of the array mindset.


All generalities are false  (?)

I'm not sure what you mean by the array mindset? Do you 
seriously advocate solving a determinant by defining it as 
DET.ONE.ONE, DET.ONE.TWO, etc. rather than DET.1.1, etc.? I 
don't consider this a mindset, but rather a prudent approach 
(and I realize that the computation in ForTran or PL/I would be 
faster, but could also be less accurate).


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Ian S. Worthington
I refer to the tendency of programmers new to rexx stems, but familiar with
hll arrays, to reduce their (non-numerical) problem to one of integral indices
into arrays rather than make full use of the rexx stem facility.

i

-- Original Message --
Received: Wed, 18 Mar 2009 09:29:58 AM COT
From: Gerhard Postpischil gerh...@valley.net
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multi-dimensional arrays in REXX

 Ian S. Worthington wrote:
  It implements them as a conceptual subset of stems, and they are indexed
with
  strings rather than by integers which actually makes them rather more
powerful
  once one breaks out of the array mindset.
 
 All generalities are false  (?)
 
 I'm not sure what you mean by the array mindset? Do you 
 seriously advocate solving a determinant by defining it as 
 DET.ONE.ONE, DET.ONE.TWO, etc. rather than DET.1.1, etc.? I 
 don't consider this a mindset, but rather a prudent approach 
 (and I realize that the computation in ForTran or PL/I would be 
 faster, but could also be less accurate).
 
 Gerhard Postpischil
 Bradford, VT
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Gerhard Postpischil

Ian S. Worthington wrote:

I refer to the tendency of programmers new to rexx stems, but familiar with
hll arrays, to reduce their (non-numerical) problem to one of integral indices
into arrays rather than make full use of the rexx stem facility.


I agree completely, but that was not the meaning I got from your 
original statement.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Ian S. Worthington
Regrettably you can only set a default for the stem as a whole, not for a
subset of the variable space.

Its one of my pet peeves.

i

-- Original Message --
Received: Wed, 18 Mar 2009 03:08:19 PM COT
From: Patrick O'Keefe patrick.oke...@wamu.net
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multi-dimensional arrays in REXX

 On Wed, 18 Mar 2009 09:48:10 -0500, Ian S. Worthington  
 ianworthing...@usa.net wrote:
 
  It implements them as a conceptual subset of stems, and
  they are indexed with  strings rather than by integers which 
 actually makes them rather more powerful  once one breaks 
 out of the array mindset.
 
  I'm not sure what you mean by the array mindset?
 
 I refer to the tendency of programmers new to rexx stems, but 
 familiar with hll arrays, to reduce their (non-numerical) problem 
 to one of integral indices into arrays rather than make full use 
 of the rexx stem facility.
 ...
 
 I'm not new to REXX stems nor recently familiar with HLL arrays, 
 but *still* make REXX blunders based on array-think. 
 It's seductive.
 
 An individual compound variable can be assigned a value, and the
 stem can be assigned a value.   That's all there is with REXX stems.
 You cannot assign a value to a row or a column (or any other 
 more abstract partitioning of the compound variable space) no 
 matter how much you might want to.
 
 I conceptually had a very non-array-like structure 
 BASE.i   
 BASE.key.n   
 Where i and n were integers and key was alphanumeric.
 I wanted all BASE.key.n to be set to the value of key for a fixed set
 of keys.  But what I wanted doesn't count for much.
 
 FOO.BAR. = BAR is invalid.  :-(
 
 I think my attempted logic came more from wishful thinking than 
 from any knowledge of HLL array processing.  Even if more powerful
 that arrays, there are limits to compund varaible processing in REXX.
 
 Pat O'Keefe
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Paul Gilmartin
On Wed, 18 Mar 2009 15:21:31 -0500, Ian S. Worthington wrote:

Regrettably you can only set a default for the stem as a whole, not for a
subset of the variable space.

It is *not* a default, and Rexx documentation avoids
the possibly misleading use of default by a correct
description that:

X. = 'blank'

assigns [in effect] the value 'blank' to every possible
member of the compound variable with stem X.

Not only freshman and sophomore Rexx programmers fail to
understand this, but even IBM developers have caused a
violation of the specification by introducing a
misconceived optimization.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Patrick O'Keefe
On Wed, 18 Mar 2009 09:48:10 -0500, Ian S. Worthington 
ianworthing...@usa.net wrote:

 It implements them as a conceptual subset of stems, and
 they are indexed with  strings rather than by integers which 
actually makes them rather more powerful  once one breaks 
out of the array mindset.

 I'm not sure what you mean by the array mindset?

I refer to the tendency of programmers new to rexx stems, but 
familiar with hll arrays, to reduce their (non-numerical) problem 
to one of integral indices into arrays rather than make full use 
of the rexx stem facility.
...

I'm not new to REXX stems nor recently familiar with HLL arrays, 
but *still* make REXX blunders based on array-think. 
It's seductive.

An individual compound variable can be assigned a value, and the
stem can be assigned a value.   That's all there is with REXX stems.
You cannot assign a value to a row or a column (or any other 
more abstract partitioning of the compound variable space) no 
matter how much you might want to.

I conceptually had a very non-array-like structure 
BASE.i   
BASE.key.n   
Where i and n were integers and key was alphanumeric.
I wanted all BASE.key.n to be set to the value of key for a fixed set
of keys.  But what I wanted doesn't count for much.

FOO.BAR. = BAR is invalid.  :-(

I think my attempted logic came more from wishful thinking than 
from any knowledge of HLL array processing.  Even if more powerful
that arrays, there are limits to compund varaible processing in REXX.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Terry Sambrooks
Hi,

I though a quick thank you was in order to all those who responded to my
earlier query.

Having reviewed the various responses and combined that information with
some gleaned from query on STEMs posted earlier in the week by somebody
else. I have been able to correct my misunderstanding and produce a
demonstration routine.

Thanks again - Terry

Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK

Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk

Company Reg: 3767263 at the above address

All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware, trojans,
viruses, and worms.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Ian S. Worthington
I'm aware of the distinction, but have always felt that that's a fairly
reasonable working definition of default, at least up until a reassignment.

i

-- Original Message --
Received: Wed, 18 Mar 2009 03:39:27 PM COT
From: Paul Gilmartin paulgboul...@aim.com
To: IBM-MAIN@bama.ua.edu
Subject: Re: Multi-dimensional arrays in REXX

 On Wed, 18 Mar 2009 15:21:31 -0500, Ian S. Worthington wrote:
 
 Regrettably you can only set a default for the stem as a whole, not for a
 subset of the variable space.
 
 It is *not* a default, and Rexx documentation avoids
 the possibly misleading use of default by a correct
 description that:
 
 X. = 'blank'
 
 assigns [in effect] the value 'blank' to every possible
 member of the compound variable with stem X.
 
 Not only freshman and sophomore Rexx programmers fail to
 understand this, but even IBM developers have caused a
 violation of the specification by introducing a
 misconceived optimization.
 
 -- gil
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Patrick O'Keefe
On Wed, 18 Mar 2009 15:36:24 -0500, Paul Gilmartin 
paulgboul...@aim.com wrote:

On Wed, 18 Mar 2009 15:21:31 -0500, Ian S. Worthington wrote:

Regrettably you can only set a default for the stem as a whole, not 
for a
subset of the variable space.

It is *not* a default, and Rexx documentation avoids
the possibly misleading use of default by a correct
description that:

X. = 'blank'

assigns [in effect] the value 'blank' to every possible
member of the compound variable with stem X.
...

Whether or not this behavior fits the definition of default, it 
does highlight the meaning of stem.   In the compund variable 
A.B.C.D the stem is A., not A.B. or A.B.C., and only the stem
or a whole compound variable can be assigned a value.

Last I knew (and admitedly, that was 25 years ago) PL/I was even
less flexable than that.  You cfould assign a value to a whole 
dimension of an array, but that generated code to set every element
in that dimension to that value.  You can obviously do the same thing
(explicitly) in REXX but that is a lot different (and a whole lot
less efficient) than setting an initial value for otherwise unset
elements of a compound variable.

It would be tough for REXX to handle initilized stems differently,
actually.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-18 Thread Gerhard Postpischil

Ian S. Worthington wrote:

I'm aware of the distinction, but have always felt that that's a fairly
reasonable working definition of default, at least up until a reassignment.


I suspect that he considers the language assignment of the 
upper-cased variable name to be the default, hence the distinction?


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Multi-dimensional arrays in REXX

2009-03-17 Thread Terry Sambrooks
Hi,

I have done a search of the archives, and read the relevant REXX manuals and
am left with a need for a second opinion on my conclusion.

The question I have been asked relates to whether REXX supports
multi-dimensional arrays. There is a lot of discussion in the manuals about
single dimension arrays a.k.a. STEM variables, but additional dimensions are
not covered which leads me to conclude that multi-dimensional arrays are not
supported.

I know this question is better directed at the REXX New Group, but I feel
sure that there is enough expertise available here to confirm my assessment
or correct any erroneous view I may have formed.

Kind regards - Terry


Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK

Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk

Company Reg: 3767263 at the above address

All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware, trojans,
viruses, and worms.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-17 Thread Binyamin Dissen
On Tue, 17 Mar 2009 22:09:15 - Terry Sambrooks
terry.sambro...@btclick.com wrote:

:I have done a search of the archives, and read the relevant REXX manuals and
:am left with a need for a second opinion on my conclusion.

:The question I have been asked relates to whether REXX supports
:multi-dimensional arrays. There is a lot of discussion in the manuals about
:single dimension arrays a.k.a. STEM variables, but additional dimensions are
:not covered which leads me to conclude that multi-dimensional arrays are not
:supported.

Why can't stems be multi-dimensional?

STEM.x.y.z

:I know this question is better directed at the REXX New Group, but I feel
:sure that there is enough expertise available here to confirm my assessment
:or correct any erroneous view I may have formed.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-17 Thread Paul Gilmartin
On Wed, 18 Mar 2009 00:11:35 +0200, Binyamin Dissen wrote:

On Tue, 17 Mar 2009 22:09:15 - Terry Sambrooks wrote:

:The question I have been asked relates to whether REXX supports
:multi-dimensional arrays. There is a lot of discussion in the manuals about
:single dimension arrays a.k.a. STEM variables, but additional dimensions are
:not covered which leads me to conclude that multi-dimensional arrays are not
:supported.

True, they are not.

Why can't stems be multi-dimensional?

STEM.x.y.z

Which is equivalent to:

I = x'.'y'.'z
STEM.I

But this suffers an ambiguity.  Consider:

I = 'A.B'
J = 'C'

X = 'A'
Y = 'B.C'

Then STEM.I.J and STEM.X.Y refer to the same variable,
even though IX and JY.  When this occurs, admittedly
seldom but not never, the astonishment factor is likely
to be enormous.

FORTRAN introduces a similar ambiguity with its flattening
of subscripts.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-17 Thread Binyamin Dissen
On Tue, 17 Mar 2009 17:22:29 -0500 Paul Gilmartin paulgboul...@aim.com
wrote:

:On Wed, 18 Mar 2009 00:11:35 +0200, Binyamin Dissen wrote:

:On Tue, 17 Mar 2009 22:09:15 - Terry Sambrooks wrote:

::The question I have been asked relates to whether REXX supports
::multi-dimensional arrays. There is a lot of discussion in the manuals about
::single dimension arrays a.k.a. STEM variables, but additional dimensions 
are
::not covered which leads me to conclude that multi-dimensional arrays are 
not
::supported.

:True, they are not.

:Why can't stems be multi-dimensional?

:STEM.x.y.z

:Which is equivalent to:

:I = x'.'y'.'z
:STEM.I

:But this suffers an ambiguity.  Consider:

:I = 'A.B'
:J = 'C'

:X = 'A'
:Y = 'B.C'

:Then STEM.I.J and STEM.X.Y refer to the same variable,
:even though IX and JY.  When this occurs, admittedly
:seldom but not never, the astonishment factor is likely
:to be enormous.

Also when 
   a = 4
   b = 04

Even though a=b, stem.Astem.B

Plenty of ammunition if one plans to shoot at the toes.

:FORTRAN introduces a similar ambiguity with its flattening
:of subscripts.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Multi-dimensional arrays in REXX

2009-03-17 Thread Raymond Noal
Terry,

OK - I'm no REXX expert, so take this for what it's worth:

In the technical/classical sense of arrays, REXX does not have any support of 
arrays per se - either single or multi-dimensional. When I was using Fortran 
you had:

Dimension array(10,10)
Do I = 1 to 10
Do X = 1 to 10
Array(I,X) = some value
End
End

Instead, Rexx has STEM variables that can be made to work as arrays:

Do I = 1 to 10;
Stemvar.I = some value;
End;

This makes STEM variables 'look' like arrays. However, REXX and STEM variables 
are perfectly happy with saying

Stemvar.5 = some value

The above only creates the STEM variable 'stemvar.5' and assigns it some value. 
Note there is no STEM variable of 'stemvar.1/2/3/4/6/7/8/9/10'. Only 
'stemvar.5' exists.

Also, please save yourself some embarrassment when talking to anyone who is a 
REXX bigot/user and NEVER - NEVER say that stem variables are arrays. Doing so 
causes you life-long shame.

HTH

HITACHI
 DATA SYSTEMS 
Raymond E. Noal 
Senior Technical Engineer 
Office: (408) 970 - 7978 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Terry Sambrooks
Sent: Tuesday, March 17, 2009 3:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Multi-dimensional arrays in REXX

Hi,

I have done a search of the archives, and read the relevant REXX manuals and
am left with a need for a second opinion on my conclusion.

The question I have been asked relates to whether REXX supports
multi-dimensional arrays. There is a lot of discussion in the manuals about
single dimension arrays a.k.a. STEM variables, but additional dimensions are
not covered which leads me to conclude that multi-dimensional arrays are not
supported.

I know this question is better directed at the REXX New Group, but I feel
sure that there is enough expertise available here to confirm my assessment
or correct any erroneous view I may have formed.

Kind regards - Terry


Terry Sambrooks
Director
KMS-IT Limited
228 Abbeydale Road South
Dore, Sheffield, S17 3LA, UK

Tel: +44 (0)114 262 0933
WEB: www.legac-e.co.uk

Company Reg: 3767263 at the above address

All outgoing E-mail is scanned, but it remains the recipient's
responsibility to ensure their system is protected from spy-ware, trojans,
viruses, and worms.  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html