It also depends on your experience level. I'm comfortable writing REXX-aware functions in HLASM, but that might not be the best choice for someone just learning. Using parse or substring is easier, although tedious.
If Joseph just wants to display them then CBF is clearly the way to go, but I don't know how much processing he wants to do. Maybe a hybrid approach? ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Tony Harminc <t...@harminc.net> Sent: Thursday, October 12, 2023 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS and Rexx On Thu, 12 Oct 2023 at 07:29, Joseph Reichman <reichman...@gmail.com> wrote: > I understand my only question is to get it clear to CREATE a structure > aka control block this can only be done using the BLSQ assembler macros > > I agree any other processing I need to do I’ll do it in Rexx > I suggest you think about what you want to accomplish. If you want to have IPCS format your control block and display it, then sure - use the BLSQ macros, and then issue CBF. This is essentially adding your CBs to IPCS so IPCS can produce the same kind of thing you get from the SUMMary and ANALYZE and CBF commands, which - if you issue all of them - is pretty much like reproducing a printed SYSUDUMP. You then do the work of figuring out what went wrong. But then what's the REXX doing? In my view the benefit of using REXX in IPCS is that it can do analysis, and as I said, can go through your (and IBM's) control blocks to discover anomalies, summarize the status of things *with knowledge of and from the point of view of your application*, and perhaps interact with you as the analysis proceeds. You can certainly issue CBF (using your CB definitions) from your REXX code - nothing wrong with that. But again, it might be more useful to have your REXX go through your CB directly (not through formatted output from CBF) to discover what's gone wrong. It depends on what you want, and that may be very different from our case as an ISV. Our need is first to promptly get an idea of what a customer dump is about, and how it relates to the ticket they've opened. We routinely run a REXX program that summarizes things - is our product actually running (we get plenty of dumps that don't capture our code or where the product isn't even installed or was never started or the dump is from the wrong LPAR or from last year), what version is it, what fixes are applied, a list of the module eyecatchers, what abended (if anything), how long has our code been running (sometimes it abended at startup - other times it's been running for 6 months), etc. etc. This saves a lot of time in initial analysis. Then we have the background, and can go on to more detailed look at what went wrong and how it relates to the reported symptoms (abend, hang, wrong results, performance, etc.) For this second stage we can, as I described earlier, format useful information from our own and IBM's CBs, summarize and drill down into the status of our work queues, and so on. If you are just debugging your own code in your own dev/test environment, then your needs will be quite different. If you'll explain what you want to accomplish, then I'm sure people will have further suggestions. Tony H. ---------------------------------------------------------------------- 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
