Re: Searching the ASVT

2023-02-06 Thread Ed Jaffe

On 2/5/2023 9:14 AM, Joe Monk wrote:

I always find it fascinating when someone tries to explain to the IBM z/OS
designers how z/OS works...


Not sure I follow what you're trying to say with this snarky-sounding 
comment, particularly since Michael Stein's explanation was correct...



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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


Re: Searching the ASVT

2023-02-06 Thread Peter Relson
> ASVTENTY is the address of the entry for ASID 0 (which, of course, is never 
> used).

Apologies. That's wrong. ASVTENTY is, as others have posted, the entry for ASID 
1.

ASVTFRST locates an entry that is available for use for a new address space.

Peter Relson
z/OS Core Technology Design


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


Re: Searching the ASVT

2023-02-05 Thread Joe Monk
I always find it fascinating when someone tries to explain to the IBM z/OS
designers how z/OS works...

Joe

On Sun, Feb 5, 2023 at 9:16 AM Michael Stein  wrote:

> On Sun, Feb 05, 2023 at 01:34:36PM +, Peter Relson wrote:
>
> > ASVTFRST is documented as "address of first available ASVT entry". It
> > has nothing to do with "next".
>
> ASVTFRST is the address of the slot for ASID 0 which doesn't exist but
> is usefull to adjust for the fact that ASIDs start at 1 since it is
> just before ASVTENTY.
>
> > The ASVT entries form an array with the first being at ASVTENTY,
> > and each entry mapped by 4-byte field ASVTENTY.]
>
> ASVTENTY is the slot for ASID 1 and the actual start of the slots
> which (might) point to ASCBs.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: Searching the ASVT

2023-02-05 Thread Michael Stein
On Sun, Feb 05, 2023 at 07:12:57AM +, Seymour J Metz wrote:
> Shouldn't that be
> USING ASVTBEGN,R10  ESTABLISH ADDRESSABILITY
> 
> Or does CVTASVT point to the prefix?

It points to the prefix.  This allows IBM to add fields to the ASVT
without the other offsets changing.  They can't add them at the end
since the end has an unknown number of slots for ASCB addresses.

It's possible (likely?) that the full prefix doesn't exist as
allocated storage to the ASVT (ie: the unused part of the prefix
overlays something else).

There is a lot of code which knows the ASVT structure and possibly
micro-code too...

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


Re: Searching the ASVT

2023-02-05 Thread Seymour J Metz
It looks correct, but I have a few style comments.

Use of "magic numbers" can obscure the code; I'd use the symbol from IHAPSA

The extraneous DROP  R10 before USING ASVT,R10 is confusing.

You don't need to bump the pointer to AVTENTY before the loop.

Something like

 USING PSA,R0
 L R10,CVTPTR
 USING CVTMAP,R10
 L R11,CVTASVT
 USING ASVT,R11
 L R9,ASVTMAXU
LOOPASVT TMASVTENTY,ASVTAVAL
 BONEXTASVT   
 L R10,ASVTENTY
 USING ASCB,R10
 ...

NEXTASVT LAR11,4(,R11)
 BCT   R9,LOOPASVT
 ...
IHAPSA ,
 CVT   DSECT=YES
   IHAASVT ,
 ...

Also, please read Peter's message.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, February 5, 2023 5:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Searching the ASVT

Thank you all for this discussion;
I have learned something new :-)

Would you kindly look at this coding and tell me, if it is correct in
your opinion,
and if it is allowed to execute this by non-privileged programs?

What macro calls do I need to get the needed definitions (CVT, ASVT, ASCB)?

Thanks in advance,
have a nice day

Bernd



*
*-
*walk thru all ASCBs
*-
*
  L R10,16  LOAD ADDR OF CVT
  USING CVT,R10 SET ADDRESSABILITY TO CVT
  L R10,CVTASVT POINT TO ADDRESS SPACE VECTOR TABLE
  DROP  R10
  USING ASVT,R10SET ADDRESSABILITY TO ASVT
  L R9,ASVTMAXU LOAD MAX. NUMBER OF ADDRESS SPACES.
  LAR11,ASVTENTYLOAD ADDRESS OF FIRST ASCB POINTER
  DROP  R10
