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 <dcrayf...@gmail.com> 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 <dcrayf...@gmail.com>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 <dcrayf...@gmail.com> 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, robhbrid...@gmail.com, 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 <IBM-MAIN@LISTSERV.UA.EDU> 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 [robhbrid...@gmail.com] >>>>>>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>>> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
