Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Mike Schwab]

https://github.com/CBTTape/CBT993

Probably other CBT tape members to process.

On Sun, Mar 17, 2024 at 7:11 PM Rupert Reynolds  wrote:
>
> SMF logging of data for management information? I never did much with SMF,
> but I can't see why not.
>
> I did briefly consider being able to parse existing mapping macros, but
> that's bound to be a bigger job than it seems, especially now I'm a bit
> rusty and only have Hercules to play with.
>
> Structures (maybe 'map' because 'str' is already short for the most basic
> type of 'string'). And pointers to them, yes. Wouldn't be without them :-)
>
> I'll probably be old and slow, or losing my concentration, before it's even
> half finished. Still, it keeps me out of mischief when I'm not at work or
> converting the van for mobile glamping  :-)
>
> Roops
>
> On Sun, 17 Mar 2024, 18:31 Seymour J Metz,  wrote:
>
> > I probably would use ":=" for assignment and "=" for equality.
> >
> > Are you supporting SMF-like structures?
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> > עַם יִשְׂרָאֵל חַי
> > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Rupert Reynolds 
> > Sent: Sunday, March 17, 2024 2:08 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> > question
> >
> > It's too soon to publish much, especially when I have a full time job doing
> > something else. To be honest I probably never will, because it only suits
> > my pet bigotries :-)
> >
> > But briefly, I looked at day 1 notes (on back of a gas bill). They included
> > these, not all of which will ever make it into use of course:
> >
> > . fairly terse {} syntax, borrowing from 'C' etc.
> >
> > . strongly typed by default
> >
> > . one type is bignum--arbitrary precision and base arithmetic, trig, logs
> >
> > . correctness and flexibility more important than speed (like external
> > functions in Rexx scripts, for example)
> >
> > . project to include thorough test cases, and any bugs/unintended quirks in
> > either impl or tests will be fixed ruthlessly, not supported. If it fails
> > the test, it is not the real thing.
> >
> > . compiled code could include interpreter for scripting
> >
> > . preserves case, but keywords and functions etc. not case sensitive
> >
> > . all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
> > same as 'function')
> >
> > . '=' not required for assignment!
> >
> > . ability to convert 'C' style strings and call 'C' code
> >
> > . all built-in functions for handling null-terminated data and UTF-16 to be
> > prefixed gk_ (short for "ghastly kludge" ;-) )
> >
> > Feel free to laugh/crjticise, but please be kind--I was drinking during
> > lockdown when I finished that list :-)
> >
> > I made some progress on the bignum logarithms and trig early, borrowing
> > heavily on the external Rexx functions I used under Windows.
> >
> > It does basics such as finding and moving files interpreted, so I can use
> > it to test my Rexx admin scripts, and vice versa, but there are *huge*
> > gaps, and I'm moving house this year, so... :-)
> >
> > Roops
> >
> >
> > On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:
> >
> > > >  I'm developing a language
> > >
> > > Have you published any details?
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > > עַם יִשְׂרָאֵל חַי
> > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on behalf
> > > of Rupert Reynolds 
> > > Sent: Saturday, March 16, 2024 9:07 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> > > question
> > >
> > > My experience of modern scripting languages, compared with classic Rexx,
> > is
> > > that they all do something new more easily, but also I can't think of one
> > > that doesn't have an obvious pitfall (such as, for example, stumbling
> > badly
> > > over certain byte values such as NUL in strings).
> > >
> > > Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> > > certain old-fashioned quirks, are still s

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Rupert Reynolds]

SMF logging of data for management information? I never did much with SMF,
but I can't see why not.

I did briefly consider being able to parse existing mapping macros, but
that's bound to be a bigger job than it seems, especially now I'm a bit
rusty and only have Hercules to play with.

Structures (maybe 'map' because 'str' is already short for the most basic
type of 'string'). And pointers to them, yes. Wouldn't be without them :-)