*
*-
*R11 is moved over the table of all ASCB pointers
*R10 is no longer needed
*R9  contains the number of entries in the ASCB table
*-
*
LOOPASVT DS0H
  TM0(R11),ASVTAVAL VALID ASCB Available ?
  BONEXTASVTNO, CHECK NEXT ASVT ENTRY
*
*-
*Examine ASCB
*Use R10 to address the ASCB
*-
*
  L R10,0(R11)
  USING ASCB,R10
*
*-
*access fields of current ASCB
*-
*
*--- to be entered here ---
*
*-
*advance R11 to next ASCB address
*-
*
NEXTASVT DS0H
  LAR11,4(,R11) Advance to NEXT ASVT ENTRY
  BCT   R9,LOOPASVT
*



Am 05.02.2023 um 07:39 schrieb Tony Harminc:
> On Sat, 4 Feb 2023 at 18:00, 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,CVTASVTGET 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 ?
>> LAR11,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.
>> TM0(R11),ASVTAVALVALID ASCB Available ?
>> BORUNLOP1NO, 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  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

Re: Searching the ASVT

2023-02-05 Thread Michael Stein
On Sun, Feb 05, 2023 at 01:34:36PM +, Peter Relson wrote:

> ASVTFRST is documented as "address of first available ASVT entry". It
> has nothing to do with "next".

ASVTFRST is the address of the slot for ASID 0 which doesn't exist but
is usefull to adjust for the fact that ASIDs start at 1 since it is
just before ASVTENTY.
 
> The ASVT entries form an array with the first being at ASVTENTY,
> and each entry mapped by 4-byte field ASVTENTY.]

ASVTENTY is the slot for ASID 1 and the actual start of the slots
which (might) point to ASCBs.

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


Re: Searching the ASVT

2023-02-05 Thread Michael Stein
> Next its test for an ASCB that is assigned.
> > TM0(R11),ASVTAVALVALID ASCB Available ?
> > BORUNLOP1NO, CHECK NEXT ASVT ENTRY

I wouldn't separate the test for valid with picking up the ASCB address
as the ASVT slot might change between my ASVT references.  I'd 
load the word from the ASVT slot and then test the high bit in
the register (LTR or ICM).

I'm assuming you don't hold the required locks to serialize ASVT
updates (unlike deep in the zOS dispatcher etc..)

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


Re: Searching the ASVT

2023-02-05 Thread Peter Relson
Before addressing the question, a question in return. Why are you searching the 
ASVT?
Most user ASVT references relate to finding the ASCB address for a specific 
ASID.
LOCASCB is usually used for that.

If you must search the ASVT, do you have reason to doubt the current code?
What are you searching for? Do you have the serialization you need to safeguard 
whatever it is that you are doing?
How are you determining how far to go? You might find using ASVTHWMAsid to meet 
your needs rather than ASVTMAXU, if you happen to know you are running on z/OS 
2.4 or later.

The comment on the "LA" is obviously incorrect, assuming "#" is "number". 
ASVTENTY is the address of the entry for ASID 0 (which, of course, is never 
used).

ASVTFRST is documented as "address of first available ASVT entry". It has 
nothing to do with "next".

The ASVT entries form an array with the first being at ASVTENTY, and each entry 
mapped by 4-byte field ASVTENTY.

Peter Relson
z/OS Core Technology Design


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


Re: Searching the ASVT

2023-02-05 Thread Colin Paice
Personally, I would take a dump and use IPCS to go through the pointers
with pencil and paper to make sure I understand the linkage, and it points
to what I want.
For example, to find the job name from an ASCB is either pASCB+ASCBJBNI or
pASCB+ASCBJBNS depending if it is a job or started task.
You can use the runchain IPCS command to run a chain... then do it in your
code.
Colin

On Sat, 4 Feb 2023 at 23:00, esst...@juno.com  wrote:

> .
> Hello
>
> 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,CVTASVTGET ASVT ADDRESS
> USING ASVT,R10  ESTABLISH ADDRESSABILITY
> .
> It then issues a Load Address For the first entry ?
> This doesn't  look correct to me ?
> LAR11,ASVTENTY   GET # OF FIRST ENTRY
> .
> Next its test for an ASCB that is assigned.
> TM0(R11),ASVTAVALVALID ASCB Available ?
> BORUNLOP1NO, CHECK NEXT ASVT ENTRY
> .
> * Examine ASCB
> .
> .
> Besides the Load Address above - How should this module
> advance to the Next ASVT entry ?
> Shoud I issue the following to get to the next ASVT
> LR10,ASVTFRST
> .
> The current code issues the following instruction, which
> looks incorrect according to IHAASVT
> LAR11,4(,R11)  Advance NEXT ASVT ENTRY
> .
> .
> Your comments please
> .
> Paul D'Angelo
> ***
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


