Re: REXX, ooRexx, BSF4ooRExx (Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rony G. Flatscher]

On 08.03.2023 02:30, David Crayford wrote:

On 8/3/23 02:26, Rony G. Flatscher wrote:
There also appears to be bugs in SysThread where the "attached" member variable is not 
initialized in the constructor that takes a pthread_t argument.


Ah, interesting that this is regarded a stumbling block, how about pthread_getunique_np() or such 
then?



Obviously, the "_np" suffix stands for "non-portable". It doesn't exist on z/OS! I happen to know 
the internal structure of the opaque pthread_t structure on z/OS and to extract the thread ID (TCB 
address) one would implement something like:


int gettid() { return (int)(pthread_self().__ & 0x7fff); }


Erich, a developer, has applied a fix that should make it possible to get over this on z/OS with an 
elegant solution, here his respective comment:


   Committed code fix with revision [r12649]
   As reported by David Crayford, pthread_t is a struct on z/OS and setting or 
casting it, fails

Good luck with your next attempt to compile ooRexx on z/OS and please let us 
know how you fare!
:)

---rony


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

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Seymour J Metz]

There is lots of Rexx off of the mainframe; it just doesn't get much press. I 
just wish that it had native regexen with named captures.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Tuesday, March 7, 2023 10:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: 
Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

On 7/3/23 16:59, René Jansen wrote:
> On 7 Mar 2023, at 08:45, David Crayford  wrote:
>> The industry has spoken! Python is the most popular programming language in 
>> the world so haters will have to just suck that up.
> That is a very funny statement. Nobody hates Python - the hype will blow over 
> like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons of 
> COBOL around, like there will be tons of Rexx around for ages.

Agreed. And there is lots of REXX on the mainframe.


>
> While we do not hate Python (it was a great television series in the 
> seventies) we can do without the attacks on Rexx. Like the JCL replacement 
> from IBM’s Clunkification department, the examples will speak for themselves. 
> Look at it in all its glory, coming in at 190 lines plus lots of imported 
> zooutils, at 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FIBM%2Fzoau-samples%2Fblob%2Fmain%2Fsamples%2Fsmpe_list.py=05%7C01%7Csmetz3%40gmu.edu%7C60e13f4a45264c70f77308db1f86c60f%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638138435933107600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jTeCGpNTGInuvsu3RPGPfVlZVphY%2BJu%2FZMkmw%2F%2ByUMs%3D=0
>  - it replaces about 15 lines of JCL. If that was meant to undercut the 
> credibility of Python, it is a very, very clever attempt by an old mainframer.
>
> If I now ask ChatGPT for a script to list some SMP/E zones, it shows me:
>
> /* REXX program to list the status of all SYSMODs */
>
> /* Set up the SMP/E commands to be executed */
> smp_cmds.1 = "SET BDY(GLOBAL)."
> smp_cmds.2 = "LIST SYSMOD(*) WHERE(SYMBOLICDATE GT 0)."
> smp_cmds.3 = "SET BDY(LOCAL)."
>
> /* Write the SMP/E commands to a temporary data set */
> "ALLOC F(SMPCMD) NEW REUSE SPACE(80 80) TRK"
> do i = 1 to smp_cmds.0
>"EXECIO 1 DISKW SMPCMD (STEM smp_cmds. " i ")"
> end
> "FREE F(SMPCMD)"
>
> /* Invoke SMP/E to execute the commands */
> "ADDRESS TSO"
> "CALL 'SYS1.SMP.EB2A.EXEC(SMPXMSGS)'"
> "EXECIO 0 DISKR SMPXMSGS (STEM smp_msgs. FINIS)"
> "FREE F(SMPXMSGS)"
>
> /* Display the results */
> do i = 1 to smp_msgs.0
>say smp_msgs.i
> end

There's bugs in that code ;)


>
> I rest my case. Still not sure why JCL needs to be replaced but hey.

100% agree. Can't say I'm a big fan of JCL but it does the job.


> The curious case with Rexx is that it has been under attack from the 
> beginning, like all good things within IBM, like VM and JES2. Later, in OS/2, 
> it was relentlessly attacked by Microsoft and almost left out of it, only to 
> be introduced in the IBM EE “Extended Edition”, possibly because it was 
> better than BASIC of the day.

Interesting. I know it seems like I'm always attacking REXX but I would
suggest that I'm criticizing, not attacking. I used to work on NetMaster
back in the 90s and danced a jig of joy when I could use REXX instead of
NCL. I ways also delighted when ISPF supported inline REXX panel exits
so I could avoid horrible panel logic.

These days I spend most of my time on z/OS using a bash shell. I have
written REXX scripts that use the SDSF API to interact with the spool,
console etc. I also like REXX to write scripts that call batch programs
redirecting the output to stdout/stderr etc so I can spawn batch
utilities from UNIX processes such as Java web servers. For short
scripts REXX is an excellent language. However, I don't think it scales.
One glance at the ISPF DTL compiler which is 42KLOC confirms this.

/* REXX */

parse arg script_file
if script_file = '' then do
   "Usage: kciomega "
   exit 2
end

call syscalls 'ON'
address syscall 'realpath . cwd'
address syscall 'realpath 'script_file' script_file'

call BPXWDYN("ALLOC DD(SYSPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY)
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(SYSOUT) PATH('/dev/fd2') PATHOPTS(OWRONLY)
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY)
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIFLOW) PATH('"script_file"') FILEDATA(TEXT)
PATHOPTS(ORDONLY) MSG(2) REU

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Seymour J Metz]

> I did not know the DTL compiler was written in Rexx. I did never like it

I liked DTL, and used it when appropriate, although I did a lot by hand. You 
have to carve the bird at its joints.

> I would applaud a Unicode-only strategy for new software 

++

> Also, PDS and ZFS could have been integrated way earlier but the problem 
> seems to be vision. 

Way back when, after IBM introduced VSAM and VTAM, I thought that an ACB-based 
strategy was a no-brainer. Despite the precednt of a Reverse Compatibility 
Interface in OS/VS1, IBM clearly did not see it that way.

> About those LLVM/Clang ports:

Licensing is complicated, and a clear answer requires specifying the specific 
license, but in general you have to make the source code available for those 
parts covered by the open source license. There are massive differences between 
the terms of, e.g., GPL and bsd.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
René Jansen [rene.vincent.jan...@gmail.com]
Sent: Wednesday, March 8, 2023 4:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: 
Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

> On 8 Mar 2023, at 04:39, David Crayford  wrote:
>
> On 7/3/23 16:59, René Jansen wrote:
>> On 7 Mar 2023, at 08:45, David Crayford > <mailto:dcrayf...@gmail.com>> wrote:
>>> The industry has spoken! Python is the most popular programming language in 
>>> the world so haters will have to just suck that up.
>> That is a very funny statement. Nobody hates Python - the hype will blow 
>> over like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons 
>> of COBOL around, like there will be tons of Rexx around for ages.
>
> Agreed. And there is lots of REXX on the mainframe.
>
>
>
> There's bugs in that code ;)

That’s ChatGPT, it is a bit like a bullshitter consultant.
>
>
>>
>> I rest my case. Still not sure why JCL needs to be replaced but hey.
>
> 100% agree. Can't say I'm a big fan of JCL but it does the job.
>

So the question is why the self hate (in the sense of wilful deprecation of own 
history and intellectual/cultural heritage) with IBM has reached the levels 
that it attacks JCL and the Rexx scripts that not even need to replace JCL. 
It’s hip to be square, and lots of people want to learn ‘mainframe’ - or have a 
course in ‘3270’ as they call it.

>
>> The curious case with Rexx is that it has been under attack from the 
>> beginning, like all good things within IBM, like VM and JES2. Later, in 
>> OS/2, it was relentlessly attacked by Microsoft and almost left out of it, 
>> only to be introduced in the IBM EE “Extended Edition”, possibly because it 
>> was better than BASIC of the day.
>
> Interesting. I know it seems like I'm always attacking REXX but I would 
> suggest that I'm criticizing, not attacking. I used to work on NetMaster back 
> in the 90s and danced a jig of joy when I could use REXX instead of NCL. I 
> ways also delighted when ISPF supported inline REXX panel exits so I could 
> avoid horrible panel logic.
>
You could have fooled me, but please keep criticising, it can only become a 
better language. I doubt that it will be the original supplier that will do the 
changes though.
By the way, Marc Remes checked in a change yesterday (on the Linux and Windows 
scripts) to enable NetRexx to compile without setting a CLASSPATH. Although the 
user will need a CLASSPTH when running their first compiled (not interpreted) 
program, and when linking to the first JVM Library or other external method; 
but it is a start.

> These days I spend most of my time on z/OS using a bash shell. I have written 
> REXX scripts that use the SDSF API to interact with the spool, console etc. I 
> also like REXX to write scripts that call batch programs redirecting the 
> output to stdout/stderr etc so I can spawn batch utilities from UNIX 
> processes such as Java web servers. For short scripts REXX is an excellent 
> language. However, I don't think it scales. One glance at the ISPF DTL 
> compiler which is 42KLOC confirms this.
>
I did not know the DTL compiler was written in Rexx. I did never like it as I 
always thought the joy of ISPF panels was that you could layout the screen just 
like it needed to look and we did not need tags for that. Nor did we need CUA.
Rexx does fit its niche. The compiler enables larger programs, it has an 
include statement that the interpreter does not have, and it is better for 
‘application’ type of programs, while the interpreter does better at scripting. 
It was never meant as a replacement for tasks that are better done in PL/I, but 
for EXEC2 and CLIST replac

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

> On 8 Mar 2023, at 04:39, David Crayford  wrote:
> 
> On 7/3/23 16:59, René Jansen wrote:
>> On 7 Mar 2023, at 08:45, David Crayford > > wrote:
>>> The industry has spoken! Python is the most popular programming language in 
>>> the world so haters will have to just suck that up.
>> That is a very funny statement. Nobody hates Python - the hype will blow 
>> over like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons 
>> of COBOL around, like there will be tons of Rexx around for ages.
> 
> Agreed. And there is lots of REXX on the mainframe.
> 
> 
> 
> There's bugs in that code ;)

That’s ChatGPT, it is a bit like a bullshitter consultant.
> 
> 
>> 
>> I rest my case. Still not sure why JCL needs to be replaced but hey.
> 
> 100% agree. Can't say I'm a big fan of JCL but it does the job.
> 

So the question is why the self hate (in the sense of wilful deprecation of own 
history and intellectual/cultural heritage) with IBM has reached the levels 
that it attacks JCL and the Rexx scripts that not even need to replace JCL. 
It’s hip to be square, and lots of people want to learn ‘mainframe’ - or have a 
course in ‘3270’ as they call it.

> 
>> The curious case with Rexx is that it has been under attack from the 
>> beginning, like all good things within IBM, like VM and JES2. Later, in 
>> OS/2, it was relentlessly attacked by Microsoft and almost left out of it, 
>> only to be introduced in the IBM EE “Extended Edition”, possibly because it 
>> was better than BASIC of the day.
> 
> Interesting. I know it seems like I'm always attacking REXX but I would 
> suggest that I'm criticizing, not attacking. I used to work on NetMaster back 
> in the 90s and danced a jig of joy when I could use REXX instead of NCL. I 
> ways also delighted when ISPF supported inline REXX panel exits so I could 
> avoid horrible panel logic.
> 
You could have fooled me, but please keep criticising, it can only become a 
better language. I doubt that it will be the original supplier that will do the 
changes though.
By the way, Marc Remes checked in a change yesterday (on the Linux and Windows 
scripts) to enable NetRexx to compile without setting a CLASSPATH. Although the 
user will need a CLASSPTH when running their first compiled (not interpreted) 
program, and when linking to the first JVM Library or other external method; 
but it is a start.

> These days I spend most of my time on z/OS using a bash shell. I have written 
> REXX scripts that use the SDSF API to interact with the spool, console etc. I 
> also like REXX to write scripts that call batch programs redirecting the 
> output to stdout/stderr etc so I can spawn batch utilities from UNIX 
> processes such as Java web servers. For short scripts REXX is an excellent 
> language. However, I don't think it scales. One glance at the ISPF DTL 
> compiler which is 42KLOC confirms this.
> 
I did not know the DTL compiler was written in Rexx. I did never like it as I 
always thought the joy of ISPF panels was that you could layout the screen just 
like it needed to look and we did not need tags for that. Nor did we need CUA.
Rexx does fit its niche. The compiler enables larger programs, it has an 
include statement that the interpreter does not have, and it is better for 
‘application’ type of programs, while the interpreter does better at scripting. 
It was never meant as a replacement for tasks that are better done in PL/I, but 
for EXEC2 and CLIST replacement.

> I haven't got the spare cycles to port ooRexx. I managed to build it in the 
> naughties but it was full of bugs. That was and EBCDIC port. I don't do 
> EBCDIC ports anymore (nor does Rocket or IBM). A feasibile port of ooRexx 
> would use the new LLVM/clang compilers and use enhanced ASCII with file 
> tagging. That's probably not what the majority of REXXers on this forum would 
> want. They want ooRexx to be native EBCDIC and for the scripts to be in PDS 
> data sets. And integration to TSO/ISPF and all that stuff. I can assure you 
> that is a VERY heavy lift.
> 
It is no problem for current Rexx to do what it always did, and also function 
in USS. ooRexx could use most of those interfaces. But at the moment it seems 
that the strategy is to be overrun by the rest of the world. I would applaud a 
Unicode-only strategy for new software that should work in USS and conventional 
MVS; DB2 did very good work. USS was very late in making it at least workable, 
and there is too much ISO8859 in there still. Also, PDS and ZFS could have been 
integrated way earlier but the problem seems to be vision. As it is, I would 
rather see some respect for the things that work well and the people working 
with those tools.

About those LLVM/Clang ports: I thought I read somewhere that you could only 
use those if you have a license for the older XLC compilers? Is that true? 
Would that even be legal given that those are open source? Reminds me of 
Curaçao where you could buy any beer if 

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 7/3/23 16:59, René Jansen wrote:

On 7 Mar 2023, at 08:45, David Crayford  wrote:

The industry has spoken! Python is the most popular programming language in the 
world so haters will have to just suck that up.

That is a very funny statement. Nobody hates Python - the hype will blow over 
like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons of COBOL 
around, like there will be tons of Rexx around for ages.


Agreed. And there is lots of REXX on the mainframe.




While we do not hate Python (it was a great television series in the seventies) 
we can do without the attacks on Rexx. Like the JCL replacement from IBM’s 
Clunkification department, the examples will speak for themselves. Look at it 
in all its glory, coming in at 190 lines plus lots of imported zooutils, at 
https://github.com/IBM/zoau-samples/blob/main/samples/smpe_list.py - it 
replaces about 15 lines of JCL. If that was meant to undercut the credibility 
of Python, it is a very, very clever attempt by an old mainframer.

If I now ask ChatGPT for a script to list some SMP/E zones, it shows me:

/* REXX program to list the status of all SYSMODs */

/* Set up the SMP/E commands to be executed */
smp_cmds.1 = "SET BDY(GLOBAL)."
smp_cmds.2 = "LIST SYSMOD(*) WHERE(SYMBOLICDATE GT 0)."
smp_cmds.3 = "SET BDY(LOCAL)."

/* Write the SMP/E commands to a temporary data set */
"ALLOC F(SMPCMD) NEW REUSE SPACE(80 80) TRK"
do i = 1 to smp_cmds.0
   "EXECIO 1 DISKW SMPCMD (STEM smp_cmds. " i ")"
end
"FREE F(SMPCMD)"

/* Invoke SMP/E to execute the commands */
"ADDRESS TSO"
"CALL 'SYS1.SMP.EB2A.EXEC(SMPXMSGS)'"
"EXECIO 0 DISKR SMPXMSGS (STEM smp_msgs. FINIS)"
"FREE F(SMPXMSGS)"

/* Display the results */
do i = 1 to smp_msgs.0
   say smp_msgs.i
end


There's bugs in that code ;)




I rest my case. Still not sure why JCL needs to be replaced but hey.


100% agree. Can't say I'm a big fan of JCL but it does the job.



The curious case with Rexx is that it has been under attack from the beginning, 
like all good things within IBM, like VM and JES2. Later, in OS/2, it was 
relentlessly attacked by Microsoft and almost left out of it, only to be 
introduced in the IBM EE “Extended Edition”, possibly because it was better 
than BASIC of the day.


Interesting. I know it seems like I'm always attacking REXX but I would 
suggest that I'm criticizing, not attacking. I used to work on NetMaster 
back in the 90s and danced a jig of joy when I could use REXX instead of 
NCL. I ways also delighted when ISPF supported inline REXX panel exits 
so I could avoid horrible panel logic.


These days I spend most of my time on z/OS using a bash shell. I have 
written REXX scripts that use the SDSF API to interact with the spool, 
console etc. I also like REXX to write scripts that call batch programs 
redirecting the output to stdout/stderr etc so I can spawn batch 
utilities from UNIX processes such as Java web servers. For short 
scripts REXX is an excellent language. However, I don't think it scales. 
One glance at the ISPF DTL compiler which is 42KLOC confirms this.


/* REXX */

parse arg script_file
if script_file = '' then do
  "Usage: kciomega "
  exit 2
end

call syscalls 'ON'
address syscall 'realpath . cwd'
address syscall 'realpath 'script_file' script_file'

call BPXWDYN("ALLOC DD(SYSPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY) 
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(SYSOUT) PATH('/dev/fd2') PATHOPTS(OWRONLY) 
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY) 
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIFLOW) PATH('"script_file"') FILEDATA(TEXT) 
PATHOPTS(ORDONLY) MSG(2) REUSE")


