On 7 Jan 2022, at 08:44, Matt Hogstrom <[email protected]> wrote: > > I concur. The challenge as we all know is that technology evolves over time > and is implemented in what we know and works versus where we’ll be fifty > years later. The absolute strength of Z is that people are not left to have > to keep rewriting what has been done and invest more time and money moving > things along. IBM has done a good job at preserving investment at the cost > of lost velocity on the platform. This is why I think Frank’s comments and > request to consider Python (this thread) is so active. > > A path forward that would make sense would be a new job control language like > HELM that is familiar and modern and Kubernetes is the scheduler that runs > the jobs. Embracing the new paradigms along side the existing models is what > we as practitioners need to do. Tech that has existed for years has its > place and benefits; it likely is not the future. Z is part of the cloud and > must responsibly embrace those models without sacrificing what is good. I > like the Eagles, they are not producing new music so I listen to new music > and see what I like. We need to not get stuck but plot a path forward. >
I think those are wise words. On the other hand … I also like the Eagles. Here in Latin America there lately is a particular kind of music that I generally not like too much - reggaeton with voices in autotune. You would not like it if you visit a concert of an Eagles-cover band (let’s call them the z/Eagles) and they only play reggaeton. Well, I would not like that. There is the ratio between greater (better/faster/more abstract) fitness for purpose and newness. Thanks for pointing me to HELM. I cannot discern yet if I like that, but more importantly, why it should be the JCL of Kubernetes. What I do know, is that the portrait format of JCL is much preferable to a very long shell command command line (that wraps or even vanishes on the right). Even with the use of environment variables, it is harder than with JCL to see what actually happens. The proof of that is the instability of the applications that are run that way. The parallel with build systems was made earlier, and I think there is a point there. When NetRexx was open sourced, I built that with a makefile. But the team decided that ANT was the way. Because modern and multiplatform, but the thing with ANT is that you need tasks for everything, this are written in Java (well, NetRexx in our case), and guess who is fixing the errors now, some of them even because Oracle cannot leave Java be (after the painful changes because of the JPMS, now the SecurityManager has been taken out, breaking the <java> task of ANT itself). And yet we know that people moved to Maven, then to Gradle, and from xml to json and yaml (hint: binary formats like compiled copybooks, or if you want, protocol buffers, are very much more efficient). I don’t know what you think, but I do not consider that to be useful work. It might be for the short term, and if you have something to sell by hype. I prefer cmake and ninja, for the purpose of covering the most platforms and yielding the speediest builds with a reasonable DSL (as opposed to autotools and sh, make). For the purpose of controlling jobs, JCL is not at all bad. The L is from Language by the way, so Fred Brooks’ statement that they did not know they were building a language is questionable. Not every DSL needs to be Turing complete. Some should not be, that is what my operators taught me, and the stability of the z/OS batch system shows that every day. “Backing the wrong horse” (Swift, PHP, and a slew of other things that did not pan out) is a symptom of a closed environment. Working on Clang/LLVM is indeed much smarter because then the customers can port what they want, but then enabling people to develop without prohibitive cost is a must. Instead of backing one product again, knocking your own traditional environment, and seeing how that turns out in a number of years, and nurturing discontent with younger people. We see the handling of the Redbooks thing and the z/PDT Personal Learner’s Edition and we can literally smell the panic. Now that computing became available to more people it is not strange to see that the tastes and trends change faster and faster. I need to make a website but what I did in AngularJS a number of years ago does not even work anymore with the new version. This is why I oppose the use of the word “luddites” here and there in this discussion; we are only embracing new things all the time, but so very few of them last more than a few years. It was IBM’s strength that it invested a lot in very well thought-out architectures that embrace the essence of the purpose; only, after earning billions, it forgot to give those back to the community that supported it; also a lot of that investment was public money on defense contracts. If it had put VTAM in a box and called it LAN Server, we would not have needed PC DOS and its problematic heritage. The failure to execute the core business led to the whole PC department - the RISC people within IBM already knew better. If there was a good development environment for z/OS available for a larger group of people, we would have had Object Rexx available a number of years ago. And then people can make their own choices, and write their own DSL’s or larger translators. I like David’s list of requirements for a language, and I am sure it will be input into a newer version of something that looks like Rexx; that should have happened a long time ago. For the moment, I would appreciate to know what exactly the problems were in porting ooRexx, so we could maybe try and finish that when a development environment becomes available. Best regards, René. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
