Dale, Respectfully I disagree - CSI is not equally complicated to setup and process in all languages.
Here's the IBM shipped z/OS java sample that sets up a call: https://github.com/zsystems/java-samples/blob/master/CatalogSearchSample.java ... CatalogSearch catSearch = new CatalogSearch(filterKey, 64000); if (args.length == 2) { catSearch.setEntryTypes(args[1]); } int datasetCount = 0; try { catSearch.addFieldName("ENTNAME"); catSearch.addFieldName("VOLSER"); catSearch.search(); while (catSearch.hasNext()) { CatalogSearch.Entry entry = (CatalogSearch.Entry)catSearch.next(); if (entry.isDatasetEntry()) { ... This particular sample program uses the com.ibm.jzos.CatalogSearch class (which is included with the z/OS Java SDK, which is included with z/OS). It does a CSI for a given filter key, then for each returned dataset entry it looks up the Format1DSCB. It also resolves VOLSERs that are system symbols. The sample code is less than 100 lines. REXXers: please provide a REXX example that does the same thing as this sample so we can make some fair comparisons. On Fri, Mar 20, 2020 at 6:33 PM Dale R. Smith <dale-sm...@columbus.rr.com> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
