On Fri, 20 Mar 2020 13:45:05 +0800, David Crayford <dcrayf...@gmail.com> wrote:
>I'm not knocking your code which looks very good, but yet again it's a >good example of why REXX is a poor language for processing binary data. > >I don't use REXX much these days. On z/OS I use either Lua [1] or Python >[2], mainly Lua as it runs in TSO/ISPF which Python doesn't. Both >languages have >libraries for reading/writing binary data (structs). They even handle >endian conversion. > >It's tempting to reach for REXX as the simple option but in many cases >the result is write-only code and technical debt. I believe some people >process SMF records >using REXX which sounds like a can of worms that I wouldn't want to open. > >[1] http://www.inf.puc-rio.br/~roberto/struct/ >[2] https://docs.python.org/2/library/struct.html The problem really isn't with REXX, the real problem is that the CSI API sucks! It's just as complicated to setup and process in other languages. REXX comes with z/OS (and z/VM and I believe z/VSE, don't know about TPF), Lua does not. PL/I and COBOL cost money. Even High Level Assembler costs money! I assume most z/OS shops have it because it's generally bundled with z/OS. High Level Assembler costs extra on z/VM and z/VSE. Lua may be free, but it doesn't come with z/OS and as you have probably noticed, some people on this list would not be allowed to use it. (BTW, is LUA available for z/VM (CMS) or z/VSE?) I was primarily a z/VM Systems Programmer and have been using REXX since VM/SP Release 3 came out in 1983, (the first release to include REXX). I also did some limited installs on z/OS, (prior to MVS/XA!), like the COBOL and COBOL II Compilers. (I started out my IT career as a COBOL application developer.) Due to outsourcing, I no longer work as a Systems Programmer, (except when they need my help, of course). I work for a contracting company that supports one of the major billing systems for the company that I originally worked for. I support the inhouse written VM/CMS code that is used by the z/OS application developers to edit and compile their programs. These systems are written in Assembler and REXX and use various screen managers, like Xedit, ISPF, and XMenu. Within the last 10-12 years, I have found the need to write code for The Slow One (TSO) and use the APIs that are available there. (If you want to see a pretty decent REXX API, look at the one for FTP documented in the "IP Programmer's Guide and Reference".) There are things missing in TSO REXX that are in CMS REXX. There is also a very big tool missing on TSO, namely CMS/TSO PIPELINEs. These two items make it more difficult then it should be to write one REXX program that can run under CMS and TSO, (I have some REXX programs that do that). Anyway, I think I have ranted long enough. In the end, REXX is only as good as the other tools you use it with! -- Dale R. Smith ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
