I agree with Rony. I think your ‘benchmarks’ are a bit synthetic but I understand your goal. I think calling ISPF ‘a relic’ and constantly badgering Rexx does not serve any purpose in front of this audience, most of which see ISPF as something shiny and worthwhile (e.g. to have on OS VS2 r3.8 (clones of Rexx and ISPF have even been built there recently)).
We know IBM has divested some of its software maintenance. It is important to remember that ’the new mainframe’ *if casted in the image of Windows or Linux* always would be a hampered version of something. The mainframe is a high-end market and not everybody needs one anymore. It could be competitive, but it would need competition, a sane pricing scheme and less RACF admins reared in the 80’s ‘lock her down’ mindset. That last thing, not the toolset, is why it is hard to get new staff in. If good tools were enabled young people would choose them and use them. There is no need for any badmouthing or skewed benchmarks. If one needs fast I/O, one writes assembler or COBOL. It is important to not let new tools loose before their time, and seen the difference in the number of interfaces to the OS compared to Rexx, the time of Python has not come yet. I remember IBM or Rational people demoing the new GUI way of working to grumpy old COBOL programmers, and always having to open a 3270 TSO session to do something or other before the demo could go on. It was a laugh. In the end, it meant that the quality of people’s 3270 emulators went down the drain and they were grumpier than ever. I am sure Visual Studio Code is a nice editor (I sometimes use it on the Mac for markdown, mermaid plugins etc) but it is not going to sell mainframes - there will be VBS to confront, and maybe VSAM. And obj modules. And probably Cool:gen or RPG. What adaptation to modern dinky machines does, is more dynamic memory usage, more senseless multithreading and worse algorithms - just read in that 88MB XML file and shove it into a Db2 column. Where you used to be able to run an LPAR flat out at 100%, you cannot do that anymore because websphere and service oriented architecture. With IBM’s current approach and its horrible handling of its intellectual property (sealing it off from a legal perspective, and neglecting it from a development point of view) the mainframe is going to be a niche market. That is not bad in itself: look at Tandem, long dead but still non-stop running a very large part of cards transactions. If IBM had been serious about the cloud, it would have been forced to acknowledge that it would have been best and cheapest to run it on mainframe lpars in sysplexes and on COBOL, but alas, they were not serious at all and told us mainframe ‘always were the cloud’ but forgot to build one doing what they did best. We like Xedit, we like ISPF. We like Rexx, and we are very fortunate that IBM open sourced Object Rexx and NetRexx before that window closed and the open sourcing was locked down with ‘business cases’. It also meant, of course, they are never going to maintain it again. We now see important parts in the hands of private companies, and we see everything we know built anew, but worse. And, old problems, once solved, are coming back (memory fragmentation anyone?). Transactions? We now have No-SQL but please don’t run my bank accounts on it. My suggestion would be to keep working on new things, but we don’t need the negative propaganda. On the other hand, now would be a good time for IBM to open source and publish everything they reaped the benefits from over and over, instead of allowing it to wither and waste. And IBM should invent some good new stuff. best regards, René. > On 1 Mar 2023, at 12:15, Rony G. Flatscher <[email protected]> wrote: > > On 28.02.2023 20:55, David Crayford wrote: >> I respectfully express my opinion without intending to badmouth anyone. I >> believe that benchmarking the performance of reading a large file is not an >> artificial test but rather a real-world use case that we encounter >> regularly. It is no secret that REXX on z/OS can be slow. In fact, one of my >> colleagues who worked on the IBM File Manager product, which incorporates >> REXX scripting, developed their own subset of REXX because the performance >> of the TSO REXX interpreter did not meet their objectives. > > If that is the case then it shows that IBM needs to maintain their mainframe > REXX by replacing it with an up-to-date version of REXX (finally). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
