Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Jim Mulder
  MVS/370 also used absolute zero for the IPL processor.
In MVS/XA, we changed to  use a non-zero prefix for every processor.

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

"IBM Mainframe Assembler List"  wrote on 
11/12/2019 01:51:22 PM:

> From: "Seymour J Metz" 
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 11/13/2019 01:14 AM
> Subject: Re: Questionable Instructions in Obtaining EAX documentation
> Sent by: "IBM Mainframe Assembler List" 

> 
> I don't know about MVS, but OS/360 support for 65MP used absolute 
> address 0 for one processor.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> 
> From: IBM Mainframe Assembler List 
> on behalf of John McKown 
> Sent: Tuesday, November 12, 2019 9:49 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Questionable Instructions in Obtaining EAX documentation
> 
> On Tue, Nov 12, 2019 at 8:43 AM Tom Marchant <
> 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:
> 
> > >I cannot fathom the reason to use _any_ base for the PSA other than 
GPR0.
> > >It is simply wasteful of a scarce resource.
> >
> > It isn't "the" PSA. There is the PSA of the processor that you are 
running
> > on.
> > That PSA is always at location 0.
> >
> 
> True. I left out the words "of the processor". I guess that I ASSuMEd 
that.
> 
> 
> 
> >
> > Every processor in the LPAR has its own PSA, and when the processor is
> > running,
> > that PSA is at real (and virtual) location 0 for that processor. The 
PSA
> > for any
> > other processor can also be referenced using the real address that 
matches
> > the
> > value that is used for the prefix register for that processor. This is
> > documented
> > in the Principles of Operation under "Prefixing".
> >
> 
> I know. But I have never wanted to look at the PSA of any CP other than 
the
> one that I am running on. I'm not really sure why I would. Do you know 
of a
> reason to do so? I am curious.
> 
> 
> 
> >
> > You cannot use the value in the prefix register for your own processor 
to
> > reference
> > your PSA though. That would get you to absolute page 0, which, if I
> > understand
> > correctly, MVS never uses.
> >
> 
> That's interesting. So z/OS and it's ancestors have never really used
> absolute page 0. I guess it doesn't really matter since it is a small
> amount of physical storage in today's world. Actually, I thought 
absolute 0
> was used as the PSA for the IPL processor, but that, again, was an
> assumption.
> 
> 
> 
> >
> > --
> > Tom Marchant


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Steve Thompson

From memories of 30-ish years ago...

I worked on MDF (Multiple Domain Facility -- What IBM came to 
call PR/SM and domains got called LPARs) at Amdahl.


So let me elaborate on what Seymour said just based on the Amdahl 
MVS Structure and Flow class I had (2 weeks of in depth teaching).


When you hit the blue LOAD button (as I recall that was the 
color), the system went into IPL mode/state (I've forgotten which 
is the formal name) and fetched from a specific volume the IPL TEXT.


Now we summarize all the fun from that.

Page Frame 0 for that DOMAIN/LPAR is *the INITIAL* PSA (PSA 0) 
while in IPL mode/state. This is all done in REAL mode. So you 
get all of the IRIM and RIMs done (Initial Resource 
Initialization Module, and Resource INIT module -- I didn't come 
up with those names, IBM did) and you are now preparing for MP 
INIT (or DP if you only have a Dyadic machine), so, you point 
some register (not 0) at this PSA you are about to build, doing a 
copy from the PSA 0 to this PSA being built and now you load your 
prefix reg with this address. Now R0 is pointing to this new PSA 
and no longer to PSA 0.


Why did we do this? Because PSA 0 now has all of the NEW/PSWs set 
to point to the xxx Interrupt FLIHs (First Level Interrupt 
Handlers). And it has all the other stuff that has to be anchored 
in the PSA stored at the specified positions.


I have forgotten when RSM (Real Storage Manager) has been done, 
and VSM, etc. are init-ed, but DAT should now be active.


We can now do "MP" INIT. For each CPU we have to get the storage 
for its PSA and copy PSA 0 to it to init it -- You may need to 
make a change in that PSA, so you have to address it with 
something other than R0. Once that is done, a SIGP RESTART is 
done for that CPU. Now that CPU goes through all the stuff it 
must to get to a dispatchable state for the dispatcher to control 
it. And that may be a very short # of items.


