Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Farley, Peter x23353]

You're on your own for z/OS-specific python scripts.  Mr. Google will let you 
see many python examples out on the net, but none I suspect oriented on z/OS 
facilities.

As for JCL, I use IBM's batch utility to run awk scripts, I don't know of 
python will work in the same way due to the difference between the open() and 
fopen() library routines in the IBM C library.  The awk command uses fopen() 
which allows DD's to be used as files, many other IBM Unix commands use open() 
which does NOT allow DD's to be used as files.  I do not know what the IBM or 
Rocket python implementation is using, as I do not have it here to test (we are 
at 2.3 here).

The fopen() vs open() differences may well disappear with the announced move to 
"full dataset access" for z/OS Unix services, but we don't have a delivery date 
for that functionality that I have seen.

Here is an example awk JCL I have used successfully:

//**
//* INVOKE AWK SCRIPT 
//**
// EXPORT SYMLIST=*
//RUNAWK   EXEC PGM=BPXBATCH,   
// PARMDD=PARMIN
//STDOUT   DD  DISP=(NEW,CATLG,CATLG),  
// DSN=,   
// UNIT=SYSDA,SPACE=(CYL,(050,050),RLSE),
// DSORG=PS,RECFM=VA,LRECL=516,BLKSIZE=0,BUFNO=31   
//STDERR   DD  SYSOUT=* 
//SCRIPT   DD  DISP=SHR,DSN=(TESTAWK)  
//AWKINDD  DISP=SHR,DSN=,  
// BUFNO=31 
//STDENV   DD  *
_BPX_SHAREAS=MUST   
_BPX_BATCH_SPAWN=YES
//STDINDD  DUMMY
//PARMIN   DD  *,SYMBOLS=JCLONLY
PGM /bin/awk -v OUTF=//DD:STDOUT -f //DD:SCRIPT //''
 
  //DD:AWKIN
//

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Billy Ashton
Sent: Thursday, January 13, 2022 10:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

All of this sounds interesting, so if I wanted to try out some Python scripts 
to see how they stack up to Rexx, where might I find some Python source members 
along with JCL members to run them?

Thanks!
Billy

-- Original Message --
From "Farley, Peter x23353" 
<031df298a9da-dmarc-requ...@listserv.ua.edu>
To IBM-MAIN@listserv.ua.edu
Date 1/13/2022 10:49:48 AM
Subject Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

>It is my understanding that Java is and has been available in z/OS for a long 
>time now, but not from TSO or CLIST directly.  From REXX via SYSCALL and 
>BPXWUNIX I suspect it is possible, but not from, e.g., the TSO / ISPF command 
>line directly
--

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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Billy Ashton]

All of this sounds interesting, so if I wanted to try out some Python 
scripts to see how they stack up to Rexx, where might I find some Python 
source members along with JCL members to run them?


Thanks!
Billy

-- Original Message --
From "Farley, Peter x23353" 

<031df298a9da-dmarc-requ...@listserv.ua.edu>
To IBM-MAIN@listserv.ua.edu
Date 1/13/2022 10:49:48 AM
Subject Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming 
features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for 
z/OS



It is my understanding that Java is and has been available in z/OS for a long 
time now, but not from TSO or CLIST directly.  From REXX via SYSCALL and 
BPXWUNIX I suspect it is possible, but not from, e.g., the TSO / ISPF command 
line directly


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

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Farley, Peter x23353]

It is my understanding that Java is and has been available in z/OS for a long 
time now, but not from TSO or CLIST directly.  From REXX via SYSCALL and 
BPXWUNIX I suspect it is possible, but not from, e.g., the TSO / ISPF command 
line directly.

The python interpreter is I think going to be standard at z/OS 2.5, with I 
think IBM's version and not Rocket's (unless IBM's is just a repackaging of the 
Rocket version, which I do not know one way or the other).

My general impression is that you will be able to use python from the Unix 
system services command line, but not directly from TSO or CLIST.  Obviously 
also available in batch via one of the XXXBATCH programs (IBM's or Dovetail's). 
 I run awk scripts in batch that way with no issues, though I often wish they 
had gawk instead of the POSIX awk they now provide.

What I also wish IBM would provide as a standard component is the bash shell.  
Their POSIX sh and tcsh are difficult for me to use, and I suspect for others 
as well.  Knowledge of the bash shell is far more pervasive in the community 
(and particularly in the generations following us) than either of the two 
shells IBM now provides.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Wednesday, January 12, 2022 7:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I keep seeing references like this, from time to time, but so far whenever I 
ask I get answers that aren't quite what I was looking for.  Am I hearing that 
both Java and Python are available in TSO, like CLIST and REXX?  Or only in 
some environment with which I am (so far) unfamiliar, such as OMVS?  I'm 
thinking it's about time I tacked on another language or two, but I'm most 
interested in one that requires the least effort by a client to maintain it 
afterward.  No languages that aren't already built in, that would be, and it 
should be accessible from TSO because most of the folks who hire me aren't Unix 
jocks.

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

/* To punish me for my contempt for authority, Fate made me an authority 
myself.  -Albert Einstein */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Wednesday, January 12, 2022 06:45

I did run a Javascript benchtest on z/OS using IBMs Node.js port. I was 
pleasantly surprised to see that IBM have done an amazing job porting the V8 
JavaScript engine to z/OS. It nukes Python.
--

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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bob Bridges]

I keep seeing references like this, from time to time, but so far whenever I 
ask I get answers that aren't quite what I was looking for.  Am I hearing that 
both Java and Python are available in TSO, like CLIST and REXX?  Or only in 
some environment with which I am (so far) unfamiliar, such as OMVS?  I'm 
thinking it's about time I tacked on another language or two, but I'm most 
interested in one that requires the least effort by a client to maintain it 
afterward.  No languages that aren't already built in, that would be, and it 
should be accessible from TSO because most of the folks who hire me aren't Unix 
jocks.

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

/* To punish me for my contempt for authority, Fate made me an authority 
myself.  -Albert Einstein */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Wednesday, January 12, 2022 06:45

I did run a Javascript benchtest on z/OS using IBMs Node.js port. I was 
pleasantly surprised to see that IBM have done an amazing job porting the V8 
JavaScript engine to z/OS. It nukes Python.

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

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> If only I could remember CLIST, Tom!

If only I could forget CLIST! The paired apostrophes could replicate to an 
obscene degree, especially after the enhancements in OS/VS2 R3.6; REXX is much 
cleaner.

Do you mean that IBM's JS port is faster, or that you prefer JS to Python? If 
the latter, why?


--
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: Wednesday, January 12, 2022 6:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 12/1/22 1:41 am, Tom Brennan wrote:
> Nice! Now do CLIST

If only I could remember CLIST, Tom! I did work on a project last year
where I had to convert 3 CLIST scripts to REXX and it quite was painful.
Variable substitution killed me, but I remembered it from the NetMaster
NCL language.

I did run a Javascript benchtest on z/OS using IBMs Node.js port. I was
pleasantly surprised to see that IBM have done an amazing job porting
the V8 JavaScript engine to z/OS. It nukes Python.

 > cat squares.js
let MAX = 1000
let s = []
for (i = 1; i <= MAX; i++) {
 let square = i * i
 s.push(square)
}

function getMax(arr) {
 let len = arr.length;
 let max = -Infinity;
 while (len--) {
 max = arr[len] > max ? arr[len] : max;
 }
 return max;
}

console.log(getMax(s))

 > time node squares.js
100
real0m0.384s
user0m0.195s
sys 0m0.076s (edited)

>
> Ok, just joking.  I was probably the last person on my block to switch
> from CLIST to Rexx when it became available on MVS.  A simple thing
> finally pushed me over:  I ran a small performance test and Rexx beat
> CLIST by about 1000 times if I remember correctly.  So I pulled out
> the Rexx manuals.
>
> On 1/10/2022 8:46 PM, David Crayford wrote:
>> On 10/1/22 11:15 pm, Seymour J Metz wrote:
 ooRexx will never be high speed because it's implementation is
 fundamentally ineffecient.
>>> That seems to be begging the question. Certainly the current
>>> implementation is inefficient, but what fundamental issue prevents a
>>> more efficient implementation?
>>
>> A more effecient implementation requires a rewrite.
>>
>>> For that matter, what fundamental issue prevents compiling into Java
>>> bytecode with a large runtime similar to the CREXX runtime?
>>
>> None. TBH, I hadn't had much of a look at NetRexx but it's promising.
>> It's strongly typed and the JVM is going to JIT compile it so it will
>> be fast. As Rene mentioned you can use Java classes so there is a
>> massive eco-system available.
>>
>>
>> I knocked up some simple benchtests which create an array of squares
>> and then find the maximum value. The maximum value is the end
>> element. The results are just what I expected. ooRexx performs poorly.
>> Stem variables are particularly bad which is to be expected because
>> they are essentially associative arrays. Using the Array class was
>> much better but the result was still many orders of magnitude worse
>> then the
>> other languages I tested. What's interesting is that LuaJIT is as
>> fast as C++ and interpreted Lua is almost as fast as Julia which has
>> JIT.
>>
>> ❯ rexx -v
>> Open Object Rexx Version 4.2.0
>> Build date: Dec 29 2013
>> Addressing Mode: 64
>> Copyright (c) IBM Corporation 1995, 2004.
>> Copyright (c) RexxLA 2005-2013.
>> All Rights Reserved.
>> This program and the accompanying materials are made available under
>> the terms of the Common Public License v1.0 which accompanies this
>> distribution or at
>> http://secure-web.cisco.com/1r_GTvH-Plr8ga-NNHsh2cO1nRoevr5kRKDrdZ1jHQ7CGKP_SGwZRBiTJXQQbF1MOTARH8uTbgZcumlkPqn3ERVJ0BfUPOhaQEM-sEs_oZWm0f5hdit6_QGQyshydNDBVG8y0pNMEuUSkjLu6HmKb7K3dIX40NKRDtrl0xEvRhzPxaOpK16EuT76LOHpNHEArCotpR_L9qX7LQcipUur57l9wPu9xgAXNddwW5YyT_dOS_E5ZAJcleFzwBnH1Slg_5o_fu-shk06cOzlukGKoy8QNsB878WuJ8c0G91_uphoQ3GPNT8Vnk0SA7qZ2dNPugmiuzGffPegh8dcKtogqgQveDXHWkUaZ8kiylT--uprM23EgppVvySkWNy9v4baI_5TWIPuvhQ2VVJR1Nu7tSjgAxH19m9MXPWEnaN1V3vrvjQMt-v9Pd79ORJHUjnff/http%3A%2F%2Fwww.oorexx.org%2Flicense.html
>>
>> ❯ cat squares.rexx
>> /* REXX */
>> numeric digits 30
>> MAX = 1000
>> s. = 0
>> do n = 1 to MAX
>>s.n = n * n
>> end
>> m = 0
>> do i = 1 to MAX
>>m = max(m, s.i)
>> end
>> say max
>>
>> ❯ time rexx squares.rexx
>> 1000rexx squares.rexx  43.04s user 3.25s system 99% cpu 46.296 total
>>
>> ❯ cat squares2.rexx
>> numeric digits 30
>> s = .Array~new()
>> do n = 1 to 1000
>>s~append(n * n)
>> end
>> m = 0
>> do n = 1 to s~items
>>m = max(m, s[n])
>> end
>> say m
>>
>> ❯ time rexx squares2.rexx
>> 100
>> rexx squares2.rexx  17.25s user 1.32s system 99% cpu 18.568 total
>>
>> ❯ lua -v
>> Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
>>
>> local s = {}
>> for n = 1, 1000 do
>> s[n] = n 

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 12/1/22 1:41 am, Tom Brennan wrote:

Nice! Now do CLIST


If only I could remember CLIST, Tom! I did work on a project last year 
where I had to convert 3 CLIST scripts to REXX and it quite was painful. 
Variable substitution killed me, but I remembered it from the NetMaster 
NCL language.


I did run a Javascript benchtest on z/OS using IBMs Node.js port. I was 
pleasantly surprised to see that IBM have done an amazing job porting 
the V8 JavaScript engine to z/OS. It nukes Python.


> cat squares.js
let MAX = 1000
let s = []
for (i = 1; i <= MAX; i++) {
    let square = i * i
    s.push(square)
}

function getMax(arr) {
    let len = arr.length;
    let max = -Infinity;
    while (len--) {
    max = arr[len] > max ? arr[len] : max;
    }
    return max;
}

console.log(getMax(s))

> time node squares.js
100
real    0m0.384s
user    0m0.195s
sys 0m0.076s (edited)



Ok, just joking.  I was probably the last person on my block to switch 
from CLIST to Rexx when it became available on MVS.  A simple thing 
finally pushed me over:  I ran a small performance test and Rexx beat 
CLIST by about 1000 times if I remember correctly.  So I pulled out 
the Rexx manuals.


On 1/10/2022 8:46 PM, David Crayford wrote:

On 10/1/22 11:15 pm, Seymour J Metz wrote:

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient.
That seems to be begging the question. Certainly the current 
implementation is inefficient, but what fundamental issue prevents a 
more efficient implementation?


A more effecient implementation requires a rewrite.

For that matter, what fundamental issue prevents compiling into Java 
bytecode with a large runtime similar to the CREXX runtime?


None. TBH, I hadn't had much of a look at NetRexx but it's promising. 
It's strongly typed and the JVM is going to JIT compile it so it will 
be fast. As Rene mentioned you can use Java classes so there is a 
massive eco-system available.



I knocked up some simple benchtests which create an array of squares 
and then find the maximum value. The maximum value is the end 
element. The results are just what I expected. ooRexx performs poorly.
Stem variables are particularly bad which is to be expected because 
they are essentially associative arrays. Using the Array class was 
much better but the result was still many orders of magnitude worse 
then the
other languages I tested. What's interesting is that LuaJIT is as 
fast as C++ and interpreted Lua is almost as fast as Julia which has 
JIT.


❯ rexx -v
Open Object Rexx Version 4.2.0
Build date: Dec 29 2013
Addressing Mode: 64
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2013.
All Rights Reserved.
This program and the accompanying materials are made available under
the terms of the Common Public License v1.0 which accompanies this
distribution or at
http://www.oorexx.org/license.html

❯ cat squares.rexx
/* REXX */
numeric digits 30
MAX = 1000
s. = 0
do n = 1 to MAX
   s.n = n * n
end
m = 0
do i = 1 to MAX
   m = max(m, s.i)
end
say max

❯ time rexx squares.rexx
1000rexx squares.rexx  43.04s user 3.25s system 99% cpu 46.296 total

❯ cat squares2.rexx
numeric digits 30
s = .Array~new()
do n = 1 to 1000
   s~append(n * n)
end
m = 0
do n = 1 to s~items
   m = max(m, s[n])
end
say m

❯ time rexx squares2.rexx
100
rexx squares2.rexx  17.25s user 1.32s system 99% cpu 18.568 total

❯ lua -v
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio

local s = {}
for n = 1, 1000 do
    s[n] = n * n
end
local max = 0
for _, n in ipairs(s) do
   max = math.max(max, n)
end
print(max)

❯ time lua squares.lua
100
lua squares.lua  0.79s user 0.07s system 99% cpu 0.862 total

❯ luajit -v
LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. 
http://luajit.org/


❯ time luajit squares.lua
1e+14
luajit squares.lua  0.08s user 0.05s system 99% cpu 0.137 total

❯ python3 --version
Python 3.8.10

❯ cat squares.py
s = []
for n in range(1, 1000+1):
 s.append(n * n)
print(max(s))

❯ time python3 squares.py
100
python3 squares.py  1.13s user 0.16s system 99% cpu 1.288 total

❯ julia --version
julia version 1.4.1

❯ cat squares.jl
s = Int[]
for n = 1:1000
   push!(s, n * n)
end
println(maximum(s))

❯ time julia squares.jl
100
julia squares.jl  0.56s user 0.74s system 214% cpu 0.608 total

❯ clang++ --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

❯ cat squares.cpp
#include 
#include 
#include 
#include 
int main() {
 constexpr int MAX = 1000;
 std::vector s(MAX);
 for (uint64_t n = 1; n <= MAX; n++) s.push_back(n * n);
 std::cout << *std::max_element(s.begin(), s.end()) << "\n";

❯ time ./squares
100
./squares  0.05s user 0.05s system 99% cpu 0.107 total





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


From: IBM Mainframe Discussion List 

Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

I can't remember other than it was only around 10 lines.  I think just 
variable access and some simple calculations.


On 1/11/2022 10:47 AM, Paul Gilmartin wrote:

What didn't your "small performance test" do?


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

Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

(Subject: and content trimmed.)
On Tue, 11 Jan 2022 09:41:23 -0800, Tom Brennan wrote:
>...
>finally pushed me over:  I ran a small performance test and Rexx beat
>CLIST by about 1000 times if I remember correctly.  So I pulled out the
>Rexx manuals.
>
Back in the day when fiche was available I ran a code coverage tool on a
CLIST with a "do very little" loop.  The preponderance of time was spent
in CALL/RETURN from "get one source character" routine.  Great
structure; lousy performance.  I assume they never heard of macros.

CLIST performance was supposed to improve with TSO/E R2 and code
reusable between Rexx/CLIST, but no fiche.

What didn't your "small performance test" do?

-- gil

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

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

Nice!  Now do CLIST

Ok, just joking.  I was probably the last person on my block to switch 
from CLIST to Rexx when it became available on MVS.  A simple thing 
finally pushed me over:  I ran a small performance test and Rexx beat 
CLIST by about 1000 times if I remember correctly.  So I pulled out the 
Rexx manuals.


On 1/10/2022 8:46 PM, David Crayford wrote:

On 10/1/22 11:15 pm, Seymour J Metz wrote:

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient.
That seems to be begging the question. Certainly the current 
implementation is inefficient, but what fundamental issue prevents a 
more efficient implementation?


A more effecient implementation requires a rewrite.

For that matter, what fundamental issue prevents compiling into Java 
bytecode with a large runtime similar to the CREXX runtime?


None. TBH, I hadn't had much of a look at NetRexx but it's promising. 
It's strongly typed and the JVM is going to JIT compile it so it will be 
fast. As Rene mentioned you can use Java classes so there is a massive 
eco-system available.



I knocked up some simple benchtests which create an array of squares and 
then find the maximum value. The maximum value is the end element. The 
results are just what I expected. ooRexx performs poorly.
Stem variables are particularly bad which is to be expected because they 
are essentially associative arrays. Using the Array class was much 
better but the result was still many orders of magnitude worse then the
other languages I tested. What's interesting is that LuaJIT is as fast 
as C++ and interpreted Lua is almost as fast as Julia which has JIT.


❯ rexx -v
Open Object Rexx Version 4.2.0
Build date: Dec 29 2013
Addressing Mode: 64
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2013.
All Rights Reserved.
This program and the accompanying materials are made available under
the terms of the Common Public License v1.0 which accompanies this
distribution or at
http://www.oorexx.org/license.html

❯ cat squares.rexx
/* REXX */
numeric digits 30
MAX = 1000
s. = 0
do n = 1 to MAX
   s.n = n * n
end
m = 0
do i = 1 to MAX
   m = max(m, s.i)
end
say max

❯ time rexx squares.rexx
1000rexx squares.rexx  43.04s user 3.25s system 99% cpu 46.296 total

❯ cat squares2.rexx
numeric digits 30
s = .Array~new()
do n = 1 to 1000
   s~append(n * n)
end
m = 0
do n = 1 to s~items
   m = max(m, s[n])
end
say m

❯ time rexx squares2.rexx
100
rexx squares2.rexx  17.25s user 1.32s system 99% cpu 18.568 total

❯ lua -v
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio

local s = {}
for n = 1, 1000 do
    s[n] = n * n
end
local max = 0
for _, n in ipairs(s) do
   max = math.max(max, n)
end
print(max)

❯ time lua squares.lua
100
lua squares.lua  0.79s user 0.07s system 99% cpu 0.862 total

❯ luajit -v
LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/

❯ time luajit squares.lua
1e+14
luajit squares.lua  0.08s user 0.05s system 99% cpu 0.137 total

❯ python3 --version
Python 3.8.10

❯ cat squares.py
s = []
for n in range(1, 1000+1):
     s.append(n * n)
print(max(s))

❯ time python3 squares.py
100
python3 squares.py  1.13s user 0.16s system 99% cpu 1.288 total

❯ julia --version
julia version 1.4.1

❯ cat squares.jl
s = Int[]
for n = 1:1000
   push!(s, n * n)
end
println(maximum(s))

❯ time julia squares.jl
100
julia squares.jl  0.56s user 0.74s system 214% cpu 0.608 total

❯ clang++ --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

❯ cat squares.cpp
#include 
#include 
#include 
#include 
int main() {
     constexpr int MAX = 1000;
     std::vector s(MAX);
     for (uint64_t n = 1; n <= MAX; n++) s.push_back(n * n);
     std::cout << *std::max_element(s.begin(), s.end()) << "\n";

❯ time ./squares
100
./squares  0.05s user 0.05s system 99% cpu 0.107 total





--
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: Monday, January 10, 2022 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming 
features (Re: ... Re: Top 8 Reasons for using Python instead of REXX 
for z/OS


On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.
What do you mean by "the message paradigm"? How does it differ from 
sending method invocation and response messages to objects?
The message paradigm as set forth by Smalltalk explicitly defines a 
class for messages, allows for
intercepting messages, rerouting messages at the will of the 
programmer and much more, as messages
themselves become objects that the programmer can interact with, if 
needed.


ooRexx implements the 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 11.01.2022 14:06, David Crayford wrote:
> I've gone silent now Rony. But if you're a Windows user you may want to check 
> out Measure-Command
> for PowerShell so you don't have to instrument your code with timers.
>
> [1]
> https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/measure-command?view=powershell-7.2

Thank you for this pointer, David!

Mostly I have been working on Windows, but also on Linux and MacOS, for making 
sure that BSF4ooRexx
runs flawlessly and seamlessly on all those platforms.

---rony


>
> On 11/1/22 8:30 pm, Rony G. Flatscher wrote:
>> And here an example of ooRexx being used without any direct access to Java:
>>
>>  d1=.datetime~new  /* take time   */
>>  "java squares"    /* run command */
>>  d2=.datetime~new  /* take time   */
>>  say "duration:" d2-d1
>>
>> The results of running this program are:
>>
>>  G:\tmp\ibmmain\arrays>squares_oorexx.rex
>>  100
>>  duration: 00:00:00.247000
>>
>>  G:\tmp\ibmmain\arrays>squares_oorexx.rex
>>  100
>>  duration: 00:00:00.242000
>>
>> Quite fast! ;)
>>
>> ---rony
>>
>> On 11.01.2022 13:15, Rony G. Flatscher wrote:
>>> Now, if you want ooRexx to control an application and need to run the 
>>> NetRexx program from it, you
>>> can do that with ooRexx (including timings) as such:
>>>
>>>  /* ooRexx solution to control execution of NetRexx' squares  */
>>>  clz=bsf.loadClass("squares")  /* load NetRexx' squares class */
>>>
>>>  /* create an empty Java array of type java.lang.String   */
>>>  arr=bsf.createJavaArrayOf("java.lang.String")
>>>
>>>  d1=.dateTime~new  /* take time   */
>>>  /* run main method which expects a Java String array */
>>>  clz~main(arr)
>>>  d2=.dateTime~new  /* take time   */
>>>  say "duration:" d2-d1
>>>
>>>  ::requires "BSF.CLS" /* get full access to Java  */
>>>
>>> The results of running this program are, believe it or not, even faster:
>>>
>>>  G:\tmp\ibmmain\arrays>rexx squares.rxj
>>>  100
>>>  duration: 00:00:00.095000
>>>
>>>  G:\tmp\ibmmain\arrays>rexx squares.rxj
>>>  100
>>>  duration: 00:00:00.109000
>>>
>>> So the interpreted ooRexx can even beat ... :)
>>>
>>> ---rony
>>>
>>>
>>> On 11.01.2022 12:21, Rony G. Flatscher wrote:
 On 11.01.2022 05:46, David Crayford wrote:
> On 10/1/22 11:15 pm, Seymour J Metz wrote:
>>> ooRexx will never be high speed because it's implementation is
>>> fundamentally ineffecient.
>> That seems to be begging the question. Certainly the current 
>> implementation is inefficient, but
>> what fundamental issue prevents a more efficient implementation?
> A more effecient implementation requires a rewrite.
>
>> For that matter, what fundamental issue prevents compiling into Java 
>> bytecode with a large
>> runtime similar to the CREXX runtime?
> None. TBH, I hadn't had much of a look at NetRexx but it's promising. 
> It's strongly typed and the
> JVM is going to JIT compile it so it will be fast. As Rene mentioned you 
> can use Java classes so
> there is a massive eco-system available.
 BTW, you could use Java classes from ooRexx as well, hence there is a 
 "massive eco-system
 available"
 for ooRexx. You would need the external function package named BSF4ooRexx, 
 which enables ooRexx to
 work with any Java class library, no matter whether it got created with 
 Java, NetRexx, Kotlin,
 Groovy, ...

> I knocked up some simple benchtests which create an array of squares and 
> then find the maximum
> value. The maximum value is the end element. The results are just what I 
> expected. ooRexx
> performs
> poorly.
 Not a surprise. :)

 This "simple benchtest" is architected in a way that makes interpreted 
 languages look
 especially bad
 compared to compiled languages, it is of a form that is not relevant in 
 real life. Also, using
 unnecessarily numeric 30 digits for the arithmetics is interesting, as 
 well as the outdated, seven
 year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.


> Stem variables are particularly bad which is to be expected because they 
> are essentially
> associative arrays. Using the Array class was much better but the result 
> was still many orders of
> magnitude worse then the
> other languages I tested. What's interesting is that LuaJIT is as fast as 
> C++ and interpreted Lua
> is almost as fast as Julia which has JIT.
 Not a surprise. :)

 Now, if it was truly the case that someone would need such an abmysal 
 amount of number crunching
 then speed becomes interesting. In such a case what I would do for any 
 interpreted language, I
 would
 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

I've gone silent now Rony. But if you're a Windows user you may want to 
check out Measure-Command for PowerShell so you don't have to instrument 
your code with timers.


[1] 
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/measure-command?view=powershell-7.2



On 11/1/22 8:30 pm, Rony G. Flatscher wrote:

And here an example of ooRexx being used without any direct access to Java:

 d1=.datetime~new  /* take time   */
 "java squares"/* run command */
 d2=.datetime~new  /* take time   */
 say "duration:" d2-d1

The results of running this program are:

 G:\tmp\ibmmain\arrays>squares_oorexx.rex
 100
 duration: 00:00:00.247000

 G:\tmp\ibmmain\arrays>squares_oorexx.rex
 100
 duration: 00:00:00.242000

Quite fast! ;)

---rony

On 11.01.2022 13:15, Rony G. Flatscher wrote:

Now, if you want ooRexx to control an application and need to run the NetRexx 
program from it, you
can do that with ooRexx (including timings) as such:

 /* ooRexx solution to control execution of NetRexx' squares  */
 clz=bsf.loadClass("squares")  /* load NetRexx' squares class */

 /* create an empty Java array of type java.lang.String   */
 arr=bsf.createJavaArrayOf("java.lang.String")

 d1=.dateTime~new  /* take time   */
 /* run main method which expects a Java String array */
 clz~main(arr)
 d2=.dateTime~new  /* take time   */
 say "duration:" d2-d1

 ::requires "BSF.CLS" /* get full access to Java  */

The results of running this program are, believe it or not, even faster:

 G:\tmp\ibmmain\arrays>rexx squares.rxj
 100
 duration: 00:00:00.095000

 G:\tmp\ibmmain\arrays>rexx squares.rxj
 100
 duration: 00:00:00.109000

So the interpreted ooRexx can even beat ... :)

---rony


On 11.01.2022 12:21, Rony G. Flatscher wrote:

On 11.01.2022 05:46, David Crayford wrote:

On 10/1/22 11:15 pm, Seymour J Metz wrote:

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient.

That seems to be begging the question. Certainly the current implementation is 
inefficient, but
what fundamental issue prevents a more efficient implementation?

A more effecient implementation requires a rewrite.


For that matter, what fundamental issue prevents compiling into Java bytecode 
with a large
runtime similar to the CREXX runtime?

None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
strongly typed and the
JVM is going to JIT compile it so it will be fast. As Rene mentioned you can 
use Java classes so
there is a massive eco-system available.

BTW, you could use Java classes from ooRexx as well, hence there is a "massive 
eco-system available"
for ooRexx. You would need the external function package named BSF4ooRexx, 
which enables ooRexx to
work with any Java class library, no matter whether it got created with Java, 
NetRexx, Kotlin,
Groovy, ...


I knocked up some simple benchtests which create an array of squares and then 
find the maximum
value. The maximum value is the end element. The results are just what I 
expected. ooRexx performs
poorly.

Not a surprise. :)

This "simple benchtest" is architected in a way that makes interpreted 
languages look especially bad
compared to compiled languages, it is of a form that is not relevant in real 
life. Also, using
unnecessarily numeric 30 digits for the arithmetics is interesting, as well as 
the outdated, seven
year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.



Stem variables are particularly bad which is to be expected because they are 
essentially
associative arrays. Using the Array class was much better but the result was 
still many orders of
magnitude worse then the
other languages I tested. What's interesting is that LuaJIT is as fast as C++ 
and interpreted Lua
is almost as fast as Julia which has JIT.

Not a surprise. :)

Now, if it was truly the case that someone would need such an abmysal amount of 
number crunching
then speed becomes interesting. In such a case what I would do for any 
interpreted language, I would
use a compiled one.

As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
interpreted languages
bite the dust. The question then would be whether to solve this particular 
problem in an interpreted
language at all.

In the case of REXX-savvy programmers I would suggest to use NetRexx for this 
particular purpose:

 /* NetRexx: squares.nrx  */
 options binary/* in this case we want speed */
 items = 1000
 s = long[items]   /* define a Java array of type long   */
 loop i=1 to items