address ATTCHMVS "KCIOMEGA"

call BPXWDYN("FREE DD(SYSPRINT)")
call BPXWDYN("FREE DD(SYSOUT)")
call BPXWDYN("FREE DD(KCIPRINT)")
call BPXWDYN("FREE DD(KCIFLOW)")



Rexx always has been the tool of systems staff, who, while disallowed to do any 
programming, saved many an application (and company) with Rexx, and rubber 
bands. This is why this is such a strange forum to attack Rexx on, and I wonder 
if you just cannot help yourself, or it is some officially sanctioned action, 
somewhat akin to the movement of replacing some easy to use SMP/E JCL (the plot 
comes together here, the unconscious hints give at away) with endless dialogs, 
like young IT people want to be turned into clerks doing spreadsheets.


I was just responding to Peter Farley's post WRT I/O performance which 
gave me an opportunity for a shameless pyzfile plug ;)




So why don’t you indeed port ooRexx to z/OS, and see what happens? You can 
change the threads structure, VS Studio Code has nice tools for that. It would 
be a constructive addition to the discussion. And it would prove some points, 
like porting to z/OS is easy and IBM now embraces open source, and that that 
decision to not port Object Rexx has been walked back.


I haven't got the spare cycles to port ooRexx. I managed to build it in 
the naughties but it was 

Re: REXX, ooRexx, BSF4ooRExx (Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 8/3/23 02:26, Rony G. Flatscher wrote:
There also appears to be bugs in SysThread where the "attached" 
member variable is not initialized in the constructor that takes a 
pthread_t argument.


Ah, interesting that this is regarded a stumbling block, how about 
pthread_getunique_np() or such then?



Obviously, the "_np" suffix stands for "non-portable". It doesn't exist 
on z/OS! I happen to know the internal structure of the opaque pthread_t 
structure on z/OS and to extract the thread ID (TCB address) one would 
implement something like:


int gettid() { return (int)(pthread_self().__ & 0x7fff); }



... cut ...

I you want to attract people to work on ooRexx then I suggest 
modernizing the development pipeline. Move everything to Github. 
Nobody wants to use Subversion anymore and you can create wikis and 
improve the documentation.


Sorry, there are lots of projects that use subversion, despite the big 
trend to Github and the likes. Therefore there are some who also 
shadow ooRexx in github informally.


Luckily I don't have to work on those projects. We converted all of our 
Subversion projects to Git 15 years ago. There's tooling for that. BTW, 
the shadow ooRexx repo on Github doesn't have branches and I couldn't 
find ooRexx 5.0. Subversion is not supported on z/OS so I'm stuck with Git.



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

REXX, ooRexx, BSF4ooRExx (Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rony G. Flatscher]

On 07.03.2023 08:45, David Crayford wrote:

On 7/3/23 02:39, Rony G. Flatscher wrote:

On 06.03.2023 02:43, David Crayford wrote:


... cut ...

I did notice that CMake is being used for the build. That's good as IBM have ported CMake to z/OS. 
It's hidden away on a personal Github repo by an ex-IBMer who used to work in the Java JIT team. I 
may mention that to IBM.


Anyway, I digress. ooRexx still have the same portability issues as before. For example, it 
assumes that 'phread_t' is a integer. On z/OS, System i, BSD etc it's an opaque type, a struct.


In file included from 
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:70:36: error: no matching constructor for 
initialization of 'pthread_t'

    SysThread() : attached(false), _threadID(0) { ; }
   ^ ~
/usr/include/sys/types.h:300:19: note: candidate constructor (the implicit copy constructor) not 
viable: no known conversion from 'int' to 'const pthread_t' for 1st argument

  typedef struct {
  ^
/usr/include/sys/types.h:300:19: note: candidate constructor (the implicit move constructor) not 
viable: no known conversion from 'int' to 'pthread_t' for 1st argument
/usr/include/sys/types.h:300:19: note: candidate constructor (the implicit default constructor) 
not viable: requires 0 arguments, but 1 was provided

In file included from /u/ts8004/git/ooRexx/rexxapi/client/ClientMessage.cpp:41:
In file included from 
/u/ts8004/git/ooRexx/rexxapi/client/LocalAPIManager.hpp:47:
In file included from 
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:86:17: error: cannot convert 'pthread_t' 
to 'uintptr_t' (aka 'unsigned long') without a conversion operator

 return (uintptr_t)_threadID;
    ^~~~
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:89:37: error: cannot convert 'pthread_t' 
to 'size_t' (aka 'unsigned long') without a conversion operator

    inline size_t hash() { return (((size_t)_threadID) >> :sunglasses: * 37; }

IBM warns about this in it's documentation 
https://www.ibm.com/docs/en/i/7.1?topic=ssw_ibm_i_71/apis/concep17.html


Amazon have been fixing this bug in their C SDK 
https://github.com/awslabs/aws-c-io/issues/217

There also appears to be bugs in SysThread where the "attached" member variable is not initialized 
in the constructor that takes a pthread_t argument.


Ah, interesting that this is regarded a stumbling block, how about 
pthread_getunique_np() or such then?


... cut ...

I you want to attract people to work on ooRexx then I suggest modernizing the development 
pipeline. Move everything to Github. Nobody wants to use Subversion anymore and you can create 
wikis and improve the documentation.


Sorry, there are lots of projects that use subversion, despite the big trend to Github and the 
likes. Therefore there are some who also shadow ooRexx in github informally.




I would be interested to know to average age of the commiters.


Probably younger than you in the average! ;)


... cut ...


BSF4ooRexx even allows you to implement abstract Java methods in ooRexx, wich is actually very 
easy! :)


Does it support lambda functions?


Of course! Java lambda functions get defined as interface classes. As I mentioned BSF4ooRexx adds 
the ability to use Rexx classes to implement abstract Java methods and also Java interface classes.



Here an example which uses a Predicate and a Consumer function implemented in a Rexx class named 
"Worker":


   -- the Rexx class "Worker" see below implements the abstract function 
methods in ooRexx methods
   wordstring="Just a bunch of words to test for killer items containing a K."
   arrWords  =.bsf~new("java.lang.String", wordstring)~split(" ") -- returns a 
Java String array

   -- create a RexxProxy of our Worker class, tell Java the interfaces it 
supports
   rexxWorker= 
BsfCreateRexxProxy(.worker~new,,"java.util.function.Predicate","java.util.function.Consumer")

   clzArrays =bsf.loadClass("java.util.Arrays") -- load the Java class in order 
to use its stream() method

   -- create a stream use its "filter" (needs a Predicate function) method, 
return an array
   arr=clzArrays~stream(arrWords) ~filter(rexxWorker) ~toArray
   say "words containing 'k' or 'K':"
   say
   do y over arr -- iterate over array, display its elements
  say "   ["y"]"
   end
   say

   say "all words in array:"
   say
   -- create stream use its "forEach" method (needs a Consumer function): 
accepts and displays every word
   clzArrays~stream(arrWords) ~foreach(rexxWorker) -- accept each word (a 
Consumer function)

   *::requires BSF.CLS -- get the ooRexx-Java bridge***
   -- Rexx class that implements two abstract Java methods in Rexx
   *::class Worker*

   -- implements the abstract method named "test" of the 

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

On 7 Mar 2023, at 08:45, David Crayford  wrote:
> 
> The industry has spoken! Python is the most popular programming language in 
> the world so haters will have to just suck that up.

That is a very funny statement. Nobody hates Python - the hype will blow over 
like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons of COBOL 
around, like there will be tons of Rexx around for ages.

While we do not hate Python (it was a great television series in the seventies) 
we can do without the attacks on Rexx. Like the JCL replacement from IBM’s 
Clunkification department, the examples will speak for themselves. Look at it 
in all its glory, coming in at 190 lines plus lots of imported zooutils, at 
https://github.com/IBM/zoau-samples/blob/main/samples/smpe_list.py - it 
replaces about 15 lines of JCL. If that was meant to undercut the credibility 
of Python, it is a very, very clever attempt by an old mainframer.

If I now ask ChatGPT for a script to list some SMP/E zones, it shows me:

/* REXX program to list the status of all SYSMODs */

/* Set up the SMP/E commands to be executed */
smp_cmds.1 = "SET BDY(GLOBAL)."
smp_cmds.2 = "LIST SYSMOD(*) WHERE(SYMBOLICDATE GT 0)."
smp_cmds.3 = "SET BDY(LOCAL)."

/* Write the SMP/E commands to a temporary data set */
"ALLOC F(SMPCMD) NEW REUSE SPACE(80 80) TRK" 
do i = 1 to smp_cmds.0
  "EXECIO 1 DISKW SMPCMD (STEM smp_cmds. " i ")"
end
"FREE F(SMPCMD)"

/* Invoke SMP/E to execute the commands */
"ADDRESS TSO"
"CALL 'SYS1.SMP.EB2A.EXEC(SMPXMSGS)'"
"EXECIO 0 DISKR SMPXMSGS (STEM smp_msgs. FINIS)"
"FREE F(SMPXMSGS)"

/* Display the results */
do i = 1 to smp_msgs.0
  say smp_msgs.i
end

I rest my case. Still not sure why JCL needs to be replaced but hey.
The curious case with Rexx is that it has been under attack from the beginning, 
like all good things within IBM, like VM and JES2. Later, in OS/2, it was 
relentlessly attacked by Microsoft and almost left out of it, only to be 
introduced in the IBM EE “Extended Edition”, possibly because it was better 
than BASIC of the day.

Rexx always has been the tool of systems staff, who, while disallowed to do any 
programming, saved many an application (and company) with Rexx, and rubber 
bands. This is why this is such a strange forum to attack Rexx on, and I wonder 
if you just cannot help yourself, or it is some officially sanctioned action, 
somewhat akin to the movement of replacing some easy to use SMP/E JCL (the plot 
comes together here, the unconscious hints give at away) with endless dialogs, 
like young IT people want to be turned into clerks doing spreadsheets.

So why don’t you indeed port ooRexx to z/OS, and see what happens? You can 
change the threads structure, VS Studio Code has nice tools for that. It would 
be a constructive addition to the discussion. And it would prove some points, 
like porting to z/OS is easy and IBM now embraces open source, and that that 
decision to not port Object Rexx has been walked back.

best regards,

René.




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

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 7/3/23 02:39, Rony G. Flatscher wrote:

On 06.03.2023 02:43, David Crayford wrote:
I'm sure your BSF4ooRexx is a really nice library. But it's moot 
point talking about it on this forum because ooRexx has not been 
ported to z/OS, I'm sorry to say that I think it probably never will be. 


That would be unfortunate and actually a little bit unprofessional if 
other non-IBM-invented and great software gets ported to it. OTOH 
seeing the FUDding towards ooRexx it is not a surprise, keeping 
everyone in the wait-and-see room (the purpose of FUD marketing).


Unless, of course, there is a REXX enthusiast who has the time and 
skills to do the port. I can tell you from experience, it's not easy. 


Your experience stems from the days where ooRexx was coded to be 
32-bit only, with quite a few hacks from its history at IBM (written 
originally at a time where C++ was not yet standardized, every company 
had its own C++ (pre-)compiler, then the need to have it run on OS/2, 
AIX, Windows and the like).


In the meantime the kernel got totally rewritten and the build system 
changed from autotools to CMake, making it possible to create ports of 
ooRexx with any bitness and operating system targets quickly.



I did notice that CMake is being used for the build. That's good as IBM 
have ported CMake to z/OS. It's hidden away on a personal Github repo by 
an ex-IBMer who used to work in the Java JIT team. I may mention that to 
IBM.


Anyway, I digress. ooRexx still have the same portability issues as 
before. For example, it assumes that 'phread_t' is a integer. On z/OS, 
System i, BSD etc it's an opaque type, a struct.


In file included from 
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:70:36: error: no 
matching constructor for initialization of 'pthread_t'

    SysThread() : attached(false), _threadID(0) { ; }
   ^ ~
/usr/include/sys/types.h:300:19: note: candidate constructor (the 
implicit copy constructor) not viable: no known conversion from 'int' to 
'const pthread_t' for 1st argument

  typedef struct {
  ^
/usr/include/sys/types.h:300:19: note: candidate constructor (the 
implicit move constructor) not viable: no known conversion from 'int' to 
'pthread_t' for 1st argument
/usr/include/sys/types.h:300:19: note: candidate constructor (the 
implicit default constructor) not viable: requires 0 arguments, but 1 
was provided
In file included from 
/u/ts8004/git/ooRexx/rexxapi/client/ClientMessage.cpp:41:
In file included from 
/u/ts8004/git/ooRexx/rexxapi/client/LocalAPIManager.hpp:47:
In file included from 
/u/ts8004/git/ooRexx/common/platform/unix/SysSemaphore.hpp:51:
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:86:17: error: 
cannot convert 'pthread_t' to 'uintptr_t' (aka 'unsigned long') without 
a conversion operator

 return (uintptr_t)_threadID;
    ^~~~
/u/ts8004/git/ooRexx/common/platform/unix/SysThread.hpp:89:37: error: 
cannot convert 'pthread_t' to 'size_t' (aka 'unsigned long') without a 
conversion operator
    inline size_t hash() { return (((size_t)_threadID) >> :sunglasses: 
* 37; }


IBM warns about this in it's documentation 
https://www.ibm.com/docs/en/i/7.1?topic=ssw_ibm_i_71/apis/concep17.html


Amazon have been fixing this bug in their C SDK 
https://github.com/awslabs/aws-c-io/issues/217


There also appears to be bugs in SysThread where the "attached" member 
variable is not initialized in the constructor that takes a pthread_t 
argument.




I also wonder what will happen to ooRexx once Rick McGuire retires? 
Is there a big enough community to keep it going?


Again FUD (fear, uncertainty and doubts): make its future doubtful 
should anyone think of porting it to z/OS?


Seriously, ooRexx is open-source so no one can pull it from the market 
such that any investment in it is strategically safe. The current set 
of features add already a lot of wealth of help and flexibility to the 
REXX table, there would be no need to add new ones to keep ooRexx an 
extremely improved over classic REXX tool forever.


I you want to attract people to work on ooRexx then I suggest 
modernizing the development pipeline. Move everything to Github. Nobody 
wants to use Subversion anymore and you can create wikis and improve the 
documentation.



Back to your doubts: yes, there are plenty of highly skilled 
programmers in the ooRexx community to take on maintenance and even 
add new features if deemed necessary (one of the ooRexx developers has 
even an experimental branch of ooRexx where he tests all sort of 
interesting features).


So, there is no reason to doubt the future of ooRexx. It is a safe 
investment.


I would be interested to know to average age of the commiters.




FWIW, the Python Py4J and JPype (and others)  libraries are similar 
to BSF4ooRexx and both run on z/OS. Note: you will need access to the 

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rony G. Flatscher]

On 06.03.2023 02:43, David Crayford wrote:
I'm sure your BSF4ooRexx is a really nice library. But it's moot point talking about it on this 
forum because ooRexx has not been ported to z/OS, I'm sorry to say that I think it probably never 
will be. 


That would be unfortunate and actually a little bit unprofessional if other non-IBM-invented and 
great software gets ported to it. OTOH seeing the FUDding towards ooRexx it is not a surprise, 
keeping everyone in the wait-and-see room (the purpose of FUD marketing).


Unless, of course, there is a REXX enthusiast who has the time and skills to do the port. I can 
tell you from experience, it's not easy. 


Your experience stems from the days where ooRexx was coded to be 32-bit only, with quite a few hacks 
from its history at IBM (written originally at a time where C++ was not yet standardized, every 
company had its own C++ (pre-)compiler, then the need to have it run on OS/2, AIX, Windows and the 
like).


In the meantime the kernel got totally rewritten and the build system changed from autotools to 
CMake, making it possible to create ports of ooRexx with any bitness and operating system targets 
quickly.


So I assume that anyone who ported software from the Unix world to z/OS would have the necessary 
skills to create a proof of concept port of ooRexx to z/OS. It would add a lot of new and additional 
features for REXX programmers.


I also wonder what will happen to ooRexx once Rick McGuire retires? Is there a big enough 
community to keep it going?


Again FUD (fear, uncertainty and doubts): make its future doubtful should anyone think of porting it 
to z/OS?


Seriously, ooRexx is open-source so no one can pull it from the market such that any investment in 
it is strategically safe. The current set of features add already a lot of wealth of help and 
flexibility to the REXX table, there would be no need to add new ones to keep ooRexx an extremely 
improved over classic REXX tool forever.


Back to your doubts: yes, there are plenty of highly skilled programmers in the ooRexx community to 
take on maintenance and even add new features if deemed necessary (one of the ooRexx developers has 
even an experimental branch of ooRexx where he tests all sort of interesting features).


So, there is no reason to doubt the future of ooRexx. It is a safe investment.

FWIW, the Python Py4J and JPype (and others)  libraries are similar to BSF4ooRexx and both run on 
z/OS. Note: you will need access to the xlclang/xlclang++ libraries to install those packages as 
PyPi doesn't have binaries for z/OS.


https://talvi.net/posts/a-brief-overview-of-python-java-bridges-in-2020.html


Thank you for that interesting link. The only implementation of a Java bridge there that adheres to 
the Java standard (this should go without saying that everyone should adhere to!), i.e. the Java 
scripting framework as defined in the javax.script package is Jython.


As such only Jython can be used as a scripting language from the Java side, if Java programmers want 
to run a Python script from their application using the Java scripting framework. E.g. you can use 
Jython for event handling in JavaFX, but none of the other Python-Java bridge attempts which is 
unfortunate.


All other bridges just ignore the Java scripting framework standard and whatever the respective 
author felt was right for himself turned into the infrastructure one has to learn in order to become 
able to use a particular Java bridge. Such an approach is quite ignorant and hence dilletantic 
despite the talent that people may show. Also one can tell the fascination of new Java-related 
projects like GraalVM (which is not ready for prime time for quite some time) without caring for 
business (professional) deployments of Java.


So the only candidate for a valid Python-Java bridge would be Jython. [Let me add that 
ooRexx+BSF4ooRexx is faster by comparison (comparing loading and dispatching scripts on the same 
machine in the same Java runtime environment).]


Comparing the ooRexx-Java bridge (BSF4ooRexx): it is fully implemented in both directions from 
ooRexx to Java and from Java to ooRexx: you can send ooRexx messages to Java objects (including 
arguments meant for the targeted Java method) that cause the appropriate Java method to be invoked 
on the targeted Java object; vice versa: you can invoke Java methods on the ooRexx proxy object on 
the Java side which will cause the proxied ooRexx object to receive a genuine ooRexx message 
accompanied with all Java arguments going with it.


BSF4ooRexx even allows you to implement abstract Java methods in ooRexx, wich 
is actually very easy! :)

We use ReactorNetty for Java TCP servers [1]. Although it's far more common these days to use a 
layer 7 protocol such as HTTP(S) using a framework like Spring to do all the heavy lifting. It 
would be interesting to see how BSF4ooRexx could use ReactorNetty and if there would be any 
benefit over just using Java or Kotlin.

Re: Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

I'm sure your BSF4ooRexx is a really nice library. But it's moot point 
talking about it on this forum because ooRexx has not been ported to 
z/OS, I'm sorry to say that I think it probably never will be. Unless, 
of course, there is a REXX enthusiast who has the time and skills to do 
the port. I can tell you from experience, it's not easy. I also wonder 
what will happen to ooRexx once Rick McGuire retires? Is there a big 
enough community to keep it going?


FWIW, the Python Py4J and JPype (and others)  libraries are similar to 
BSF4ooRexx and both run on z/OS. Note: you will need access to the 
xlclang/xlclang++ libraries to install those packages as PyPi doesn't 
have binaries for z/OS.


https://talvi.net/posts/a-brief-overview-of-python-java-bridges-in-2020.html

We use ReactorNetty for Java TCP servers [1]. Although it's far more 
common these days to use a layer 7 protocol such as HTTP(S) using a 
framework like Spring to do all the heavy lifting. It would be 
interesting to see how BSF4ooRexx could use ReactorNetty and if there 
would be any benefit over just using Java or Kotlin.


[1] https://projectreactor.io/docs/netty/release/reference/index.html

Python is not my favorite language by a country mile. For scripting I 
would choose Lua every day of the week and twice on Sundays. My younger 
colleagues, however, would not. A lot of universities use Python as the 
language for Introduction to Programming courses so the new hires 
already know the language from colleague. The reason I evangelize Python 
on z/OS is because I can see that IBM are backing it and it's strategic. 
I recently noticed IBM have released the Python AI Toolkit for z/OS 
which is free of charge. Exciting times ahead.


https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS223-021/index.html=en_locale=en


On 6/3/23 04:16, Rony G. Flatscher wrote:

Comment, asking:

    > Like what? Have you ever tried to write a TCP server in REXX?

Comment, receiving:

    > Start here and it is reasonably simple:


    - TCPIP.SEZAINST(RSSERVER)
    - TCPIP.SEZAINST(R6SERVER)


Comment: so writing a TCP server in REXX is not only theoretically 
possible, but a reality. Interesting what happens next:


    Thanks for the links. Now, there is code duplication between the 
two modules. How would one go

    about externalizing the common code to a module?

    The method of maintaining the socket descriptor list is crude and 
highlights the lack of data

    structures in classic REXX.

    Writing a non-blocking, multiplexing TCP server in Python is simple
    https://docs.python.org/3/library/selectors.html

Comment: surprisingly bringing up totally different items/aspects 
(somehow as "if you can, confuse/sidetrack/derail them"). The answer 
is: if one has a need for a TCP server or a TCP client in REXX one can 
create and use one as has been pointed out.


There have been no questions asked about how to go about "writing a 
non-blocking, mulitplexing TCP server in Python". If there was a need 
to "write a non-blocking, multiplexing TCP server in Python" why was 
that particular question not asked in the first place?


OTOH if the need is for REXX servers and/or clients (the original 
question) that employ "a non-blocking, mulitplexing TCP server" (the 
new, derailing questions) and one wishes to code that in REXX one can 
either look for REXX function libraries supplying the needed 
infrastructure, or create such interfaces to such libraries, or use 
NetRexx or BSF4ooRexx, which get one even more powerful abilities due 
to be immediately able to exploit the multiplatform, tested, cunning 
Java class libraries that come for free with Java. :)