Re: Searching the ASVT

2023-02-05 Thread Bernd Oppolzer

Thank you all for this discussion;
I have learned something new :-)

Would you kindly look at this coding and tell me, if it is correct in 
your opinion,

and if it is allowed to execute this by non-privileged programs?

What macro calls do I need to get the needed definitions (CVT, ASVT, ASCB)?

Thanks in advance,
have a nice day

Bernd



*
*-
*    walk thru all ASCBs
*-
*
 L R10,16  LOAD ADDR OF CVT
 USING CVT,R10 SET ADDRESSABILITY TO CVT
 L R10,CVTASVT POINT TO ADDRESS SPACE VECTOR TABLE
 DROP  R10
 USING ASVT,R10    SET ADDRESSABILITY TO ASVT
 L R9,ASVTMAXU LOAD MAX. NUMBER OF ADDRESS SPACES.
 LA    R11,ASVTENTY    LOAD ADDRESS OF FIRST ASCB POINTER
 DROP  R10
*
*-
*    R11 is moved over the table of all ASCB pointers
*    R10 is no longer needed
*    R9  contains the number of entries in the ASCB table
*-
*
LOOPASVT DS    0H
 TM    0(R11),ASVTAVAL VALID ASCB Available ?
 BO    NEXTASVT    NO, CHECK NEXT ASVT ENTRY
*
*-
*    Examine ASCB
*    Use R10 to address the ASCB
*-
*
 L R10,0(R11)
 USING ASCB,R10
*
*-
*    access fields of current ASCB
*-
*
*    --- to be entered here ---
*
*-
*    advance R11 to next ASCB address
*-
*
NEXTASVT DS    0H
 LA    R11,4(,R11) Advance to NEXT ASVT ENTRY
 BCT   R9,LOOPASVT
*



Am 05.02.2023 um 07:39 schrieb Tony Harminc:

On Sat, 4 Feb 2023 at 18:00, 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,CVTASVTGET 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 ?
LAR11,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.

TM0(R11),ASVTAVALVALID ASCB Available ?
BORUNLOP1NO, 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  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
LR10,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 

Re: Searching the ASVT

2023-02-04 Thread Seymour J Metz
Shouldn't that be
USING ASVTBEGN,R10  ESTABLISH ADDRESSABILITY

Or does CVTASVT point to the prefix?

The LAR11,ASVTENTY   is unnecessary unless you need to refer to the base of 
the table again; if you include it then include a corresponding USING. 
Otherwise you can just use and increment R10.

LAR11,4(,R11)  is correct for the code shown.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
esst...@juno.com [esst...@juno.com]
Sent: Saturday, February 4, 2023 5:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Searching the ASVT

.
Hello

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,CVTASVTGET ASVT ADDRESS
USING ASVT,R10  ESTABLISH ADDRESSABILITY
.
It then issues a Load Address For the first entry ?
This doesn't  look correct to me ?
LAR11,ASVTENTY   GET # OF FIRST ENTRY
.
Next its test for an ASCB that is assigned.
TM0(R11),ASVTAVALVALID ASCB Available ?
BORUNLOP1NO, CHECK NEXT ASVT ENTRY
.
* Examine ASCB
.
.
Besides the Load Address above - How should this module
advance to the Next ASVT entry ?
Shoud I issue the following to get to the next ASVT
LR10,ASVTFRST
.
The current code issues the following instruction, which
looks incorrect according to IHAASVT
LAR11,4(,R11)  Advance NEXT ASVT ENTRY
.
.
Your comments please
.
Paul D'Angelo
***

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

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


Re: Searching the ASVT

2023-02-04 Thread Tony Harminc
On Sat, 4 Feb 2023 at 18:00, 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,CVTASVTGET 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 ?
> LAR11,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.
> TM0(R11),ASVTAVALVALID ASCB Available ?
> BORUNLOP1NO, 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  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
> LR10,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
> LAR11,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


Re: Searching the ASVT