n=long i   /* for multiplication we want to use long */
s[i-1] = n * n
 end
 /* use a Java stream (introduced with Java 8)  */
 say java.util.Arrays.stream(s).max.getAsLong

You 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

And here an example of ooRexx being used without any direct access to Java:

d1=.datetime~new  /* take time   */
"java squares"/* run command */
d2=.datetime~new  /* take time   */
say "duration:" d2-d1

The results of running this program are:

G:\tmp\ibmmain\arrays>squares_oorexx.rex
100
duration: 00:00:00.247000

G:\tmp\ibmmain\arrays>squares_oorexx.rex
100
duration: 00:00:00.242000

Quite fast! ;)

---rony

On 11.01.2022 13:15, Rony G. Flatscher wrote:
> Now, if you want ooRexx to control an application and need to run the NetRexx 
> program from it, you
> can do that with ooRexx (including timings) as such:
>
> /* ooRexx solution to control execution of NetRexx' squares  */
> clz=bsf.loadClass("squares")  /* load NetRexx' squares class */
>
> /* create an empty Java array of type java.lang.String   */
> arr=bsf.createJavaArrayOf("java.lang.String")
>
> d1=.dateTime~new  /* take time   */
> /* run main method which expects a Java String array */
> clz~main(arr)
> d2=.dateTime~new  /* take time   */
> say "duration:" d2-d1
>
> ::requires "BSF.CLS" /* get full access to Java  */
>
> The results of running this program are, believe it or not, even faster:
>
> G:\tmp\ibmmain\arrays>rexx squares.rxj
> 100
> duration: 00:00:00.095000
>
> G:\tmp\ibmmain\arrays>rexx squares.rxj
> 100
> duration: 00:00:00.109000
>
> So the interpreted ooRexx can even beat ... :)
>
> ---rony
>
>
> On 11.01.2022 12:21, Rony G. Flatscher wrote:
>> On 11.01.2022 05:46, David Crayford wrote:
>>> On 10/1/22 11:15 pm, Seymour J Metz wrote:
> ooRexx will never be high speed because it's implementation is
> fundamentally ineffecient.
 That seems to be begging the question. Certainly the current 
 implementation is inefficient, but
 what fundamental issue prevents a more efficient implementation?
>>> A more effecient implementation requires a rewrite.
>>>
 For that matter, what fundamental issue prevents compiling into Java 
 bytecode with a large
 runtime similar to the CREXX runtime?
>>> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
>>> strongly typed and the
>>> JVM is going to JIT compile it so it will be fast. As Rene mentioned you 
>>> can use Java classes so
>>> there is a massive eco-system available.
>> BTW, you could use Java classes from ooRexx as well, hence there is a 
>> "massive eco-system available"
>> for ooRexx. You would need the external function package named BSF4ooRexx, 
>> which enables ooRexx to
>> work with any Java class library, no matter whether it got created with 
>> Java, NetRexx, Kotlin,
>> Groovy, ...
>>
>>> I knocked up some simple benchtests which create an array of squares and 
>>> then find the maximum
>>> value. The maximum value is the end element. The results are just what I 
>>> expected. ooRexx performs
>>> poorly.
>> Not a surprise. :)
>>
>> This "simple benchtest" is architected in a way that makes interpreted 
>> languages look especially bad
>> compared to compiled languages, it is of a form that is not relevant in real 
>> life. Also, using
>> unnecessarily numeric 30 digits for the arithmetics is interesting, as well 
>> as the outdated, seven
>> year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.
>>
>>
>>> Stem variables are particularly bad which is to be expected because they 
>>> are essentially
>>> associative arrays. Using the Array class was much better but the result 
>>> was still many orders of
>>> magnitude worse then the
>>> other languages I tested. What's interesting is that LuaJIT is as fast as 
>>> C++ and interpreted Lua
>>> is almost as fast as Julia which has JIT.
>> Not a surprise. :)
>>
>> Now, if it was truly the case that someone would need such an abmysal amount 
>> of number crunching
>> then speed becomes interesting. In such a case what I would do for any 
>> interpreted language, I would
>> use a compiled one.
>>
>> As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
>> interpreted languages
>> bite the dust. The question then would be whether to solve this particular 
>> problem in an interpreted
>> language at all.
>>
>> In the case of REXX-savvy programmers I would suggest to use NetRexx for 
>> this particular purpose:
>>
>> /* NetRexx: squares.nrx  */
>> options binary/* in this case we want speed */
>> items = 1000
>> s = long[items]   /* define a Java array of type long   */
>> loop i=1 to items
>>n=long i   /* for multiplication we want to use long */
>>s[i-1] = n * n
>> end
>> /* use a Java stream (introduced with Java 8)*/
>> say java.util.Arrays.stream(s).max.getAsLong
>>
>> You would compile that NetRexx program with "netrexxc squares.nrx" and run 
>> 

Re: Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

Now, if you want ooRexx to control an application and need to run the NetRexx 
program from it, you
can do that with ooRexx (including timings) as such:

/* ooRexx solution to control execution of NetRexx' squares  */
clz=bsf.loadClass("squares")  /* load NetRexx' squares class */

/* create an empty Java array of type java.lang.String   */
arr=bsf.createJavaArrayOf("java.lang.String")

d1=.dateTime~new  /* take time   */
/* run main method which expects a Java String array */
clz~main(arr)
d2=.dateTime~new  /* take time   */
say "duration:" d2-d1

::requires "BSF.CLS" /* get full access to Java  */

The results of running this program are, believe it or not, even faster:

G:\tmp\ibmmain\arrays>rexx squares.rxj
100
duration: 00:00:00.095000

G:\tmp\ibmmain\arrays>rexx squares.rxj
100
duration: 00:00:00.109000

So the interpreted ooRexx can even beat ... :)

---rony


On 11.01.2022 12:21, Rony G. Flatscher wrote:
> On 11.01.2022 05:46, David Crayford wrote:
>> On 10/1/22 11:15 pm, Seymour J Metz wrote:
 ooRexx will never be high speed because it's implementation is
 fundamentally ineffecient.
>>> That seems to be begging the question. Certainly the current implementation 
>>> is inefficient, but
>>> what fundamental issue prevents a more efficient implementation?
>> A more effecient implementation requires a rewrite.
>>
>>> For that matter, what fundamental issue prevents compiling into Java 
>>> bytecode with a large
>>> runtime similar to the CREXX runtime?
>> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
>> strongly typed and the
>> JVM is going to JIT compile it so it will be fast. As Rene mentioned you can 
>> use Java classes so
>> there is a massive eco-system available.
> BTW, you could use Java classes from ooRexx as well, hence there is a 
> "massive eco-system available"
> for ooRexx. You would need the external function package named BSF4ooRexx, 
> which enables ooRexx to
> work with any Java class library, no matter whether it got created with Java, 
> NetRexx, Kotlin,
> Groovy, ...
>
>> I knocked up some simple benchtests which create an array of squares and 
>> then find the maximum
>> value. The maximum value is the end element. The results are just what I 
>> expected. ooRexx performs
>> poorly.
> Not a surprise. :)
>
> This "simple benchtest" is architected in a way that makes interpreted 
> languages look especially bad
> compared to compiled languages, it is of a form that is not relevant in real 
> life. Also, using
> unnecessarily numeric 30 digits for the arithmetics is interesting, as well 
> as the outdated, seven
> year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.
>
>
>> Stem variables are particularly bad which is to be expected because they are 
>> essentially
>> associative arrays. Using the Array class was much better but the result was 
>> still many orders of
>> magnitude worse then the
>> other languages I tested. What's interesting is that LuaJIT is as fast as 
>> C++ and interpreted Lua
>> is almost as fast as Julia which has JIT.
> Not a surprise. :)
>
> Now, if it was truly the case that someone would need such an abmysal amount 
> of number crunching
> then speed becomes interesting. In such a case what I would do for any 
> interpreted language, I would
> use a compiled one.
>
> As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
> interpreted languages
> bite the dust. The question then would be whether to solve this particular 
> problem in an interpreted
> language at all.
>
> In the case of REXX-savvy programmers I would suggest to use NetRexx for this 
> particular purpose:
>
> /* NetRexx: squares.nrx  */
> options binary/* in this case we want speed */
> items = 1000
> s = long[items]   /* define a Java array of type long   */
> loop i=1 to items
>n=long i   /* for multiplication we want to use long */
>s[i-1] = n * n
> end
> /* use a Java stream (introduced with Java 8) */
> say java.util.Arrays.stream(s).max.getAsLong
>
> You would compile that NetRexx program with "netrexxc squares.nrx" and run 
> the resulting Java class
> with "java squares".
>
> To give you a feeling for the speed (you can test it right on your own 
> computer and compare with
> your other versions), here the timings of your c++ program (compiled with MS 
> cl) and this NetRexx
> program on my Windows 10 laptop (all in 32-bit mode):
>
>   * c++ (using MS compiler) out of the box:
> G:\tmp\ibmmain\arrays>timeit squares.exe
> *** ooRexx-Timeit:  command: squares.exe
>
> 100
> *** ended.
>
> *** command:  squares.exe
> *** started:  2022-01-11T11:19:55.506000
> *** ended:    2022-01-11T11:19:56.493000
>  duration: 00:00:00.987000*
>
>   

Speedy, speedier, speedest (Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 11.01.2022 05:46, David Crayford wrote:
> On 10/1/22 11:15 pm, Seymour J Metz wrote:
>>> ooRexx will never be high speed because it's implementation is
>>> fundamentally ineffecient.
>> That seems to be begging the question. Certainly the current implementation 
>> is inefficient, but
>> what fundamental issue prevents a more efficient implementation?
>
> A more effecient implementation requires a rewrite.
>
>> For that matter, what fundamental issue prevents compiling into Java 
>> bytecode with a large
>> runtime similar to the CREXX runtime?
>
> None. TBH, I hadn't had much of a look at NetRexx but it's promising. It's 
> strongly typed and the
> JVM is going to JIT compile it so it will be fast. As Rene mentioned you can 
> use Java classes so
> there is a massive eco-system available.

BTW, you could use Java classes from ooRexx as well, hence there is a "massive 
eco-system available"
for ooRexx. You would need the external function package named BSF4ooRexx, 
which enables ooRexx to
work with any Java class library, no matter whether it got created with Java, 
NetRexx, Kotlin,
Groovy, ...

> I knocked up some simple benchtests which create an array of squares and then 
> find the maximum
> value. The maximum value is the end element. The results are just what I 
> expected. ooRexx performs
> poorly.

Not a surprise. :)

This "simple benchtest" is architected in a way that makes interpreted 
languages look especially bad
compared to compiled languages, it is of a form that is not relevant in real 
life. Also, using
unnecessarily numeric 30 digits for the arithmetics is interesting, as well as 
the outdated, seven
year old ooRexx 4.2 rather than ooRexx 5.0 does not help either.


> Stem variables are particularly bad which is to be expected because they are 
> essentially
> associative arrays. Using the Array class was much better but the result was 
> still many orders of
> magnitude worse then the
> other languages I tested. What's interesting is that LuaJIT is as fast as C++ 
> and interpreted Lua
> is almost as fast as Julia which has JIT.

Not a surprise. :)

Now, if it was truly the case that someone would need such an abmysal amount of 
number crunching
then speed becomes interesting. In such a case what I would do for any 
interpreted language, I would
use a compiled one.

As you point out the compiled versions (cpp, JIT-etc. compiled one) let the 
interpreted languages
bite the dust. The question then would be whether to solve this particular 
problem in an interpreted
language at all.

In the case of REXX-savvy programmers I would suggest to use NetRexx for this 
particular purpose:

/* NetRexx: squares.nrx  */
options binary/* in this case we want speed */
items = 1000
s = long[items]   /* define a Java array of type long   */
loop i=1 to items
   n=long i   /* for multiplication we want to use long */
   s[i-1] = n * n
end
/* use a Java stream (introduced with Java 8)   */
say java.util.Arrays.stream(s).max.getAsLong

You would compile that NetRexx program with "netrexxc squares.nrx" and run the 
resulting Java class
with "java squares".

To give you a feeling for the speed (you can test it right on your own computer 
and compare with
your other versions), here the timings of your c++ program (compiled with MS 
cl) and this NetRexx
program on my Windows 10 laptop (all in 32-bit mode):

  * c++ (using MS compiler) out of the box:
G:\tmp\ibmmain\arrays>timeit squares.exe
*** ooRexx-Timeit:  command: squares.exe

100
*** ended.

*** command:  squares.exe
*** started:  2022-01-11T11:19:55.506000
*** ended:    2022-01-11T11:19:56.493000
 duration: 00:00:00.987000*

  * NetRexx (Java 17) out of the box:

G:\tmp\ibmmain\arrays>timeit java squares
*** ooRexx-Timeit:  command: java squares

100
*** ended.

*** command:  java squares
*** started:  2022-01-11T12:09:51.849000
*** ended:    2022-01-11T12:09:52.134000
 duration: 00:00:00.285000*

As C++ on your machine was fastest of all compiled solutions, this may be quite 
surprising: NetRexx
can beat even C++! :)

Again: pick the language that meets the job at hand at best! Doing abmysal 
loopings, arrays, etc.
pick a compiled language, solving "bread-and-butter" problems use the language 
that allows you to
quickly create the program solution in a readable, maintable manner.

REXX programmers have good reasons why they use an interpreter for their 
problem solutions for
decades on mainframes.

And as can be seen, even such artificial samples constructed to make 
interpreters look bad, it is
not difficult for programmers with REXX knowledge to use NetRexx to solve 
problems that really would
need "hi speed".

Or with other words: whenever REXX programmers need functionality and speed on 
a mainframe they
resort to external native programs that they instrumentate. The same is 
possible with 

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 10/1/22 11:28 pm, René Jansen wrote:

I find that a very interesting question - I think there is no real reason, and 
that is one of the things CREXX is trying to prove.


I've already said enough in this thread. CREXX looks interesting and 
fun. I'm happy to contribute.




For the other things, other mailing lists. But we have to remember that ooRexx 
is doing a lot of work like keeping activation records and doing garbage 
collection, which used to be essential but we decided are not really a priority 
now due to large addressing spaces (would take a century and a non-existing 
machine to page everything in though) and we know a lot more about optimization 
(inlining, avoiding pipeline stalls, keeping routines in cache) that are only 
valid for modern ISA implementations.

It turned out that you need to profile the heck out of everything before you 
commit it. We could not do that for ooRexx yet - that is a manpower issue (man 
includes man and women (I wish) here). I do wish that all the knowledge on this 
list could be transformed into one or two people more to work on things - it is 
clearly not IBM or companies that bought pieces of its history that we can 
count on here.

Best regards,

René.


On 10 Jan 2022, at 11:15, Rony  wrote:


Am 10.01.2022 um 15:34 schrieb David Crayford :

On 10/1/22 10:10 pm, Rony G. Flatscher wrote:

On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.

What do you mean by "the message paradigm"? How does it differ from sending 
method invocation
and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.

If it's not necessary then why did you make such a big deal about it?

Well if you have really read the entire post you should know. Without 
implementing the message
paradigm things become clumsy and some important features, if you need them, 
are simply not available.



I'm still completely baffled by the why not implementing the "message paradigm" is 
clumsy. Returning "self" from a method makes sense to me. What if I'm creating a class 
which supports method chaining
but some methods return values other than self. Nothing you are saying makes 
sense to me. It's dogma.

No, there is no dogma here, just a description that a mechanism is available in 
ooRexx by default that needs explicit programming in other languages which wish 
to be as fluent as ooRexx! ;)

Just try it out. Many times new concepts that look alien at first or even 
unnecessary become more understandable by experimenting itj. Given your 
background I am sure that you would grasp these concepts quite quickly. J

—-rony

Rony G. Flatscher (mobil/e)
--
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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 10/1/22 11:15 pm, Seymour J Metz wrote:

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient.

That seems to be begging the question. Certainly the current implementation is 
inefficient, but what fundamental issue prevents a more efficient 
implementation?


A more effecient implementation requires a rewrite.


For that matter, what fundamental issue prevents compiling into Java bytecode 
with a large runtime similar to the CREXX runtime?


None. TBH, I hadn't had much of a look at NetRexx but it's promising. 
It's strongly typed and the JVM is going to JIT compile it so it will be 
fast. As Rene mentioned you can use Java classes so there is a massive 
eco-system available.



I knocked up some simple benchtests which create an array of squares and 
then find the maximum value. The maximum value is the end element. The 
results are just what I expected. ooRexx performs poorly.
Stem variables are particularly bad which is to be expected because they 
are essentially associative arrays. Using the Array class was much 
better but the result was still many orders of magnitude worse then the
other languages I tested. What's interesting is that LuaJIT is as fast 
as C++ and interpreted Lua is almost as fast as Julia which has JIT.


❯ rexx -v
Open Object Rexx Version 4.2.0
Build date: Dec 29 2013
Addressing Mode: 64
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2013.
All Rights Reserved.
This program and the accompanying materials are made available under
the terms of the Common Public License v1.0 which accompanies this
distribution or at
http://www.oorexx.org/license.html

❯ cat squares.rexx
/* REXX */
numeric digits 30
MAX = 1000
s. = 0
do n = 1 to MAX
  s.n = n * n
end
m = 0
do i = 1 to MAX
  m = max(m, s.i)
end
say max

❯ time rexx squares.rexx
1000rexx squares.rexx  43.04s user 3.25s system 99% cpu 46.296 total

❯ cat squares2.rexx
numeric digits 30
s = .Array~new()
do n = 1 to 1000
  s~append(n * n)
end
m = 0
do n = 1 to s~items
  m = max(m, s[n])
end
say m

❯ time rexx squares2.rexx
100
rexx squares2.rexx  17.25s user 1.32s system 99% cpu 18.568 total

❯ lua -v
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio

local s = {}
for n = 1, 1000 do
   s[n] = n * n
end
local max = 0
for _, n in ipairs(s) do
  max = math.max(max, n)
end
print(max)

❯ time lua squares.lua
100
lua squares.lua  0.79s user 0.07s system 99% cpu 0.862 total

❯ luajit -v
LuaJIT 2.1.0-beta3 -- Copyright (C) 2005-2017 Mike Pall. http://luajit.org/

❯ time luajit squares.lua
1e+14
luajit squares.lua  0.08s user 0.05s system 99% cpu 0.137 total

❯ python3 --version
Python 3.8.10

❯ cat squares.py
s = []
for n in range(1, 1000+1):
    s.append(n * n)
print(max(s))

❯ time python3 squares.py
100
python3 squares.py  1.13s user 0.16s system 99% cpu 1.288 total

❯ julia --version
julia version 1.4.1

❯ cat squares.jl
s = Int[]
for n = 1:1000
  push!(s, n * n)
end
println(maximum(s))

❯ time julia squares.jl
100
julia squares.jl  0.56s user 0.74s system 214% cpu 0.608 total

❯ clang++ --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

❯ cat squares.cpp
#include 
#include 
#include 
#include 
int main() {
    constexpr int MAX = 1000;
    std::vector s(MAX);
    for (uint64_t n = 1; n <= MAX; n++) s.push_back(n * n);
    std::cout << *std::max_element(s.begin(), s.end()) << "\n";

❯ time ./squares
100
./squares  0.05s user 0.05s system 99% cpu 0.107 total





--
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: Monday, January 10, 2022 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.

What do you mean by "the message paradigm"? How does it differ from sending 
method invocation and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.

If it's not necessary then why did you make such a big deal about it?


As you can see, if there should be need for adding external functions and/or 
methods to ooRexx, this
can be done with the powerful and easy to use C++ API of ooRexx. As a matter of 
fact 

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

Please be careful with attributions; "fundamentally ineffecient" was David, not 
me. I was questioning his claim.

OOREXX does seem to be less efficient than SAA ("classic") REXX, but I use it 
regardless because of its expressive power. I know of no barrier to a more 
efficient design, nor do I know of any fundamental difference between NetRexx 
and oorexx that would prevent one from being efficient but not the other.

Not oorexx, but IBM has used REXX as the implementation language for, e.g., 
some CMS commands. I don't recall those commands being too slow.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rony [rony.flatsc...@wu.ac.at]
Sent: Monday, January 10, 2022 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Am 10.01.2022 um 16:16 schrieb Seymour J Metz :
>
> 
>>
>> ooRexx will never be high speed because it's implementation is
>> fundamentally ineffecient.
No, for what ooRexx does and allows for it is not „fundamentally inefficient“. 
If forgoing all its helpful new features, because all of a sudden „inheritance“ 
or „message paradigm“ is not important, then you could implement it totally 
different. But then you loose what makes it so powerful and easy to use.

Just think about REXX and for what purposes you use it there. If „hi speed“ 
gets important then you probably use native code/functions/libraries from REXX.

I know of companies that use ooRexx with BSF4ooRexx for nifty professional 
applications, where they use powerful JavaFX for the GUI, but interact with 
RDBMS on IBM middle range hardware. They develop on the MacOS platform, but can 
deploy their products on Windows and Linux. Complex, challenging applications 
that get created and maintained with ooRexx+BSF4ooRexx.

The reason? They had REXX knowledge (coming from the mainframe world, also 
consulting AS/400 customrs etc.), learned about ooRexx and BSF4ooRexx and were 
able (on their own!) to learn and research all they needed for a solution that 
others would have thought was impossible with REXX knowledge. Rather they would 
speculate/expect to have to learn a new language from scratch. This is not the 
case, one can keep and take advantage of the REXX knowledge and year long 
experiences.

—-rony

Rony G. Flatscher (mobil/e)

--
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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony]

Am 10.01.2022 um 16:16 schrieb Seymour J Metz :
> 
> 
>> 
>> ooRexx will never be high speed because it's implementation is
>> fundamentally ineffecient.
No, for what ooRexx does and allows for it is not „fundamentally inefficient“. 
If forgoing all its helpful new features, because all of a sudden „inheritance“ 
or „message paradigm“ is not important, then you could implement it totally 
different. But then you loose what makes it so powerful and easy to use.

Just think about REXX and for what purposes you use it there. If „hi speed“ 
gets important then you probably use native code/functions/libraries from REXX.

I know of companies that use ooRexx with BSF4ooRexx for nifty professional 
applications, where they use powerful JavaFX for the GUI, but interact with 
RDBMS on IBM middle range hardware. They develop on the MacOS platform, but can 
deploy their products on Windows and Linux. Complex, challenging applications 
that get created and maintained with ooRexx+BSF4ooRexx. 

The reason? They had REXX knowledge (coming from the mainframe world, also 
consulting AS/400 customrs etc.), learned about ooRexx and BSF4ooRexx and were 
able (on their own!) to learn and research all they needed for a solution that 
others would have thought was impossible with REXX knowledge. Rather they would 
speculate/expect to have to learn a new language from scratch. This is not the 
case, one can keep and take advantage of the REXX knowledge and year long 
experiences.

—-rony

Rony G. Flatscher (mobil/e)

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

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

I find that a very interesting question - I think there is no real reason, and 
that is one of the things CREXX is trying to prove. For the other things, other 
mailing lists. But we have to remember that ooRexx is doing a lot of work like 
keeping activation records and doing garbage collection, which used to be 
essential but we decided are not really a priority now due to large addressing 
spaces (would take a century and a non-existing machine to page everything in 
though) and we know a lot more about optimization (inlining, avoiding pipeline 
stalls, keeping routines in cache) that are only valid for modern ISA 
implementations.

It turned out that you need to profile the heck out of everything before you 
commit it. We could not do that for ooRexx yet - that is a manpower issue (man 
includes man and women (I wish) here). I do wish that all the knowledge on this 
list could be transformed into one or two people more to work on things - it is 
clearly not IBM or companies that bought pieces of its history that we can 
count on here.

Best regards,

René.

> On 10 Jan 2022, at 11:15, Rony  wrote:
> 
>> 
>> Am 10.01.2022 um 15:34 schrieb David Crayford :
>> 
>> On 10/1/22 10:10 pm, Rony G. Flatscher wrote:
 On 10/1/22 8:34 pm, Rony G. Flatscher wrote:
>> On 09.01.2022 16:29, Seymour J Metz wrote:
 Well all of your languages miss the support for the message paradigm.
>>> What do you mean by "the message paradigm"? How does it differ from 
>>> sending method invocation
>>> and response messages to objects?
>> The message paradigm as set forth by Smalltalk explicitly defines a 
>> class for messages, allows for
>> intercepting messages, rerouting messages at the will of the programmer 
>> and much more, as messages
>> themselves become objects that the programmer can interact with, if 
>> needed.
>> 
>> ooRexx implements the message paradigm in full, something that is easily 
>> overlooked as usually it is
>> not necessary to be aware of it.
 If it's not necessary then why did you make such a big deal about it?
>>> Well if you have really read the entire post you should know. Without 
>>> implementing the message
>>> paradigm things become clumsy and some important features, if you need 
>>> them, are simply not available.
>>> 
>>> 
>> I'm still completely baffled by the why not implementing the "message 
>> paradigm" is clumsy. Returning "self" from a method makes sense to me. What 
>> if I'm creating a class which supports method chaining
>> but some methods return values other than self. Nothing you are saying makes 
>> sense to me. It's dogma.
> 
> No, there is no dogma here, just a description that a mechanism is available 
> in ooRexx by default that needs explicit programming in other languages which 
> wish to be as fluent as ooRexx! ;)
> 
> Just try it out. Many times new concepts that look alien at first or even 
> unnecessary become more understandable by experimenting itj. Given your 
> background I am sure that you would grasp these concepts quite quickly. J
> 
> —-rony
> 
> Rony G. Flatscher (mobil/e)
> --
> 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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> ooRexx will never be high speed because it's implementation is
> fundamentally ineffecient.

That seems to be begging the question. Certainly the current implementation is 
inefficient, but what fundamental issue prevents a more efficient 
implementation? For that matter, what fundamental issue prevents compiling into 
Java bytecode with a large runtime similar to the CREXX runtime?


--
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: Monday, January 10, 2022 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features 
(Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 8:34 pm, Rony G. Flatscher wrote:
> On 09.01.2022 16:29, Seymour J Metz wrote:
>>> Well all of your languages miss the support for the message paradigm.
>> What do you mean by "the message paradigm"? How does it differ from sending 
>> method invocation and response messages to objects?
> The message paradigm as set forth by Smalltalk explicitly defines a class for 
> messages, allows for
> intercepting messages, rerouting messages at the will of the programmer and 
> much more, as messages
> themselves become objects that the programmer can interact with, if needed.
>
> ooRexx implements the message paradigm in full, something that is easily 
> overlooked as usually it is
> not necessary to be aware of it.

If it's not necessary then why did you make such a big deal about it?

> As you can see, if there should be need for adding external functions and/or 
> methods to ooRexx, this
> can be done with the powerful and easy to use C++ API of ooRexx. As a matter 
> of fact BSF4ooRexx and
> dbusoorexx are using those native C++ APIs allowing high speed and using all 
> that is available in
> and via the C++ world.

ooRexx will never be high speed because it's implementation is
fundamentally ineffecient. Most scripting languages compile to bytecode
which is then processed by a VM. For example, the Lua VM is less tha 2K
lines of code and can fit into L2 cache which is why it's blistering
fast 
https://secure-web.cisco.com/1toUKHC4qJ1L65nxMUHlKxOYU0nCw63de1WYnrGbKff1yrwqYGas-OyWjVfJCDmHbQ8-AEVUh6XufmmTHQpXuiui1Oz3dT6hK9s0lRpekgPRdl4akdM0MwK100qVFGPYGqGt81W8-MPFrje4gSpXNazzn4fMSiHGgSWDamtQAH5tueZ_8T8aa5iE1pL9UvLLcIjjfsFGUK-P4tUucjxCM8HO0LyO8nmOWh_0CeNAdWcuWTrN5Em2BLnvFL5WapeGIHJvU2D9PJmk3_BsvxgPJfOMtt2RV2r4gqg7t_Xgjannaba2uFqkrW9h4s00If0apuc23VCaI-qz9jjywnRdKULdBrJcCqDYBtHL27rlQwQ3tbdu4b4XEqaAk6QlYej9JA7eII2tBWpYbOg_-qjjJhbabjho8C4tTZgJ8jb5GWs9S2bP9ztKJFOjoVG-toKSS/https%3A%2F%2Fwww.lua.org%2Fsource%2F5.1%2Flvm.c.html.
 ooRexx chose to use a
graph of C++ classes with abstract base classes for every instruction
and clause. OMG, dynamic dispatch for every instruction!

https://secure-web.cisco.com/1x1EEYRKnnOq4ErWK3XEX2TNTsQD0UuiUNjaIlV74LtBLh321aBDX8DuBmGkeEwlVa2nEDe_0WiZceoWQpQpAlJAptvu2Pgsg3VfvzAc19VMyrkgP6hFgWGpmex9xKNvxIu8OjmtH2TCcgPcTS0QhVf7T-8hfM-Ajwx_i-XiuIwhPspCAux-kzFz7ipM7H6Q8Fr-i2xzGtLJC4YOPthkFUUz7q-t-QNpKAT7Ueqfl3gLB-TNHYgYvg5Mo36B2KhDB4Q36sHe5f2XVg3KnPmIRV3q_AxuZAhQYGyJozZbO9cMrzV6UaF942P531jtLuMYxf1UtWbXlw89wSf8QVdMN5E6F0p9eylZcPucm5blJUIF9Ws0BIe4nj4OSooCHL1QoVyAw2_-Hw9nsWU6t-c0mjjDw4ou64vahrdNYommLhznZK49gubwnaoT9tKaLVwbc/https%3A%2F%2Fgithub.com%2FooRexx%2FooRexx%2Ftree%2Fmaster%2Finterpreter%2Finstructions

It's gigantic clump of inefficient code based upon inheritance. The GoF
Design Patterns book which dates back to the 90s was a groundbreaking,
seminal work which had a central theme of introducing patterns to avoid
inheritance. Modern languages like Rust don't even support Inheritance.

If you want high speed then use a JIT compiler. The Lua Functional
library used with LuaJIT can boil a chain of method calls down to a
dozen instructions with no linkage overhead
https://secure-web.cisco.com/1VGsux3zwLoFPlfRJthZWOyRRuMwoUesawXiAoOEGNBSpwc8MJTo_mTKwvCEMkjgvHvlY-YaKdYzPaVz1dG1h6YFTiRsgrq0TwNPjdMt2oUIMlwjqLKvM7q_jCe7R8HwQLHyRZ2uQZS6Vt4fHDBgmNbTBc_0cjIKlJ7JyekEm2GEDauJ5o8jonSS747C4tVgfM6MLLcz6ctR9YUeUKvqE0r45xSXwYFz0tC4jg3dus4FrE9VmJPakzfNzH-Uzr0mJJwtpBqkiF6E4WvuMsxJwF6pKRHyrJvM9f4iGcBHa9-m5OcGOaaLxIc_johKMK7lU4fpLGKg5Q9bVczgMOrGrRAFOGkfVJJ8dc_UPTacOUKlWFmWnLWPrssX62RX0gtKqr0RyYegQ_TD8Irzb9oX_9SE4ZY8b1vdh5HnsxNpeTEsECVs9J7PBcRh9l_YcuM5XllzvcAi9NeVF_L_pRcEaWg/https%3A%2F%2Fluafun.github.io%2Fintro.html.
 The Julia programming language can
do the same with similar syntax. If I wanted to use REXX
I would use NetRexx to take advantage of the JVM JIT.


>
> Again it is fairly straight-forward and easy to add external routines and 
> external methods to ooRexx
> if need be.
>
> ---rony
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: 

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony]