Here slides where business administration students who learn 
programming (in a course named "Business Programming") as novices (!) 
in the second part of the semester (after two months learning Rexx and 
then ooRexx from scratch) having become able to use all of Java as a 
huge external ooRexx function and class library: 
 
(the slides also demonstrate how to take advantage of the Java SSL/TLS 
classes, it is actually quite easy). This demonstrates among other 
things how easy it becomes to exploit Java from ooRexx for creating 
TCP server and clients, and as one can see it is even easy doing the 
same with employing Java's SSL/TLS from the Rexx programs! [BTW this 
has become possible because of ooRexx dynamic and message based 
nature. Java objects suddenly understand ooRexx messages, the case of 
spelling method names or field names is not relevant anymore and some 
more. Or invoking Java methods on the Java RexxProxy class causes 
messages to be sent off to the proxied Rexx object and some more.]


Compare the Python library above with what Java allows for, here a 
nice overview article about it: 

Ad TCP/Socket programs in REXX (Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rony G. Flatscher]

Comment, asking:

> Like what? Have you ever tried to write a TCP server in REXX?

Comment, receiving:

> Start here and it is reasonably simple:


- TCPIP.SEZAINST(RSSERVER)
- TCPIP.SEZAINST(R6SERVER)


Comment: so writing a TCP server in REXX is not only theoretically possible, but a reality. 
Interesting what happens next:



Thanks for the links. Now, there is code duplication between the two 
modules. How would one go
about externalizing the common code to a module?

The method of maintaining the socket descriptor list is crude and 
highlights the lack of data
structures in classic REXX.

Writing a non-blocking, multiplexing TCP server in Python is simple
https://docs.python.org/3/library/selectors.html

Comment: surprisingly bringing up totally different items/aspects (somehow as "if you can, 
confuse/sidetrack/derail them"). The answer is: if one has a need for a TCP server or a TCP client 
in REXX one can create and use one as has been pointed out.


There have been no questions asked about how to go about "writing a non-blocking, mulitplexing TCP 
server in Python". If there was a need to "write a non-blocking, multiplexing TCP server in Python" 
why was that particular question not asked in the first place?


OTOH if the need is for REXX servers and/or clients (the original question) that employ "a 
non-blocking, mulitplexing TCP server" (the new, derailing questions) and one wishes to code that in 
REXX one can either look for REXX function libraries supplying the needed infrastructure, or create 
such interfaces to such libraries, or use NetRexx or BSF4ooRexx, which get one even more powerful 
abilities due to be immediately able to exploit the multiplatform, tested, cunning Java class 
libraries that come for free with Java. :)


Here slides where business administration students who learn programming (in a course named 
"Business Programming") as novices (!) in the second part of the semester (after two months learning 
Rexx and then ooRexx from scratch) having become able to use all of Java as a huge external ooRexx 
function and class library: 
 (the slides 
also demonstrate how to take advantage of the Java SSL/TLS classes, it is actually quite easy). This 
demonstrates among other things how easy it becomes to exploit Java from ooRexx for creating TCP 
server and clients, and as one can see it is even easy doing the same with employing Java's SSL/TLS 
from the Rexx programs! [BTW this has become possible because of ooRexx dynamic and message based 
nature. Java objects suddenly understand ooRexx messages, the case of spelling method names or field 
names is not relevant anymore and some more. Or invoking Java methods on the Java RexxProxy class 
causes messages to be sent off to the proxied Rexx object and some more.]


Compare the Python library above with what Java allows for, here a nice overview article about it: 
. 
Anything you see in the discussion about the POSIX definitions (that shine through that Python 
library above and as such mandates the knowledge about it) , the explanations about blocking, 
non-blocking, synchroneous, asynchroneous, multiplexing followed by the overview of respective Java 
classes in an overview form as well as the nutshell Java samples (using Sockets, NIO, NIO2) can be 
directly and immediately used/exploited from REXX in the form of ooRexx and NetRexx, where NetRexx 
will even create native Java classes from your Rexx code (running at the speed of native code). If 
wanting to keep the interactivity of an interpreter, the dynamics and the flexibility of ooRexx at 
runtime then use that.


The point here is simple: everyone who has REXX skills can rather easily and immediately take 
advantage of ooRexx or NetRexx.


The design principle of "human-centricness" of REXX defined by its inventor Mike F. Cowlishaw has 
been successfully applied for these two Rexx languages as well, making it even for newcomers 
(novices, see above!) easy to learn and take advantage of these Rexx languages (as a matter of fact 
Mike F. Cowlishaw also designed NetRexx at IBM which later got open-sourced and gets further 
developed by RexxLA.org).


Just try out these REXX variants, experiment a little bit, they open totally new doors in addition 
to those you have been enjoying with classic REXX already, hence it will pay in any case.

:)

---rony

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 3/3/23 22:33, Sebastian Welton wrote:

On Thu, 2 Mar 2023 06:57:01 -0600, Jay Maynard  wrote:


I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.


Start here and it is reasonably simple:

- TCPIP.SEZAINST(RSSERVER)
- TCPIP.SEZAINST(R6SERVER)


Thanks for the links. Now, there is code duplication between the two 
modules. How would one go about externalizing the common code to a module?


The method of maintaining the socket descriptor list is crude and 
highlights the lack of data structures in classic REXX.


Writing a non-blocking, multiplexing TCP server in Python is simple 
https://docs.python.org/3/library/selectors.html




Sebastian

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Jay Maynard]

Oh, you can bet I'll tell the world what I think...not like I'm exactly
shy, now am i? :-)

On Fri, Mar 3, 2023 at 10:14 AM Ed Jaffe 
wrote:

> On 3/3/2023 3:53 AM, Jay Maynard wrote:
> > I am assured they are working on a replacement, but I have no details.
>
> When you do get the details, please post your reactions here on IBM-MAIN.
>
> For the record, I predict you won't like it... but one never knows...
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Ed Jaffe]

On 3/3/2023 3:53 AM, Jay Maynard wrote:

I am assured they are working on a replacement, but I have no details.


When you do get the details, please post your reactions here on IBM-MAIN.

For the record, I predict you won't like it... but one never knows...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Sebastian Welton]

On Thu, 2 Mar 2023 06:57:01 -0600, Jay Maynard  wrote:

>I haven't tried to write anything in Rexx, let alone a TCP server. I'd
>probably be inclined to use Go for that, though.
>

Start here and it is reasonably simple: 

- TCPIP.SEZAINST(RSSERVER)
- TCPIP.SEZAINST(R6SERVER) 

Sebastian

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Jay Maynard]

I have a zD (as it got called). IBM wasn't prepared to deal with the
response they got, and they also are simply not set up to deal with selling
to individuals. On top of that, the technology they're using for licensing
is getting long in the tooth, and they are not going to be able to use it
beyond some time this year. Existing zD users got an extra year for
free, but that's the end of that program. I am assured they are working on
a replacement, but I have no details.

On Thu, Mar 2, 2023 at 10:22 PM David Crayford  wrote:

> It's my understanding that IBM made the zPDT available at a much more
> affordable price with quite restrictive T's. I do agree with your
> sentiments. I work with young guys and they raised the same point,
> accessibility to a system to kick tires is an issue for young guys
> considering a career as a mainframer.
>
> On 3/3/23 11:27, David Spiegel wrote:
> > Hi David,
> > You said: "... If we want to attract and retain young talent we need
> > tools that they are familiar with ...".
> > That is not the entire story. IBM also should realize that allowing
> > people to experiment with z/OS via Hercules (for free) is in their
> > best interest.
> > How many more decades will this take and will it be too late by the
> > tie IBM figures it out?
> >
> > Regards,
> > David
> >
> > On 2023-03-02 19:40, David Crayford wrote:
> >> On 2/3/23 22:10, Rick Troth wrote:
> >>> On 3/2/23 05:49, David Crayford wrote:
>  I think 99% of the folks on this forum want a language that can run
>  in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
>  and it's orders of magnitudes faster then REXX with the advantage
>  of package management. The next gen guys don't use TSO/ISPF and
>  they're going to use Python and couldn't give a hoot about NetRexx.
> >>>
> >>>
> >>> Lua is great. (Got a link to the MVS version of it?)
> >>
> >> Yes
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0
> >> and the doc is here
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0
> >> which includes the installation instructions.
> >>
> >> Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the
> >> package loader to support PDS source data sets. Check out lpeg [1],
> >> it rocks and is frequently used to write transpilers [2]
> >>
> >> [1]
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
> >> [2]
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0
> >>
> >>
> >>> But language-centric ecosystems not so much. (everything from PIP to
> >>> Maven)
> >>>
> >>> We've lost the concept of inter-language calls.
> >>> With increasing numbers of new and amazing languages, we seem to be
> >>> LESS able to choose and use the right language for the function.
> >>
> >> It's great that there is more choice on z/OS now but we are still way
> >> behind other platforms such as Linux. If we want to attract and
> >> retain young talent we need tools that they are familiar with. IBM
> >> are investing heavily on porting tools to z/OS and have a dedicated
> >> team headed up by a distinguished engineer. IBM don't do altruism so
> >> they obviously take this seriously. I see they have a port of rsync
> >> which piqued my interest.
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0
> >>
> >>
> >>>
> >>>
> >>> -- R; <><
> >>>
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive 

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Bob Bridges]

It's been a while since I mentioned this, but some years ago my oldest son got 
his fill of hearing me talk about the vanishing mainframers and wondered 
whether he should get me to teach him some of the basics.  I started asking 
around, wanting to know how much it would cost me to rent a little space on a 
z/OS system, enough for two IDs for enough time for him to know whether he 
hated it.

Apparently my questions got around.  About three weeks after I started asking, 
an IBM guy called me and made me an offer:  If I could get my local college to 
start some mainframe classes, the college would need to rent an LPAR and IBM 
would ~give~ me space on that machine.

I graduated from UNC-Greensboro, but I'd learned PL/1 there and I suppose they 
still had some mainframe classes.  I'd worked two years at A, so I called 
them.  I was unable to get anyone interested, as I recall.  Seems a shame.  
Heck, at the time I would probably have been willing to ~teach~ one or two of 
the classes; I like training.  But I never forgot what the IBMer told me, that 
businesses are so eager for mainframe skills that they often sponsor college 
classes with their own money.

David Spiegel, how would you define "too late"?  I don't see that ever coming, 
at least not from that particular piece of short-sidedness.

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

/* My goal for 2023 is to lose 10 lbs.  Only 15 more to go! */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Thursday, March 2, 2023 23:22

It's my understanding that IBM made the zPDT available at a much more 
affordable price with quite restrictive T's. I do agree with your sentiments. 
I work with young guys and they raised the same point, accessibility to a 
system to kick tires is an issue for young guys considering a career as a 
mainframer.

--- On 3/3/23 11:27, David Spiegel wrote:
> IBM also should realize that allowing people to experiment with
> z/OS via Hercules (for free) is in their best interest.  How many
> more decades will this take and will it be too late by the tie IBM
> figures it out?

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 3/3/23 12:51, Mike Schwab wrote:

They only got a few dongles out before they shut the program down.


That's disappointing. IIRC, IBM allow access to containerized z/OS 
images. I don't know anything about how one would procure access but I 
believe Peter Farley has experience in that space.




On Thu, Mar 2, 2023 at 10:22 PM David Crayford  wrote:

It's my understanding that IBM made the zPDT available at a much more
affordable price with quite restrictive T's. I do agree with your
sentiments. I work with young guys and they raised the same point,
accessibility to a system to kick tires is an issue for young guys
considering a career as a mainframer.

On 3/3/23 11:27, David Spiegel wrote:

Hi David,
You said: "... If we want to attract and retain young talent we need
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing
people to experiment with z/OS via Hercules (for free) is in their
best interest.
How many more decades will this take and will it be too late by the
tie IBM figures it out?

Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:

I think 99% of the folks on this forum want a language that can run
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
and it's orders of magnitudes faster then REXX with the advantage
of package management. The next gen guys don't use TSO/ISPF and
they're going to use Python and couldn't give a hoot about NetRexx.


Lua is great. (Got a link to the MVS version of it?)

Yes
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0
and the doc is here
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0
which includes the installation instructions.

Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the
package loader to support PDS source data sets. Check out lpeg [1],
it rocks and is frequently used to write transpilers [2]

[1]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to
Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be
LESS able to choose and use the right language for the function.

It's great that there is more choice on z/OS now but we are still way
behind other platforms such as Linux. If we want to attract and
retain young talent we need tools that they are familiar with. IBM
are investing heavily on porting tools to z/OS and have a dedicated
team headed up by a distinguished engineer. IBM don't do altruism so
they obviously take this seriously. I see they have a port of rsync
which piqued my interest.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0




-- R; <><

--
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

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Mike Schwab]

They only got a few dongles out before they shut the program down.