I'll probably be old and slow, or losing my concentration, before it's even
half finished. Still, it keeps me out of mischief when I'm not at work or
converting the van for mobile glamping  :-)

Roops

On Sun, 17 Mar 2024, 18:31 Seymour J Metz,  wrote:

> I probably would use ":=" for assignment and "=" for equality.
>
> Are you supporting SMF-like structures?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Rupert Reynolds 
> Sent: Sunday, March 17, 2024 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> question
>
> It's too soon to publish much, especially when I have a full time job doing
> something else. To be honest I probably never will, because it only suits
> my pet bigotries :-)
>
> But briefly, I looked at day 1 notes (on back of a gas bill). They included
> these, not all of which will ever make it into use of course:
>
> . fairly terse {} syntax, borrowing from 'C' etc.
>
> . strongly typed by default
>
> . one type is bignum--arbitrary precision and base arithmetic, trig, logs
>
> . correctness and flexibility more important than speed (like external
> functions in Rexx scripts, for example)
>
> . project to include thorough test cases, and any bugs/unintended quirks in
> either impl or tests will be fixed ruthlessly, not supported. If it fails
> the test, it is not the real thing.
>
> . compiled code could include interpreter for scripting
>
> . preserves case, but keywords and functions etc. not case sensitive
>
> . all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
> same as 'function')
>
> . '=' not required for assignment!
>
> . ability to convert 'C' style strings and call 'C' code
>
> . all built-in functions for handling null-terminated data and UTF-16 to be
> prefixed gk_ (short for "ghastly kludge" ;-) )
>
> Feel free to laugh/crjticise, but please be kind--I was drinking during
> lockdown when I finished that list :-)
>
> I made some progress on the bignum logarithms and trig early, borrowing
> heavily on the external Rexx functions I used under Windows.
>
> It does basics such as finding and moving files interpreted, so I can use
> it to test my Rexx admin scripts, and vice versa, but there are *huge*
> gaps, and I'm moving house this year, so... :-)
>
> Roops
>
>
> On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:
>
> > >  I'm developing a language
> >
> > Have you published any details?
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> > עַם יִשְׂרָאֵל חַי
> > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf
> > of Rupert Reynolds 
> > Sent: Saturday, March 16, 2024 9:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> > question
> >
> > My experience of modern scripting languages, compared with classic Rexx,
> is
> > that they all do something new more easily, but also I can't think of one
> > that doesn't have an obvious pitfall (such as, for example, stumbling
> badly
> > over certain byte values such as NUL in strings).
> >
> > Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> > certain old-fashioned quirks, are still sometimes what I reach for when I
> > want to process some data while avoiding those pitfalls.
> >
> > The differences are so strong to me that I'm developing a language which
> is
> > effectively the best bits (IMHO) of Rexx, C and even older languages such
> > as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> > that much effort without reason :-)
> >
> > By definition it works the same interpreted or compiled, which brings a
> > couple of restrictions I'm willing to live with :-)
> >
> > Roops
> > p.s. I'm not convinced that that familiarity is a reason to criticise
> > choosing a lan

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

I probably would use ":=" for assignment and "=" for equality.

Are you supporting SMF-like structures?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Rupert Reynolds 
Sent: Sunday, March 17, 2024 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

It's too soon to publish much, especially when I have a full time job doing
something else. To be honest I probably never will, because it only suits
my pet bigotries :-)

But briefly, I looked at day 1 notes (on back of a gas bill). They included
these, not all of which will ever make it into use of course:

. fairly terse {} syntax, borrowing from 'C' etc.

. strongly typed by default

. one type is bignum--arbitrary precision and base arithmetic, trig, logs

. correctness and flexibility more important than speed (like external
functions in Rexx scripts, for example)

. project to include thorough test cases, and any bugs/unintended quirks in
either impl or tests will be fixed ruthlessly, not supported. If it fails
the test, it is not the real thing.

. compiled code could include interpreter for scripting