> 
> Am 10.01.2022 um 15:34 schrieb David Crayford :
> 
> On 10/1/22 10:10 pm, Rony G. Flatscher wrote:
>>> On 10/1/22 8:34 pm, Rony G. Flatscher wrote:
> On 09.01.2022 16:29, Seymour J Metz wrote:
>>> Well all of your languages miss the support for the message paradigm.
>> What do you mean by "the message paradigm"? How does it differ from 
>> sending method invocation
>> and response messages to objects?
> The message paradigm as set forth by Smalltalk explicitly defines a class 
> for messages, allows for
> intercepting messages, rerouting messages at the will of the programmer 
> and much more, as messages
> themselves become objects that the programmer can interact with, if 
> needed.
> 
> ooRexx implements the message paradigm in full, something that is easily 
> overlooked as usually it is
> not necessary to be aware of it.
>>> If it's not necessary then why did you make such a big deal about it?
>> Well if you have really read the entire post you should know. Without 
>> implementing the message
>> paradigm things become clumsy and some important features, if you need them, 
>> are simply not available.
>> 
>> 
> I'm still completely baffled by the why not implementing the "message 
> paradigm" is clumsy. Returning "self" from a method makes sense to me. What 
> if I'm creating a class which supports method chaining
> but some methods return values other than self. Nothing you are saying makes 
> sense to me. It's dogma.

No, there is no dogma here, just a description that a mechanism is available in 
ooRexx by default that needs explicit programming in other languages which wish 
to be as fluent as ooRexx! ;)

Just try it out. Many times new concepts that look alien at first or even 
unnecessary become more understandable by experimenting itj. Given your 
background I am sure that you would grasp these concepts quite quickly. J

—-rony

Rony G. Flatscher (mobil/e)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony]

> 
> Am 10.01.2022 um 15:22 schrieb Seymour J Metz :
> 
> 
>> 
>> As a little teaser, if interested, just look-up the ooRexx runtime objects
>> named .input, .output and .error.
> 
> Aren't those just monitor objects?
Yes. They monitor stdin, stdout and stderr (all three are streams that could 
also be redirected from to the Rexx program). ooRexx will use the monitors 
itself rather than directly interacting with the stream objects. 

So say statements will cause the string to be sent to .output which then will 
forward the message with string argument (if any) to .stdout.

If using lineout or charout to write an error message to „stderr“ the message 
gets sent to .error which forwards the message to its monitored .stderr stream.

If one knows that it is easy to e.g. create error logfiles on a daily basis if 
running a 7/24 ooRexx program: you merely replace the destination of the .error 
monitor to a logger object you create which would create a file like 
„error-20220110.log“ and forward each received say/lineout/charout message to 
that file object (which is an instance of the ooRexx class .stream). Then if 
midnight is up, the logger object closes that log file and creates a new one 
like „error-20220111.log“ to which messages get forwarded.

This way all error messages get logged and can be inspected. The nice thing 
about this is that no REXX program needs to know or realize that!

—-

Another application possibility is employed by BSF4ooRexx: this external 
function package makes it easy to host REXX and ooRexx scripts that get 
executed with ooRexx (and it is even possible to supply Java objects the 
REXX/ooRexx scripts wish to interact with). 

Usually this is done by Java/NetRexx/Kotlin/Grooivy/… with the help of the Java 
scfripting framework which supplies Java objects representing stdin, stdout and 
stderr.

Exploiting the ooRexx monitor objects .input, .output and .error BSF4ooRexx 
transparently replaces the destination objects of these monitors, intercepting 
all messages and forwarding them to the appropriate Java objects.

And the best: the REXX/ooRexx programs do not even need to know that, which 
alleviates the programmers. So they even do not need to know how this „magic“ 
gets realized under the hood. 

Sheer power! Easy to use as no one needs to code an extra line of code for that 
(important) purpose. :)

Again, this is only possible in such an easy (in this case even totally 
transparent) manner, because ooRexx implements and uses the message paradigm. 

And BTW BSF4ooRexx does one more thing: by default it prefixes the streams e.g. 
with „REXXout>“, „REXXerr>“ such that all REXX/ooRexx related interactions with 
the streams can be quickly identified in Java log files which is extremely 
helpful for locating them (if Java logging is enabled long running programs can 
create huge log files).

—-rony

Rony G. Flatscher (mobil/e)


> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Rony G. Flatscher [rony.flatsc...@wu.ac.at]
> Sent: Monday, January 10, 2022 7:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming 
> features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
> 
>> On 10.01.2022 05:28, David Crayford wrote:
>>> On 9/1/22 11:22 pm, Rony G. Flatscher wrote:
>>> On 09.01.2022 03:19, David Crayford wrote:
 On 9/1/22 2:15 am, Rony G. Flatscher wrote:
> On 08.01.2022 01:52, David Crayford wrote:
>> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:
> 
> ... cut ...
> 
 Number 7 on my list is support for OO which implies message passing.
>>> Well, this does not mean that the programming language supports the message 
>>> paradigm. If it did it
>>> would have an explicit "Message" class (like there are explicit classes 
>>> like "Object", "Class",
>>> "Method" and the like), hence messages are not FCOs. Compare this to 
>>> languages like SmallTalk or
>>> ooRexx.
>>> 
>>> Maybe it is easier to grasp some of the ramifications by looking at the 
>>> popular fluent pattern
>>> (https://secure-web.cisco.com/16gHuUSvm6wTt36qDHrbk52jx7cBfrMxkFy9KdL4OA5teVngp8Mpxa3-ScxQQj6e8NG8rc5Poicg4agf5YtCC7n9giLhoKsCYDHGyaSIplNNZYJpoOiaHTibhkaNKJDd5kMrMIsI7iMuEcfUcSxBtXuq80eRv-jsiH3bt0FEkf2whHXX3X9KAku-TVgGXniJyaOhg4rTanyB_YmPOXyiZKSyA0kL3i8i8SnOVK3RaQ0jMgetCj6diuu61cSmSouZ3VeteLv7HyTfu8lDFu0g2esJUbMSz_nitJ1YkcB_d9OyZvpJb9WB0O6E9S8kPfLuixlWnfmgLwpxGWgYK0xZZcsF18e3TiQuoePIwYl2HE7LOHxHE6lHW7jaAEwPD5ehgtPaIjK7Wqqqbp-m7skw8ruTvJkYUOXXAc5U7m6oGqnt_ugEow8VOV6C1QQlhfDME/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFluent_interface)
>>>  which needs to be explicitly programmed in
>>> languages that do not support the message paradigm, but is "freely" ;) 
>>> available in languages like
>>> Smalltalk and ooRexx.
>> 
>> I'm familiar with fluent APIs. I've been coding C++ and Java for over 25 
>> years. They don't need an
>> explict "Message", "Object" 

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

That page has other issues. The “IBM Open XL Fortran for AIX” and the “IBM XL 
Fortran for AIX” refer to the same page. The "IBM XL Fortran for Linux” link 
omits to mention that is it also Open, but only for Power systems; it doesn’t 
mention the repo from which the community edition is to be gotten to check if 
it works on X86_64 or aarch64 - when it is on LLVM that should be the case. Oh 
my.

> On 10 Jan 2022, at 10:53, Seymour J Metz  wrote:
> 
>> AFAIK, there is no officially supported Fortran (or Ada) compiler for z/OS
> 
> "mainframe ¬= 'z/OS"
> 
>> we had to port a Fortran to C transpiler.
> 
> ?
> 
> 

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

When I follow that link - very s l o w it is I might add - I see: 

IBM® VS FORTRAN compiles FORTRAN code to generate efficient applications for 
the IBM z/OS® and IBM z/VM® platforms. It includes a compiler, a library and 
interactive debugging facilities.  

Is it not supported? That might be odd.
Also, the linking page commits the error of telling us

IBM VS FORTRAN: Develop efficient applications for IBM Z® and z/VM® with IBM VS 
FORTRAN.
Which jumbles the categories a little and makes me afraid to push that “talk to 
an expert” button.

René.

> On 10 Jan 2022, at 10:53, Seymour J Metz  wrote:
> 
>> AFAIK, there is no officially supported Fortran (or Ada) compiler for z/OS
> 
> "mainframe ¬= 'z/OS"
> 
>> we had to port a Fortran to C transpiler.
> 
> ?
> 
> 
> --
> 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: Monday, January 10, 2022 7:08 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
> 
> On 10/1/22 6:13 am, Seymour J Metz wrote:
>>> he raison d'être of the mainframe is to run applications written in COBOL.
>> What is FORTRAN, chopped liver?
> 
> AFAIK, there is no officially supported Fortran (or Ada) compiler for
> z/OS. When Rocket ported the R programming language to z/OS we had to
> port a Fortran to C transpiler. Bringing back Fortran is another sweet
> spot that a z/OS LLVM port will solve.
> 
> 
>> 
>> 
>> --
>> 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: Friday, January 7, 2022 11:16 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
>> 
>> On 8/1/22 1:42 am, Tony Harminc wrote:
>>> On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:
>>> 
 I've been following this thread and one thing that has yet to appear, or I 
 missed it, has to do with 4GL's and the drive, at one point, for languages 
 that were more human oriented - those that could be written more like a 
 normal sentence or phrase, and avoid the technical 
 jargon/gobblygook/syntax. As I recall in the 1980's there were a few but 
 nothing came of them, instead we have languages that have their own 
 syntax, and which require extensive learning but nothing that allows a 
 non-programmer to actually generate a complex business program.
>>> COBOL was supposed to be that, no? Managers could in theory at least
>>> read (if not write) a COBOL program and understand what it does,
>>> because it so (superficially) resembles English.
>> It's interesting that no language since COBOL has ever tried to emulate
>> the "english" syntax. It turns out that it was not actually a terribly
>> good idea. Programmers preferred languages with more concise syntax.
>> 
>> BTW, I'm not knocking COBOL. I'm a mainframe guy and I'm cognizant to
>> the fact that the raison d'être of the mainframe is to run applications
>> written in COBOL. PL/I programmers will disagree but COBOL is king.
>> 
>> 
  From my experience, REXX has many of the 4GL goals as the syntax isn't 
 overly complex and is something a non-programmer can comprehend rather 
 easily. As has been previously mentioned in this thread, REXX can be more 
 readily learned and used than the majority of the current languages. It 
 isn't perfect but it works very well.
>>> Indeed.
>> --
>> 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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> AFAIK, there is no officially supported Fortran (or Ada) compiler for z/OS

"mainframe ¬= 'z/OS"

> we had to port a Fortran to C transpiler.

 ?


--
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: Monday, January 10, 2022 7:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10/1/22 6:13 am, Seymour J Metz wrote:
>> he raison d'être of the mainframe is to run applications written in COBOL.
> What is FORTRAN, chopped liver?

AFAIK, there is no officially supported Fortran (or Ada) compiler for
z/OS. When Rocket ported the R programming language to z/OS we had to
port a Fortran to C transpiler. Bringing back Fortran is another sweet
spot that a z/OS LLVM port will solve.


>
>
> --
> 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: Friday, January 7, 2022 11:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
>
> On 8/1/22 1:42 am, Tony Harminc wrote:
>> On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:
>>
>>> I've been following this thread and one thing that has yet to appear, or I 
>>> missed it, has to do with 4GL's and the drive, at one point, for languages 
>>> that were more human oriented - those that could be written more like a 
>>> normal sentence or phrase, and avoid the technical 
>>> jargon/gobblygook/syntax. As I recall in the 1980's there were a few but 
>>> nothing came of them, instead we have languages that have their own syntax, 
>>> and which require extensive learning but nothing that allows a 
>>> non-programmer to actually generate a complex business program.
>> COBOL was supposed to be that, no? Managers could in theory at least
>> read (if not write) a COBOL program and understand what it does,
>> because it so (superficially) resembles English.
> It's interesting that no language since COBOL has ever tried to emulate
> the "english" syntax. It turns out that it was not actually a terribly
> good idea. Programmers preferred languages with more concise syntax.
>
> BTW, I'm not knocking COBOL. I'm a mainframe guy and I'm cognizant to
> the fact that the raison d'être of the mainframe is to run applications
> written in COBOL. PL/I programmers will disagree but COBOL is king.
>
>
>>>   From my experience, REXX has many of the 4GL goals as the syntax isn't 
>>> overly complex and is something a non-programmer can comprehend rather 
>>> easily. As has been previously mentioned in this thread, REXX can be more 
>>> readily learned and used than the majority of the current languages. It 
>>> isn't perfect but it works very well.
>> Indeed.
> --
> 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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> One important thing though: if you have no need for these features do not use 
> them! :)

Why? I find chained messages more readable than nested function calls. 
Similarly, I find "foo[expresion]" more readable than "bar=expression;foo.bar".


--
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: Monday, January 10, 2022 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: 
... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 09.01.2022 16:29, Seymour J Metz wrote:
>> Well all of your languages miss the support for the message paradigm.
> What do you mean by "the message paradigm"? How does it differ from sending 
> method invocation and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.

A REXX programmer may stick to REXX programs and still is able to use ooRexx to 
run them as ooRexx
is a snap-in replacement which supports all of REXX and adds additional 
features. For anyone who is
not acquainted to REXX or ooRexx the little ten page 
paper
 gives an
introduction and explains the most important concepts. There is no need for 
more pages to make the
language understandable and applicable for those who already know how to 
program (including
Assembler, VB/VBA/VBA.Net, Python etc. programmers).

In ooRexx messages in code can be identified by locating the message operator 
(tilde: ~). Classic
REXX BIFs (built-in functions) like c2x(), reverse(), substr() etc. are 
available in ooRexx, but
"behind the curtain" the implementation of each string BIF is organized in the 
"String"
class/structure/type where the implementation resides in form of method 
routines that are named
"c2x", "reverse", "substr" and the like. Usually this is not important to know 
if using REXX
concepts only. In the context of this discussion however it allows for 
understanding how ooRexx
works "behind the curtain": everything in ooRexx (like in Smalltalk) is an 
object (synonyms: value,
instance).

Conceptually a programmer communicates with objects by sending them messages as 
if objects were
living things. The object receives the message and will start out to look for a 
method it possesses
that carries the same name as the received message. Once the method is located, 
the object invokes
it, supplying any arguments that may have been given with the message. If the 
method returns a value
(object, instance), the object will return it to the caller. So in the caller 
the message expression
will get replaced with the returned value.

To see how this works an example in REXX (which ooRexx understands and is able 
to execute) and one
in ooRexx:

  * REXX (and ooRexx)

str="?yadot uoy era woh ,tsiL-MBI ,olleH"
say reverse(str) /* reverse the string and show it */

  * ooRexx (message style)

str="?yadot uoy era woh ,tsiL-MBI ,olleH"
say str~reverse  /* reverse the string and show it */

Both yield the same result, here a rexxtry session (in this case on Windows 10):

F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\clr\raffel>rexxtry
REXX-ooRexx_5.0.0(MT)_32-bit 6.05 30 Nov 2021
  rexxtry.rex lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
  Go on - try a few...Enter 'exit' to end.

str="?yadot uoy era woh ,tsiL-MBI ,olleH"
  ... rexxtry.rex on WindowsNT
say reverse(str)
Hello, IBM-List, how are you today?
  ... rexxtry.rex on WindowsNT
say str~reverse
Hello, IBM-List, how are you today?
  ... rexxtry.rex on WindowsNT

As you can see the results are identical. Here a version that first reverses 
the string, replaces
commas with a blank in the string and then extracts the second word and 

Re: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 10/1/22 10:10 pm, Rony G. Flatscher wrote:

On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.

What do you mean by "the message paradigm"? How does it differ from sending 
method invocation
and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.

If it's not necessary then why did you make such a big deal about it?

Well if you have really read the entire post you should know. Without 
implementing the message
paradigm things become clumsy and some important features, if you need them, 
are simply not available.


I'm still completely baffled by the why not implementing the "message 
paradigm" is clumsy. Returning "self" from a method makes sense to me. 
What if I'm creating a class which supports method chaining
but some methods return values other than self. Nothing you are saying 
makes sense to me. It's dogma.


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

Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> As a little teaser, if interested, just look-up the ooRexx runtime objects
> named .input, .output and .error.

Aren't those just monitor objects?


--
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: Monday, January 10, 2022 7:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming 
features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 10.01.2022 05:28, David Crayford wrote:
> On 9/1/22 11:22 pm, Rony G. Flatscher wrote:
>> On 09.01.2022 03:19, David Crayford wrote:
>>> On 9/1/22 2:15 am, Rony G. Flatscher wrote:
 On 08.01.2022 01:52, David Crayford wrote:
> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:

... cut ...

>>> Number 7 on my list is support for OO which implies message passing.
>> Well, this does not mean that the programming language supports the message 
>> paradigm. If it did it
>> would have an explicit "Message" class (like there are explicit classes like 
>> "Object", "Class",
>> "Method" and the like), hence messages are not FCOs. Compare this to 
>> languages like SmallTalk or
>> ooRexx.
>>
>> Maybe it is easier to grasp some of the ramifications by looking at the 
>> popular fluent pattern
>> (https://secure-web.cisco.com/16gHuUSvm6wTt36qDHrbk52jx7cBfrMxkFy9KdL4OA5teVngp8Mpxa3-ScxQQj6e8NG8rc5Poicg4agf5YtCC7n9giLhoKsCYDHGyaSIplNNZYJpoOiaHTibhkaNKJDd5kMrMIsI7iMuEcfUcSxBtXuq80eRv-jsiH3bt0FEkf2whHXX3X9KAku-TVgGXniJyaOhg4rTanyB_YmPOXyiZKSyA0kL3i8i8SnOVK3RaQ0jMgetCj6diuu61cSmSouZ3VeteLv7HyTfu8lDFu0g2esJUbMSz_nitJ1YkcB_d9OyZvpJb9WB0O6E9S8kPfLuixlWnfmgLwpxGWgYK0xZZcsF18e3TiQuoePIwYl2HE7LOHxHE6lHW7jaAEwPD5ehgtPaIjK7Wqqqbp-m7skw8ruTvJkYUOXXAc5U7m6oGqnt_ugEow8VOV6C1QQlhfDME/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFluent_interface)
>>  which needs to be explicitly programmed in
>> languages that do not support the message paradigm, but is "freely" ;) 
>> available in languages like
>> Smalltalk and ooRexx.
>
> I'm familiar with fluent APIs. I've been coding C++ and Java for over 25 
> years. They don't need an
> explict "Message", "Object" or "Class". In Java every object is a subclass of 
> Obect. C++ is a
> multi-paradigm language so doesn't require that.
> To write a fluent interface in C++, Java, JavaScript just return "this" from 
> the class method or
> member function. In Lua or Python return self. Then you can chain together 
> method calls. This is
> meat a potatoes stuff in all of the languages I listed.

Yes, one has to explicitly change the method signatures in strictly typed 
languages to return the
object for which the method executes and one must supply the appropriate return 
statement in each of
these methods, which is fine.

---

In ooRexx however, you do not have to explicitly code "return self" in methods 
in order to use
methods of a class fluently. It even does not matter whether a method returns 
the proper object
(referred to with the variable named self in the fluent method) or has no 
return value at all! If an
ooRexx programmer wants to use an object's/value's/instance's methods 
("behaviour") fluently, he can
do so independent of whether the method returns the proper object or not.

It is this flexibility (if needed) that is available by design, because of the 
full implementation
of the message paradigm, relieving the programmers of burdens they must undergo 
in many popular
programming languages, and all must apply properly the pattern.

---

There are other aspects, abilities that ooRexx possesses that other popular 
programming languages
lack because of the message paradigm ooRexx implements. As a little teaser, if 
interested, just
look-up the ooRexx runtime objects named .input, .output and .error. As 
harmless as they may look,
it is incredible which power they make available to programmers if need be. But 
that would be
another story ...

---rony

--
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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 10.01.2022 14:13, David Crayford wrote:
> On 10/1/22 8:34 pm, Rony G. Flatscher wrote:
>> On 09.01.2022 16:29, Seymour J Metz wrote:
 Well all of your languages miss the support for the message paradigm.
>>> What do you mean by "the message paradigm"? How does it differ from sending 
>>> method invocation
>>> and response messages to objects?
>> The message paradigm as set forth by Smalltalk explicitly defines a class 
>> for messages, allows for
>> intercepting messages, rerouting messages at the will of the programmer and 
>> much more, as messages
>> themselves become objects that the programmer can interact with, if needed.
>>
>> ooRexx implements the message paradigm in full, something that is easily 
>> overlooked as usually it is
>> not necessary to be aware of it.
>
> If it's not necessary then why did you make such a big deal about it?

Well if you have really read the entire post you should know. Without 
implementing the message
paradigm things become clumsy and some important features, if you need them, 
are simply not available.


>
>> As you can see, if there should be need for adding external functions and/or 
>> methods to ooRexx, this
>> can be done with the powerful and easy to use C++ API of ooRexx. As a matter 
>> of fact BSF4ooRexx and
>> dbusoorexx are using those native C++ APIs allowing high speed and using all 
>> that is available in
>> and via the C++ world.
>
> ooRexx will never be high speed because it's implementation is fundamentally 
> ineffecient. 

LOL!

ooRexx for any practical purpose is more than speedy enough! And its speedness 
has been excercised
in quite a few applications I wrote in the past twenty, twenty fiver years.

Have you every tried it out, e.g. for controlling applications, processes, 
having macros dispatched
against hosting applications, for processing MS Office documents, 
OpenOffice/LibreOffice documents,
controlling your Linux infrastructure via DBus, taking advantage of e.g. data 
mining Java class
libraries etc., etc.?

Clearly you have not, hence it is unfortunately ongoing badmouthing without any 
practical experience
knowledge.


> Most scripting languages compile to bytecode which is then processed by a VM. 
> For example, the Lua
> VM is less tha 2K lines of code and can fit into L2 cache which is why it's 
> blistering fast
> https://www.lua.org/source/5.1/lvm.c.html. 

Cool! If high speed is so important then Assembler would be much better, of 
course, forget Lua by
comparison! ;)


> ooRexx chose to use a graph of C++ classes with abstract base classes for 
> every instruction and
> clause. OMG, dynamic dispatch for every instruction!

You seem to not understand - or intentionally ignore - the implications of a 
true implementation of
the message paradigm, the power, the flexibility and the easeness for 
unleashing it.


> https://github.com/ooRexx/ooRexx/tree/master/interpreter/instructions
>
> It's gigantic clump of inefficient code based upon inheritance. 

Badmouthing again. If you really believe that you should go back to text books 
then and read about
oo and inheritance all over and  stop requesting OO-features to be present in 
programming languages
at all, which you have been claiming is so important in the first place...

And while giving us the impression you would be an expert in this field how 
does it compare to
Objective-C?

Now the red herring seems to be clumsiness, high speed, unnecessary 
inheritance, ... unfortunately
distracting and badmouthing again. :(


> The GoF Design Patterns book which dates back to the 90s was a 
> groundbreaking, seminal work which
> had a central theme of introducing patterns to avoid inheritance. 

Please stop giving misinformation (I have read the book decades ago)!

But fighting inheritance, declaring it to be useless, clumsy all of a sudden is 
quite strange to say
the least.


> Modern languages like Rust don't even support Inheritance.

There are assemblers that do neither, so wouldn't they be much better than Rust 
then?  ;)

[Your "name calling" of languages suggesting you would be an expert in all of 
them has not been
really convincing and not really relevant in this context.]


> If you want high speed then use a JIT compiler. The Lua Functional library 
> used with LuaJIT can
> boil a chain of method calls down to a dozen instructions with no linkage 
> overhead
> https://luafun.github.io/intro.html. The Julia programming language can do 
> the same with similar
> syntax. If I wanted to use REXX
> I would use NetRexx to take advantage of the JVM JIT.

Indeed, if high speed is of high priority and you are not able to mix and match 
languages then that
is always a nice path to go: starting out with Assembler of course.

And yes, NetRexx qualifies like Java, Kotlin, Groovy and the like which is 
really great as REXX
programmers can quickly take advantage of the NetRexx language.

If there are segments that need high speed such that ooRexx would not qualify, 
then you can easily

Re: EXTERNAL: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Crawford, Robert C.]

The 4GL's from the 80's had two problems, as I remember.  First, if you wanted 
to customize something, make it a little snazzier than out of the box, you had 
to od some pretty wicked things that weren't human language like at all.  

Second, they didn't perform as well as real programming languages.  That may be 
why the 4GL's tended to be relegated to back-office work by end-users.

Robert Crawford
Mainframe Management
United Services Automobile Association
(210) 913-3822

"Moy glaz! YA ne dolzhen dobavlyat' v nego puding!"
- Tolstoy
Please send requests to mainframe management through our front door at  
go/mfmfrontdoor

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Friday, January 7, 2022 3:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: ... Re: Top 8 Reasons for using Python instead of REXX 
for z/OS

I agree with Shmuel; we heard a lot about 4GLs back in the '80s and '90s, but I 
never saw one that lived up to the claims.  DYL-280II, for example, was 
advertised as a 4GL, but it wasn't close.  Don't get me wrong, as a 3GL I liked 
it just fine, and my company had me teach it to end users so they could fetch 
data from their particular databases without throwing off developers' estimated 
completion dates -- very successfully, I add happily.
But it was no 4GL.

Actually I lump 4GLs and AI into the same bucket.  They're related, I think:
Folks dream of getting computers to think and talk like a human, but so far it 
hasn't happened and I suspect it cannot happen.  But then as a Christian I'm 
also a mystic, by which I mean that the 37 cents' worth of chemicals that one 
often hears about are not what we are, only what we're made of, and that the 
scientists' attempts to figure out what consciousness is and why it evolved is 
doomed to failure because they're starting with the wrong postulates.  But, 
heck, I may be mistaken.  Maybe someday a computer will pass a really decent 
Turing test.

I'm not concerned that my profession is about to wither away, though.

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

/* Woe to him inside a nonconformist clique who does not conform with 
nonconformity.  -Eric Hoffer */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Friday, January 7, 2022 16:09

I know of languages that have been peddled as human oriented or English like; I 
don't know of any that even come close. 

--
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: Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 10/1/22 8:34 pm, Rony G. Flatscher wrote:

On 09.01.2022 16:29, Seymour J Metz wrote:

Well all of your languages miss the support for the message paradigm.

What do you mean by "the message paradigm"? How does it differ from sending 
method invocation and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.


If it's not necessary then why did you make such a big deal about it?


As you can see, if there should be need for adding external functions and/or 
methods to ooRexx, this
can be done with the powerful and easy to use C++ API of ooRexx. As a matter of 
fact BSF4ooRexx and
dbusoorexx are using those native C++ APIs allowing high speed and using all 
that is available in
and via the C++ world.


ooRexx will never be high speed because it's implementation is 
fundamentally ineffecient. Most scripting languages compile to bytecode 
which is then processed by a VM. For example, the Lua VM is less tha 2K 
lines of code and can fit into L2 cache which is why it's blistering 
fast https://www.lua.org/source/5.1/lvm.c.html. ooRexx chose to use a 
graph of C++ classes with abstract base classes for every instruction 
and clause. OMG, dynamic dispatch for every instruction!


https://github.com/ooRexx/ooRexx/tree/master/interpreter/instructions

It's gigantic clump of inefficient code based upon inheritance. The GoF 
Design Patterns book which dates back to the 90s was a groundbreaking, 
seminal work which had a central theme of introducing patterns to avoid 
inheritance. Modern languages like Rust don't even support Inheritance.


If you want high speed then use a JIT compiler. The Lua Functional 
library used with LuaJIT can boil a chain of method calls down to a 
dozen instructions with no linkage overhead 
https://luafun.github.io/intro.html. The Julia programming language can 
do the same with similar syntax. If I wanted to use REXX

I would use NetRexx to take advantage of the JVM JIT.




Again it is fairly straight-forward and easy to add external routines and 
external methods to ooRexx
if need be.

---rony



--
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: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 10.01.2022 05:28, David Crayford wrote:
> On 9/1/22 11:22 pm, Rony G. Flatscher wrote:
>> On 09.01.2022 03:19, David Crayford wrote:
>>> On 9/1/22 2:15 am, Rony G. Flatscher wrote:
 On 08.01.2022 01:52, David Crayford wrote:
> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:

... cut ...