On Thu, Mar 2, 2023 at 10:22 PM David Crayford  wrote:
>
> It's my understanding that IBM made the zPDT available at a much more
> affordable price with quite restrictive T's. I do agree with your
> sentiments. I work with young guys and they raised the same point,
> accessibility to a system to kick tires is an issue for young guys
> considering a career as a mainframer.
>
> On 3/3/23 11:27, David Spiegel wrote:
> > Hi David,
> > You said: "... If we want to attract and retain young talent we need
> > tools that they are familiar with ...".
> > That is not the entire story. IBM also should realize that allowing
> > people to experiment with z/OS via Hercules (for free) is in their
> > best interest.
> > How many more decades will this take and will it be too late by the
> > tie IBM figures it out?
> >
> > Regards,
> > David
> >
> > On 2023-03-02 19:40, David Crayford wrote:
> >> On 2/3/23 22:10, Rick Troth wrote:
> >>> On 3/2/23 05:49, David Crayford wrote:
>  I think 99% of the folks on this forum want a language that can run
>  in a TSO/ISPF environment hosted in PDS data sets. Lua can do that
>  and it's orders of magnitudes faster then REXX with the advantage
>  of package management. The next gen guys don't use TSO/ISPF and
>  they're going to use Python and couldn't give a hoot about NetRexx.
> >>>
> >>>
> >>> Lua is great. (Got a link to the MVS version of it?)
> >>
> >> Yes
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0
> >> and the doc is here
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0
> >> which includes the installation instructions.
> >>
> >> Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the
> >> package loader to support PDS source data sets. Check out lpeg [1],
> >> it rocks and is frequently used to write transpilers [2]
> >>
> >> [1]
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
> >> [2]
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0
> >>
> >>
> >>> But language-centric ecosystems not so much. (everything from PIP to
> >>> Maven)
> >>>
> >>> We've lost the concept of inter-language calls.
> >>> With increasing numbers of new and amazing languages, we seem to be
> >>> LESS able to choose and use the right language for the function.
> >>
> >> It's great that there is more choice on z/OS now but we are still way
> >> behind other platforms such as Linux. If we want to attract and
> >> retain young talent we need tools that they are familiar with. IBM
> >> are investing heavily on porting tools to z/OS and have a dedicated
> >> team headed up by a distinguished engineer. IBM don't do altruism so
> >> they obviously take this seriously. I see they have a port of rsync
> >> which piqued my interest.
> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0
> >>
> >>
> >>>
> >>>
> >>> -- R; <><
> >>>
> >>> --
> >>> 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
> >
> > --
> > For 

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

It's my understanding that IBM made the zPDT available at a much more 
affordable price with quite restrictive T's. I do agree with your 
sentiments. I work with young guys and they raised the same point, 
accessibility to a system to kick tires is an issue for young guys 
considering a career as a mainframer.


On 3/3/23 11:27, David Spiegel wrote:

Hi David,
You said: "... If we want to attract and retain young talent we need 
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing 
people to experiment with z/OS via Hercules (for free) is in their 
best interest.
How many more decades will this take and will it be too late by the 
tie IBM figures it out?


Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage 
of package management. The next gen guys don't use TSO/ISPF and 
they're going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0 
and the doc is here 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0 
which includes the installation instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the 
package loader to support PDS source data sets. Check out lpeg [1], 
it rocks and is frequently used to write transpilers [2]


[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and 
retain young talent we need tools that they are familiar with. IBM 
are investing heavily on porting tools to z/OS and have a dedicated 
team headed up by a distinguished engineer. IBM don't do altruism so 
they obviously take this seriously. I see they have a port of rsync 
which piqued my interest. 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0






-- R; <><

--
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


--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Spiegel]

Hi David,
You said: "... If we want to attract and retain young talent we need 
tools that they are familiar with ...".
That is not the entire story. IBM also should realize that allowing 
people to experiment with z/OS via Hercules (for free) is in their best 
interest.
How many more decades will this take and will it be too late by the tie 
IBM figures it out?


Regards,
David

On 2023-03-02 19:40, David Crayford wrote:

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLua4z%2FLua4z=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=jeAvZSPCDIzkEhY0X5UMvrcno4CSGEGC%2BHUCTdaGs%2FY%3D=0 
and the doc is here 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Lb%2Fta5hn0YrHv55d1uZdfLnMh7JIfpIrDLR%2F0bLqyAM%3D=0 
which includes the installation instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the 
package loader to support PDS source data sets. Check out lpeg [1], it 
rocks and is frequently used to write transpilers [2]


[1] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Flpeg%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=AtRLB0kd74fylPFeqmFPxm2ovG5BawGC03vNSgiUx5U%3D=0
[2] 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoonscript.org%2F=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gGBIv%2BkBUUO0Y%2BWuxQrK4MoV%2BNy%2FUnHQnXbVm0cvmDQ%3D=0



But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and retain 
young talent we need tools that they are familiar with. IBM are 
investing heavily on porting tools to z/OS and have a dedicated team 
headed up by a distinguished engineer. IBM don't do altruism so they 
obviously take this seriously. I see they have a port of rsync which 
piqued my interest. 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FZOSOpenTools=05%7C01%7C%7C8543ad69920a4eb52ad508db1b7fed92%7C84df9e7fe9f640afb435%7C1%7C0%7C638134008542999041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=iO2AsRLJSLWKM7VYXy5euYnP0uHhVm57Qd1COtLdGgY%3D=0






-- R; <><

--
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


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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

[David Crayford]

On 3/3/23 00:22, Farley, Peter wrote:

But I found that using them from the z/OS Unix command line embedded in a python script just as in 
the article link is a performance nightmare.  Definitely NOT ready for production use.  The idea is 
good but the implementation is awful.  Take a close look at the implementation of the ZOAU 
dataset-read function for an example of what I saw.  Substantially better performance can be had by 
using the python subprocess.run() function to execute the "cat" shell command to capture 
the z/OS dataset file contents you need in a python list (assuming your file contents will fit in 
available memory, of course; if not use "head" instead to read in chunks at a time)
Spawning a subprocess is a bizarre way to use cat. The idomatic UNIX 
method would be to pipe cat into your Python program and read from stdin.


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 22:10, Rick Troth wrote:

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)


Yes https://github.com/Lua4z/Lua4z and the doc is here 
https://lua4z.github.io/Lua4z/ which includes the installation 
instructions.


Disclaimer: lt's my port. It's an EBCDIC port and I tweaked the package 
loader to support PDS source data sets. Check out lpeg [1], it rocks and 
is frequently used to write transpilers [2]


[1] https://www.inf.puc-rio.br/~roberto/lpeg/
[2] https://moonscript.org/


But language-centric ecosystems not so much. (everything from PIP to 
Maven)


We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be 
LESS able to choose and use the right language for the function.


It's great that there is more choice on z/OS now but we are still way 
behind other platforms such as Linux. If we want to attract and retain 
young talent we need tools that they are familiar with. IBM are 
investing heavily on porting tools to z/OS and have a dedicated team 
headed up by a distinguished engineer. IBM don't do altruism so they 
obviously take this seriously. I see they have a port of rsync which 
piqued my interest. https://github.com/ZOSOpenTools






-- R; <><

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Andrew Rowley]

On 3/03/2023 1:36 am, David Spiegel wrote:
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes 
about 15 minutes on the fastest mainframes.


I think that's a reflection on WAS, not Java.

When I was playing with the software drag racing, I compared the times 
from SMF to get an idea of the Java startup etc. overhead.


For a 5 second elapsed time of 5 seconds timed inside the program, SMF 
showed:

C++ : 5.02 seconds elapsed, 4.95 seconds CPU time
Java: 6.16 seconds elapsed, 5.24 seconds CPU time.

So the overhead to start Java looked to be around 1 second elapsed, and 
1/4 second of CPU time. After the startup, Java was as fast as C++ in 
this test.


--
Andrew Rowley
Black Hill Software

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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

[Farley, Peter]

That is apparently the issue on the system to which I have access, zoaversion 
there returns "CUT V1.1.1", while the latest version seems to be 1.2.1.

Thanks for the update.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Thursday, March 2, 2023 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - 
again (Re: zOSMF and zOWE for non-mainframers]

On 3/2/2023 8:22 AM, Farley, Peter wrote:
> One thing I will add from actual testing I have done with ZOAU facilities -- 
> they are HORRIBLY slow.  Yes, you can run them from off-platform - that was 
> their intended raison d'etre - and the fact that you even CAN do that if you 
> really, really need it is a Good Thing (tm).

The original version of ZOAU used SDSF REXX and that was indeed quite slow. 
Ugh...

The latest version uses direct SSI calls written in C and performs much better.
-- 


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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Seymour J Metz]

ILC doesn't seem to be a thing in the open source community. It's not an easy 
thing to achieve.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rick Troth [tro...@gmail.com]
Sent: Thursday, March 2, 2023 9:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

On 3/2/23 05:49, David Crayford wrote:
> I think 99% of the folks on this forum want a language that can run in
> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and
> it's orders of magnitudes faster then REXX with the advantage of
> package management. The next gen guys don't use TSO/ISPF and they're
> going to use Python and couldn't give a hoot about NetRexx.


Lua is great. (Got a link to the MVS version of it?)
But language-centric ecosystems not so much. (everything from PIP to Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be LESS
able to choose and use the right language for the function.


-- R; <><

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Mike Schwab]

JOL is still available and up to date.

On Thu, Mar 2, 2023 at 6:44 AM Jay Maynard  wrote:
>
> "The mainframe needs to keep pace with the industry."
>
> I certainly hope that whatever the industry is doing that gets adapted to
> the mainframe does so much more cleanly than, say, Python... The absolute
> abortion that is Python's idea of replacing JCL makes COBOL look like APL.
>
> On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:
>
> > On 2/3/23 19:48, René Jansen wrote:
> > >> I think 99% of the folks on this forum want a language that can run in
> > a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
> > orders of magnitudes faster then REXX with the advantage of package
> > management. The next gen guys don't use TSO/ISPF and they're going to use
> > Python and couldn't give a hoot about NetRexx.
> > > NetRexx can and does, using the IBM jzos classes, which are delivered
> > with its JVM’s.
> >
> > Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
> > I don't get the point of NetRexx.
> >
> >
> > > They can do a lot more with conventional MVS than LUA, I am sure.
> >
> > Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
> > VDEFINE. And  you can write packages and applications using PDS data
> > sets. REXX is impoverished in this respect and you can't share state or
> > data structures between modules.
> >
> > /https://lua4z.github.io/Lua4z
> >
> > > Not that anyone would do that, of course, being so much easier with ISPF
> > and Rexx and their shared variable pool. I have built dialogs in COBOL and
> > PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
> > first.
> >
> > That's subjective. I find it much easier to write code in Lua. A
> > programming language that supports OO, meta-programming, functional
> > programming and co-routines with just 20 reserved words is a thing of
> > absolute beauty and a testament to the designers. REXX is a niche
> > language that's only used to any great extend on mainframes and it's
> > popularity is constantly eroding. The mainframe needs to keep pace with
> > the industry.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Jay Maynard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

[Ed Jaffe]

On 3/2/2023 8:22 AM, Farley, Peter wrote:

One thing I will add from actual testing I have done with ZOAU facilities -- 
they are HORRIBLY slow.  Yes, you can run them from off-platform - that was 
their intended raison d'etre - and the fact that you even CAN do that if you 
really, really need it is a Good Thing (tm).


The original version of ZOAU used SDSF REXX and that was indeed quite 
slow. Ugh...


The latest version uses direct SSI calls written in C and performs much 
better.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: ZOAU [was: RE: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers]

[Farley, Peter]

One thing I will add from actual testing I have done with ZOAU facilities -- 
they are HORRIBLY slow.  Yes, you can run them from off-platform - that was 
their intended raison d'etre - and the fact that you even CAN do that if you 
really, really need it is a Good Thing (tm).

But I found that using them from the z/OS Unix command line embedded in a 
python script just as in the article link is a performance nightmare.  
Definitely NOT ready for production use.  The idea is good but the 
implementation is awful.  Take a close look at the implementation of the ZOAU 
dataset-read function for an example of what I saw.  Substantially better 
performance can be had by using the python subprocess.run() function to execute 
the "cat" shell command to capture the z/OS dataset file contents you need in a 
python list (assuming your file contents will fit in available memory, of 
course; if not use "head" instead to read in chunks at a time).  Or even use 
David's pyzfile facility, assuming you can get it installed at your shop.

I suppose one could put ZOAU in the class of development tool that is "OK to 
use once or twice a day" but not something you want to use more often than that 
in our CPU-constrained-for-cost environments, at least not until the underlying 
implementation improves dramatically.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jay 
Maynard
Sent: Thursday, March 2, 2023 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

I haven't tried to write anything in Rexx, let alone a TCP server. I'd probably 
be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a
 

--

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Paul Gorlinsky]

I chose external for a reason... to my knowledge, the breaches occurred with 
the cooperation of internal staff either purposely or through negligence...

Like RACF admins being lazy and putting things in WARN mode then forgetting 
about it...

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

Respectfully, I think your performance testing is hopelessly outdated. 
Starting a Java application server on z/OS takes a few seconds.


 Starting DataStreamerApplication v1.1.5-SNAPSHOT using Java 1.8.0_351 
on RSD6 with PID 33620928

 No active profile set, falling back to 1 default profile: "default"
 Tomcat initialized with port(s): 9070 (http)
 Starting service [Tomcat]
 Starting Servlet engine: [Apache Tomcat/9.0.60]
 Initializing Spring embedded WebApplicationContext
 Root WebApplicationContext: initialization completed in 3538 ms


On 2/3/23 22:36, David Spiegel wrote:

Hi Paul,
You said: "...JAVA is a good example of this. The mainframe's JAVA 
runtime is written to exploit machine assists and hardware 
instructions that a PC doesn't have..."
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes 
about 15 minutes on the fastest mainframes.

Good thing it has assists, otherwise it might take 2 days Feh!

Regards,
David

On 2023-03-02 08:31, Paul Gorlinsky wrote:

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the 
optimization area. Some are lazy and just convert the code to pseudo 
code and store it as an executable to remove one layer of processing.


2) The selection of a computer language for a given task should be 
based upon:

  A) Shop standards
  B) Limitations imposed by the OS or OS components the task is 
to be integrated with
  C) The performance requirements, that is does this new widget 
run once a day, hour,minute,second,etc.

  D) Time constraints ... execution time as well as development time
  D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key 
to a successful project.


Note: that a benchmark run with different languages on a commodity 
computer ( AKA PC ) is NOT transferable to the mainframe. JAVA is a 
good example of this. The mainframe's JAVA runtime is written to 
exploit  machine assists and hardware instructions that a PC doesn't 
have. For example, all the string manipulation instructions.


IMHO



--
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


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Paul Gorlinsky]

On newer machines there are specific mainframe firmware levels that should be 
kept in sync with the specific versions of the JRE ... otherwise ... the JRE 
takes a longer path

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Spiegel]

Hi Paul,
You said: "...JAVA is a good example of this. The mainframe's JAVA 
runtime is written to exploit machine assists and hardware instructions 
that a PC doesn't have..."
Every time I've watched mainframe Java since OS/90 V1, it has been 
painfully slow. Have you ever watched a WAS startup? ... It takes about 
15 minutes on the fastest mainframes.

Good thing it has assists, otherwise it might take 2 days Feh!

Regards,
David

On 2023-03-02 08:31, Paul Gorlinsky wrote:

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the optimization 
area. Some are lazy and just convert the code to pseudo code and store it as an 
executable to remove one layer of processing.

2) The selection of a computer language for a given task should be based upon:
  A) Shop standards
  B) Limitations imposed by the OS or OS components the task is to be 
integrated with
  C) The performance requirements, that is does this new widget run once a 
day, hour,minute,second,etc.
  D) Time constraints ... execution time as well as development time
  D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key to a 
successful project.

Note: that a benchmark run with different languages on a commodity computer ( 
AKA PC ) is NOT transferable to the mainframe. JAVA is a good example of this. 
The mainframe's JAVA runtime is written to exploit  machine assists and 
hardware instructions that a PC doesn't have. For example, all the string 
manipulation instructions.

IMHO


  


--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Spiegel]

Hi Paul,
You said: "...where no externally security breach has occurred…"
If you're saying that no mainframe has ever been hacked, I am certain 
that statement is not true.
The one in particular which comes to mind, involved incompetent security 
admin staff, READ Access to the RACF Database and (i'm guessing some 
insider assistance).
It also involved multi-session software which had vulnerabilities as 
well as lack of protection.


Regards,
David

On 2023-03-02 09:15, Paul Gorlinsky wrote:

IMHO … this is the classic PC v Mainframe programmer debate…
The same people that said Mainframes would be gone … when 40-50% of the worlds 
core data is still in on a mainframe… where a small staff of Systems 
programmers can manage and support entire enterprises and yet thousands of PC 
techs support the server farms… where no externally security breach has 
occurred… and yet PC servers are being held ransom time after time after time …

I still prefer assembler language when I Program on the mainframe… but if 
circumstances dictate… I’ll do cobol pl/1 c Rexx Clist Execs … etc. because I 
am a programmer not a python programmer…

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Paul Gorlinsky]

IMHO … this is the classic PC v Mainframe programmer debate…
The same people that said Mainframes would be gone … when 40-50% of the worlds 
core data is still in on a mainframe… where a small staff of Systems 
programmers can manage and support entire enterprises and yet thousands of PC 
techs support the server farms… where no externally security breach has 
occurred… and yet PC servers are being held ransom time after time after time … 

I still prefer assembler language when I Program on the mainframe… but if 
circumstances dictate… I’ll do cobol pl/1 c Rexx Clist Execs … etc. because I 
am a programmer not a python programmer…

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rick Troth]

On 3/2/23 05:49, David Crayford wrote:
I think 99% of the folks on this forum want a language that can run in 
a TSO/ISPF environment hosted in PDS data sets. Lua can do that and 
it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx. 