Rinse repeat for each CPU defined for this domain/LPAR.

That's one use of addressing a PSA where you can't use R0.

ACR -- Alternate CPU recovery may be another.

MCK -- Machine check handler. It may have to look at a dead CPU 
(MCK PD comes to mind, and PI loop is another -- but that may be 
done in ACR) and so it has to use something other than R0 to look 
at that processor's PSA.


Now you know some of the reasons for using other than R0 to 
address a PSA.


Again, it has been 30 years now since I worked at that level and 
MVS has changed a lot since then.


Regards,
Steve Thompson


On 11/12/19 2:01 PM, Seymour J Metz wrote:

No, it's not a waste of resources. There is a valid use case regardless of 
whether you can conceive of it.


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



From: IBM Mainframe Assembler List  on behalf of 
John McKown 
Sent: Tuesday, November 12, 2019 8:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Questionable Instructions in Obtaining EAX documentation

On Tue, Nov 12, 2019 at 6:56 AM Peter Relson  wrote:



What if R9 is not supposed to be zero? Maybe the code is looking at the
PSA
of another processor.


The normal way to accomplish that is
  USING PSA,R9
rather than leaving a time-bomb for those who come after by using "0".



I cannot fathom the reason to use _any_ base for the PSA other than GPR0.
It is simply wasteful of a scarce resource.




Peter Relson
z/OS Core Technology Design




--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown



Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Seymour J Metz
No, it's not a waste of resources. There is a valid use case regardless of 
whether you can conceive of it.


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



From: IBM Mainframe Assembler List  on behalf 
of John McKown 
Sent: Tuesday, November 12, 2019 8:13 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Questionable Instructions in Obtaining EAX documentation

On Tue, Nov 12, 2019 at 6:56 AM Peter Relson  wrote:

> 
> What if R9 is not supposed to be zero? Maybe the code is looking at the
> PSA
> of another processor.
> 
>
> The normal way to accomplish that is
>  USING PSA,R9
> rather than leaving a time-bomb for those who come after by using "0".
>

I cannot fathom the reason to use _any_ base for the PSA other than GPR0.
It is simply wasteful of a scarce resource.


>
> Peter Relson
> z/OS Core Technology Design
>


--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Seymour J Metz
I don't know about MVS, but OS/360 support for 65MP used absolute address 0 for 
one processor.


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



From: IBM Mainframe Assembler List  on behalf 
of John McKown 
Sent: Tuesday, November 12, 2019 9:49 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Questionable Instructions in Obtaining EAX documentation

On Tue, Nov 12, 2019 at 8:43 AM Tom Marchant <
00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:

> >I cannot fathom the reason to use _any_ base for the PSA other than GPR0.
> >It is simply wasteful of a scarce resource.
>
> It isn't "the" PSA. There is the PSA of the processor that you are running
> on.
> That PSA is always at location 0.
>

True. I left out the words "of the processor". I guess that I ASSuMEd that.



>
> Every processor in the LPAR has its own PSA, and when the processor is
> running,
> that PSA is at real (and virtual) location 0 for that processor. The PSA
> for any
> other processor can also be referenced using the real address that matches
> the
> value that is used for the prefix register for that processor. This is
> documented
> in the Principles of Operation under "Prefixing".
>

I know. But I have never wanted to look at the PSA of any CP other than the
one that I am running on. I'm not really sure why I would. Do you know of a
reason to do so? I am curious.



>
> You cannot use the value in the prefix register for your own processor to
> reference
> your PSA though. That would get you to absolute page 0, which, if I
> understand
> correctly, MVS never uses.
>

That's interesting. So z/OS and it's ancestors have never really used
absolute page 0. I guess it doesn't really matter since it is a small
amount of physical storage in today's world. Actually, I thought absolute 0
was used as the PSA for the IPL processor, but that, again, was an
assumption.



>
> --
> Tom Marchant
>


--
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Seymour J Metz
I believe that z/OS creates a PSA virtual address for every processor. As you 
guessed, absolute address zero is defined in the context of the LPAR or virtual 
machine, not the bare metal. 


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



From: IBM Mainframe Assembler List  on behalf 
of Gary Weinhold 
Sent: Tuesday, November 12, 2019 11:28 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Questionable Instructions in Obtaining EAX documentation

