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