On 7/3/23 16:59, René Jansen wrote:
On 7 Mar 2023, at 08:45, David Crayford <dcrayf...@gmail.com> wrote:
The industry has spoken! Python is the most popular programming language in the
world so haters will have to just suck that up.
That is a very funny statement. Nobody hates Python - the hype will blow over
like Perl, Visual Basic, Ruby, COBOL, etc. O wait, there is still tons of COBOL
around, like there will be tons of Rexx around for ages.
Agreed. And there is lots of REXX on the mainframe.
While we do not hate Python (it was a great television series in the seventies)
we can do without the attacks on Rexx. Like the JCL replacement from IBM’s
Clunkification department, the examples will speak for themselves. Look at it
in all its glory, coming in at 190 lines plus lots of imported zooutils, at
https://github.com/IBM/zoau-samples/blob/main/samples/smpe_list.py - it
replaces about 15 lines of JCL. If that was meant to undercut the credibility
of Python, it is a very, very clever attempt by an old mainframer.
If I now ask ChatGPT for a script to list some SMP/E zones, it shows me:
/* REXX program to list the status of all SYSMODs */
/* Set up the SMP/E commands to be executed */
smp_cmds.1 = "SET BDY(GLOBAL)."
smp_cmds.2 = "LIST SYSMOD(*) WHERE(SYMBOLICDATE GT 0)."
smp_cmds.3 = "SET BDY(LOCAL)."
/* Write the SMP/E commands to a temporary data set */
"ALLOC F(SMPCMD) NEW REUSE SPACE(80 80) TRK"
do i = 1 to smp_cmds.0
"EXECIO 1 DISKW SMPCMD (STEM smp_cmds. " i ")"
end
"FREE F(SMPCMD)"
/* Invoke SMP/E to execute the commands */
"ADDRESS TSO"
"CALL 'SYS1.SMP.EB2A.EXEC(SMPXMSGS)'"
"EXECIO 0 DISKR SMPXMSGS (STEM smp_msgs. FINIS)"
"FREE F(SMPXMSGS)"
/* Display the results */
do i = 1 to smp_msgs.0
say smp_msgs.i
end
There's bugs in that code ;)
I rest my case. Still not sure why JCL needs to be replaced but hey.
100% agree. Can't say I'm a big fan of JCL but it does the job.
The curious case with Rexx is that it has been under attack from the beginning,
like all good things within IBM, like VM and JES2. Later, in OS/2, it was
relentlessly attacked by Microsoft and almost left out of it, only to be
introduced in the IBM EE “Extended Edition”, possibly because it was better
than BASIC of the day.
Interesting. I know it seems like I'm always attacking REXX but I would
suggest that I'm criticizing, not attacking. I used to work on NetMaster
back in the 90s and danced a jig of joy when I could use REXX instead of
NCL. I ways also delighted when ISPF supported inline REXX panel exits
so I could avoid horrible panel logic.
These days I spend most of my time on z/OS using a bash shell. I have
written REXX scripts that use the SDSF API to interact with the spool,
console etc. I also like REXX to write scripts that call batch programs
redirecting the output to stdout/stderr etc so I can spawn batch
utilities from UNIX processes such as Java web servers. For short
scripts REXX is an excellent language. However, I don't think it scales.
One glance at the ISPF DTL compiler which is 42KLOC confirms this.
/* REXX */
parse arg script_file
if script_file = '' then do
"Usage: kciomega <script_file>"
exit 2
end
call syscalls 'ON'
address syscall 'realpath . cwd'
address syscall 'realpath 'script_file' script_file'
call BPXWDYN("ALLOC DD(SYSPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY)
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(SYSOUT) PATH('/dev/fd2') PATHOPTS(OWRONLY)
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIPRINT) PATH('/dev/fd2') PATHOPTS(OWRONLY)
FILEDATA(TEXT) MSG(2) REUSE")
call BPXWDYN("ALLOC DD(KCIFLOW) PATH('"script_file"') FILEDATA(TEXT)
PATHOPTS(ORDONLY) MSG(2) REUSE")
address ATTCHMVS "KCIOMEGA"
call BPXWDYN("FREE DD(SYSPRINT)")
call BPXWDYN("FREE DD(SYSOUT)")
call BPXWDYN("FREE DD(KCIPRINT)")
call BPXWDYN("FREE DD(KCIFLOW)")
Rexx always has been the tool of systems staff, who, while disallowed to do any
programming, saved many an application (and company) with Rexx, and rubber
bands. This is why this is such a strange forum to attack Rexx on, and I wonder
if you just cannot help yourself, or it is some officially sanctioned action,
somewhat akin to the movement of replacing some easy to use SMP/E JCL (the plot
comes together here, the unconscious hints give at away) with endless dialogs,
like young IT people want to be turned into clerks doing spreadsheets.
I was just responding to Peter Farley's post WRT I/O performance which
gave me an opportunity for a shameless pyzfile plug ;)
So why don’t you indeed port ooRexx to z/OS, and see what happens? You can
change the threads structure, VS Studio Code has nice tools for that. It would
be a constructive addition to the discussion. And it would prove some points,
like porting to z/OS is easy and IBM now embraces open source, and that that
decision to not port Object Rexx has been walked back.
I haven't got the spare cycles to port ooRexx. I managed to build it in
the naughties but it was full of bugs. That was and EBCDIC port. I don't
do EBCDIC ports anymore (nor does Rocket or IBM). A feasibile port of
ooRexx would use the new LLVM/clang compilers and use enhanced ASCII
with file tagging. That's probably not what the majority of REXXers on
this forum would want. They want ooRexx to be native EBCDIC and for the
scripts to be in PDS data sets. And integration to TSO/ISPF and all that
stuff. I can assure you that is a VERY heavy lift.
best regards,
René.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