. preserves case, but keywords and functions etc. not case sensitive

. all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
same as 'function')

. '=' not required for assignment!

. ability to convert 'C' style strings and call 'C' code

. all built-in functions for handling null-terminated data and UTF-16 to be
prefixed gk_ (short for "ghastly kludge" ;-) )

Feel free to laugh/crjticise, but please be kind--I was drinking during
lockdown when I finished that list :-)

I made some progress on the bignum logarithms and trig early, borrowing
heavily on the external Rexx functions I used under Windows.

It does basics such as finding and moving files interpreted, so I can use
it to test my Rexx admin scripts, and vice versa, but there are *huge*
gaps, and I'm moving house this year, so... :-)

Roops


On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:

> >  I'm developing a language
>
> Have you published any details?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Rupert Reynolds 
> Sent: Saturday, March 16, 2024 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> question
>
> My experience of modern scripting languages, compared with classic Rexx, is
> that they all do something new more easily, but also I can't think of one
> that doesn't have an obvious pitfall (such as, for example, stumbling badly
> over certain byte values such as NUL in strings).
>
> Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> certain old-fashioned quirks, are still sometimes what I reach for when I
> want to process some data while avoiding those pitfalls.
>
> The differences are so strong to me that I'm developing a language which is
> effectively the best bits (IMHO) of Rexx, C and even older languages such
> as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> that much effort without reason :-)
>
> By definition it works the same interpreted or compiled, which brings a
> couple of restrictions I'm willing to live with :-)
>
> Roops
> p.s. I'm not convinced that that familiarity is a reason to criticise
> choosing a language. Using something you know well is often a way of giving
> bettet value and reliability for ones employers.
>
>
>
>
>
> On Sat, 16 Mar 2024, 11:49 David Crayford, <
> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Hey Rony,
> >
> > From what I understand, you haven't had experience working on z/OS. Let's
> > stick to the topic and focus on discussing REXX as it functions on z/OS.
> > This means no discussions about ooRexx or Java bridges, as they don't
> exist
> > and are unlikely to in the future on z/OS.
> >
> > The majority of REXX programmers here utilize classic TSO REXX and
> > primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> > module system. Therefore, any routines or libraries need to be manually
> > copied and pasted wherever they're needed, or you have to create a
> > pre-processor to merge source files together. If your language lacks the
> > fundamental basic features to sort an array then to me that’s a good
> > indication you should use one that does.
> >
&

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Rupert Reynolds]

It's too soon to publish much, especially when I have a full time job doing
something else. To be honest I probably never will, because it only suits
my pet bigotries :-)

But briefly, I looked at day 1 notes (on back of a gas bill). They included
these, not all of which will ever make it into use of course:

. fairly terse {} syntax, borrowing from 'C' etc.

. strongly typed by default

. one type is bignum--arbitrary precision and base arithmetic, trig, logs

. correctness and flexibility more important than speed (like external
functions in Rexx scripts, for example)

. project to include thorough test cases, and any bugs/unintended quirks in
either impl or tests will be fixed ruthlessly, not supported. If it fails
the test, it is not the real thing.

. compiled code could include interpreter for scripting

. preserves case, but keywords and functions etc. not case sensitive

. all keywords can be abbreviated (eg. if min abbreviation is 3, 'fun' is
same as 'function')

. '=' not required for assignment!

. ability to convert 'C' style strings and call 'C' code

. all built-in functions for handling null-terminated data and UTF-16 to be
prefixed gk_ (short for "ghastly kludge" ;-) )

Feel free to laugh/crjticise, but please be kind--I was drinking during
lockdown when I finished that list :-)

I made some progress on the bignum logarithms and trig early, borrowing
heavily on the external Rexx functions I used under Windows.

It does basics such as finding and moving files interpreted, so I can use
it to test my Rexx admin scripts, and vice versa, but there are *huge*
gaps, and I'm moving house this year, so... :-)