Lua is great. (Got a link to the MVS version of it?)
But language-centric ecosystems not so much. (everything from PIP to Maven)

We've lost the concept of inter-language calls.
With increasing numbers of new and amazing languages, we seem to be LESS 
able to choose and use the right language for the function.



-- R; <><

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Paul Gorlinsky]

I use ooRexx as an integrated procedural language within my mainframe FICON 
attached Virtual Tape Appliance. Why? Because it is the primary procedural 
language used by Systems Programmers on the mainframe. 

We can use a well architected interface and the ADDRESS construct to develop 
and select what environment we want to process commands. Simple well crafted 
interfaces.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Spiegel]

Hi David,
You said: "... REXX is a niche language that's only used to any great 
extend on mainframes and it's popularity is constantly eroding. The 
mainframe needs to keep pace with the industry.  ..."
1) " used to any great extend on mainframes ..."Last time I looked, 
this is a MAINFRAME (my Caps Lock button isn't stuck) discussion group. 
Niche or not, who cares?
2) It's popularity is "constantly eroding". Do you have facts to back up 
your assertion? Even if true, who cares?
3) The mainframe "... needs to keep pace ..."? With 850,000,000,000 
Lines of COBOL running US industry, the Mainframe does not have to keep 
pace with anything.


Caveat: I've been programming in Rexx since the day it came out (on 
VM/SP). Most of my usage is to simplify Systems Programming tasks, such 
as, generating JCL and Commands to implement software updates/upgrades.
(I would never use it in any typical business application; instead, I 
would use PL/I or COBOL.) If it takes a few extra nanoseconds, again, 
who cares? Finally, learning Rexx is similar to the argument for 
learning vi.
Vi comes installed with every *ix. Similarly, Rexx comes installed with 
every z/OS and z/VM. (I've worked in places that don't let SysProgs 
install anything other than what is licensed. No matter how good Lua is, 
it might, therefore, not be available.)


Regards,
David

On 2023-03-02 07:36, David Crayford wrote:

On 2/3/23 19:48, René Jansen wrote:
I think 99% of the folks on this forum want a language that can run 
in a TSO/ISPF environment hosted in PDS data sets. Lua can do that 
and it's orders of magnitudes faster then REXX with the advantage of 
package management. The next gen guys don't use TSO/ISPF and they're 
going to use Python and couldn't give a hoot about NetRexx.
NetRexx can and does, using the IBM jzos classes, which are delivered 
with its JVM’s.


Hmm, I don't think so. NetRexx programs can not reside in PDS data 
sets. I don't get the point of NetRexx.




They can do a lot more with conventional MVS than LUA, I am sure.


Don't agree. Lua4z has a heap of integrations including TSO/ISPF 
without VDEFINE. And  you can write packages and applications using 
PDS data sets. REXX is impoverished in this respect and you can't 
share state or data structures between modules.


/https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F%2F%2F%2F=05%7C01%7C%7C5d8a2c3555eb47089d8508db1b1ade72%7C84df9e7fe9f640afb435%7C1%7C0%7C638133574493344939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=DLt1zWGCKau0226D2noVdejr2ioh759Bw0DvdiQlwKw%3D=0 



Not that anyone would do that, of course, being so much easier with 
ISPF and Rexx and their shared variable pool. I have built dialogs in 
COBOL and PL/1 but nothing beats Rexx for that, having not to VDEFINE 
everything first.


That's subjective. I find it much easier to write code in Lua. A 
programming language that supports OO, meta-programming, functional 
programming and co-routines with just 20 reserved words is a thing of 
absolute beauty and a testament to the designers. REXX is a niche 
language that's only used to any great extend on mainframes and it's 
popularity is constantly eroding. The mainframe needs to keep pace 
with the industry.


--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 21:30, René Jansen wrote:

Not that anyone would do that, of course, being so much easier with ISPF and 
Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.

That's subjective. I find it much easier to write code in Lua. A programming 
language that supports OO, meta-programming, functional programming and 
co-routines with just 20 reserved words is a thing of absolute beauty and a 
testament to the designers. REXX is a niche language that's only used to any 
great extend on mainframes and it's popularity is constantly eroding. The 
mainframe needs to keep pace with the industry.


A very true word. And in trying to cast it in the image of Unix, it will always 
be some steps behind, and be an eternal disappointment to next gen people. Look 
at every github project or distribution repo, s390x is always a hanger-on. It 
is a platform of unique strength. What is the point of WebSphere when you have 
CICS? What is the point of then still running WebSphere on Java version 8? Why 
not build the ultimate cloud machine with all the middleware API’s but 
implemented in the best tools there are? Why doesn’t the next ChatGPT run on a 
Z17 with a Prolog/Asm combo using these enormous address spaces with all these 
new instructions on a small number of CPU’s instead of letting those 
datacenters use up all our natural resources with dinky but power hungry - even 
when idling - X86 machines. The problem with all the Z propaganda (still need 
to change that name, IBM) is that all these things about Green and Cloud were 
true, but nobody invested in the software for it, not like the /360 investment 
of the early sixties.

The problem now is pretending that it is leading edge, by running late and 
behind in rebuilding Unix tools from decades ago. The new mainframe should not 
be the old Unix, we have the new Unix in Linux and on the Mac already, and WSL 
for Windows people. IBM does need to invest in software for the mainframe, not 
to divest from it. And it should stop badmouthing its own past.


IBM are investing heavily in porting tools and have some top notch 
talent working on it https://github.com/ZOSOpenTools. Why not ask them 
to port ooRexx? I don't think they will as there just isn't a market for it.




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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Paul Gorlinsky]

After watching this chain for awhile I have a couple of observations:

1) Not all compilers are equal in their tasks especially in the optimization 
area. Some are lazy and just convert the code to pseudo code and store it as an 
executable to remove one layer of processing.

2) The selection of a computer language for a given task should be based upon:
 A) Shop standards
 B) Limitations imposed by the OS or OS components the task is to be 
integrated with
 C) The performance requirements, that is does this new widget run once a 
day, hour,minute,second,etc. 
 D) Time constraints ... execution time as well as development time
 D) The skill of the programmer


Understanding the PROS and CONS of each computer language is the key to a 
successful project.

Note: that a benchmark run with different languages on a commodity computer ( 
AKA PC ) is NOT transferable to the mainframe. JAVA is a good example of this. 
The mainframe's JAVA runtime is written to exploit  machine assists and 
hardware instructions that a PC doesn't have. For example, all the string 
manipulation instructions. 

IMHO




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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

On 2 Mar 2023, at 13:36, David Crayford  wrote:
> 
> On 2/3/23 19:48, René Jansen wrote:
>>> I think 99% of the folks on this forum want a language that can run in a 
>>> TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's 
>>> orders of magnitudes faster then REXX with the advantage of package 
>>> management. The next gen guys don't use TSO/ISPF and they're going to use 
>>> Python and couldn't give a hoot about NetRexx.
>> NetRexx can and does, using the IBM jzos classes, which are delivered with 
>> its JVM’s.
> 
> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. I 
> don't get the point of NetRexx.

This is getting silly. While you would normally compile or run the NetRexx 
interpreter (it can do both) from ZFS there is no reason you could not store 
the source in a PDS. You can run everything from JCL if you wanted. If you 
don’t get the point, I cannot really help you. NetRexx is an oo  variant of the 
Rexx language by the creator of Rexx. It can run everywhere where there is a 
JVM (JRE) available. This is a larger environment than just our PC’s or 
mainframes. I have shown you that it performs rather well, given that it 
produces Java bytecode. It integrates with the environment that hosts the JVM 
rather well, depending on the JVM support for that. The discussion went from 
performance to all over the place.
> 
> 
>> They can do a lot more with conventional MVS than LUA, I am sure.
> 
> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without 
> VDEFINE. And  you can write packages and applications using PDS data sets. 
> REXX is impoverished in this respect and you can't share state or data 
> structures between modules.

> /https://lua4z.github.io/Lua4z
> 
I am not going to compare what Lua4z can do compared to IBM jZos with regard to 
interacting with its environment. I always regarded Java as a safer bet for 
reusability of my code, and I have not been disappointed. I did not encounter a 
lot of ISPF dialogs in Lua yet, and I hope people keep writing them in Rexx or 
Rexx370.

>> Not that anyone would do that, of course, being so much easier with ISPF and 
>> Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 
>> but nothing beats Rexx for that, having not to VDEFINE everything first.
> 
> That's subjective. I find it much easier to write code in Lua. A programming 
> language that supports OO, meta-programming, functional programming and 
> co-routines with just 20 reserved words is a thing of absolute beauty and a 
> testament to the designers. REXX is a niche language that's only used to any 
> great extend on mainframes and it's popularity is constantly eroding. The 
> mainframe needs to keep pace with the industry.
> 

A very true word. And in trying to cast it in the image of Unix, it will always 
be some steps behind, and be an eternal disappointment to next gen people. Look 
at every github project or distribution repo, s390x is always a hanger-on. It 
is a platform of unique strength. What is the point of WebSphere when you have 
CICS? What is the point of then still running WebSphere on Java version 8? Why 
not build the ultimate cloud machine with all the middleware API’s but 
implemented in the best tools there are? Why doesn’t the next ChatGPT run on a 
Z17 with a Prolog/Asm combo using these enormous address spaces with all these 
new instructions on a small number of CPU’s instead of letting those 
datacenters use up all our natural resources with dinky but power hungry - even 
when idling - X86 machines. The problem with all the Z propaganda (still need 
to change that name, IBM) is that all these things about Green and Cloud were 
true, but nobody invested in the software for it, not like the /360 investment 
of the early sixties.

The problem now is pretending that it is leading edge, by running late and 
behind in rebuilding Unix tools from decades ago. The new mainframe should not 
be the old Unix, we have the new Unix in Linux and on the Mac already, and WSL 
for Windows people. IBM does need to invest in software for the mainframe, not 
to divest from it. And it should stop badmouthing its own past.

There is really nothing better for workloads consisting of batch, CICS, COBOL, 
MQ and DB2 in a sysplex. It could be the base for new workloads but milking out 
the work from the 60-80’s and not investing in it will not bring that future. 
Future Systems (FS) was a great idea if we look at whats left from it, but it 
died because it was so closed that even IBM’s own architects could not 
understand it all in one piece - because it was closely guarded by the internal 
police. We are fortunately past OCO (except for the very things we speak about 
- are we afraid that someone else will build a cloud with it?) and it is 
already clear that open source runs rings around closed source work. It is a 
shame we cannot reuse the many brilliant parts of VM and MVS, DB2 and 
CICS-still. Rexx was 

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Seymour J Metz]

Reserved words? We don't need no stinking reserved words. That's one of the 
things I like about PL/I.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Crayford [dcrayf...@gmail.com]
Sent: Thursday, March 2, 2023 7:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

On 2/3/23 19:48, René Jansen wrote:
>> I think 99% of the folks on this forum want a language that can run in a 
>> TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's 
>> orders of magnitudes faster then REXX with the advantage of package 
>> management. The next gen guys don't use TSO/ISPF and they're going to use 
>> Python and couldn't give a hoot about NetRexx.
> NetRexx can and does, using the IBM jzos classes, which are delivered with 
> its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.


> They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua4z.github.io%2FLua4z%2F%2F%2F%2F=05%7C01%7Csmetz3%40gmu.edu%7Cfabdfa1c24b14701a95008db1b1add29%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638133574414760901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=u47BULUorcSSEQnuX3DNC1lpg8Wie6mcyQ4xdL4wFq8%3D=0

> Not that anyone would do that, of course, being so much easier with ISPF and 
> Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 
> but nothing beats Rexx for that, having not to VDEFINE everything first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Paul Gorlinsky]

Due to shop standard constraints I end up writing a client and a server in 
COBOL for a state agency. Code is still in use after 15 years and has not 
required any maintenance.

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Seymour J Metz]

A good compilers does, e.g., flow analysis, to optimize the generated code. It 
may be difficult to hand optimize well enough to beat a good compiler and still 
keep the code readable.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Colin Paice [colinpai...@gmail.com]
Sent: Thursday, March 2, 2023 2:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF 
and zOWE for non-mainframers

I think it is horses for courses.  Someone once said to me something along
the lines of ..

If you run it once a day write it in rexx (or Python)
If you run it once an hour - write it in Java
If you run it once a second write it in C
If you run it 1000 times a second - write it in Assembler.

It is not just a matter of performance - how much of your time do you want
to invest in writing the program.  The more time you spend - the better it
should be.
If it is good enough - is that OK ?
Colin

On Thu, 2 Mar 2023 at 04:25, David Crayford  wrote:

> After struggling with NetRexx, I've found that it could benefit from
> being as user-friendly as Kotlin or Groovy if the maintainers want to
> attract more users. On my machine, NetRexx is slower than Python but
> still respectable.
>
> However, both Python and NetRexx are outperformed by highly optimized
> Java solutions. Go is also impressive and available on z/OS using the
> IBM SDK.
>
> It's important to note that NetRexx is not ooRexx, and the discussion
> was focused on the poor performance of ooRexx. While some may choose to
> bridge NetRexx with Java, I personally find it more convenient to use
> Kotlin or Groovy instead.
>
>
> ❯ python3 PrimePy.py
> Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881,
> Limit: 100, Count: 78498, Valid: True
> emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8
>
> ❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
> joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes
>
> Optimized Java
>
> ❯ ./runSolution.sh
> chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
>
> chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
>
> chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
> chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes,bits=1
>
> chrvanorleStrided32Blocks16k;12069;5.00;1;algorithm=base,faithful=yes,bits=1
>
> chrvanorleStrided32Blocks16k;37190;5.009000;4;algorithm=base,faithful=yes,bits=1
>
> ❯ go run .
> Run for 5.0 seconds using 12 workers to builing a sieve up to 100...
> Passes: 19506, Time: 5000 ms, Avg: 256336 ns/op, Limit: 100, Count1:
> 78498, Count2: 78498, Valid: true
> kpym-go-multi;19506;5.96;4;algorithm=base,faithful=yes
>
>
> On 2/3/23 00:54, René Jansen wrote:
> > so this should work for you:
> >
> > ➜  test git:(master) ✗ cat hello.nrx
> > import java.lang.String
> >
> > say 'hello java' System.getProperty("java.version")
> >
> > loop i=long 0 to 10
> >   hello(i)
> > end
> >
> > loop i=long 0 to 10
> >   hello(java.lang.String(i))
> > end
> >
> > method hello(j)
> >say "hello" j
> >
> >method hello(j=long)
> >  say "hello long" j
> >
> >method hello(j=java.lang.String)
> >  say "hello String" j
> > ➜  test git:(master) ✗ unset CLASSPATH
> > ➜  test git:(master) ✗ echo $CLASSPATH
> >
> > ➜  test git:(master) ✗ java -jar NetRexxC.jar hello
> > NetRexx portable processor 4.05-beta build 374-20230213-1052
> > Copyright (c) RexxLA, 2011,2023.   All rights reserved.
> > Parts Copyright (c) IBM Corporation, 1995,2008.
> > Program hello.nrx
> >  constructor hello(Rexx)
> >  constructor hello(long)
> >  constructor hello(String)
> > Compilation of 'hello.nrx' succe

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 20:57, Jay Maynard wrote:

I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a


Totally agree with you. JCL is what it is. The data set I/O classes are 
even more pathetic which is why I wrote https://github.com/daveyc/pyzfile





On Thu, Mar 2, 2023 at 6:54 AM David Crayford  wrote:


On 2/3/23 20:43, Jay Maynard wrote:

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python...

Like what? Have you ever tried to write a TCP server in REXX?



The absolute abortion that is Python's idea of replacing JCL makes COBOL

look like APL.

I haven't seen that. Can you post a link?



On Thu, Mar 2, 2023 at 6:37 AM David Crayford 

wrote:

On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in

a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
orders of magnitudes faster then REXX with the advantage of package
management. The next gen guys don't use TSO/ISPF and they're going to

use

Python and couldn't give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered

with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.



They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with

ISPF

and Rexx and their shared variable pool. I have built dialogs in COBOL

and

PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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





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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Jay Maynard]

I haven't tried to write anything in Rexx, let alone a TCP server. I'd
probably be inclined to use Go for that, though.

JCL to Python:
https://medium.com/theropod/the-journey-from-jcl-to-python-so-easy-even-an-old-mainframer-can-do-it-f088cc49366a

On Thu, Mar 2, 2023 at 6:54 AM David Crayford  wrote:

> On 2/3/23 20:43, Jay Maynard wrote:
> > "The mainframe needs to keep pace with the industry."
> >
> > I certainly hope that whatever the industry is doing that gets adapted to
> > the mainframe does so much more cleanly than, say, Python...
>
> Like what? Have you ever tried to write a TCP server in REXX?
>
>
> > The absolute abortion that is Python's idea of replacing JCL makes COBOL
> look like APL.
>
> I haven't seen that. Can you post a link?
>
>
> >
> > On Thu, Mar 2, 2023 at 6:37 AM David Crayford 
> wrote:
> >
> >> On 2/3/23 19:48, René Jansen wrote:
>  I think 99% of the folks on this forum want a language that can run in
> >> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
> >> orders of magnitudes faster then REXX with the advantage of package
> >> management. The next gen guys don't use TSO/ISPF and they're going to
> use
> >> Python and couldn't give a hoot about NetRexx.
> >>> NetRexx can and does, using the IBM jzos classes, which are delivered
> >> with its JVM’s.
> >>
> >> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
> >> I don't get the point of NetRexx.
> >>
> >>
> >>> They can do a lot more with conventional MVS than LUA, I am sure.
> >> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
> >> VDEFINE. And  you can write packages and applications using PDS data
> >> sets. REXX is impoverished in this respect and you can't share state or
> >> data structures between modules.
> >>
> >> /https://lua4z.github.io/Lua4z
> >>
> >>> Not that anyone would do that, of course, being so much easier with
> ISPF
> >> and Rexx and their shared variable pool. I have built dialogs in COBOL
> and
> >> PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
> >> first.
> >>
> >> That's subjective. I find it much easier to write code in Lua. A
> >> programming language that supports OO, meta-programming, functional
> >> programming and co-routines with just 20 reserved words is a thing of
> >> absolute beauty and a testament to the designers. REXX is a niche
> >> language that's only used to any great extend on mainframes and it's
> >> popularity is constantly eroding. The mainframe needs to keep pace with
> >> the industry.
> >>
> >> --
> >> 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
>


