Do you mean write HLASM code that populates IPCS equates or REXX variables?
If there are control blocks that you just want to display, I would use CBF with BLSQMDEF, BLSQMFLD and BLSQSHDR macros defining your fields; you don't need VERBX for that. ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Joseph Reichman <reichman...@gmail.com> Sent: Thursday, October 12, 2023 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS and Rexx Seymour starting with verbx in the assembler to generate structure symbols Then for debugging with runchain etc I’m going to go with Rexx > On Oct 12, 2023, at 4:03 PM, Seymour J Metz <sme...@gmu.edu> wrote: > > 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 ---------------------------------------------------------------------- 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
