In what way is OS/2 remotely similar to Unix? Are you thinking of the pipe and redirection characters in the command line? If so, yhat's pretty tenuous.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Jon Perryman <jperr...@pacbell.net> Sent: Wednesday, July 3, 2024 12:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx is quite cool, flexible, powerful, feature-rich, thank you! (Re: z/OS 3.1 Enhancements & Support News On Wed, 3 Jul 2024 13:19:13 +0200, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote: >No, it was *not* designed for Unix. It is available for Unix, Windows, Apple, >and many more >operating systems. While they may not adhere to the UNIX standards, those OS's are for all pratical purposes a UNIX variant with very similar concepts. While there are some differences, they are not completely foreign like (z/OS, z/VSE & z/VM) where OORexx will have major compatibility issues. >By the way, the first operating system IBM released ooRexx was OS/2 Warp. ooRexx was probably a simple port because of it's similarities to UNIX. >Object REXX/ooRexx has all address environments that have ever been > written for Rexx as it offers the REXX SAA interface, I'm not bashing ooRexx. I'm sure that it's a great language but as a product developer, my products effortlessly integrate in IBM REXX. > The availability of C++ APIs is one of the reasons why it has become quite > easy to integrate ooRexx with any OO system. Where is IBM REXX being used for complete applications where OOP is useful? Automation is the largest REXX user but OOP is of little use. TSO uses rexx for environmental setup and small problem resolution. >is also responsible for making it possible to implement Java interface and >abstract classes in >ooRexx classes, implementing abstract Java methods in plain [oo]Rexx! :) This is a nice feature but are these the types of problems that z/OS users want to solve using REXX? Why not just use JAVA directly since ooRexx must use it under the covers for processing Java methods. >With the Java bindings, you can integrate ooRexx with any complex application >system that offers >Java APIs, like SAP [1], PeopleSoft [2], and many more. IBM REXX environment integration is a 0 step implementation for the customer and end user. On the other hand, ooRexx requires some configuration for each ooRexx environment to be used. At a very minimum for each environment, you must define the Java libraries. For more complicated products like SAP, you must install the SAP Java connector. While these tasks seem trivial, you must remember an end user may want to use this but a system admin typically performs these tasks and must perform these on each system where ooRexx is needed. This is not automatic like in z/OS. >This support is available out of the box for Windows, Linux, and Apple. You >write one ooRexx script >on Windows and can run it unchanged on Linux or Apple, and vice versa. These are compatible UNIX variants where everything is similar. IBM Rexx exec's are not portable between z/OS, z/VM & z/VSE. The same is true for ooRexx. >> z/OS REXX on the other hand automatically integrates into most available >> environments. >Yes, because IBM created REXX and integrated it in z/OS. Too funny because REXX is not integrated in z/OS. REXX was originally written for VM and designed to be disconnected from everything by dynamic ADDRESS environments. It can be a challenge to find the REXX anchor control blocks because of the REXX execution environment (e.g. CICS, IMS TSO, automation & more). Instead of integration, it is a REXX design philosophy that does not make it OS dependent. >The problem is that IBM has never improved the REXX language on the mainframe >in the past decades, Do you think it's a coincidence that variables can't be passed between REXX members nor the ability to pass stem variables? Ask yourself why automation products implemented this capability instead of making it common to all REXX environments. I'm guessing that the lack of improvements to REXX is more about discouraging it's use as an application language than simply not improving it. >Now, ooRexx being TRL2 (and much more) would improve the productivity that >REXX allows in a >remarkable way. Hence, if offered on the mainframe, then it would allow for a >huge jump to a modern >version of REXX, buying a lot of functionality and productivity for the >customers. No doubt REXX productivity could easily be improved but there must be underlying reasons for not doing so. My guess is to limit the language use to solving trivial problems. ---------------------------------------------------------------------- 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