Roops


On Sun, 17 Mar 2024, 16:58 Seymour J Metz,  wrote:

> >  I'm developing a language
>
> Have you published any details?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Rupert Reynolds 
> Sent: Saturday, March 16, 2024 9:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation
> question
>
> My experience of modern scripting languages, compared with classic Rexx, is
> that they all do something new more easily, but also I can't think of one
> that doesn't have an obvious pitfall (such as, for example, stumbling badly
> over certain byte values such as NUL in strings).
>
> Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
> certain old-fashioned quirks, are still sometimes what I reach for when I
> want to process some data while avoiding those pitfalls.
>
> The differences are so strong to me that I'm developing a language which is
> effectively the best bits (IMHO) of Rexx, C and even older languages such
> as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
> that much effort without reason :-)
>
> By definition it works the same interpreted or compiled, which brings a
> couple of restrictions I'm willing to live with :-)
>
> Roops
> p.s. I'm not convinced that that familiarity is a reason to criticise
> choosing a language. Using something you know well is often a way of giving
> bettet value and reliability for ones employers.
>
>
>
>
>
> On Sat, 16 Mar 2024, 11:49 David Crayford, <
> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Hey Rony,
> >
> > From what I understand, you haven't had experience working on z/OS. Let's
> > stick to the topic and focus on discussing REXX as it functions on z/OS.
> > This means no discussions about ooRexx or Java bridges, as they don't
> exist
> > and are unlikely to in the future on z/OS.
> >
> > The majority of REXX programmers here utilize classic TSO REXX and
> > primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> > module system. Therefore, any routines or libraries need to be manually
> > copied and pasted wherever they're needed, or you have to create a
> > pre-processor to merge source files together. If your language lacks the
> > fundamental basic features to sort an array then to me that’s a good
> > indication you should use one that does.
> >
> > I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating
> > my observations based on over 30 years of using REXX on z/OS, including
> > developing extensions. I believe this gives me a significant level of
> > expertise to offer commentary on the matter.
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
&

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

Every language has warts, including PL/I and REXX, but I believe that they are 
the best choices for writing ISPF dialogs, especially if you are allowed to use 
PCRE.

I don't supposed that a fully supported IBM port of Ruby to z/OS will ever 
happen, but it would catch my eye if it did. Likewise replacing the current 
backlevel REXX with ooRexx.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
David Crayford <0595a051454b-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, March 16, 2024 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

Hey Rony,

From what I understand, you haven't had experience working on z/OS. Let's stick 
to the topic and focus on discussing REXX as it functions on z/OS. This means 
no discussions about ooRexx or Java bridges, as they don't exist and are 
unlikely to in the future on z/OS.

The majority of REXX programmers here utilize classic TSO REXX and primarily 
work within a TSO/ISPF environment. In this setup, REXX lacks a module system. 
Therefore, any routines or libraries need to be manually copied and pasted 
wherever they're needed, or you have to create a pre-processor to merge source 
files together. If your language lacks the fundamental basic features to sort 
an array then to me that’s a good indication you should use one that does.

I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating my 
observations based on over 30 years of using REXX on z/OS, including developing 
extensions. I believe this gives me a significant level of expertise to offer 
commentary on the matter.


