Heretic alert: I really detest TSO REXX (the language)

Discussion:

Heretic alert: I really detest TSO REXX (the language)

(too old to reply)

Kirk Wolf

2018-05-11 15:40:37 UTC

Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.

Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.

I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)

The good:

- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

The bad:

- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

John McKown

2018-05-11 16:06:12 UTC

Post by Kirk Wolf
Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.

ref: http://oorexx.org/docs/rexxref/book1.htm

Post by Kirk Wolf
Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Seymour J Metz

2018-05-11 16:12:34 UTC

I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of John McKown <***@GMAIL.COM>
Sent: Friday, May 11, 2018 12:07 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Kirk Wolf
Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.

ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhOJdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIAnOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVqhlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNLcZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm

Post by Kirk Wolf
Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdyrHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoiNQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39npoYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gntBT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlVkRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5lRuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/http%3A%2F%2Fdovetail.com

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

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

John McKown

2018-05-11 16:34:01 UTC

Post by Seymour J Metz
I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.

I have not reviewed the actual OOREXX source code. If is uses the C
language "fopen()" to open disk files, then it's good. But if it uses the C
language "open()" for disk files; that subroutine does not support z/OS
datasets.

Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.

Maranatha! <><
John McKown

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

Steve Smith

2018-05-11 17:34:39 UTC

Well, if it's "Free-For-All-Friday", I vote for replacing all that crap
with Perl. And I'm sure that PHP and even that snake language have their
fans. Maybe IBM should leave script language design to the wider world.

REXX is adequate for a lot of things, but the // and % operators just make
me mad.

sas

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

David Crayford

2018-05-11 18:26:59 UTC

I would have to respectfully disagree. PHP is the worst designed
programming language ever and perl isn't much better. Perl excels at one
thing, regular expressions. Its syntax is ugly
and it suffers from language bloat. I dislike Ruby because it has
borrowed many of the "multiple ways to do things" bloat from Perl.

As it's Friday we can all have a laugh at the fact that PHP function
names were specifically chosen because they were hashed using strlen()
:) [1]

[1] https://news.ycombinator.com/item?id=6919216

Post by Steve Smith
Well, if it's "Free-For-All-Friday", I vote for replacing all that crap
with Perl. And I'm sure that PHP and even that snake language have their
fans. Maybe IBM should leave script language design to the wider world.
REXX is adequate for a lot of things, but the // and % operators just make
me mad.
sas
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Seymour J Metz

2018-05-13 19:31:29 UTC

We all have our favorite candidates for worst language ever. I lean to C, but there are other worthy contestants.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of David Crayford <***@gmail.com>
Sent: Friday, May 11, 2018 2:28 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

I would have to respectfully disagree. PHP is the worst designed
programming language ever and perl isn't much better. Perl excels at one
thing, regular expressions. Its syntax is ugly
and it suffers from language bloat. I dislike Ruby because it has
borrowed many of the "multiple ways to do things" bloat from Perl.

As it's Friday we can all have a laugh at the fact that PHP function
names were specifically chosen because they were hashed using strlen()
:) [1]

[1] https://secure-web.cisco.com/1GnDI9B4K4ayPdu-mY7uKBpAHE3k7ktk8k8vMSwnZA5GHwdu-hjoaS49d3tn85wUTPfB4G9dtpSrJ3ooc4iqr8cAEsQ_kCEz3dIOt1wCfjZlnEJrCW-X5Sr40vqRfYhVMhPF48nwds3borNIxCAeNw8UI-NbiJXzW0Y2jgcHn9-112mRS-oXxEhzmwNW2duiMYvF4FgfjiaYvGxGpr3RtxcD1jswd2G3vEVj1Dy8iuSvRoDqeAN_NCRPi9zmnigxWi80TUVfaaTXZwVjBrXBWgd85695K0koyBtgGYCzpgaASidQeeCjdx0G-llRL0GPjvfXUWgcb1eNStjRwqlhpwJZ7Aasl2VI9yq3AxIE94n23jVG6j4-zt_CDi88EqG3C9QVvuuiBPzB0SzXnM-_WOg/https%3A%2F%2Fnews.ycombinator.com%2Fitem%3Fid%3D6919216

Post by Steve Smith
Well, if it's "Free-For-All-Friday", I vote for replacing all that crap
with Perl. And I'm sure that PHP and even that snake language have their
fans. Maybe IBM should leave script language design to the wider world.
REXX is adequate for a lot of things, but the // and % operators just make
me mad.
sas
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

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

Seymour J Metz

2018-05-13 19:38:42 UTC

I feel compelled to use Perl because of its expressive power and the massive library available at CPAN, but I consider it ugly. I'd really prefer a language with regex syntax for people who aren't limited to slow teletypes, more in the style of ICON, SNOBOL or Wylbur.

As for REXX, it is a very clean language for scripting OS commands, and acceptable for more complicated tasks. I just wish that IBM, having invented OREXX, would bring OOREXX into the z fold.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Steve Smith <***@gmail.com>
Sent: Friday, May 11, 2018 1:35 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Well, if it's "Free-For-All-Friday", I vote for replacing all that crap
with Perl. And I'm sure that PHP and even that snake language have their
fans. Maybe IBM should leave script language design to the wider world.

REXX is adequate for a lot of things, but the // and % operators just make
me mad.

sas

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

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

David Crayford

2018-05-11 18:29:42 UTC

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's because
of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

Post by Seymour J Metz
I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Friday, May 11, 2018 12:07 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Kirk Wolf
Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.
ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhOJdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIAnOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVqhlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNLcZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm

Post by Kirk Wolf
Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdyrHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoiNQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39npoYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gntBT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlVkRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5lRuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/http%3A%2F%2Fdovetail.com

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Kirk Wolf

2018-05-11 19:01:03 UTC

It would be nice to have a choice of scripting languages like on other
platforms.

Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
interface for invoking a "command" in an arbitrary scripting language and
then providing it with a command processing (and/or ISPF) interface?

What if the TSO command interface that handles REXX/CLIST could recognize
shebangs to support other script processors, which would be local-spawned
in the TSO address space and be given a TSO Command processing environment?

Who knows, maybe get crazy and allow TSO command/script processing from
zFS. With mixed case > 8 characters!

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

I'm at a loss as to why anybody would use OOREXX on platforms where there
are a multitude of better languages to chose from. If it's because of
familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern scripting
languages can be picked up in less then a day.

Post by Seymour J Metz
I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Friday, May 11, 2018 12:07 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)
Yeah, I said it. I remember how fond I was of REXX when I first

Post by Kirk Wolf
discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)
TSO REXX needs to be allowed to quietly retire to a placid village

somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.
ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhO
Jdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIA
nOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVq
hlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI
8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8
wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNL
cZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-
hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/
http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm
Kirk Wolf

Post by Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdy
rHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoi
NQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39n
poYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gnt
BT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlV
kRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5l
RuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4
s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/
http%3A%2F%2Fdovetail.com
--

We all have skeletons in our closet.
Mine are so old, they have osteoporosis.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Dyck, Lionel B. , TRA

2018-05-11 19:04:10 UTC

Couldn't you do Address XYZ and then have commands that XYZ understands?

--------------------------------------------------------------------------
Lionel B. Dyck (Contractor) <sdg><
Mainframe Systems Programmer – RavenTek Solution Partners

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf
Sent: Friday, May 11, 2018 2:02 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

It would be nice to have a choice of scripting languages like on other
platforms.

Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
interface for invoking a "command" in an arbitrary scripting language and
then providing it with a command processing (and/or ISPF) interface?

What if the TSO command interface that handles REXX/CLIST could recognize
shebangs to support other script processors, which would be local-spawned
in the TSO address space and be given a TSO Command processing environment?

Who knows, maybe get crazy and allow TSO command/script processing from
zFS. With mixed case > 8 characters!

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

I'm at a loss as to why anybody would use OOREXX on platforms where there
are a multitude of better languages to chose from. If it's because of
familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern scripting
languages can be picked up in less then a day.

Post by Seymour J Metz
I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Friday, May 11, 2018 12:07 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)
Yeah, I said it. I remember how fond I was of REXX when I first

Post by Kirk Wolf
discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)
TSO REXX needs to be allowed to quietly retire to a placid village

somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.
ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhO
Jdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIA
nOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVq
hlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI
8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8
wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNL
cZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-
hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/
http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm
Kirk Wolf

Post by Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdy
rHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoi
NQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39n
poYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gnt
BT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlV
kRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5l
RuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4
s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/
http%3A%2F%2Fdovetail.com
--

We all have skeletons in our closet.
Mine are so old, they have osteoporosis.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

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

Tony Harminc

2018-05-11 22:50:25 UTC

Post by Kirk Wolf
Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
interface for invoking a "command" in an arbitrary scripting language and
then providing it with a command processing (and/or ISPF) interface?

Yes. This is particularly a problem if you want to run APF authorized
things from within your scripting language environment.

Post by Kirk Wolf
What if the TSO command interface that handles REXX/CLIST could recognize
shebangs to support other script processors, which would be local-spawned
in the TSO address space and be given a TSO Command processing environment?

Well it's almost there, with some annoyances that IBM could fix if
they wanted to. The interface designed to support compiled REXX looks
for a magic string at a fixed position in the first record, and will
then invoke a routine named later in that same record. So it *should*
be possible for the language to not be REXX, if it can get past a few
basic syntax things.

This is described in some pretty good detail in the TSO/E
Customization book. It even has its own chapter (43 currently).

You can see this in (failing) action by creating an "exec" with a
first line like
EXECPROCBADMODUL
where the "EXECPROC" starts in column 5. Then run it and you'll get an
interesting message.

Post by Kirk Wolf
Who knows, maybe get crazy and allow TSO command/script processing from
zFS. With mixed case > 8 characters!

When you say "from zFS", I'm not quite sure what you mean. You want to type
/u/kirk/myscript
and have it look for the shebang and call the appropriate runtime?
Hmmm... I think that could be accomplished with a drop-in modification
to TSO's IKJSCAN. But of course you're going to want it to work from
ISPF and such, so not quite so simple.

Tony H.

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

Seymour J Metz

2018-05-13 19:20:02 UTC

REXX already supports issuing authorized commands for supported environments, e.g., TSO. It's not particularly difficult to add a new environment to REXX, but executing APF authorized commands safely in that environment is not for the faint of heart.

OS/2 has something similar to shebang called EXTPROC. I agree that shebang support for TSO would be nice.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tony Harminc <***@HARMINC.NET>
Sent: Friday, May 11, 2018 6:51 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Kirk Wolf
Isn't a big obstacle on z/OS the fact that TSO doesn't have a generalized
interface for invoking a "command" in an arbitrary scripting language and
then providing it with a command processing (and/or ISPF) interface?

Yes. This is particularly a problem if you want to run APF authorized
things from within your scripting language environment.

Post by Kirk Wolf
What if the TSO command interface that handles REXX/CLIST could recognize
shebangs to support other script processors, which would be local-spawned
in the TSO address space and be given a TSO Command processing environment?

Well it's almost there, with some annoyances that IBM could fix if
they wanted to. The interface designed to support compiled REXX looks
for a magic string at a fixed position in the first record, and will
then invoke a routine named later in that same record. So it *should*
be possible for the language to not be REXX, if it can get past a few
basic syntax things.

This is described in some pretty good detail in the TSO/E
Customization book. It even has its own chapter (43 currently).

You can see this in (failing) action by creating an "exec" with a
first line like
EXECPROCBADMODUL
where the "EXECPROC" starts in column 5. Then run it and you'll get an
interesting message.

Post by Kirk Wolf
Who knows, maybe get crazy and allow TSO command/script processing from
zFS. With mixed case > 8 characters!

When you say "from zFS", I'm not quite sure what you mean. You want to type
/u/kirk/myscript
and have it look for the shebang and call the appropriate runtime?
Hmmm... I think that could be accomplished with a drop-in modification
to TSO's IKJSCAN. But of course you're going to want it to work from
ISPF and such, so not quite so simple.

Tony H.

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

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

Seymour J Metz

2018-05-13 19:28:03 UTC

I'm at a loss as to why anybody would pay good money for cheese, given that the Moon is made of the stuff. It's hard to understand the reason for something when it isn't true in the first place. The fact that you prefer other languages doesn't make them better.

Is REXX perfect? No way. But then, no language is. REXX has its strengths and its weaknesses. It's much cleaner than its competitors for scripting OS commands, but other languages have more expressive power and decent scoping rules.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
http://www.rexxla.org/Newsletter/9812safe.html
http://www.rexxla.org/Newsletter/9901safe.html

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of David Crayford <***@gmail.com>
Sent: Friday, May 11, 2018 2:30 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's because
of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