>>> Number 7 on my list is support for OO which implies message passing.
>> Well, this does not mean that the programming language supports the message 
>> paradigm. If it did it
>> would have an explicit "Message" class (like there are explicit classes like 
>> "Object", "Class",
>> "Method" and the like), hence messages are not FCOs. Compare this to 
>> languages like SmallTalk or
>> ooRexx.
>>
>> Maybe it is easier to grasp some of the ramifications by looking at the 
>> popular fluent pattern
>> (https://en.wikipedia.org/wiki/Fluent_interface) which needs to be 
>> explicitly programmed in
>> languages that do not support the message paradigm, but is "freely" ;) 
>> available in languages like
>> Smalltalk and ooRexx.
>
> I'm familiar with fluent APIs. I've been coding C++ and Java for over 25 
> years. They don't need an
> explict "Message", "Object" or "Class". In Java every object is a subclass of 
> Obect. C++ is a
> multi-paradigm language so doesn't require that.
> To write a fluent interface in C++, Java, JavaScript just return "this" from 
> the class method or
> member function. In Lua or Python return self. Then you can chain together 
> method calls. This is
> meat a potatoes stuff in all of the languages I listed.

Yes, one has to explicitly change the method signatures in strictly typed 
languages to return the
object for which the method executes and one must supply the appropriate return 
statement in each of
these methods, which is fine.

---

In ooRexx however, you do not have to explicitly code "return self" in methods 
in order to use
methods of a class fluently. It even does not matter whether a method returns 
the proper object
(referred to with the variable named self in the fluent method) or has no 
return value at all! If an
ooRexx programmer wants to use an object's/value's/instance's methods 
("behaviour") fluently, he can
do so independent of whether the method returns the proper object or not.

It is this flexibility (if needed) that is available by design, because of the 
full implementation
of the message paradigm, relieving the programmers of burdens they must undergo 
in many popular
programming languages, and all must apply properly the pattern.

---

There are other aspects, abilities that ooRexx possesses that other popular 
programming languages
lack because of the message paradigm ooRexx implements. As a little teaser, if 
interested, just
look-up the ooRexx runtime objects named .input, .output and .error. As 
harmless as they may look,
it is incredible which power they make available to programmers if need be. But 
that would be
another story ...

---rony

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

Ad message paradigm (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 09.01.2022 16:29, Seymour J Metz wrote:
>> Well all of your languages miss the support for the message paradigm.
> What do you mean by "the message paradigm"? How does it differ from sending 
> method invocation and response messages to objects?

The message paradigm as set forth by Smalltalk explicitly defines a class for 
messages, allows for
intercepting messages, rerouting messages at the will of the programmer and 
much more, as messages
themselves become objects that the programmer can interact with, if needed.

ooRexx implements the message paradigm in full, something that is easily 
overlooked as usually it is
not necessary to be aware of it.

A REXX programmer may stick to REXX programs and still is able to use ooRexx to 
run them as ooRexx
is a snap-in replacement which supports all of REXX and adds additional 
features. For anyone who is
not acquainted to REXX or ooRexx the little ten page 
paper gives an
introduction and explains the most important concepts. There is no need for 
more pages to make the
language understandable and applicable for those who already know how to 
program (including
Assembler, VB/VBA/VBA.Net, Python etc. programmers).

In ooRexx messages in code can be identified by locating the message operator 
(tilde: ~). Classic
REXX BIFs (built-in functions) like c2x(), reverse(), substr() etc. are 
available in ooRexx, but
"behind the curtain" the implementation of each string BIF is organized in the 
"String"
class/structure/type where the implementation resides in form of method 
routines that are named
"c2x", "reverse", "substr" and the like. Usually this is not important to know 
if using REXX
concepts only. In the context of this discussion however it allows for 
understanding how ooRexx
works "behind the curtain": everything in ooRexx (like in Smalltalk) is an 
object (synonyms: value,
instance).

Conceptually a programmer communicates with objects by sending them messages as 
if objects were
living things. The object receives the message and will start out to look for a 
method it possesses
that carries the same name as the received message. Once the method is located, 
the object invokes
it, supplying any arguments that may have been given with the message. If the 
method returns a value
(object, instance), the object will return it to the caller. So in the caller 
the message expression
will get replaced with the returned value.

To see how this works an example in REXX (which ooRexx understands and is able 
to execute) and one
in ooRexx:

  * REXX (and ooRexx)

str="?yadot uoy era woh ,tsiL-MBI ,olleH"
say reverse(str) /* reverse the string and show it */

  * ooRexx (message style)

str="?yadot uoy era woh ,tsiL-MBI ,olleH"
say str~reverse  /* reverse the string and show it */

Both yield the same result, here a rexxtry session (in this case on Windows 10):

F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples\clr\raffel>rexxtry
REXX-ooRexx_5.0.0(MT)_32-bit 6.05 30 Nov 2021
  rexxtry.rex lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
  Go on - try a few...Enter 'exit' to end.

str="?yadot uoy era woh ,tsiL-MBI ,olleH"
  ... rexxtry.rex on WindowsNT
say reverse(str)
Hello, IBM-List, how are you today?
  ... rexxtry.rex on WindowsNT
say str~reverse
Hello, IBM-List, how are you today?
  ... rexxtry.rex on WindowsNT

As you can see the results are identical. Here a version that first reverses 
the string, replaces
commas with a blank in the string and then extracts the second word and 
displays it, using the same
rexxtry session:

say word(changestr(',',reverse(str),' '),2)
IBM-List
  ... rexxtry.rex on WindowsNT
say str~reverse~changestr(',',' ')~word(2)
IBM-List
  ... rexxtry.rex on WindowsNT

As one can have white space around the message operator one could use it to 
e.g. format the message
version as:

say str~reverse ~changestr(',',' ') ~word(2)
IBM-List
  ... rexxtry.rex on WindowsNT

Once one is accustomed to the message paradigm it becomes easy to use it (and 
also to read the
message version statements).

---

One nice thing about this is the abstraction that goes with it: we as 
programmers do not need to
understand how the implementation goes we only need to know which messages an 
object understands and
then send it to it (the object has the knowledge and inventory to resolve it 
appropriately).

---

However there is much more a full implementation of the message paradigm allows 
for, e.g. monitoring
messages that get sent to an object, rerouting/forwarding messages to 

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 10/1/22 6:13 am, Seymour J Metz wrote:

he raison d'être of the mainframe is to run applications written in COBOL.

What is FORTRAN, chopped liver?


AFAIK, there is no officially supported Fortran (or Ada) compiler for 
z/OS. When Rocket ported the R programming language to z/OS we had to 
port a Fortran to C transpiler. Bringing back Fortran is another sweet 
spot that a z/OS LLVM port will solve.






--
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: Friday, January 7, 2022 11:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 8/1/22 1:42 am, Tony Harminc wrote:

On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:


I've been following this thread and one thing that has yet to appear, or I 
missed it, has to do with 4GL's and the drive, at one point, for languages that 
were more human oriented - those that could be written more like a normal 
sentence or phrase, and avoid the technical jargon/gobblygook/syntax. As I 
recall in the 1980's there were a few but nothing came of them, instead we have 
languages that have their own syntax, and which require extensive learning but 
nothing that allows a non-programmer to actually generate a complex business 
program.

COBOL was supposed to be that, no? Managers could in theory at least
read (if not write) a COBOL program and understand what it does,
because it so (superficially) resembles English.

It's interesting that no language since COBOL has ever tried to emulate
the "english" syntax. It turns out that it was not actually a terribly
good idea. Programmers preferred languages with more concise syntax.

BTW, I'm not knocking COBOL. I'm a mainframe guy and I'm cognizant to
the fact that the raison d'être of the mainframe is to run applications
written in COBOL. PL/I programmers will disagree but COBOL is king.



  From my experience, REXX has many of the 4GL goals as the syntax isn't overly 
complex and is something a non-programmer can comprehend rather easily. As has 
been previously mentioned in this thread, REXX can be more readily learned and 
used than the majority of the current languages. It isn't perfect but it works 
very well.

Indeed.

--
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: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 9/1/22 11:22 pm, Rony G. Flatscher wrote:

On 09.01.2022 03:19, David Crayford wrote:

On 9/1/22 2:15 am, Rony G. Flatscher wrote:

On 08.01.2022 01:52, David Crayford wrote:

On 7/1/22 7:53 pm, Rony G. Flatscher wrote:

... cut ...


Well all of your languages miss the support for the message paradigm.

What on earth are you talking about?

Hmm, this sounds quite emotional. :)


Not at all. I don't get emotional about technology. I'm just terribly 
confused by what you're saying.







Number 7 on my list is support for OO which implies message passing.

Well, this does not mean that the programming language supports the message 
paradigm. If it did it
would have an explicit "Message" class (like there are explicit classes like "Object", 
"Class",
"Method" and the like), hence messages are not FCOs. Compare this to languages 
like SmallTalk or ooRexx.

Maybe it is easier to grasp some of the ramifications by looking at the popular 
fluent pattern
(https://en.wikipedia.org/wiki/Fluent_interface) which needs to be explicitly 
programmed in
languages that do not support the message paradigm, but is "freely" ;) 
available in languages like
Smalltalk and ooRexx.


I'm familiar with fluent APIs. I've been coding C++ and Java for over 25 
years. They don't need an explict "Message", "Object" or "Class". In 
Java every object is a subclass of Obect. C++ is a multi-paradigm 
language so doesn't require that.
To write a fluent interface in C++, Java, JavaScript just return "this" 
from the class method or member function. In Lua or Python return self. 
Then you can chain together method calls. This is meat a potatoes stuff 
in all of the languages I listed.




... cut ...



That's why I have absolutely no interest in NetRexx. I have far better options 
on the JVM.

Well, you mention in another post that you were/are an expert REXX programmer, 
love Lua, use Python
in your shop because of your teams coming with that knowledge from the 
colleges, but nowadays you
would mainly code in Java/Kotlin. Kudos!

What appears to be a little bit strange with such a background is that you have 
obviously never
really assessed NetRexx, as otherwise you could not possibly have come to such 
wrong conclusions.

Why would I invest time into NetRexx. How many NetRexx jobs are there out there?

Why would that be important?
(Besides, due to NetRexx' design philosophy there is not really much time to 
invest, especially if
you have a good REXX background such that you understand already the purpose of 
e.g. the keyword
statement TRACE; you may want to try to trace a program written in Java or 
Kotlin the way NetRexx
allows for.)

The question to ask is: can NetRexx be used to (quickly) create reliable 
professional applications?
The answer is simple: yes. It is available, it is proven, it has been 
successfully used to create
professional programs. (In case you must supply Java source code, you still can 
use NetRexx and have
it eject Java source code.)

NetRexx creates normal, genuine Java classes as does the Java compiler or the 
Kotlin (or the Groovy
...) compiler. All the compiled Java classes (Java bytecode) can interoperate, 
with each other so it
is possible to use NetRexx compiled Java classes from Java and Kotlin (and 
Groovy ...) and the other
way round, NetRexx can use Java classes compiled from Java or Kotlin (or Groovy 
...) programs and
the like. Therefore it does not matter whether everyone on earth is using 
NetRexx or only a single
person.

The question then is: what is the problem at hand, what programming languages 
qualify best to solve
it? And NetRexx can be used for most problem domains, no need to use a language 
with special
features that are not needed to solve the problem at hand.

If I were you (with your background), I would seriously look into NetRexx, 
rather then ignore it.
You for sure would quickly become able to solve most of your programming 
problems with it,
exploiting your REXX and Java knowledge. OTOH, if you do not want to look into 
it, that is fine too,
of course, but then, please do not badmouth technologies you simply have no 
experience with.



Kotlin is not only a first class language for server side it is also the 
language of choice for
building Android applications.

Kotlin and Android is interesting:  Android is a Linux-based operating system 
for which Android
applications have been mostly created in Java for more than a decade, without 
the public even
realizing it (even today). This is the reason why Oracle has been suing Google 
over the use of Java,
although Google used an open source Java implementation from the Apache 
software foundation. Google
used IntelliJ for developing Java applications for Android and even forked 
IntelliJ. The IntelliJ
people came up with Kotlin a few years ago, which is a JVM language compiling 
to Java classes (Java
bytecode), and Google embraced it.

AFAIK most of the Android applications get still created with Java as it takes 
time to learn 

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bob Bridges]

He was talking about NetREXX.

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

/* Fatal error; system halted.  Press any key to do nothing. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, January 9, 2022 19:28

Which Rexx?

--- On Sun, 9 Jan 2022 18:38:07 -0400, René Jansen  wrote:
>> On 9 Jan 2022, at 18:34, Seymour J Metz wrote:
>> I downloaded the new documentation, and address doesn't seem to have the 
>> same semantics as in REXX.

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

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Sun, 9 Jan 2022 18:38:07 -0400, René Jansen  wrote:
>... 
>In the meantime, the case in which you just quote the command you would like 
>to be executed, works very well.

Quoting commands sounds like the way (FSVO) good old Rexx works.


>> On 9 Jan 2022, at 18:34, Seymour J Metz wrote:
>> 
>> I downloaded the new documentation, and address doesn't seem to have the 
>> same semantics as in REXX.
>> 
Which Rexx?

-- gil

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[John McKown]

Create the temp file. Open it. Unlink it. When you close the file, it will
be removed by the filesystem. Until then, the inside exists without a
directory entry.

On Sun, Jan 9, 2022, 16:51 Seymour J Metz  wrote:

> Unique names for temporary Unix files is trivial. Making them go away at
> the completion of the work is more difficult.
>
> The user can also make ad hoc changes to many scripts by changing
> environment variables or configuration files.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
> Sent: Friday, January 7, 2022 4:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for
> z/OS
>
> On Fri, 7 Jan 2022 19:43:58 +, Seymour J Metz wrote:
>
> >Well, if you introduced the concept of steps into a script language then
> it shouldn't be too hard to also add the concept of passed data sets. Named
> temporary data sets also shouldn't be difficult. Or you could just use,
> e.g., ~/temp.
> >
> With JCL, the processor generates a unique name; makes it available
> in subsequent steps and reliable removes it when the job completes.
> Not easy or even possible with UNIX facilities.
>
> >Overrides are necessary unless you can anticipate every ad hoc change
> that the user might want to make; otherwise he would have to edit the
> script.
> >
> Il a les défauts de ses qualités.  I'm uncomfortable that someone cam
> mane unanticipated  ad hoc changes by overrides to my read-only
> library PROC and complain that it doesn't  work.
>
> -- gil
>
> --
> 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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Sun, 9 Jan 2022 22:50:46 +, Seymour J Metz wrote:

>Unique names for temporary Unix files is trivial. Making them go away at the 
>completion of the work is more difficult.
> 
Most implementations of tmpfile() unlink the file immediately on creating it,
before returning to the caller.  z/OS is an outlier, perhaps because of
historic support for Classic data sets.  (But that could work for PDS or
connected PDSE members.)

-- gil

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bob Bridges]

Yeah, I've become a BIG fan of comments in my old age.

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

/* He that is of the opinion money will do everything may well be suspected of 
doing everything for money.  -Ben Franklin */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Brennan
Sent: Sunday, January 9, 2022 17:51

I don't like anything complex enough that I have trouble figuring out what the 
original programmer had in mind.  The worst though, is when I get halfway into 
something I'm already complaining about, then realize it's my own code I wrote 
10 years earlier :)

--- On 1/9/2022 2:17 PM, Seymour J Metz wrote:
> I take it you don't like REXX scripts, since they can conditionally select 
> different dynamic allocations.

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

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

I think that is a very valid requirement. Due to the platform it is running on, 
the JSR223 interface would also be usable for that purpose, although that is 
also rather light on retaining state at the moment. It will not be in the next 
release (4.02) because that is functionally closing, but I’ll be back by the 
time 4.03 hits the street.

René.

> On 9 Jan 2022, at 19:00, Seymour J Metz  wrote:
> 
> What I want to do is to register environments and function packages in a 
> manner similar to what REXX supports, including retaining context. For 
> instance, I would like for an editor to be able to call an edit macro written 
> in NetRexx and allow the macro to issue commands and queries back to the 
> editor, with the editor able to set variables within the macro.
> 
> 
> --
> 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: Sunday, January 9, 2022 5:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 
> Reasons for using Python instead of REXX for z/OS
> 
> Yes, we are working on that. If you can tell me what you want to see, we’ll 
> have a go.
> In the meantime, the case in which you just quote the command you would like 
> to be executed, works very well.
> 
> Best regards,
> 
> René.
> 
> 
>> On 9 Jan 2022, at 18:34, Seymour J Metz  wrote:
>> 
>> I downloaded the new documentation, and address doesn't seem to have the 
>> same semantics as in REXX.
>> 
>> 
>> --
>> 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: Sunday, January 9, 2022 3:05 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 
>> Reasons for using Python instead of REXX for z/OS
>> 
>> Hi Shmuel.
>> 
>> NetRexx has ADDRESS. It was added by Marc Remes in release 4.01. It can 
>> address any executable on your system. Subsequent versions will add ADDRESS 
>> WITH for collections and network.
>> This was a syntactical addition, the runtime contains, for years and years 
>> already, the package org.netrexx.address, which has class OSProcess with 
>> method exec(), outtrap(command=Rexx) (where could that have come from?) and 
>> event for lines of output.
>> But we decided to make this look more like Rexx.
>> 
>> Best regards,
>> 
>> René.
>> 
>>> On 9 Jan 2022, at 11:29, Seymour J Metz  wrote:
>>> 
>>> FSVO follows. NetRexx doesn't have the concept of routing bare expressions 
>>> to the default environment. In fact, it doesn't have the address statement 
>>> at all, unless there has been a subsequent addition to the language.
>>> 
>> 
>> 
>> --
>> 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: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

What I want to do is to register environments and function packages in a manner 
similar to what REXX supports, including retaining context. For instance, I 
would like for an editor to be able to call an edit macro written in NetRexx 
and allow the macro to issue commands and queries back to the editor, with the 
editor able to set variables within the macro.


--
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: Sunday, January 9, 2022 5:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons 
for using Python instead of REXX for z/OS

Yes, we are working on that. If you can tell me what you want to see, we’ll 
have a go.
In the meantime, the case in which you just quote the command you would like to 
be executed, works very well.

Best regards,

René.


> On 9 Jan 2022, at 18:34, Seymour J Metz  wrote:
>
> I downloaded the new documentation, and address doesn't seem to have the same 
> semantics as in REXX.
>
>
> --
> 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: Sunday, January 9, 2022 3:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 
> Reasons for using Python instead of REXX for z/OS
>
> Hi Shmuel.
>
> NetRexx has ADDRESS. It was added by Marc Remes in release 4.01. It can 
> address any executable on your system. Subsequent versions will add ADDRESS 
> WITH for collections and network.
> This was a syntactical addition, the runtime contains, for years and years 
> already, the package org.netrexx.address, which has class OSProcess with 
> method exec(), outtrap(command=Rexx) (where could that have come from?) and 
> event for lines of output.
> But we decided to make this look more like Rexx.
>
> Best regards,
>
> René.
>
>> On 9 Jan 2022, at 11:29, Seymour J Metz  wrote:
>>
>> FSVO follows. NetRexx doesn't have the concept of routing bare expressions 
>> to the default environment. In fact, it doesn't have the address statement 
>> at all, unless there has been a subsequent addition to the language.
>>
>
>
> --
> 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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

Well, I've promoted the use of symbolic parameters since OS/360 R14, causing me 
to curse the old 100 character limit on PARM.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Friday, January 7, 2022 4:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Not strictly speaking, no.  But find me an old-timer (especially manager types) 
who is symbol-aware and actively uses them or promotes their extensive use in 
crafting PROC's for other than UNIT, REGION and sometimes HLQ and SPACE.

I have faced active resistance on several jobs to my "overuse" of symbols.  I 
use them a lot, everywhere I can get away with it.  Many do not, and fail to 
understand the flexibility they provide.

One place you CANNOT use a symbol is for the JCL statement label.  I never 
really understood that restriction, though I have managed to get by with the 
rules as they are.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, January 7, 2022 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 18:47:47 +, Seymour J Metz wrote:

>ENQ and overrides come to mind.
>
Add passed temporary DSNs to the list.

Are overrides necessary?  Is there anything that overrides that couldn't be 
done (in a more controlled manner) with symbol substitution?

--

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

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

I don't like anything complex enough that I have trouble figuring out 
what the original programmer had in mind.  The worst though, is when I 
get halfway into something I'm already complaining about, then realize 
it's my own code I wrote 10 years earlier :)


On 1/9/2022 2:17 PM, Seymour J Metz wrote:

I take it you don't like REXX scripts, since they can conditionally select 
different dynamic allocations.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, January 7, 2022 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I was more talking about JCL forcing the DD-to-dataset relationships
into one place, which makes them easier to find.

Here's a line I had to mess with last week in a Linux shell script:

$IM_INSTALL_LOCATION/eclipse/IBMIM -input "$SCRIPTHOME/updateSKLM.xml"

While those $ variables are set in that same script, various "if"
statements and other sources make it difficult to figure out what the
end result of the command might be.

On 1/7/2022 1:16 PM, Seymour J Metz wrote:

+There's no forced standard for the choice of ddnames either; you need to know whether 
it's INPUT, SYSIN, SYSUT1 or "E. None of the above."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, January 7, 2022 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yes, but since there's no forced standard, variables and other methods
mean I might have to look the script or code to figure out what's going
on.  Sometimes that can get quite complex with the things people do that
eventually comes up with a filename/path string.  JCL makes everything
nice and neat and in one place.

On 1/7/2022 12:01 PM, Seymour J Metz wrote:


Variables and file handles may not be the same as DD names, but they can 
serve the same function.



--
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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

Unique names for temporary Unix files is trivial. Making them go away at the 
completion of the work is more difficult.

The user can also make ad hoc changes to many scripts by changing environment 
variables or configuration files.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, January 7, 2022 4:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 19:43:58 +, Seymour J Metz wrote:

>Well, if you introduced the concept of steps into a script language then it 
>shouldn't be too hard to also add the concept of passed data sets. Named 
>temporary data sets also shouldn't be difficult. Or you could just use, e.g., 
>~/temp.
>
With JCL, the processor generates a unique name; makes it available
in subsequent steps and reliable removes it when the job completes.
Not easy or even possible with UNIX facilities.

>Overrides are necessary unless you can anticipate every ad hoc change that the 
>user might want to make; otherwise he would have to edit the script.
>
Il a les défauts de ses qualités.  I'm uncomfortable that someone cam
mane unanticipated  ad hoc changes by overrides to my read-only
library PROC and complain that it doesn't  work.

-- gil

--
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: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

Yes, we are working on that. If you can tell me what you want to see, we’ll 
have a go. 
In the meantime, the case in which you just quote the command you would like to 
be executed, works very well.

Best regards,

René.


> On 9 Jan 2022, at 18:34, Seymour J Metz  wrote:
> 
> I downloaded the new documentation, and address doesn't seem to have the same 
> semantics as in REXX.
> 
> 
> --
> 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: Sunday, January 9, 2022 3:05 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 
> Reasons for using Python instead of REXX for z/OS
> 
> Hi Shmuel.
> 
> NetRexx has ADDRESS. It was added by Marc Remes in release 4.01. It can 
> address any executable on your system. Subsequent versions will add ADDRESS 
> WITH for collections and network.
> This was a syntactical addition, the runtime contains, for years and years 
> already, the package org.netrexx.address, which has class OSProcess with 
> method exec(), outtrap(command=Rexx) (where could that have come from?) and 
> event for lines of output.
> But we decided to make this look more like Rexx.
> 
> Best regards,
> 
> René.
> 
>> On 9 Jan 2022, at 11:29, Seymour J Metz  wrote:
>> 
>> FSVO follows. NetRexx doesn't have the concept of routing bare expressions 
>> to the default environment. In fact, it doesn't have the address statement 
>> at all, unless there has been a subsequent addition to the language.
>> 
> 
> 
> --
> 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: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I downloaded the new documentation, and address doesn't seem to have the same 
semantics as in REXX.


--
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: Sunday, January 9, 2022 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons 
for using Python instead of REXX for z/OS

Hi Shmuel.

NetRexx has ADDRESS. It was added by Marc Remes in release 4.01. It can address 
any executable on your system. Subsequent versions will add ADDRESS WITH for 
collections and network.
This was a syntactical addition, the runtime contains, for years and years 
already, the package org.netrexx.address, which has class OSProcess with method 
exec(), outtrap(command=Rexx) (where could that have come from?) and event for 
lines of output.
But we decided to make this look more like Rexx.

Best regards,

René.

> On 9 Jan 2022, at 11:29, Seymour J Metz  wrote:
>
> FSVO follows. NetRexx doesn't have the concept of routing bare expressions to 
> the default environment. In fact, it doesn't have the address statement at 
> all, unless there has been a subsequent addition to the language.
>


--
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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I take it you don't like REXX scripts, since they can conditionally select 
different dynamic allocations.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, January 7, 2022 6:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I was more talking about JCL forcing the DD-to-dataset relationships
into one place, which makes them easier to find.

Here's a line I had to mess with last week in a Linux shell script:

$IM_INSTALL_LOCATION/eclipse/IBMIM -input "$SCRIPTHOME/updateSKLM.xml"

While those $ variables are set in that same script, various "if"
statements and other sources make it difficult to figure out what the
end result of the command might be.

On 1/7/2022 1:16 PM, Seymour J Metz wrote:
> +There's no forced standard for the choice of ddnames either; you need to 
> know whether it's INPUT, SYSIN, SYSUT1 or "E. None of the above."
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Tom Brennan [t...@tombrennansoftware.com]
> Sent: Friday, January 7, 2022 4:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
>
> Yes, but since there's no forced standard, variables and other methods
> mean I might have to look the script or code to figure out what's going
> on.  Sometimes that can get quite complex with the things people do that
> eventually comes up with a filename/path string.  JCL makes everything
> nice and neat and in one place.
>
> On 1/7/2022 12:01 PM, Seymour J Metz wrote:
>>
>>Variables and file handles may not be the same as DD names, but they can 
>> serve the same function.
>>
>
> --
> 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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> he raison d'être of the mainframe is to run applications written in COBOL. 

What is FORTRAN, chopped liver?


--
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: Friday, January 7, 2022 11:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On 8/1/22 1:42 am, Tony Harminc wrote:
> On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:
>
>> I've been following this thread and one thing that has yet to appear, or I 
>> missed it, has to do with 4GL's and the drive, at one point, for languages 
>> that were more human oriented - those that could be written more like a 
>> normal sentence or phrase, and avoid the technical jargon/gobblygook/syntax. 
>> As I recall in the 1980's there were a few but nothing came of them, instead 
>> we have languages that have their own syntax, and which require extensive 
>> learning but nothing that allows a non-programmer to actually generate a 
>> complex business program.
> COBOL was supposed to be that, no? Managers could in theory at least
> read (if not write) a COBOL program and understand what it does,
> because it so (superficially) resembles English.

It's interesting that no language since COBOL has ever tried to emulate
the "english" syntax. It turns out that it was not actually a terribly
good idea. Programmers preferred languages with more concise syntax.

BTW, I'm not knocking COBOL. I'm a mainframe guy and I'm cognizant to
the fact that the raison d'être of the mainframe is to run applications
written in COBOL. PL/I programmers will disagree but COBOL is king.


>>  From my experience, REXX has many of the 4GL goals as the syntax isn't 
>> overly complex and is something a non-programmer can comprehend rather 
>> easily. As has been previously mentioned in this thread, REXX can be more 
>> readily learned and used than the majority of the current languages. It 
>> isn't perfect but it works very well.
> Indeed.

--
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: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> I could be wrong, but I think the first use of "macro" in a
> programming/computer context was introduced in Assembler languages:

The first programming use of the term macro that I'm aware of was 705 
Autocoder. The first macro assembler that I'm aware of to allow conditional 
code generation was FAP. Did SAP have conditional assembly? The first assembler 
I'm aware of whose macro capability was turing complete was 7070 Autocoder (a 
macro was actually a 7070 proogram with special macros to emit code.)

> In order to perform that role, Assembler Macros definitely are required to 
> include
> statements that support conditional logic and looping and symbolic values;

Some macro assemblers lack conditional logic and looping. They could emit long 
sequences of code, but other than replacing parameter with arguments the 
sequence was the same for every call.

Micros in COMPASS were just variables; roughly the same as SETx symbols in 
HLASM.

Macros in, e.g., HLASM can generate things other than code, using the PUNCH 
statement.

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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Joel C. Ewing [jce.ebe...@cox.net]
Sent: Saturday, January 8, 2022 12:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python 
instead of REXX for z/OS

I could be wrong, but I think the first use of "macro" in a
programming/computer context was introduced in Assembler languages:  A
macro invocation statement basically looked like an assembly statement
with parameters, but instead of generating a single machine instruction
or data definition could generate a whole series of assembly
instructions.  The Macro definition typically includes both Assembly
statements and special macro control statements.  I was first introduced
to them in IBM 1410 Assembler, where they were used to generate the
relatively complex interfaces required to do I/O.  In 360/370/etc
Assembler, macros are extensively used to enforce the conventions for
requesting any service from the Operating System, not just I/O.   As
hardware architectures became more complex, programmers quickly
discovered there were many repetitive instruction sequences in a typical
assembler program, and macros were designed to allow a single statement
to generate the entire sequence with minimal effort.  In order to
perform that role, Assembler Macros definitely are required to include
statements that support conditional logic and looping and symbolic
values; but it is a pretty restrictive language, as its only intended
capability is to generate, perhaps conditionally, other Assembly
language statements, not to solve general purpose problems.

CDC 6000 Assembly Language included not only "macros" but "micros".   A
"micro" allowed you do create a definition of a new "machine
instruction" that would create a 15-bit, 30-bit, or 60-bit "instruction"
with binary sub-fields and parameter rules similar to actual machine
instructions statements, with a one-to-one correspondence between a
statement and an "instruction".  Could be used for "new" hardware
instructions not yet supported by the Assembler, for creating a
customized version of an instruction where some fields were desired to
be constrained, and possibly other bizarre applications.

The main distinction between a macro language and a full programming
language seems to be the context in which it is executed.   Macros are
embedded with statements of another language and "executed" when
processing or pre-processing those statements to generate additional
statements in that language to generate the complete program.   They are
part of the process of generating the statements for the full program,
not actually part of the final program.

 Joel C Ewing