> On 16 Mar 2024, at 6:03 pm, Rony G. Flatscher  wrote:
>
> On 16.03.2024 01:17, David Crayford wrote:
>>> On 16 Mar 2024, at 7:45 am, Jay 
>>> Maynard<05997213d6c2-dmarc-requ...@listserv.ua.edu>  wrote:
>>>
>>> That depends. Can you use, say, Python to implement all the scripting kinds
>>> of things you can use REXX for?
>> Like what, TSO? I don’t find I need to do that any more as I work in a UNIX 
>> shell. Let me flip that around. Can I use REXX to implement the kind of 
>> scripting that I do in Python? For example, process a YAML configuration 
>> file.
> Yes, if you wanted, it is fairly easy BTW and would not be as potentially 
> dangerous if done in REXX than done with Perl or Python (cf. 
> <https://en.wikipedia.org/wiki/YAML#Security>).
>> We need to do that stuff on z/OS now. CICS resource definitions can be 
>> defined as YAML documents, configuration as code and all that stuff. DevOps, 
>> Git repos. REXX is a pretty poor language for anything modern.
>
> Again, unsubstantiated and derogative, please just stop behaving like a 
> religious warrior and stick to facts and discuss sorberly, stop your FUD 
> please!
>
>> IBM and ISVs are working on Python APIs for products right now.
> That is fine. On slides and in imaginations everything in the future is 
> always much better than what is available at present.
>> And they will be better than the REXX versions.
>
> Well, that has yet to be seen. If improvements materialize, then it would a) 
> be fine and b) be a reason to look into the existing, working REXX versions 
> for the same improvements then.
>
> A massive improvement for the mainframes were to make ooRexx available on 
> them.
>
> Combine ooRexx with the ooRexx-Java bridge and software engineers have 
> immediately gained the ability to use *any* Java API from ooRexx, without a 
> need to learn Java at all, it suffices to be able to read the HTML 
> documentation of Java classes. The easiness and the productivity gains can be 
> inferred if you know that my novices can do this successfully during the last 
> two months of the semester even becoming able to exploit the SSL/TLS Java 
> socket classes, besides awt/swing, JavaFX and some more.
>
> The potential savings for the mainframe users would be enormeous if they 
> started to exploit that combination. It is actually available already today 
> in the Linux subsystems such that one can assess the technology (I know of 
> deployments that exploit this combination in production, using ooRexx to run 
> programs that interact with DB2 using JDBC).
>
> ---rony
>
>>> On Fri, Mar 15, 2024 at 6:36 PM David Crayford <
>>> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>>>
>>>> Working with REXX doesn't feel comfortable to me at all. I'm troubled by
>>>> the fact that every function call carries a potential side effect. While we
>>>> can resort to procedures, we then encounter the challen

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

>  I'm developing a language

Have you published any details?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Rupert Reynolds 
Sent: Saturday, March 16, 2024 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

My experience of modern scripting languages, compared with classic Rexx, is
that they all do something new more easily, but also I can't think of one
that doesn't have an obvious pitfall (such as, for example, stumbling badly
over certain byte values such as NUL in strings).

Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
certain old-fashioned quirks, are still sometimes what I reach for when I
want to process some data while avoiding those pitfalls.

The differences are so strong to me that I'm developing a language which is
effectively the best bits (IMHO) of Rexx, C and even older languages such
as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
that much effort without reason :-)

By definition it works the same interpreted or compiled, which brings a
couple of restrictions I'm willing to live with :-)

Roops
p.s. I'm not convinced that that familiarity is a reason to criticise
choosing a language. Using something you know well is often a way of giving
bettet value and reliability for ones employers.





On Sat, 16 Mar 2024, 11:49 David Crayford, <
0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:

> Hey Rony,
>
> From what I understand, you haven't had experience working on z/OS. Let's
> stick to the topic and focus on discussing REXX as it functions on z/OS.
> This means no discussions about ooRexx or Java bridges, as they don't exist
> and are unlikely to in the future on z/OS.
>
> The majority of REXX programmers here utilize classic TSO REXX and
> primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> module system. Therefore, any routines or libraries need to be manually
> copied and pasted wherever they're needed, or you have to create a
> pre-processor to merge source files together. If your language lacks the
> fundamental basic features to sort an array then to me that’s a good
> indication you should use one that does.
>
> I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating
> my observations based on over 30 years of using REXX on z/OS, including
> developing extensions. I believe this gives me a significant level of
> expertise to offer commentary on the matter.
>
>

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


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

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Seymour J Metz]

