Why not the more powerful PCRE? Note that Lua is also an implementation language for, e.g., Firefox.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of David Crayford [[email protected]] Sent: Thursday, January 6, 2022 8:05 PM To: [email protected] Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS Forgot to mention. Support for functional programming map, reduce, filter etc. REXX does support ECMAScript regular expressions on z/OS if you use my package https://secure-web.cisco.com/1X3C9QcigwcCl8-jZ4gngXIPXjjcQ-01pEsoZx0DdhUf_u0z9FnkpDW1a6xYU5acdnlnzueFN6b9IZ0Hs1vNFDmyXIzLOG-nieCui-CY1S2EHaOg9maQXpwIf4E66ljnh4y3NygUgt0kFYQjDjbdWf6vGdbzwUD_JxTtMeLIMQ_KwaZmjMwGEG9qJYhLpPAYH89_sMfty0jYIpUH-TVtyimyVi5jsqDtSrKGzfpk-UDjHqBlsnhWpbFsWBeHoijbE2Zkcmp_AlYzQ9cdm8BtWO1pDV7grukrGanEqlXArFjbXNDbbYV_L3LVPkCr1ag2ZPSjwaVPvJy_weWLK2Scvd_JxtNpHjJJjNZn2k5CzYzjPmA5tApiEga1G4I1iUKJdz2p0-5mDWXLZ-211Ek8dE0GhE3fo2EgRiMrcvKaMNfyl5OvixglBY0g8uTQ6HIy5/https%3A%2F%2Fgithub.com%2Fdaveyc%2FRTK. 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://secure-web.cisco.com/1scJmLnbBLstkXq-aWhsMcW2LfP6Kzt-KPcOim9SD_a9QKsO4wNZz2GnuFGM90MQXY6yk8vVV55OjUddXpyLtKWbD8QPSrU4Hj-ONfjETjcmNVu0MtnvhrthZ1-jzVzdJrBTz8FUeaVwrAyWbA34U6rBiAwIL_EzTh0CDA1KBb5FBO1JgCGDpa5X_VwXnT8wPgEFEUWRW9uexiriTueD6Sx3vT7t0MnMTwzd1dICcjftPitfI4LqpHqwdNQr5pg46hVmkofVx4_0ZmkRQqLjdCMUXNWr0SuUIIqsDWT12ko9B9quNDBnGPctQYYwX0JkoPh8vRZhRKUrpttqrPg8pHml3HzWppODOYW-2R_MnXwNOXtI8aPmu17Le7BFO-CPl_Wxlj2jloXBs8_57C-FaORq93eA9iz9VZ0MXPmAhpeDXCs0ZVY0JwyAaaIj6JKVVLSj4JL5y5TwPW3Mgn7JKBw/https%3A%2F%2Flua4z.github.io%2FLua4z%2F On 7/1/22 8:56 am, René Jansen wrote: > ooRexx meets most of those, we can discuss 1,2 and 5. NetRexx does as Java > does. > > Sent from my iPhone > >> On 6 Jan 2022, at 20:47, David Crayford <[email protected]> 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 >> >> It's my understanding that IBM dropped Swift because there was no interest >> in it. They have since ported Golang which is more useful. For example, >> running Prometheus/Grafana natively on z/OS or Docker. >> >>> On 6/1/22 7:46 pm, René Jansen wrote: >>> Answers inline. >>> >>>> On 6 Jan 2022, at 04:54, David Crayford <[email protected]>levelled. If >>>> young employees don’t want to work on 3270 tube images or JCL, maybe we >>>> should stop hiring prima donna’s but instead disadvantaged people who want >>>> to work and learn something. >>>> >>>> It's insulting to call young people prima donna's just because they don't >>>> want to use 3270 or JCL. Are we pima donna's because we didn't want to use >>>> paper tape and typewriters to write code? Technology moves on and the >>>> mainframe has to keep up. And I'm happy that IBM are doing a brilliant job >>>> of doing that. >>>> >>>> >>> I used all of those including punch cards. It was needed at the time. You >>> did not parse the sentence right, it started with if, and young is just an >>> adverb. I know some old men here that categorically refuse to logon to z/VM >>> - they also are prima donna’s. So don’t make it look like I said anything >>> about young people. I know a lot of young people who work on 3270 and don’t >>> complain. >>> >>> >>>>> Tragically, the true value of the mainframe, which is realized in all >>>>> those products you call old, is not realized in those ‘modern’ >>>>> programming paradigms - remember the first TCP implementation for MVS ? - >>>>> it ran like a dog and chewed up whole lpars while VTAM still did the >>>>> work. This was of course because it was a straight port of the code for >>>>> some other architecture. >>>> Have to disagree with you there Rene. I work with the guy who was the >>>> architect for OMVS back then and TCP was implemented in Pascal with a crap >>>> compiler. It's a topic of nostalgic jokes on our internal slack channels. >>>> >>>> >>> If you have seen the code then you must know that it did not really utilize >>> the channel architecture. We are talking pre-omvs. OMVS needed TCP and not >>> the other way around. The second Pascal version was a lot better because it >>> understood architecture. >>> >>>>> Moving to other tools while they are not ripe for the environment would >>>>> be irrational. I don’t know what happened to the budget for Swift on z/OS >>>>> but I hope you see what I mean. A port of Python that is not ready will >>>>> accomplish the same thing. Your prima donna’s will complain that library >>>>> X, Y or Z is still not available on the mainframe and pressure their >>>>> management to go off it - I see that happen every day, while fighting >>>>> performance myths and disasters caused by ‘modern’. It is undeniable that >>>>> git - which I love and use every day, is much more complicated on z/OS >>>>> because of EBCDIC, access methods, records and block sizes. This is the >>>>> reality and we should not deny it to please people who learned to >>>>> allocate a file with ‘touch test.txt’. They will get stuck without that >>>>> knowledge and hate their work even more. >>>> A Swift port wasn't expensive. IBM had already ported LLVM to z/OS using a >>>> ported front end and their TOBY back-end so it was just a matter of >>>> interop. Same with golang etc, etc. Now there is a real z/OS port open >>>> source port of LLVM the possibilities are endless. Why not be positive >>>> about the future? >>>> >>> Another suggestive statement. I can argue with you about facts, without >>> accusations and suggestions. Can you? I worked with the Swift compiler, to >>> sort out some things for a colleague. I liked it and am disappointed IBM >>> now decided, over Medium, to push Python, which I find decidedly mèh and >>> not innovative at all compared to Swift. While knocking Rexx without any >>> valid content. Because it is old? Exec and Clist are old, and I don’t need >>> to say anything bad about it, they just are available and keep running. >>>>> We all have different tastes and that is one thing, another thing is when >>>>> that taste is driven by commercial interests. And still another when >>>>> those interests are going against the best interest of the platform. >>>> The best interests of the platform is maintain the system of record and >>>> the legacy and then modernize. Otherwise, the platform with wither on the >>>> vine. >>>> >>>> >>> I worked on systems in the other side of the ocean on a pensioner’s adsl >>> (half the cost, half the speed). The only thing that works well is 3270, >>> and technical people must know why it is better than RDP. While putting >>> Racf on a z/VM and protecting the tcpip too well, I had to fall back to the >>> emulator on the HMC. I am still dreading the moment that might happen again. >>> >>> To keep this alive, IBM should invest in Rexx, provide an OO version and >>> make sure the compiler, which generates revenue, is uplevelled to 64 bit. >>> If it chooses to back Python, that is fine with me, but it can be done >>> without pitting it against Rexx. The adoption of Rexx was a groundswell >>> against IBM management, that made strategic choices at the time like we >>> need to use TSS, go off VM and convert to JES3. >>> >>> Then of course it should invest in Python to make sure its interfaces can >>> call 24, 31 and 64 bit code, use or replicate the existing ADDRESS >>> environments, and that will be a lot of work. Then it is to be seen if that >>> investment can be recuperated. >>> >>> What would be even better is to let the customers decide and develop. For >>> some reason IBM stopped taking care of the tools that brought in the money, >>> and instead of letting customers take care of them, it sold off or >>> outsourced a lot of stuff. There are a lot of people willing to work in >>> this, but the source is closed and the development environments expensive. >>> *That* is the real old-world thinking here. Other companies (I heard >>> Amazon, lately) are writing whole API compatible layers now to enable >>> companies to re-platform their stuff, those must be enormous investments, >>> and IBM could obviate them with opening up the development environments and >>> right-pricing the OS and hardware; put in a services model. It is no >>> coincident that a machine with only IFL’s in it is a tenth of the price? >>> Those miss one or two instructions - and that exactly shows you the value >>> of z/OS and other things that are being called old. >>>>> Best regards, >>>>> >>>>> René. >>>>> >>>>> >>>>> >>>>> >>>>>>> On 5 Jan 2022, at 05:20, David Crayford <[email protected]> wrote: >>>>>> On 5/1/22 12:01 pm, Bob Bridges wrote: >>>>>>> Hm. If that's true of many shops (and it sounds plausible), maybe my >>>>>>> sneers at the colleges' ignorant comments are ill-founded and they may >>>>>>> be starting to win their war against the mainframe. Of course, if >>>>>>> their efforts have a lot of effect then surely the need for CICS will >>>>>>> reverse the trend...wouldn't you think? >>>>>> I don't think the universities have got anything against the mainframe. >>>>>> They don't have access to them. IBM should make mainframe emulators >>>>>> freely available to all universities. Some of our best young guys have >>>>>> degrees in engineering, not CS. It takes a long time to train new hires >>>>>> on the mainframe. For example, JCL is arcane and generally despised by >>>>>> kids who have grown up coding shell scripts. As you mentioned CICS it's >>>>>> worth noting that CICS supports both Spring Boot and Node.js. They set >>>>>> the standard for modernization. The open beta has a new has a new YAML >>>>>> file for resource definitions that comes with a JSON schema so you can >>>>>> get context assist in editors and validation in the DevOps pipeline. The >>>>>> CICS guys innovate and modernize. I salute them. >>>>>> >>>>>> >>>>>>> --- >>>>>>> Bob Bridges, [email protected], cell 336 382-7313 >>>>>>> >>>>>>> /* [On the observation that every culture has words equating >>>>>>> "uncivilized" and "foreigner":] Tragic? It's sidesplitting! It's the >>>>>>> only joke the Almighty ever repeats, because it never grows stale with >>>>>>> use. -from _Star Beast_ by Robert A Heinlein. */ >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: IBM Mainframe Discussion List <[email protected]> On >>>>>>> Behalf Of David Crayford >>>>>>> Sent: Tuesday, January 4, 2022 21:48 >>>>>>> >>>>>>> It's true. The company I work for has been on-boarding millennials for >>>>>>> years now to replace the guys that are retiring. I work with some very >>>>>>> smart young guys, some of who write systems level code. None of them >>>>>>> use REXX unless it's used in a product they are working on. We're >>>>>>> ripping and replacing decades old build tools written in REXX with >>>>>>> Python because it's become technical debt and no one can support it. >>>>>>> >>>>>>> The typical millenial uses: >>>>>>> >>>>>>> * An IDE such as VS Code, IntelliJ, Slickedit with plugins for >>>>>>> mainframe languages and to access the MVS file system. >>>>>>> * They don't use TSO or the ISPF editor so there is no need for REXX >>>>>>> edit macros etc. ISPF is mainly used for SDSF and submitting jobs. >>>>>>> * They work in a interactive shell and use UNIX utilties. >>>>>>> * Everything is stored in Git repositories. >>>>>>> * They code scripts in Python, Node.js or a JVM language. >>>>>>> >>>>>>>> --- On 5/1/22 10:06 am, Seymour J Metz wrote: >>>>>>>> That's David Crayford, not me. I have no basis to either confirm or >>>>>>>> contradict. It's unfortunate if true. >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: Bob Bridges [[email protected]] >>>>>>>> Sent: Tuesday, January 4, 2022 9:03 PM >>>>>>>> >>>>>>>> Shmuel, I'm interested (and perhaps a little dismayed) at your third >>>>>>>> point. I've gotten the impression, from reading ads about job >>>>>>>> openings, that REXX programmers aren't very thick on the ground even >>>>>>>> at IBM where you'd think it'd be pretty easy to find them. But >>>>>>>> "shrinking by the day"? Where do you get that? I'm not disagreeing >>>>>>>> -- I have no data -- but have you? >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Crayford >>>>>>>> Sent: Tuesday, January 4, 2022 19:23 >>>>>>>> >>>>>>>> 1. IBM are too busy porting contemporary languages like Python, >>>>>>>> Golang >>>>>>>> and Node.js >>>>>>>> 2. No vendor will port ooRexx because there is no market for it >>>>>>>> that is >>>>>>>> willing to pay support >>>>>>>> 3. The pool of REXX developers is shrinking by the day and no young >>>>>>>> people want to learn it unless they have to >>>>>>> ---------------------------------------------------------------------- >>>>>>> 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 > ---------------------------------------------------------------------- > 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