On 1/7/22 06:57, Rony G. Flatscher wrote:
> On 07.01.2022 03:00, Bob Bridges wrote:
>> I usually include JCL under the ~very~ general rubric of "programming 
>> language", but even mentally I think that's a stretch.  It's more like a 
>> macro language, sort of like .bat I guess.
>>
>> I may as well take this opportunity to include a mild rant.  I've often 
>> heard the programs you can write for automating some applications referred 
>> to as "macros"; I have in mind VBA, for example, and what WordPerfect used 
>> to have if WordPerfect is still around.  It always seemed to me that VBA 
>> qualifies just fine as a programming language, and what I write in VBA is 
>> not a "macro", just a program.
>>
>> But then what is a macro?  In searching for some sort of distinction that 
>> would justify there being two different words, I've concluded to my own 
>> satisfaction that a macro is a set of instructions that have no 
>> decision-making capability, maybe no if-then syntax and definitely no 
>> looping, probably no arithmetic, possibly some rudimentary logic operators 
>> like NOT (and may only NOT).  The old 

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

Hi Shmuel.

NetRexx has ADDRESS. It was added by Marc Remes in release 4.01. It can address 
any executable on your system. Subsequent versions will add ADDRESS WITH for 
collections and network.
This was a syntactical addition, the runtime contains, for years and years 
already, the package org.netrexx.address, which has class OSProcess with method 
exec(), outtrap(command=Rexx) (where could that have come from?) and event for 
lines of output. 
But we decided to make this look more like Rexx. 

Best regards,

René.

> On 9 Jan 2022, at 11:29, Seymour J Metz  wrote:
> 
> FSVO follows. NetRexx doesn't have the concept of routing bare expressions to 
> the default environment. In fact, it doesn't have the address statement at 
> all, unless there has been a subsequent addition to the language.
> 


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

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

I wish, but I had no access to their outside network.  My work was done 
locally via crash cart.


On 1/9/2022 10:33 AM, Paul Gilmartin wrote:

On Sun, 9 Jan 2022 10:04:52 -0800, Tom Brennan  wrote:

...
shouldn't I call the customer and make sure he can remotely access the
unit?


ProTip:  When I pretend to be an operator and want to know whether the
link to Remotehost is working, I don't ask the local host.  I ask Remotehost
via the link.

-- gil

--
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: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Sun, 9 Jan 2022 10:04:52 -0800, Tom Brennan  wrote:
>...
>shouldn't I call the customer and make sure he can remotely access the
>unit? 
>
ProTip:  When I pretend to be an operator and want to know whether the
link to Remotehost is working, I don't ask the local host.  I ask Remotehost
via the link.

-- gil

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

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

On 1/9/2022 7:25 AM, Rony G. Flatscher wrote:

Ah, "http" instead of "https", sorry (wrote it from memory and did not test it) 
!


I have this joke I try to follow that sometimes makes the people I work 
with upset with me:  "Unless you tested it, there is *absolutely* no way 
it will work".


A few months ago I was working on a DS8000 key management box (Linux, 
WAS, DB2, SKLM).  This was during the day in Dallas and I drove to the 
site with my boss, let's call him.  I finished the work in about 2 
hours, tested the DS8000 key retrieval, and all was working fine.  The 
boss was getting antsy to get to the airport and fly home, but I said, 
shouldn't I call the customer and make sure he can remotely access the 
unit?  "No, it'll work fine. Take me to the airport and then drive to 
Austin" (my next stop).  Well, we all know what happened on my way to 
Austin :)


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

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I've always felt that a professional should be willing and able to learn new 
tools while continuing to use old tools when appropriate.


--
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: Saturday, January 8, 2022 1:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad programming features (Re: ... Re: Top 8 Reasons for using 
Python instead of REXX for z/OS

I looked at your list and I am happy to see that these include the things you 
find important. JS is undeniably a big factor but “the good parts” is a thin 
booklet. As is groovy - slow and nevery had any appeal to me, just looks messy. 
I quite like Ruby as an idea but slow as molasses.

Today I looked at Lua, and although quite elegant, small and snappy, I am 
really disappointed that this is one of those languages that gives you wrong 
answers for numeric problems and having unicode support in a utf8 library that 
is different from the string functions - that is just funny. I am not implying 
that all Rexx implementations shine in this regard, but that is just neglect. 
NetRexx does, however, as it does in unlimited decimal precision arithmetic.

Of course NetRexx can use the Java stream API for functional programming. That 
remark is just as odd as ‘it only has one type’. The fact that it is from 1995 
and can use features that only appeared in Java 8 - personally I find that 
telling about the quality of the design. But I am not telling you that you need 
to like it - like the way we are told that we now need to like Python more than 
Rexx, while it cannot do what we need to do - for all the wrong reasons.

Looking at your list of requirements I think Scheme had it quite covered. Some 
of them are gimmicky and some seem useful. None of them address the core 
qualities of the mainframe, which are Channels, packed decimal, DB2, CICS and 
COBOL (as long as you forbid dynamic memory).

I think the discussion has strayed too much from what sparked it, which is a 
hitpiece with 8 untruths about Python and Rexx. Yes we like all languages to be 
available, and well maintained on z/OS. Please provide interfaces and 
precompilers for the main infrastructure. It is remarkably odd that IBM does 
not invest in the things that made the platform what it is, but it is not my 
problem. If the message is that the mainframe now can run the same software as 
the Raspberry Pi or your generic AWS instance, so be it.

I think you will find that other people are emotionally attached to their tools 
and programming languages, it is a human thing. Also, I found that not all 
people can easily switch between a large number of ever-changing programming 
languages; which is meant as a compliment to you; but nevertheless very true.

So I thank you all for a very interesting discussion.

Best regards,

René.

> On 7 Jan 2022, at 20:53, David Crayford  wrote:
>
> I could go on. Even Java supports functional programming since Java 1.8 and 
> which introduced the streams API. It's unusual to see and old school loop in 
> modern Java code. Even C++ has lambda's.
>
> I missed "closures" on my list which code hand in hand with "functions as 
> first class objects". Very powerful, for example in Kotlin you can easily 
> create type safe builders (DSLs) 
> https://secure-web.cisco.com/1aedK9sNhMsicx6WFcyhRBiH7c4eMJpCAiE7ok-xAjKbhEr66FBZH1Vb730F2CtN3H1tdxar_ZH0yMfbWMCh4oiqWLn0ZxZJczrQkYPW4EAAo7MFY3nMJCKA9JlPtPxcZj2DhShlt1sOx2zGx_XoxCRl0HUCqCUI7BD8YWTrwXlenB6PcCzQIeoRb_3waFnSE2Q2n3iO0uZYLaSJDc9HjeanJGkzdQIlsE5wWWwc42Ii8aPlRR6XInxrnlHVKDEJjd9jERdng9e1uXbiCSIJqFs7mucaSXJ8OY8zXTduMNv3QClTlK4-DyxlNd0PJ2O9k8KgwOlVoTRLKacsYeWzZPErVe41RzWHQL5m8zlxF0SrSHEzBPjTk8QY_cPgVM-YU4bLFurXCvUuGAlNo-tsg-5PljvZ1p3aZEEVW_obZ7GP8ufRNFfZqEKve92LD6PT-guf6I5VQDKIAvq2wjYWsDQ/https%3A%2F%2Fkotlinlang.org%2Fdocs%2Ftype-safe-builders.html.
> That's why I have absolutely no interest in NetRexx. I have far better 
> options on the JVM. I don't get emotionally attached to programming 
> languages. If a better one becomes available I will quite happily switch as I 
> have done

--
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: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

While REXX is my preferred scripting language, my passion is languages that are 
or were leading edge, e.g., Icon, SETL.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of W 
Mainframe [01304632a58d-dmarc-requ...@listserv.ua.edu]
Sent: Saturday, January 8, 2022 8:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad programming features (Re: ... Re: Top 8 Reasons for using 
Python instead of REXX for z/OS

If you are coding as professional, use the best language for that, if you are 
coding by passion, just use Rexx... :)
Dan


Sent from Yahoo Mail for iPhone


On Saturday, January 8, 2022, 8:50 AM, David Crayford  
wrote:

Nobody is denying the value of that code. I wrote thousands of lines of REXX  
code for system automation back in the 90s

I just can’t find a use case for writing new REXX code today. Everything had 
changed.

> On 8 Jan 2022, at 19:40, René Jansen  wrote:
>
> Well I am explicitly not reacting on another round of namecalling. What is 
> worrying to me is the denial of the value of all existing interfaces in the 
> OS and infrastructure to the standard scripting language on the platform, 
> making the ‘modernization’ effort a reduction to uss, which will be hated by 
> everybody used to Linux. But if the reaction consists of ‘unprofessional’, 
> I’m done.
>
>
>> On 8 Jan 2022, at 05:43, David Crayford  wrote:
>>
>> Why not compile lua to support utf8?
>>
>> Your unrelenting love of REXX worries me. it’s  the perfect example of 
>> personal preference over a functional requirement which is unprofessional 
>> and a red flag.
>>
 On 8 Jan 2022, at 14:57, René Jansen  wrote:
>>>
>>> I looked at your list and I am happy to see that these include the things 
>>> you find important. JS is undeniably a big factor but “the good parts” is a 
>>> thin booklet. As is groovy - slow and nevery had any appeal to me, just 
>>> looks messy. I quite like Ruby as an idea but slow as molasses.
>>>
>>> Today I looked at Lua, and although quite elegant, small and snappy, I am 
>>> really disappointed that this is one of those languages that gives you 
>>> wrong answers for numeric problems and having unicode support in a utf8 
>>> library that is different from the string functions - that is just funny. I 
>>> am not implying that all Rexx implementations shine in this regard, but 
>>> that is just neglect. NetRexx does, however, as it does in unlimited 
>>> decimal precision arithmetic.
>>>
>>> Of course NetRexx can use the Java stream API for functional programming. 
>>> That remark is just as odd as ‘it only has one type’. The fact that it is 
>>> from 1995 and can use features that only appeared in Java 8 - personally I 
>>> find that telling about the quality of the design. But I am not telling you 
>>> that you need to like it - like the way we are told that we now need to 
>>> like Python more than Rexx, while it cannot do what we need to do - for all 
>>> the wrong reasons.
>>>
>>> Looking at your list of requirements I think Scheme had it quite covered. 
>>> Some of them are gimmicky and some seem useful. None of them address the 
>>> core qualities of the mainframe, which are Channels, packed decimal, DB2, 
>>> CICS and COBOL (as long as you forbid dynamic memory).
>>>
>>> I think the discussion has strayed too much from what sparked it, which is 
>>> a hitpiece with 8 untruths about Python and Rexx. Yes we like all languages 
>>> to be available, and well maintained on z/OS. Please provide interfaces and 
>>> precompilers for the main infrastructure. It is remarkably odd that IBM 
>>> does not invest in the things that made the platform what it is, but it is 
>>> not my problem. If the message is that the mainframe now can run the same 
>>> software as the Raspberry Pi or your generic AWS instance, so be it.
>>>
>>> I think you will find that other people are emotionally attached to their 
>>> tools and programming languages, it is a human thing. Also, I found that 
>>> not all people can easily switch between a large number of ever-changing 
>>> programming languages; which is meant as a compliment to you; but 
>>> nevertheless very true.
>>>
>>> So I thank you all for a very interesting discussion.
>>>
>>> Best regards,
>>>
>>> René.
>>>
> On 7 Jan 2022, at 20:53, David Crayford  wrote:

 I could go on. Even Java supports functional programming since Java 1.8 
 and which introduced the streams API. It's unusual to see and old school 
 loop in modern Java code. Even C++ has lambda's.

 I missed "closures" on my list which code hand in hand with "functions as 
 first class objects". Very powerful, for example in Kotlin you can easily 
 create type safe builders (DSLs) 
 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I'm a TSO bigot, but my main objections to Unix System Services (née MVS 
OpenEdition) have not been based ondislike for Unix. Rather, I saw two major 
flaws in the goals.

In the Unix world, there are requirements for certification, but there is a 
large ecology of tools that users have come to expect. My first impression of 
MVS-OE was that IBM was only interested in the tools required foor 
certification. That has gotten better over the years, but z/OS still doesn't 
come with all the tools that Unix users expect.

IBM failed to seamlessly integrate Unix System Services with legacy services. 
Some exaples

   * Adding stream I/O to REXX only for Unix
   * The open() vs fopen() issue
   * Concatenating PDS(E) and directories


--
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: Saturday, January 8, 2022 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad programming features (Re: ... Re: Top 8 Reasons for using 
Python instead of REXX for z/OS

I think USS is very interesting, a great technical accomplishment, but it is 
generally agreed that the differences with other Unices made life different for 
people wanting to use it in anger for applications. It gives z/OS the Unix 
system calls in a library that wraps MVS supervisor calls, and it offers an 
hierarchical filesystem in something that looks like a VSAM LDS to MVS. 
Differences with other Unices, like being EBCDIC based have been mostly masked, 
but will hit everybody sometimes, and did not make it less complicated. A lot 
of work was done on Rexx so it can address the conventional environments, and 
it even brought linein and lineout as standard components to MVS - a tender 
point un the Rexx world, because Endicott (it was?) closed the window on Rexx 
just before these became available for z/OS. These were available in a separate 
library that most often was not installed by sysprogs ‘because management’.

Often seen wrongly by application people as a Unix ‘emulator’; USS is part of 
z/OS and makes it POSIX compliant. You can write a program that calls Unix 
services and MVS SVC’s (using their macros, preferably) in the same CSECT. Why 
you would do that is another question. It is truly a work of art, but all the 
younger people at sites where I needed to fight fires were pretty negative, and 
it always takes a lot of explaining. Also, wrong defaults on Java memory made 
it look terrible at first sight. Also, traditional sysprogs also refused to 
install bash and git and RACF-protected the C compiler, in a repeat of what 
happened when TCP hit the platform, making it even less popular, with no 
tab-expansion of filenames (tcsh cam first, and could do that, but also not 
very popular).

This reminds me of OS/2’s “a better DOS than DOS”, which was absolutely true, 
but did not bring the marketing people what they expected. It would have been 
better to give away the C++ compiler (CSET/2) for free, astroturf the fora, and 
bribe the application developers and hardware people, like some other company 
did. BTW for a very short time I had the official job title ‘OS/2 Systems 
Programmer’ and it was a happy time solving lots of problems with the kernel 
debugger on the second machine. That stopped the Token Ring if it hit a 
breakpoint at the wrong moment.

Best regards,

René.

> On 8 Jan 2022, at 09:58, PINION, RICHARD W.  wrote:
>
> I've not followed this thread.  But, one thing I saw in your latest reply, 
> about z/OS USS/Open Edition and Linux.  USS/Open Edition is/was a port of 
> UNIX.  I remember the IBM marketing presentation about OE/USS, the local IBM 
> rep stated "more UNIX than UNIX".


--
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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I would, in general, not compare any programming language to any natural 
language. The evolution of natural languages was driven by the types of 
challenges we faced over the millenia, and those did not require expressing 
algorithms and data structures. COBOL may be a terrible language, but it is 
much better than English for, e.g., describing a record layout.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bill Ogden [og...@us.ibm.com]
Sent: Saturday, January 8, 2022 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Before saying something like "COBOL is terrible compared to the English
language" try studying a remote analysis of common, everyday English
sentences --- the study based on a wholly different language base. The
order of words in English, and the exact meaning of the order in a
particular sentence situation,  can be complex and writing a "syntax
definition" for how English "must" be written --- again based on a very
different language and cultural set  --- can be very very difficult.

My computer uses go back to 1966 (1620, 1410, 1401, 7040, 7090/94 before
going to S/360) and I installed OS/360 Release 1 (after attending a
two-week TSS session!). And, I am not a COBOL programmer! (Except for a
bit of Fortran and PL/1, a long long time ago, I think in assembly
language.) Some of the early COBOL programs I saw were fairly readable --
even to someone with only a bit of data handling experience. Possibly this
was due to the early nature of COBOL programmers and to the rather small
and simple (in modern terms) COBOL programs involved.

Over the years we have all seen an almost countless number of  "new,
modern, super, will-replace-everything" languages. Very few maintained
upward compatibility as their basic implementation shifted and not many
have survived as  the  "new, modern, super, will-replace-everything"
language of today.

Interesting discussion!

Bill


--
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: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> Well all of your languages miss the support for the message paradigm.

What do you mean by "the message paradigm"? How does it differ from sending 
method invocation and response messages to objects?

> NetRexx follows the Rexx philosophy, 

FSVO follows. NetRexx doesn't have the concept of routing bare expressions to 
the default environment. In fact, it doesn't have the address statement at all, 
unless there has been a subsequent addition to the language.


--
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: Saturday, January 8, 2022 1:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for 
using Python instead of REXX for z/OS

On 08.01.2022 01:52, David Crayford wrote:
> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:
>>> Here is my list of must haves for a scripting language. Does REXX or ooRexx 
>>> meet the requirements?
>>>
>>> 1. Short circuit evaluation
>>> 2. Functions as first class objects
>>> 3. Mutli-threading
>>> 4. Dynamically typed, preferably with type hints
>>> 5. co-routintes
>>> 6. A module system
>>> 7. Support for object oriented programming
>>> 8. Regular expressions
>>> 9. Libraries for web programming, pegs, JSON/YAML parsing etc
>> You also mentioned in your follow up: "Forgot to mention. Support for 
>> functional programming map,
>> reduce, filter etc."
>>
>> This list reads a little bit like a wish list for concepts found in 
>> different programming languages.
>> Sometimes such features are specific for a particular language (e.g. 
>> functional programming) and
>> then sometimes made available in other languages.
>
> Umm, nope. Here is a list of programming languages that I use that support 
> all of my requirements.
>
>  * Javascript
>  * Typescript
>  * Lua
>  * Python
>  * Ruby
>  * Kotlin
>  * Groovy
>
> I could go on. Even Java supports functional programming since Java 1.8 and 
> which introduced the
> streams API. It's unusual to see and old school loop in modern Java code. 
> Even C++ has lambda's.
>
> I missed "closures" on my list which code hand in hand with "functions as 
> first class objects".
> Very powerful, for example in Kotlin you can easily create type safe builders 
> (DSLs)
> https://secure-web.cisco.com/184LYywUwz18zPXrw7R3oMpn_maLcleRsoPwaLTyxGMhAKBc1E-pLGTbyzTIra9a6G7JV6pUmBZUHkAo2UInwNdJJdNaxexsAei-4o0OBmJrvLNLgqMMipW5AIrczA1DtF0n5kWp9cSpd-4R45rETdC1bFjZxgjwlfVUVgQmixi93TQnAhq-rYxEjs4NPKRhfYWkQbSLt_vfkLPMTdI4Jp9VJH32b02HWwDWqNEN-jGLmG5MOTD0Qc6PAOxz8Sd6uebDV1qwldTC_x0FMN4s_LBUym7Ut9HrALVgLN-iVEcjwN1mKPsHzsrd_sGjPVbMR5PHLyiC6n1A62fElgFSJgJ1FYRiQL4gyWwtbbuZwLRFSyDzDRK3EqwUW-9OpT5DSjc6BRTopk5xLyzlTyghw7CV2VMbJlgvY9WUpD_i_Z3mj8G5l-wnRL8UxLVflk08QbtBGvO-Ki50IwVyXYafjfw/https%3A%2F%2Fkotlinlang.org%2Fdocs%2Ftype-safe-builders.html.

Well all of your languages miss the support for the message paradigm. So, does 
this invalidate all
of your languages? Probably not, as each may serve and prove useful for the one 
or other
purpose/problem. However it means that e.g. in situations where the message 
paradigm becomes
helpful, none of your programming languages/skills qualify. (The same pattern 
you use in your
argument, just turned around a little bit. :) )

None of the above programming languages are human centric by design, such that 
it is not possible to
teach them as quickly as REXX or ooRexx and become productive quickly and 
relevant for as long as a
professional life lasts...

You must not overlook the fact, that IBM was very lucky in having a gentleman 
hired by the name of
Mike F. Cowlishaw who has turned out to be an ingenious language designer, and 
much more. The
history of how REXX got developed and how it became so successful also explains 
why it still is in
professional use and still serves as a beautiful language to teach and to use.

(And as you may know, Mike F. Cowlishaw has been very seminal in quite 
different IT related areas.)


> That's why I have absolutely no interest in NetRexx. I have far better 
> options on the JVM.

Well, you mention in another post that you were/are an expert REXX programmer, 
love Lua, use Python
in your shop because of your teams coming with that knowledge from the 
colleges, but nowadays you
would mainly code in Java/Kotlin. Kudos!

What appears to be a little bit strange with such a background is that you have 
obviously never
really assessed NetRexx, as otherwise you could not possibly have come to such 
wrong conclusions.

To explain:

  * Mike F. Cowlishaw's (see above) Java expertise has been impressive from the 
early days of Java
which many do not know

  * NetRexx got designed by Mike F. Cowlishaw, and as a matter of fact it is 
the first JVM language,
believe it or not, many years before others have appeared (and many years 
before .Net/clr
languages came 

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 09.01.2022 05:52, Wayne Bickerdike wrote:
> I couldn't find Netrexx at  (https://www.netrexx.org), I did find it here
> http://www.netrexx.org 
Ah, "http" instead of "https", sorry (wrote it from memory and did not test it) 
!
> I like it!

+1

---rony

... cut ...

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

Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 09.01.2022 03:19, David Crayford wrote:
> On 9/1/22 2:15 am, Rony G. Flatscher wrote:
>> On 08.01.2022 01:52, David Crayford wrote:
>>> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:

... cut ... 

>> Well all of your languages miss the support for the message paradigm.
>
> What on earth are you talking about? 

Hmm, this sounds quite emotional. :)


> Number 7 on my list is support for OO which implies message passing.

Well, this does not mean that the programming language supports the message 
paradigm. If it did it
would have an explicit "Message" class (like there are explicit classes like 
"Object", "Class",
"Method" and the like), hence messages are not FCOs. Compare this to languages 
like SmallTalk or ooRexx.

Maybe it is easier to grasp some of the ramifications by looking at the popular 
fluent pattern
(https://en.wikipedia.org/wiki/Fluent_interface) which needs to be explicitly 
programmed in
languages that do not support the message paradigm, but is "freely" ;) 
available in languages like
Smalltalk and ooRexx.

... cut ...


>>> That's why I have absolutely no interest in NetRexx. I have far better 
>>> options on the JVM.
>> Well, you mention in another post that you were/are an expert REXX 
>> programmer, love Lua, use Python
>> in your shop because of your teams coming with that knowledge from the 
>> colleges, but nowadays you
>> would mainly code in Java/Kotlin. Kudos!
>>
>> What appears to be a little bit strange with such a background is that you 
>> have obviously never
>> really assessed NetRexx, as otherwise you could not possibly have come to 
>> such wrong conclusions.
>
> Why would I invest time into NetRexx. How many NetRexx jobs are there out 
> there? 

Why would that be important?
(Besides, due to NetRexx' design philosophy there is not really much time to 
invest, especially if
you have a good REXX background such that you understand already the purpose of 
e.g. the keyword
statement TRACE; you may want to try to trace a program written in Java or 
Kotlin the way NetRexx
allows for.)

The question to ask is: can NetRexx be used to (quickly) create reliable 
professional applications?
The answer is simple: yes. It is available, it is proven, it has been 
successfully used to create
professional programs. (In case you must supply Java source code, you still can 
use NetRexx and have
it eject Java source code.)

NetRexx creates normal, genuine Java classes as does the Java compiler or the 
Kotlin (or the Groovy
...) compiler. All the compiled Java classes (Java bytecode) can interoperate, 
with each other so it
is possible to use NetRexx compiled Java classes from Java and Kotlin (and 
Groovy ...) and the other
way round, NetRexx can use Java classes compiled from Java or Kotlin (or Groovy 
...) programs and
the like. Therefore it does not matter whether everyone on earth is using 
NetRexx or only a single
person.

The question then is: what is the problem at hand, what programming languages 
qualify best to solve
it? And NetRexx can be used for most problem domains, no need to use a language 
with special
features that are not needed to solve the problem at hand. 

If I were you (with your background), I would seriously look into NetRexx, 
rather then ignore it.
You for sure would quickly become able to solve most of your programming 
problems with it,
exploiting your REXX and Java knowledge. OTOH, if you do not want to look into 
it, that is fine too,
of course, but then, please do not badmouth technologies you simply have no 
experience with.


> Kotlin is not only a first class language for server side it is also the 
> language of choice for
> building Android applications. 

Kotlin and Android is interesting:  Android is a Linux-based operating system 
for which Android
applications have been mostly created in Java for more than a decade, without 
the public even
realizing it (even today). This is the reason why Oracle has been suing Google 
over the use of Java,
although Google used an open source Java implementation from the Apache 
software foundation. Google
used IntelliJ for developing Java applications for Android and even forked 
IntelliJ. The IntelliJ
people came up with Kotlin a few years ago, which is a JVM language compiling 
to Java classes (Java
bytecode), and Google embraced it.

AFAIK most of the Android applications get still created with Java as it takes 
time to learn Kotlin
and as long as Kotlin does not really add great value to the application domain 
it is cheaper to
stick to Java (saving learning curves and new type of coding errors). Besides, 
if you witness the
evolution of the Java language you see that it is not really necessary to 
switch to Kotlin as Java
gains step by step those concepts that programmers find really helpful.

Here a comparison of Java with Kotlin using your Google trends (borrowing your 
idea from below):
.


> Who uses NetRexx? Are there any example 

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Wayne Bickerdike]

I couldn't find Netrexx at  (https://www.netrexx.org), I did find it here
http://www.netrexx.org 

I like it!

On Sun, Jan 9, 2022 at 1:20 PM David Crayford  wrote:

> On 9/1/22 2:15 am, Rony G. Flatscher wrote:
> > On 08.01.2022 01:52, David Crayford wrote:
> >> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:
>  Here is my list of must haves for a scripting language. Does REXX or
> ooRexx meet the requirements?
> 
>  1. Short circuit evaluation
>  2. Functions as first class objects
>  3. Mutli-threading
>  4. Dynamically typed, preferably with type hints
>  5. co-routintes
>  6. A module system
>  7. Support for object oriented programming
>  8. Regular expressions
>  9. Libraries for web programming, pegs, JSON/YAML parsing etc
> >>> You also mentioned in your follow up: "Forgot to mention. Support for
> functional programming map,
> >>> reduce, filter etc."
> >>>
> >>> This list reads a little bit like a wish list for concepts found in
> different programming languages.
> >>> Sometimes such features are specific for a particular language (e.g.
> functional programming) and
> >>> then sometimes made available in other languages.
> >> Umm, nope. Here is a list of programming languages that I use that
> support all of my requirements.
> >>
> >>   * Javascript
> >>   * Typescript
> >>   * Lua
> >>   * Python
> >>   * Ruby
> >>   * Kotlin
> >>   * Groovy
> >>
> >> I could go on. Even Java supports functional programming since Java 1.8
> and which introduced the
> >> streams API. It's unusual to see and old school loop in modern Java
> code. Even C++ has lambda's.
> >>
> >> I missed "closures" on my list which code hand in hand with "functions
> as first class objects".
> >> Very powerful, for example in Kotlin you can easily create type safe
> builders (DSLs)
> >> https://kotlinlang.org/docs/type-safe-builders.html.
> > Well all of your languages miss the support for the message paradigm.
>
> What on earth are you talking about? Number 7 on my list is support for
> OO which implies message passing.
>
>
> >   So, does this invalidate all
> > of your languages? Probably not, as each may serve and prove useful for
> the one or other
> > purpose/problem. However it means that e.g. in situations where the
> message paradigm becomes
> > helpful, none of your programming languages/skills qualify. (The same
> pattern you use in your
> > argument, just turned around a little bit. :) )
> >
> > None of the above programming languages are human centric by design,
> such that it is not possible to
> > teach them as quickly as REXX or ooRexx and become productive quickly
> and relevant for as long as a
> > professional life lasts...
> >
> > You must not overlook the fact, that IBM was very lucky in having a
> gentleman hired by the name of
> > Mike F. Cowlishaw who has turned out to be an ingenious language
> designer, and much more. The
> > history of how REXX got developed and how it became so successful also
> explains why it still is in
> > professional use and still serves as a beautiful language to teach and
> to use.
> >
> > (And as you may know, Mike F. Cowlishaw has been very seminal in quite
> different IT related areas.)
> >
> >
> >> That's why I have absolutely no interest in NetRexx. I have far better
> options on the JVM.
> > Well, you mention in another post that you were/are an expert REXX
> programmer, love Lua, use Python
> > in your shop because of your teams coming with that knowledge from the
> colleges, but nowadays you
> > would mainly code in Java/Kotlin. Kudos!
> >
> > What appears to be a little bit strange with such a background is that
> you have obviously never
> > really assessed NetRexx, as otherwise you could not possibly have come
> to such wrong conclusions.
>
> Why would I invest time into NetRexx. How many NetRexx jobs are there
> out there? Kotlin is not only a first class language for server side it
> is also the language of choice for building
> Android applications. Who uses NetRexx? Are there any example
> applications that you can cite? REXX has fallen off a cliff
> https://trends.google.com/trends/explore?date=all=%2Fm%2F06g3m.
> It's niche is the mainframe where it is an important and useful
> language. The reason IBM are porting languages like Python to z/OS is to
> keep the platform relevant. A lot of new products coming online
> in the future have a dependency on Python. Ansible etc are written in
> Python. Ansible playbooks are basically built using Jinja2 templates.
> Python skills will be in demand on z/OS.
>
>
> >
> > To explain:
> >
> >* Mike F. Cowlishaw's (see above) Java expertise has been impressive
> from the early days of Java
> >  which many do not know
> >
> >* NetRexx got designed by Mike F. Cowlishaw, and as a matter of fact
> it is the first JVM language,
> >  believe it or not, many years before others have appeared (and many
> years before .Net/clr
> >  languages came 

Re: Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 9/1/22 2:15 am, Rony G. Flatscher wrote:

On 08.01.2022 01:52, David Crayford wrote:

On 7/1/22 7:53 pm, Rony G. Flatscher wrote:

Here is my list of must haves for a scripting language. Does REXX or ooRexx 
meet the requirements?

1. Short circuit evaluation
2. Functions as first class objects
3. Mutli-threading
4. Dynamically typed, preferably with type hints
5. co-routintes
6. A module system
7. Support for object oriented programming
8. Regular expressions
9. Libraries for web programming, pegs, JSON/YAML parsing etc

You also mentioned in your follow up: "Forgot to mention. Support for 
functional programming map,
reduce, filter etc."

This list reads a little bit like a wish list for concepts found in different 
programming languages.
Sometimes such features are specific for a particular language (e.g. functional 
programming) and
then sometimes made available in other languages.

Umm, nope. Here is a list of programming languages that I use that support all 
of my requirements.

  * Javascript
  * Typescript
  * Lua
  * Python
  * Ruby
  * Kotlin
  * Groovy

I could go on. Even Java supports functional programming since Java 1.8 and 
which introduced the
streams API. It's unusual to see and old school loop in modern Java code. Even 
C++ has lambda's.

I missed "closures" on my list which code hand in hand with "functions as first 
class objects".
Very powerful, for example in Kotlin you can easily create type safe builders 
(DSLs)
https://kotlinlang.org/docs/type-safe-builders.html.

Well all of your languages miss the support for the message paradigm.


What on earth are you talking about? Number 7 on my list is support for 
OO which implies message passing.




  So, does this invalidate all
of your languages? Probably not, as each may serve and prove useful for the one 
or other
purpose/problem. However it means that e.g. in situations where the message 
paradigm becomes
helpful, none of your programming languages/skills qualify. (The same pattern 
you use in your
argument, just turned around a little bit. :) )

