Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sorting multiple correllated stem vars
66 views
Skip to first unread message
Bill Ashton
Mar 9, 2012, 3:23:50 PM3/9/12
to
Hi again, friends!
I have gotten a list of datasets and information from CSI, and the details
are in a number of stem vars - like dsn. vol. alloc. used.
I have a routine to quicksort a single stemset, and it works great.
However, I lose the correllation with all the other stemsets when I sort.
Do any of you have a "magic" process to use multiple related stemsets, when
you sort one of them? In this case, I could sort on DSN or I might sort on
create date or on used space. I would then need to refer to the correct
item in the other stemsets after I have sorted.
What do you think?
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
I have gotten a list of datasets and information from CSI, and the details
are in a number of stem vars - like dsn. vol. alloc. used.
I have a routine to quicksort a single stemset, and it works great.
However, I lose the correllation with all the other stemsets when I sort.
Do any of you have a "magic" process to use multiple related stemsets, when
you sort one of them? In this case, I could sort on DSN or I might sort on
create date or on used space. I would then need to refer to the correct
item in the other stemsets after I have sorted.
What do you think?
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
Don Imbriale
Mar 9, 2012, 3:49:05 PM3/9/12
to
You need another stem to track the sort order. Then use this as an index
into the actual stems.
- Don Imbriale
into the actual stems.
- Don Imbriale
Farley, Peter x23353
Mar 9, 2012, 3:53:55 PM3/9/12
to
Brute force method would be to concatenate all the values into a new stem (key value to be sorted first) with either space separation or some special character to separate fields, sort the new stem, then use PARSE to separate out all the sorted values.
HTH
Peter
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf
> Of Bill Ashton
> Sent: Friday, March 09, 2012 3:23 PM
> To: TSO-...@vm.marist.edu
> Subject: Sorting multiple correllated stem vars
>
> Hi again, friends!
>
> I have gotten a list of datasets and information from CSI, and the details
> are in a number of stem vars - like dsn. vol. alloc. used.
>
> I have a routine to quicksort a single stemset, and it works great.
> However, I lose the correllation with all the other stemsets when I sort.
> Do any of you have a "magic" process to use multiple related stemsets,
> when
> you sort one of them? In this case, I could sort on DSN or I might sort on
> create date or on used space. I would then need to refer to the correct
> item in the other stemsets after I have sorted.
>
> What do you think?
> Thank you and best regards,
> *Billy Ashton*
--
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
HTH
Peter
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf
> Of Bill Ashton
> Sent: Friday, March 09, 2012 3:23 PM
> To: TSO-...@vm.marist.edu
> Subject: Sorting multiple correllated stem vars
>
> Hi again, friends!
>
> I have gotten a list of datasets and information from CSI, and the details
> are in a number of stem vars - like dsn. vol. alloc. used.
>
> I have a routine to quicksort a single stemset, and it works great.
> However, I lose the correllation with all the other stemsets when I sort.
> Do any of you have a "magic" process to use multiple related stemsets,
> when
> you sort one of them? In this case, I could sort on DSN or I might sort on
> create date or on used space. I would then need to refer to the correct
> item in the other stemsets after I have sorted.
>
> What do you think?
> Thank you and best regards,
> *Billy Ashton*
--
Horacio Villa
Mar 9, 2012, 4:02:29 PM3/9/12
to
I would add the stem number at the end of the stem you're sorting,
separating it with some character. I'm presume this won't change the sort
order.
Then, use that value as an index into the other stems.
Cheers,
separating it with some character. I'm presume this won't change the sort
order.
Then, use that value as an index into the other stems.
Cheers,
Dave Salt
Mar 9, 2012, 4:38:00 PM3/9/12
to
I'd probably load the records into an ISPF table as this could be quickly and easily sorted by any column.
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/program-development/simplist.html
> Date: Fri, 9 Mar 2012 15:23:03 -0500
> From: bill00...@GMAIL.COM
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/program-development/simplist.html
> Date: Fri, 9 Mar 2012 15:23:03 -0500
> From: bill00...@GMAIL.COM
> Subject: Sorting multiple correllated stem vars
> To: TSO-...@VM.MARIST.EDU
Rob Zenuk
Mar 9, 2012, 5:18:09 PM3/9/12
to
That's how I usually do it...
Danger! Danger! Danger! Untested code...
Do i=1 to stem.0
Sortvar.i = var1.i'~'var2.i'~'var3.i'~'var.4
End
Call stemsort 'sortvar.' sortparms
Do o=1 to sortvar.0
Parse var sortvar.o var1.o '~' var2.o '~' var3.o '~' var4.o
End
Depending on your data you might need to left or right justify during your
concatenation...
Rob
Danger! Danger! Danger! Untested code...
Do i=1 to stem.0
Sortvar.i = var1.i'~'var2.i'~'var3.i'~'var.4
End
Call stemsort 'sortvar.' sortparms
Do o=1 to sortvar.0
Parse var sortvar.o var1.o '~' var2.o '~' var3.o '~' var4.o
End
Depending on your data you might need to left or right justify during your
concatenation...
Rob
Bob Bridges
Mar 9, 2012, 6:24:20 PM3/9/12
to
Interesting, all the different ways people want to skin this cat. You
didn't say so but I presume your stems are numbered, ie dsn.1, dsn.2, dsn.3
etc, and the same for the other stems. If so, there's a place in your sort
logic that reärranges the numbers, eg
x=alloc.hi; alloc.hi=alloc.lo; alloc.lo=x
It isn't clear to me why you wouldn't just modify your code in this case to
swap ALL the stems:
x= dsn.hi; dsn.hi =dsn.lo; dsn.lo=x
x= vol.hi; vol.hi =vol.lo; vol.lo=x
x=alloc.hi; alloc.hi=alloc.lo; alloc.lo=x
Personally I think I'd go with Don Imbriale's suggestion. But all of these
would work pretty well, I think.
By the way, I'd be interested to see the technique you use to sort your
stem. I have an external routine to sort the stack, but it just calls
SYNCSORT or DFSORT, and while that's great for some purposes I wouldn't mind
adding to my repertoire.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* I don't think I'd have been in such a hurry to reach adulthood if I'd
known the whole thing was going to be ad-libbed. -Calvin's dad, Calvin &
Hobbes 1989-05-11 */
-----Original Message-----
From: Horacio Villa
Sent: Friday, March 9, 2012 15:54
I would add the stem number at the end of the stem you're sorting,
separating it with some character. I'm presume this won't change the sort
order. Then, use that value as an index into the other stems.
didn't say so but I presume your stems are numbered, ie dsn.1, dsn.2, dsn.3
etc, and the same for the other stems. If so, there's a place in your sort
logic that reärranges the numbers, eg
x=alloc.hi; alloc.hi=alloc.lo; alloc.lo=x
It isn't clear to me why you wouldn't just modify your code in this case to
swap ALL the stems:
x= dsn.hi; dsn.hi =dsn.lo; dsn.lo=x
x= vol.hi; vol.hi =vol.lo; vol.lo=x
x=alloc.hi; alloc.hi=alloc.lo; alloc.lo=x
Personally I think I'd go with Don Imbriale's suggestion. But all of these
would work pretty well, I think.
By the way, I'd be interested to see the technique you use to sort your
stem. I have an external routine to sort the stack, but it just calls
SYNCSORT or DFSORT, and while that's great for some purposes I wouldn't mind
adding to my repertoire.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* I don't think I'd have been in such a hurry to reach adulthood if I'd
known the whole thing was going to be ad-libbed. -Calvin's dad, Calvin &
Hobbes 1989-05-11 */
-----Original Message-----
From: Horacio Villa
Sent: Friday, March 9, 2012 15:54
I would add the stem number at the end of the stem you're sorting,
separating it with some character. I'm presume this won't change the sort
order. Then, use that value as an index into the other stems.
-----Original Message-----
From: Bill Ashton
Sent: Friday, March 9, 2012 15:23
I have gotten a list of datasets and information from CSI, and the details
are in a number of stem vars - like dsn. vol. alloc. used.
I have a routine to quicksort a single stemset, and it works great.
However, I lose the correllation with all the other stemsets when I sort.
Do any of you have a "magic" process to use multiple related stemsets, when
you sort one of them? In this case, I could sort on DSN or I might sort on
create date or on used space. I would then need to refer to the correct item
in the other stemsets after I have sorted.
From: Bill Ashton
Sent: Friday, March 9, 2012 15:23
I have gotten a list of datasets and information from CSI, and the details
are in a number of stem vars - like dsn. vol. alloc. used.
I have a routine to quicksort a single stemset, and it works great.
However, I lose the correllation with all the other stemsets when I sort.
Do any of you have a "magic" process to use multiple related stemsets, when
you sort one of them? In this case, I could sort on DSN or I might sort on
create date or on used space. I would then need to refer to the correct item
in the other stemsets after I have sorted.
Steve Coalbran
Mar 12, 2012, 7:14:54 AM3/12/12
to
Or do all the swaps at once?
PARSE VALUE dsn.hi";"dsn.lo";",
vol.hi";"vol.lo";",
alloc.hi";"alloc.lo";",
WITH dsn.lo";"dsn.hi";",
vol.lo";"vol.hi";",
alloc.lo";"alloc.hi
Steve Coalbran
Accredited Senior IT Specialist, Global Business Services, Application Services
IBM Svenska AB, SE 164 92 Stockholm, Sweden
> Date: Fri, 9 Mar 2012 18:22:59 -0500
> From: rhb...@ATTGLOBAL.NET
> Subject: Re: [TSO-REXX] Sorting multiple correllated stem vars
> To: TSO-...@VM.MARIST.EDU
PARSE VALUE dsn.hi";"dsn.lo";",
vol.hi";"vol.lo";",
alloc.hi";"alloc.lo";",
WITH dsn.lo";"dsn.hi";",
vol.lo";"vol.hi";",
alloc.lo";"alloc.hi
Steve Coalbran
Accredited Senior IT Specialist, Global Business Services, Application Services
IBM Svenska AB, SE 164 92 Stockholm, Sweden
> Date: Fri, 9 Mar 2012 18:22:59 -0500
> From: rhb...@ATTGLOBAL.NET
> Subject: Re: [TSO-REXX] Sorting multiple correllated stem vars
> To: TSO-...@VM.MARIST.EDU
Bill Ashton
Mar 12, 2012, 8:16:30 AM3/12/12
to
Thanks for the suggestions - I too like Don I's suggestion, but am also
intrigued at the possibility of using an ISPF table. Since I am building a
dynamic area on the screen (consolidating this stemset info with other info
based on client input) I have understood that I can't use a TBDISPL in the
dynamic area. So - I probably should know this - can I use the table to
house and sort my info on different columns, and then manually extract the
rows to build my area?
B
--
intrigued at the possibility of using an ISPF table. Since I am building a
dynamic area on the screen (consolidating this stemset info with other info
based on client input) I have understood that I can't use a TBDISPL in the
dynamic area. So - I probably should know this - can I use the table to
house and sort my info on different columns, and then manually extract the
rows to build my area?
B
Thank you and best regards,
*Billy Ashton*
*Billy Ashton*
Paul Gilmartin
Mar 12, 2012, 8:33:22 AM3/12/12
to
On Mar 12, 2012, at 05:13, Steve Coalbran wrote:
> Or do all the swaps at once?
> PARSE VALUE dsn.hi";"dsn.lo";",
> vol.hi";"vol.lo";",
> alloc.hi";"alloc.lo";",
> WITH dsn.lo";"dsn.hi";",
> vol.lo";"vol.hi";",
> alloc.lo";"alloc.hi
>
>
> Steve Coalbran
> Accredited Senior IT Specialist, Global Business Services, Application Services
>
> IBM Svenska AB, SE 164 92 Stockholm, Sweden
>
I would not consider this technique satisfactory unless it's preceded
> Or do all the swaps at once?
> PARSE VALUE dsn.hi";"dsn.lo";",
> vol.hi";"vol.lo";",
> alloc.hi";"alloc.lo";",
> WITH dsn.lo";"dsn.hi";",
> vol.lo";"vol.hi";",
> alloc.lo";"alloc.hi
>
>
> Steve Coalbran
> Accredited Senior IT Specialist, Global Business Services, Application Services
>
> IBM Svenska AB, SE 164 92 Stockholm, Sweden
>
by a check that the data do not contain a ";". And if they do, what's
the recovery procedure?
-- gil
Baldon, David
Mar 12, 2012, 8:44:59 AM3/12/12
to
Yes you can use the ISPF table to "manipulate" the data and then extract it for building the dynamic area. Depending on the amount of data you're talking about, ISPF tables will only scale so far. Exactly how far is something you will have to determine.
...David
...David
Steve Coalbran
Mar 12, 2012, 8:48:42 AM3/12/12
to
Of course one would in reality do a check.
However, if the program is also writing the stems to it should know what characters these could comprise?
If paranoid one could use hex values as separators?
something like ...
PARSE VALUE dsn.hi '00'X dsn.lo '00'X,
vol.hi '00'X vol.lo '00'X,
alloc.hi '00'X alloc.lo '00'X,
WITH dsn.lo '00'X dsn.hi '00'X,
vol.lo '00'X vol.hi '00'X,
alloc.lo '00'X alloc.hi '00'X
Steve Coalbran
Accredited Senior IT Specialist, Global Business Services, Application Services
IBM Svenska AB, SE 164 92 Stockholm, Sweden
> Date: Mon, 12 Mar 2012 06:29:47 -0600
> From: PaulGB...@AIM.COM
However, if the program is also writing the stems to it should know what characters these could comprise?
If paranoid one could use hex values as separators?
something like ...
PARSE VALUE dsn.hi '00'X dsn.lo '00'X,
vol.hi '00'X vol.lo '00'X,
alloc.hi '00'X alloc.lo '00'X,
WITH dsn.lo '00'X dsn.hi '00'X,
vol.lo '00'X vol.hi '00'X,
alloc.lo '00'X alloc.hi '00'X
Steve Coalbran
Accredited Senior IT Specialist, Global Business Services, Application Services
IBM Svenska AB, SE 164 92 Stockholm, Sweden
> From: PaulGB...@AIM.COM
Bill Ashton
Mar 12, 2012, 8:52:23 AM3/12/12
to
Thanks David; I will probably go that route, as the data can be sorted on
different columns, which with the stemsets would require a lot of
manipulation. I will try to load my data into a single ISPF table, and then
can handle the sorting easily, and then will pull the records I need for my
dynamic area.
Thanks again for your advice and for everyone else's suggestions! TIme to
go head down for a while now to make this work!
Billy
different columns, which with the stemsets would require a lot of
manipulation. I will try to load my data into a single ISPF table, and then
can handle the sorting easily, and then will pull the records I need for my
dynamic area.
Thanks again for your advice and for everyone else's suggestions! TIme to
go head down for a while now to make this work!
Billy
Ken MacKenzie
Mar 12, 2012, 9:12:55 AM3/12/12
to
Or, to make it more readable, in my opinion:
d = '00'x /* Set delimiter */
PARSE VALUE dsn.hi (d) dsn.lo (d),
vol.hi (d) vol.lo (d),
alloc.hi (d) alloc.lo (d),
WITH dsn.lo (d) dsn.hi (d),
vol.lo (d) vol.hi (d),
alloc.lo (d) alloc.hi (d)
Ken MacKenzie
Pramerica Systems Ireland Limited
is a private company limited by shares incorporated and registered
in the Republic of Ireland with registered number 319900 and
registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4,
Ireland.
From:
Steve Coalbran <coal...@HOTMAIL.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
12/03/2012 12:50
Subject:
Re: [TSO-REXX] Sorting multiple correllated stem vars
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
d = '00'x /* Set delimiter */
PARSE VALUE dsn.hi (d) dsn.lo (d),
vol.hi (d) vol.lo (d),
alloc.hi (d) alloc.lo (d),
WITH dsn.lo (d) dsn.hi (d),
vol.lo (d) vol.hi (d),
alloc.lo (d) alloc.hi (d)
Ken MacKenzie
Pramerica Systems Ireland Limited
is a private company limited by shares incorporated and registered
in the Republic of Ireland with registered number 319900 and
registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4,
Ireland.
From:
Steve Coalbran <coal...@HOTMAIL.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
12/03/2012 12:50
Subject:
Re: [TSO-REXX] Sorting multiple correllated stem vars
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Jeremy Nicoll - ls tsrx
Mar 12, 2012, 9:19:55 AM3/12/12
to
Bill Ashton <bill00...@GMAIL.COM> wrote:
> Thanks David; I will probably go that route, as the data can be sorted on
> different columns, which with the stemsets would require a lot of
> manipulation. I will try to load my data into a single ISPF table, and
> then can handle the sorting easily, and then will pull the records I need
> for my dynamic area.
I recall that it used to be necessary to have dummy columns in some of my
> Thanks David; I will probably go that route, as the data can be sorted on
> different columns, which with the stemsets would require a lot of
> manipulation. I will try to load my data into a single ISPF table, and
> then can handle the sorting easily, and then will pull the records I need
> for my dynamic area.
ispf tables so that sorting worked properly. In essence for some types of
data I put the values I'd show to a user in one column [eg date() values],
but put a sortable equivalent in another column [ie date("B")].
--
Jeremy C B Nicoll - my opinions are my own.
Steve Coalbran
Mar 12, 2012, 9:33:19 AM3/12/12
to
Thanks Ken - much neater! I'll use that technique in future ;-)
Steve Coalbran
Accredited Senior IT Specialist, Global Business Services, Application Services
IBM Svenska AB, SE 164 92 Stockholm, Sweden
> Date: Mon, 12 Mar 2012 13:56:53 +0100
> From: Ken.Ma...@PRAMERICA.IE
Steve Coalbran
Accredited Senior IT Specialist, Global Business Services, Application Services
IBM Svenska AB, SE 164 92 Stockholm, Sweden
> From: Ken.Ma...@PRAMERICA.IE
Dave Salt
Mar 12, 2012, 11:22:51 AM3/12/12
to
> From: bill00...@GMAIL.COM
> intrigued at the possibility of using an ISPF table. can I use the table to
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/program-development/simplist.html
> intrigued at the possibility of using an ISPF table. can I use the table to
> house and sort my info on different columns, and then manually extract the
> rows to build my area?
That's exactly how SimpList works. The objects in each object list (e.g. Data Set Names) are extracted from an ISPF table and displayed in a dynamic area where a user can select and update them (etc).
> rows to build my area?
Dave Salt
SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/program-development/simplist.html
Bill Ashton
Mar 12, 2012, 11:37:31 AM3/12/12
to
Thanks, Dave. In looking at this, I presume there is no easier way than a
loop with TBGET, to get each row one at a time, right?
loop with TBGET, to get each row one at a time, right?
--
Thank you and best regards,
*Billy Ashton*
Thank you and best regards,
*Billy Ashton*
Vitonis, Tony
Mar 12, 2012, 11:50:54 AM3/12/12
to
My typical approach to stem sorting:
MyStem.0 = 3
MyStem.1 = "c"
MyStem.2 = "a"
MyStem.3 = "b"
INTERPRET SORTSTEM("MyStem")
/* Use the sorted MyStem */
The SORTSTEM routine:
/* REXX */
Main:
PARSE ARG Stem
RETURN "IF "Stem".0 > 1 THEN ;",
"DO ;",
"$$_Gap = "Stem".0 ;",
"DO UNTIL $$_Done ;",
"$$_Gap = MAX(($$_Gap / 1.3) % 1, 1) ;",
"$$_Swapped = (1=0) ;",
"DO $$_i = 1 TO "Stem".0 - $$_Gap ;",
"$$_j = $$_i + $$_Gap ;",
"IF" Stem".$$_i >" Stem".$$_j THEN;",
"DO ;",
"$$_Hold = "Stem".$$_i ;",
Stem".$$_i = "Stem".$$_j ;",
Stem".$$_j = $$_Hold ;",
"$$_Swapped = (1=1) ;",
"END ;",
"END ;",
"$$_Done = \$$_Swapped & ($$_Gap = 1) ;",
"END ;",
"DROP $$_Gap $$_Done $$_Swapped $$_i $$_j $$_Hold ;",
"END"
-----Original Message-----
From: Bill Ashton
MyStem.0 = 3
MyStem.1 = "c"
MyStem.2 = "a"
MyStem.3 = "b"
INTERPRET SORTSTEM("MyStem")
/* Use the sorted MyStem */
The SORTSTEM routine:
/* REXX */
Main:
PARSE ARG Stem
RETURN "IF "Stem".0 > 1 THEN ;",
"DO ;",
"$$_Gap = "Stem".0 ;",
"DO UNTIL $$_Done ;",
"$$_Gap = MAX(($$_Gap / 1.3) % 1, 1) ;",
"$$_Swapped = (1=0) ;",
"DO $$_i = 1 TO "Stem".0 - $$_Gap ;",
"$$_j = $$_i + $$_Gap ;",
"IF" Stem".$$_i >" Stem".$$_j THEN;",
"DO ;",
"$$_Hold = "Stem".$$_i ;",
Stem".$$_i = "Stem".$$_j ;",
Stem".$$_j = $$_Hold ;",
"$$_Swapped = (1=1) ;",
"END ;",
"END ;",
"$$_Done = \$$_Swapped & ($$_Gap = 1) ;",
"END ;",
"DROP $$_Gap $$_Done $$_Swapped $$_i $$_j $$_Hold ;",
"END"
-----Original Message-----
From: Bill Ashton
Subject: Re: Sorting multiple correllated stem vars
Thanks, Dave. In looking at this, I presume there is no easier way than a
loop with TBGET, to get each row one at a time, right?
On Mon, Mar 12, 2012 at 11:07 AM, Dave Salt <ds...@hotmail.com> wrote:
> > From: bill00...@GMAIL.COM
> > intrigued at the possibility of using an ISPF table. can I use the table
> to
> > house and sort my info on different columns, and then manually extract
> the
> > rows to build my area?
>
> That's exactly how SimpList works. The objects in each object list (e.g.
> Data Set Names) are extracted from an ISPF table and displayed in a dynamic
> area where a user can select and update them (etc).
Thanks, Dave. In looking at this, I presume there is no easier way than a
loop with TBGET, to get each row one at a time, right?
On Mon, Mar 12, 2012 at 11:07 AM, Dave Salt <ds...@hotmail.com> wrote:
> > From: bill00...@GMAIL.COM
> > intrigued at the possibility of using an ISPF table. can I use the table
> to
> > house and sort my info on different columns, and then manually extract
> the
> > rows to build my area?
>
> That's exactly how SimpList works. The objects in each object list (e.g.
> Data Set Names) are extracted from an ISPF table and displayed in a dynamic
> area where a user can select and update them (etc).
Dave Salt
Mar 12, 2012, 12:50:06 PM3/12/12
to
> From: bill00...@GMAIL.COM
> Thanks, Dave. In looking at this, I presume there is no easier way than a
> loop with TBGET, to get each row one at a time, right?
That depends on what you want to do with the data. If (for example) everything was stored in the table as one huge record (presumably with multiple 'columns', e.g. one for each stem), then a single TBBOTTOM would retrieve everything from the table all in one go. You could then parse the data however you want. But if you need to be able to sort the data then it might be better to have individual records in the table so you can take advantage of TBSORT. If that's the case, then yes you'd need to use TBGET to read the record(s) you want.
> loop with TBGET, to get each row one at a time, right?
Steve Coalbran
Mar 13, 2012, 7:44:02 AM3/13/12
to
Thanks Ken - nice one.
Was "instr" a typo for "fstr"?
d = LEFT(STRIP(TRANSLATE(XRANGE(), ftab, fstr)), 1)
/Steve
Was "instr" a typo for "fstr"?
d = LEFT(STRIP(TRANSLATE(XRANGE(), ftab, fstr)), 1)
/Steve
Robert Zenuk
Mar 13, 2012, 8:26:51 AM3/13/12
to
I periodically have to do that as well. One example that comes to mind is
a hidden zero filled IP address column to get a good sorts by IP address.
Rob
In a message dated 3/12/2012 6:30:18 A.M. US Mountain Standard Time,
a hidden zero filled IP address column to get a good sorts by IP address.
Rob
In a message dated 3/12/2012 6:30:18 A.M. US Mountain Standard Time,
jn.ls....@WINGSANDBEAKS.ORG.UK writes:
Bill Ashton <bill00...@GMAIL.COM> wrote:
> Thanks David; I will probably go that route, as the data can be sorted on
> different columns, which with the stemsets would require a lot of
> manipulation. I will try to load my data into a single ISPF table, and
> then can handle the sorting easily, and then will pull the records I need
> for my dynamic area.
I recall that it used to be necessary to have dummy columns in some of my
ispf tables so that sorting worked properly. In essence for some types of
data I put the values I'd show to a user in one column [eg date() values],
but put a sortable equivalent in another column [ie date("B")].
--
Jeremy C B Nicoll - my opinions are my own.
Bill Ashton <bill00...@GMAIL.COM> wrote:
> Thanks David; I will probably go that route, as the data can be sorted on
> different columns, which with the stemsets would require a lot of
> manipulation. I will try to load my data into a single ISPF table, and
> then can handle the sorting easily, and then will pull the records I need
> for my dynamic area.
I recall that it used to be necessary to have dummy columns in some of my
ispf tables so that sorting worked properly. In essence for some types of
data I put the values I'd show to a user in one column [eg date() values],
but put a sortable equivalent in another column [ie date("B")].
--
Jeremy C B Nicoll - my opinions are my own.
Ken MacKenzie
Apr 3, 2012, 10:07:19 AM4/3/12
to
Hi All,
Inspired by a discussion either on ISPF-L or TSO-REXX, I have written a
little routine called RXVARS, which will return (in the stack) the names
of all (or selected) variables known to the current REXX environment. This
can be useful for returning all STEM variables for a particular stem. If
anyone wants a copy, give me a shout and I'll send it in XMIT form.
Examples:
X = RXVARS()
Or
Call RXVARS
Will return all variable names in the stack
X = RXVARS('KEN.')
Or
Call RXVARS 'KEN.'
Will return all variables beginning with KEN.
X = RXVARS('MAC')
Or
Call RXVARS 'MAC'
Will return all variables beginning with MAC, with or without a dot.
Inspired by a discussion either on ISPF-L or TSO-REXX, I have written a
little routine called RXVARS, which will return (in the stack) the names
of all (or selected) variables known to the current REXX environment. This
can be useful for returning all STEM variables for a particular stem. If
anyone wants a copy, give me a shout and I'll send it in XMIT form.
Examples:
X = RXVARS()
Or
Call RXVARS
Will return all variable names in the stack
X = RXVARS('KEN.')
Or
Call RXVARS 'KEN.'
Will return all variables beginning with KEN.
X = RXVARS('MAC')
Or
Call RXVARS 'MAC'
Will return all variables beginning with MAC, with or without a dot.
Bob Bridges
Apr 3, 2012, 11:15:59 AM4/3/12
to
I'm interested, Ken, but what's it written in? Not interpreted REXX, I take
it, so is it in the form of a load module, or what?
/* No single raindrop considers itself responsible for the flood. */
it, so is it in the form of a load module, or what?
/* No single raindrop considers itself responsible for the flood. */
Ken MacKenzie
Apr 3, 2012, 12:14:04 PM4/3/12
to
Due to overwhelming response I've made it available on the internet:
https://rapidshare.com/files/2156022311/rxvars.xmi
https://rapidshare.com/files/477065443/readme.txt
From:
Ken MacKenzie <Ken.Ma...@PRAMERICA.IE>
To:
ISP...@LISTSERV.ND.EDU
Date:
03/04/2012 15:09
Subject:
List all (or selected) REXX variables
Sent by:
ISPF discussion list <ISP...@LISTSERV.ND.EDU>
https://rapidshare.com/files/2156022311/rxvars.xmi
https://rapidshare.com/files/477065443/readme.txt
From:
Ken MacKenzie <Ken.Ma...@PRAMERICA.IE>
To:
ISP...@LISTSERV.ND.EDU
Date:
03/04/2012 15:09
Subject:
List all (or selected) REXX variables
Sent by:
ISPF discussion list <ISP...@LISTSERV.ND.EDU>
Walter Pachl
Apr 3, 2012, 12:25:02 PM4/3/12
to
can you advise what to do after RapidShare opens?
Rob Zenuk
Apr 3, 2012, 7:20:54 PM4/3/12
to
VERY NICE!
I found it useful to put this in a subroutine so I could add a feature you
might want to consider. After I pull from the stack, I say the VAR and its
VALUE.
vardump: parse arg comment, rxvarparm
say center(' RXVARS' time('l') comment' ',78,'-')
"NEWSTACK"
call rxvars rxvarparm
do queued()
pull rxvar
say rxvar'='value(rxvar)
end
"DELSTACK"
say center(' RXVARS' time('l') comment' ',78,'-')
return
Additionally, since apparently all variables names are stored in memory in
upper case, you might want to consider folding the input variable name. I
was missing some output for a few minutes (since I traditionally do most
things in lower case) until I realized what was happening.
I also suspect this will be very interesting to see what else is floating
around in REXX variable storage. I saw some extra stuff from my USS dub as
well as some extra stuff from the outtrap...
Here is my test exec. It is something I was working on for a CICS/DB2
issue, but was very easy to add your tool to...
/* rexx - Find active DB2 threads for a CICS and display their tokens
arg db2ssid cicsapplid loops
call vardump 'startup'
if syscalls('ON') > 0 then exit(99)
do i=1 to loops
queue '-DIS THD('cicsapplid')'
queue "END"
x = outtrap(thread.)
"DSN SYSTEM("db2ssid")"
pull emptystack
pull emptystack
threadcount = 0
disptime = time()
call vardump 'loop' i, 'THREAD.'
do t=1 to thread.0
parse var thread.t cicsname threadtype active . . . plan . token
if threadtype = 'T' & active = '*' then
do
say disptime cicsname plan token
threadcount = threadcount + 1
end
end
say disptime threadcount
drop thread.
address SYSCALL "SLEEP" 1
end
call vardump 'finish'
exit 0
vardump: parse arg comment, rxvarparm
say center(' RXVARS' time('l') comment' ',78,'-')
"NEWSTACK"
call rxvars rxvarparm
do queued()
pull rxvar
say rxvar'='value(rxvar)
end
"DELSTACK"
say center(' RXVARS' time('l') comment' ',78,'-')
return
Thanks!
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
I found it useful to put this in a subroutine so I could add a feature you
might want to consider. After I pull from the stack, I say the VAR and its
VALUE.
vardump: parse arg comment, rxvarparm
say center(' RXVARS' time('l') comment' ',78,'-')
"NEWSTACK"
call rxvars rxvarparm
do queued()
pull rxvar
say rxvar'='value(rxvar)
end
"DELSTACK"
say center(' RXVARS' time('l') comment' ',78,'-')
return
Additionally, since apparently all variables names are stored in memory in
upper case, you might want to consider folding the input variable name. I
was missing some output for a few minutes (since I traditionally do most
things in lower case) until I realized what was happening.
I also suspect this will be very interesting to see what else is floating
around in REXX variable storage. I saw some extra stuff from my USS dub as
well as some extra stuff from the outtrap...
Here is my test exec. It is something I was working on for a CICS/DB2
issue, but was very easy to add your tool to...
/* rexx - Find active DB2 threads for a CICS and display their tokens
arg db2ssid cicsapplid loops
call vardump 'startup'
if syscalls('ON') > 0 then exit(99)
do i=1 to loops
queue '-DIS THD('cicsapplid')'
queue "END"
x = outtrap(thread.)
"DSN SYSTEM("db2ssid")"
pull emptystack
pull emptystack
threadcount = 0
disptime = time()
call vardump 'loop' i, 'THREAD.'
do t=1 to thread.0
parse var thread.t cicsname threadtype active . . . plan . token
if threadtype = 'T' & active = '*' then
do
say disptime cicsname plan token
threadcount = threadcount + 1
end
end
say disptime threadcount
drop thread.
address SYSCALL "SLEEP" 1
end
call vardump 'finish'
exit 0
vardump: parse arg comment, rxvarparm
say center(' RXVARS' time('l') comment' ',78,'-')
"NEWSTACK"
call rxvars rxvarparm
do queued()
pull rxvar
say rxvar'='value(rxvar)
end
"DELSTACK"
say center(' RXVARS' time('l') comment' ',78,'-')
return
Thanks!
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Apr 3, 2012, 9:12:42 PM4/3/12
to
On 2012-04-03 17:19, Rob Zenuk wrote:
> VERY NICE!
>
> I found it useful to put this in a subroutine so I could add a feature you
> might want to consider. After I pull from the stack, I say the VAR and its
> VALUE.
>
> vardump: parse arg comment, rxvarparm
> say center(' RXVARS' time('l') comment' ',78,'-')
> "NEWSTACK"
> call rxvars rxvarparm
> do queued()
> pull rxvar
> say rxvar'='value(rxvar)
Be careful here. Since value() uses the symbolic interface
> VERY NICE!
>
> I found it useful to put this in a subroutine so I could add a feature you
> might want to consider. After I pull from the stack, I say the VAR and its
> VALUE.
>
> vardump: parse arg comment, rxvarparm
> say center(' RXVARS' time('l') comment' ',78,'-')
> "NEWSTACK"
> call rxvars rxvarparm
> do queued()
> pull rxvar
> say rxvar'='value(rxvar)
and RXVARS has little choice but to return direct names,
if you pull something like FOO.Bar (careful of case)
and have previously assigned BAR=42, this will say value( "FOO.42" ),
an unexpected result. You need something like:
parse pull rxvar '.' +0 dot +1 Tail /* preserve case of Tail! */
say value( rxvar || dot"TaiL" ) /* Untested! */
>
> end
> "DELSTACK"
> say center(' RXVARS' time('l') comment' ',78,'-')
> return
Thomas Berg
Apr 4, 2012, 2:29:10 AM4/4/12
to
All this seems to presume that the variables was set in the same rexx.
My thought was to use it for variables from other rexxes.
Regards,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Paul
> Gilmartin
> Skickat: den 4 april 2012 03:11
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] List all (or selected) REXX variables
My thought was to use it for variables from other rexxes.
Regards,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Paul
> Gilmartin
> Skickat: den 4 april 2012 03:11
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] List all (or selected) REXX variables
Thomas Berg
Apr 4, 2012, 6:09:51 AM4/4/12
to
A common problem when I'm working with applications based on rexx is the communication of the variables through it.
You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
(Among other things.)
(You have the STEMPULL and STEMPUSH functions by Rob Scott, but they are as implicated by name stem oriented.)
Med Vänlig Hälsning,
> Skickat: den 4 april 2012 10:47
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] SV: [TSO-REXX] List all (or selected) REXX
> variables
>
> Once again we seem to have a solution without a problem. I'm sure it's
> very
> nice, but who writes code and then doesn't know what the variable names
> are?
>
> There are simple solutions to keeping track of non-array stem usage so
> what
> really is the function for?
You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
(Among other things.)
(You have the STEMPULL and STEMPUSH functions by Rob Scott, but they are as implicated by name stem oriented.)
Med Vänlig Hälsning,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För
> Adrian Stern
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För
> Skickat: den 4 april 2012 10:47
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] SV: [TSO-REXX] List all (or selected) REXX
> variables
>
> Once again we seem to have a solution without a problem. I'm sure it's
> very
> nice, but who writes code and then doesn't know what the variable names
> are?
>
> There are simple solutions to keeping track of non-array stem usage so
> what
> really is the function for?
Ken MacKenzie
Apr 4, 2012, 6:42:00 AM4/4/12
to
New version - automatically folds variable prefix to upper-case so X =
RXVARS('ken.') is equivalent to X = RXVARS('KEN.')
https://rapidshare.com/files/1516777755/rxvars.xmi
From:
Ken MacKenzie <Ken.Ma...@PRAMERICA.IE>
To:
ISP...@LISTSERV.ND.EDU
Date:
03/04/2012 15:09
Subject:
RXVARS('ken.') is equivalent to X = RXVARS('KEN.')
https://rapidshare.com/files/1516777755/rxvars.xmi
From:
Ken MacKenzie <Ken.Ma...@PRAMERICA.IE>
To:
ISP...@LISTSERV.ND.EDU
Date:
03/04/2012 15:09
Subject:
List all (or selected) REXX variables
Paul Gilmartin
Apr 4, 2012, 8:58:57 AM4/4/12
to
On Apr 4, 2012, at 02:47, Adrian Stern wrote:
>
> There are simple solutions to keeping track of non-array stem usage so what
> really is the function for?
>
Unless you're a masochist, it's easier to let the computer
>
> There are simple solutions to keeping track of non-array stem usage so what
> really is the function for?
>
do the work for you.
And the function is reusable; once it's coded it needn't
be replicated in every EXEC you write.
I suppose the downside is that you didn't invent it.
Ted MacNEIL
Apr 4, 2012, 9:19:46 AM4/4/12
to
>You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
>This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
(Among other things.)
See EXPOSE, or just dispense with the PROCEEDURE keyword.
>This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
(Among other things.)
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL
Paul Gilmartin
Apr 4, 2012, 9:55:20 AM4/4/12
to
On Apr 4, 2012, at 07:18, Ted MacNEIL wrote:
>> You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
>> This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
> (Among other things.)
>
> See EXPOSE, or just dispense with the PROCEEDURE keyword.
>
You overlooked the key word, "external".
>> You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
>> This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
> (Among other things.)
>
> See EXPOSE, or just dispense with the PROCEEDURE keyword.
>
I understand that OO Rexx and compiled Rexx have facilities
to INCLUDE text from a copybook. Interpreted Rexx lacks that.
I have a library of a few general purpose routines. In some
batch jobs I concatenate them with a main program in a DD
statement; REPRO that to a member of a temporary PDS, and
execute it from that. PITA. To address two egregious
deficiencies of Rexx.
-- gil
Don Imbriale
Apr 4, 2012, 10:52:32 AM4/4/12
to
I find that if I preface his comments with "In my opinion" or "In my not so
humble opinion", they sit better and I can read them and glean some value
due to his difference of opinion.
- Don Imbriale
On Wed, Apr 4, 2012 at 10:18 AM, Rob Zenuk <robz...@aol.com> wrote:
> You know, I think I'm going to have to block all email from Adrian... I am
> getting distracted and irritated by his constant "never wrong", "holier
> than
> thou" and "nobody could possibly know what they want or need" attitude.
>
> Some people actually do know what they need and do NOT find it necessary to
> spend the time providing this list all the background. If the list can
> help, great! If we can't because there are too few details, then we won't
> help and/or might ask for more details. When someone is looking for an
> opinion it is always helpful to provide background. When someone is waste
> deep in a problem or project, they are usually looking for a way to
> continue
> what they are doing (usually due to a deadline) and we should not judge
> since we do not know the details.
>
> There are also some newbies that are genuinely asking for help and might be
> innocently asking a question and do not deserve to be lambasted because
> they
> are just entering a subject that may have been around for a while. There
> are many valid times to suggest they RTFM, but I do not see a reason to
> push
> them away by ridiculing them in public. This piece of the industry is
> shrinking and the next generation is small compared to other platforms. If
> we are concerned about that, we need to do our part to encourage and
> promote
> usage and exploitation of this platform.
>
> While it would be nice to have the synergy of all the resources on this
> list
> review every request in detail to ensure the best possible solutions, I
> suspect that is probably an unrealistic expectation.
>
> In all cases, anyone can decide to ignore/delete threads they do not want
> to
> participate in. Additionally, we can also decide to participate at any
> level we want; ranging from the 1 word reply to a dissertation on any topic
> to a fully functional sample program. If you have the time and
> inclination;
> go for it. If not, no worries.
>
> Personally, I like to accumulate tools. I have found tools are what
> separates man from the animals. In regards to this thread in particular, I
> think Ken did a great job of providing a tool that gives great insight
> beyond adding SAY statements throughout the program. While there is or has
> been no requirement today (that I know of), this has been a long standing
> "nice to have" and mimics features of other languages and IDE's. Failing
> to
> see the utility in this generic debugging tool for the real programmer
> baffles me.
>
> In all cases, let's do this with respect, courtesy and professionalism.
>
> Rob
>
> Well I don't recall ever having a problem of this nature or anything like
> it
> so there's no work involved for me.
>
> After some 30 years or so of rexx I find most programs feel like
> replications - in fact many are made up of bits and pieces I've used so
> many
> times.
>
> There's no downside to using tools - as long as they're useful - I can't
> see
> the problem ever arising that would necessitate the use of this particular
> one.
>
> Generally speaking I find that so many posts involve a degree of complexity
> arising from what appears to be a need to do something in a particularly
> clever way rather than the easiest way.
humble opinion", they sit better and I can read them and glean some value
due to his difference of opinion.
- Don Imbriale
On Wed, Apr 4, 2012 at 10:18 AM, Rob Zenuk <robz...@aol.com> wrote:
> You know, I think I'm going to have to block all email from Adrian... I am
> getting distracted and irritated by his constant "never wrong", "holier
> than
> thou" and "nobody could possibly know what they want or need" attitude.
>
> Some people actually do know what they need and do NOT find it necessary to
> spend the time providing this list all the background. If the list can
> help, great! If we can't because there are too few details, then we won't
> help and/or might ask for more details. When someone is looking for an
> opinion it is always helpful to provide background. When someone is waste
> deep in a problem or project, they are usually looking for a way to
> continue
> what they are doing (usually due to a deadline) and we should not judge
> since we do not know the details.
>
> There are also some newbies that are genuinely asking for help and might be
> innocently asking a question and do not deserve to be lambasted because
> they
> are just entering a subject that may have been around for a while. There
> are many valid times to suggest they RTFM, but I do not see a reason to
> push
> them away by ridiculing them in public. This piece of the industry is
> shrinking and the next generation is small compared to other platforms. If
> we are concerned about that, we need to do our part to encourage and
> promote
> usage and exploitation of this platform.
>
> While it would be nice to have the synergy of all the resources on this
> list
> review every request in detail to ensure the best possible solutions, I
> suspect that is probably an unrealistic expectation.
>
> In all cases, anyone can decide to ignore/delete threads they do not want
> to
> participate in. Additionally, we can also decide to participate at any
> level we want; ranging from the 1 word reply to a dissertation on any topic
> to a fully functional sample program. If you have the time and
> inclination;
> go for it. If not, no worries.
>
> Personally, I like to accumulate tools. I have found tools are what
> separates man from the animals. In regards to this thread in particular, I
> think Ken did a great job of providing a tool that gives great insight
> beyond adding SAY statements throughout the program. While there is or has
> been no requirement today (that I know of), this has been a long standing
> "nice to have" and mimics features of other languages and IDE's. Failing
> to
> see the utility in this generic debugging tool for the real programmer
> baffles me.
>
> In all cases, let's do this with respect, courtesy and professionalism.
>
> Rob
>
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
> Of
> Adrian Stern
> Sent: Wednesday, April 04, 2012 6:14 AM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: SV: [TSO-REXX] List all (or selected) REXX variables
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
> Of
> Adrian Stern
> Sent: Wednesday, April 04, 2012 6:14 AM
> To: TSO-...@VM.MARIST.EDU
>
> Well I don't recall ever having a problem of this nature or anything like
> it
> so there's no work involved for me.
>
> After some 30 years or so of rexx I find most programs feel like
> replications - in fact many are made up of bits and pieces I've used so
> many
> times.
>
> There's no downside to using tools - as long as they're useful - I can't
> see
> the problem ever arising that would necessitate the use of this particular
> one.
>
> Generally speaking I find that so many posts involve a degree of complexity
> arising from what appears to be a need to do something in a particularly
> clever way rather than the easiest way.
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
> Of
> Paul Gilmartin
> Sent: den 4 april 2012 14:57
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] SV: [TSO-REXX] List all (or selected) REXX
> variables
>
> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
> Of
> Paul Gilmartin
> Sent: den 4 april 2012 14:57
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] SV: [TSO-REXX] List all (or selected) REXX
> variables
>
Rob Zenuk
Apr 4, 2012, 11:45:32 AM4/4/12
to
Why I abandoned the use of PROCEDURE...
Over the last ~23 years (since REXX became available in TSO) I have
developed a "framework" for all my REXX EXEC's. I have a library of over
200 subroutines that work with my framework. This allows me to figure out
how something works once (ok, may twice or twelve times), then build a
subroutine around it. This is probably no different then many of the rest
of you.
I also developed a subroutine commenting technique that is used by my
@REFRESH edit macro to import/replace the current copies of a subroutine
into a source member. This makes coding easier since my stable of
subroutines is separate, can be updated independently and merged with
existing programs quickly, easily and most importantly when appropriate.
My generic "model" has all the most common subroutines already incorporated
and allows me to quickly code something up and solve many adhoc problems in
minutes.
The framework gives me generic error handling, improved diagnostics,
application/module level tracing and a "dump" of useful debugging data when
errors occur after rollout. This is possible because I chose to use the
STACK for "command and control". Each subroutine is pushed onto the STACK
when it starts (along with its name, "trace level", SIGL, start time and
parmlist) and pulled off when it completes. If an error occurs, I simply
"unwind" the stack in my RCEXIT routine and can see how I got there with my
"Parentage Stack Trace". Since I wrapper every call to any environment
(TSOTRAP, ISPWRAP, ISRWRAP, USSTRAP, USSWRAP, SQLTRAP, to name a few - *TRAP
routines trap command output, *WRAP routines are for commands that just do
something and return an RC), I even see the exact command attempted
(including all substituted values). I also have the ability to turn on
trace for a specific subroutine (or subset of routines). I can also do a
"Module Trace" that will let me see performance characteristics (since the
start and end times are "logged" in the stack). Ken's RXVARS will probably
be incorporated as an optional debugging feature soon...
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.
My two cents...
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: Wednesday, April 04, 2012 6:54 AM
To: TSO-...@VM.MARIST.EDU
Over the last ~23 years (since REXX became available in TSO) I have
developed a "framework" for all my REXX EXEC's. I have a library of over
200 subroutines that work with my framework. This allows me to figure out
how something works once (ok, may twice or twelve times), then build a
subroutine around it. This is probably no different then many of the rest
of you.
I also developed a subroutine commenting technique that is used by my
@REFRESH edit macro to import/replace the current copies of a subroutine
into a source member. This makes coding easier since my stable of
subroutines is separate, can be updated independently and merged with
existing programs quickly, easily and most importantly when appropriate.
My generic "model" has all the most common subroutines already incorporated
and allows me to quickly code something up and solve many adhoc problems in
minutes.
The framework gives me generic error handling, improved diagnostics,
application/module level tracing and a "dump" of useful debugging data when
errors occur after rollout. This is possible because I chose to use the
STACK for "command and control". Each subroutine is pushed onto the STACK
when it starts (along with its name, "trace level", SIGL, start time and
parmlist) and pulled off when it completes. If an error occurs, I simply
"unwind" the stack in my RCEXIT routine and can see how I got there with my
"Parentage Stack Trace". Since I wrapper every call to any environment
(TSOTRAP, ISPWRAP, ISRWRAP, USSTRAP, USSWRAP, SQLTRAP, to name a few - *TRAP
routines trap command output, *WRAP routines are for commands that just do
something and return an RC), I even see the exact command attempted
(including all substituted values). I also have the ability to turn on
trace for a specific subroutine (or subset of routines). I can also do a
"Module Trace" that will let me see performance characteristics (since the
start and end times are "logged" in the stack). Ken's RXVARS will probably
be incorporated as an optional debugging feature soon...
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.
My two cents...
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: Wednesday, April 04, 2012 6:54 AM
To: TSO-...@VM.MARIST.EDU
Bob Bridges
Apr 4, 2012, 8:38:36 PM4/4/12
to
I'm a little surprised that no one gave the obvious answer to this one. Who
writes code and then doesn't know what the variable names are? Anyone who
uses user- or file-supplied values as stem tails, that's who.
For instance, if I want to know what values to expect in a certain field, I
write a quick program like this:
/* This REXX counts record types in the DBU. */
count.=0 /* count.<typ> = number of records found of type <typ> */
typs='' /* list of types found */
call execiost rendsn('DBU') /* read in the dataset */
do queued()
parse pull 1 typ 5 .
if wordpos(typ,typs)=0 then typs=typs typ
count.typ=count.typ+1; end
do jt=1 to words(typs); typ=word(typs,jt)
queue typ count.typ; end
call viewq /* display the queue */
return 0
If you're curious about execiost and viewq I can explain, but otherwise just
take it that the former reads my file onto the stack and the latter displays
the stack at the terminal. I read through the input file picking out the
record type and totaling up how many of each I find. But at the end, how do
I display the results? In order to display all the counts, I have to know
which record types I actually found. My usual solution is to save up a
string of record types, but I've never been very happy with it. Ken's
routine, or something like it, would suit me better.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* No single raindrop considers itself responsible for the flood. */
-----Original Message-----
writes code and then doesn't know what the variable names are? Anyone who
uses user- or file-supplied values as stem tails, that's who.
For instance, if I want to know what values to expect in a certain field, I
write a quick program like this:
/* This REXX counts record types in the DBU. */
count.=0 /* count.<typ> = number of records found of type <typ> */
typs='' /* list of types found */
call execiost rendsn('DBU') /* read in the dataset */
do queued()
parse pull 1 typ 5 .
if wordpos(typ,typs)=0 then typs=typs typ
count.typ=count.typ+1; end
do jt=1 to words(typs); typ=word(typs,jt)
queue typ count.typ; end
call viewq /* display the queue */
return 0
If you're curious about execiost and viewq I can explain, but otherwise just
take it that the former reads my file onto the stack and the latter displays
the stack at the terminal. I read through the input file picking out the
record type and totaling up how many of each I find. But at the end, how do
I display the results? In order to display all the counts, I have to know
which record types I actually found. My usual solution is to save up a
string of record types, but I've never been very happy with it. Ken's
routine, or something like it, would suit me better.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* No single raindrop considers itself responsible for the flood. */
-----Original Message-----
From: Adrian Stern
Sent: Wednesday, April 4, 2012 04:47
Once again we seem to have a solution without a problem. I'm sure it's very
nice, but who writes code and then doesn't know what the variable names are?
Sent: Wednesday, April 4, 2012 04:47
Once again we seem to have a solution without a problem. I'm sure it's very
nice, but who writes code and then doesn't know what the variable names are?
There are simple solutions to keeping track of non-array stem usage so what
really is the function for?
really is the function for?
John McKown
Apr 4, 2012, 10:11:23 PM4/4/12
to
I would love an "in stream" capability for REXX. So much so that I may
look at writing a program which reads the contents of a sequential input
DD (//REXXPGM DD ?) into memory, then invokes REXX (IRXEXEC?) passing
the buffer as the program to execute. I'm getting a bit tired of writing
UNIX programs in HLASM, for now. I need some ideas on what to do with
that (but that's for the MVS-OE forum, some day, maybe)
On Wed, 2012-04-04 at 07:54 -0600, Paul Gilmartin wrote:
> On Apr 4, 2012, at 07:18, Ted MacNEIL wrote:
>
> >> You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
> >> This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
> > (Among other things.)
> >
> > See EXPOSE, or just dispense with the PROCEEDURE keyword.
> >
> You overlooked the key word, "external".
>
> I understand that OO Rexx and compiled Rexx have facilities
> to INCLUDE text from a copybook. Interpreted Rexx lacks that.
>
> I have a library of a few general purpose routines. In some
> batch jobs I concatenate them with a main program in a DD
> statement; REPRO that to a member of a temporary PDS, and
> execute it from that. PITA. To address two egregious
> deficiencies of Rexx.
>
> -- gil
--
John McKown
Maranatha! <><
look at writing a program which reads the contents of a sequential input
DD (//REXXPGM DD ?) into memory, then invokes REXX (IRXEXEC?) passing
the buffer as the program to execute. I'm getting a bit tired of writing
UNIX programs in HLASM, for now. I need some ideas on what to do with
that (but that's for the MVS-OE forum, some day, maybe)
On Wed, 2012-04-04 at 07:54 -0600, Paul Gilmartin wrote:
> On Apr 4, 2012, at 07:18, Ted MacNEIL wrote:
>
> >> You could "modulize" the program(s) by procedures, but external ones do not have the access to the variables (in contrast to internal).
> >> This means that You have to develop interface(s) to communicate the variable values. Which is not a technical problem in itself but clutters the construction.
> > (Among other things.)
> >
> > See EXPOSE, or just dispense with the PROCEEDURE keyword.
> >
> You overlooked the key word, "external".
>
> I understand that OO Rexx and compiled Rexx have facilities
> to INCLUDE text from a copybook. Interpreted Rexx lacks that.
>
> I have a library of a few general purpose routines. In some
> batch jobs I concatenate them with a main program in a DD
> statement; REPRO that to a member of a temporary PDS, and
> execute it from that. PITA. To address two egregious
> deficiencies of Rexx.
>
> -- gil
--
Maranatha! <><
Paul Gilmartin
Apr 5, 2012, 12:38:32 AM4/5/12
to
On Apr 4, 2012, at 20:10, John McKown wrote:
> I would love an "in stream" capability for REXX. So much so that I may
> look at writing a program which reads the contents of a sequential input
> DD (//REXXPGM DD ?) into memory, then invokes REXX (IRXEXEC?) passing
> the buffer as the program to execute. I'm getting a bit tired of writing
> UNIX programs in HLASM, for now. I need some ideas on what to do with
> that (but that's for the MVS-OE forum, some day, maybe)
>
It's a sometimes exploited, AFAIK undocumented, behavior
> I would love an "in stream" capability for REXX. So much so that I may
> look at writing a program which reads the contents of a sequential input
> DD (//REXXPGM DD ?) into memory, then invokes REXX (IRXEXEC?) passing
> the buffer as the program to execute. I'm getting a bit tired of writing
> UNIX programs in HLASM, for now. I need some ideas on what to do with
> that (but that's for the MVS-OE forum, some day, maybe)
>
of IRXJCL that it copies the member name from PARM to JFCB
(TIOT? whatever). Initialization then does CLI (TM?) on
the member name and assumes sequential if it's zero. So
if you have an editor that lets you insert 0x00 as the first
character of PARM, you can execute a Rexx exec directly
out of //SYSEXEC DD *.
-- gil
Thomas Berg
Apr 5, 2012, 4:23:07 AM4/5/12
to
A bit like Robert Zenuk I'm using my own "standard" routines for common tasks. Although I use the compilers %INCLUDE directive to access them.
E g I have functions for I/O, like: "rcr = @READ('* INDD R.')" where all error handling is incorporated, including a jump to an exit routine if necessary. (And the error and exit routine is also an INCLUDE.)
This eliminates the error-prone reinventing of wheels and also makes the code easier to read.
The advantage of internal routines like these is the access to the variables local to the caller. Which in itself simplifies the callers code.
(You do not necessary need a compiler to work like this, a special execute command or a separation of the source and "execution" libraries with a "compile" command can accomplish this.)
Of course, this wouldn't be necessary if You could expose the local variables to an external subroutine.
Regards,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
E g I have functions for I/O, like: "rcr = @READ('* INDD R.')" where all error handling is incorporated, including a jump to an exit routine if necessary. (And the error and exit routine is also an INCLUDE.)
This eliminates the error-prone reinventing of wheels and also makes the code easier to read.
The advantage of internal routines like these is the access to the variables local to the caller. Which in itself simplifies the callers code.
(You do not necessary need a compiler to work like this, a special execute command or a separation of the source and "execution" libraries with a "compile" command can accomplish this.)
Of course, this wouldn't be necessary if You could expose the local variables to an external subroutine.
Regards,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
Walter Pachl
Apr 5, 2012, 4:35:12 AM4/5/12
to
My way:
keyxlist=''
Parse Var rec 13 key +10 22 data +30
data.key=data
keyx=c2x(key)
If wordpos(keyx,keyxlist)=0 Then keyxlist=keyxlist keyx
Do While keyxlist<>''
Parse Var keyxlist keyx keyxlist
key=x2c(keyx)
Say key '->' data.key
End
Never expect data.walter to work for tails like 'Walter', 'walter', or even 'WALTER'
walter=4711 may have been inserted somewhere
Just my 2 EuroCents
Walter
---- Adrian Stern <adrian...@TELE2.SE> schrieb:
> I've always used a string (bracketing each entry with some character to
> avoid false matches) nothing I've ever seen could be simpler
keyxlist=''
Parse Var rec 13 key +10 22 data +30
data.key=data
keyx=c2x(key)
If wordpos(keyx,keyxlist)=0 Then keyxlist=keyxlist keyx
Do While keyxlist<>''
Parse Var keyxlist keyx keyxlist
key=x2c(keyx)
Say key '->' data.key
End
Never expect data.walter to work for tails like 'Walter', 'walter', or even 'WALTER'
walter=4711 may have been inserted somewhere
Just my 2 EuroCents
Walter
---- Adrian Stern <adrian...@TELE2.SE> schrieb:
> I've always used a string (bracketing each entry with some character to
> avoid false matches) nothing I've ever seen could be simpler
Walter Pachl
Apr 5, 2012, 4:56:30 AM4/5/12
to
Maybe I answerer the wrong question/problem
On second thought I don't understand what you mean by
On second thought I don't understand what you mean by
" I've always used a string (bracketing each entry with some character to
avoid false matches) nothing I've ever seen could be simpler"
Walter
avoid false matches) nothing I've ever seen could be simpler"
Ken MacKenzie
Apr 5, 2012, 5:34:05 AM4/5/12
to
Wow! Thanks Paul. The number of times I've wanted to do this and end up
writing an extra IEBGENER step before the REXX step, the result of which
is confusion for the users.
Just tested it and it works a treat!
From:
Paul Gilmartin <PaulGB...@AIM.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
05/04/2012 05:39
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
writing an extra IEBGENER step before the REXX step, the result of which
is confusion for the users.
Just tested it and it works a treat!
From:
Paul Gilmartin <PaulGB...@AIM.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
05/04/2012 05:39
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Walter Pachl
Apr 5, 2012, 7:29:19 AM4/5/12
to
That's why wordpos is better (as long as the key has no blanks in or around it)
Paul Gilmartin
Apr 5, 2012, 9:25:03 AM4/5/12
to
On Apr 5, 2012, at 03:19, Adrian Stern wrote:
> Instead of stringing the values together as simple words I will for example bracket each string with delimiters like this
>
> newString = "<"value">"
>
> if pos(newString, myStrings) < 1 then myString = myString newString
>
> so I avoid confusing the value "fred" and "freddy"
>
Provided that you know a priori that "<" and ">" can not
occur in your tails.
-- gil
> Instead of stringing the values together as simple words I will for example bracket each string with delimiters like this
>
> newString = "<"value">"
>
> if pos(newString, myStrings) < 1 then myString = myString newString
>
> so I avoid confusing the value "fred" and "freddy"
>
Provided that you know a priori that "<" and ">" can not
occur in your tails.
-- gil
Paul Gilmartin
Apr 5, 2012, 9:29:52 AM4/5/12
to
On Apr 5, 2012, at 03:33, Ken MacKenzie wrote:
> Wow! Thanks Paul. The number of times I've wanted to do this and end up
> writing an extra IEBGENER step before the REXX step, the result of which
> is confusion for the users.
>
> Just tested it and it works a treat!
>
This is a sort of behavior that an implementation
> Wow! Thanks Paul. The number of times I've wanted to do this and end up
> writing an extra IEBGENER step before the REXX step, the result of which
> is confusion for the users.
>
> Just tested it and it works a treat!
>
should either document and support or prohibit and
enforce.
Paul Gilmartin
Apr 5, 2012, 9:38:27 AM4/5/12
to
On Apr 5, 2012, at 03:33, Ken MacKenzie wrote:
> Wow! Thanks Paul. The number of times I've wanted to do this and end up
> writing an extra IEBGENER step before the REXX step, the result of which
> is confusion for the users.
>
Addendum: Do you believe it's less confusing for the
> writing an extra IEBGENER step before the REXX step, the result of which
> is confusion for the users.
>
users to provide JCL containing a nondisplayable character
that some editors may shun?
Adrian Stern
Apr 5, 2012, 9:40:32 AM4/5/12
to
Another one who doesn't understand plain English!
Those delimiters were given as an example to explain the idea in a simple
way - not simple enough apparently. I tend to use odd or non-printable
characters (<hex 32).
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Those delimiters were given as an example to explain the idea in a simple
way - not simple enough apparently. I tend to use odd or non-printable
characters (<hex 32).
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 5 april 2012 15:24
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] List all (or selected) REXX variables
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] List all (or selected) REXX variables
Ken MacKenzie
Apr 5, 2012, 10:42:06 AM4/5/12
to
Yes, I think it's less confusing, especially if you code it like this:
//REXX EXEC PGM=IRXJCL,
// PARM=' ' <- Note: the PARM is X'00'
From:
Paul Gilmartin <PaulGB...@AIM.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
05/04/2012 14:39
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
//REXX EXEC PGM=IRXJCL,
// PARM=' ' <- Note: the PARM is X'00'
From:
Paul Gilmartin <PaulGB...@AIM.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
05/04/2012 14:39
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Rob Zenuk
Apr 5, 2012, 1:51:07 PM4/5/12
to
I think what Bob was suggesting, exploiting RXVARS may even be simpler... I
was playing with this last night after Bob sent out his post. Pretty cool.
Until Bob had suggested this I had not considered RXVARS for anything but a
debugging tool...
/* rexx - Using RXVARS to keep track of non numeric stems */
arg count
do i=1 to count
rec = 'KEY'i 'My Stuff' time('l') 'DATA'i
parse var rec key data
data.key = data
end
call rxvars('DATA.')
do queued()
pull key
parse var key . '.' keyvalue
say keyvalue '->' value(key)
end
The current challenge with this approach (maybe Ken can look at this), is
when the KEY value is lower case, RXVARS has a problem finding the variable
(even with the old non-translating version).
So, out of curiosity I benchmarked the 2 techniques...
This is what I found:
#STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK
#TEST100 RXVARS IKJEFT01 00 90 .02 .00 .08
#TEST100 WORDPOS IKJEFT01 00 51 .02 .00 .04
#TEST1K RXVARS IKJEFT01 00 102 .05 .00 .08
#TEST1K WORDPOS IKJEFT01 00 64 .07 .00 .11
#TEST10K RXVARS IKJEFT01 00 238 .29 .00 .36
#TEST10K WORDPOS IKJEFT01 00 197 4.38 .00 4.81
#TEST100K RXVARS IKJEFT01 00 1631 2.87 .01 3.24
IEF450I JOBNAME WORDPOS TEST100K - ABEND=S222 U0000 REASON=00000000
#TEST100K WORDPOS IKJEFT01 *S222 46 220.15 .00 240.28
I ran each technique with 100, 1000, 10000 and 100000 variables. Somewhere
between 100 and 1000 variable RXVARS becomes more efficient. I had to
cancel the 100K trial for WORDPOS...
Here are the 2 EXEC's
/* rexx - Using old method */
arg count
keyxlist = ''
do i=1 to count
rec = 'KEY'i 'My Stuff' time('l') 'DATA'i
parse var rec key data
data.key = data
keyx = c2x(key)
if wordpos(keyx,keyxlist) = 0 then
keyxlist = keyxlist keyx
end
do while keyxlist <> ''
parse var keyxlist keyx keyxlist
key = x2c(keyx)
say key '->' data.key
end
/* rexx - Using RXVARS to keep track of non numeric stems */
arg count
do i=1 to count
rec = 'KEY'i 'My Stuff' time('l') 'DATA'i
parse var rec key data
data.key = data
end
call rxvars('DATA.')
do queued()
pull key
parse var key . '.' keyvalue
say keyvalue '->' value(key)
end
My JCL:
//jobname...
//***************************************************************
//* TEST RXVARS VERSUS WORDPOS *
//***************************************************************
//TEST PROC COUNT=
//RXVARS EXEC PGM=IKJEFT01,PARM='RXVART1 &COUNT'
//STEPLIB DD DSN=MY.RXVARS.LOADLIB,DISP=SHR
//SYSEXEC DD DSN=MY.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//***************************************************************
//WORDPOS EXEC PGM=IKJEFT01,PARM='RXVART2 &COUNT'
//STEPLIB DD DSN=MY.RXVARS.LOADLIB,DISP=SHR
//SYSEXEC DD DSN=MY.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//***************************************************************
//TEST100 EXEC TEST,COUNT=100
//TEST1K EXEC TEST,COUNT=1000
//TEST10K EXEC TEST,COUNT=10000
//TEST100K EXEC TEST,COUNT=100000
Food for thought...
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
was playing with this last night after Bob sent out his post. Pretty cool.
Until Bob had suggested this I had not considered RXVARS for anything but a
debugging tool...
/* rexx - Using RXVARS to keep track of non numeric stems */
arg count
do i=1 to count
rec = 'KEY'i 'My Stuff' time('l') 'DATA'i
parse var rec key data
data.key = data
end
call rxvars('DATA.')
do queued()
pull key
parse var key . '.' keyvalue
say keyvalue '->' value(key)
end
The current challenge with this approach (maybe Ken can look at this), is
when the KEY value is lower case, RXVARS has a problem finding the variable
(even with the old non-translating version).
So, out of curiosity I benchmarked the 2 techniques...
This is what I found:
#STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK
#TEST100 RXVARS IKJEFT01 00 90 .02 .00 .08
#TEST100 WORDPOS IKJEFT01 00 51 .02 .00 .04
#TEST1K RXVARS IKJEFT01 00 102 .05 .00 .08
#TEST1K WORDPOS IKJEFT01 00 64 .07 .00 .11
#TEST10K RXVARS IKJEFT01 00 238 .29 .00 .36
#TEST10K WORDPOS IKJEFT01 00 197 4.38 .00 4.81
#TEST100K RXVARS IKJEFT01 00 1631 2.87 .01 3.24
IEF450I JOBNAME WORDPOS TEST100K - ABEND=S222 U0000 REASON=00000000
#TEST100K WORDPOS IKJEFT01 *S222 46 220.15 .00 240.28
I ran each technique with 100, 1000, 10000 and 100000 variables. Somewhere
between 100 and 1000 variable RXVARS becomes more efficient. I had to
cancel the 100K trial for WORDPOS...
Here are the 2 EXEC's
/* rexx - Using old method */
arg count
keyxlist = ''
do i=1 to count
rec = 'KEY'i 'My Stuff' time('l') 'DATA'i
parse var rec key data
data.key = data
keyx = c2x(key)
if wordpos(keyx,keyxlist) = 0 then
keyxlist = keyxlist keyx
end
do while keyxlist <> ''
parse var keyxlist keyx keyxlist
key = x2c(keyx)
say key '->' data.key
end
/* rexx - Using RXVARS to keep track of non numeric stems */
arg count
do i=1 to count
rec = 'KEY'i 'My Stuff' time('l') 'DATA'i
parse var rec key data
data.key = data
end
call rxvars('DATA.')
do queued()
pull key
parse var key . '.' keyvalue
say keyvalue '->' value(key)
end
My JCL:
//jobname...
//***************************************************************
//* TEST RXVARS VERSUS WORDPOS *
//***************************************************************
//TEST PROC COUNT=
//RXVARS EXEC PGM=IKJEFT01,PARM='RXVART1 &COUNT'
//STEPLIB DD DSN=MY.RXVARS.LOADLIB,DISP=SHR
//SYSEXEC DD DSN=MY.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//***************************************************************
//WORDPOS EXEC PGM=IKJEFT01,PARM='RXVART2 &COUNT'
//STEPLIB DD DSN=MY.RXVARS.LOADLIB,DISP=SHR
//SYSEXEC DD DSN=MY.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//***************************************************************
//TEST100 EXEC TEST,COUNT=100
//TEST1K EXEC TEST,COUNT=1000
//TEST10K EXEC TEST,COUNT=10000
//TEST100K EXEC TEST,COUNT=100000
Food for thought...
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Phil Smith III
Apr 6, 2012, 10:25:40 AM4/6/12
to
Rob Zenuk wrote:
<snip>
Or did you mean it really doesn't find the variable? I find that hard to believe (but then, I didn't write it). In any case, you want to use PARSE PULL, because otherwise you're lying to yourself! :-)
...phsiii
<snip>
>The current challenge with this approach (maybe Ken can look at this), is
>when the KEY value is lower case, RXVARS has a problem finding the variable
>(even with the old non-translating version).
Use PARSE PULL instead of PULL. You're the one translating...
>when the KEY value is lower case, RXVARS has a problem finding the variable
>(even with the old non-translating version).
Or did you mean it really doesn't find the variable? I find that hard to believe (but then, I didn't write it). In any case, you want to use PARSE PULL, because otherwise you're lying to yourself! :-)
...phsiii
Paul Gilmartin
Apr 6, 2012, 10:41:27 AM4/6/12
to
On Apr 6, 2012, at 08:23, Phil Smith III wrote:
> Rob Zenuk wrote:
> <snip>
>> The current challenge with this approach (maybe Ken can look at this), is
>> when the KEY value is lower case, RXVARS has a problem finding the variable
>> (even with the old non-translating version).
>
> Use PARSE PULL instead of PULL. You're the one translating...
> Or did you mean it really doesn't find the variable? I find that hard to believe (but then, I didn't write it). In any case, you want to use PARSE PULL, because otherwise you're lying to yourself! :-)
>
What happens when the key value contains blanks or
> Rob Zenuk wrote:
> <snip>
>> The current challenge with this approach (maybe Ken can look at this), is
>> when the KEY value is lower case, RXVARS has a problem finding the variable
>> (even with the old non-translating version).
>
> Use PARSE PULL instead of PULL. You're the one translating...
> Or did you mean it really doesn't find the variable? I find that hard to believe (but then, I didn't write it). In any case, you want to use PARSE PULL, because otherwise you're lying to yourself! :-)
>
nondisplayable characters? There's some argument here
for a technique that returns results in a compound
variable rather than the stack so PARSE is unnecessary.
-- gil
Rob Zenuk
Apr 6, 2012, 11:13:09 AM4/6/12
to
I had done that...
Here is the code using a lower case key and parse pull instead...
/* rexx - Using RXVARS to keep track of non numeric stems */
arg count
do i=1 to count
rec = 'key'i 'My Stuff' time('l') 'DATA'i
key1 -> DATA.KEY1
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Phil Smith III
Sent: Friday, April 06, 2012 7:23 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: List all (or selected) REXX variables
Here is the code using a lower case key and parse pull instead...
/* rexx - Using RXVARS to keep track of non numeric stems */
arg count
do i=1 to count
parse var rec key data
data.key = data
end
call rxvars('DATA.')
do queued()
parse pull key
data.key = data
end
call rxvars('DATA.')
do queued()
parse var key . '.' keyvalue
say keyvalue '->' value(key)
end
The results are:
say keyvalue '->' value(key)
end
key1 -> DATA.KEY1
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Phil Smith III
Sent: Friday, April 06, 2012 7:23 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: List all (or selected) REXX variables
Paul Gilmartin
Apr 6, 2012, 11:30:17 AM4/6/12
to
On Apr 6, 2012, at 09:11, Rob Zenuk wrote:
> I had done that...
>
> Here is the code using a lower case key and parse pull instead...
>
Gone from rapidshare?:
> I had done that...
>
> Here is the code using a lower case key and parse pull instead...
>
Download not available
The following download is not available:
https://rapidshare.com/files/2156022311/rxvars.xmi | 0.00 MB
The file of the above link no longer exists. This could be for several reasons:
• The uploader deleted the file.
• The file contained illegal contents and was deleted from our servers by our Anti-Abuse team.
• The link is incorrect.
• The server is busy and can not process the request.
Oops?
-- gil
Farley, Peter x23353
Apr 6, 2012, 12:09:05 PM4/6/12
to
I'm replying to one of the older messages in this discussion to respond to Adrian's original question.
A while back I wrote a very large Rexx routine that does very complex text analysis with a quite irregular text input, where parts of the text being analyzed needed to be used as tails of various stems. Although it is certainly possible (and it is what I did during the original development) to write code to track the tails being found and used, it is somewhat tedious to set up debugging code to dump all of the tails and the values of the stems addressed by those tails. If I had something like RXVARS available at that time (or even just a "FOR (X IN STEM.) DO ... END" construct) it would have been SO much easier to debug this complex multi-phase process.
IMHO, although it is not a perfect solution, RXVARS could be a valuable debugging tool by making complex variable dumps in complex code easier. I'm all for making things easier.
Ken, I do hope you will be able to release the source for RXVARS sooner rather than later. Many of our employers have business policies that absolutely prohibit using any outside code not supplied by a "trusted" vendor unless source is available for inspection. That's part of what makes CBT code so valuable to so many of us.
Thanks again for devising a useful tool.
Peter
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Adrian Stern
Sent: Wednesday, April 04, 2012 4:47 AM
To: TSO-...@vm.marist.edu
Subject: Re: SV: [TSO-REXX] List all (or selected) REXX variables
Once again we seem to have a solution without a problem. I'm sure it's very
nice, but who writes code and then doesn't know what the variable names are?
There are simple solutions to keeping track of non-array stem usage so what
really is the function for?
--
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
A while back I wrote a very large Rexx routine that does very complex text analysis with a quite irregular text input, where parts of the text being analyzed needed to be used as tails of various stems. Although it is certainly possible (and it is what I did during the original development) to write code to track the tails being found and used, it is somewhat tedious to set up debugging code to dump all of the tails and the values of the stems addressed by those tails. If I had something like RXVARS available at that time (or even just a "FOR (X IN STEM.) DO ... END" construct) it would have been SO much easier to debug this complex multi-phase process.
IMHO, although it is not a perfect solution, RXVARS could be a valuable debugging tool by making complex variable dumps in complex code easier. I'm all for making things easier.
Ken, I do hope you will be able to release the source for RXVARS sooner rather than later. Many of our employers have business policies that absolutely prohibit using any outside code not supplied by a "trusted" vendor unless source is available for inspection. That's part of what makes CBT code so valuable to so many of us.
Thanks again for devising a useful tool.
Peter
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Adrian Stern
Sent: Wednesday, April 04, 2012 4:47 AM
To: TSO-...@vm.marist.edu
Subject: Re: SV: [TSO-REXX] List all (or selected) REXX variables
Once again we seem to have a solution without a problem. I'm sure it's very
nice, but who writes code and then doesn't know what the variable names are?
There are simple solutions to keeping track of non-array stem usage so what
really is the function for?
--
Phil Smith III
Apr 7, 2012, 12:00:15 PM4/7/12
to
Rob Zenuk wrote:
>I had done that...
Ah. I bet whoever wrote that function didn't understand about tails not always being uppercase, and was being "hygienic". Tsk.
>I had done that...
Phil Smith III
Apr 7, 2012, 12:03:06 PM4/7/12
to
Paul Gilmartin wrote:
>What happens when the key value contains blanks or=20
The stack approach also fails if the variable value is longer than the maximum stacked line; returning variables makes MUCH more sense.
...phsiii
>What happens when the key value contains blanks or=20
>nondisplayable characters? There's some argument here
>for a technique that returns results in a compound
>variable rather than the stack so PARSE is unnecessary.
Excellent point. Or at a minimum, stacking the variable name and value as separate lines.
>for a technique that returns results in a compound
>variable rather than the stack so PARSE is unnecessary.
The stack approach also fails if the variable value is longer than the maximum stacked line; returning variables makes MUCH more sense.
...phsiii
Ken MacKenzie
Apr 10, 2012, 4:46:34 AM4/10/12
to
I renamed the old version.
https://rapidshare.com/files/2156022311/rxvars_old.xmi
https://rapidshare.com/files/477065443/readme.txt
https://rapidshare.com/files/1516777755/rxvars.xmi
From:
Paul Gilmartin <PaulGB...@AIM.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
06/04/2012 16:31
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
? The file contained illegal contents and was deleted
? The server is busy and can not process the request.
https://rapidshare.com/files/2156022311/rxvars_old.xmi
https://rapidshare.com/files/477065443/readme.txt
https://rapidshare.com/files/1516777755/rxvars.xmi
From:
Paul Gilmartin <PaulGB...@AIM.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
06/04/2012 16:31
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
On Apr 6, 2012, at 09:11, Rob Zenuk wrote:
> I had done that...
>
> Here is the code using a lower case key and parse pull instead...
>
Gone from rapidshare?:
Download not available
The following download is not available:
https://rapidshare.com/files/2156022311/rxvars.xmi | 0.00 MB
The file of the above link no longer exists. This could be for several
reasons:
? The uploader deleted the file.
> I had done that...
>
> Here is the code using a lower case key and parse pull instead...
>
Gone from rapidshare?:
Download not available
The following download is not available:
https://rapidshare.com/files/2156022311/rxvars.xmi | 0.00 MB
The file of the above link no longer exists. This could be for several
reasons:
? The file contained illegal contents and was deleted
from our servers by our Anti-Abuse team.
? The link is incorrect.
? The server is busy and can not process the request.
Ken MacKenzie
Apr 10, 2012, 4:55:57 AM4/10/12
to
I did think about returning the variable names in another stem. Then I
thought that the program was in danger of disappearing up its own ...
(well, you get the picture!) My interim solution to that problem was to
return them all to the stack and then unstack them as a stem but then I
thought, "what the heck!, If I'm going to do that, the calling REXX might
as well do it." Returning the values was never an option and my program
sets the maximum value length to zero so that (almost) all variables are
returned with a truncated value.
Given the above, I'm still open to suggestions and the next enhancement
I'm working on, when I get the time, is to allow a parameter to sort the
variable names into ascending or descending order.
From:
Phil Smith III <li...@AKPHS.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
07/04/2012 17:04
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
thought that the program was in danger of disappearing up its own ...
(well, you get the picture!) My interim solution to that problem was to
return them all to the stack and then unstack them as a stem but then I
thought, "what the heck!, If I'm going to do that, the calling REXX might
as well do it." Returning the values was never an option and my program
sets the maximum value length to zero so that (almost) all variables are
returned with a truncated value.
Given the above, I'm still open to suggestions and the next enhancement
I'm working on, when I get the time, is to allow a parameter to sort the
variable names into ascending or descending order.
From:
Phil Smith III <li...@AKPHS.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
07/04/2012 17:04
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Paul Gilmartin
Apr 10, 2012, 11:41:49 AM4/10/12
to
On Apr 10, 2012, at 02:55, Ken MacKenzie wrote:
> I did think about returning the variable names in another stem. Then I
> thought that the program was in danger of disappearing up its own ...
> (well, you get the picture!) My interim solution to that problem was to
> return them all to the stack and then unstack them as a stem but then I
> thought, "what the heck!, If I'm going to do that, the calling REXX might
> as well do it." Returning the values was never an option and my program
> sets the maximum value length to zero so that (almost) all variables are
> returned with a truncated value.
>
Thanks for that; I now see it at:
> I did think about returning the variable names in another stem. Then I
> thought that the program was in danger of disappearing up its own ...
> (well, you get the picture!) My interim solution to that problem was to
> return them all to the stack and then unstack them as a stem but then I
> thought, "what the heck!, If I'm going to do that, the calling REXX might
> as well do it." Returning the values was never an option and my program
> sets the maximum value length to zero so that (almost) all variables are
> returned with a truncated value.
>
I renamed the old version.
https://rapidshare.com/files/2156022311/rxvars_old.xmi
https://rapidshare.com/files/477065443/readme.txt
https://rapidshare.com/files/1516777755/rxvars.xmi
> Given the above, I'm still open to suggestions and the next enhancement
> I'm working on, when I get the time, is to allow a parameter to sort the
> variable names into ascending or descending order.
>
Thanks for that. Doc needed:
> I'm working on, when I get the time, is to allow a parameter to sort the
> variable names into ascending or descending order.
>
o Are the names stacked FIFO or LIFO?
o How do I know how many, or where the list ends, in order
to avoid reading stuff that was previously on the stack
or even dropping in to a terminal input prompt? (There's
probably a way, but I never use the stack, so I don't
know it offhand.)
o I'd prefer "rxvars.readme.txt". I have too many just
plain "readme.txt" running around my system already.
On Apr 9, 2012, at 15:41, Vitonis, Tony wrote:
>
> CALL SYSCALLS "ON"
> /* Use the handy-dandy RXVARS() to get a list of created variables */
>
My continuing concern is to have something I can
deliver to customers with assurance of support.
Something downloaded OCO from Rapidshare doesn't
qualify. In fact, there were reports here of sites
that didn't allow access to Rapidshare.
-- gil
Ken MacKenzie
Apr 10, 2012, 12:02:33 PM4/10/12
to
Your wish, is my command:
https://rapidshare.com/files/477065443/rxvars-readme.txt
I'm going to put them on Dropbox as well, later
https://rapidshare.com/files/477065443/rxvars-readme.txt
I'm going to put them on Dropbox as well, later
10/04/2012 16:42
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject:
Re: [TSO-REXX] List all (or selected) REXX variables
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Rob Zenuk
Apr 10, 2012, 12:52:33 PM4/10/12
to
> o How do I know how many, or where the list ends, in order
> to avoid reading stuff that was previously on the stack
> or even dropping in to a terminal input prompt? (There's
> probably a way, but I never use the stack, so I don't
> know it offhand.)
I wrappered RXVARS with NEWSTACK/DELSTACK to protect and avoid confusion
> to avoid reading stuff that was previously on the stack
> or even dropping in to a terminal input prompt? (There's
> probably a way, but I never use the stack, so I don't
> know it offhand.)
with the existing stack...
Rob
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Ken MacKenzie
Apr 11, 2012, 5:05:36 AM4/11/12
to
Vitonis, Tony
Apr 11, 2012, 2:26:34 PM4/11/12
to
The Dropbox link doesn't work for me. It shows up as an already-accepted invitation.
George, William@FTB
Apr 11, 2012, 2:34:20 PM4/11/12
to
Same here
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Vitonis, Tony
Sent: Wednesday, April 11, 2012 11:26 AM
To: TSO-...@VM.MARIST.EDU
______________________________________________________________________
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email.
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf
Of Vitonis, Tony
Sent: Wednesday, April 11, 2012 11:26 AM
To: TSO-...@VM.MARIST.EDU
CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email.
Thom Stone
Apr 11, 2012, 11:06:18 PM4/11/12
to
Download not available
The following download is not available:
https://rapidshare.com/files/477065443/rxvars-readme.txt | 0.00 MB
The following download is not available:
Both XMI files were there.
Thanks.
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Ken MacKenzie
Sent: Tuesday, April 10, 2012 11:02 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] List all (or selected) REXX variables
Your wish, is my command:
https://rapidshare.com/files/477065443/rxvars-readme.txt
I'm going to put them on Dropbox as well, later
<SNIP>
Sent: Tuesday, April 10, 2012 11:02 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] List all (or selected) REXX variables
Your wish, is my command:
https://rapidshare.com/files/477065443/rxvars-readme.txt
I'm going to put them on Dropbox as well, later
Ken MacKenzie
Apr 12, 2012, 5:22:29 AM4/12/12
to
OK, I think these will work:
http://db.tt/BjKPcGao
http://db.tt/1tdjPATG
http://db.tt/ykc1EWB0
Unfortunately I can't test from my work PC.
From:
"Vitonis, Tony" <Tony.V...@CA.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
11/04/2012 19:27
Subject:
Re: [TSO-REXX] RXVARS: File locations
http://db.tt/BjKPcGao
http://db.tt/1tdjPATG
http://db.tt/ykc1EWB0
Unfortunately I can't test from my work PC.
From:
"Vitonis, Tony" <Tony.V...@CA.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
11/04/2012 19:27
Subject:
Re: [TSO-REXX] RXVARS: File locations
Höglund Lars
Apr 12, 2012, 6:18:08 AM4/12/12
to
False and True correct
Adrian, du glömde THEN efter IF
-----Ursprungligt meddelande-----
Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Adrian Stern
Skickat: den 12 april 2012 12:13
Till: TSO-...@VM.MARIST.EDU
Ämne: Re: [TSO-REXX] PROCEDURE
I'm fairly certain this is the wrong thread SUBJECT but I just had a
thought:
If I were to code a solution to the min/max question it would probably look like this
If isInRange(test value, min value, max value)
-z-
-z-
isInRange: procedure
arg value, min, max
if value < min return 0
if value > max return 0
return 1
I think zero is false and 1 true - if not just reverse them.
Wouldn't that be a simple solution?
Adrian, du glömde THEN efter IF
-----Ursprungligt meddelande-----
Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Adrian Stern
Skickat: den 12 april 2012 12:13
Till: TSO-...@VM.MARIST.EDU
Ämne: Re: [TSO-REXX] PROCEDURE
I'm fairly certain this is the wrong thread SUBJECT but I just had a
thought:
If I were to code a solution to the min/max question it would probably look like this
If isInRange(test value, min value, max value)
-z-
-z-
isInRange: procedure
arg value, min, max
if value < min return 0
if value > max return 0
return 1
I think zero is false and 1 true - if not just reverse them.
Wouldn't that be a simple solution?
Vitonis, Tony
Apr 12, 2012, 10:45:48 AM4/12/12
to
Or just:
RETURN (value >= min) & (value <= max)
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Adrian Stern
Sent: Thursday, April 12, 2012 6:07 AM
To: TSO-...@VM.MARIST.EDU
RETURN (value >= min) & (value <= max)
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Adrian Stern
Sent: Thursday, April 12, 2012 6:07 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: PROCEDURE
I'm fairly certain this is the wrong thread SUBJECT but I just had a
thought:
If I were to code a solution to the min/max question it would probably look
like this
If isInRange(test value, min value, max value)
-z-
-z-
isInRange: procedure
arg value, min, max
if value < min return 0
if value > max return 0
return 1
I think zero is false and 1 true - if not just reverse them.
Wouldn't that be a simple solution?
I'm fairly certain this is the wrong thread SUBJECT but I just had a
thought:
If I were to code a solution to the min/max question it would probably look
like this
If isInRange(test value, min value, max value)
-z-
-z-
isInRange: procedure
arg value, min, max
if value < min return 0
if value > max return 0
return 1
I think zero is false and 1 true - if not just reverse them.
Wouldn't that be a simple solution?
Bill Ashton
Apr 12, 2012, 11:42:16 AM4/12/12
to
Thanks for your help here...here is what I wound up with:
001700 InRange: Procedure; Call
Trace("O");
001701
001702 Parse Arg _val _low _high
_include
001703 If _include = "I" Then /* Inclusive
values */
001704 Return ((_val >= _low) & (_val <=
_high));
001705 Else /* Exclusive
values */
001706 Return ((_val > _low) & (_val <
_high));
Billy
--
Thank you and best regards,
*Billy Ashton*
001700 InRange: Procedure; Call
Trace("O");
001701
001702 Parse Arg _val _low _high
_include
001703 If _include = "I" Then /* Inclusive
values */
001704 Return ((_val >= _low) & (_val <=
_high));
001705 Else /* Exclusive
values */
001706 Return ((_val > _low) & (_val <
_high));
Billy
Thank you and best regards,
*Billy Ashton*
Paul Gilmartin
Apr 12, 2012, 12:24:18 PM4/12/12
to
On Apr 12, 2012, at 09:41, Bill Ashton wrote:
> Thanks for your help here...here is what I wound up with:
>
> 001700 InRange: Procedure; Call Trace("O");
> 001701
> 001702 Parse Arg _val _low _high _include
> 001703 If _include = "I" Then /* Inclusive values */
> 001704 Return ((_val >= _low) & (_val <= _high));
> 001705 Else /* Exclusive values */
> 001706 Return ((_val > _low) & (_val < _high));
>
But you might also want to support semiopen intervals:
> Thanks for your help here...here is what I wound up with:
>
> 001700 InRange: Procedure; Call Trace("O");
> 001701
> 001702 Parse Arg _val _low _high _include
> 001703 If _include = "I" Then /* Inclusive values */
> 001704 Return ((_val >= _low) & (_val <= _high));
> 001705 Else /* Exclusive values */
> 001706 Return ((_val > _low) & (_val < _high));
>
return ( _low <= _val ) & ( _val < _high )
return ( _low < _val ) & ( _val <= _high )
(I feel this order of operands is more legible)
Useful for partitioning into subranges with no overlap.
Also to support string comparisons ("<<=") vs.
numeric comparisons ( "<=" ), etc. There are too
many variants to handle in a function; perhaps inline
code is better.
-- gil
Ted MacNEIL
Apr 12, 2012, 6:41:07 PM4/12/12
to
>And the answer to your question is yes as I have an intrinsic aversion to
compound conditions - I much prefer to deal with them one at a time.
I prefer them all together, but I will use brackets and white space (and continuations, when required) to ensure legibility.
I want to keep the associated logic all together, finding that breaking it up over multiple IF...THEN constructs confusing.
I tend towards:
IF (
(condition AND condition)
OR
(condition
AND
(condition OR ...)
)
) THEN ...
[As an pseudo code example]
But, to each their own.
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL
compound conditions - I much prefer to deal with them one at a time.
I prefer them all together, but I will use brackets and white space (and continuations, when required) to ensure legibility.
I want to keep the associated logic all together, finding that breaking it up over multiple IF...THEN constructs confusing.
I tend towards:
IF (
(condition AND condition)
OR
(condition
AND
(condition OR ...)
)
) THEN ...
[As an pseudo code example]
But, to each their own.
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL
Vitonis, Tony
Apr 12, 2012, 11:05:39 PM4/12/12
to
If a test is complicated, I like to encapsulate it:
IF LifeIsMeaningful() THEN ...
LifeIsMeaningful:
RETURN /* Some boolean operations here */
It approaches self-documentation, and it can make code maintenance easier by reducing indentation depth and so on. I've been known to break complicated condition routines into subcalls as well, for the same reasons.
-----Original Message-----
From: Ted MacNEIL
Sent: Thursday, April 12, 2012 6:26 PM
To: TSO-...@VM.MARIST.EDU
IF LifeIsMeaningful() THEN ...
LifeIsMeaningful:
RETURN /* Some boolean operations here */
It approaches self-documentation, and it can make code maintenance easier by reducing indentation depth and so on. I've been known to break complicated condition routines into subcalls as well, for the same reasons.
-----Original Message-----
From: Ted MacNEIL
Sent: Thursday, April 12, 2012 6:26 PM
To: TSO-...@VM.MARIST.EDU
Paul Gilmartin
Apr 12, 2012, 11:14:14 PM4/12/12
to
On Apr 12, 2012, at 21:04, Vitonis, Tony wrote:
> If a test is complicated, I like to encapsulate it:
>
> IF LifeIsMeaningful() THEN ...
>
> LifeIsMeaningful:
> RETURN /* Some boolean operations here */
>
> It approaches self-documentation, and it can make code maintenance easier by reducing indentation depth and so on. I've been known to break complicated condition routines into subcalls as well, for the same reasons.
>
Also valuable in allowing incorporation of end-of-file
> If a test is complicated, I like to encapsulate it:
>
> IF LifeIsMeaningful() THEN ...
>
> LifeIsMeaningful:
> RETURN /* Some boolean operations here */
>
> It approaches self-documentation, and it can make code maintenance easier by reducing indentation depth and so on. I've been known to break complicated condition routines into subcalls as well, for the same reasons.
>
test into the loop control:
do while ReadInput( ... )
...
end
(Implementation is left as a homework problem.)
-- gil
Ted MacNEIL
Apr 12, 2012, 11:16:32 PM4/12/12
to
Some would complain about overhead for a call -- I wouldn't.
But, I would still like to keep all references to similar elements, being checked/compared, together.
In other words, if vara and varb are in the predicates (correct term?) keep them within the same encapsulation (as much as possible.
Again, this can (IMO) cause a disconnect, when trying to figure out what the logic is attempting to do.
But, I would still like to keep all references to similar elements, being checked/compared, together.
In other words, if vara and varb are in the predicates (correct term?) keep them within the same encapsulation (as much as possible.
Again, this can (IMO) cause a disconnect, when trying to figure out what the logic is attempting to do.
Walter Pachl
Apr 13, 2012, 9:22:00 AM4/13/12
to
EXECIO 1 is prohibitive performancewise (on MVS/TSO)
I use
Do until src<>0
'EXECIO 1000 DISKR INPUT (STEM L.'
scr=rc
Do i=1 To l.0
Process l.i
End
End
Similar on output...
o.0=0
..
Call o output_line
...
'EXECIO' o.0 'DISKW OU (STEM O. FINIS'; 'FREE FI(OU)'
Exit
o:
If o.0>=1000 Then Do
'EXECIO' o.0 'DISKW OU (STEM O.'
o.0=0
End
z=o.0+1
o.z=arg(1)
o.0=z
Return
---- Adrian Stern <adrian...@TELE2.SE> schrieb:
> Now who else always uses:
>
> Do forever
> Execio 1 diskr input
> If rc<>0 then leave
I use
Do until src<>0
'EXECIO 1000 DISKR INPUT (STEM L.'
scr=rc
Do i=1 To l.0
Process l.i
End
End
Similar on output...
o.0=0
..
Call o output_line
...
'EXECIO' o.0 'DISKW OU (STEM O. FINIS'; 'FREE FI(OU)'
Exit
o:
If o.0>=1000 Then Do
'EXECIO' o.0 'DISKW OU (STEM O.'
o.0=0
End
z=o.0+1
o.z=arg(1)
o.0=z
Return
---- Adrian Stern <adrian...@TELE2.SE> schrieb:
> Now who else always uses:
>
> Do forever
> Execio 1 diskr input
> If rc<>0 then leave
0 new messages