On Sat, 4 Feb 2023 at 18:00, esst...@juno.com <esst...@juno.com> wrote:


> I am on a z/os 2.2 system, trying to rseurrect some old code.
> .
> can some one confirm the instructions for Searching the
> Address Space Vector Table (ASVT) on z/OS 2.2
> .
> This program  loads R10 with CVTASVT
> L     R10,CVTASVT        GET ASVT ADDRESS
> USING ASVT,R10          ESTABLISH ADDRESSABILITY
>

That's fine.


> It then issues a Load Address For the first entry ?
> This doesn't  look correct to me ?
> LA    R11,ASVTENTY       GET # OF FIRST ENTRY
>

It's fine. The ASVT has a bunch of header stuff, and then an array of
fullword pointers starting at ASVTENTY. The PL/X declaration may make it a
bit clearer.

Next its test for an ASCB that is assigned.
> TM    0(R11),ASVTAVAL    VALID ASCB Available ?
> BO    RUNLOP1            NO, CHECK NEXT ASVT ENTRY
>

It's fine.I suppose there may be a serialization issue, e.g. an ASVT
entry's assignment status may change after you've looked. But programs that
either index the ASVT with the ASID (x 4), or those that go sequentially
through the array and do <something> with each active address space have
done it this way forever (i.e. since 1972), and I'm sure many are still out
there working fine. Like anything, it's conceivable IBM could change this
at some point, but it's such a basic interface in MVS--> z/OS that they
would surely introduce some new data structure or API to access the list of
ASCBs rather than change the ASVT and break things all over the place.


> Besides the Load Address above - How should this module
> advance to the Next ASVT entry ?
>

There's nothing wrong with the LA. The start of the array of ASCB pointers
is at whatever offset ASVTENTY is at, and that hasn't changed in 50 years.
The content of the header info has grown, but not the offset of the array
of pointers.


> Shoud I issue the following to get to the next ASVT
> L    R10,ASVTFRST
>

No. I think you're thinking that the entire ASVT has multiple instances
that are chained together. There's only one, with an array of pointers on
the end. ASVTFRST points somewhere you don't want - I think the first
*available* ASCB, though IBM doesn't document the ASCB creation logic, and
I assume things have changed with reusable ASIDs. Presumably you are not
planning to modify the ASVT, so you're not looking for an available
entry... If you are, well Just Don't. But effectively ASVTFRST is element 0
of the array of ASCB pointers, and there's no ASID 0. So if you have the
address of ASVTFRST (not the address that is *in* ASVTFRST), then you can
multiply the ASID by 4 and use it as an origin-0 array index. If you start
at ASVTENTY then it's origin-1, so add 4 (or 1 before you multiply by 4).
Or if you want to look at all active ASCBs then start with the first array
element, follow the pointer *if it's active*, and do whatever it is you
want to do with each ASCB.


> The current code issues the following instruction, which
> looks incorrect according to IHAASVT
> LA    R11,4(,R11)          Advance NEXT ASVT ENTRY
>

It's fine. I suppose if you want to be pedantic you could use L'ASVTENTY
instead of hardcoding 4, but seriously, that's not going to change, and if
it does all kinds of other things will break.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to