On z/Linux? Already here? In TSO? I wish, but won't hold my breathe.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges <0587168ababf-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, March 16, 2024 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation 
question

Surely that's moon-pie and dreamscapes?  There's no serious suggestion that 
that will ever happen, is there?  I'm all for it, but don't expect it ever.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Sometimes you feel like a nut.  After a day of working on a walnut farm, you 
don't.  -Mike Rowe of the TV show "Dirty Jobs" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rony G. Flatscher
Sent: Saturday, March 16, 2024 06:03

A massive improvement for the mainframes were to make ooRexx available on them.

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


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

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Bob Bridges]

Surely that's moon-pie and dreamscapes?  There's no serious suggestion that 
that will ever happen, is there?  I'm all for it, but don't expect it ever.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Sometimes you feel like a nut.  After a day of working on a walnut farm, you 
don't.  -Mike Rowe of the TV show "Dirty Jobs" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rony G. Flatscher
Sent: Saturday, March 16, 2024 06:03

A massive improvement for the mainframes were to make ooRexx available on them.

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

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Rupert Reynolds]

My experience of modern scripting languages, compared with classic Rexx, is
that they all do something new more easily, but also I can't think of one
that doesn't have an obvious pitfall (such as, for example, stumbling badly
over certain byte values such as NUL in strings).

Classic Rexx under TSO and Regina Rexx under Windows and Linux, despite
certain old-fashioned quirks, are still sometimes what I reach for when I
want to process some data while avoiding those pitfalls.

The differences are so strong to me that I'm developing a language which is
effectively the best bits (IMHO) of Rexx, C and even older languages such
as Algol 68 (much underrated in my book) and hints of PL/1. I don't make
that much effort without reason :-)

By definition it works the same interpreted or compiled, which brings a
couple of restrictions I'm willing to live with :-)

Roops
p.s. I'm not convinced that that familiarity is a reason to criticise
choosing a language. Using something you know well is often a way of giving
bettet value and reliability for ones employers.





On Sat, 16 Mar 2024, 11:49 David Crayford, <
0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:

> Hey Rony,
>
> From what I understand, you haven't had experience working on z/OS. Let's
> stick to the topic and focus on discussing REXX as it functions on z/OS.
> This means no discussions about ooRexx or Java bridges, as they don't exist
> and are unlikely to in the future on z/OS.
>
> The majority of REXX programmers here utilize classic TSO REXX and
> primarily work within a TSO/ISPF environment. In this setup, REXX lacks a
> module system. Therefore, any routines or libraries need to be manually
> copied and pasted wherever they're needed, or you have to create a
> pre-processor to merge source files together. If your language lacks the
> fundamental basic features to sort an array then to me that’s a good
> indication you should use one that does.
>
> I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating
> my observations based on over 30 years of using REXX on z/OS, including
> developing extensions. I believe this gives me a significant level of
> expertise to offer commentary on the matter.
>
>

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

Re: Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[David Crayford]

Hey Rony,

From what I understand, you haven't had experience working on z/OS. Let's stick 
to the topic and focus on discussing REXX as it functions on z/OS. This means 
no discussions about ooRexx or Java bridges, as they don't exist and are 
unlikely to in the future on z/OS.

The majority of REXX programmers here utilize classic TSO REXX and primarily 
work within a TSO/ISPF environment. In this setup, REXX lacks a module system. 
Therefore, any routines or libraries need to be manually copied and pasted 
wherever they're needed, or you have to create a pre-processor to merge source 
files together. If your language lacks the fundamental basic features to sort 
an array then to me that’s a good indication you should use one that does. 

I'm not spreading fear, uncertainty, and doubt (FUD). I'm simply stating my 
observations based on over 30 years of using REXX on z/OS, including developing 
extensions. I believe this gives me a significant level of expertise to offer 
commentary on the matter.