None of the above programming languages are human centric by design, such that 
it is not possible to
teach them as quickly as REXX or ooRexx and become productive quickly and 
relevant for as long as a
professional life lasts...

You must not overlook the fact, that IBM was very lucky in having a gentleman 
hired by the name of
Mike F. Cowlishaw who has turned out to be an ingenious language designer, and 
much more. The
history of how REXX got developed and how it became so successful also explains 
why it still is in
professional use and still serves as a beautiful language to teach and to use.

(And as you may know, Mike F. Cowlishaw has been very seminal in quite 
different IT related areas.)



That's why I have absolutely no interest in NetRexx. I have far better options 
on the JVM.

Well, you mention in another post that you were/are an expert REXX programmer, 
love Lua, use Python
in your shop because of your teams coming with that knowledge from the 
colleges, but nowadays you
would mainly code in Java/Kotlin. Kudos!

What appears to be a little bit strange with such a background is that you have 
obviously never
really assessed NetRexx, as otherwise you could not possibly have come to such 
wrong conclusions.


Why would I invest time into NetRexx. How many NetRexx jobs are there 
out there? Kotlin is not only a first class language for server side it 
is also the language of choice for building
Android applications. Who uses NetRexx? Are there any example 
applications that you can cite? REXX has fallen off a cliff 
https://trends.google.com/trends/explore?date=all=%2Fm%2F06g3m.
It's niche is the mainframe where it is an important and useful 
language. The reason IBM are porting languages like Python to z/OS is to 
keep the platform relevant. A lot of new products coming online
in the future have a dependency on Python. Ansible etc are written in 
Python. Ansible playbooks are basically built using Jinja2 templates. 
Python skills will be in demand on z/OS.





To explain:

   * Mike F. Cowlishaw's (see above) Java expertise has been impressive from 
the early days of Java
 which many do not know

   * NetRexx got designed by Mike F. Cowlishaw, and as a matter of fact it is 
the first JVM language,
 believe it or not, many years before others have appeared (and many years 
before .Net/clr
 languages came into existence too)

   * NetRexx allows REXX programmers to take advantage of their Rexx skills as 
NetRexx follows the
 Rexx philosophy, or with other words REXX programmers can quite easily 
create real Java programs
 using NetRexx without a need in coding in Java itself, interestingly REXX 
programmers do not
 know and realize that (including yourself it seems)

   * NetRexx programmers, if need be, can create Java classes and Java methods 
that other programs
 can exploit and use, hence it becomes possible to create Java class 
libraries 

Re: VBA -> ooRexx and ooRexx -> VBA (Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bob Bridges]

I've mentioned before that once I dropped my first major, I floundered around a 
little before settling on Accounting.  I had a best friend who was moving from 
Pennsylvania to southern California about this time, and he came by way of 
North Carolina to give me a visit on his way out there.  He'd already learned 
something about programming, so I asked him to describe it for me.

I guess he didn’t care for it all that much, because it sounded boring.  But in 
the end I decided that an accountant in the '70s really must know something 
about computers, so I signed up for a summer course in PL/1.

I caught fire almost immediately, and have been a programmer at heart ever 
since, no matter what my job title was.  Looking back on that time, I said at 
first "I was made to do this".  Later on I said "I had a good teacher, but 
really I was made to do this."  Nowadays I still think I was made to do it, but 
I linger much, much longer on "I had a good teacher".  I honor that man.

One important feature of that class is that he had us writing programs the very 
first day.  If you're going to write a program to compare two numbers and tell 
you which one is larger, he asked us, what's the first thing you have to do?  
We all made bad guesses with verbs like "print" and "compare" and "decide", and 
after a few minutes he pointed out that the first thing you have to do is "get 
the first number".  He went on from there, writing the program on the board.  
Remember this was a PL/1 class -- actually a subset of PL/1 called 
"seven-statement PL/C", I think -- so the verb GET is native PL/1; it does 
STREAM input.  The rest of the explanation likewise used PL/1 keywords, so we 
didn't notice at first that we were learning PL/1 syntax; it looked and felt 
like ordinary logical instructions.

We were repairing to the computer center and typing up our own attempts at PL/C 
programs before a week had gone by.  I forget how we ran them; I suppose he 
must have handed out some JCL cards that we could put around our own cards and 
hand them to the HASP operator to submit.

Halfway through the summer that class was ended, but I was hooked and started 
spending much of my time at the computer center (much to the disgust of my 
fiancée) writing my own programs and teaching myself BASIC and FORTRAN.  They 
offered me a student job for the fall semester; I finished my degree in 
Accounting but I've never done anything but computers afterward.

I say all this partly because I'm afflicted with logorrhea, but also because 
while I was working at the computer center (mostly my job was to help fellow 
students diagnose simple compile-time errors) I learned that some folks taking 
COBOL were six weeks into the class, getting lots and lots of theory, before 
they wrote their first line of code, and they were halfway through the semester 
before learning about loops.  In my view this is a TERR9IBLE way to teach 
coding!  I have to admit it isn't clear to me how COBOL could be taught the 
same way as PL/1, since there's so much crap you have to write before you can 
get into the procedure division, but still...!  I doubt my enthusiasm would 
have awakened at that introduction.

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

/* The people most apt to want the pleasures of marriage without the 
obligations are, as you may have observed, young men.  Men complain about 
marriage.  Women don't complain about marriage; they complain about men.  
-Joseph Sobran */

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

Ad NetRexx (Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 08.01.2022 01:52, David Crayford wrote:
> On 7/1/22 7:53 pm, Rony G. Flatscher wrote:
>>> Here is my list of must haves for a scripting language. Does REXX or ooRexx 
>>> meet the requirements?
>>>
>>> 1. Short circuit evaluation
>>> 2. Functions as first class objects
>>> 3. Mutli-threading
>>> 4. Dynamically typed, preferably with type hints
>>> 5. co-routintes
>>> 6. A module system
>>> 7. Support for object oriented programming
>>> 8. Regular expressions
>>> 9. Libraries for web programming, pegs, JSON/YAML parsing etc
>> You also mentioned in your follow up: "Forgot to mention. Support for 
>> functional programming map,
>> reduce, filter etc."
>>
>> This list reads a little bit like a wish list for concepts found in 
>> different programming languages.
>> Sometimes such features are specific for a particular language (e.g. 
>> functional programming) and
>> then sometimes made available in other languages.
>
> Umm, nope. Here is a list of programming languages that I use that support 
> all of my requirements.
>
>  * Javascript
>  * Typescript
>  * Lua
>  * Python
>  * Ruby
>  * Kotlin
>  * Groovy
>
> I could go on. Even Java supports functional programming since Java 1.8 and 
> which introduced the
> streams API. It's unusual to see and old school loop in modern Java code. 
> Even C++ has lambda's.
>
> I missed "closures" on my list which code hand in hand with "functions as 
> first class objects".
> Very powerful, for example in Kotlin you can easily create type safe builders 
> (DSLs)
> https://kotlinlang.org/docs/type-safe-builders.html.

Well all of your languages miss the support for the message paradigm. So, does 
this invalidate all
of your languages? Probably not, as each may serve and prove useful for the one 
or other
purpose/problem. However it means that e.g. in situations where the message 
paradigm becomes
helpful, none of your programming languages/skills qualify. (The same pattern 
you use in your
argument, just turned around a little bit. :) )

None of the above programming languages are human centric by design, such that 
it is not possible to
teach them as quickly as REXX or ooRexx and become productive quickly and 
relevant for as long as a
professional life lasts...

You must not overlook the fact, that IBM was very lucky in having a gentleman 
hired by the name of
Mike F. Cowlishaw who has turned out to be an ingenious language designer, and 
much more. The
history of how REXX got developed and how it became so successful also explains 
why it still is in
professional use and still serves as a beautiful language to teach and to use.

(And as you may know, Mike F. Cowlishaw has been very seminal in quite 
different IT related areas.)


> That's why I have absolutely no interest in NetRexx. I have far better 
> options on the JVM. 

Well, you mention in another post that you were/are an expert REXX programmer, 
love Lua, use Python
in your shop because of your teams coming with that knowledge from the 
colleges, but nowadays you
would mainly code in Java/Kotlin. Kudos!

What appears to be a little bit strange with such a background is that you have 
obviously never
really assessed NetRexx, as otherwise you could not possibly have come to such 
wrong conclusions.

To explain:

  * Mike F. Cowlishaw's (see above) Java expertise has been impressive from the 
early days of Java
which many do not know

  * NetRexx got designed by Mike F. Cowlishaw, and as a matter of fact it is 
the first JVM language,
believe it or not, many years before others have appeared (and many years 
before .Net/clr
languages came into existence too)

  * NetRexx allows REXX programmers to take advantage of their Rexx skills as 
NetRexx follows the
Rexx philosophy, or with other words REXX programmers can quite easily 
create real Java programs
using NetRexx without a need in coding in Java itself, interestingly REXX 
programmers do not
know and realize that (including yourself it seems)

  * NetRexx programmers, if need be, can create Java classes and Java methods 
that other programs
can exploit and use, hence it becomes possible to create Java class 
libraries not in Java, but
in NetRexx only which can be programmed by REXX programmers (whereas the 
learning curve for Java
is probably too steep)

To demonstrate the "difficulty" of creating and understanding NetRexx programs, 
here a simple
example which probably everyone on this list can understand without any further 
explanation, so here
is a NetRex program:

parse version v /* get the NetRexx version*/
say "parse version:" v
parse source s  /* get the source information */
say "parse source: " s

say "1/3:" 1/3  /* demo Rexx arithmetics  */
numeric digits 100
say "numeric digits now:" digits
say "1/3:" 1/3
say

numeric digits 1000
say "numeric digits now:" digits
sum=0
loop i=1 to 1
   sum=sum+1
   sum=sum*i
end
   

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bill Ogden]

Before saying something like "COBOL is terrible compared to the English 
language" try studying a remote analysis of common, everyday English 
sentences --- the study based on a wholly different language base. The 
order of words in English, and the exact meaning of the order in a 
particular sentence situation,  can be complex and writing a "syntax 
definition" for how English "must" be written --- again based on a very 
different language and cultural set  --- can be very very difficult. 

My computer uses go back to 1966 (1620, 1410, 1401, 7040, 7090/94 before 
going to S/360) and I installed OS/360 Release 1 (after attending a 
two-week TSS session!). And, I am not a COBOL programmer! (Except for a 
bit of Fortran and PL/1, a long long time ago, I think in assembly 
language.) Some of the early COBOL programs I saw were fairly readable -- 
even to someone with only a bit of data handling experience. Possibly this 
was due to the early nature of COBOL programmers and to the rather small 
and simple (in modern terms) COBOL programs involved.

Over the years we have all seen an almost countless number of  "new, 
modern, super, will-replace-everything" languages. Very few maintained 
upward compatibility as their basic implementation shifted and not many 
have survived as  the  "new, modern, super, will-replace-everything" 
language of today.

Interesting discussion!

Bill


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

Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 07.01.2022 17:38, Seymour J Metz wrote:
> Some language purists claim that the messages are an intrinsic part of 
> object-oriented programming. Check the documentation for Concurrency or for 
> the REPLY instruction for some context.
>
> I always thought that object-oriented programming started with Simula 67 by 
> way of Smalltalk, but according to wiki some of the concepts go back toDoug 
> Ross's Automated Engineering Design/Algol Extended for Design. (AED).
>
>  * 
>  * 
>  * 
>  * 
>  * 

Smalltalk is an interesting and important language as it has been having a 
tremendous impact on the
proliferation of the terms such as "object" or "object orientation"
(https://en.wikipedia.org/wiki/Smalltalk). You will also notice that Smalltalk 
is based on the
message paradigm, which is a great paradigm as it helps to abstract from 
implementations, allowing
them to be regarded as black boxes (which inner workings one does not need to 
know), only the
protocol (the set of messages understood, i.e. the set of method routines that 
can be invoked) need
to be known.

In this context it may be interesting to read the following about Alan Kay (cf.
https://en.wikipedia.org/wiki/Alan_Kay):

"... Along with some colleagues at PARC, Kay is one of the fathers of the 
idea of
object-oriented programming 
 (OOP),
which he named. Some of the original object-oriented concepts, including 
the use of the words
'object' and 'class', had been developed for Simula 
 67 at
the Norwegian Computing Center 
. Later
he said:

I'm sorry that I long ago coined the term "objects" for this topic 
because it gets many
people to focus on the lesser idea. The big idea is "messaging".

..."

ooRexx is another language that makes the message paradigm available, easying 
the interaction with
different systems (on different systems) considerably.

---rony


> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Bob Bridges [robhbrid...@gmail.com]
> Sent: Friday, January 7, 2022 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python 
> instead of REXX for z/OS
>
> When I first started learning ooREXX (not that long ago, and I still don't 
> know it well) I read that bit about "messages" that are apparently sent to 
> methods and properties and was confused.  My only object-oriented language at 
> the time was VB (the VBA and VBS varieties), and I thought of methods as 
> merely specialized function calls.
>
> Really I still do, I guess.  I told myself provisionally that the tilde in 
> ooREXX is simply the equivalent of the period in a VBA method or property 
> reference, and although I'm pretty sure that isn't the whole story I was at 
> least able to continue on that basis.  I keep reading descriptions like the 
> below, though, thinking that more will sink in eventually.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* This sad little lizard told me that he was a brontosaurus on his mother's 
> side.  I did not laugh; people who boast of ancestry often have little else 
> to sustain them.  Humoring them costs nothing and adds to happiness in a 
> world in which happiness is always in short supply.  -from the Notebooks of 
> Lazarus Long */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Rony G. Flatscher
> Sent: Friday, January 7, 2022 07:57
>
>   * The tilde (~) is the ooRexx message operator; one can send messages to 
> any value/object/instance
> in an ooRexx program. Left of the tilde is the receiving 
> value/object/instance/receiver (these
> are synonyms), right of it the name of a method routine that conceptually 
> the receiver is
> supposed to look up and invoke on behalf of the programmer. If the 
> invoked method routine
> returns a result one can immediately send it a message too, if needed.
>


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

VBA -> ooRexx and ooRexx -> VBA (Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Rony G. Flatscher]

On 07.01.2022 16:16, Bob Bridges wrote:
> When I first started learning ooREXX (not that long ago, and I still don't 
> know it well) I read that bit about "messages" that are apparently sent to 
> methods and properties and was confused.  My only object-oriented language at 
> the time was VB (the VBA and VBS varieties), and I thought of methods as 
> merely specialized function calls.
>
> Really I still do, I guess.  I told myself provisionally that the tilde in 
> ooREXX is simply the equivalent of the period in a VBA method or property 
> reference, and although I'm pretty sure that isn't the whole story I was at 
> least able to continue on that basis.  I keep reading descriptions like the 
> below, though, thinking that more will sink in eventually.

That is a great stance! :)

When teaching ooRexx (the course is called "Business Programming"), in the 
middle of the semester
(after two months, 4 hours per week) the students arrive at writing ooRexx 
programs against Windows
and MS Office. They will propose three little projects (controlling three 
Windows applications, one
must not be from Microsoft, from a single ooRexx script that creates value, 
solves a specific
problem) of which one gets picked which they need to implement within a week 
and present it.

Now, newcomers who have never been exposed to programming and those who learned 
some programming
already usually have never worked with OLE and scripting Windows applications 
via OLE. OTOH in the
Windows world VBA is known, popular because of MS Office and those application 
for which VBA got
licensed from MS. Given the huge market share for so many years there are 
incredibly many VBA code
snippets that demonstrate how to achieve some given functionality using VBA, 
such that by studying
the VBA code helps one to find the needed solution path rather quickly (which 
values/objects need to
be fetched, which attributes and method routines with what arguments etc. are 
needed and so on).

Also, they learn that for Windows applications that have VBA as a macro 
language, they can usually
employ some function "record macro" which will record all user generated events 
(key presses,
clicks, selections, etc.) and translate them into the respective VBA macro 
program when exercising a
matching "saving macro". One can then study the resulting VBA macro program to 
see what objects need
to be addressed how, which methods/functions need to be invoked in which 
sequence with what
arguments, etc.

---

The challenge then is: how to translate VBA code to ooRexx? And indeed, the 
simplest advice is to
change the VBA dot (.) to the ooRexx tilde (~), which in 90% of the cases is 
already everything one
needs to know!

The VBA dot (.) operator works like the C++ dot operator (e.g.
), it 
allows one to define a
path (path segments  concatenated by dots) to the embedded member of a 
structure, which can be a an
attribute/field/property, a method routine...

The ooRexx tilde (~) operator is the message operator. Replacing the VBA dot 
with the ooRexx message
operator causes the fetching of the referred to element by fetching each path 
segment one by the
other and in the end referring to the member.

In another post I mentioned that I had employed VBA in the past to teach 
Business administration
students how to automate and program (confined to the Windows world back then), 
that VBA is rather
difficult to teach despite carrying the name "BASIC" in its name. Some of the 
reasons are quite a
few idiosyncracies that need far too much explanation (i.e. too much time) such 
that at the end of
the course there was no time left for learning more about exploiting/applying 
the learned concepts.

Therefore I created a little presentation that documents the most important VBA 
features the
students would be confronted with (e.g. with VBA macro code from "record 
macro") and how they
translate to ooRexx (the students had learned REXX and ooRexx by then, i.e. in 
addition to the BIFs
the additional message paradigm which is available in all contexts). The same 
rules apply also the
other way around, i.e. in translating ooRexx code to VBA code in a Windows 
environment. Here the
link to these slides: 
, cf.
slides # 2 thru # 8 (slide # 8 also demonstrates the different possibilities 
one can exploit in
invoking routines in VBA).

Quite important to know are two things when mapping VBA code to ooRexx code:

  * If a VBA argument is of the form "somearg := abc", then a named argument is 
used (left of the
":=" operator is the name of the argument, right of it the value to be used 
for it). It may be
the case that the named argument "somearg" is not defined at the given 
position, such that one
needs to research the VBA routine/function definition and locate the 
position of the argument
named "somearg". Then in the ooRexx 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

Link to the Lua CICSs 3270 SHARE presentation shorturl.at/ilyFG

On 8/1/22 10:29 pm, David Crayford wrote:
I think we will have to agree to disagree Rene. I certainly don't want 
to engage in a sh**storm because I respect you.


I'm a REXX expert. Not only do I know the language I have written many 
extensions. It's not easy because the REXX API is designed for HLASM 
so I had to write a CEEPIPI glue module. Horrible REXX fact is REXX is 
dog slow. The DSNREXX command environment you cited took 12secs to run 
a query that luasql ran in 0.03 secs using ODBC. Reading a large file 
using EXECIO is 3 orders of magnitude slower than using Lua. SDSF? A 
lot of my workmates are ex IBMers some of whom worked on FileManager. 
REXX was so slow they had to dump it and write a subset for the 
product. There is no Lua API and I don't care about performance. We 
also got Lua running in CICS so we could replace a 3270 application 
with a web application shorturl.at/ilyFG. I don't use Lua much these 
days as I am mainly a Java programmer. My background is 35 of years 
HLASM, REXX, CLIST, COBOL, C/C++, etc, etc, etc.



On 8/1/22 9:49 pm, René Jansen wrote:
I thought gmail had eaten my reply so I took some time to give you a 
more elaborate reaction. I am still sorry that you need to resort to 
ad-hominems but I would like to give you some facts. It is not only 
my undeniable love for Rexx (but I do program in anything that the 
job requires, even ABAP, well maybe not that anymore), but also for 
z/OS, and the facts are these:


Rexx has (on z/OS, at least) the following address environments:

TSO
MVS
ISREDIT
ISPEXEC
ISPF Panel Rexx
ISPF File Tailoring Skeleton Rexx
CONSOLE
LINK, LINKMVS, LINKPGM, ATTACH, ATTCHMVS, ATTCHPGM
SYSCALL
SDSF
DSNREXX
IPCS
IRRXUTIL
RACVAR

Then there is:
System Rexx
Rexx/CICS
and I even saw some NetView Rexx only last year.

There are very many samples of how to use MQ, DB2, ICSF, DFDSS, VSAM 
(you told us that Rexx does not support VSAM but that is also plainly 
untrue, there are many ways to do that), variable record SAM. Someone 
starting on the platform with only Python in their repertoire would 
be lost.


I fail to see how much computer science gimmickry (which I also 
enjoy, really, but on the Raspberry Pi and the macbook) that mostly 
is available in the latest releases of coming and going fad languages 
(you mentioned Swift as one - Swift I appreciate because of the 
Objective C integration as not to invalidate people’s code, and those 
clean OO concepts which make C++ seem overcomplicated) *compensates* 
for not having these interfaces to the platform. I worry for the 
platform when its originator deprecates it in an act of self-harm. 
Personally, I think that Linux is better done in Linux than in USS, 
at least in Linux on Z, which makes people happy while still running 
a solid platform.


I also like the other languages you mention and I see the appeal of 
Lua as a macro language for gaming and LuaTeX. Still, numeric support 
is bad and Unicode support is worse. It does macro language worse 
than the original macro language, certainly on z/OS. For applications 
you don’t need those interfaces, but then I would like to see Elixir, 
and maybe Prolog and APL in open source versions, instead of all 
those small variations on C, C++, Java, JS - the aforementioned 
really bring something to the table.


Unless a lot of work is done to make Python support the above list of 
interfaces, it is - in my view - plainly the wrong proposition for 
the platform. Maybe some good examples of how to use IRXSUBCM, 
SHVBLOCK, ENVBLOCK,  EXECBLK and EVALBLOCK from Python would help in 
addressing these interfaces. You can interface Python using C 
routines to those (need examples), but I think that would needlessly 
complicate things, as opposed to the language that has syntax for that.


So I stand by my original propositions, but after being called 
unprofessional, a luddite, red flagged and whatever after mentioning 
factual truths, I fear for the quality of the discussion here. To 
really modernize, lots of device specific code needs to be taken out 
to adapt to the current reality (DB2 did that some years ago and 
guess what, taking out the optimizations for non-existing disks made 
it faster), the strong points of the OS (LPA, LLA) need to be 
reinforced for newer software, TCP/IP within the boxes still needs to 
be a lot better, better scripting level tools like Pipelines (that 
know about the environment) need to be included (doesn’t IBM look at 
SHARE requirement anymore?), instead of building layers on top of it, 
like new filesystems added on top or equivalent scripting 
environments added that can do less than the existing ones. And there 
is always the danger of fighting the last war.


best regards,

René.



On 8 Jan 2022, at 07:49, David Crayford <

Nobody is denying the value of that code. I wrote thousands of lines 
of REXX  code for system automation back in the 90s


I just can’t 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

I agree, let’s agree we both like Java.

> On 8 Jan 2022, at 10:29, David Crayford  wrote:
> 
> I think we will have to agree to disagree Rene. I certainly don't want to 
> engage in a sh**storm because I respect you.


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

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

I think USS is very interesting, a great technical accomplishment, but it is 
generally agreed that the differences with other Unices made life different for 
people wanting to use it in anger for applications. It gives z/OS the Unix 
system calls in a library that wraps MVS supervisor calls, and it offers an 
hierarchical filesystem in something that looks like a VSAM LDS to MVS. 
Differences with other Unices, like being EBCDIC based have been mostly masked, 
but will hit everybody sometimes, and did not make it less complicated. A lot 
of work was done on Rexx so it can address the conventional environments, and 
it even brought linein and lineout as standard components to MVS - a tender 
point un the Rexx world, because Endicott (it was?) closed the window on Rexx 
just before these became available for z/OS. These were available in a separate 
library that most often was not installed by sysprogs ‘because management’.

Often seen wrongly by application people as a Unix ‘emulator’; USS is part of 
z/OS and makes it POSIX compliant. You can write a program that calls Unix 
services and MVS SVC’s (using their macros, preferably) in the same CSECT. Why 
you would do that is another question. It is truly a work of art, but all the 
younger people at sites where I needed to fight fires were pretty negative, and 
it always takes a lot of explaining. Also, wrong defaults on Java memory made 
it look terrible at first sight. Also, traditional sysprogs also refused to 
install bash and git and RACF-protected the C compiler, in a repeat of what 
happened when TCP hit the platform, making it even less popular, with no 
tab-expansion of filenames (tcsh cam first, and could do that, but also not 
very popular).

This reminds me of OS/2’s “a better DOS than DOS”, which was absolutely true, 
but did not bring the marketing people what they expected. It would have been 
better to give away the C++ compiler (CSET/2) for free, astroturf the fora, and 
bribe the application developers and hardware people, like some other company 
did. BTW for a very short time I had the official job title ‘OS/2 Systems 
Programmer’ and it was a happy time solving lots of problems with the kernel 
debugger on the second machine. That stopped the Token Ring if it hit a 
breakpoint at the wrong moment.

Best regards,

René.   

> On 8 Jan 2022, at 09:58, PINION, RICHARD W.  wrote:
> 
> I've not followed this thread.  But, one thing I saw in your latest reply, 
> about z/OS USS/Open Edition and Linux.  USS/Open Edition is/was a port of 
> UNIX.  I remember the IBM marketing presentation about OE/USS, the local IBM 
> rep stated "more UNIX than UNIX".


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

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

I think we will have to agree to disagree Rene. I certainly don't want 
to engage in a sh**storm because I respect you.


I'm a REXX expert. Not only do I know the language I have written many 
extensions. It's not easy because the REXX API is designed for HLASM so 
I had to write a CEEPIPI glue module. Horrible REXX fact is REXX is dog 
slow. The DSNREXX command environment you cited took 12secs to run a 
query that luasql ran in 0.03 secs using ODBC. Reading a large file 
using EXECIO is 3 orders of magnitude slower than using Lua. SDSF? A lot 
of my workmates are ex IBMers some of whom worked on FileManager. REXX 
was so slow they had to dump it and write a subset for the product. 
There is no Lua API and I don't care about performance. We also got Lua 
running in CICS so we could replace a 3270 application with a web 
application shorturl.at/ilyFG. I don't use Lua much these days as I am 
mainly a Java programmer. My background is 35 of years HLASM, REXX, 
CLIST, COBOL, C/C++, etc, etc, etc.



On 8/1/22 9:49 pm, René Jansen wrote:

I thought gmail had eaten my reply so I took some time to give you a more 
elaborate reaction. I am still sorry that you need to resort to ad-hominems but 
I would like to give you some facts. It is not only my undeniable love for Rexx 
(but I do program in anything that the job requires, even ABAP, well maybe not 
that anymore), but also for z/OS, and the facts are these:

Rexx has (on z/OS, at least) the following address environments:

TSO
MVS
ISREDIT
ISPEXEC
ISPF Panel Rexx
ISPF File Tailoring Skeleton Rexx
CONSOLE
LINK, LINKMVS, LINKPGM, ATTACH, ATTCHMVS, ATTCHPGM
SYSCALL
SDSF
DSNREXX
IPCS
IRRXUTIL
RACVAR

Then there is:
System Rexx
Rexx/CICS
and I even saw some NetView Rexx only last year.

There are very many samples of how to use MQ, DB2, ICSF, DFDSS, VSAM (you told 
us that Rexx does not support VSAM but that is also plainly untrue, there are 
many ways to do that), variable record SAM. Someone starting on the platform 
with only Python in their repertoire would be lost.

I fail to see how much computer science gimmickry (which I also enjoy, really, 
but on the Raspberry Pi and the macbook) that mostly is available in the latest 
releases of coming and going fad languages (you mentioned Swift as one - Swift 
I appreciate because of the Objective C integration as not to invalidate 
people’s code, and those clean OO concepts which make C++ seem overcomplicated) 
*compensates* for not having these interfaces to the platform. I worry for the 
platform when its originator deprecates it in an act of self-harm. Personally, 
I think that Linux is better done in Linux than in USS, at least in Linux on Z, 
which makes people happy while still running a solid platform.

I also like the other languages you mention and I see the appeal of Lua as a 
macro language for gaming and LuaTeX. Still, numeric support is bad and Unicode 
support is worse. It does macro language worse than the original macro 
language, certainly on z/OS. For applications you don’t need those interfaces, 
but then I would like to see Elixir, and maybe Prolog and APL in open source 
versions, instead of all those small variations on C, C++, Java, JS - the 
aforementioned really bring something to the table.

Unless a lot of work is done to make Python support the above list of 
interfaces, it is - in my view - plainly the wrong proposition for the 
platform. Maybe some good examples of how to use IRXSUBCM, SHVBLOCK, ENVBLOCK,  
EXECBLK and EVALBLOCK from Python would help in addressing these interfaces. 
You can interface Python using C routines to those (need examples), but I think 
that would needlessly complicate things, as opposed to the language that has 
syntax for that.

So I stand by my original propositions, but after being called unprofessional, 
a luddite, red flagged and whatever after mentioning factual truths, I fear for 
the quality of the discussion here. To really modernize, lots of device 
specific code needs to be taken out to adapt to the current reality (DB2 did 
that some years ago and guess what, taking out the optimizations for 
non-existing disks made it faster), the strong points of the OS (LPA, LLA) need 
to be reinforced for newer software, TCP/IP within the boxes still needs to be 
a lot better, better scripting level tools like Pipelines (that know about the 
environment) need to be included (doesn’t IBM look at SHARE requirement 
anymore?), instead of building layers on top of it, like new filesystems added 
on top or equivalent scripting environments added that can do less than the 
existing ones. And there is always the danger of fighting the last war.

best regards,

René.



On 8 Jan 2022, at 07:49, David Crayford <

Nobody is denying the value of that code. I wrote thousands of lines of REXX  
code for system automation back in the 90s

I just can’t find a use case for writing new REXX code today. Everything had 
changed.


On 8 Jan 2022, at 19:40, René Jansen <

Well I 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[PINION, RICHARD W.]

I've not followed this thread.  But, one thing I saw in your latest reply, 
about z/OS USS/Open Edition and Linux.  USS/Open Edition is/was a port of UNIX. 
 I remember the IBM marketing presentation about OE/USS, the local IBM rep 
stated "more UNIX than UNIX".


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
René Jansen
Sent: Saturday, January 8, 2022 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ad programming features (Re: ... Re: Top 8 Reasons for using 
Python instead of REXX for z/OS

[External Email. Exercise caution when clicking links or opening attachments.]

I thought gmail had eaten my reply so I took some time to give you a more 
elaborate reaction. I am still sorry that you need to resort to ad-hominems but 
I would like to give you some facts. It is not only my undeniable love for Rexx 
(but I do program in anything that the job requires, even ABAP, well maybe not 
that anymore), but also for z/OS, and the facts are these:

Rexx has (on z/OS, at least) the following address environments:

TSO
MVS
ISREDIT
ISPEXEC
ISPF Panel Rexx
ISPF File Tailoring Skeleton Rexx
CONSOLE
LINK, LINKMVS, LINKPGM, ATTACH, ATTCHMVS, ATTCHPGM SYSCALL SDSF DSNREXX IPCS 
IRRXUTIL RACVAR

Then there is:
System Rexx
Rexx/CICS
and I even saw some NetView Rexx only last year.

There are very many samples of how to use MQ, DB2, ICSF, DFDSS, VSAM (you told 
us that Rexx does not support VSAM but that is also plainly untrue, there are 
many ways to do that), variable record SAM. Someone starting on the platform 
with only Python in their repertoire would be lost.

I fail to see how much computer science gimmickry (which I also enjoy, really, 
but on the Raspberry Pi and the macbook) that mostly is available in the latest 
releases of coming and going fad languages (you mentioned Swift as one - Swift 
I appreciate because of the Objective C integration as not to invalidate 
people’s code, and those clean OO concepts which make C++ seem overcomplicated) 
*compensates* for not having these interfaces to the platform. I worry for the 
platform when its originator deprecates it in an act of self-harm. Personally, 
I think that Linux is better done in Linux than in USS, at least in Linux on Z, 
which makes people happy while still running a solid platform.

I also like the other languages you mention and I see the appeal of Lua as a 
macro language for gaming and LuaTeX. Still, numeric support is bad and Unicode 
support is worse. It does macro language worse than the original macro 
language, certainly on z/OS. For applications you don’t need those interfaces, 
but then I would like to see Elixir, and maybe Prolog and APL in open source 
versions, instead of all those small variations on C, C++, Java, JS - the 
aforementioned really bring something to the table.

Unless a lot of work is done to make Python support the above list of 
interfaces, it is - in my view - plainly the wrong proposition for the 
platform. Maybe some good examples of how to use IRXSUBCM, SHVBLOCK, ENVBLOCK,  
EXECBLK and EVALBLOCK from Python would help in addressing these interfaces. 
You can interface Python using C routines to those (need examples), but I think 
that would needlessly complicate things, as opposed to the language that has 
syntax for that.

So I stand by my original propositions, but after being called unprofessional, 
a luddite, red flagged and whatever after mentioning factual truths, I fear for 
the quality of the discussion here. To really modernize, lots of device 
specific code needs to be taken out to adapt to the current reality (DB2 did 
that some years ago and guess what, taking out the optimizations for 
non-existing disks made it faster), the strong points of the OS (LPA, LLA) need 
to be reinforced for newer software, TCP/IP within the boxes still needs to be 
a lot better, better scripting level tools like Pipelines (that know about the 
environment) need to be included (doesn’t IBM look at SHARE requirement 
anymore?), instead of building layers on top of it, like new filesystems added 
on top or equivalent scripting environments added that can do less than the 
existing ones. And there is always the danger of fighting the last war.

best regards,

René.


> On 8 Jan 2022, at 07:49, David Crayford <
>
> Nobody is denying the value of that code. I wrote thousands of lines 
> of REXX  code for system automation back in the 90s
>
> I just can’t find a use case for writing new REXX code today. Everything had 
> changed.
>
>> On 8 Jan 2022, at 19:40, René Jansen <
>>
>> Well I am explicitly not reacting on another round of namecalling. What is 
>> worrying to me is the denial of the value of all existing interfaces in the 
>> OS and infrastructure to the standard scripting language on the platform, 
>> making the ‘modernization’ effort a reduction to uss, which will be hated by 
>> everybody used to Linux. But if the reaction consists of ‘unprofessional’, 
>> I’m done.
>>
>>
>>> On 8 Jan 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

“the passionate programmer”, I think I’ll keep that.

> On 8 Jan 2022, at 09:19, W Mainframe 
> <01304632a58d-dmarc-requ...@listserv.ua.edu> wrote:
> 
> If you are coding as professional, use the best language for that, if you are 
> coding by passion, just use Rexx... :)
> Dan
> 

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

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

I thought gmail had eaten my reply so I took some time to give you a more 
elaborate reaction. I am still sorry that you need to resort to ad-hominems but 
I would like to give you some facts. It is not only my undeniable love for Rexx 
(but I do program in anything that the job requires, even ABAP, well maybe not 
that anymore), but also for z/OS, and the facts are these:

Rexx has (on z/OS, at least) the following address environments:

TSO
MVS
ISREDIT
ISPEXEC
ISPF Panel Rexx
ISPF File Tailoring Skeleton Rexx
CONSOLE
LINK, LINKMVS, LINKPGM, ATTACH, ATTCHMVS, ATTCHPGM
SYSCALL
SDSF
DSNREXX
IPCS
IRRXUTIL
RACVAR

Then there is:
System Rexx
Rexx/CICS
and I even saw some NetView Rexx only last year.

There are very many samples of how to use MQ, DB2, ICSF, DFDSS, VSAM (you told 
us that Rexx does not support VSAM but that is also plainly untrue, there are 
many ways to do that), variable record SAM. Someone starting on the platform 
with only Python in their repertoire would be lost.

I fail to see how much computer science gimmickry (which I also enjoy, really, 
but on the Raspberry Pi and the macbook) that mostly is available in the latest 
releases of coming and going fad languages (you mentioned Swift as one - Swift 
I appreciate because of the Objective C integration as not to invalidate 
people’s code, and those clean OO concepts which make C++ seem overcomplicated) 
*compensates* for not having these interfaces to the platform. I worry for the 
platform when its originator deprecates it in an act of self-harm. Personally, 
I think that Linux is better done in Linux than in USS, at least in Linux on Z, 
which makes people happy while still running a solid platform.

I also like the other languages you mention and I see the appeal of Lua as a 
macro language for gaming and LuaTeX. Still, numeric support is bad and Unicode 
support is worse. It does macro language worse than the original macro 
language, certainly on z/OS. For applications you don’t need those interfaces, 
but then I would like to see Elixir, and maybe Prolog and APL in open source 
versions, instead of all those small variations on C, C++, Java, JS - the 
aforementioned really bring something to the table.

Unless a lot of work is done to make Python support the above list of 
interfaces, it is - in my view - plainly the wrong proposition for the 
platform. Maybe some good examples of how to use IRXSUBCM, SHVBLOCK, ENVBLOCK,  
EXECBLK and EVALBLOCK from Python would help in addressing these interfaces. 
You can interface Python using C routines to those (need examples), but I think 
that would needlessly complicate things, as opposed to the language that has 
syntax for that. 

So I stand by my original propositions, but after being called unprofessional, 
a luddite, red flagged and whatever after mentioning factual truths, I fear for 
the quality of the discussion here. To really modernize, lots of device 
specific code needs to be taken out to adapt to the current reality (DB2 did 
that some years ago and guess what, taking out the optimizations for 
non-existing disks made it faster), the strong points of the OS (LPA, LLA) need 
to be reinforced for newer software, TCP/IP within the boxes still needs to be 
a lot better, better scripting level tools like Pipelines (that know about the 
environment) need to be included (doesn’t IBM look at SHARE requirement 
anymore?), instead of building layers on top of it, like new filesystems added 
on top or equivalent scripting environments added that can do less than the 
existing ones. And there is always the danger of fighting the last war.

best regards,

René.


> On 8 Jan 2022, at 07:49, David Crayford <
> 
> Nobody is denying the value of that code. I wrote thousands of lines of REXX  
> code for system automation back in the 90s
> 
> I just can’t find a use case for writing new REXX code today. Everything had 
> changed. 
> 
>> On 8 Jan 2022, at 19:40, René Jansen <
>> 
>> Well I am explicitly not reacting on another round of namecalling. What is 
>> worrying to me is the denial of the value of all existing interfaces in the 
>> OS and infrastructure to the standard scripting language on the platform, 
>> making the ‘modernization’ effort a reduction to uss, which will be hated by 
>> everybody used to Linux. But if the reaction consists of ‘unprofessional’, 
>> I’m done.
>> 
>> 
>>> On 8 Jan 2022, at 05:43, David Crayford <
>>> 
>>> Why not compile lua to support utf8?
>>> 
>>> Your unrelenting love of REXX worries me. it’s  the perfect example of 
>>> personal preference over a functional requirement which is unprofessional 
>>> and a red flag. 
>>> 
> On 8 Jan 2022, at 14:57, René Jansen <
 
 I looked at your list and I am happy to see that these include the things 
 you find important. JS is undeniably a big factor but “the good parts” is 
 a thin booklet. As is groovy - slow and nevery had any appeal to me, just 
 looks messy. I quite like Ruby as an idea 

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bob Bridges]

