Kirk,
the sample exec is equal to the class you are using. What you supplied is
the calling program code snip. With a small change to the exec, (PARSE
UPPER ARG KEY replaces the Say & Pull statements) you can class it as a
function. exactly like you do with Java, and it is much shorter from caller
side: Call NewIGGCSI('*.SCEE**').
we changed the sample code for use in our product (IronSphere) and return
the results as a long string using push command. easy as that.
ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM comming son *
On Fri, Mar 27, 2020 at 10:31 PM Kirk Wolf <k...@wolf-associates.com> wrote:
> 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
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
