Import command from ISPF as ispfcmd
Import command from EDIT as editcmd
rc = editcmd("SEEK 'string' FIRST")
etc.
IBM would need to provide Python interfaces to MVS, TSO, ISPF, SDSF, and all
the other current supported environments.
What I don't know is how hard it is for the various functions to share the same
variable space.
For example, a solution to one of the 2023 AoC puzzles was to use the Z3
theorem prover (https://en.wikipedia.org/wiki/Z3_Theorem_Prover). But this was
confusing to use, because you had to use special code to map Python's variables
into the variables used by Z3. It was kind of like coding ISPF dialogs in COBOL
or assembler, where you have to use ISPF services to connect the variables from
the language to ISPF.
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Seymour J Metz
Sent: Monday, July 1, 2024 4:07 PM
To: [email protected]
Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you!
(Re: z/OS 3.1 Enhancements & Support News
How do you write an ISPF dialog or EDIT macro in Python. The REXX concept of
registering an environment makes it very useful.
That said, TSO/E is way behind the Rexx world. In ooRexx you can iterate over,
e.g., arrays, stem objects. The cobbler's children are barefoot.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of
Schmitt, Michael <[email protected]>
Sent: Monday, July 1, 2024 4:35 PM
To: [email protected]
Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you!
(Re: z/OS 3.1 Enhancements & Support News
> They miss discovering that REXX is the most
> powerful procedural language, bar none.
I think that crown goes to Python now.
I've been doing the annual Advent of Code (https://adventofcode.com/) since
2019. I did the first two years in Regina REXX, then switched to Python. I used
Python 2 in 2021 with no IDE, Python 3 with VS Code in 2022 & 2023.
I had 30 years of experience in REXX at that point, but still was more
productive in Python -- with ZERO years of experience. My first Python program
was the day 5 AoC program in 2021.
The main reason is that REXX only has 2 data structures: lists of words, and
stems. So you're in "if the only tool you have is a hammer, all problems look
like nails" territory. It is like coding using a Turing machine: while it is
technically *possible* to create any algorithm, it is a lot more work than if
you had a language with data structures that directly model your business data
structures.
z/OS REXX makes this even harder, because you can't iterate over a stem. So now
you have to either use just lists of words, or create *two* structures: a stem
to hold the data, and another stem or list to index it sequentially.
Nor is there a built-in way to sort stems. Or search them for a value. Or join
them. And so on.
And I know from the AoC puzzles that very long lists of words will really bog
down the performance.
I'd like to see Python as a first-party scripting language on the MVS side of
z/OS, equal in support to REXX. What I mean is, anywhere you can use REXX, you
could use Python instead. In particular, as ISPF function code. (You'd be
limited to 8 character variable names, just like you're limited in REXX.)
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Hobart Spitz
Sent: Monday, July 1, 2024 3:02 PM
To: [email protected]
Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you!
(Re: z/OS 3.1 Enhancements & Support News
[Some people who received this message don't often get email from
[email protected]. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
I submit that there is something else to consider. People tend to approach
any new language thinking in terms of the language that they were most
skilled in previously. Because REXX is so flexible, there is little need
to learn some of the unique features of REXX. Some people never take off
their "training wheels". They miss discovering that REXX is the most
powerful procedural language, bar none. To cite some examples that I have
observed:..
- Stems are multi-key tables, not arrays.
- Internal routines are almost always faster than repetitive code. The
less code, the less tokenization phase overhead. Internal routines let you
write more general code, and you might hesitate to deal with an unlikely
case where something has to be changed in 30 (e.g.) places.
- The procedure statement and stems can be performance tools. Each has
a structure separate from the simple marin variable pool. Variable
searches focus on smaller numbers of targets than if all were in a single
pool.
- EXECIO 1 is a dog.
- Algorithm efficiency matters, more so in REXX than in other
languages. A recursive Fibonacci function of 100 might take hours or days
depending on the platform. If you save intermediate results in a global
stem, Fib(100) takes seconds or less, only slightly longer than the loop
method.
- Typing and sizing are non-issues in REXX. How often has a compiled
language program needed to be updated because a field length changed or a
table overflowed? Whatever you do in any other procedural language can be
done more easily and with less down the line maintenance in REXX.
I could go on.
OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
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 Mon, Jul 1, 2024 at 1:58 PM Seymour J Metz <[email protected]> wrote:
> probably means here files; inline with the source code.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> ________________________________________
> From: IBM Mainframe Discussion List <[email protected]> on behalf
> of Phil Smith III <[email protected]>
> Sent: Monday, July 1, 2024 2:45 PM
> To: [email protected]
> Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank
> you! (Re: z/OS 3.1 Enhancements & Support News
>
> Paul Gilmartin wrote:
> >Lack of closure: I don't believe a function package, much less a
> >command environment can be coded in REXX. those must be coded in
> >another language, therefore less portable.
>
> Well, that's a good point. OORexx makes that somewhat better, but not like
> P/P. But I could imagine writing an interface to enable this. The tricky
> part with Classic Rexx would be variable passing, but Pipes demonstrates
> that it's quite doable. I think it'd be easier with OORexx, no?
>
> >I've written some utility packages which I concatenate with
> >SYSIN, REPRO to a temporary member, and execute that.
> >Ugh!
>
> You mean so you have your program + "standard" functions, glue 'em
> together, and thus the standard functions are local and can access
> variables easily? Cool. Can't quite imagine doing that on CMS!
>
> >Lack of support for instream data.
>
> Not sure what you mean here--is it that it's not native/trivial to read
> from a DD * in Rexx?
>
> >Lack of elementary functions, made a challenge by the
> >desire to support arbitrary precision. (Can a function
> >package, in whatever language determine the caller's
> >NUMERIC settings at the instant of call?)
>
> No, though I've never wanted that. Not saying it's not a valid
> requirement: had the Rexx ecosystem developed more, stuff like this would
> have become necessary and presumably been enabled.
>
> This is a fun discussion.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
