Re: IPCS: accessing data in a dataspace
- From: rlw@xxxxxxxxxxxx (Robert Wright)
- Date: 3 Feb 2006 09:40:07 -0800
Todd Burch wrote on 02/03/2006 11:57:09 AM:
Reading through IPCS customization, it is not clear to me how to go aboutthe
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
ASID of the owning dataspace and the DSPNAME itself. OK so far.dataspace,
What is not clear to me is where to supply the address within the
or the length of the data I want returned. Do I have to create a symbolsimilarly
(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,
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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- Re: IPCS: accessing data in a dataspace
- From: Todd Burch
- Re: IPCS: accessing data in a dataspace
- References:
- IPCS: accessing data in a dataspace
- From: Todd Burch
- IPCS: accessing data in a dataspace
- Prev by Date: Re: Access to Mainframes via Putty?
- Next by Date: Re: Mount a tape
- Previous by thread: IPCS: accessing data in a dataspace
- Next by thread: Re: IPCS: accessing data in a dataspace
- Index(es):
Relevant Pages
|
