Todd Burch wrote on 02/03/2006 11:57:09 AM: > Reading through IPCS customization, it is not clear to me how to go about > accessing data in the dataspace through a verbexit. > > I would typically use the Storage Access Service (Chap 10.2.18) to acess > data in a dump, but it says right up front to use the Storage Access > function of the Symbol Service (Chap. 10.2.20). > > In the Symbol Service, I have to supply an ESR, which in turn describes the > ASID of the owning dataspace and the DSPNAME itself. OK so far. > > What is not clear to me is where to supply the address within the dataspace, > or the length of the data I want returned. Do I have to create a symbol > (using the Equate Symbol Service) for each address/length I want to > (programmatically) look at in the dataspace? Seems like a pain. > > On the other hand, I considered using the Storage Map Service (Chap > 10.2.19), as this indicates dataspace access is supported. But, similarly > to the Symbol Service, I have not figured out how/where to specify the > address & length of storage I am insterested in.
The BLSRESSY (symbol service) and BLSRSASY structures both use three elements to talk about the dump data of interest: 1. A BLSRDATS structure (field name suffix AS) that you've characterized accurately. It tells IPCS what address space (broader term than you generally hear being used to discuss z/OS) is of interest. A large variety of address spaces are supported in various contexts, including ASID(a) DSPNAME(d). Part of IPCS considers every address space to have full 64-bit addresses. Some front-end functions notice that you really cannot talk about addresses beyond 1040 in a HEADER record and that most data spaces are still limited to 31-bit addresses. 2. An address that comes in two flavors, depending on whether you asked for an ABITS(64) structure or accepted a default ABITS(31) structure. The former is a 64-bit address, and the latter is a 31-bit address in a 32-bit field. In all cases the field name suffix is LAD for "logical address". The logical address is the value that you expect to find in other blocks that point to whatever is being discussed. In the case of blocks like TCBs, UCBs, RBs, ASVTs, JSCBs, and at least a few others, it is not the address of the first byte occupied by the thing being discussed. 3. A BLSRDATC structure (field name suffix D in BLSRESSY and F in BLSRSASY) that supplies an attribute bundle including offset, length, and one-dimensional array characteristics. The offset plus the logical address yields the address of the first byte occupied by whatever is being discussed in the address space in the dumped system. When you request a dump access function, the first phsical byte of interst lands in the first byte of the buffer that you provide. That may require an interesting USING operation to get proper addressability to what lands in the buffer. There are also some other fields that help explain why BLSRESSY (symbol table) and BLSRSASY (storage map) records are different. I hope that this helps. Bob Wright - MVS Service Aids ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