Speaking as a PL/1 bigot -- it was my first language -- there's no doubt you're 
right.  I dislike COBOL for its wordiness, but even I have to admit that aside 
from that it's powerful enough to do the job and a bit over.  I have 
occasionally had to pause to reluctantly admire its ability to do modular.

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

/* Real programmers don't work from 9 to 5.  If any real programmers are around 
at 9am it's because they were up all night. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Friday, January 7, 2022 23:17

--- On 8/1/22 1:42 am, Tony Harminc wrote:
It's interesting that no language since COBOL has ever tried to emulate the 
"english" syntax. It turns out that it was not actually a terribly good idea. 
Programmers preferred languages with more concise syntax.

BTW, I'm not knocking COBOL. I'm a mainframe guy and I'm cognizant to the fact 
that the raison d'être of the mainframe is to run applications written in 
COBOL. PL/I programmers will disagree but COBOL is king.

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

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[W Mainframe]

If you are coding as professional, use the best language for that, if you are 
coding by passion, just use Rexx... :)
Dan


Sent from Yahoo Mail for iPhone


On Saturday, January 8, 2022, 8:50 AM, David Crayford  
wrote:

Nobody is denying the value of that code. I wrote thousands of lines of REXX  
code for system automation back in the 90s

I just can’t find a use case for writing new REXX code today. Everything had 
changed. 

> On 8 Jan 2022, at 19:40, René Jansen  wrote:
> 
> Well I am explicitly not reacting on another round of namecalling. What is 
> worrying to me is the denial of the value of all existing interfaces in the 
> OS and infrastructure to the standard scripting language on the platform, 
> making the ‘modernization’ effort a reduction to uss, which will be hated by 
> everybody used to Linux. But if the reaction consists of ‘unprofessional’, 
> I’m done.
> 
> 
>> On 8 Jan 2022, at 05:43, David Crayford  wrote:
>> 
>> Why not compile lua to support utf8?
>> 
>> Your unrelenting love of REXX worries me. it’s  the perfect example of 
>> personal preference over a functional requirement which is unprofessional 
>> and a red flag. 
>> 
 On 8 Jan 2022, at 14:57, René Jansen  wrote:
>>> 
>>> I looked at your list and I am happy to see that these include the things 
>>> you find important. JS is undeniably a big factor but “the good parts” is a 
>>> thin booklet. As is groovy - slow and nevery had any appeal to me, just 
>>> looks messy. I quite like Ruby as an idea but slow as molasses. 
>>> 
>>> Today I looked at Lua, and although quite elegant, small and snappy, I am 
>>> really disappointed that this is one of those languages that gives you 
>>> wrong answers for numeric problems and having unicode support in a utf8 
>>> library that is different from the string functions - that is just funny. I 
>>> am not implying that all Rexx implementations shine in this regard, but 
>>> that is just neglect. NetRexx does, however, as it does in unlimited 
>>> decimal precision arithmetic.
>>> 
>>> Of course NetRexx can use the Java stream API for functional programming. 
>>> That remark is just as odd as ‘it only has one type’. The fact that it is 
>>> from 1995 and can use features that only appeared in Java 8 - personally I 
>>> find that telling about the quality of the design. But I am not telling you 
>>> that you need to like it - like the way we are told that we now need to 
>>> like Python more than Rexx, while it cannot do what we need to do - for all 
>>> the wrong reasons.
>>> 
>>> Looking at your list of requirements I think Scheme had it quite covered. 
>>> Some of them are gimmicky and some seem useful. None of them address the 
>>> core qualities of the mainframe, which are Channels, packed decimal, DB2, 
>>> CICS and COBOL (as long as you forbid dynamic memory).
>>> 
>>> I think the discussion has strayed too much from what sparked it, which is 
>>> a hitpiece with 8 untruths about Python and Rexx. Yes we like all languages 
>>> to be available, and well maintained on z/OS. Please provide interfaces and 
>>> precompilers for the main infrastructure. It is remarkably odd that IBM 
>>> does not invest in the things that made the platform what it is, but it is 
>>> not my problem. If the message is that the mainframe now can run the same 
>>> software as the Raspberry Pi or your generic AWS instance, so be it.
>>> 
>>> I think you will find that other people are emotionally attached to their 
>>> tools and programming languages, it is a human thing. Also, I found that 
>>> not all people can easily switch between a large number of ever-changing 
>>> programming languages; which is meant as a compliment to you; but 
>>> nevertheless very true.
>>> 
>>> So I thank you all for a very interesting discussion.
>>> 
>>> Best regards,
>>> 
>>> René. 
>>> 
> On 7 Jan 2022, at 20:53, David Crayford  wrote:
 
 I could go on. Even Java supports functional programming since Java 1.8 
 and which introduced the streams API. It's unusual to see and old school 
 loop in modern Java code. Even C++ has lambda's.
 
 I missed "closures" on my list which code hand in hand with "functions as 
 first class objects". Very powerful, for example in Kotlin you can easily 
 create type safe builders (DSLs) 
 https://kotlinlang.org/docs/type-safe-builders.html.
 That's why I have absolutely no interest in NetRexx. I have far better 
 options on the JVM. I don't get emotionally attached to programming 
 languages. If a better one becomes available I will quite happily switch 
 as I have done
>>> 
>>> --
>>> 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,
>> 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

Nobody is denying the value of that code. I wrote thousands of lines of REXX  
code for system automation back in the 90s

I just can’t find a use case for writing new REXX code today. Everything had 
changed. 

> On 8 Jan 2022, at 19:40, René Jansen  wrote:
> 
> Well I am explicitly not reacting on another round of namecalling. What is 
> worrying to me is the denial of the value of all existing interfaces in the 
> OS and infrastructure to the standard scripting language on the platform, 
> making the ‘modernization’ effort a reduction to uss, which will be hated by 
> everybody used to Linux. But if the reaction consists of ‘unprofessional’, 
> I’m done.
> 
> 
>> On 8 Jan 2022, at 05:43, David Crayford  wrote:
>> 
>> Why not compile lua to support utf8?
>> 
>> Your unrelenting love of REXX worries me. it’s  the perfect example of 
>> personal preference over a functional requirement which is unprofessional 
>> and a red flag. 
>> 
 On 8 Jan 2022, at 14:57, René Jansen  wrote:
>>> 
>>> I looked at your list and I am happy to see that these include the things 
>>> you find important. JS is undeniably a big factor but “the good parts” is a 
>>> thin booklet. As is groovy - slow and nevery had any appeal to me, just 
>>> looks messy. I quite like Ruby as an idea but slow as molasses. 
>>> 
>>> Today I looked at Lua, and although quite elegant, small and snappy, I am 
>>> really disappointed that this is one of those languages that gives you 
>>> wrong answers for numeric problems and having unicode support in a utf8 
>>> library that is different from the string functions - that is just funny. I 
>>> am not implying that all Rexx implementations shine in this regard, but 
>>> that is just neglect. NetRexx does, however, as it does in unlimited 
>>> decimal precision arithmetic.
>>> 
>>> Of course NetRexx can use the Java stream API for functional programming. 
>>> That remark is just as odd as ‘it only has one type’. The fact that it is 
>>> from 1995 and can use features that only appeared in Java 8 - personally I 
>>> find that telling about the quality of the design. But I am not telling you 
>>> that you need to like it - like the way we are told that we now need to 
>>> like Python more than Rexx, while it cannot do what we need to do - for all 
>>> the wrong reasons.
>>> 
>>> Looking at your list of requirements I think Scheme had it quite covered. 
>>> Some of them are gimmicky and some seem useful. None of them address the 
>>> core qualities of the mainframe, which are Channels, packed decimal, DB2, 
>>> CICS and COBOL (as long as you forbid dynamic memory).
>>> 
>>> I think the discussion has strayed too much from what sparked it, which is 
>>> a hitpiece with 8 untruths about Python and Rexx. Yes we like all languages 
>>> to be available, and well maintained on z/OS. Please provide interfaces and 
>>> precompilers for the main infrastructure. It is remarkably odd that IBM 
>>> does not invest in the things that made the platform what it is, but it is 
>>> not my problem. If the message is that the mainframe now can run the same 
>>> software as the Raspberry Pi or your generic AWS instance, so be it.
>>> 
>>> I think you will find that other people are emotionally attached to their 
>>> tools and programming languages, it is a human thing. Also, I found that 
>>> not all people can easily switch between a large number of ever-changing 
>>> programming languages; which is meant as a compliment to you; but 
>>> nevertheless very true.
>>> 
>>> So I thank you all for a very interesting discussion.
>>> 
>>> Best regards,
>>> 
>>> René. 
>>> 
> On 7 Jan 2022, at 20:53, David Crayford  wrote:
 
 I could go on. Even Java supports functional programming since Java 1.8 
 and which introduced the streams API. It's unusual to see and old school 
 loop in modern Java code. Even C++ has lambda's.
 
 I missed "closures" on my list which code hand in hand with "functions as 
 first class objects". Very powerful, for example in Kotlin you can easily 
 create type safe builders (DSLs) 
 https://kotlinlang.org/docs/type-safe-builders.html.
 That's why I have absolutely no interest in NetRexx. I have far better 
 options on the JVM. I don't get emotionally attached to programming 
 languages. If a better one becomes available I will quite happily switch 
 as I have done
>>> 
>>> --
>>> 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 

Re: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

Well I am explicitly not reacting on another round of namecalling. What is 
worrying to me is the denial of the value of all existing interfaces in the OS 
and infrastructure to the standard scripting language on the platform, making 
the ‘modernization’ effort a reduction to uss, which will be hated by everybody 
used to Linux. But if the reaction consists of ‘unprofessional’, I’m done.


> On 8 Jan 2022, at 05:43, David Crayford  wrote:
> 
> Why not compile lua to support utf8?
> 
> Your unrelenting love of REXX worries me. it’s  the perfect example of 
> personal preference over a functional requirement which is unprofessional and 
> a red flag. 
> 
>> On 8 Jan 2022, at 14:57, René Jansen  wrote:
>> 
>> I looked at your list and I am happy to see that these include the things 
>> you find important. JS is undeniably a big factor but “the good parts” is a 
>> thin booklet. As is groovy - slow and nevery had any appeal to me, just 
>> looks messy. I quite like Ruby as an idea but slow as molasses. 
>> 
>> Today I looked at Lua, and although quite elegant, small and snappy, I am 
>> really disappointed that this is one of those languages that gives you wrong 
>> answers for numeric problems and having unicode support in a utf8 library 
>> that is different from the string functions - that is just funny. I am not 
>> implying that all Rexx implementations shine in this regard, but that is 
>> just neglect. NetRexx does, however, as it does in unlimited decimal 
>> precision arithmetic.
>> 
>> Of course NetRexx can use the Java stream API for functional programming. 
>> That remark is just as odd as ‘it only has one type’. The fact that it is 
>> from 1995 and can use features that only appeared in Java 8 - personally I 
>> find that telling about the quality of the design. But I am not telling you 
>> that you need to like it - like the way we are told that we now need to like 
>> Python more than Rexx, while it cannot do what we need to do - for all the 
>> wrong reasons.
>> 
>> Looking at your list of requirements I think Scheme had it quite covered. 
>> Some of them are gimmicky and some seem useful. None of them address the 
>> core qualities of the mainframe, which are Channels, packed decimal, DB2, 
>> CICS and COBOL (as long as you forbid dynamic memory).
>> 
>> I think the discussion has strayed too much from what sparked it, which is a 
>> hitpiece with 8 untruths about Python and Rexx. Yes we like all languages to 
>> be available, and well maintained on z/OS. Please provide interfaces and 
>> precompilers for the main infrastructure. It is remarkably odd that IBM does 
>> not invest in the things that made the platform what it is, but it is not my 
>> problem. If the message is that the mainframe now can run the same software 
>> as the Raspberry Pi or your generic AWS instance, so be it.
>> 
>> I think you will find that other people are emotionally attached to their 
>> tools and programming languages, it is a human thing. Also, I found that not 
>> all people can easily switch between a large number of ever-changing 
>> programming languages; which is meant as a compliment to you; but 
>> nevertheless very true.
>> 
>> So I thank you all for a very interesting discussion.
>> 
>> Best regards,
>> 
>> René. 
>> 
 On 7 Jan 2022, at 20:53, David Crayford  wrote:
>>> 
>>> I could go on. Even Java supports functional programming since Java 1.8 and 
>>> which introduced the streams API. It's unusual to see and old school loop 
>>> in modern Java code. Even C++ has lambda's.
>>> 
>>> I missed "closures" on my list which code hand in hand with "functions as 
>>> first class objects". Very powerful, for example in Kotlin you can easily 
>>> create type safe builders (DSLs) 
>>> https://kotlinlang.org/docs/type-safe-builders.html.
>>> That's why I have absolutely no interest in NetRexx. I have far better 
>>> options on the JVM. I don't get emotionally attached to programming 
>>> languages. If a better one becomes available I will quite happily switch as 
>>> I have done
>> 
>> --
>> 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: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

Why not compile lua to support utf8?

Your unrelenting love of REXX worries me. it’s  the perfect example of personal 
preference over a functional requirement which is unprofessional and a red 
flag. 

> On 8 Jan 2022, at 14:57, René Jansen  wrote:
> 
> I looked at your list and I am happy to see that these include the things 
> you find important. JS is undeniably a big factor but “the good parts” is a 
> thin booklet. As is groovy - slow and nevery had any appeal to me, just looks 
> messy. I quite like Ruby as an idea but slow as molasses. 
> 
> Today I looked at Lua, and although quite elegant, small and snappy, I am 
> really disappointed that this is one of those languages that gives you wrong 
> answers for numeric problems and having unicode support in a utf8 library 
> that is different from the string functions - that is just funny. I am not 
> implying that all Rexx implementations shine in this regard, but that is just 
> neglect. NetRexx does, however, as it does in unlimited decimal precision 
> arithmetic.
> 
> Of course NetRexx can use the Java stream API for functional programming. 
> That remark is just as odd as ‘it only has one type’. The fact that it is 
> from 1995 and can use features that only appeared in Java 8 - personally I 
> find that telling about the quality of the design. But I am not telling you 
> that you need to like it - like the way we are told that we now need to like 
> Python more than Rexx, while it cannot do what we need to do - for all the 
> wrong reasons.
> 
> Looking at your list of requirements I think Scheme had it quite covered. 
> Some of them are gimmicky and some seem useful. None of them address the core 
> qualities of the mainframe, which are Channels, packed decimal, DB2, CICS and 
> COBOL (as long as you forbid dynamic memory).
> 
> I think the discussion has strayed too much from what sparked it, which is a 
> hitpiece with 8 untruths about Python and Rexx. Yes we like all languages to 
> be available, and well maintained on z/OS. Please provide interfaces and 
> precompilers for the main infrastructure. It is remarkably odd that IBM does 
> not invest in the things that made the platform what it is, but it is not my 
> problem. If the message is that the mainframe now can run the same software 
> as the Raspberry Pi or your generic AWS instance, so be it.
> 
> I think you will find that other people are emotionally attached to their 
> tools and programming languages, it is a human thing. Also, I found that not 
> all people can easily switch between a large number of ever-changing 
> programming languages; which is meant as a compliment to you; but 
> nevertheless very true.
> 
> So I thank you all for a very interesting discussion.
> 
> Best regards,
> 
> René. 
> 
>> On 7 Jan 2022, at 20:53, David Crayford  wrote:
>> 
>> I could go on. Even Java supports functional programming since Java 1.8 and 
>> which introduced the streams API. It's unusual to see and old school loop in 
>> modern Java code. Even C++ has lambda's.
>> 
>> I missed "closures" on my list which code hand in hand with "functions as 
>> first class objects". Very powerful, for example in Kotlin you can easily 
>> create type safe builders (DSLs) 
>> https://kotlinlang.org/docs/type-safe-builders.html.
>> That's why I have absolutely no interest in NetRexx. I have far better 
>> options on the JVM. I don't get emotionally attached to programming 
>> languages. If a better one becomes available I will quite happily switch as 
>> I have done
> 
> --
> 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: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[René Jansen]

I looked at your list and I am happy to see that these include the things you 
find important. JS is undeniably a big factor but “the good parts” is a thin 
booklet. As is groovy - slow and nevery had any appeal to me, just looks messy. 
I quite like Ruby as an idea but slow as molasses. 

Today I looked at Lua, and although quite elegant, small and snappy, I am 
really disappointed that this is one of those languages that gives you wrong 
answers for numeric problems and having unicode support in a utf8 library that 
is different from the string functions - that is just funny. I am not implying 
that all Rexx implementations shine in this regard, but that is just neglect. 
NetRexx does, however, as it does in unlimited decimal precision arithmetic.

Of course NetRexx can use the Java stream API for functional programming. That 
remark is just as odd as ‘it only has one type’. The fact that it is from 1995 
and can use features that only appeared in Java 8 - personally I find that 
telling about the quality of the design. But I am not telling you that you need 
to like it - like the way we are told that we now need to like Python more than 
Rexx, while it cannot do what we need to do - for all the wrong reasons.

Looking at your list of requirements I think Scheme had it quite covered. Some 
of them are gimmicky and some seem useful. None of them address the core 
qualities of the mainframe, which are Channels, packed decimal, DB2, CICS and 
COBOL (as long as you forbid dynamic memory).

I think the discussion has strayed too much from what sparked it, which is a 
hitpiece with 8 untruths about Python and Rexx. Yes we like all languages to be 
available, and well maintained on z/OS. Please provide interfaces and 
precompilers for the main infrastructure. It is remarkably odd that IBM does 
not invest in the things that made the platform what it is, but it is not my 
problem. If the message is that the mainframe now can run the same software as 
the Raspberry Pi or your generic AWS instance, so be it.

I think you will find that other people are emotionally attached to their tools 
and programming languages, it is a human thing. Also, I found that not all 
people can easily switch between a large number of ever-changing programming 
languages; which is meant as a compliment to you; but nevertheless very true.

So I thank you all for a very interesting discussion.

Best regards,

René. 

> On 7 Jan 2022, at 20:53, David Crayford  wrote:
> 
> I could go on. Even Java supports functional programming since Java 1.8 and 
> which introduced the streams API. It's unusual to see and old school loop in 
> modern Java code. Even C++ has lambda's.
> 
> I missed "closures" on my list which code hand in hand with "functions as 
> first class objects". Very powerful, for example in Kotlin you can easily 
> create type safe builders (DSLs) 
> https://kotlinlang.org/docs/type-safe-builders.html.
> That's why I have absolutely no interest in NetRexx. I have far better 
> options on the JVM. I don't get emotionally attached to programming 
> languages. If a better one becomes available I will quite happily switch as I 
> have done

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

Re: Macro/script/program (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Joel C. Ewing]

I could be wrong, but I think the first use of "macro" in a 
programming/computer context was introduced in Assembler languages:  A 
macro invocation statement basically looked like an assembly statement 
with parameters, but instead of generating a single machine instruction 
or data definition could generate a whole series of assembly 
instructions.  The Macro definition typically includes both Assembly 
statements and special macro control statements.  I was first introduced 
to them in IBM 1410 Assembler, where they were used to generate the 
relatively complex interfaces required to do I/O.  In 360/370/etc 
Assembler, macros are extensively used to enforce the conventions for 
requesting any service from the Operating System, not just I/O.   As 
hardware architectures became more complex, programmers quickly 
discovered there were many repetitive instruction sequences in a typical 
assembler program, and macros were designed to allow a single statement 
to generate the entire sequence with minimal effort.  In order to 
perform that role, Assembler Macros definitely are required to include 
statements that support conditional logic and looping and symbolic 
values; but it is a pretty restrictive language, as its only intended 
capability is to generate, perhaps conditionally, other Assembly 
language statements, not to solve general purpose problems.


CDC 6000 Assembly Language included not only "macros" but "micros".   A 
"micro" allowed you do create a definition of a new "machine 
instruction" that would create a 15-bit, 30-bit, or 60-bit "instruction" 
with binary sub-fields and parameter rules similar to actual machine 
instructions statements, with a one-to-one correspondence between a 
statement and an "instruction".  Could be used for "new" hardware 
instructions not yet supported by the Assembler, for creating a 
customized version of an instruction where some fields were desired to 
be constrained, and possibly other bizarre applications.


The main distinction between a macro language and a full programming 
language seems to be the context in which it is executed.   Macros are 
embedded with statements of another language and "executed" when 
processing or pre-processing those statements to generate additional 
statements in that language to generate the complete program.   They are 
part of the process of generating the statements for the full program, 
not actually part of the final program.


    Joel C Ewing

On 1/7/22 06:57, Rony G. Flatscher wrote:

On 07.01.2022 03:00, Bob Bridges wrote:

I usually include JCL under the ~very~ general rubric of "programming 
language", but even mentally I think that's a stretch.  It's more like a macro 
language, sort of like .bat I guess.

I may as well take this opportunity to include a mild rant.  I've often heard the programs you can 
write for automating some applications referred to as "macros"; I have in mind VBA, for 
example, and what WordPerfect used to have if WordPerfect is still around.  It always seemed to me 
that VBA qualifies just fine as a programming language, and what I write in VBA is not a 
"macro", just a program.

But then what is a macro?  In searching for some sort of distinction that would 
justify there being two different words, I've concluded to my own satisfaction 
that a macro is a set of instructions that have no decision-making capability, 
maybe no if-then syntax and definitely no looping, probably no arithmetic, 
possibly some rudimentary logic operators like NOT (and may only NOT).  The old 
.bat language would fit this description; so would JCL, especially before they 
added IF statements.  So, if I remember right, are the instruction sets I used 
to write for QMF.  But not VBA; not even TECO.  (Anyone remember TECO?)

Now I sit back and wait for someone more knowledgeable to correct me either on the 
capabilities of the languages I named, or on the definition of "macro".

Most of the time Wikipedia is a quite good starting point, e.g.
.

The distinction between a macro/script (a set of statements allowing for 
executing repetitively in
the context of a hosting application) and a stand-alone program can be even 
totally blurred, e.g.
the following ooRexx program can be run from the macro menu of OpenOffice 
(OOO)/LibreOffice (LO) or
as a stand-alone program from the command line:

 #!/usr/bin/env rexx
 use arg slotArg   /* if called as a macro, we can access the document for 
which we were called  */

 scriptContext=uno.getScriptContext(slotArg)  /* get the xScriptContext 
object   */
 if scriptContext<>.nil then  /* o.k., we are invoked as a 
macro from OOo/LO */
 do