> On 16 Mar 2024, at 6:03 pm, Rony G. Flatscher  wrote:
> 
> On 16.03.2024 01:17, David Crayford wrote:
>>> On 16 Mar 2024, at 7:45 am, Jay 
>>> Maynard<05997213d6c2-dmarc-requ...@listserv.ua.edu>  wrote:
>>> 
>>> That depends. Can you use, say, Python to implement all the scripting kinds
>>> of things you can use REXX for?
>> Like what, TSO? I don’t find I need to do that any more as I work in a UNIX 
>> shell. Let me flip that around. Can I use REXX to implement the kind of 
>> scripting that I do in Python? For example, process a YAML configuration 
>> file.
> Yes, if you wanted, it is fairly easy BTW and would not be as potentially 
> dangerous if done in REXX than done with Perl or Python (cf. 
> ).
>> We need to do that stuff on z/OS now. CICS resource definitions can be 
>> defined as YAML documents, configuration as code and all that stuff. DevOps, 
>> Git repos. REXX is a pretty poor language for anything modern.
> 
> Again, unsubstantiated and derogative, please just stop behaving like a 
> religious warrior and stick to facts and discuss sorberly, stop your FUD 
> please!
> 
>> IBM and ISVs are working on Python APIs for products right now.
> That is fine. On slides and in imaginations everything in the future is 
> always much better than what is available at present.
>> And they will be better than the REXX versions.
> 
> Well, that has yet to be seen. If improvements materialize, then it would a) 
> be fine and b) be a reason to look into the existing, working REXX versions 
> for the same improvements then.
> 
> A massive improvement for the mainframes were to make ooRexx available on 
> them.
> 
> Combine ooRexx with the ooRexx-Java bridge and software engineers have 
> immediately gained the ability to use *any* Java API from ooRexx, without a 
> need to learn Java at all, it suffices to be able to read the HTML 
> documentation of Java classes. The easiness and the productivity gains can be 
> inferred if you know that my novices can do this successfully during the last 
> two months of the semester even becoming able to exploit the SSL/TLS Java 
> socket classes, besides awt/swing, JavaFX and some more.
> 
> The potential savings for the mainframe users would be enormeous if they 
> started to exploit that combination. It is actually available already today 
> in the Linux subsystems such that one can assess the technology (I know of 
> deployments that exploit this combination in production, using ooRexx to run 
> programs that interact with DB2 using JDBC).
> 
> ---rony
> 
>>> On Fri, Mar 15, 2024 at 6:36 PM David Crayford <
>>> 0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
 Working with REXX doesn't feel comfortable to me at all. I'm troubled by
 the fact that every function call carries a potential side effect. While we
 can resort to procedures, we then encounter the challenge of dealing with
 telescoping exposure lists. When I hear about adapting to quirks, it seems
 to translate to "I acknowledge REXX's flaws, but I stick with it because
 it's what I'm familiar with, even if I have to tolerate it.” The recent
 discussions on this forum have brought attention to the shortcomings and
 limitations of REXX as a programming language.
 
 In comparison to other platforms, Z/OS used to offer limited options in
 terms of programming languages. However, that's no longer the case. What
 struck me as ironic during my recent presentation was that the majority of
 the audience were millennials who were unfamiliar with REXX. This might
 come as a surprise to seasoned veterans of mainframes who are used to REXX,
 but in today's landscape, familiarity with it isn't necessary.
 
> On 16 Mar 2024, at 7:19 am, Seymour J Metz  wrote:
> 
> Every language has pitfalls. While I generally prefer strongly typed
 languages, I find Rexx and ooRexx to be comfortable to 