Post by Seymour J Metz
I/O? The ANSI stream I/O functions are in OOREXX, as are equivalent methods.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Friday, May 11, 2018 12:07 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Kirk Wolf
Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

TSO REXX needs to be allowed to quietly retire to a placid village
somewhere; turning the reigns of scripting on TSO & UNIX to "Object
Oriented REXX" (oorexx). Of course OOREXX would need to be enhanced with
the addition of ADDRESS TSO and ADDRESS SYSCALL as well as some way to do
I/O to z/OS data sets. I don't really care for EXECIO, but it is
acceptable.
ref: http://secure-web.cisco.com/1h-uqbWNXqq1CuCFKDqzvqcBgRLzHQhOJdj2QPbZDjibdycV5-gSQ4zBsxF-ySP4yE3Gnt8Ci7-gFOQl1o0QfWxnGLIAnOWtWwjFiWyUO6_oelF6zzlfdVJQGh93pcQfmj1CKFH1yFltii1H6D55GHVqhlsQI5G4T4c_fzxq5jUS8tGqqG5f8RAtojricobH62fLXMveqVtA58NnnyEI8J5ZFDLn1euLi04N_1B_wwkslkM66qjWZUUUgKLQa9ysGVaz_dSEPSqD4Jy8wDlXsjlYE5gs0zv8KMeW2NdylohDK5PH2h3D1BO5nS9Xy3MWHsivQyqjUZNLcZBpCljXLtIOX4npezWZi40DpWGg9OVec3RcKEsxRLjrx3H32tSLSPkiR-hnnC1DcEu-XXmWaxCqwWfEkmVEWQrN7qwdK2pu0XeO_qZ8uCxzHK_BzA7cQ/http%3A%2F%2Foorexx.org%2Fdocs%2Frexxref%2Fbook1.htm

Post by Kirk Wolf
Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1n0sGnuNhDW6q3fXx-PJT_zwbOkG5mdyrHujXRMNNl7mvKl5Xve_kqaLCr4c3THMnMEdrV1yAhJRWqk6ztNUqrFGZvoiNQUVtP_xSkRVWaaTzYQQvCyTbvlkQUXPnknsR22cMBQJERLsge_SWbQFs39npoYpHo3efptLwktjYxH3NX8PAK9oDvUHPpLBqrimbXG8ywzzNV_DFiUG3gntBT0E1P2p_TPl3grRW6PItAqncbeCMmsAOSgxehPiM6Jec5-t7r-EFbUooKlVkRd4jIoPs_SxfEXReTOJgloSU0-j82q4DY4B55eBqk1u4fT50E_97OkQxn5lRuHL36Xe3703XiFulTeLHG6xt1WgwuuybblSE2xcKi8oypvdR_E7UCmPexg4s8B8tstAk46elSl1OOCp4v7P4IKI2PwnsqKSsW93XDy3XJIQOALSAmaEO/http%3A%2F%2Fdovetail.com

--
We all have skeletons in our closet.
Mine are so old, they have osteoporosis.
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

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

Seymour J Metz

2018-05-11 16:22:50 UTC

Actually, CLIST can do some things that REXX can't, although on balance I'll take REXX over CLIST, EXEC or EXCE2.

I find REXX much friendlier than any Unix shell, although bash certainly has some things that REXX needs. IBM: why haven't you added all of the ANSI extensions to REXX?

See my "Safe REXX" article from the last century.

I'm relying heavily on Perl, because of regexen and CPAN, and there are many things that are much cleaner in REXX.

Add to your bad list:

looks a lot like PL/I, but PL/I habits will get you in trouble. And, no, SIGNAL is not a goto and is a booby trap for the unwary.

And, yes, it is long past time for IBM to upgrade TSO REXX to OOREXX, or at least ANSI REXX.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Kirk Wolf <***@DOVETAIL.COM>
Sent: Friday, May 11, 2018 11:41 AM
To: IBM-***@listserv.ua.edu
Subject: Heretic alert: I really detest TSO REXX (the language)

Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.

Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.

I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)

The good:

- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

The bad:

- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

Kirk Wolf
Dovetailed Technologies
http://secure-web.cisco.com/1sCovw_caeZCTiKKtwKM6KRqfReM5pqylWtuvk1WwFDPKPskPZj1hu1_JrFVbwdNQfWij5DzJGZ4GVtjiTXmvZJJHbxLgTfQem4eYseB1CJo1utY4r-0e5vb9C6Duqr9ipvP1TNN5Cf1JYJA4Pqw_VOPfp-9h5bJN-nXwm8QMFXoFe3pxze54XYnZAh0bsuT2S0_B0loJk6BL-cnC8QUoyYo2IyZM1iqTrJLeMUxQ3uLO8lpTjvbnaF51EfzDkdp-E4oEnOBN03c0CPFarq_bG9q0ooIn0E7x7dcozCPHAi2V7--SBonkXru9OIaeQcQwciQ7Pkz33s2xUeqv0fN3uGeMe9UBnucjGHZkPwJ7FR9ekbl9Ele2EAYre-rnt-Y2NjrWRDBKjNmUJQEELWilx84BgJh7GJ_ghLn4pmAs7yUz3-93Ux4PuFrABtv_E2dG/http%3A%2F%2Fdovetail.com

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

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

Paul Gilmartin

2018-05-11 16:24:06 UTC

Post by Kirk Wolf
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

Sort of, or inconsistently. Simple symbols are case-insensitive; derived names
or compound symbols are case-sensitive.

Post by Kirk Wolf
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

My list, considerably overlapping yours:

Shortcomings:
No expressions in compound tails
No sharing variables between EXECs
No call by reference
No COPY/INCLUDE/SOURCE facility
No longITERATE/longLEAVE
No instream data facility (here-document)

-- gil

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

Seymour J Metz

2018-05-13 19:58:39 UTC

All symbols are case insensitive. Talis are case sensivtive:

bar='baz'
say f.bar
say foo.BAR
say FOO.bar
say FOO.BAR

will give 4 identical outputs, but change that first line to bar='BAZ' and you're talking about a different variable.

You can use the value BIF to get expressions in tails: x =value('foo.'bar'2')

WTF is a "longITERATE" or a "longLEAVE"?

Admittedly I use here documents in Perl, but I'm not a big fan of them.

Why can't IBM implement GLOBALV in TSO?

If IBM would be up OOREXX some of your other issues would be addressed.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Friday, May 11, 2018 12:25 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Kirk Wolf
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)

Sort of, or inconsistently. Simple symbols are case-insensitive; derived names
or compound symbols are case-sensitive.

Post by Kirk Wolf
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)

My list, considerably overlapping yours:

Shortcomings:
No expressions in compound tails
No sharing variables between EXECs
No call by reference
No COPY/INCLUDE/SOURCE facility
No longITERATE/longLEAVE
No instream data facility (here-document)

-- gil

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

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

David Crayford

2018-05-11 18:20:59 UTC

That's a fine curated list of the bad points of REXX. If I may add that
only having one data type, the string, is not the killer feature that
people laud it to be. As you mentioned, compound varibles
being the only data structure REXX is a problem in todays world. Try
serializing a REXX array into JSON.

Lack of variable scoping is one of my biggest gripes. It means REXX
doesn't scale. Of course, you can add "procedure expose" to functions
but that soon turns into an intractable mess.

I discovered just how slow REXX is when I first started using Lua on
z/OS. Programs that were running sub-second in Lua were taking 40
seconds in REXX! Once I ported the Lua I/O standard
library to z/OS it handled all the file systems and data sets types that
C stdio supports, PS, VSAM, UNIX, hiperspace etc. The fact that REXX
does not have native support for VSAM data sets
is a shocking omission. And other features like multi-threading are pipe
dreams in REXX.

Post by Kirk Wolf
Yeah, I said it. I remember how fond I was of REXX when I first discovered
it VM/CMS in the 1980s, when big hair and mullets were also great.
Sure, on the surface it seems like a user friendly scripting language, but
IMO that is only true if you compare it to JCL, CLIST, RPGII, and Windows
"BAT". It does look much easier than the classic Unix shell, but not so
much in practice.
I recognize that many here have learned it really well and don't have to
think about all of the pitfalls and landmines. But please don't try to
tell new mainframers who have learned modern scripting languages how nice
it is :-)
- it is on every z/OS system, and it has a good set of system interfaces
("environments")
- it does have case-sensitive variable names, which maybe some people don't
like ;-)
- a single data type (string)
- limited control flow statements; lack of short-cut boolean expressions
- compound variables - the only data structure you'll ever need?
- weird handling of undefined/omitted variables/args
- variable name scopes?
- packages/namespaces/libraries?
- purports to follow the principle of "least surprise", but I often find
the opposite
- slow (although that really isn't a language criticism)
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Tony Thigpen

2018-05-11 22:21:42 UTC

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

No sharing variables between EXECs

This is available on s/VM. (If you know what you are doing.) I don't
know if it will work on s/VSE or z/OS. It's use is considered
'non-standard' and usually avoided. Because of that, it's not something
that is obvious in the documentation but once someone shows you how to
do it, you will say 'why did I not see that'.

REXX is adequate for a lot of things, but the // and % operators
just make me mad

Every language has it's syntax. Maybe I would have picked something
else, but it is reasonable.

Lack of variable scoping is one of my biggest gripes. It means
REXX doesn't scale. Of course, you can add "procedure expose"
to functions but that soon turns into an intractable mess.

I disagree. This sounds more like you are trying to use programming
habits/methods designed for another language. Any programming 'language'
should be used as it was designed, not as some other 'language' was
designed. Are you trying to make REXX look like Perl, Java, PHP or bash?

Perl excels at one thing, regular expressions. Its syntax is ugly
and it suffers from language bloat.

I equate regular expressions with vi. It takes a lot of use to get where
you can use it without looking things up, and if you get to that point,
you have lived a hard life. :-)

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's
because of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

And the code produced is usually crap for the first 5,000 or 10,000
lines of code written in a new language. I had rather know a few
languages well than many languages 'so-so'. Bringing your existing
skills into play is always a good thing. Bringing your poor skills into
play for a production code is just stupid. (I am not against using your
poorer skills for one-off, one-time use code. That is the best place to
learn new skills.)

After all the cut-n-paste, I noticed that the biggest complainer is
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and ....

Tony Thigpen

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

David Crayford

2018-05-12 02:08:18 UTC

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.

Post by Tony Thigpen

Lack of variable scoping is one of my biggest gripes. It means
REXX doesn't scale. Of course, you can add "procedure expose"
to functions but that soon turns into an intractable mess.

I disagree. This sounds more like you are trying to use programming
habits/methods designed for another language. Any programming
'language' should be used as it was designed, not as some other
'language' was designed. Are you trying to make REXX look like Perl,
Java, PHP or bash?

Not at all! My opinion is based upon 30+ years of using REXX. The
inability to pass aggregate types (objects) in REXX (stem variables) to
functions makes it unsuitable for large programs. This is especially
true for external functions.
REXX also lacks modules or packages so reusing code is hard. The "expose
stem." construct doesn't cut it IMO. Once the code grows large it takes
a lot of mental gymnastics to remember what's been exposed. Lexical
scoping is
an absolute must in modern programming languages.

Post by Tony Thigpen

Perl excels at one thing, regular expressions. Its syntax is ugly
and it suffers from language bloat.

I equate regular expressions with vi. It takes a lot of use to get
where you can use it without looking things up, and if you get to that
point, you have lived a hard life. :-)

I have to admit that the parse instruction in REXX is elegant and one of
it's redeeming features. But it lacks the power of regular expressions.
I missed regular expressions in REXX so much I wrote a command processor
[1].
Extending REXX is difficult and requires writing assembler code. In the
case of my regex API I needed to use CEEPIPI to glue together the
assembler code and LE C++ code. Extending languages like Python, Ruby,
Lua, Node.js
is trivial in comparison. But of course the language bindings for those
languages are written in C/C++, which is ok for me as I know those
languages.

[1] https://github.com/daveyc/RTK

Post by Tony Thigpen

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's
because of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

And the code produced is usually crap for the first 5,000 or 10,000
lines of code written in a new language. I had rather know a few
languages well than many languages 'so-so'. Bringing your existing
skills into play is always a good thing. Bringing your poor skills
into play for a production code is just stupid. (I am not against
using your poorer skills for one-off, one-time use code. That is the
best place to learn new skills.)

But with modern languages you have to write less code. There are
libraries to do just about everything you can imagine. I was reading
about the new web services for REXX to create JSON. It really did hammer
home
just how difficult it is to do things in REXX that is one line of code
in modern languages. And to install libraries in modern languages you
use an installer like pip, gem, npm, luarocks which takes care of
dependencies etc.
It's a cliche but if the only tool you have is a hammer the whole world
looks like a nail.