-- 
Jay Maynard

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 20:43, Jay Maynard wrote:

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python...


Like what? Have you ever tried to write a TCP server in REXX?



The absolute abortion that is Python's idea of replacing JCL makes COBOL look 
like APL.


I haven't seen that. Can you post a link?




On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:


On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in

a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
orders of magnitudes faster then REXX with the advantage of package
management. The next gen guys don't use TSO/ISPF and they're going to use
Python and couldn't give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered

with its JVM’s.

Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
I don't get the point of NetRexx.



They can do a lot more with conventional MVS than LUA, I am sure.

Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
VDEFINE. And  you can write packages and applications using PDS data
sets. REXX is impoverished in this respect and you can't share state or
data structures between modules.

/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with ISPF

and Rexx and their shared variable pool. I have built dialogs in COBOL and
PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
first.

That's subjective. I find it much easier to write code in Lua. A
programming language that supports OO, meta-programming, functional
programming and co-routines with just 20 reserved words is a thing of
absolute beauty and a testament to the designers. REXX is a niche
language that's only used to any great extend on mainframes and it's
popularity is constantly eroding. The mainframe needs to keep pace with
the industry.

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Jay Maynard]

"The mainframe needs to keep pace with the industry."

I certainly hope that whatever the industry is doing that gets adapted to
the mainframe does so much more cleanly than, say, Python... The absolute
abortion that is Python's idea of replacing JCL makes COBOL look like APL.

On Thu, Mar 2, 2023 at 6:37 AM David Crayford  wrote:

> On 2/3/23 19:48, René Jansen wrote:
> >> I think 99% of the folks on this forum want a language that can run in
> a TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's
> orders of magnitudes faster then REXX with the advantage of package
> management. The next gen guys don't use TSO/ISPF and they're going to use
> Python and couldn't give a hoot about NetRexx.
> > NetRexx can and does, using the IBM jzos classes, which are delivered
> with its JVM’s.
>
> Hmm, I don't think so. NetRexx programs can not reside in PDS data sets.
> I don't get the point of NetRexx.
>
>
> > They can do a lot more with conventional MVS than LUA, I am sure.
>
> Don't agree. Lua4z has a heap of integrations including TSO/ISPF without
> VDEFINE. And  you can write packages and applications using PDS data
> sets. REXX is impoverished in this respect and you can't share state or
> data structures between modules.
>
> /https://lua4z.github.io/Lua4z
>
> > Not that anyone would do that, of course, being so much easier with ISPF
> and Rexx and their shared variable pool. I have built dialogs in COBOL and
> PL/1 but nothing beats Rexx for that, having not to VDEFINE everything
> first.
>
> That's subjective. I find it much easier to write code in Lua. A
> programming language that supports OO, meta-programming, functional
> programming and co-routines with just 20 reserved words is a thing of
> absolute beauty and a testament to the designers. REXX is a niche
> language that's only used to any great extend on mainframes and it's
> popularity is constantly eroding. The mainframe needs to keep pace with
> the industry.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 19:48, René Jansen wrote:

I think 99% of the folks on this forum want a language that can run in a 
TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's orders 
of magnitudes faster then REXX with the advantage of package management. The 
next gen guys don't use TSO/ISPF and they're going to use Python and couldn't 
give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered with its 
JVM’s.


Hmm, I don't think so. NetRexx programs can not reside in PDS data sets. 
I don't get the point of NetRexx.




They can do a lot more with conventional MVS than LUA, I am sure.


Don't agree. Lua4z has a heap of integrations including TSO/ISPF without 
VDEFINE. And  you can write packages and applications using PDS data 
sets. REXX is impoverished in this respect and you can't share state or 
data structures between modules.


/https://lua4z.github.io/Lua4z


Not that anyone would do that, of course, being so much easier with ISPF and 
Rexx and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.


That's subjective. I find it much easier to write code in Lua. A 
programming language that supports OO, meta-programming, functional 
programming and co-routines with just 20 reserved words is a thing of 
absolute beauty and a testament to the designers. REXX is a niche 
language that's only used to any great extend on mainframes and it's 
popularity is constantly eroding. The mainframe needs to keep pace with 
the industry.


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

> On 2 Mar 2023, at 11:49, David Crayford  wrote:
> 
> That shouldn't make any difference. SquareRoot is only called once. I had to 
> laugh when I noticed that it was implemented using Newton–Raphson in REXX. 
> How can a programming language not implement a sqrt() function?
> 

You might want to verify that statement. It is not called once but but every 
time there is an Erastothenes object created. That, of course, explains the 
difference when replacing the squareroot method.
Which language does not implement a sqrt function? NetRexx does not, because 
Java has a perfectly and transparantly usable java.lang.Math.sqrt(). We might 
improve on it with unlimited precision decimals, though, one day.

> 
> How do I build NetRexx programs using Gradle or Maven! It kind of sucks 
> having to rub two sticks together using the command line!
> 
You can if you must. Maven will documented in the upcoming 4.05 release 
documentation. When fixing the Kotlin Gradle build I’ll try to document that 
with NetRexx builds.

> 
> I think 99% of the folks on this forum want a language that can run in a 
> TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's orders 
> of magnitudes faster then REXX with the advantage of package management. The 
> next gen guys don't use TSO/ISPF and they're going to use Python and couldn't 
> give a hoot about NetRexx.

NetRexx can and does, using the IBM jzos classes, which are delivered with its 
JVM’s. They can do a lot more with conventional MVS than LUA, I am sure. Not 
that anyone would do that, of course, being so much easier with ISPF and Rexx 
and their shared variable pool. I have built dialogs in COBOL and PL/1 but 
nothing beats Rexx for that, having not to VDEFINE everything first.

Who knows what the next gen guys and girls are going to do? It is not what I am 
worrying about; just wanted to correct some untruths.

René.


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 17:19, René Jansen wrote:

Time for a new pc, I think. I installed numpy (which did not came standard) and 
I got


I'm getting a m2 MacBook Pro (12-30) soon so I'll run it again and let 
you know.




➜  solution_3 git:(drag-race) ✗ python3 PrimePY.py
Passes: 11241, Time: 5.000303332984913, Avg: 0.00044482726919179013, Limit: 
100, Count: 78498, Valid: True

and speaking about ooRexx, on my daily machine, which is a glorified iPhone (a 
Mac Mini with the first m1 SOC) it runs 117 iterations instead of the 3 you 
reported. I’ll profile that later and will let the team know.

One look at the NetRexx solution gave me this (with one small change):

➜  solution_2 git:(drag-race) ✗ java PrimeNetRexx
joss_NetRexx;15686;5.54;1;algorithm=base,bits=8,faithful=yes

I’ll submit that as PrimeRexx solution_3 later today; I only changed the 
SquareRoot method to that from the JDK because there is no reason to do that 
with variable precision if you are going to trunc the result to int. There 
might be more to do, but I am rather pleased with this result already.


That shouldn't make any difference. SquareRoot is only called once. I 
had to laugh when I noticed that it was implemented using Newton–Raphson 
in REXX. How can a programming language not implement a sqrt() function?





I had a look at Kotlin. To build that example, I needed to download and install 
Gradle. Started compile.sh, this downloaded hundreds of megabytes, and then 
failed.
If I compare that to NetRexx:

nrc PrimeNetRexx


How do I build NetRexx programs using Gradle or Maven! It kind of sucks 
having to rub two sticks together using the command line!





with (sorry!) a CLASSPATH of .:NetRexxC.jar - I am not really convinced that we 
are that user unfriendly. Of course I will look into having a CLASSPATH env 
variable set in one of the scripts, but the moment the user includes something 
from another jar - they have to set a CLASSPATH anyway.

As Rony has shown, someone with mainframe experience could easily write bog 
standard Rexx and, when the performance is really needed, do a slight detour 
through NetRexx (with the added advantage that the NetRexx stays easy and 
understandable). As Colin said, we are not sieving primes all day.


I think 99% of the folks on this forum want a language that can run in a 
TSO/ISPF environment hosted in PDS data sets. Lua can do that and it's 
orders of magnitudes faster then REXX with the advantage of package 
management. The next gen guys don't use TSO/ISPF and they're going to 
use Python and couldn't give a hoot about NetRexx.





I am interested in having a place to analyse Z arch vector instructions and DFP 
usage by compilers, also for an upcoming Rexx compiler for 64 bits. Would 
someone have such a place? I am reluctant to drive my customers lpars through 
the roof due to capping and tariffs (although slightly related to my work 
there). It would be open source, so there is no financial gain attached.

best regards,

René.



On 2 Mar 2023, at 05:24, David Crayford  wrote:

After struggling with NetRexx, I've found that it could benefit from being as 
user-friendly as Kotlin or Groovy if the maintainers want to attract more 
users. On my machine, NetRexx is slower than Python but still respectable.

However, both Python and NetRexx are outperformed by highly optimized Java 
solutions. Go is also impressive and available on z/OS using the IBM SDK.

It's important to note that NetRexx is not ooRexx, and the discussion was 
focused on the poor performance of ooRexx. While some may choose to bridge 
NetRexx with Java, I personally find it more convenient to use Kotlin or Groovy 
instead.


❯ python3 PrimePy.py
Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8

❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes

Optimized Java

❯ ./runSolution.sh
chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

Time for a new pc, I think. I installed numpy (which did not came standard) and 
I got

➜  solution_3 git:(drag-race) ✗ python3 PrimePY.py
Passes: 11241, Time: 5.000303332984913, Avg: 0.00044482726919179013, Limit: 
100, Count: 78498, Valid: True

and speaking about ooRexx, on my daily machine, which is a glorified iPhone (a 
Mac Mini with the first m1 SOC) it runs 117 iterations instead of the 3 you 
reported. I’ll profile that later and will let the team know.

One look at the NetRexx solution gave me this (with one small change):

➜  solution_2 git:(drag-race) ✗ java PrimeNetRexx
joss_NetRexx;15686;5.54;1;algorithm=base,bits=8,faithful=yes

I’ll submit that as PrimeRexx solution_3 later today; I only changed the 
SquareRoot method to that from the JDK because there is no reason to do that 
with variable precision if you are going to trunc the result to int. There 
might be more to do, but I am rather pleased with this result already.

I had a look at Kotlin. To build that example, I needed to download and install 
Gradle. Started compile.sh, this downloaded hundreds of megabytes, and then 
failed.
If I compare that to NetRexx:

nrc PrimeNetRexx

with (sorry!) a CLASSPATH of .:NetRexxC.jar - I am not really convinced that we 
are that user unfriendly. Of course I will look into having a CLASSPATH env 
variable set in one of the scripts, but the moment the user includes something 
from another jar - they have to set a CLASSPATH anyway.

As Rony has shown, someone with mainframe experience could easily write bog 
standard Rexx and, when the performance is really needed, do a slight detour 
through NetRexx (with the added advantage that the NetRexx stays easy and 
understandable). As Colin said, we are not sieving primes all day.

I am interested in having a place to analyse Z arch vector instructions and DFP 
usage by compilers, also for an upcoming Rexx compiler for 64 bits. Would 
someone have such a place? I am reluctant to drive my customers lpars through 
the roof due to capping and tariffs (although slightly related to my work 
there). It would be open source, so there is no financial gain attached.

best regards,

René.


> On 2 Mar 2023, at 05:24, David Crayford  wrote:
> 
> After struggling with NetRexx, I've found that it could benefit from being as 
> user-friendly as Kotlin or Groovy if the maintainers want to attract more 
> users. On my machine, NetRexx is slower than Python but still respectable.
> 
> However, both Python and NetRexx are outperformed by highly optimized Java 
> solutions. Go is also impressive and available on z/OS using the IBM SDK.
> 
> It's important to note that NetRexx is not ooRexx, and the discussion was 
> focused on the poor performance of ooRexx. While some may choose to bridge 
> NetRexx with Java, I personally find it more convenient to use Kotlin or 
> Groovy instead.
> 
> 
> ❯ python3 PrimePy.py
> Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881, Limit: 
> 100, Count: 78498, Valid: True
> emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8
> 
> ❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
> joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes
> 
> Optimized Java
> 
> ❯ ./runSolution.sh
> chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
> chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
> chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleStrided32Blocks16k;12069;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleStrided32Blocks16k;37190;5.009000;4;algorithm=base,faithful=yes,bits=1
> 
> ❯ go run .
> Run for 5.0 seconds using 12 workers to builing a sieve up to 100...
> Passes: 19506, Time: 5000 ms, Avg: 256336 ns/op, Limit: 100, Count1: 
> 78498, Count2: 78498, Valid: true
> kpym-go-multi;19506;5.96;4;algorithm=base,faithful=yes
> 
> 
> On 2/3/23 00:54, René Jansen wrote:
>> so this should work for you:
>> 
>> ➜  test git:(master) ✗ cat hello.nrx
>> import java.lang.String
>> 
>> say 'hello java' System.getProperty("java.version")
>> 
>> loop i=long 0 to 10
>>  hello(i)
>> end
>> 
>> loop i=long 0 to 10
>>  

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Colin Paice]

I think it is horses for courses.  Someone once said to me something along
the lines of ..

If you run it once a day write it in rexx (or Python)
If you run it once an hour - write it in Java
If you run it once a second write it in C
If you run it 1000 times a second - write it in Assembler.

It is not just a matter of performance - how much of your time do you want
to invest in writing the program.  The more time you spend - the better it
should be.
If it is good enough - is that OK ?
Colin

On Thu, 2 Mar 2023 at 04:25, David Crayford  wrote:

> After struggling with NetRexx, I've found that it could benefit from
> being as user-friendly as Kotlin or Groovy if the maintainers want to
> attract more users. On my machine, NetRexx is slower than Python but
> still respectable.
>
> However, both Python and NetRexx are outperformed by highly optimized
> Java solutions. Go is also impressive and available on z/OS using the
> IBM SDK.
>
> It's important to note that NetRexx is not ooRexx, and the discussion
> was focused on the poor performance of ooRexx. While some may choose to
> bridge NetRexx with Java, I personally find it more convenient to use
> Kotlin or Groovy instead.
>
>
> ❯ python3 PrimePy.py
> Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881,
> Limit: 100, Count: 78498, Valid: True
> emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8
>
> ❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
> joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes
>
> Optimized Java
>
> ❯ ./runSolution.sh
> chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
>
> chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
>
> chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
> chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
> chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes,bits=1
>
> chrvanorleStrided32Blocks16k;12069;5.00;1;algorithm=base,faithful=yes,bits=1
>
> chrvanorleStrided32Blocks16k;37190;5.009000;4;algorithm=base,faithful=yes,bits=1
>
> ❯ go run .
> Run for 5.0 seconds using 12 workers to builing a sieve up to 100...
> Passes: 19506, Time: 5000 ms, Avg: 256336 ns/op, Limit: 100, Count1:
> 78498, Count2: 78498, Valid: true
> kpym-go-multi;19506;5.96;4;algorithm=base,faithful=yes
>
>
> On 2/3/23 00:54, René Jansen wrote:
> > so this should work for you:
> >
> > ➜  test git:(master) ✗ cat hello.nrx
> > import java.lang.String
> >
> > say 'hello java' System.getProperty("java.version")
> >
> > loop i=long 0 to 10
> >   hello(i)
> > end
> >
> > loop i=long 0 to 10
> >   hello(java.lang.String(i))
> > end
> >
> > method hello(j)
> >say "hello" j
> >
> >method hello(j=long)
> >  say "hello long" j
> >
> >method hello(j=java.lang.String)
> >  say "hello String" j
> > ➜  test git:(master) ✗ unset CLASSPATH
> > ➜  test git:(master) ✗ echo $CLASSPATH
> >
> > ➜  test git:(master) ✗ java -jar NetRexxC.jar hello
> > NetRexx portable processor 4.05-beta build 374-20230213-1052
> > Copyright (c) RexxLA, 2011,2023.   All rights reserved.
> > Parts Copyright (c) IBM Corporation, 1995,2008.
> > Program hello.nrx
> >  constructor hello(Rexx)
> >  constructor hello(long)
> >  constructor hello(String)
> > Compilation of 'hello.nrx' successful
> > ➜  test git:(master) ✗
> >
> > I have a global CLASSPATH, and only for specific projects I have a -cp
> on the command line for Make or Ninja, to have control over versions and
> libraries.
> > A global classpath enables me to check if all code is still compatible
> with the combination of releases from different libraries I use.
> > But as you see it is not really needed. We are not mandating anything,
> and if you want to run from a jar, that is fine.
> >
> > best regards,
> >
> > René.
> >
> >> On 1 Mar 2023, at 17:23, David Crayford  wrote:
> >>
> >> On 2/3/23 00:20, René Jansen wrote:
> >>> Well, it *is* an executable jar. Up to you.
> >> Executable Jars don't require setting a CLASSPATH Rene
> >>
> >>
>  On 1 Mar 2023, at 17:17, David Crayford  wrote:
> 
>  Why doesn't it just use an executable jar and use "-jar"?
> >>> --
> >>> For IBM-MAIN subscribe / signoff / archive access 

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