Hmm, 3 ... (Re: Rexx numeric digits and scientific notation question

[Rony G. Flatscher]

On 16.03.2024 01:17, David Crayford wrote:

On 16 Mar 2024, at 7:45 am, Jay 
Maynard<05997213d6c2-dmarc-requ...@listserv.ua.edu>  wrote:

That depends. Can you use, say, Python to implement all the scripting kinds
of things you can use REXX for?

Like what, TSO? I don’t find I need to do that any more as I work in a UNIX 
shell. Let me flip that around. Can I use REXX to implement the kind of 
scripting that I do in Python? For example, process a YAML configuration file.
Yes, if you wanted, it is fairly easy BTW and would not be as potentially dangerous if done in REXX 
than done with Perl or Python (cf. ).

We need to do that stuff on z/OS now. CICS resource definitions can be defined 
as YAML documents, configuration as code and all that stuff. DevOps, Git repos. 
REXX is a pretty poor language for anything modern.


Again, unsubstantiated and derogative, please just stop behaving like a religious warrior and stick 
to facts and discuss sorberly, stop your FUD please!



IBM and ISVs are working on Python APIs for products right now.
That is fine. On slides and in imaginations everything in the future is always much better than what 
is available at present.

And they will be better than the REXX versions.


Well, that has yet to be seen. If improvements materialize, then it would a) be fine and b) be a 
reason to look into the existing, working REXX versions for the same improvements then.


A massive improvement for the mainframes were to make ooRexx available on them.

Combine ooRexx with the ooRexx-Java bridge and software engineers have immediately gained the 
ability to use *any* Java API from ooRexx, without a need to learn Java at all, it suffices to be 
able to read the HTML documentation of Java classes. The easiness and the productivity gains can be 
inferred if you know that my novices can do this successfully during the last two months of the 
semester even becoming able to exploit the SSL/TLS Java socket classes, besides awt/swing, JavaFX 
and some more.


The potential savings for the mainframe users would be enormeous if they started to exploit that 
combination. It is actually available already today in the Linux subsystems such that one can assess 
the technology (I know of deployments that exploit this combination in production, using ooRexx to 
run programs that interact with DB2 using JDBC).


---rony


On Fri, Mar 15, 2024 at 6:36 PM David Crayford <
0595a051454b-dmarc-requ...@listserv.ua.edu> wrote:


Working with REXX doesn't feel comfortable to me at all. I'm troubled by
the fact that every function call carries a potential side effect. While we
can resort to procedures, we then encounter the challenge of dealing with
telescoping exposure lists. When I hear about adapting to quirks, it seems
to translate to "I acknowledge REXX's flaws, but I stick with it because
it's what I'm familiar with, even if I have to tolerate it.” The recent
discussions on this forum have brought attention to the shortcomings and
limitations of REXX as a programming language.

In comparison to other platforms, Z/OS used to offer limited options in
terms of programming languages. However, that's no longer the case. What
struck me as ironic during my recent presentation was that the majority of
the audience were millennials who were unfamiliar with REXX. This might
come as a surprise to seasoned veterans of mainframes who are used to REXX,
but in today's landscape, familiarity with it isn't necessary.


On 16 Mar 2024, at 7:19 am, Seymour J Metz  wrote:

Every language has pitfalls. While I generally prefer strongly typed

languages, I find Rexx and ooRexx to be comfortable to work with, and it is
not difficult to adapt to its quirks:




--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on

behalf of David Crayford<0595a051454b-dmarc-requ...@listserv.ua.edu>

Sent: Friday, March 15, 2024 6:40 PM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx numeric digits and scientific notation question

REXX can indeed be quite tricky to navigate. I recently conducted a

session titled "Python for REXX programmers" at work, and during the
preparation, I was surprised (although not entirely) by the numerous traps
and pitfalls inherent in REXX. When you add to this its absence of basic
functionalities like sorting lists, it begs the question: Why opt for REXX
when we have a plethora of alternatives available today?

The obvious answer may be familiarity, but in our industry, this

argument seems rather weak unless you're confined to a limited environment.
After all, I wouldn't want to revert to using a 1990s-era flip-top phone,
let alone a rotary dial from the 1970s.

On 16 Mar 2024, at 2:47 am, Charles Mills  wrote:

Well, that