I had a reason a couple weeks ago.  We were trying to programmatically
verify whether we were running certain code on a zIIP or a CP.  I found
a bit in the PSA that it appeared was set if you're on a zIIP and not if
not.  It was not set for my PSA, (not surprising since I was on TSO ISPF
running TASID).  But wanted to look at the zIIP's PSA to verify it.  But
I couldn't find an easy way to locate it

Instead, the person developing a JNI routine and testing it for lazy
switching effects just added it to their code and it seems to be a valid
indicator.

At IPL absolute 0 is the only PSA because I believe software has to
implement prefixing as it implements multi-tasking.  I assume absolute
zero is only absolute from the lpar's (or virtual machine's) point of view.

On 2019-11-12 10:00 a.m., Tom Marchant wrote:
> On Tue, 12 Nov 2019 08:49:36 -0600, John McKown wrote:
>
>> I have never wanted to look at the PSA of any CP other than the
>> one that I am running on. I'm not really sure why I would. Do you know of a
>> reason to do so? I am curious.
> I have no need to do so, and don't know why I might. But the post from Peter
>
> that you replied to was about doing that
>
>> I thought absolute 0
>> was used as the PSA for the IPL processor, but that, again, was an
>> assumption.
> That may be. I don't know. The POO would probably say.
>


Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at 
http://secure-web.cisco.com/1wgqzG9Xl26cce10857wqyZbQRJi5cb-hWjhobI7jicyVXwhFCSN6nurVUMKRkpVG2op1q9A049esH8DXypqRmbcHzPfP4nFNuP0eJzrG91DwfFZeQ_XyC4D9ZifcOfFNQtgtHIEYJj0q5n2cNVy0F4S6JoayeQZie60oOuhafGfNEnVxMkIXv6zLjYLNCo19haUVRJgjgSPWSJ-AFjHIDpAvcO0f28Q8aTgkKEkOkTLgkUXSEasuL3-OGKtzDfQLe5awZKCsuHkE90vegJvAsCLG-J6bXPQASsFYJbhGOdr2P8zAelnK8ZM_xRIEd94vpkrLQjnFwaSPy9HQ4ujQmjYUBy6L3o-JwAHpf1lLiB_l09ZVJAMeih_jOMeGaJSJz2-CYpwHe-NVhko75l6U-Q/http%3A%2F%2Fwww.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.



Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Gary Weinhold
I had a reason a couple weeks ago.  We were trying to programmatically
verify whether we were running certain code on a zIIP or a CP.  I found
a bit in the PSA that it appeared was set if you're on a zIIP and not if
not.  It was not set for my PSA, (not surprising since I was on TSO ISPF
running TASID).  But wanted to look at the zIIP's PSA to verify it.  But
I couldn't find an easy way to locate it

Instead, the person developing a JNI routine and testing it for lazy
switching effects just added it to their code and it seems to be a valid
indicator.

At IPL absolute 0 is the only PSA because I believe software has to
implement prefixing as it implements multi-tasking.  I assume absolute
zero is only absolute from the lpar's (or virtual machine's) point of view.

On 2019-11-12 10:00 a.m., Tom Marchant wrote:
> On Tue, 12 Nov 2019 08:49:36 -0600, John McKown wrote:
>
>> I have never wanted to look at the PSA of any CP other than the
>> one that I am running on. I'm not really sure why I would. Do you know of a
>> reason to do so? I am curious.
> I have no need to do so, and don't know why I might. But the post from Peter
>
> that you replied to was about doing that
>
>> I thought absolute 0
>> was used as the PSA for the IPL processor, but that, again, was an
>> assumption.
> That may be. I don't know. The POO would probably say.
>


Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Tom Marchant
On Tue, 12 Nov 2019 08:49:36 -0600, John McKown wrote:

> I have never wanted to look at the PSA of any CP other than the
>one that I am running on. I'm not really sure why I would. Do you know of a
>reason to do so? I am curious.

I have no need to do so, and don't know why I might. But the post from Peter 

that you replied to was about doing that

>I thought absolute 0
>was used as the PSA for the IPL processor, but that, again, was an
>assumption.

That may be. I don't know. The POO would probably say.

-- 
Tom Marchant


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread John McKown
On Tue, Nov 12, 2019 at 8:43 AM Tom Marchant <
00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote:

