Well, if Open XL C/C++ is the "wave of the future" then IBM had better plan to also buy and integrate all of Rocket's GNU ports (especially bash) because I for one can NOT work in that @#$%!^ POSIX "sh" they supply at the moment. It is a hideous shell to try to work in. It does not even support using the arrow keys to recall previous commands, the backspace key does not work to let you fix command text . . . I could go on, but what's the point. It is just plain awful.
Or they could do all new GNU ports of their own using Open XL C/C++. I could see that working as well, and it gets around any NIH issue inside of IBM. They also need a plan to upgrade/replace the existing JCL-only XL C/C++. That cannot be allowed to die, nor can MetalC be allowed to die. My USD$0.02 only. Peter -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of David Crayford Sent: Tuesday, May 9, 2023 10:36 PM To: [email protected] Subject: Re: XLC version? [was: RE: XLC - Weak symbols] 2.4.1 is more than a slight update, it’s a completely different front-end. To make it more confusing there are three C/C++ compiler products on z/OS. XL C/C++ is the legacy compiler which supports 31/64-bit and has CICS translation built it. It can run as a batch program. IBM have made no statements of direction but it’s withering on the vine and does not support the latest C/C++ standards. It’s almost impossible to use it for any modern ports. I can’t see this product ever disappearing as it’s required for the old school JCL only shops. That’s not a dig at Peter, we have products that use PDS data sets and are compiled using a legacy SCM product. I find it very difficult to adapt when I work on these products after spending so long building in a shell. XL C/C++ 2.4.1 Web Deliverable is a port of Clang which uses the existing back-end. It’s better than the legacy compiler but it must run as a z/OS UNIX executable. It supports more modern language standards such as C++14. Open XL C/C++ is a full on port of Clang. IBM are working with the open source community. It’s interesting to read the code reviews which include devs from Apple and Google. It’s my understanding that this compiler will replace 2.4.1 some time in the future. > On 9 May 2023, at 12:29 pm, Phil Smith III <[email protected]> wrote: > > David Crayford wrote: > >> They're different products. I can't see a convergence as that would >> be > >> a high impact change to customers and would require Metal/C spinning > >> off. It's far more likely that XL 2.4.1 and Open XL C/C++ will > >> converge. > > Huh, something gave me the impression that 2.4.1 was Open XL C/C++. The fact > that it looks like a slight update to 2.4 of XL C is, of course, a big part > of the problem here! > > I would very much like to understand what's what and what's going where here, > for planning purposes. IBM? Please? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