Post by Tony Thigpen
After all the cut-n-paste, I noticed that the biggest complainer is
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and ....

I hate Perl and PHP too. I'm not a fan of Ruby either. I don't much like
C but it's a useful language to know.
I have been accused before on this list of pathologically hating REXX.
That's not true, I appreciate it for what it's good at. But I have found
over the years that I prefer other languages. I'm a software developer
and write
code for a living so having the best tools available is important to me.

Post by Tony Thigpen
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Farley, Peter x23353

2018-05-12 16:52:26 UTC

Rexx does have several versions of VSAM support, though none from IBM. Quoting from the website of the late Gilbert St. Fleur (http://gsf-soft.com/Documents/TSOVSAM.html):

Several RXVSAM programs are available, all of them are free:

1.Written and supported by Mark Winges, in file 268 of the CBT Tape. (http://cbttape.org/ftp/cbt/CBT268.zip)
2.Written and supported by Steven Scott, found here. (http://sourceforge.net/projects/rxvsam/)
3.There is a read-only VSAM function package, also called RXVSAM, in the VSAM section of the Xephon archives. (http://www.xephon.com/archives/a012a01.txt)
4. The EXECIOVS program, found on the HiLMAs web site, provides an EXECIO-like interface to VSAM data sets in REXX.

HTH

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Crayford
Sent: Friday, May 11, 2018 10:10 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

EXTERNAL EMAIL

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.

<Snipped>
--

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.

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

Tony Thigpen

2018-05-12 17:27:55 UTC

The real question is:

Why are z/OS developers unable to lower themselves and ask the z/VSE
developers to share their REXX VSAMIO code?

And, while they are at it, they could also borrow the REXX SORTSTEM
function from z/VSE.

These have been there since 2003 (or earlier). The code can't be that
different between the operating systems. I know the VSAMIO code
(ARXVCSTB) is C based so it should just be a recompile.

Tony Thigpen

Post by Farley, Peter x23353
1.Written and supported by Mark Winges, in file 268 of the CBT Tape. (http://cbttape.org/ftp/cbt/CBT268.zip)
2.Written and supported by Steven Scott, found here. (http://sourceforge.net/projects/rxvsam/)
3.There is a read-only VSAM function package, also called RXVSAM, in the VSAM section of the Xephon archives. (http://www.xephon.com/archives/a012a01.txt)
4. The EXECIOVS program, found on the HiLMAs web site, provides an EXECIO-like interface to VSAM data sets in REXX.
HTH
Peter
-----Original Message-----
Sent: Friday, May 11, 2018 10:10 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)
EXTERNAL EMAIL

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.
<Snipped>
--
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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Steve Horein

2018-05-12 18:47:44 UTC

... or port the NetView *for z/OS* suite of Rexx functions over to TSO.
NetView PIPEs offer a lot of functionality/enhancements to the Rexx
language.

Post by Tony Thigpen
Why are z/OS developers unable to lower themselves and ask the z/VSE
developers to share their REXX VSAMIO code?
And, while they are at it, they could also borrow the REXX SORTSTEM
function from z/VSE.
These have been there since 2003 (or earlier). The code can't be that
different between the operating systems. I know the VSAMIO code (ARXVCSTB)
is C based so it should just be a recompile.
Tony Thigpen

Post by Farley, Peter x23353
Rexx does have several versions of VSAM support, though none from IBM.
Quoting from the website of the late Gilbert St. Fleur (
1.Written and supported by Mark Winges, in file 268 of the CBT Tape. (
http://cbttape.org/ftp/cbt/CBT268.zip)
2.Written and supported by Steven Scott, found here. (
http://sourceforge.net/projects/rxvsam/)
3.There is a read-only VSAM function package, also called RXVSAM, in the
VSAM section of the Xephon archives. (http://www.xephon.com/archive
s/a012a01.txt)
4. The EXECIOVS program, found on the HiLMAs web site, provides an
EXECIO-like interface to VSAM data sets in REXX.
HTH
Peter
-----Original Message-----
Behalf Of David Crayford
Sent: Friday, May 11, 2018 10:10 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)
EXTERNAL EMAIL

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.
<Snipped>
--
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.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Seymour J Metz

2018-05-13 19:15:14 UTC

OOREXX solves many of the problems in classic REXX.

I never found writing REXX function packages to be difficult.

I don't care for Perl syntax, but between its expressive power and the massive CPAN I find myself using it regardless.

That said, I find that REXX has a much cleaner syntax for scripting OS commands

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
http://www.rexxla.org/Newsletter/9812safe.html
http://www.rexxla.org/Newsletter/9901safe.html

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of David Crayford <***@GMAIL.COM>
Sent: Friday, May 11, 2018 10:09 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.

Post by Tony Thigpen

Lack of variable scoping is one of my biggest gripes. It means
REXX doesn't scale. Of course, you can add "procedure expose"
to functions but that soon turns into an intractable mess.

I disagree. This sounds more like you are trying to use programming
habits/methods designed for another language. Any programming
'language' should be used as it was designed, not as some other
'language' was designed. Are you trying to make REXX look like Perl,
Java, PHP or bash?

Not at all! My opinion is based upon 30+ years of using REXX. The
inability to pass aggregate types (objects) in REXX (stem variables) to
functions makes it unsuitable for large programs. This is especially
true for external functions.
REXX also lacks modules or packages so reusing code is hard. The "expose
stem." construct doesn't cut it IMO. Once the code grows large it takes
a lot of mental gymnastics to remember what's been exposed. Lexical
scoping is
an absolute must in modern programming languages.

Post by Tony Thigpen

Perl excels at one thing, regular expressions. Its syntax is ugly
and it suffers from language bloat.

I equate regular expressions with vi. It takes a lot of use to get
where you can use it without looking things up, and if you get to that
point, you have lived a hard life. :-)

I have to admit that the parse instruction in REXX is elegant and one of
it's redeeming features. But it lacks the power of regular expressions.
I missed regular expressions in REXX so much I wrote a command processor
[1].
Extending REXX is difficult and requires writing assembler code. In the
case of my regex API I needed to use CEEPIPI to glue together the
assembler code and LE C++ code. Extending languages like Python, Ruby,
Lua, Node.js
is trivial in comparison. But of course the language bindings for those
languages are written in C/C++, which is ok for me as I know those
languages.

[1] https://secure-web.cisco.com/1hl2S1kpirFFJW9IvenEuaa4EAGxduLA8veYSk-oplRc6Kst7sAdKMuWYMRxwh9TxWDln5kMQtW4nFoVsM6fNGpYmpBnRSL6ok280lKYp25zEIK4njlXHFylhgoLjzzJD9dGWh2Bmk0bTKbkne1Ycwn3JnZY7ugfrWBToNL2__OfEaFxvtYiP9c29Lpg_sb-BwxmDSmQEUnyn5vldeqVaeuaT3k2GX-M8WtSK7TJ8rAlDvXLD8FLIgnjdh_egoly8LgYVNjgLfraPfIFxepNbD6ZVziom8nUgvP2GNxJNfpQNp0PombTDtVzJnVtLsYeeRCCqQdkXiepdzXKAvrjaVdVE1lX2oA3YgQjfGxxdOEtDIQsG-wGayObGxLUDx8X0xGI53_kCoAYXlQppYqpVhg/https%3A%2F%2Fgithub.com%2Fdaveyc%2FRTK

Post by Tony Thigpen

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's
because of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

And the code produced is usually crap for the first 5,000 or 10,000
lines of code written in a new language. I had rather know a few
languages well than many languages 'so-so'. Bringing your existing
skills into play is always a good thing. Bringing your poor skills
into play for a production code is just stupid. (I am not against
using your poorer skills for one-off, one-time use code. That is the
best place to learn new skills.)

But with modern languages you have to write less code. There are
libraries to do just about everything you can imagine. I was reading
about the new web services for REXX to create JSON. It really did hammer
home
just how difficult it is to do things in REXX that is one line of code
in modern languages. And to install libraries in modern languages you
use an installer like pip, gem, npm, luarocks which takes care of
dependencies etc.
It's a cliche but if the only tool you have is a hammer the whole world
looks like a nail.

Post by Tony Thigpen
After all the cut-n-paste, I noticed that the biggest complainer is
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and ....

I hate Perl and PHP too. I'm not a fan of Ruby either. I don't much like
C but it's a useful language to know.
I have been accused before on this list of pathologically hating REXX.
That's not true, I appreciate it for what it's good at. But I have found
over the years that I prefer other languages. I'm a software developer
and write
code for a living so having the best tools available is important to me.

Post by Tony Thigpen
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

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

David Crayford

2018-05-14 05:51:34 UTC

Post by Seymour J Metz
OOREXX solves many of the problems in classic REXX.

And it retains many of them. Like being typeless and lacking lexical
scoping.

Post by Seymour J Metz
I never found writing REXX function packages to be difficult.

Maybe not difficult for some but it's significantly more complex when
compared to writing language bindings for modern languages. You have to
write some of the code in Assembler whether you like it or not. If you
require an LE environment you have to write glue code
using CEEPIPI. For most of the stuff I'm interested in I require LE
because I want to bind C++ libraries. REXX function packages seem
promising but retaining state is tricky and requires stashing an
environment pointer using name/token services.
Not to mention function names are limited to a maximum of 8 characters!
Better to use a command processor environment, but then you have to
write a command parser. Been there, done that it's a lot of work.

Now compare that to Lua where the entire I/O package in the standard
library is less than 1000 lines of code [1]

[1] https://github.com/lua/lua/blob/master/liolib.c*.*

Post by Seymour J Metz
I don't care for Perl syntax, but between its expressive power and the massive CPAN I find myself using it regardless.

I can do without the expressive power of Perl! It shone briefly as a CGI
language and it's good for text processing but with the emergence of
powerful PEG parser libraries [1] I can easily do more with less using
much cleaner languages.

[1] http://www.igordejanovic.net/Arpeggio/grammars/
      https://github.com/pegjs/pegjs
      http://www.inf.puc-rio.br/~roberto/lpeg/
      https://github.com/evanphx/kpeg

Post by Seymour J Metz
That said, I find that REXX has a much cleaner syntax for scripting OS commands

Agreed. Processing command strings is much cleaner in REXX then any
other language I know. But not by much.

Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
http://www.rexxla.org/Newsletter/9812safe.html
http://www.rexxla.org/Newsletter/9901safe.html
________________________________________
Sent: Friday, May 11, 2018 10:09 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.

Post by Tony Thigpen

Lack of variable scoping is one of my biggest gripes. It means
REXX doesn't scale. Of course, you can add "procedure expose"
to functions but that soon turns into an intractable mess.

I disagree. This sounds more like you are trying to use programming
habits/methods designed for another language. Any programming
'language' should be used as it was designed, not as some other
'language' was designed. Are you trying to make REXX look like Perl,
Java, PHP or bash?

Not at all! My opinion is based upon 30+ years of using REXX. The
inability to pass aggregate types (objects) in REXX (stem variables) to
functions makes it unsuitable for large programs. This is especially
true for external functions.
REXX also lacks modules or packages so reusing code is hard. The "expose
stem." construct doesn't cut it IMO. Once the code grows large it takes
a lot of mental gymnastics to remember what's been exposed. Lexical
scoping is
an absolute must in modern programming languages.

Post by Tony Thigpen

Perl excels at one thing, regular expressions. Its syntax is ugly
and it suffers from language bloat.

I equate regular expressions with vi. It takes a lot of use to get
where you can use it without looking things up, and if you get to that
point, you have lived a hard life. :-)

I have to admit that the parse instruction in REXX is elegant and one of
it's redeeming features. But it lacks the power of regular expressions.
I missed regular expressions in REXX so much I wrote a command processor
[1].
Extending REXX is difficult and requires writing assembler code. In the
case of my regex API I needed to use CEEPIPI to glue together the
assembler code and LE C++ code. Extending languages like Python, Ruby,
Lua, Node.js
is trivial in comparison. But of course the language bindings for those
languages are written in C/C++, which is ok for me as I know those
languages.
[1] https://secure-web.cisco.com/1hl2S1kpirFFJW9IvenEuaa4EAGxduLA8veYSk-oplRc6Kst7sAdKMuWYMRxwh9TxWDln5kMQtW4nFoVsM6fNGpYmpBnRSL6ok280lKYp25zEIK4njlXHFylhgoLjzzJD9dGWh2Bmk0bTKbkne1Ycwn3JnZY7ugfrWBToNL2__OfEaFxvtYiP9c29Lpg_sb-BwxmDSmQEUnyn5vldeqVaeuaT3k2GX-M8WtSK7TJ8rAlDvXLD8FLIgnjdh_egoly8LgYVNjgLfraPfIFxepNbD6ZVziom8nUgvP2GNxJNfpQNp0PombTDtVzJnVtLsYeeRCCqQdkXiepdzXKAvrjaVdVE1lX2oA3YgQjfGxxdOEtDIQsG-wGayObGxLUDx8X0xGI53_kCoAYXlQppYqpVhg/https%3A%2F%2Fgithub.com%2Fdaveyc%2FRTK

Post by Tony Thigpen

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's
because of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

And the code produced is usually crap for the first 5,000 or 10,000
lines of code written in a new language. I had rather know a few
languages well than many languages 'so-so'. Bringing your existing
skills into play is always a good thing. Bringing your poor skills
into play for a production code is just stupid. (I am not against
using your poorer skills for one-off, one-time use code. That is the
best place to learn new skills.)

But with modern languages you have to write less code. There are
libraries to do just about everything you can imagine. I was reading
about the new web services for REXX to create JSON. It really did hammer
home
just how difficult it is to do things in REXX that is one line of code
in modern languages. And to install libraries in modern languages you
use an installer like pip, gem, npm, luarocks which takes care of
dependencies etc.
It's a cliche but if the only tool you have is a hammer the whole world
looks like a nail.

Post by Tony Thigpen
After all the cut-n-paste, I noticed that the biggest complainer is
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and ....

I hate Perl and PHP too. I'm not a fan of Ruby either. I don't much like
C but it's a useful language to know.
I have been accused before on this list of pathologically hating REXX.
That's not true, I appreciate it for what it's good at. But I have found
over the years that I prefer other languages. I'm a software developer
and write
code for a living so having the best tools available is important to me.

Post by Tony Thigpen
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Seymour J Metz

2018-05-14 19:54:06 UTC

You have to write some of the code in Assembler whether you like it or not.

As it happens, I like.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of David Crayford <***@GMAIL.COM>
Sent: Monday, May 14, 2018 1:52 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

OOREXX solves many of the problems in classic REXX.

And it retains many of them. Like being typeless and lacking lexical
scoping.

I never found writing REXX function packages to be difficult.

Maybe not difficult for some but it's significantly more complex when
compared to writing language bindings for modern languages. You have to
write some of the code in Assembler whether you like it or not. If you
require an LE environment you have to write glue code
using CEEPIPI. For most of the stuff I'm interested in I require LE
because I want to bind C++ libraries. REXX function packages seem
promising but retaining state is tricky and requires stashing an
environment pointer using name/token services.
Not to mention function names are limited to a maximum of 8 characters!
Better to use a command processor environment, but then you have to
write a command parser. Been there, done that it's a lot of work.

Now compare that to Lua where the entire I/O package in the standard
library is less than 1000 lines of code [1]

[1] https://secure-web.cisco.com/1fAE1FRpOV9ojUJunEHUBCFVOD9Cq2OCD86vgyzOiIsHIwBDb6-WW2lyfEwSKGyQjD5o4R0Qn78nIchAmYSESFM2sAr-IcGGPoOLpNrcSwqwecpV77BFCMgzRwn5CrNe7u4x-r4I-c4ssCj1JvexeCG-yfyQOwMEU_NB5i42tPvDGI0AW3N53li50oydNGIIEUdo1BgECp7fP9iSg41phwOf7EPgu5jDNi9Pzhe7VFSiF6XKfSo_rIhhexeJGpb9PDlbgHGTz7jcu5yM1fP-788ENVRxM4MMJmO3IBllVauhb_8XQMD9y05xA0FGb3YtIklpbfiiPlM_8QZmdeJ5mLV8SrO4QTi1qiQGDDSapHElDxYj1np6rEu-4KE7MXoxVFdcL48lEeu9CQnE5kwcDaw/https%3A%2F%2Fgithub.com%2Flua%2Flua%2Fblob%2Fmaster%2Fliolib.c%2A.%2A

I don't care for Perl syntax, but between its expressive power and the massive CPAN I find myself using it regardless.

I can do without the expressive power of Perl! It shone briefly as a CGI
language and it's good for text processing but with the emergence of
powerful PEG parser libraries [1] I can easily do more with less using
much cleaner languages.

[1] http://secure-web.cisco.com/1EEbpMNm2VKYWvGNw5YBUs_RbBqZHENUg8e4xfBd0hdeQnWk5Klw_AteQx0Iq_99PxUyJCYwDngm7XZP8PJUlNtNfe8WlpvHFmqKAxgJ56YZAjPdP-wawZEzOP6zmn0RNikkWsevN6cxtGxeZ9dmZrEuFnjg90BwCtrEZSBhKClU3CuFE_lPeYqLQX6dTqickTnVzO0ABt2x9OdyCroqjjFvO17_Y5Oq-dUMp0V2oN2O-iXDZBvvxC2Bm0PAA_Thjdojx6i7gfGu_9Q4_BdEV-wCHwWGS8ilRNbz3Ln9reaWkwZCfQ-SxEc81SF1nmN0iTR4E7JpTNura2ZW2och9sqEQmdpIeDxow9pCjfMxY5t39Ekt9skUCvYMjTZWPuXxyRlv35qSxKDG7QIIet6bKQ/http%3A%2F%2Fwww.igordejanovic.net%2FArpeggio%2Fgrammars%2F
https://secure-web.cisco.com/1F9OM8QJ2XyavxlCLH586mfiSbel08ataY-oMZl78K1kDEFa3mHAXcWbfBmgYlN4jA_uiEvHb5Lu4q2r0Dp-bBIcn9_CfEQYyFQqQ3CesYfaUiAd0qFTNf3u7sCVBMo4lIPgheolAmshmCXDHszAkEmkTfY-Oiu0YrSTJdzCKs0TeDbH3Oum_8XOJbIUpcZ4Xv3OvNvn46Ow-MzTWcvIdtbEqbeDyPmZrGiQ6o5_yo5Q5pk5_NJuwBu7DmSsI8Op7MHsntg3juJO8rNKmjwSE48xdtKxTT-sA_VtA74WWdZhbSiAj8qv7HvwASQdCSeGJYTBF847xdjxFVT6yvk8N6TNisUhlFPHAk394zmMQr3kpW-N4l-Qe6EZ2vY2uxzyDF1wq8P7-it9_bCieSmG8IA/https%3A%2F%2Fgithub.com%2Fpegjs%2Fpegjs
http://secure-web.cisco.com/1h6h6skXopckK2hfFJ6m_0QAMj7zePQQAeo23EPud_hD5YxAFCNFaNByYW5t7guGOst5nVvW_SzYMwWllW8jIeTCVAHUdqW8D9B9ZYplMSj9aXWibQEWTX-A-U4W0XUYaBY9ymbl6TO4WbJMMMC92k9XawDN0cy_fH5cJVNaLxuKoYXrzHSJIaEdmvPeen3PbgQc1zSUD7sCTBLUYwCqdsmnwmINZBtNPlnBnhjJA0p3l29aToCBAFylp8DLO0VLd6xeMDNsf9BY52jBMTFZxE0OLdfSsvr_CwGqpLKYd8p55zo_lVr9tue9c-3s2DA52hLBZBQbSyAoOvl5iou8uiTs-Xkkzythad1MFlo1ZJ9SjqdrenwQ6tV2ZzEVFONpK/http%3A%2F%2Fwww.inf.puc-rio.br%2F%7Eroberto%2Flpeg%2F
https://secure-web.cisco.com/10pTPbff4_0BbOMkG9LCpI2KXGAXoH5XiQyt2PIAk5v9UOd04uiRc8SYnkKUCFleCzcDYgHYCV2DRjn6jWnyEQ__eZFnDDxHKioZ6jsadxVUgZIFQg4-5sFjlg9JmqACIserqEL3pkCEPgfRIGSh651z152lFdYZ9L_mtyjDR3nLAXnHF7PUcjR3N8OKaUg9mq_byrtlnbSI-V9u4C_sP0_VlpXbyP5OxXkT0rrlsKmMXTV8TIjWxe0GaFomx5hp9PLsxcoVo-Wyxaw30wV8J5xQdZp-h11YI06Rb2ClqEw0m768kLmlrZL8DAwB14qfJvWF1TRKbD08UckOSvoXDvAyv_L4gFdP1h8y1BUKn8tiYqLhRvwSmzsqeXZnErSaXs5ze45Eb6EaNPSM5x9jtCA/https%3A%2F%2Fgithub.com%2Fevanphx%2Fkpeg

That said, I find that REXX has a much cleaner syntax for scripting OS commands

Agreed. Processing command strings is much cleaner in REXX then any
other language I know. But not by much.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
http://secure-web.cisco.com/1d2-ayEOq0ufqQVN67vXwQwfMwSZgP6Y1Z6HtAyVsCBFOpBrST89wKlEFsyomHH4OzuHssEe1HaqUy2pdgoh5MkrMFXqQF8Hy91XE-eKbhUM4Ec6W7nolRa41s4dLfBnWBEtjX-LBx55vLW1xCsU1PTRU87_N9AuYwygQviLNXbKb5WGf7xrTRqBMMlBk83GKfZnaPsYKpNlr67j0rdV0tiPPnNT-Z9BYD2Vt51yZs1deHpzOdvnwIN_S5wLsV8KQadTPL4_auilFNvuOSy4Iec23zSBEjViEa23GKsuJwF0_S8QKEN15H30dDCDP8NNH1eltdHJn3_X4P2UZl98Dyw3BfdPFw3gXN36bwYvxp1gcoJ_TJjLBpvWgbCqE_ugZ/http%3A%2F%2Fwww.rexxla.org%2FNewsletter%2F9812safe.html
http://secure-web.cisco.com/1yKXKkvheTyHbkEEvq631b7xdeJZpD7rJoar6OHKLyP2Ua9x6zz7BiTmpoTTGhEzPJA8oxs2DjHzHsyA-lGVDqoUIwKAGQwKOrcOlX5-cn5_Txv-QFwitRk3RMj0ItP7zLEJFY11eCoVPU7k2qF77yfq2gM6C8N21ccen9sRDmnwC3__70eP059jkLmYpuWEUWt9gx59D2JY_kuVXNXAwcHYm0Au9maSFYRVYzX5kXffdLy4py-8rn8W_yWqiH9eh2SnxazK1e11SZHixaNo8OkyTmMBjrojZEIl8V4Aac0U85PoUcFBn_fcrFFqTh_hn8qeXZJZ94HeZ1pfHytodFs7rAV44yEGGjOltz8lGwaNwOVb_1F21MLIyH9XcJenl/http%3A%2F%2Fwww.rexxla.org%2FNewsletter%2F9901safe.html
________________________________________
Sent: Friday, May 11, 2018 10:09 PM
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Tony Thigpen

The fact that REXX does not have native support for VSAM
data sets is a shocking omission.

This is available on s/VSE.

z/VM and z/VSE seem to have lots of features that z/OS lacks, like pipes.

Post by Tony Thigpen

Lack of variable scoping is one of my biggest gripes. It means
REXX doesn't scale. Of course, you can add "procedure expose"
to functions but that soon turns into an intractable mess.

I disagree. This sounds more like you are trying to use programming
habits/methods designed for another language. Any programming
'language' should be used as it was designed, not as some other
'language' was designed. Are you trying to make REXX look like Perl,
Java, PHP or bash?

Not at all! My opinion is based upon 30+ years of using REXX. The
inability to pass aggregate types (objects) in REXX (stem variables) to
functions makes it unsuitable for large programs. This is especially
true for external functions.
REXX also lacks modules or packages so reusing code is hard. The "expose
stem." construct doesn't cut it IMO. Once the code grows large it takes
a lot of mental gymnastics to remember what's been exposed. Lexical
scoping is
an absolute must in modern programming languages.

Post by Tony Thigpen

Perl excels at one thing, regular expressions. Its syntax is ugly
and it suffers from language bloat.

I equate regular expressions with vi. It takes a lot of use to get
where you can use it without looking things up, and if you get to that
point, you have lived a hard life. :-)

I have to admit that the parse instruction in REXX is elegant and one of
it's redeeming features. But it lacks the power of regular expressions.
I missed regular expressions in REXX so much I wrote a command processor
[1].
Extending REXX is difficult and requires writing assembler code. In the
case of my regex API I needed to use CEEPIPI to glue together the
assembler code and LE C++ code. Extending languages like Python, Ruby,
Lua, Node.js
is trivial in comparison. But of course the language bindings for those
languages are written in C/C++, which is ok for me as I know those
languages.
[1] https://secure-web.cisco.com/1hl2S1kpirFFJW9IvenEuaa4EAGxduLA8veYSk-oplRc6Kst7sAdKMuWYMRxwh9TxWDln5kMQtW4nFoVsM6fNGpYmpBnRSL6ok280lKYp25zEIK4njlXHFylhgoLjzzJD9dGWh2Bmk0bTKbkne1Ycwn3JnZY7ugfrWBToNL2__OfEaFxvtYiP9c29Lpg_sb-BwxmDSmQEUnyn5vldeqVaeuaT3k2GX-M8WtSK7TJ8rAlDvXLD8FLIgnjdh_egoly8LgYVNjgLfraPfIFxepNbD6ZVziom8nUgvP2GNxJNfpQNp0PombTDtVzJnVtLsYeeRCCqQdkXiepdzXKAvrjaVdVE1lX2oA3YgQjfGxxdOEtDIQsG-wGayObGxLUDx8X0xGI53_kCoAYXlQppYqpVhg/https%3A%2F%2Fgithub.com%2Fdaveyc%2FRTK

Post by Tony Thigpen

I'm at a loss as to why anybody would use OOREXX on platforms where
there are a multitude of better languages to chose from. If it's
because of familiarity coming from z/OS or z/VM then I would
advise them to take the time to learn something new. Most modern
scripting languages can be picked up in less then a day.

And the code produced is usually crap for the first 5,000 or 10,000
lines of code written in a new language. I had rather know a few
languages well than many languages 'so-so'. Bringing your existing
skills into play is always a good thing. Bringing your poor skills
into play for a production code is just stupid. (I am not against
using your poorer skills for one-off, one-time use code. That is the
best place to learn new skills.)

But with modern languages you have to write less code. There are
libraries to do just about everything you can imagine. I was reading
about the new web services for REXX to create JSON. It really did hammer
home
just how difficult it is to do things in REXX that is one line of code
in modern languages. And to install libraries in modern languages you
use an installer like pip, gem, npm, luarocks which takes care of
dependencies etc.
It's a cliche but if the only tool you have is a hammer the whole world
looks like a nail.

Post by Tony Thigpen
After all the cut-n-paste, I noticed that the biggest complainer is
David. That's ok. You hate Rexx, I hate 'C', and Perl and PHP and ....

I hate Perl and PHP too. I'm not a fan of Ruby either. I don't much like
C but it's a useful language to know.
I have been accused before on this list of pathologically hating REXX.
That's not true, I appreciate it for what it's good at. But I have found
over the years that I prefer other languages. I'm a software developer
and write
code for a living so having the best tools available is important to me.

Post by Tony Thigpen
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

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

Paul Gilmartin

2018-05-11 23:26:19 UTC

...
...

I've seen no mention in this thread of arbitrary precision aritnmetic.
Some would consider GAAP support even more valuable.

Somehow it's not entirely a scripting feature.

What other languages have it?

-- gil

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

Clark Morris

2018-05-12 01:46:30 UTC

[Default] On 11 May 2018 16:26:19 -0700, in bit.listserv.ibm-main

Post by Paul Gilmartin

...
...

I've seen no mention in this thread of arbitrary precision aritnmetic.
Some would consider GAAP support even more valuable.
Somehow it's not entirely a scripting feature.
What other languages have it?

While they aren't scripting languages, I would assume that COBOL and
PL/1 fit the requirement for supporting GAAP.

Clark Morris

Post by Paul Gilmartin
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

David Crayford

2018-05-12 02:09:36 UTC

Post by Paul Gilmartin

...
...

I've seen no mention in this thread of arbitrary precision aritnmetic.
Some would consider GAAP support even more valuable.
Somehow it's not entirely a scripting feature.
What other languages have it?

All modern scripting languages have decimal libraries. Ironically, some
use the decNumber package written by Mike Cowlishaw.

Post by Paul Gilmartin
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Paul Gilmartin

2018-05-13 20:43:39 UTC

Post by Seymour J Metz
OOREXX solves many of the problems in classic REXX.
I never found writing REXX function packages to be difficult.

THere's a lack of closure. Why can't a command (ADDRESS) environment
be implemented in Rexx?

Post by Seymour J Metz
bar='baz'
say f.bar
say foo.BAR
say FOO.bar
say FOO.BAR
will give 4 identical outputs, but change that first line to bar='BAZ' and you're talking about a different variable.
You can use the value BIF to get expressions in tails: x =value('foo.'bar'2')

Circuitous. And if BAR || '2' is an assigned variable you may get undesired results.
(Try it; I think we had this discusion long ago.) For safety, you need to:
TAIL = bar'2'
X = foo.TAIL

Post by Seymour J Metz
WTF is a "longITERATE" or a "longLEAVE"?

Idiosyncratic neologism by analogy to "longjump". Imagine ITERATE X
or LEAVE X where X is not local but EXPOSEd from an enclosing procedure.

Post by Seymour J Metz
Admittedly I use here documents in Perl, but I'm not a big fan of them.

How about in JCL?

Post by Seymour J Metz
Why can't IBM implement GLOBALV in TSO?

Circuitous. Why not some sort of IMPORT list or EXPOSE list so the names
could just be used as variables. As in POSIX shell.

Post by Seymour J Metz
If IBM would be up OOREXX some of your other issues would be addressed.

-- gil

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

Seymour J Metz

2018-05-14 20:20:27 UTC

I know that you think you know what circuitous means, but ...

Why can't a command (ADDRESS) environment be implemented in Rexx?

Because REXX isn't PL/I? Because REXX isn't a scripting language?

Circuitous.

Not even close; it was a counterexample to your claim about case insensitivity.

And if BAR || '2' is an assigned variable

The statement in question was

x =value('foo.'bar'2')

It has nothing to do with a variable called BAR2, but rather a variable called BAR.

TAIL = bar'2'
X = foo.TAIL

ITYM for safety you need to use the value() BIF.

How about in JCL?

Yes, I use inline data in JCL, but a lot less than when I was dealing with cards. Most of the inline data that I've seen in the last few decades shouldn't have been inline.

Idiosyncratic neologism by analogy to "longjump". Imagine ITERATE X
or LEAVE X where X is not local but EXPOSEd from an enclosing procedure.

I think I'm going to be sick!

Circuitous.

Again, no.

Why not some sort of IMPORT list or EXPOSE list so the names
could just be used as variables. As in POSIX shell.

Because it's the right answer to the wrong question, and has nothing to do with the need for GLOBALV. Google for "persistent data".

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Sunday, May 13, 2018 4:45 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

OOREXX solves many of the problems in classic REXX.
I never found writing REXX function packages to be difficult.

THere's a lack of closure. Why can't a command (ADDRESS) environment
be implemented in Rexx?

bar='baz'
say f.bar
say foo.BAR
say FOO.bar
say FOO.BAR
will give 4 identical outputs, but change that first line to bar='BAZ' and you're talking about a different variable.
You can use the value BIF to get expressions in tails: x =value('foo.'bar'2')

Circuitous. And if BAR || '2' is an assigned variable you may get undesired results.
(Try it; I think we had this discusion long ago.) For safety, you need to:
TAIL = bar'2'
X = foo.TAIL

WTF is a "longITERATE" or a "longLEAVE"?

Idiosyncratic neologism by analogy to "longjump". Imagine ITERATE X
or LEAVE X where X is not local but EXPOSEd from an enclosing procedure.

Admittedly I use here documents in Perl, but I'm not a big fan of them.

How about in JCL?

Why can't IBM implement GLOBALV in TSO?

Circuitous. Why not some sort of IMPORT list or EXPOSE list so the names
could just be used as variables. As in POSIX shell.

If IBM would be up OOREXX some of your other issues would be addressed.

-- gil

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

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

Phil Smith III

2018-05-14 04:02:10 UTC

Heretic indeed! I've been a Rexx user for 35+ years, so I'm at least used to
it. Have written entire products in it, published a book about it, so
(surprise) I disagree.

I believe that Rexx's biggest weakness was that it came from IBM back when
IBM was considered Bad by the non-IBM community. If folks had jumped on Rexx
and written packages like they did for Perl, I like to think that it would
have been as popular. It's certainly easier to learn and write (one of its
design goals, of course).

I always say I have "angry" Perl skills: not "mad skillz", but angry ones.
Because whenever I'm forced to use Perl, I wind up pissed off at the
language!

.phsiii

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

Seymour J Metz

2018-05-14 19:33:35 UTC

There's enough interest in the PC world to support multiple PC implementations, to say nothing of OOREXX. Does anybody remember what the scripting language was for Amiga?

I don't like Perl syntax, but I use it from choice because it has named captures in regexen and an awesome library (CPAN) of useful packages.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Phil Smith III <***@AKPHS.COM>
Sent: Monday, May 14, 2018 12:03 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Heretic indeed! I've been a Rexx user for 35+ years, so I'm at least used to
it. Have written entire products in it, published a book about it, so
(surprise) I disagree.

I believe that Rexx's biggest weakness was that it came from IBM back when
IBM was considered Bad by the non-IBM community. If folks had jumped on Rexx
and written packages like they did for Perl, I like to think that it would
have been as popular. It's certainly easier to learn and write (one of its
design goals, of course).

I always say I have "angry" Perl skills: not "mad skillz", but angry ones.
Because whenever I'm forced to use Perl, I wind up pissed off at the
language!

.phsiii

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

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

Clark Morris

2018-05-14 21:53:53 UTC

[Default] On 14 May 2018 12:33:35 -0700, in bit.listserv.ibm-main

Post by Seymour J Metz
There's enough interest in the PC world to support multiple PC implementations, to say nothing of OOREXX. Does anybody remember what the scripting language was for Amiga?

From what I vaguely recall reading I think it was AREXX. Iè am fairly
certain it was a variant of REXX not from ever having used an Amiga
but because what I believe I read made a strong impression on me.

Clark Morris

Post by Seymour J Metz
I don't like Perl syntax, but I use it from choice because it has named captures in regexen and an awesome library (CPAN) of useful packages.

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

Paul Gilmartin

2018-05-14 15:21:44 UTC

Post by Phil Smith III
I believe that Rexx's biggest weakness was that it came from IBM back when
IBM was considered Bad by the non-IBM community. If folks had jumped on Rexx
and written packages like they did for Perl, I like to think that it would
have been as popular. It's certainly easier to learn and write (one of its
design goals, of course).

I call that weakness a tie with lack of regular expressions. There's a similar
bias in the IBM community to consider regexen Bad.

Concerning language competitions, I've long wondered how PL/S would have
fared against C on a level playing field. But that case is closed; stare decis.

-- gil

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

Phil Smith III

2018-05-14 15:38:07 UTC

Post by Paul Gilmartin
I call that weakness a tie with lack of regular expressions. There's a

similar

Post by Paul Gilmartin
bias in the IBM community to consider regexen Bad.

Well, we could have a whole 'nother thread on whether regex are A Good Thing
or not ("now you have two problems" and all that), but actually there was at
least one regex implementation for Rexx, as a function package, so it sort
of winds up being (arguably!) the same point.

David Crayford complained about Rexx being typeless and lacking lexical
scoping. These are considered strengths by some of us. And PROCEDURE gives
you lexical scoping of a sort, no?

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

Charles Mills

2018-05-14 16:19:48 UTC

And PROCEDURE gives you lexical scoping of a sort, no?

Indeed. Nothing that would make an Algol purist happy, but then, Rexx is not
Algol -- QED.

I wrote a large set of applications in Rexx once. I put all of my "intended
to be global" variable names into a single Rexx variable and exposed it with
Procedure Expose (Rexx_Globals)

Worked pretty well.

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Monday, May 14, 2018 8:39 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

I call that weakness a tie with lack of regular expressions. There's a

similar

bias in the IBM community to consider regexen Bad.

Well, we could have a whole 'nother thread on whether regex are A Good Thing
or not ("now you have two problems" and all that), but actually there was at
least one regex implementation for Rexx, as a function package, so it sort
of winds up being (arguably!) the same point.

David Crayford complained about Rexx being typeless and lacking lexical
scoping. These are considered strengths by some of us. And PROCEDURE gives
you lexical scoping of a sort, no?

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

Mike Schwab

2018-05-14 16:28:04 UTC

z/OS has Regex in
ISPF 2.01 https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54em00/useofr1.htm
Awk https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug444.htm
Shells https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/regexpa.htm

Post by Seymour J Metz

Post by Paul Gilmartin
I call that weakness a tie with lack of regular expressions. There's a

similar

Post by Paul Gilmartin
bias in the IBM community to consider regexen Bad.

Well, we could have a whole 'nother thread on whether regex are A Good Thing
or not ("now you have two problems" and all that), but actually there was at
least one regex implementation for Rexx, as a function package, so it sort
of winds up being (arguably!) the same point.
David Crayford complained about Rexx being typeless and lacking lexical
scoping. These are considered strengths by some of us. And PROCEDURE gives
you lexical scoping of a sort, no?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Seymour J Metz

2018-05-14 18:51:44 UTC

Yes, ISPF has limited (e.g., no named captures) regexen, but lots of REXX code is not intended to run under ISPF.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Mike Schwab <***@GMAIL.COM>
Sent: Monday, May 14, 2018 12:29 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

z/OS has Regex in
ISPF 2.01 https://secure-web.cisco.com/1gd11NXtRpsNGpTEQV0GHccNCniCu4XpHBL76NpmleVI5NU-yDW6SaS43JUJ_u4EL3P_7uelrG2112ssPpg7szKIFpj2dpDqjSH10_1G8TaCwqgz9P2eW4c-il8x5XMWT7MGiP7KVr2391DohQdT-90LQzxAEs8171euUfqv8LNnl18Ic3YQHIbAas7jCaB6UHmC4N5C8OWRz_OYBfoaGHXU1izCVrUgR4prIFhE6gWBxyHY9k49I4Y7tTf2Q_xbgp71k6JCfJqP0mOVcKdYjgJGnQf9g60Ev2BoBbfySzWQotVoXf3NFApAF5ZELooUIP1S7N8j9lat12gWXT9fFKubf14Jwy-3gX10asRYYfatW5dYOhNxKA_1wiPxpyVGeFuiAKb4wHSDKdDJ-1bcuV3YJ58OOozsKBuM0r04--3xJ1Sme9CzlTCBC_6d05mfs/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.f54em00%2Fuseofr1.htm
Awk https://secure-web.cisco.com/1fQY98dsOtQ7culCYmjaia00Hrvcabq2S8M4hQqCzZFwhPI5LfDy6IjXE8ADK4ZzQRRqsSTd7YN3qI33RP7d6zYKtisl2PzgimWUK4WdNrHUE_zmowcJx2xzIKRSgzPtUVmfdva1TJG72qZ2hlUjjpRsQvlwKRWcWXqODvT_SdzlIlEqOFnxv3wbRH1Dw1fWpDQ1b4gYh9457QbuO31GeoHnCb5VADph85i_gIZktY0bJ9K0dWHIQfgbx2QLfY0qTEnmi97_F6PTuZWD0wfWR3R3B5KeI8HqtZ3RfWvRornliSDVKzaYHwTnwk89LhrG_ciqP3g983oGZ9I-4rrca-19vWpgYBYXknvJ3AzG16nEBg-XP4YoItIamgiukRB3tLZKITcn6XBRe9j2aNoB8LAbO5CheSTZysNXud1hD3M-Z12Jbe0GOIfB2HVjOIVqQ/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.bpxa400%2Fbpxug444.htm
Shells https://secure-web.cisco.com/1cEMAEZMMuIWhuBuvX3Nt3pp_G3TuqM-dVvN9oT2IDLNx4DG7xIC9UdmK96vhMf_YJXwmBGtBGlfxNDYo-6t8Wfz51TNGE4YKZsCEFiqnFH5S6XyI7Ng2PkzPlUrA2Eyi2dyS2TwTC05ei1q072QqCCezd8B3fUdVJ6ogZZhsEFgUWAMiHoD6GrNgk9zPcYWVNGQLnuMRRfvJpWEnzeLl1R9De52WciYcxU97Qprg6p-c7tfHiN9e_2i3P-PwbHM-tibukl8vdKBeRKAj6Vcz9kfffvnQ13rgvraEWZoPHYtHbAFmJF8FfA9ZXqkKl1264flsPcuNS3-eW2e5P75Y07Ps13kW6n7ICShN65KieGKEa0r9FciwHTpRPz3SdrEWKGZwmxPlgIcOk8HAgXeId6cP_897oaXQ0tJJ_9Oy3Mpe33gVa64gWR2ZD2TMLVIU/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.1.0%2Fcom.ibm.zos.v2r1.bpxa500%2Fregexpa.htm

Post by Seymour J Metz

Post by Paul Gilmartin
I call that weakness a tie with lack of regular expressions. There's a

similar

Post by Paul Gilmartin
bias in the IBM community to consider regexen Bad.

Well, we could have a whole 'nother thread on whether regex are A Good Thing
or not ("now you have two problems" and all that), but actually there was at
least one regex implementation for Rexx, as a function package, so it sort
of winds up being (arguably!) the same point.
David Crayford complained about Rexx being typeless and lacking lexical
scoping. These are considered strengths by some of us. And PROCEDURE gives
you lexical scoping of a sort, no?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

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

Seymour J Metz

2018-05-14 19:14:16 UTC

And PROCEDURE gives you lexical scoping of a sort, no?

Yes and no, mostly no.

The term lexical scoping normally includes proper handling of nesting, which REXX doesn't have.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Phil Smith III <***@AKPHS.COM>
Sent: Monday, May 14, 2018 11:39 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

I call that weakness a tie with lack of regular expressions. There's a

similar

bias in the IBM community to consider regexen Bad.

Well, we could have a whole 'nother thread on whether regex are A Good Thing
or not ("now you have two problems" and all that), but actually there was at
least one regex implementation for Rexx, as a function package, so it sort
of winds up being (arguably!) the same point.

David Crayford complained about Rexx being typeless and lacking lexical
scoping. These are considered strengths by some of us. And PROCEDURE gives
you lexical scoping of a sort, no?

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

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

Paul Gilmartin

2018-05-14 17:48:05 UTC

Post by Mike Schwab
z/OS has Regex in
ISPF 2.01 https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54em00/useofr1.htm
Awk https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/bpxug444.htm
Shells https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/regexpa.htm

Seriously!?

Think how long a reach that is if you're running Rexx under Unix System Services.
ADDRESS TSO to start ISPF to enter Edit of a temp file with a profile to insert your
string and FIND r'whatever'! And in that Rube Goldberg I doubt that your Edit
profile macro will be able to access variables in your original Rexx to return a
result.

Better ADDRESS SYSCALL spawn sed.

-- gil

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

Phil Smith III

2018-05-14 17:51:33 UTC

Post by Charles Mills
I wrote a large set of applications in Rexx once. I put all of my "intended
to be global" variable names into a single Rexx variable and exposed it

with

Post by Charles Mills
Procedure Expose (Rexx_Globals)

Yep. That's one of the approaches; I've used that, also used a set of stems:

G.

U.

D.

(whatever, but often segmented that way-for example, G. might be global
configuration settings; U. be user data; D. might be, well, data data!).
This strongly suggests being rigorous with tail naming: I use leading
underscores for non-variable tails:

G._Logging

and then never use any local variables with leading underscores (yes,
_Logging is a valid variable name). An easy convention to follow, and makes
it easy to tell the difference between:

U.settings

(which will substitute the tail, and

U._settings

Enforced with SIGNAL ON NOVALUE (and perhaps G.='' et al. as appropriate),
this gives me the lexical scoping I need with the power of tails etc.

For those who aren't experience with Rexx: don't overlook the associative
memory aspect of tails!

A final note: a friend commented to me re this thread, "Nobody will change
anyone's mind, so it's all just wind." Well, sorta. But it's useful,
perhaps, to discuss these issues and at least understand the other folks'
perspective. Rexx isn't perfect, isn't the right hammer for all nails. But
for what it was designed to do, it's pretty darned good. Perl is (arguably?)
one step along the track toward a "real" programming language, but it's also
not as well suited for what Rexx was designed to do - be an interface for
operating system commands.

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

David Crayford

2018-05-15 04:26:24 UTC

Post by Phil Smith III

Post by Charles Mills
I wrote a large set of applications in Rexx once. I put all of my "intended
to be global" variable names into a single Rexx variable and exposed it

with

Post by Charles Mills
Procedure Expose (Rexx_Globals)

G.
U.
D.
(whatever, but often segmented that way-for example, G. might be global
configuration settings; U. be user data; D. might be, well, data data!).
This strongly suggests being rigorous with tail naming: I use leading
G._Logging
and then never use any local variables with leading underscores (yes,
_Logging is a valid variable name). An easy convention to follow, and makes
U.settings
(which will substitute the tail, and
U._settings

A common technique with the use of the underscore to reserve the
namespace. Inadvertently clobbering a stem identifier with a local
variable is a common and confusing error.

Unfortunately, it doesn't take long before those expose lists start to
telescope. A case in point is the ISPF DTL compiler which is 40,000
lines of REXX code.
It's not uncommon to see functions like this:

SL_STag:
Procedure Expose Global. Panel. Globalw. Help. Info. olist. ,
obuf orec i m Logbuff.

And variables like "Global.PS_lclvar.jk.jl.jz.H".

Urrgghh, someone hand me a bucket!

Post by Phil Smith III
A final note: a friend commented to me re this thread, "Nobody will change
anyone's mind, so it's all just wind."

Yep. Our opinions have been forged over decades and the majority of us
are too long in the tooth to change.

Post by Phil Smith III
Well, sorta. But it's useful,
perhaps, to discuss these issues and at least understand the other folks'
perspective. Rexx isn't perfect, isn't the right hammer for all nails. But
for what it was designed to do, it's pretty darned good. Perl is (arguably?)
one step along the track toward a "real" programming language, but it's also
not as well suited for what Rexx was designed to do - be an interface for
operating system commands.

Perl was displaced well over a decade ago by Python and Ruby which are
currently used to write the back-ends of the likes of Instagram,
Spotify, Dropbox and Github. Python has
become the language de jour for data scientists for machine learning.
Streaming behemoths like Netflix are swapping out racks of Java
application servers and
replacing them with single Node.js instances. That's right JavaScript!
Scripting languages have come a long way since Perl and are in a
completely different universe
now to when classic REXX was the new kid on the block.

The good news is that those languages are starting to arrive on z/OS.
Maybe not for the oldies but definitely the next generation who will be
supporting the old dog in the decades to come.

Post by Phil Smith III
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Robert Prins

2018-05-17 15:07:44 UTC

Post by Phil Smith III

Post by Charles Mills
I wrote a large set of applications in Rexx once. I put all of my "intended
to be global" variable names into a single Rexx variable and exposed it

with

Post by Charles Mills
Procedure Expose (Rexx_Globals)

G.
U.
D.
(whatever, but often segmented that way-for example, G. might be global
configuration settings; U. be user data; D. might be, well, data data!).
This strongly suggests being rigorous with tail naming: I use leading

Even better, start tail names with a number, from many of my execs:

* Global (!g.0xxxx) variables:

Robert

--
Robert AH Prins
robert.ah.prins(a)gmail.com

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

Phil Smith III

2018-05-14 20:24:27 UTC

Post by Seymour J Metz
Does anybody remember what the scripting language was for Amiga?

AmigaRexx, yes?

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

Seymour J Metz

2018-05-15 17:46:22 UTC

Exactly my point.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Phil Smith III <***@AKPHS.COM>
Sent: Monday, May 14, 2018 4:25 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Seymour J Metz
Does anybody remember what the scripting language was for Amiga?

AmigaRexx, yes?

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

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

Paul Gilmartin

2018-05-15 04:39:14 UTC

Post by Seymour J Metz

Post by Paul Gilmartin
And if BAR || '2' is an assigned variable

The statement in question was
x =value('foo.'bar'2')
It has nothing to do with a variable called BAR2, but rather a variable called BAR.

Read what I wrote. Not the variable called "BAR2", but the variable called "value
(not name) of BAR with digit 2 appended. We had this discussion several years
ago; you were wrong then; you remain wrong now.

Sample Rexx code:
trace R
signal on novalue
BAR = 'Wombat'

drop WOMBAT2
say '==>' value( 'foo.'bar'2' )

WOMBAT2 = 'XYZZY'
say '==>' value( 'foo.'bar'2' )

And output, traced:
2 *-* signal on novalue
3 *-* BAR = 'Wombat'

5 *-* drop WOMBAT2
6 *-* say '==>' value( 'foo.'bar'2' )

Post by Seymour J Metz
V> "Wombat"

==> FOO.WOMBAT2

8 *-* WOMBAT2 = 'XYZZY'
9 *-* say '==>' value( 'foo.'bar'2' )

Post by Seymour J Metz
V> "Wombat"

==> FOO.XYZZY

Post by Seymour J Metz

Post by Paul Gilmartin
TAIL = bar'2'
X = foo.TAIL

ITYM for safety you need to use the value() BIF.

No, I meant what I said.

-- gil

Post by Seymour J Metz

Post by Paul Gilmartin
How about in JCL?

Yes, I use inline data in JCL, but a lot less than when I was dealing with cards. Most of the inline data that I've seen in the last few decades shouldn't have been inline.

???

-- gil

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

Seymour J Metz

2018-05-16 16:31:41 UTC

Post by Paul Gilmartin
Read what I wrote.

I did. You wrote " And if BAR || '2' is an assigned variable" in response to " x =value('foo.'bar'2')", and the question has no relevance to that code, which has no variable called BAR or BAR2. The point at issue was the behavior of the value() BIF, which you kept ignoring. Now that you have noticed that to be the issue, I see where the confusion came in; I was thinking of the .stem class in OOREXX rather than the way value() accesses compound variables.

/* REXX semantics for the value() BIF */
/* trace i */
lvar = 'left'
uvar = LEFT

mystem = .stem~new('MYSTEM.')
say 'uninitialized mystem[left2] =' mystem[lvar'2']
say 'uninitialized mystem[LEFT2] =' mystem[uvar'2']

/*
Produces
uninitialized mystem[left2] = MYSTEM.left2
uninitialized mystem[LEFT2] = MYSTEM.LEFT2
*/

mystem[lvar'2'] = LOWER
mystem[uvar'2'] = UPPER
say 'initialized mystem[left2] =' mystem[lvar'2']
say 'initialized mystem[LEFT2] =' mystem[uvar'2']

/*
Produces
initialized mystem[left2] = MYSTEM.left2
initialized mystem[left2] = UPPER
*/

say 'uninitialized head.left2 =' value('head.'lvar'2')
say 'uninitialized HEAD.left2 =' value('HEAD.'lvar'2')
say 'uninitialized head.LEFT2 =' value('head.'uvar'2')
say 'uninitialized HEAD.LEFT2 =' value('HEAD.'uvar'2')

/*
Produces
uninitialized head.left2 = HEAD.LEFT2
uninitialized HEAD.left2 = HEAD.LEFT2
uninitialized head.LEFT2 = HEAD.LEFT2
uninitialized HEAD.LEFT2 = HEAD.LEFT2
*/

call value 'head.'lvar'2', LOWER LOWER
call value 'HEAD.'lvar'2', UPPER LOWER
call value 'head.'uvar'2', LOWER UPPER
call value 'HEAD.'uvar'2', UPPER UPPER

say 'initialized head.left2 =' value('head.'lvar'2')
say 'initialized HEAD.left2 =' value('HEAD.'lvar'2')
say 'initialized head.LEFT2 =' value('head.'uvar'2')
say 'initialized HEAD.LEFT2 =' value('HEAD.'uvar'2')

/*
Produces
initialized head.left2 = UPPER UPPER
initialized HEAD.left2 = UPPER UPPER
initialized head.LEFT2 = UPPER UPPER
initialized HEAD.LEFT2 = UPPER UPPER
*/

Unfortunately, TSO/E does not support that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Tuesday, May 15, 2018 12:40 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Paul Gilmartin

Post by Paul Gilmartin
And if BAR || '2' is an assigned variable

The statement in question was
x =value('foo.'bar'2')
It has nothing to do with a variable called BAR2, but rather a variable called BAR.

Read what I wrote. Not the variable called "BAR2", but the variable called "value
(not name) of BAR with digit 2 appended. We had this discussion several years
ago; you were wrong then; you remain wrong now.

Sample Rexx code:
trace R
signal on novalue
BAR = 'Wombat'

drop WOMBAT2
say '==>' value( 'foo.'bar'2' )

WOMBAT2 = 'XYZZY'
say '==>' value( 'foo.'bar'2' )

And output, traced:
2 *-* signal on novalue
3 *-* BAR = 'Wombat'

5 *-* drop WOMBAT2
6 *-* say '==>' value( 'foo.'bar'2' )

Post by Paul Gilmartin
V> "Wombat"

==> FOO.WOMBAT2

8 *-* WOMBAT2 = 'XYZZY'
9 *-* say '==>' value( 'foo.'bar'2' )

Post by Paul Gilmartin
V> "Wombat"

==> FOO.XYZZY

Post by Paul Gilmartin

Post by Paul Gilmartin
TAIL = bar'2'
X = foo.TAIL

ITYM for safety you need to use the value() BIF.

No, I meant what I said.

-- gil

Post by Paul Gilmartin

Post by Paul Gilmartin
How about in JCL?

Yes, I use inline data in JCL, but a lot less than when I was dealing with cards. Most of the inline data that I've seen in the last few decades shouldn't have been inline.

???

-- gil

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

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

Paul Gilmartin

2018-05-15 04:50:55 UTC

Post by Phil Smith III
This strongly suggests being rigorous with tail naming: I use leading
G._Logging
and then never use any local variables with leading underscores (yes,
_Logging is a valid variable name). An easy convention to follow, and makes
U.settings
(which will substitute the tail, and
U._settings

In order to avoid that hazard I begin a constant symbol with a digit, e.g.
G.9Logging, which tail is not a legal variable name.

-- gil

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

David Crayford

2018-05-15 04:55:44 UTC

Post by Paul Gilmartin

Post by Phil Smith III
This strongly suggests being rigorous with tail naming: I use leading
G._Logging
and then never use any local variables with leading underscores (yes,
_Logging is a valid variable name). An easy convention to follow, and makes
U.settings
(which will substitute the tail, and
U._settings

In order to avoid that hazard I begin a constant symbol with a digit, e.g.
G.9Logging, which tail is not a legal variable name.

That's ugly AF!! While it may be safer I would rather stick to
underscores and reserve the namespace like C/C++ does for the standard
library.

Post by Paul Gilmartin
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

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

Charles Mills

2018-05-15 13:27:48 UTC

I am definitely a Rexx fan but I have to agree that the necessity for hacks like these does not speak well for the language.

While one can write 40,000 line applications in Rexx -- pretty amazing for what is basically a .BAT file language -- I think perhaps the larger the application the less suitable Rexx is to the task. Rexx is at its best in the 3 to 300 line range. IMHO

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Crayford
Sent: Monday, May 14, 2018 9:57 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Phil Smith III
This strongly suggests being rigorous with tail naming: I use leading
G._Logging
and then never use any local variables with leading underscores (yes,
_Logging is a valid variable name). An easy convention to follow, and makes

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

Dyck, Lionel B. , TRA

2018-05-15 13:33:02 UTC

While I agree that REXX is more appropriate for smaller projects - there are tradeoffs. If an application is going to be used frequently (100's of times per day) and performance is important then don't use REXX. If an application is going to be used less frequently, or there is a need to be able to easily and quickly update it, then REXX is excellent for that purpose. REXX allows you to prototype an application, and if it works adequately then it may be better to leave it in REXX than to rewrite it.

Just my $0.01

--------------------------------------------------------------------------
Lionel B. Dyck (Contractor) <sdg><
Mainframe Systems Programmer – RavenTek Solution Partners

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Tuesday, May 15, 2018 8:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

I am definitely a Rexx fan but I have to agree that the necessity for hacks like these does not speak well for the language.

While one can write 40,000 line applications in Rexx -- pretty amazing for what is basically a .BAT file language -- I think perhaps the larger the application the less suitable Rexx is to the task. Rexx is at its best in the 3 to 300 line range. IMHO

Charles

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of David Crayford
Sent: Monday, May 14, 2018 9:57 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Phil Smith III
This strongly suggests being rigorous with tail naming: I use leading
G._Logging
and then never use any local variables with leading underscores (yes,
_Logging is a valid variable name). An easy convention to follow, and makes

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

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

Edward Gould

2018-05-15 14:08:05 UTC

Post by Dyck, Lionel B. , TRA
While I agree that REXX is more appropriate for smaller projects - there are tradeoffs. If an application is going to be used frequently (100's of times per day) and performance is important then don't use REXX. If an application is going to be used less frequently, or there is a need to be able to easily and quickly update it, then REXX is excellent for that purpose. REXX allows you to prototype an application, and if it works adequately then it may be better to leave it in REXX than to rewrite it.
Just my $0.01

Lionel:
I agree pretty much with you, if there are only two options (CLIST & Rexx) which would you choose?

Ed

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

Dyck, Lionel B. , TRA

2018-05-15 14:14:19 UTC

Hmmm - CLIST or REXX

I'd go with REXX. The primary reason is that the CLIST skill set just doesn't seem to be there. I know CLIST has some advantages over REXX in a few areas there are things that REXX can do that CLIST can't and one of those is that it is a much cleaner language to read and understand, and thus to pick up.

Again my $0.01

--------------------------------------------------------------------------
Lionel B. Dyck (Contractor) <sdg><
Mainframe Systems Programmer - RavenTek Solution Partners

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Edward Gould
Sent: Tuesday, May 15, 2018 9:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

Post by Dyck, Lionel B. , TRA
While I agree that REXX is more appropriate for smaller projects - there are tradeoffs. If an application is going to be used frequently (100's of times per day) and performance is important then don't use REXX. If an application is going to be used less frequently, or there is a need to be able to easily and quickly update it, then REXX is excellent for that purpose. REXX allows you to prototype an application, and if it works adequately then it may be better to leave it in REXX than to rewrite it.
Just my $0.01

Lionel:
I agree pretty much with you, if there are only two options (CLIST & Rexx) which would you choose?

Ed

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

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

Gord Tomlin

2018-05-15 14:27:34 UTC

Post by Edward Gould
I agree pretty much with you, if there are only two options (CLIST & Rexx) which would you choose?

If the choice was CLIST, I'd be starting a thread, "Heretic alert: I
really detest TSO CLIST (the language)"

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Chris Hoelscher

2018-05-15 14:47:26 UTC

Isn’t there an option to run REXX or CLIST in deTEST MODE

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin
Sent: Tuesday, May 15, 2018 10:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

Post by Edward Gould
I agree pretty much with you, if there are only two options (CLIST & Rexx) which would you choose?

If the choice was CLIST, I'd be starting a thread, "Heretic alert: I really detest TSO CLIST (the language)"

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and
do not discriminate on the basis of race, color, national origin, age, disability or
sex. Humana Inc. and its subsidiaries do not exclude people or treat them differently
because of race, color, national origin, age, disability or sex.

English: ATTENTION: If you do not speak English, language assistance services, free
of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711).

Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios
gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711).

繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助
服務。請致電 1‐877‐320‐1235 (TTY: 711)。

Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd
pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711).

Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej
pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711).

한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로
이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오.

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

Seymour J Metz

2018-05-15 17:39:52 UTC

Post by Edward Gould
if there are only two options (CLIST & Rexx) which would you choose?

"Remember that after Heracles cleaned up the Augean stables, he killed the man who asked him to." Robert Townsend, "Up The Organization.

I'd choose REXX as long as I didn't need anything fancy from the stack. Second choice is REXX with freedom to write REXX-aware external functions in HLASM.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Edward Gould <***@COMCAST.NET>
Sent: Tuesday, May 15, 2018 10:09 AM
To: IBM-***@listserv.ua.edu
Subject: Re: [EXTERNAL] Re: Heretic alert: I really detest TSO REXX (the language)

Post by Edward Gould
While I agree that REXX is more appropriate for smaller projects - there are tradeoffs. If an application is going to be used frequently (100's of times per day) and performance is important then don't use REXX. If an application is going to be used less frequently, or there is a need to be able to easily and quickly update it, then REXX is excellent for that purpose. REXX allows you to prototype an application, and if it works adequately then it may be better to leave it in REXX than to rewrite it.
Just my $0.01

Lionel:
I agree pretty much with you, if there are only two options (CLIST & Rexx) which would you choose?

Ed

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

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

Phil Smith III

2018-05-15 18:39:46 UTC

Post by Charles Mills
I am definitely a Rexx fan but I have to agree that the necessity for hacks

like these does not speak well for the language.

Eh, any worse than leading "my" or "h" or whatever TF it is that folks use
in whatever those new-fangled languages the kids are using? As Gil wrote,
you can use a digit, but it's fuglier.

Post by Charles Mills
While one can write 40,000 line applications in Rexx -- pretty amazing for

what is basically a .BAT file language -- I think perhaps the larger the
application the less suitable Rexx is to the task. Rexx is at its best in
the 3 to 300 line range. IMHO

Depends, of course. I wrote the Levanta (Linuxcare) Linux deployment
management code for z/VM all in Rexx, and it was several thousand lines but
nicely modularized and SUPER easy to manage and debug. But arguably that was
entirely within the original Rexx charter of interfacing to system commands,
just an extreme case.

I also wrote an email gateway back in 1999 between
Internet/PROFS/SMTP/Exchange, translating note formats as needed, detaching
and decoding attachments, etc., all in Rexx. I forget how many thousands of
lines that was, but it was also easy to manage and debug. The worst part was
the TNEF support, which was a CMS Pipelines stage written in Rexx.

Note that both of these relied heavily on CMS Pipelines, which is akin to a
CPAN thingy. (Or is that "to a CPAN"? Not sure of the terminology!)

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

David Crayford

2018-05-16 02:46:18 UTC

Post by Charles Mills

Post by Charles Mills
I am definitely a Rexx fan but I have to agree that the necessity for hacks

like these does not speak well for the language.
Eh, any worse than leading "my" or "h" or whatever TF it is that folks use
in whatever those new-fangled languages the kids are using? As Gil wrote,
you can use a digit, but it's fuglier.

It's interesting what we consider new. The three scripting languages I
mentioned in this thread are all in their twenties.

1. Python 1990, 28 years old
2. Lua 1993, 25 years old
3. Ruby 1995, 23 years old.

The unfortunate thing about REXX is that it hasn't improved over the
years. Here's a post from 1995 highlighting features from Object REXX
that would be
useful in classic REXX
http://www.markcrocker.com/rexxtipsntricks/rxtt28.2.0252.html. The
do/over loop is fantastic and would provide a means to do basic
introspection
on stem variables. Returning stem variables from functions, great!
Little things like that would significantly improve the language.

[1] https://en.wikipedia.org/wiki/Python_(programming_language)
[2] https://en.wikipedia.org/wiki/Lua_(programming_language)
[3] https://en.wikipedia.org/wiki/Ruby_(programming_language)

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

Seymour J Metz

2018-05-16 16:23:13 UTC

The unfortunate thing about REXX is that it hasn't improved over the years.

What is ANSI Rexx, chopped liver? TSO/E has not kept up with developments in the REXX world, which says more about TSO/E than about REXX.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of David Crayford <***@GMAIL.COM>
Sent: Tuesday, May 15, 2018 10:47 PM
To: IBM-***@listserv.ua.edu
Subject: Re: Heretic alert: I really detest TSO REXX (the language)

Post by Charles Mills
I am definitely a Rexx fan but I have to agree that the necessity for hacks

like these does not speak well for the language.
Eh, any worse than leading "my" or "h" or whatever TF it is that folks use
in whatever those new-fangled languages the kids are using? As Gil wrote,
you can use a digit, but it's fuglier.

It's interesting what we consider new. The three scripting languages I
mentioned in this thread are all in their twenties.

1. Python 1990, 28 years old
2. Lua 1993, 25 years old
3. Ruby 1995, 23 years old.

The unfortunate thing about REXX is that it hasn't improved over the
years. Here's a post from 1995 highlighting features from Object REXX
that would be
useful in classic REXX
http://secure-web.cisco.com/1YnGEhQwx7O7PdtGN_3aG6V0FIu6FFteSQdfJKrwFtIpvJqPNiEBudV4iFeCkYgKEnVqBuyCw1wEd1g4m8LlpOPSHmkupCtgzK_KomOhXuwp12dmt8HXy9KB2stmvJXtD5kzHtZC6yqVLnZfwZ9Ath8ekNDsb2DDOQOEH0wEOu_vQLgMIUAOcQj19TAczOH6j5-F0g9AD04JqNsbqMRsp66EBb2LItITbD4evRhEyvd9Jo4Hmxrg3CCavW2NN0VE-QymEID7N3GTCykAEM-UxkCDaWTZ1GmIx-E__nfUbcasidp7BvUWG1A-6tpim1AAjFgpKwST4D-MIx3mYgpTym9jbtIqDapuaAm9H9RiGupsNQGf8x1I8LD30M-nwtR-AstXm_0_MX2Cp_q-sZkny-B0EqZWtKdtUitbFc4PJmtfioYx6D-mHhCYj4LH14sUS/http%3A%2F%2Fwww.markcrocker.com%2Frexxtipsntricks%2Frxtt28.2.0252.html. The
do/over loop is fantastic and would provide a means to do basic
introspection
on stem variables. Returning stem variables from functions, great!
Little things like that would significantly improve the language.

[1] https://secure-web.cisco.com/1RwInfrp04LptArmkCF0qcWNSECnkLtmYux5OiplFcsa5Z6IxY9A9vymJ3k7NPoWglypHywt8KUJ8qoV-5HJVSMjR-xsj0w2ri59P-Wq0ObJtZE__jyQ4vcJqTqiIjAyZTBzUMyojVCf6OPTYXloAolasgMmUQy4W27vPVebdcrU1HdXwL-LT96Fr9i_-EpfeCLkv412YDwj8Uj3p4yiACvSCCeiQnGAt8gpPQiscHlEc9_zU7rx6XWguV0JAzDp2Ad107WThaqGqsUQkuic3om0xEk95ykaCot7JUoYLLoQfIyEE6Hknb_HdSRReQ93auW3lEGEa4rXepJQyaHNrCmkcwqjIU_NbcB-CckJ0mEG0hhzMvknIndW0sKKzgN0uSGu24IKeQd51YqjwktUIn3YXNeNU3dlARactxPkUuSA5elPp66OYFNvHMWmICA1d/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPython_%28programming_language%29
[2] https://secure-web.cisco.com/1fUvOJ4DfajgztUYwjrB--sp9ei9DaWvmeEdhPZ6VQ7N_BYPOSqMRvZzx10AF41l2KUmIYQTFTq-vE8NZ4F9W8ad6DknmtcDXuyxTkbVP6XYOqESOIXV56gxOmVYWs61iR3I3YDqA5XWjPJnY-W7Bn9SBU0W0rt1RGxd8ek7pSiWpiqW_X293b2XT_XcvaJyE9xPOqjh14fxvRXuUcT2WhB97XfuwMk9YR_oyGCNCzMMzq3ZjMtd1bCtbCYv8AixqfKYgWXYpeONyQhsC24GM5GHc2NfG49jFXK5FzT36af3n9DI70JorSDcggz979ODnLOvkbAfBeV_MPocizlNxLpsoENLFX85zcSbvf6dbQoxtdIVR-jHjboEcDIz_hIGm_ZYVHMaHaQXID3_RDqLy8ZcSLaEefzr3y1RPEum8kwUSAZacfABh9BLyt5yc9MYE/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FLua_%28programming_language%29
[3] https://secure-web.cisco.com/1P_tUisUgBHmJ_xaphDqHsSb6tIOLRI1tfvbZOEXjOHX2r_Efvyt-WYiBI-Go71ellC2yG73nK-9_Aio9vFjr1pbnrpuZM3PfTLj7wAqR4NiNJkxJFo1r8NChS7iUAPlGDQ1bLIjVwm28F_92_fD-JwJk0w0cLMq4whZNGgEZpX0xBeWjF3SMvtULRMAhNDWx3uIjfWNhV-7yKfwuVH9vaT2j3_PLarRgjbrxpI0Pl1bx2YVdoN2_FvDZnXPvikSBb09FDdJS_yravUyD9dzCTjfN2Xft0vRR8pejnPoxuq4-9AmjKFKj3cHh1dfqkfA0CWylI_9Mvw9Binq1eFx3kV-hl3s_bO3i9uVxLVnmBeAw33ViUkuBrjS5qpfqUVF9l0a01a9nrZG4xMveChfaEp7edZOzE_tsHRNxSD3KEl_0DEqGg07-vHF2qj_LCFMd/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRuby_%28programming_language%29

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

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

Paul Gilmartin

2018-05-16 04:07:06 UTC

Post by David Crayford
The unfortunate thing about REXX is that it hasn't improved over the
years. Here's a post from 1995 highlighting features from Object REXX
that would be
useful in classic REXX
http://www.markcrocker.com/rexxtipsntricks/rxtt28.2.0252.html. The
do/over loop is fantastic and would provide a means to do basic
introspection
on stem variables. Returning stem variables from functions, great!
Little things like that would significantly improve the language.

I like that awk accesses environment variables as a pseudo array,
ENVIRON[]. A program can even "do/over" ENVIRON. But this
presumes an orderly implementation of environment variables.

I note that these enhancements add a couple characters, '[' and ']'
to the vocabulary. I suspect Cowlishaw avoided these because they're
troublesome or ambiguous on many mainframe terminals. How many
plaints about baffling syntax errors are answered with "What code page
is your terminal using?"

Is it the intent of OoRexx to avoid changing the semantic of any construct
in standard Rexx? If so:
RETURN STEM.
alters the meaning of that standard Rexx instruction.

Gee. If you import all the neat features of OoRexx into Classic Rexx,
doesn't it become OoRexx? Why not just switch to OoRexx?

Post by David Crayford
[1] https://en.wikipedia.org/wiki/Python_(programming_language)
[2] https://en.wikipedia.org/wiki/Lua_(programming_language)
[3] https://en.wikipedia.org/wiki/Ruby_(programming_language)

-- gil

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

David Crayford

2018-05-16 04:31:00 UTC

Post by Paul Gilmartin
I note that these enhancements add a couple characters, '[' and ']'
to the vocabulary. I suspect Cowlishaw avoided these because they're
troublesome or ambiguous on many mainframe terminals. How many
plaints about baffling syntax errors are answered with "What code page
is your terminal using?"

I hate EBCDIC too! I got an e-mail from someone in Sweden asking if my
z/OS Lua port could handle square brackets in a Scandinavian code page.
In hindsight I should have used UTF8 instead of IBM1047/IBM037. Even the
ISPF editor supports UTF8 these days.

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

61 Replies
20 Views
Permalink to this page
Disable enhanced parsing

Thread Navigation

Kirk Wolf 2018-05-11 15:40:37 UTC

John McKown 2018-05-11 16:06:12 UTC

Seymour J Metz 2018-05-11 16:12:34 UTC

John McKown 2018-05-11 16:34:01 UTC

Steve Smith 2018-05-11 17:34:39 UTC

David Crayford 2018-05-11 18:26:59 UTC

Seymour J Metz 2018-05-13 19:31:29 UTC

Seymour J Metz 2018-05-13 19:38:42 UTC

David Crayford 2018-05-11 18:29:42 UTC

Kirk Wolf 2018-05-11 19:01:03 UTC

Dyck, Lionel B. , TRA 2018-05-11 19:04:10 UTC

Tony Harminc 2018-05-11 22:50:25 UTC

Seymour J Metz 2018-05-13 19:20:02 UTC

Seymour J Metz 2018-05-13 19:28:03 UTC

Seymour J Metz 2018-05-11 16:22:50 UTC

Paul Gilmartin 2018-05-11 16:24:06 UTC

Seymour J Metz 2018-05-13 19:58:39 UTC

David Crayford 2018-05-11 18:20:59 UTC

Tony Thigpen 2018-05-11 22:21:42 UTC

David Crayford 2018-05-12 02:08:18 UTC

Farley, Peter x23353 2018-05-12 16:52:26 UTC

Tony Thigpen 2018-05-12 17:27:55 UTC

Steve Horein 2018-05-12 18:47:44 UTC

Seymour J Metz 2018-05-13 19:15:14 UTC

David Crayford 2018-05-14 05:51:34 UTC

Seymour J Metz 2018-05-14 19:54:06 UTC

Paul Gilmartin 2018-05-11 23:26:19 UTC

Clark Morris 2018-05-12 01:46:30 UTC

David Crayford 2018-05-12 02:09:36 UTC

Paul Gilmartin 2018-05-13 20:43:39 UTC

Seymour J Metz 2018-05-14 20:20:27 UTC

Phil Smith III 2018-05-14 04:02:10 UTC

Seymour J Metz 2018-05-14 19:33:35 UTC

Clark Morris 2018-05-14 21:53:53 UTC

Paul Gilmartin 2018-05-14 15:21:44 UTC

Phil Smith III 2018-05-14 15:38:07 UTC

Charles Mills 2018-05-14 16:19:48 UTC

Mike Schwab 2018-05-14 16:28:04 UTC

Seymour J Metz 2018-05-14 18:51:44 UTC

Seymour J Metz 2018-05-14 19:14:16 UTC

Paul Gilmartin 2018-05-14 17:48:05 UTC

Phil Smith III 2018-05-14 17:51:33 UTC

David Crayford 2018-05-15 04:26:24 UTC

Robert Prins 2018-05-17 15:07:44 UTC

Phil Smith III 2018-05-14 20:24:27 UTC

Seymour J Metz 2018-05-15 17:46:22 UTC

Paul Gilmartin 2018-05-15 04:39:14 UTC

Seymour J Metz 2018-05-16 16:31:41 UTC

Paul Gilmartin 2018-05-15 04:50:55 UTC

David Crayford 2018-05-15 04:55:44 UTC

Charles Mills 2018-05-15 13:27:48 UTC

Dyck, Lionel B. , TRA 2018-05-15 13:33:02 UTC

Edward Gould 2018-05-15 14:08:05 UTC

Dyck, Lionel B. , TRA 2018-05-15 14:14:19 UTC

Gord Tomlin 2018-05-15 14:27:34 UTC

Chris Hoelscher 2018-05-15 14:47:26 UTC

Seymour J Metz 2018-05-15 17:39:52 UTC

Phil Smith III 2018-05-15 18:39:46 UTC

David Crayford 2018-05-16 02:46:18 UTC

Seymour J Metz 2018-05-16 16:23:13 UTC

Paul Gilmartin 2018-05-16 04:07:06 UTC

David Crayford 2018-05-16 04:31:00 UTC

about - legalese

Loading...