2023-02-04 Thread Brian Westerman
Hi,


I'm not sure what you are trying to do,  Most people would use the ASVT to get 
tot he ACSB to see what's running.  If it is that you are trying to search the 
ASCB to see if a task is actually executing, then all you really need from the 
ASVT is max number of ASCBS (located in ASVTMAXU) and the pointer to the first 
ACSB entry (located in ASVTENTY).  You load ASVTMAXU into a register (let's say 
R14) and LA ASVTENTY into a Reg (let's say R6)

 L R6,16 LOAD ADDR OF CVT
 USING CVT,R6  SET ADDRESSABILITY TO CVT
 L R6,CVTASVT  POINT TO ADDRESS SPACE VECTOR TABLE. 
 DROP  R6  DROP ADDRESSABILITY TO CVT  
 USING ASVT,R6 SET ADDRESSABILITY TO ASVT  
 L R14,ASVTMAXU   LOAD MAX. NUMBER OF ADDRESS SPACES. 
 LAR6,ASVTENTYLOAD ADDRESS OF FIRST ASCB POINTER
 DROP  R6  DROP ADDRESSABILITY TO ASVT

then you loop until you find what you want
JOBSRCH2 ICM   R3,B'',0(R6)POINT TO ASCB 
   BNP   JOBSRCH5ZERO OR NEGATIVE, BYPASS THIS ONE  
  
   USING ASCB,R3 SET ADDRESSABILITY TO ASCB 
  
   ICM   R15,B'',ASCBJBNI LOAD ADDRESS OF JOB NAME  
  
   BZJOBSRCH3ZERO, NOT A BATCH JOB must be STC  
  
   MVC   SRCHNAME,0(R15) SAVE JOB NAME  
 
   B JOBSRCH4GO SEE IF REQUESTED JOB/TASK NAME  
  
JOBSRCH3 EQU   *   Not a batch job, must be STC 
   ICM   R15,B'',ASCBJBNS LOAD ADDRESS OF STC TASK NAME 
  
   MVC   SRCHNAME,0(R15) SAVE TASK NAME 
  
... then you compare SRCHNAME to whatever you are looking for or just move it 
to print if you are just listing them

..then you just keep looping until you hit the end of the ASCBs

JOBSRCH5 LAR6,4(R6)POINT TO NEXT ASCB POINTER.
   BCT   R14,JOBSRCH2LOOP THROUGH ASCBS

If you object is to just scan the ASVT, then I have to ask why you would need 
to do that?

Brian

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


Re: Searching the ASVT

2023-02-04 Thread Michael Stein
> 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,CVTASVTGET ASVT ADDRESS
> USING ASVT,R10  ESTABLISH ADDRESSABILITY
> .
> It then issues a Load Address For the first entry ?
> This doesn't  look correct to me ? 
> LAR11,ASVTENTY   GET # OF FIRST ENTRY
> .
> Next its test for an ASCB that is assigned.
> TM0(R11),ASVTAVALVALID ASCB Available ?
> BORUNLOP1NO, CHECK NEXT ASVT ENTRY
> .
> * Examine ASCB
> .
> The current code issues the following instruction, which
> looks incorrect according to IHAASVT 
> LAR11,4(,R11)  Advance NEXT ASVT ENTRY 

ASVT mapping:

https://www.ibm.com/docs/en/zos/2.2.0?topic=information-asvt-mapping

That looks correct to me.  Here's some code from MVS3.8 IEAVEAC0:

 L R1,CVTASVT-CVT(R1)  GET THE ASVT 63660002
 BCTR  R13,ZERO   ASID-163710002
 SLL   R13,TWO(ASID-1) X 4  63730002
 L R13,ASVTENTY-ASVT(R13,R1)  GET ASCB ADDRESS @YM01596 63750002

So each slot in the ASVT is a 4 byte pointer with the high bit off if
points to an ASCB.  ASID 0 doesn't exist, so ASVTENTY is the pointer
for ASID 1.

It does need some check to not run off the end of the ASVT...

https://www.ibm.com/docs/en/zos/2.2.0?topic=information-asvt-heading

  Size:
  Offset of ASVTEND minus offset of ASVTBEGN plus four times the value
  of ASVTMAXU.

I'd guess that there are ASVTMAXU 4 byte entries starting and counting
ASVTENTY.

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