> >I cannot fathom the reason to use _any_ base for the PSA other than GPR0.
> >It is simply wasteful of a scarce resource.
>
> It isn't "the" PSA. There is the PSA of the processor that you are running
> on.
> That PSA is always at location 0.
>

True. I left out the words "of the processor". I guess that I ASSuMEd that.



>
> Every processor in the LPAR has its own PSA, and when the processor is
> running,
> that PSA is at real (and virtual) location 0 for that processor. The PSA
> for any
> other processor can also be referenced using the real address that matches
> the
> value that is used for the prefix register for that processor. This is
> documented
> in the Principles of Operation under "Prefixing".
>

I know. But I have never wanted to look at the PSA of any CP other than the
one that I am running on. I'm not really sure why I would. Do you know of a
reason to do so? I am curious.



>
> You cannot use the value in the prefix register for your own processor to
> reference
> your PSA though. That would get you to absolute page 0, which, if I
> understand
> correctly, MVS never uses.
>

That's interesting. So z/OS and it's ancestors have never really used
absolute page 0. I guess it doesn't really matter since it is a small
amount of physical storage in today's world. Actually, I thought absolute 0
was used as the PSA for the IPL processor, but that, again, was an
assumption.



>
> --
> Tom Marchant
>


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Steve Smith
The question is what reasonable use is there is of USING on a number?

I'm not sure what the rest of this post means, but it doesn't seem relevant.

sas

On Mon, Nov 11, 2019 at 2:35 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2019-11-11, at 09:08:39, Steve Smith wrote:
> >
> > I must agree that USING on numbers is a questionable feature; also
> operand
> > 1 doesn't have to be 0, anything up to 2gb should work.
> >
> What's "questionable"?  Should the Assembler require a
> relocatable expression?  Why?
>
> An old (BitSavers) Assembler manual said the allowed range
> was (1-2**24,2**24-1).  HLASM says, "non-negative".  I don't
> believe either restriction was ever enforced.
>
> What does "negative" mean for a relocatable expression?  Does
> it depdend on the address at which the CSECT/DSECT gets loaded?
>
> >  ... My guess is somebody in 1964 thought it was a good idea.
> >
> Prior to the advent of immediate instructions there was no better
> alternative.
>
> -- gil
>


-- 
sas


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Tom Marchant
On Tue, 12 Nov 2019 07:13:16 -0600, John McKown wrote:

>On Tue, Nov 12, 2019 at 6:56 AM Peter Relson  wrote:
>
>> 
>> What if R9 is not supposed to be zero? Maybe the code is looking at the
>> PSA
>> of another processor.
>> 
>>
>> The normal way to accomplish that is
>>  USING PSA,R9
>> rather than leaving a time-bomb for those who come after by using "0".
>>
>
>I cannot fathom the reason to use _any_ base for the PSA other than GPR0.
>It is simply wasteful of a scarce resource.

It isn't "the" PSA. There is the PSA of the processor that you are running on. 
That PSA is always at location 0.

Every processor in the LPAR has its own PSA, and when the processor is running, 
that PSA is at real (and virtual) location 0 for that processor. The PSA for 
any 
other processor can also be referenced using the real address that matches the 
value that is used for the prefix register for that processor. This is 
documented 
in the Principles of Operation under "Prefixing".

You cannot use the value in the prefix register for your own processor to 
reference 
your PSA though. That would get you to absolute page 0, which, if I understand 
correctly, MVS never uses.

-- 
Tom Marchant


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread John McKown
On Tue, Nov 12, 2019 at 6:56 AM Peter Relson  wrote:

> 
> What if R9 is not supposed to be zero? Maybe the code is looking at the
> PSA
> of another processor.
> 
>
> The normal way to accomplish that is
>  USING PSA,R9
> rather than leaving a time-bomb for those who come after by using "0".
>

I cannot fathom the reason to use _any_ base for the PSA other than GPR0.
It is simply wasteful of a scarce resource.


>
> Peter Relson
> z/OS Core Technology Design
>


-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown


Re: Questionable Instructions in Obtaining EAX documentation

2019-11-12 Thread Peter Relson

What if R9 is not supposed to be zero? Maybe the code is looking at the 
PSA
of another processor.


The normal way to accomplish that is 
 USING PSA,R9
rather than leaving a time-bomb for those who come after by using "0".

Peter Relson
z/OS Core Technology Design