For many of us that are orphans of the TASID utility on z/OS, with fewer options working with each z/OS release, we have the alternative of using the ISRDDN utility.

It is not the same as TASID, very few options, but there are things that we can do if you know how to use it, as well as if you know how TASID gets the information.

This is a link to the utility description in the User Guide:

https://www.ibm.com/docs/en/zos/3.1.0?topic=i-isrddn-diagnostic-utility

Quick overview of control blocks

A simple example of what you can do with ISRDDN is to look at the contents of memory locations. If you are familiar with IMS, you may have stumbled upon those very weird abends when your SVCs are not properly set up, such as this guy:

  https://www.ibm.com/docs/en/ims/15.4.0?topic=0700-0684  

You start to wonder what is the problem, perhaps the system was IPLed with the wrong volume? You look at the contents of the SYS1.NUCLEUS and it looks fine, but it still fails the start up? This is when I would go to ISRDDN to look around and see if I can figure it out.

In z/OS, there is this thing called control block (or any other platform for that matter), it is basically a memory location that contains system information, usually in the form of pointers or flags. In the example above, I would like to look at one that is called SVCTABLE.

  https://www.ibm.com/docs/en/zos/3.1.0?topic=xtl-svctable-information  

But to get to it, I would have to chain from other control blocks until I get there. Not my intention here to lecture on controls blocks, but basically I would start from the PSA (Prefixed Save Area, at address 0 in memory), go to the CVT (Communications Vector Table), SCVT (Secondary Communication Vector Table), and then the SVCTABLE. Here are the Data Areas Mapping for these control blocks:

  https://www.ibm.com/docs/en/zos/3.1.0?topic=rqe-psa-information

https://www.ibm.com/docs/en/zos/3.1.0?topic=iar-cvt-information

https://www.ibm.com/docs/en/zos/3.1.0?topic=xtl-scvt-information  

Simple overview, the way that it works is that if you browse storage 0, the PSA, at address x'10' is a pointer to the CVT control block. You can do a find for "FLCCVT" in the PSA mapping above and you will see what I mean. If you continue that in the other control blocks, eventually we get to the SVCTABLE.

Getting to ISRDDN

Very simple to get to the main panel of ISRDDN, just type TSO ISRDDN anywhere on ISPF and it will open for you. The link above to the User Guide describes many cool options that you can use, such as browse your allocations, load modules, etc.

Browse memory locations

Back to our example, when you are in ISRDDN, if you type BROWSE address., you can see the contents of that memory location. Example, to see the PSA, just type:

BROWSE 0.

You should see something like this:

That is the PSA. At address x'10' is a pointer to the CVT, which I highlighted, address x'00FD68F0'. If you do another command:

BROWSE 00FD68F0.

You will see the contents of the CVT this time. ISRDDN supports indirect addressing, if you are familiar with that, so you can just type a chain of addresses in one command and get directly to the SVCTABLE. There is also the option to allocate a file under DDname ISRDDN to your user's concatenation and define symbols. Here is a description on how to do it:

  https://www.ibm.com/docs/en/zos/3.1.0?topic=utility-defining-named-storage-locations  

Directly from ISRDDN it would be like this:

B 0.+10?+C8?+84?

Looks like a cat walked in my keyboard. : )

That is storage location 0, then location pointed to by address at offset x'10', then location pointed to by address at x'C8', then location pointed to by address at x'84'. That will position at the very first SVC entry in the SVCTABLE. Each entry is 8 bytes, the first 4 bytes are the address of the SVC and then other 4 bytes are flags.

That looks complicated to see. We can do better and format that a little bit. As I mentioned, it is a memory table with 8 bytes entries in sequence. There are 256 entries, each with 8 bytes. We can use the ARRAY command to format. The command expects two arguments, number of entries, and size of each entry. In other words:

ARRAY 256 8

Looks better now, each SVC entry is one line of data:  

You will notice that I positioned and highlighted two entries, x'CB' (203) and x'CC' (204), those are the IMS SVCs in the system that I am working. The real numbers are actually 202 and 203, but the SVCTABLE starts at index 0 and the display of the array starts at index 1, so we have to subtract one from it. The first 4 bytes of those entries are the address of the SVCs, we can just browse that address and see the contents:

BROWSE 00FD2000.

I use this to verify if the information matches what I expect to be defined. You can do the same with other control blocks, with load modules, etc. Just keep in mind that the concepts of virtual memory applies and there is storage protection, you may not be able to see information if that is fetch protected of if it belongs to another address space.

It is fairly simple to write a Rexx program to do that, it is just chaining the addresses until you find the table and them find the entry in the table, basically it is ((svc_number * 8 bytes)+svctable_address). A few BITAND commands in Rexx and you have the information about the flags as well.