> It's my understanding that IBM dropped Swift Wow. Swift was the flavor of the month a couple of years ago.
Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, January 6, 2022 4:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS 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