After struggling with NetRexx, I've found that it could benefit from 
being as user-friendly as Kotlin or Groovy if the maintainers want to 
attract more users. On my machine, NetRexx is slower than Python but 
still respectable.


However, both Python and NetRexx are outperformed by highly optimized 
Java solutions. Go is also impressive and available on z/OS using the 
IBM SDK.


It's important to note that NetRexx is not ooRexx, and the discussion 
was focused on the poor performance of ooRexx. While some may choose to 
bridge NetRexx with Java, I personally find it more convenient to use 
Kotlin or Groovy instead.



❯ python3 PrimePy.py
Passes: 6699, Time: 5.000532913953066, Avg: 0.0007464596079941881, 
Limit: 100, Count: 78498, Valid: True

emillynge_numpy; 6699;5.000532913953066;1;algorithm=base,faithful=no,bits=8

❯ java -cp ~/NetRexx-4.04-GA/lib/NetRexxF.jar:. PrimeNetRexx
joss_NetRexx;5743;5.000354;1;algorithm=base,bits=8,faithful=yes

Optimized Java

❯ ./runSolution.sh
chrvanorleI32;6197;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32;19191;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;7511;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32C;21451;5.003000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64;5957;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64;18471;5.015000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;7161;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI64C;21167;5.006000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI64PatternCalc;9308;5.00;1;algorithm=other,faithful=yes,bits=1
chrvanorleI64PatternCalc;29123;5.004000;4;algorithm=other,faithful=yes,bits=1
chrvanorleI8;4946;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI8;14963;5.016000;4;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;7927;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleI32CUnroll;25650;5.006000;4;algorithm=base,faithful=yes,bits=1
chrvanorleStrided32Blocks16k;12069;5.00;1;algorithm=base,faithful=yes,bits=1
chrvanorleStrided32Blocks16k;37190;5.009000;4;algorithm=base,faithful=yes,bits=1

❯ go run .
Run for 5.0 seconds using 12 workers to builing a sieve up to 100...
Passes: 19506, Time: 5000 ms, Avg: 256336 ns/op, Limit: 100, Count1: 
78498, Count2: 78498, Valid: true

kpym-go-multi;19506;5.96;4;algorithm=base,faithful=yes


On 2/3/23 00:54, René Jansen wrote:

so this should work for you:

➜  test git:(master) ✗ cat hello.nrx
import java.lang.String

say 'hello java' System.getProperty("java.version")

loop i=long 0 to 10
hello(i)
end

loop i=long 0 to 10
hello(java.lang.String(i))
end

method hello(j)
   say "hello" j

   method hello(j=long)
 say "hello long" j

   method hello(j=java.lang.String)
 say "hello String" j
➜  test git:(master) ✗ unset CLASSPATH
➜  test git:(master) ✗ echo $CLASSPATH

➜  test git:(master) ✗ java -jar NetRexxC.jar hello
NetRexx portable processor 4.05-beta build 374-20230213-1052
Copyright (c) RexxLA, 2011,2023.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program hello.nrx
 constructor hello(Rexx)
 constructor hello(long)
 constructor hello(String)
Compilation of 'hello.nrx' successful
➜  test git:(master) ✗

I have a global CLASSPATH, and only for specific projects I have a -cp on the 
command line for Make or Ninja, to have control over versions and libraries.
A global classpath enables me to check if all code is still compatible with the 
combination of releases from different libraries I use.
But as you see it is not really needed. We are not mandating anything, and if 
you want to run from a jar, that is fine.

best regards,

René.


On 1 Mar 2023, at 17:23, David Crayford  wrote:

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.

Executable Jars don't require setting a CLASSPATH Rene



On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?

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

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 00:54, René Jansen wrote:

maybe I was not clear.

it *is* an executable jar with the manifest built into it.


Then somebody needs to fix the scripts so it's usable by just setting 
PATH and using the current working directory.




On 1 Mar 2023, at 17:52, David Crayford  wrote:

On 2/3/23 00:34, René Jansen wrote:

Yes, I know. But linking to other code in .class files does. You can run 
NetRexx from the .jar file. This finds all NetRexx classes. But let’s say you 
want to use a Java TreeMap, or some crypto algorithm like FPE in your program - 
it will look on CLASSPATH for those.



Yes, I know that. I only want to execute the compiler without setting 
CLASSPATH. It should be an executable Jar with the main mainifest built in to 
the Jar. It makes NetRexx difficult to use and the documentation is Windows 
oriented.



On 1 Mar 2023, at 17:23, David Crayford  wrote:

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.

Executable Jars don't require setting a CLASSPATH Rene



On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?

--
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

--
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

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

so this should work for you:

➜  test git:(master) ✗ cat hello.nrx
import java.lang.String

say 'hello java' System.getProperty("java.version")

loop i=long 0 to 10
hello(i)
end

loop i=long 0 to 10
hello(java.lang.String(i))
end

method hello(j)
  say "hello" j

  method hello(j=long)
say "hello long" j

  method hello(j=java.lang.String)
say "hello String" j
➜  test git:(master) ✗ unset CLASSPATH
➜  test git:(master) ✗ echo $CLASSPATH

➜  test git:(master) ✗ java -jar NetRexxC.jar hello
NetRexx portable processor 4.05-beta build 374-20230213-1052
Copyright (c) RexxLA, 2011,2023.   All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program hello.nrx
constructor hello(Rexx)
constructor hello(long)
constructor hello(String)
Compilation of 'hello.nrx' successful
➜  test git:(master) ✗

I have a global CLASSPATH, and only for specific projects I have a -cp on the 
command line for Make or Ninja, to have control over versions and libraries.
A global classpath enables me to check if all code is still compatible with the 
combination of releases from different libraries I use.
But as you see it is not really needed. We are not mandating anything, and if 
you want to run from a jar, that is fine.

best regards,

René.

> On 1 Mar 2023, at 17:23, David Crayford  wrote:
> 
> On 2/3/23 00:20, René Jansen wrote:
>> Well, it *is* an executable jar. Up to you.
> 
> Executable Jars don't require setting a CLASSPATH Rene
> 
> 
>> 
>>> On 1 Mar 2023, at 17:17, David Crayford  wrote:
>>> 
>>> Why doesn't it just use an executable jar and use "-jar"?
>> 
>> --
>> 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

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

maybe I was not clear.

it *is* an executable jar with the manifest built into it.

> On 1 Mar 2023, at 17:52, David Crayford  wrote:
> 
> On 2/3/23 00:34, René Jansen wrote:
>> Yes, I know. But linking to other code in .class files does. You can run 
>> NetRexx from the .jar file. This finds all NetRexx classes. But let’s say 
>> you want to use a Java TreeMap, or some crypto algorithm like FPE in your 
>> program - it will look on CLASSPATH for those.
>> 
>> 
> Yes, I know that. I only want to execute the compiler without setting 
> CLASSPATH. It should be an executable Jar with the main mainifest built in to 
> the Jar. It makes NetRexx difficult to use and the documentation is Windows 
> oriented.
> 
> 
>>> On 1 Mar 2023, at 17:23, David Crayford  wrote:
>>> 
>>> On 2/3/23 00:20, René Jansen wrote:
 Well, it *is* an executable jar. Up to you.
>>> Executable Jars don't require setting a CLASSPATH Rene
>>> 
>>> 
> On 1 Mar 2023, at 17:17, David Crayford  wrote:
> 
> Why doesn't it just use an executable jar and use "-jar"?
 --
 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
>> --
>> 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

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 00:34, René Jansen wrote:

Yes, I know. But linking to other code in .class files does. You can run 
NetRexx from the .jar file. This finds all NetRexx classes. But let’s say you 
want to use a Java TreeMap, or some crypto algorithm like FPE in your program - 
it will look on CLASSPATH for those.


Yes, I know that. I only want to execute the compiler without setting 
CLASSPATH. It should be an executable Jar with the main mainifest built 
in to the Jar. It makes NetRexx difficult to use and the documentation 
is Windows oriented.




On 1 Mar 2023, at 17:23, David Crayford  wrote:

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.

Executable Jars don't require setting a CLASSPATH Rene



On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?

--
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

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

Yes, I know. But linking to other code in .class files does. You can run 
NetRexx from the .jar file. This finds all NetRexx classes. But let’s say you 
want to use a Java TreeMap, or some crypto algorithm like FPE in your program - 
it will look on CLASSPATH for those.


> On 1 Mar 2023, at 17:23, David Crayford  wrote:
> 
> On 2/3/23 00:20, René Jansen wrote:
>> Well, it *is* an executable jar. Up to you.
> 
> Executable Jars don't require setting a CLASSPATH Rene
> 
> 
>> 
>>> On 1 Mar 2023, at 17:17, David Crayford  wrote:
>>> 
>>> Why doesn't it just use an executable jar and use "-jar"?
>> 
>> --
>> 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

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 2/3/23 00:20, René Jansen wrote:

Well, it *is* an executable jar. Up to you.


Executable Jars don't require setting a CLASSPATH Rene





On 1 Mar 2023, at 17:17, David Crayford  wrote:

Why doesn't it just use an executable jar and use "-jar"?


--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

Well, it *is* an executable jar. Up to you.

> On 1 Mar 2023, at 17:17, David Crayford  wrote:
> 
> Why doesn't it just use an executable jar and use "-jar"?


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 23:54, René Jansen wrote:

yes. https://github.com/RexxLA/NetRexx

The problem there is, you have lots of other things on CLASSPATH if you do any 
real development. Also, someone might not use the nrc script at all - I don’t, 
because I just have an alias nrc=“java org.netrexx.process.NetRexxC”.


I don't set a global CLASSPATH environment variable! That's completely 
bonkers.




Also, when used in environments without a Java compiler (and we see those often 
in companies, only a JRE) use want NetRexxF.jar because that includes the 
ecilpse Java compiler. Everything is documented, of course.

But I am open to suggestions! At least it should add a $CLASSPATH, not only the 
NetRexxC.jar


Why doesn't it just use an executable jar and use "-jar"?




best regards,

René.




On 1 Mar 2023, at 16:39, David Crayford  wrote:

On 1/3/23 23:13, David Crayford wrote:

I'm happy to verify on my PC but I found NetRexx to be hopeless on Linux. I've 
added the /bin to my PATH but it's failing because it can't load the NetRexxC 
classes even though I have set the /lib directory on my CLASSPATH. Must be 
optimized for Windows weenies.


Argghhh. Let me know when it's fixed. I hate candy machine interfaces. It's so 
easy to set the working directory relative to the binary in *nix systems!!

java org.netrexx.process.NetRexxC $*
if test $? -eq 0; then
   if test "$netrexx_run" = "yes"; then
 echo "Running $1..."
 if [ ! -f $1".class" ]; then
 echo "-run error: class file not found - do not add .nrx to 
name"
 exit
 fi
 java $1
   fi
fi




On 1/3/23 22:35, René Jansen wrote:

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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


--
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

Takeaway from the mentioned book referring BLAS in context of Python, Java, C ... Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rony G. Flatscher]

On 01.03.2023 15:15, René Jansen wrote:

Well yes - that is really apples and oranges, and thanks for proving my point.

Numpy leverages hand tuned assembly (BLAS) with hinting for different chip 
levels and architectures, and the difference with plain python is shown 
here:https://en.algorithmica.org/hpc/complexity/languages/  You can of course 
integrate OpenBLAS into everything.


... cut ...

The above chapter from the above URL has an interesting Takeaway at the end of that chapter, 
worthwhile citing in the context of this thread:



 # 
Takeaway

   The key lesson here is that using a native, low-level language doesn’t 
necessarily give you
   performance; but it does give you /control/ over performance.

   Complementary to the “N operations per second” simplification, many 
programmers also have a
   misconception that using different programming languages has some sort of 
multiplier on that
   number. Thinking this way and comparing languages
    in 
terms of performance
   doesn’t make much sense: programming languages are fundamentally just tools 
that take away
   /some/ control over performance in exchange for convenient abstractions. 
Regardless of the
   execution environment, it is still largely a programmer’s job to use the 
opportunities that the
   hardware provides.

---rony

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

yes. https://github.com/RexxLA/NetRexx

The problem there is, you have lots of other things on CLASSPATH if you do any 
real development. Also, someone might not use the nrc script at all - I don’t, 
because I just have an alias nrc=“java org.netrexx.process.NetRexxC”.

Also, when used in environments without a Java compiler (and we see those often 
in companies, only a JRE) use want NetRexxF.jar because that includes the 
ecilpse Java compiler. Everything is documented, of course.

But I am open to suggestions! At least it should add a $CLASSPATH, not only the 
NetRexxC.jar

best regards,

René.



> On 1 Mar 2023, at 16:39, David Crayford  wrote:
> 
> On 1/3/23 23:13, David Crayford wrote:
>> I'm happy to verify on my PC but I found NetRexx to be hopeless on Linux. 
>> I've added the /bin to my PATH but it's failing because it can't load the 
>> NetRexxC classes even though I have set the /lib directory on my CLASSPATH. 
>> Must be optimized for Windows weenies.
>> 
> Argghhh. Let me know when it's fixed. I hate candy machine interfaces. It's 
> so easy to set the working directory relative to the binary in *nix systems!!
> 
> java org.netrexx.process.NetRexxC $*
> if test $? -eq 0; then
>   if test "$netrexx_run" = "yes"; then
> echo "Running $1..."
> if [ ! -f $1".class" ]; then
> echo "-run error: class file not found - do not add .nrx to 
> name"
> exit
> fi
> java $1
>   fi
> fi
> 
> 
> 
>> On 1/3/23 22:35, René Jansen wrote:
>>> by the way, thanks for that url. It seems my NetRexx smokes your Python 
>>> with numpy - had not expected that.
>>> Note that NetRexx runs on z/OS and is well-maintained.
>>> 
>>> ➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
>>> joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes
>>> 
 On 1 Mar 2023, at 14:16, David Crayford  wrote:
 
 ❯ python3 PrimePy.py
 Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
 100, Count: 78498, Valid: True
 emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8
>>> best regards,
>>> 
>>> René.
>>> --
>>> 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


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 23:39, René Jansen wrote:

No, and I use it mostly on macOS and Linux.it is just what Java requires: the 
NetRexxC.jar file must be on CLASSPATH. It (CLASSPATH) takes files, not 
directories, you might be successful with a /* but I never do that.


I can fix the "nrc" script to set the CLASSPATH relative to the binary. 
Is it on github?







On 1 Mar 2023, at 16:13, David Crayford  wrote:

I'm happy to verify on my PC but I found NetRexx to be hopeless on Linux. I've 
added the /bin to my PATH but it's failing because it can't load the NetRexxC 
classes even though I have set the /lib directory on my CLASSPATH. Must be 
optimized for Windows weenies.

On 1/3/23 22:35, René Jansen wrote:

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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

--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

On 1/3/23 23:13, David Crayford wrote:
I'm happy to verify on my PC but I found NetRexx to be hopeless on 
Linux. I've added the /bin to my PATH but it's failing because it 
can't load the NetRexxC classes even though I have set the /lib 
directory on my CLASSPATH. Must be optimized for Windows weenies.


Argghhh. Let me know when it's fixed. I hate candy machine interfaces. 
It's so easy to set the working directory relative to the binary in *nix 
systems!!


java org.netrexx.process.NetRexxC $*
if test $? -eq 0; then
  if test "$netrexx_run" = "yes"; then
    echo "Running $1..."
    if [ ! -f $1".class" ]; then
    echo "-run error: class file not found - do not add 
.nrx to name"

    exit
    fi
    java $1
  fi
fi




On 1/3/23 22:35, René Jansen wrote:
by the way, thanks for that url. It seems my NetRexx smokes your 
Python with numpy - had not expected that.

Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, 
Limit: 100, Count: 78498, Valid: True
emillynge_numpy; 
6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

No, and I use it mostly on macOS and Linux.it is just what Java requires: the 
NetRexxC.jar file must be on CLASSPATH. It (CLASSPATH) takes files, not 
directories, you might be successful with a /* but I never do that.


> On 1 Mar 2023, at 16:13, David Crayford  wrote:
> 
> I'm happy to verify on my PC but I found NetRexx to be hopeless on Linux. 
> I've added the /bin to my PATH but it's failing because it can't load the 
> NetRexxC classes even though I have set the /lib directory on my CLASSPATH. 
> Must be optimized for Windows weenies.
> 
> On 1/3/23 22:35, René Jansen wrote:
>> by the way, thanks for that url. It seems my NetRexx smokes your Python with 
>> numpy - had not expected that.
>> Note that NetRexx runs on z/OS and is well-maintained.
>> 
>> ➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
>> joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes
>> 
>>> On 1 Mar 2023, at 14:16, David Crayford  wrote:
>>> 
>>> ❯ python3 PrimePy.py
>>> Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
>>> 100, Count: 78498, Valid: True
>>> emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8
>> best regards,
>> 
>> René.
>> --
>> 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

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

I'm happy to verify on my PC but I found NetRexx to be hopeless on 
Linux. I've added the /bin to my PATH but it's failing because it can't 
load the NetRexxC classes even though I have set the /lib directory on 
my CLASSPATH. Must be optimized for Windows weenies.


On 1/3/23 22:35, René Jansen wrote:

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes


On 1 Mar 2023, at 14:16, David Crayford  wrote:

❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
100, Count: 78498, Valid: True
emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

René.
--
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: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

by the way, thanks for that url. It seems my NetRexx smokes your Python with 
numpy - had not expected that.
Note that NetRexx runs on z/OS and is well-maintained.

➜  solution_2 git:(drag-race) ✗ PrimeNetRexx.class
joss_NetRexx;8766;5.000282;1;algorithm=base,bits=8,faithful=yes

> On 1 Mar 2023, at 14:16, David Crayford  wrote:
> 
> ❯ python3 PrimePy.py
> Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
> 100, Count: 78498, Valid: True
> emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

best regards,

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

Well yes - that is really apples and oranges, and thanks for proving my point.

Numpy leverages hand tuned assembly (BLAS) with hinting for different chip 
levels and architectures, and the difference with plain python is shown here: 
https://en.algorithmica.org/hpc/complexity/languages/ You can of course 
integrate OpenBLAS into everything.

It is not my problem that IBM chooses to starve the support of the assets that 
brought in money, or fails to innovate them. I would have expected all language 
products to be able to use Decimal Floating Point (DFP) instructions on the 
mainframe by now - but apparently the Rexx compiler does not know about those 
yet. The interpreter probably even less, as that is mostly 24 bit when the 
compiler still manages 31 and still has mode technical debt to clear.

All modern editing features (folding, syntax coloring) come from STET, LEXX, 
Xedit and ISPF/PDF. IBM choose with OS/2 to throw out the baby with the bath 
water, and did not develop wonderfull technology- LPEX, son of LEXX, was given 
to Eclipse and did not get significantly better. Meanwhile, everybody 
intergrated these ideas. The same goes for Python and Ruby, both done by people 
knowing Rexx.

The 1970’s did not have ISPF, that was only later, >1985, with SPF being around 
1984. These could have been developed into proper PC/Internet type 
editing/paneling systems which would have made building apps and webpages a lot 
easier and more fun than the current flock of js tools, which all more or less 
try to imitate the 3270 attribute byte model, but rather poorly. But don’t take 
my word for it, watch the market and see what people do.

I am not stating that Rexx (on the mainframe) has not been neglected, I am just 
worried that you need skewed benchmarks (and years of hand-tuned Fortran and 
Assembler) to present a false impression about a product that is not there yet.

best regards,

René.


> On 1 Mar 2023, at 14:16, David Crayford  wrote:
> 
> Have you heard of Dave Plummer's Primes benchmark project, which is widely 
> regarded as a reliable way to test the speed of programming languages? In 
> this test, ooRexx only managed to complete 13 passes in 5 seconds, while 
> Python with numpy completed 6969 passes, thanks to its ability to leverage 
> GPU processing power. Given that Python has a large community of developers 
> backed by big tech, it's not surprising that more investment is being made to 
> improve its performance compared to REXX. Similarly, TSO/ISPF is only 
> supported by one person, so IBM may not prioritize investing in it as they 
> focus on other strategic areas to keep the mainframe technology relevant. 
> While this news may not be welcomed by some, it's important to consider the 
> bigger picture of ensuring the longevity of mainframe technology. We need to 
> attract young talent to the platform not handcuff them with tools for the 
> 1970's no matter how comforting they may be for old timers like us.
> 
> ❯ rexx PrimeRexx.rex
> joss_REXX;13;5.084288;1;algorithm=base,bits=8,faithful=no
> 
> 
> 8:59
> ❯ python3 PrimePy.py
> Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, Limit: 
> 100, Count: 78498, Valid: True
> emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8
> 
> [1] https://github.com/PlummersSoftwareLLC/Primes
> 
> On 1/3/23 20:52, René Jansen wrote:
>> I agree with Rony. I think your ‘benchmarks’ are a bit synthetic but I 
>> understand your goal. I think calling ISPF ‘a relic’ and constantly 
>> badgering Rexx does not serve any purpose in front of this audience, most of 
>> which see ISPF as something shiny and worthwhile (e.g. to have on OS VS2 
>> r3.8 (clones of Rexx and ISPF have even been built there recently)).
>> 
>> We know IBM has divested some of its software maintenance. It is important 
>> to remember that ’the new mainframe’ *if casted in the image of Windows or 
>> Linux* always would be a hampered version of something. The mainframe is a 
>> high-end market and not everybody needs one anymore. It could be 
>> competitive, but it would need competition, a sane pricing scheme and less 
>> RACF admins reared in the 80’s ‘lock her down’ mindset. That last thing, not 
>> the toolset, is why it is hard to get new staff in.
>> 
>> If good tools were enabled young people would choose them and use them. 
>> There is no need for any badmouthing or skewed benchmarks. If one needs fast 
>> I/O, one writes assembler or COBOL.  It is important to not let new tools 
>> loose before their time, and seen the difference in the number of interfaces 
>> to the OS compared to Rexx, the time of Python has not come yet. I remember 
>> IBM or Rational people demoing the new GUI way of working to grumpy old 
>> COBOL programmers, and always having to open a 3270 TSO session to do 
>> something or other before the demo could go on. It was a laugh. In the end, 
>> it meant that the quality of people’s 3270 emulators went down the drain 

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[David Crayford]

Have you heard of Dave Plummer's Primes benchmark project, which is 
widely regarded as a reliable way to test the speed of programming 
languages? In this test, ooRexx only managed to complete 13 passes in 5 
seconds, while Python with numpy completed 6969 passes, thanks to its 
ability to leverage GPU processing power. Given that Python has a large 
community of developers backed by big tech, it's not surprising that 
more investment is being made to improve its performance compared to 
REXX. Similarly, TSO/ISPF is only supported by one person, so IBM may 
not prioritize investing in it as they focus on other strategic areas to 
keep the mainframe technology relevant. While this news may not be 
welcomed by some, it's important to consider the bigger picture of 
ensuring the longevity of mainframe technology. We need to attract young 
talent to the platform not handcuff them with tools for the 1970's no 
matter how comforting they may be for old timers like us.


❯ rexx PrimeRexx.rex
joss_REXX;13;5.084288;1;algorithm=base,bits=8,faithful=no


8:59
❯ python3 PrimePy.py
Passes: 6769, Time: 5.000584452878684, Avg: 0.0007387478878532551, 
Limit: 100, Count: 78498, Valid: True

emillynge_numpy; 6769;5.000584452878684;1;algorithm=base,faithful=no,bits=8

[1] https://github.com/PlummersSoftwareLLC/Primes

On 1/3/23 20:52, René Jansen wrote:

I agree with Rony. I think your ‘benchmarks’ are a bit synthetic but I 
understand your goal. I think calling ISPF ‘a relic’ and constantly badgering 
Rexx does not serve any purpose in front of this audience, most of which see 
ISPF as something shiny and worthwhile (e.g. to have on OS VS2 r3.8 (clones of 
Rexx and ISPF have even been built there recently)).

We know IBM has divested some of its software maintenance. It is important to 
remember that ’the new mainframe’ *if casted in the image of Windows or Linux* 
always would be a hampered version of something. The mainframe is a high-end 
market and not everybody needs one anymore. It could be competitive, but it 
would need competition, a sane pricing scheme and less RACF admins reared in 
the 80’s ‘lock her down’ mindset. That last thing, not the toolset, is why it 
is hard to get new staff in.

If good tools were enabled young people would choose them and use them. There 
is no need for any badmouthing or skewed benchmarks. If one needs fast I/O, one 
writes assembler or COBOL.  It is important to not let new tools loose before 
their time, and seen the difference in the number of interfaces to the OS 
compared to Rexx, the time of Python has not come yet. I remember IBM or 
Rational people demoing the new GUI way of working to grumpy old COBOL 
programmers, and always having to open a 3270 TSO session to do something or 
other before the demo could go on. It was a laugh. In the end, it meant that 
the quality of people’s 3270 emulators went down the drain and they were 
grumpier than ever.

I am sure Visual Studio Code is a nice editor (I sometimes use it on the Mac 
for markdown, mermaid plugins etc) but it is not going to sell mainframes - 
there will be VBS to confront, and maybe VSAM. And obj modules. And probably 
Cool:gen or RPG. What adaptation to modern dinky machines does, is more dynamic 
memory usage, more senseless multithreading and worse algorithms - just read in 
that 88MB XML file and shove it into a Db2 column. Where you used to be able to 
run an LPAR flat out at 100%, you cannot do that anymore because websphere and 
service oriented architecture.

With IBM’s current approach and its horrible handling of its intellectual 
property (sealing it off from a legal perspective, and neglecting it from a 
development point of view) the mainframe is going to be a niche market. That is 
not bad in itself: look at Tandem, long dead but still non-stop running a very 
large part of cards transactions.

If IBM had been serious about the cloud, it would have been forced to 
acknowledge that it would have been best and cheapest to run it on mainframe 
lpars in sysplexes and on COBOL, but alas, they were not serious at all and 
told us mainframe ‘always were the cloud’ but forgot to build one doing what 
they did best.

We like Xedit, we like ISPF. We like Rexx, and we are very fortunate that IBM 
open sourced Object Rexx and NetRexx before that window closed and the open 
sourcing was locked down with ‘business cases’. It also meant, of course, they 
are never going to maintain it again. We now see important parts in the hands 
of private companies, and we see everything we know built anew, but worse. And, 
old problems, once solved, are coming back (memory fragmentation anyone?). 
Transactions? We now have No-SQL but please don’t run my bank accounts on it. 
My suggestion would be to keep working on new things, but we don’t need the 
negative propaganda. On the other hand, now would be a good time for IBM to 
open source and publish everything they reaped the benefits from over and over, 
instead of 

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Rick Troth]

On 3/1/23 06:15, Rony G. Flatscher wrote:
As ooRexx is CMake based this should be quite feasible for such a huge 
computer company (having so many excellently skilled employees) like IBM. 


CMake seems to work well for ooRexx. But I counter the idea that it 
really facilitates building of ooRexx for all IBM platforms, nor would 
CMake facilitate integration of ooRexx with systems and applications.


In a former life, I opposed CMake because it explicitly stomps on 
hand-crafted makefiles. But that only matters if you're part of the 
development team. (For ooRexx, I'm not, so it matters less.)


More recently, I have finally managed to update my own "wrapper" build 
logic for ooRexx. (Many thanks to René and others for helping me on that 
point.) But I find that CMake varies enough from one platform to the 
next that I've only been able to build ooRexx on /one/ of the half dozen 
target systems. So I'm now having supplemental CMake pain. (Apart from 
issues when I was a developer and beyond learning curve and relocation 
of curdled dairy products.)


Good multi-platform readiness has to happen at a deeper level. From what 
I see, ooRexx can get their, but it's not a drop-in.
Seamless integration has to work in the bowels of the interpreter. Of 
that I can see very little w/r/t ooRexx. (I do see that Regina is ripe 
for integration, but was not / am not raising a flag against ooRexx in 
this note.)



-- R; <><


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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[René Jansen]

I agree with Rony. I think your ‘benchmarks’ are a bit synthetic but I 
understand your goal. I think calling ISPF ‘a relic’ and constantly badgering 
Rexx does not serve any purpose in front of this audience, most of which see 
ISPF as something shiny and worthwhile (e.g. to have on OS VS2 r3.8 (clones of 
Rexx and ISPF have even been built there recently)).

We know IBM has divested some of its software maintenance. It is important to 
remember that ’the new mainframe’ *if casted in the image of Windows or Linux* 
always would be a hampered version of something. The mainframe is a high-end 
market and not everybody needs one anymore. It could be competitive, but it 
would need competition, a sane pricing scheme and less RACF admins reared in 
the 80’s ‘lock her down’ mindset. That last thing, not the toolset, is why it 
is hard to get new staff in.

If good tools were enabled young people would choose them and use them. There 
is no need for any badmouthing or skewed benchmarks. If one needs fast I/O, one 
writes assembler or COBOL.  It is important to not let new tools loose before 
their time, and seen the difference in the number of interfaces to the OS 
compared to Rexx, the time of Python has not come yet. I remember IBM or 
Rational people demoing the new GUI way of working to grumpy old COBOL 
programmers, and always having to open a 3270 TSO session to do something or 
other before the demo could go on. It was a laugh. In the end, it meant that 
the quality of people’s 3270 emulators went down the drain and they were 
grumpier than ever.

I am sure Visual Studio Code is a nice editor (I sometimes use it on the Mac 
for markdown, mermaid plugins etc) but it is not going to sell mainframes - 
there will be VBS to confront, and maybe VSAM. And obj modules. And probably 
Cool:gen or RPG. What adaptation to modern dinky machines does, is more dynamic 
memory usage, more senseless multithreading and worse algorithms - just read in 
that 88MB XML file and shove it into a Db2 column. Where you used to be able to 
run an LPAR flat out at 100%, you cannot do that anymore because websphere and 
service oriented architecture.

With IBM’s current approach and its horrible handling of its intellectual 
property (sealing it off from a legal perspective, and neglecting it from a 
development point of view) the mainframe is going to be a niche market. That is 
not bad in itself: look at Tandem, long dead but still non-stop running a very 
large part of cards transactions.

If IBM had been serious about the cloud, it would have been forced to 
acknowledge that it would have been best and cheapest to run it on mainframe 
lpars in sysplexes and on COBOL, but alas, they were not serious at all and 
told us mainframe ‘always were the cloud’ but forgot to build one doing what 
they did best.

We like Xedit, we like ISPF. We like Rexx, and we are very fortunate that IBM 
open sourced Object Rexx and NetRexx before that window closed and the open 
sourcing was locked down with ‘business cases’. It also meant, of course, they 
are never going to maintain it again. We now see important parts in the hands 
of private companies, and we see everything we know built anew, but worse. And, 
old problems, once solved, are coming back (memory fragmentation anyone?). 
Transactions? We now have No-SQL but please don’t run my bank accounts on it. 
My suggestion would be to keep working on new things, but we don’t need the 
negative propaganda. On the other hand, now would be a good time for IBM to 
open source and publish everything they reaped the benefits from over and over, 
instead of allowing it to wither and waste. And IBM should invent some good new 
stuff.

best regards,

René.




> On 1 Mar 2023, at 12:15, Rony G. Flatscher  wrote:
> 
> On 28.02.2023 20:55, David Crayford wrote:
>> I respectfully express my opinion without intending to badmouth anyone. I 
>> believe that benchmarking the performance of reading a large file is not an 
>> artificial test but rather a real-world use case that we encounter 
>> regularly. It is no secret that REXX on z/OS can be slow. In fact, one of my 
>> colleagues who worked on the IBM File Manager product, which incorporates 
>> REXX scripting, developed their own subset of REXX because the performance 
>> of the TSO REXX interpreter did not meet their objectives.
> 
> If that is the case then it shows that IBM needs to maintain their mainframe 
> REXX by replacing it with an up-to-date version of REXX (finally).

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

Re: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and zOWE for non-mainframers

[Seymour J Metz]

Is there an active SHARE requirement for ANSI Rexx, ooRexx or both?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rony G. Flatscher [rony.flatsc...@wu.ac.at]
Sent: Wednesday, March 1, 2023 6:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mainframe REXX (Re: Badmouthing Rexx and ooRexx - again (Re: zOSMF and 
zOWE for non-mainframers

On 28.02.2023 20:55, David Crayford wrote:
> I respectfully express my opinion without intending to badmouth anyone. I 
> believe that
> benchmarking the performance of reading a large file is not an artificial 
> test but rather a
> real-world use case that we encounter regularly. It is no secret that REXX on 
> z/OS can be slow. In
> fact, one of my colleagues who worked on the IBM File Manager product, which 
> incorporates REXX
> scripting, developed their own subset of REXX because the performance of the 
> TSO REXX interpreter
> did not meet their objectives.

If that is the case then it shows that IBM needs to maintain their mainframe 
REXX by replacing it
with an up-to-date version of REXX (finally).

ooRexx would be a candidate as extending it with external function packages and 
Rexx command
handlers can be done with C++ and Java. ooRexx was developed by IBM and has 
been put into
open-source by the Rexx Language [1] association after having received the 
source code by IBM for
that purpose.

Besides allowing the REXX coding knowledge to be used/applied immediately, a 
lot of benefitial
abilities would become available at a finger tip, including among other things 
the ability to
quickly create datastructures (classes) with attributes and routines if needed 
and gaining an
incredible flexibility (to ease coding problems) with the incorporated message 
paradigm making it a
natural language for any message/queue based infrastructures.

Of course, such a port needs to be done by knowledgeable and professional 
people who have no hidden
agenda to make it (or any other interpreted language) look bad, au contraire, 
having the motivation
to get the best possible port for mainframes and thereby for REXX programmers 
on the mainframe.

As ooRexx is CMake based this should be quite feasible for such a huge computer 
company (having so
many excellently skilled employees) like IBM.

---rony

[1] Rexx Language Association (RexxLA): 
<https://secure-web.cisco.com/19iB6XFennLVR93zmClbWGzrdq7uKmdmpKM26zmYYFkx1SXKSmNJInPztD75m_c2w6m6Lm91pvcorl1DR0YJ51ueLH2AxAeU7AwhYCk6YeKQXuoR2Hc6JyloTzBcvJEzJrazivTQRt3_kKkU4gk-nmcHz0jkPwdR2-wNNpYiRW8dkF-J59fYB16qqatZM1hbd2JKBwO8xkaYPVfNIswtlruSb_uePofnChxwan22hoL7LYv33sRuzFuhXUITBj24cL3Ww0KZZ3emytmmqxYxXm_QJn9BHnDLoI2BB_JG49JZKpj5-hvyjM6kcdiEiRO_jk9LKPm7VeRyrOlD61rTnzNGxONfFuNhcjdgv_Z99aDhM_MRY7mAJvrAs0s_zl2u_j1wYOzC-jVAmX1KWz9HYV8xGoqU0XxL7pf7apAzG-K7A2OYad114tLXK3NaUHX4p/https%3A%2F%2Fwww.RexxLA.org>

--
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