xContext=scriptContext~getComponentContext   /* get the context (a 
XComponentContext) object */
xDesktop=scriptContext~getDesktop/* get the desktop (a 
XDesktop) object  */

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 8/1/22 1:42 am, Tony Harminc wrote:

On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:


I've been following this thread and one thing that has yet to appear, or I 
missed it, has to do with 4GL's and the drive, at one point, for languages that 
were more human oriented - those that could be written more like a normal 
sentence or phrase, and avoid the technical jargon/gobblygook/syntax. As I 
recall in the 1980's there were a few but nothing came of them, instead we have 
languages that have their own syntax, and which require extensive learning but 
nothing that allows a non-programmer to actually generate a complex business 
program.

COBOL was supposed to be that, no? Managers could in theory at least
read (if not write) a COBOL program and understand what it does,
because it so (superficially) resembles English.


It's interesting that no language since COBOL has ever tried to emulate 
the "english" syntax. It turns out that it was not actually a terribly 
good idea. Programmers preferred languages with more concise syntax.


BTW, I'm not knocking COBOL. I'm a mainframe guy and I'm cognizant to 
the fact that the raison d'être of the mainframe is to run applications 
written in COBOL. PL/I programmers will disagree but COBOL is king.




 From my experience, REXX has many of the 4GL goals as the syntax isn't overly 
complex and is something a non-programmer can comprehend rather easily. As has 
been previously mentioned in this thread, REXX can be more readily learned and 
used than the majority of the current languages. It isn't perfect but it works 
very well.

Indeed.


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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 7/1/22 8:35 pm, Ronald Wells wrote:

Most hackable


If by hackable you mean it's not secure then that's far from true. 
Everything is Lua is contained in a single data structure, the table. 
Game mods and frameworks such as Redis use a technique called sandboxing 
to remove anything that could be dangerous such as the io library which 
could access the file system http://lua-users.org/wiki/SandBoxes.


A good example of this is Wikipedia which uses Lua for templating. It's 
removes all libraries that could be used by bad actors 
https://www.mediawiki.org/wiki/Extension:Scribunto. Lua is my favorite 
scripting language. It's the most elegantly designed programming 
language I have ever used. It's incredibly powerful and  the complete 
syntax can fit on the back of an envelope 
http://parrot.github.io/parrot-docs0/0.4.7/html/languages/lua/doc/lua51.bnf.html. 
However, my team prefer Python so that's what we use.





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Thursday, January 6, 2022 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

** EXTERNAL EMAIL - USE CAUTION **


On 7/1/22 9:44 am, Bob Bridges wrote:

I never heard of Lua until I started playing Factorio a few years ago; 
apparently it's the language in which players can add mods to the game.  For 
that reason I wasn't sure even what it is.  Is it really a programming 
language, or some special-purpose thingy?

It's a programming language. It's niche is to to be embedded as it's core is tiny which is 
why it is the language of choice for video game scripting or mods. Almost all AAA video 
games use Lua. It was designed as a configuration language so has features that make it 
ideal for writting DSLs 
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fleafo.net%2Fguides%2Fdsl-in-lua.htmldata=04%7C01%7CRon.Wells%40OMF.COM%7C7772e90be1b44314ffc208d9d1874587%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C637771201790127602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=BHm%2BNgGLz2WsI9rwgPEXZ5lnn8upcdSIIugwCCSK0y0%3Dreserved=0.



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

/* To be "matter of fact" about the world is to blunder into fantasy -
and dull fantasy at that, as the real world is strange and wonderful.
-from the Notebooks of Lazarus Long */

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of René Jansen
Sent: Thursday, January 6, 2022 20:15

I will look into Lua. Need to do that for TeX anyway.


--- On 6 Jan 2022, at 21:05, David Crayford  wrote:
...All of those requirements are met by Lua which runs on z/OS,
including modules in PDS data sets, supports TSO/ISPF and the entire
file system including VSAM which REXX does not.
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flua
4z.github.io%2FLua4z%2Fdata=04%7C01%7CRon.Wells%40OMF.COM%7C7772
e90be1b44314ffc208d9d1874587%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7
C0%7C637771201790127602%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3uTfz%
2FG47ThubN%2BgkpNWU2ovTuDLfSGNkY0Z5C8SoWQ%3Dreserved=0

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


Email Disclaimer

This E-mail contains confidential information belonging to the sender, which 
may be legally privileged information. This information is intended only for 
the use of the individual or entity addressed above. If you are not the 
intended recipient, or an employee or agent responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or the taking of any action in reliance on the contents of the 
E-mail or attached files is strictly prohibited.

--
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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 7/1/22 8:44 pm, Matt Hogstrom wrote:

A path forward that would make sense would be a new job control language like 
HELM that is familiar and modern and Kubernetes is the scheduler that runs the 
jobs.  Embracing the new paradigms along side the existing models is what we as 
practitioners need to do



Nice idea. We use Kubernetes and it's a joy to configure using YAML 
config files, either standard k8s or Help charts. YAML is the dominant 
configuration language now. We're starting to use it in legacy proeudcts.


I heard a rumor that OpenShift is coming to z/OS. That would be awesome.

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Clark Morris]

On Friday 07/01/2022 at 4:41 pm, Seymour J Metz  wrote:


COBOL was supposed to be that, no?


The use of "magic numbers" as levels in the DATA DIVISION totally 
blows away any claim that COBOL is English like or understandable to 
someone without training.


66 foo PIC X(10).

The syntax of 66 is "66 FOO RENAMES ABLE [THRU DOG]."


77 bar PIC X(10).
88 baz VALUE "S", "Y".

Then there is the weird behavior of COMMENT. In COBOL ends a 
statement, *except* when that statement is a cooment, in which case it 
swallows the remainder of the paragraph. Later versions of COBOL 
introduce a better behaved comment syntax.
That was the original NOTE statement replaced in later versions with 
of COBOL using * in column 7 for comment lines.  I believe that there 
are further developments in the 2002 and 2014 standards that give 
other options which IBM may have implemented.


Clark Morris




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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
behalf of Tony Harminc [t...@harminc.net]

Sent: Friday, January 7, 2022 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX 
for z/OS


On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:



I've been following this thread and one thing that has yet to appear, 
or I missed it, has to do with 4GL's and the drive, at one point, for 
languages that were more human oriented - those that could be written 
more like a normal sentence or phrase, and avoid the technical 
jargon/gobblygook/syntax. As I recall in the 1980's there were a few 
but nothing came of them, instead we have languages that have their 
own syntax, and which require extensive learning but nothing that 
allows a non-programmer to actually generate a complex business 
program.


COBOL was supposed to be that, no? Managers could in theory at least
read (if not write) a COBOL program and understand what it does,
because it so (superficially) resembles English.



From my experience, REXX has many of the 4GL goals as the syntax isn't 
overly complex and is something a non-programmer can comprehend rather 
easily. As has been previously mentioned in this thread, REXX can be 
more readily learned and used than the majority of the current 
languages. It isn't perfect but it works very well.


Indeed.

Tony H.

--
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: Ad programming features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[David Crayford]

On 7/1/22 7:53 pm, Rony G. Flatscher wrote:

Here is my list of must haves for a scripting language. Does REXX or ooRexx 
meet the requirements?

1. Short circuit evaluation
2. Functions as first class objects
3. Mutli-threading
4. Dynamically typed, preferably with type hints
5. co-routintes
6. A module system
7. Support for object oriented programming
8. Regular expressions
9. Libraries for web programming, pegs, JSON/YAML parsing etc

You also mentioned in your follow up: "Forgot to mention. Support for 
functional programming map,
reduce, filter etc."

This list reads a little bit like a wish list for concepts found in different 
programming languages.
Sometimes such features are specific for a particular language (e.g. functional 
programming) and
then sometimes made available in other languages.


Umm, nope. Here is a list of programming languages that I use that 
support all of my requirements.


 * Javascript
 * Typescript
 * Lua
 * Python
 * Ruby
 * Kotlin
 * Groovy

I could go on. Even Java supports functional programming since Java 1.8 
and which introduced the streams API. It's unusual to see and old school 
loop in modern Java code. Even C++ has lambda's.


I missed "closures" on my list which code hand in hand with "functions 
as first class objects". Very powerful, for example in Kotlin you can 
easily create type safe builders (DSLs) 
https://kotlinlang.org/docs/type-safe-builders.html.
That's why I have absolutely no interest in NetRexx. I have far better 
options on the JVM. I don't get emotionally attached to programming 
languages. If a better one becomes available I will quite happily switch 
as I have done slowly from Java

to Kotlin.




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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

I was more talking about JCL forcing the DD-to-dataset relationships 
into one place, which makes them easier to find.


Here's a line I had to mess with last week in a Linux shell script:

$IM_INSTALL_LOCATION/eclipse/IBMIM -input "$SCRIPTHOME/updateSKLM.xml"

While those $ variables are set in that same script, various "if" 
statements and other sources make it difficult to figure out what the 
end result of the command might be.


On 1/7/2022 1:16 PM, Seymour J Metz wrote:

+There's no forced standard for the choice of ddnames either; you need to know whether 
it's INPUT, SYSIN, SYSUT1 or "E. None of the above."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, January 7, 2022 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yes, but since there's no forced standard, variables and other methods
mean I might have to look the script or code to figure out what's going
on.  Sometimes that can get quite complex with the things people do that
eventually comes up with a filename/path string.  JCL makes everything
nice and neat and in one place.

On 1/7/2022 12:01 PM, Seymour J Metz wrote:


   Variables and file handles may not be the same as DD names, but they can 
serve the same function.



--
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: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Fri, 7 Jan 2022 20:30:03 +, Seymour J Metz wrote:

>> Would it be a favor to programmers to make misiplacing IF, etc.
>> within a job step, or SET within IF ... ENDIF a syntax error?  The
>> effect is probably not what the programmers intend.
>
>IMHO, the current behavior is a bug, but it might take an RFE to get it fixed, 
>and IBM might add a compatibility option for installations that depend on the 
>old behavior. It should at least generate a warning.
> 
Options, compatibility or otherwise, geometrically multiply the testing
burden for software suppliers.

-- gil

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Wayne Bickerdike]

One of the better 4GLs I worked with was IDEAL from ADR, later CA and
Broadcom.

It had FOR ENDFOR
SELECT
IF THEN ELSE
LOOP ENDLOOP

and GOTOless...

It fitted very nicely with James Martin and Michael Jackson (MJSL)
programming and design methodologies.

Other awful 4GLs, Natural (ADABAS). I remember working on a system in 1982
trying to write decent Natural code, it had memory limits that meant that
lines of code had to crammed together which rendered unreadable  and the
BASIC like syntax whereby line numbers were referenced and if a statement
was renumbered, references to previous I/O statements would fail.


On Sat, Jan 8, 2022 at 8:33 AM Seymour J Metz  wrote:

> I believe that reall AI will eventually arrive, and there has certainly
> been progress, but I no longer believe in the fairy tale that it is only 5
> years away. I wish that  here was a likeklihood that we would address the
> ethical issues before then, but I doubt it.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Bob Bridges [robhbrid...@gmail.com]
> Sent: Friday, January 7, 2022 4:24 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for
> z/OS
>
> I agree with Shmuel; we heard a lot about 4GLs back in the '80s and '90s,
> but I never saw one that lived up to the claims.  DYL-280II, for example,
> was advertised as a 4GL, but it wasn't close.  Don't get me wrong, as a 3GL
> I liked it just fine, and my company had me teach it to end users so they
> could fetch data from their particular databases without throwing off
> developers' estimated completion dates -- very successfully, I add happily.
> But it was no 4GL.
>
> Actually I lump 4GLs and AI into the same bucket.  They're related, I
> think:
> Folks dream of getting computers to think and talk like a human, but so far
> it hasn't happened and I suspect it cannot happen.  But then as a Christian
> I'm also a mystic, by which I mean that the 37 cents' worth of chemicals
> that one often hears about are not what we are, only what we're made of,
> and
> that the scientists' attempts to figure out what consciousness is and why
> it
> evolved is doomed to failure because they're starting with the wrong
> postulates.  But, heck, I may be mistaken.  Maybe someday a computer will
> pass a really decent Turing test.
>
> I'm not concerned that my profession is about to wither away, though.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Woe to him inside a nonconformist clique who does not conform with
> nonconformity.  -Eric Hoffer */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of
> Seymour J Metz
> Sent: Friday, January 7, 2022 16:09
>
> I know of languages that have been peddled as human oriented or English
> like; I don't know of any that even come close.
>
> --
> 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
>


-- 
Wayne V. Bickerdike

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Paul Gilmartin]

On Fri, 7 Jan 2022 19:43:58 +, Seymour J Metz wrote:

>Well, if you introduced the concept of steps into a script language then it 
>shouldn't be too hard to also add the concept of passed data sets. Named 
>temporary data sets also shouldn't be difficult. Or you could just use, e.g., 
>~/temp.
>
With JCL, the processor generates a unique name; makes it available
in subsequent steps and reliable removes it when the job completes.
Not easy or even possible with UNIX facilities.

>Overrides are necessary unless you can anticipate every ad hoc change that the 
>user might want to make; otherwise he would have to edit the script.
>
Il a les défauts de ses qualités.  I'm uncomfortable that someone cam
mane unanticipated  ad hoc changes by overrides to my read-only
library PROC and complain that it doesn't  work.

-- gil

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Farley, Peter x23353]

Not strictly speaking, no.  But find me an old-timer (especially manager types) 
who is symbol-aware and actively uses them or promotes their extensive use in 
crafting PROC's for other than UNIT, REGION and sometimes HLQ and SPACE.

I have faced active resistance on several jobs to my "overuse" of symbols.  I 
use them a lot, everywhere I can get away with it.  Many do not, and fail to 
understand the flexibility they provide.

One place you CANNOT use a symbol is for the JCL statement label.  I never 
really understood that restriction, though I have managed to get by with the 
rules as they are.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, January 7, 2022 2:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 18:47:47 +, Seymour J Metz wrote:

>ENQ and overrides come to mind.
> 
Add passed temporary DSNs to the list.

Are overrides necessary?  Is there anything that overrides that couldn't be 
done (in a more controlled manner) with symbol substitution?

-- 

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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I believe that reall AI will eventually arrive, and there has certainly been 
progress, but I no longer believe in the fairy tale that it is only 5 years 
away. I wish that  here was a likeklihood that we would address the ethical 
issues before then, but I doubt it.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Friday, January 7, 2022 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I agree with Shmuel; we heard a lot about 4GLs back in the '80s and '90s,
but I never saw one that lived up to the claims.  DYL-280II, for example,
was advertised as a 4GL, but it wasn't close.  Don't get me wrong, as a 3GL
I liked it just fine, and my company had me teach it to end users so they
could fetch data from their particular databases without throwing off
developers' estimated completion dates -- very successfully, I add happily.
But it was no 4GL.

Actually I lump 4GLs and AI into the same bucket.  They're related, I think:
Folks dream of getting computers to think and talk like a human, but so far
it hasn't happened and I suspect it cannot happen.  But then as a Christian
I'm also a mystic, by which I mean that the 37 cents' worth of chemicals
that one often hears about are not what we are, only what we're made of, and
that the scientists' attempts to figure out what consciousness is and why it
evolved is doomed to failure because they're starting with the wrong
postulates.  But, heck, I may be mistaken.  Maybe someday a computer will
pass a really decent Turing test.

I'm not concerned that my profession is about to wither away, though.

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

/* Woe to him inside a nonconformist clique who does not conform with
nonconformity.  -Eric Hoffer */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, January 7, 2022 16:09

I know of languages that have been peddled as human oriented or English
like; I don't know of any that even come close.

--
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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Bob Bridges]

I agree with Shmuel; we heard a lot about 4GLs back in the '80s and '90s,
but I never saw one that lived up to the claims.  DYL-280II, for example,
was advertised as a 4GL, but it wasn't close.  Don't get me wrong, as a 3GL
I liked it just fine, and my company had me teach it to end users so they
could fetch data from their particular databases without throwing off
developers' estimated completion dates -- very successfully, I add happily.
But it was no 4GL.

Actually I lump 4GLs and AI into the same bucket.  They're related, I think:
Folks dream of getting computers to think and talk like a human, but so far
it hasn't happened and I suspect it cannot happen.  But then as a Christian
I'm also a mystic, by which I mean that the 37 cents' worth of chemicals
that one often hears about are not what we are, only what we're made of, and
that the scientists' attempts to figure out what consciousness is and why it
evolved is doomed to failure because they're starting with the wrong
postulates.  But, heck, I may be mistaken.  Maybe someday a computer will
pass a really decent Turing test.

I'm not concerned that my profession is about to wither away, though.

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

/* Woe to him inside a nonconformist clique who does not conform with
nonconformity.  -Eric Hoffer */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, January 7, 2022 16:09

I know of languages that have been peddled as human oriented or English
like; I don't know of any that even come close. 

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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

+There's no forced standard for the choice of ddnames either; you need to know 
whether it's INPUT, SYSIN, SYSUT1 or "E. None of the above."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Friday, January 7, 2022 4:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

Yes, but since there's no forced standard, variables and other methods
mean I might have to look the script or code to figure out what's going
on.  Sometimes that can get quite complex with the things people do that
eventually comes up with a filename/path string.  JCL makes everything
nice and neat and in one place.

On 1/7/2022 12:01 PM, Seymour J Metz wrote:
>
>   Variables and file handles may not be the same as DD names, but they can 
> serve the same function.
>

--
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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

I know of languages that have been peddled as human oriented or English like; I 
don't know of any that even come close. 

As for REXX, I find it comfortable but it too has pitfalls. See, e.g., 
,
.



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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lionel B. Dyck [lbd...@gmail.com]
Sent: Friday, January 7, 2022 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I've been following this thread and one thing that has yet to appear, or I 
missed it, has to do with 4GL's and the drive, at one point, for languages that 
were more human oriented - those that could be written more like a normal 
sentence or phrase, and avoid the technical jargon/gobblygook/syntax. As I 
recall in the 1980's there were a few but nothing came of them, instead we have 
languages that have their own syntax, and which require extensive learning but 
nothing that allows a non-programmer to actually generate a complex business 
program.

>From my experience, REXX has many of the 4GL goals as the syntax isn't overly 
>complex and is something a non-programmer can comprehend rather easily. As has 
>been previously mentioned in this thread, REXX can be more readily learned and 
>used than the majority of the current languages. It isn't perfect but it works 
>very well.

My $0.01 on the topic.

Lionel B. Dyck <><
Website: 
https://secure-web.cisco.com/1939VPwC3cb4S_k-aFsodIU_iOH0Qh5AN_37Xpmk5230u2bpYLvveYqFNVyE5cqqA5UUOBvWUms44mTgRBzmqgOQnnpDnOpCWQT4rxiImRUUcSdDo5JKPcFsR2bTulM1DEC4NxASJQxmD8olXQBxIwRrvsyYEWTZPSinWkW3QoSf3WflAgML4355UQKau5b_NPtePAYNmHgKvwtXpbtN5p8dNfs7H6FR60XxtYrU7JQm-lkxbIpQjUs8_fds71Gzl83emvb1mHvCv0etYw_K4ce5ExwTxVbwfA0AljTVN1Ps2IHaE6n49Fn_Oyxh0MlOQm_zAsvFuyWar2u_zC4snXw1lJT-rDpW59f0VfmaOv78cITkVE90pbyScyfRqTl0fEDIYYcmClCWQolbgMZWgqj0KJi0c5o1FKpZ6Y1vZSZpT1fITKc8x7-t-e0IBfkik/https%3A%2F%2Fwww.lbdsoftware.com
Github: 
https://secure-web.cisco.com/1QmtCmbPfBm0yGGkzxrTVUUDY7L_QNPHyHvLyQeCVs_Zs-halqY4ba0YFDC6zFwt8A3WdwZin9Germ4b4cHsPlyjyiHtqGm_g39bGtNEiS6sx3YqAqLs_jOQM4HEsVE-L5ptkGHxas1QTCdjdsVEgeP-uVxQlYelJE4xp2l-IlkzHsM0Dt6rL6DeHINbBnPjAEeDPI2qHAF9r8NfjphBCVD4_UWG4voy-au3QVl73Zas6okGwRE0oY94_FLzPQ_VJF2AGLjTx48JjQNRu6BWbHKZoi9dRSQ3n_8lMTmOAELH6RALJ1VmIk_Tqcxilzg_H9rfICw7P5cyF8L369iLqkFAuYHW-RZw3mGTpes9Rrnb7QO0SBC6YD5TNgHjdac8bMLy0WHM2zOPC_GFXFTNWttcdmPLkDL9Lzx-W3XJeI5W8rnOttRrlQRlwDp06THj0-G8YJBakOVFXh0HouLY-dg/https%3A%2F%2Fgithub.com%2Flbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Friday, January 7, 2022 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

I agree with your point Bob; we don’t know the future.  I was merely suggesting 
that we need to adapt to the changes not hold on to the past.  Some things 
withstand the test of time and others stay behind.  I suspect none of us have 
3270 terminals but use emulators and I do a lot of my work through SSH and not 
OMVS when in USS.  Python is a newcomer and quite popular … needs updating for 
Z and it won’t replace REXX, it will be a new choice for administrators just 
like Ansible is popular for automation (not the same as System Automation) lots 
of repetitive tasks.

Its a cool future we’re moving into.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 

  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Jan 7, 2022, at 10:05 AM, Bob Bridges  wrote:
>
> Not disagreeing with your main point, Matt.  But to be fair, most of the 
> problem is that NO ONE KNOWS where we'll be fifty years later.  Betamax lost 
> (mostly), so a lot of time and investment and material is wasted.  Oh, well; 
> that's how it works; you try things out.
>
> I couldn't count the number of times I've ripped out a beautifully-conceived 
> function, or method, or entire class, because during the creation of a 
> complex tool I realized that it wasn't what I needed after all.  Sure, I try 
> to think ahead, and 

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Tom Brennan]

Yes, but since there's no forced standard, variables and other methods 
mean I might have to look the script or code to figure out what's going 
on.  Sometimes that can get quite complex with the things people do that 
eventually comes up with a filename/path string.  JCL makes everything 
nice and neat and in one place.


On 1/7/2022 12:01 PM, Seymour J Metz wrote:


  Variables and file handles may not be the same as DD names, but they can 
serve the same function.



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

Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> COBOL was supposed to be that, no?

The use of "magic numbers" as levels in the DATA DIVISION totally blows away 
any claim that COBOL is English like or understandable to someone without 
training.

 66 foo PIC X(10).
 77 bar PIC X(10).
 88 baz VALUE "S", "Y". 

Then there is the weird behavior of COMMENT. In COBOL ends a statement, 
*except* when that statement is a cooment, in which case it swallows the 
remainder of the paragraph. Later versions of COBOL introduce a better behaved 
comment syntax.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Friday, January 7, 2022 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck  wrote:

> I've been following this thread and one thing that has yet to appear, or I 
> missed it, has to do with 4GL's and the drive, at one point, for languages 
> that were more human oriented - those that could be written more like a 
> normal sentence or phrase, and avoid the technical jargon/gobblygook/syntax. 
> As I recall in the 1980's there were a few but nothing came of them, instead 
> we have languages that have their own syntax, and which require extensive 
> learning but nothing that allows a non-programmer to actually generate a 
> complex business program.

COBOL was supposed to be that, no? Managers could in theory at least
read (if not write) a COBOL program and understand what it does,
because it so (superficially) resembles English.

> From my experience, REXX has many of the 4GL goals as the syntax isn't overly 
> complex and is something a non-programmer can comprehend rather easily. As 
> has been previously mentioned in this thread, REXX can be more readily 
> learned and used than the majority of the current languages. It isn't perfect 
> but it works very well.

Indeed.

Tony H.

--
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: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

> Would it be a favor to programmers to make misiplacing IF, etc.
> within a job step, or SET within IF ... ENDIF a syntax error?  The
> effect is probably not what the programmers intend.

IMHO, the current behavior is a bug, but it might take an RFE to get it fixed, 
and IBM might add a compatibility option for installations that depend on the 
old behavior. It should at least generate a warning.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, January 7, 2022 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python 
instead of REXX for z/OS

On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
>
>... I was just
>working on some JCL and I had just assumed that I
>could set symbolics using IF THEN ELSE ENDIF:
>
>// IF (STEP1.RC = 0) THEN
>//  SYMB=GOOD
>// ELSE
>//  SYMB=BAD
>// ENDIF
>
>but I found out that BOTH SET statements are executed
>no matter what the return code is .
>
Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
Ref. is perhaps to specific in listing instructions that are not subject
to IF ... ENDIF rather than describing which control the Converter and
which control the Initiator.

>It also appears to me that I cannot put just one DD
>within an IF statement. It looks an entire step has
>to be in there... I think...
>
And it's truly confusing that if a DD statement is in a step bypassed
by IF (or COND=) allocation, deletion, or cataloging is not performed
but the ENQ SYSDSN is still issued.

Would it be a favor to programmers to make misiplacing IF, etc.
within a job step, or SET within IF ... ENDIF a syntax error?  The
effect is probably not what the programmers intend.

-- gil

--
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: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS

[Seymour J Metz]

The Initiator does the ENQ, not JES. By that time the Converter and Interpreter 
have already run. The condition code is unknown until the job actually runs, 
far too late for the Converter to examine it. The issue transcends the ENQ.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Hobart Spitz [orexx...@gmail.com]
Sent: Friday, January 7, 2022 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL IF-THEN-ELSE-ENDIF Re: ... Re: Top 8 Reasons for using Python 
instead of REXX for z/OS

I think it's worth mentioning that the reason that SET must be
unconditional is that JES has to issue ENQs after, AFAIK, the initial JCL
scan and before execution starts.  If a dataset has an embedded symbolic,
doing the correct ENQ when the value might change at execution time could
cause all kinds of problems, not the least of which is not ENQing on the
intended data set name.

REXX is the new JCL.

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Fri, Jan 7, 2022 at 11:50 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 7 Jan 2022 04:29:52 +, Nash, Jonathan S. wrote:
> >
> >... I was just
> >working on some JCL and I had just assumed that I
> >could set symbolics using IF THEN ELSE ENDIF:
> >
> >// IF (STEP1.RC = 0) THEN
> >//  SYMB=GOOD
> >// ELSE
> >//  SYMB=BAD
> >// ENDIF
> >
> >but I found out that BOTH SET statements are executed
> >no matter what the return code is .
> >
> Even as in assembler it doesn't work to BC bypassing a SETC.  The JCL
> Ref. is perhaps to specific in listing instructions that are not subject
> to IF ... ENDIF rather than describing which control the Converter and
> which control the Initiator.
>
> >It also appears to me that I cannot put just one DD
> >within an IF statement. It looks an entire step has
> >to be in there... I think...
> >
> And it's truly confusing that if a DD statement is in a step bypassed
> by IF (or COND=) allocation, deletion, or cataloging is not performed
> but the ENQ SYSDSN is still issued.
>
> Would it be a favor to programmers to make misiplacing IF, etc.
> within a job step, or SET within IF ... ENDIF a syntax error?  The
> effect is probably not what the programmers intend.
>
> -- gil
>
> --
> 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