Re: PGSER FIX returns CC = 18A Reason=35000301

[Jim Mulder]

  That is correct - cross memory page faults are resolved as you would 
want,
so the PGSER FIX is not needed.

  Unfortunately, the system does not resolve ASTE-validity exception (PIC 
2B), 
which is why nonswappability is required. 

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

> From: John McKown <john.archie.mck...@gmail.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/04/2017 04:00 PM
> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> On Fri, Aug 4, 2017 at 2:18 PM, Joseph Reichman <reichman...@gmail.com>
> wrote:
> 
> > I made it non swapable
> >
> > But that doesn't mean the virtual storage cann't get paged out
> >
> >
> ​Ah, I think that it is acceptable for a page fault to occur (on either
> "side") when doing an AR mode MVC or a DAS MVCS/MVCP instruction. Normal
> page fault resolution is done and the instruction is executed.​
> 
> 
> -- 
> Veni, Vidi, VISA: I came, I saw, I did a little shopping.
> 
> Maranatha! <><
> John McKown
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[John McKown]

On Fri, Aug 4, 2017 at 2:18 PM, Joseph Reichman 
wrote:

> I made it non swapable
>
> But that doesn't mean the virtual storage cann't get paged out
>
>
​Ah, I think that it is acceptable for a page fault to occur (on either
"side") when doing an AR mode MVC or a DAS MVCS/MVCP instruction. Normal
page fault resolution is done and the instruction is executed.​


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Joseph Reichman]

I made it non swapable

But that doesn't mean the virtual storage cann't get paged out



> On Aug 4, 2017, at 2:47 PM, John McKown  wrote:
> 
>> On Fri, Aug 4, 2017 at 1:42 PM, Jim Mulder  wrote:
>> 
>>  That does not require the storage to be fixed, unless you are disabled
>> or you are using a real address for the target of the copy.
>> 
>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
>> Poughkeepsie NY
>> 
>> 
> ​I probably shouldn't say anything, being rather ignorant of this area, but
> if one wants to copy data directly from address space B (the target of the
> SRB in this case) to address space A (the originator of the SRB in this
> case), doesn't address space A need to be "non swappable"? I think this is
> true when using AR mode or DAS mode (MVCS instruction ?).​
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[Steve Beaver]

Why not us SP=245  that is a non-pageable subpool

Steve

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Friday, August 4, 2017 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PGSER FIX returns CC = 18A Reason=35000301

I thought the address space storage I was copying to could be paged out 

Ok l'll remove and see if I get any abends

> On Aug 4, 2017, at 2:42 PM, Jim Mulder <d10j...@us.ibm.com> wrote:
> 
>  That does not require the storage to be fixed, unless you are 
> disabled or you are using a real address for the target of the copy.
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
>> From: Joseph Reichman <reichman...@gmail.com>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/04/2017 02:40 PM
>> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301 Sent by: IBM 
>> Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>> 
>> Copy storage from the address space in which SRB is running to the 
>> address space that scheduled it
>> 
>> Thanks
>> 
>> 
>> 
>>> On Aug 4, 2017, at 1:32 PM, Jim Mulder <d10j...@us.ibm.com> wrote:
>>> 
>>> The answer is in the manual:
>>> 
>>> ,EA=end add 
>>> Specifies the last byte on the last page of the virtual area for
> R
>>> requests.
>>> 
>>> 
>>>  Your EA specifies the first byte on the next page, which is not 
>>> GETMAINed.
>>> 
>>>  What are you doing in the SRB that requires this storage to be 
>>> fixed
> 
>>> in 31-bit real storage?
>>> 
>>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>>> Poughkeepsie NY
>>> 
>>>> I am getting an error for PGSER Fix that the storage has not been
>>> getmain'ed
>>>> 
>>>> I have tried different subpool(s)  0 and 10 with same result AND 
>>>> same address was returned
>>>> 
>>>> Here is the storage macro whose storage I am trying to fix
>>>> 
>>>>USING VALSTOR,R3 
>>>>LAR0,4095 GET LENGTH 
>>>>AHR0,=H'1' 
>>>>STORAGE OBTAIN, X
>>>>  LENGTH=(R0), X
>>>>  ADDR=(R7), X
>>>>  BNDRY=PAGE, X
>>>>  SP=10, X
>>>>  LOC=(31,31)
>>>> * 
>>>> *   Page Fix Ws till SRB completes 
>>>> * 
>>>> LRR7,R13 Point to beg of WS 
>>>> LAR8,4095(,R7)   4K 
>>>> LAR8,1(,R8) 
>>>> 
>>>> 
>>>> *
>>>> 
>>>> PGSER R, X
>>>>   FIX, X
>>>>   A=(R7), X
>>>>   EA=(R8), X
>>>>   ECB=0
> 
> 
> 
> --
> 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

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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Joseph Reichman]

I thought the address space storage I was copying to could be paged out 

Ok l'll remove and see if I get any abends

> On Aug 4, 2017, at 2:42 PM, Jim Mulder <d10j...@us.ibm.com> wrote:
> 
>  That does not require the storage to be fixed, unless you are disabled 
> or you are using a real address for the target of the copy. 
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
>> From: Joseph Reichman <reichman...@gmail.com>
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/04/2017 02:40 PM
>> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301
>> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>> 
>> Copy storage from the address space in which SRB is running to the 
>> address space that scheduled it
>> 
>> Thanks
>> 
>> 
>> 
>>> On Aug 4, 2017, at 1:32 PM, Jim Mulder <d10j...@us.ibm.com> wrote:
>>> 
>>> The answer is in the manual:
>>> 
>>> ,EA=end add 
>>> Specifies the last byte on the last page of the virtual area for 
> R 
>>> requests.
>>> 
>>> 
>>>  Your EA specifies the first byte on the next page, which is not 
>>> GETMAINed. 
>>> 
>>>  What are you doing in the SRB that requires this storage to be fixed 
> 
>>> in 31-bit real storage?
>>> 
>>> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
>>> Poughkeepsie NY
>>> 
>>>> I am getting an error for PGSER Fix that the storage has not been 
>>> getmain'ed
>>>> 
>>>> I have tried different subpool(s)  0 and 10 with same result AND same
>>>> address was returned
>>>> 
>>>> Here is the storage macro whose storage I am trying to fix
>>>> 
>>>>USING VALSTOR,R3 
>>>>LAR0,4095 GET LENGTH 
>>>>AHR0,=H'1' 
>>>>STORAGE OBTAIN, X
>>>>  LENGTH=(R0), X
>>>>  ADDR=(R7), X
>>>>  BNDRY=PAGE, X
>>>>  SP=10, X
>>>>  LOC=(31,31) 
>>>> * 
>>>> *   Page Fix Ws till SRB completes 
>>>> * 
>>>> LRR7,R13 Point to beg of WS 
>>>> LAR8,4095(,R7)   4K 
>>>> LAR8,1(,R8) 
>>>> 
>>>> 
>>>> * 
>>>> 
>>>> PGSER R, X
>>>>   FIX, X
>>>>   A=(R7), X
>>>>   EA=(R8), X
>>>>   ECB=0 
> 
> 
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[John McKown]

On Fri, Aug 4, 2017 at 1:42 PM, Jim Mulder  wrote:

>   That does not require the storage to be fixed, unless you are disabled
> or you are using a real address for the target of the copy.
>
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
>
>
​I probably shouldn't say anything, being rather ignorant of this area, but
if one wants to copy data directly from address space B (the target of the
SRB in this case) to address space A (the originator of the SRB in this
case), doesn't address space A need to be "non swappable"? I think this is
true when using AR mode or DAS mode (MVCS instruction ?).​

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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Jim Mulder]

  That does not require the storage to be fixed, unless you are disabled 
or you are using a real address for the target of the copy. 

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

> From: Joseph Reichman <reichman...@gmail.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/04/2017 02:40 PM
> Subject: Re: PGSER FIX returns CC = 18A Reason=35000301
> Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> 
> Copy storage from the address space in which SRB is running to the 
> address space that scheduled it
> 
> Thanks
> 
> 
> 
> > On Aug 4, 2017, at 1:32 PM, Jim Mulder <d10j...@us.ibm.com> wrote:
> > 
> >  The answer is in the manual:
> > 
> > ,EA=end add 
> >  Specifies the last byte on the last page of the virtual area for 
R 
> > requests.
> > 
> > 
> >   Your EA specifies the first byte on the next page, which is not 
> > GETMAINed. 
> > 
> >   What are you doing in the SRB that requires this storage to be fixed 

> > in 31-bit real storage?
> > 
> > Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> > Poughkeepsie NY
> > 
> >> I am getting an error for PGSER Fix that the storage has not been 
> > getmain'ed
> >> 
> >> I have tried different subpool(s)  0 and 10 with same result AND same
> >> address was returned
> >> 
> >> Here is the storage macro whose storage I am trying to fix
> >> 
> >> USING VALSTOR,R3 
> >> LAR0,4095 GET LENGTH 
> >> AHR0,=H'1' 
> >> STORAGE OBTAIN, X
> >>   LENGTH=(R0), X
> >>   ADDR=(R7), X
> >>   BNDRY=PAGE, X
> >>   SP=10, X
> >>   LOC=(31,31) 
> >> * 
> >> *   Page Fix Ws till SRB completes 
> >> * 
> >>  LRR7,R13 Point to beg of WS 
> >>  LAR8,4095(,R7)   4K 
> >>  LAR8,1(,R8) 
> >> 
> >> 
> >> * 
> >> 
> >>  PGSER R, X
> >>FIX, X
> >>A=(R7), X
> >>EA=(R8), X
> >>ECB=0 



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

Re: PGSER FIX returns CC = 18A Reason=35000301

[Joseph Reichman]

Copy storage from the address space in which SRB is running to the address 
space that scheduled it

Thanks



> On Aug 4, 2017, at 1:32 PM, Jim Mulder  wrote:
> 
>  The answer is in the manual:
> 
> ,EA=end add 
>  Specifies the last byte on the last page of the virtual area for R 
> requests.
> 
> 
>   Your EA specifies the first byte on the next page, which is not 
> GETMAINed. 
> 
>   What are you doing in the SRB that requires this storage to be fixed 
> in 31-bit real storage?
> 
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
> Poughkeepsie NY
> 
>> I am getting an error for PGSER Fix that the storage has not been 
> getmain'ed
>> 
>> I have tried different subpool(s)  0 and 10 with same result AND same
>> address was returned
>> 
>> Here is the storage macro whose storage I am trying to fix
>> 
>> USING VALSTOR,R3 
>> LAR0,4095 GET LENGTH 
>> AHR0,=H'1' 
>> STORAGE OBTAIN,   X
>>   LENGTH=(R0),X
>>   ADDR=(R7),  X
>>   BNDRY=PAGE, X
>>   SP=10,  X
>>   LOC=(31,31) 
>> * 
>> *   Page Fix Ws till SRB completes 
>> * 
>>  LRR7,R13 Point to beg of WS 
>>  LAR8,4095(,R7)   4K 
>>  LAR8,1(,R8) 
>> 
>> 
>> * 
>> 
>>  PGSER R, X
>>FIX, X
>>A=(R7), X
>>EA=(R8), X
>>ECB=0 
> 
> 
> 
> --
> 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: PGSER FIX returns CC = 18A Reason=35000301

[Jim Mulder]

  The answer is in the manual:

,EA=end add 
  Specifies the last byte on the last page of the virtual area for R 
requests.


   Your EA specifies the first byte on the next page, which is not 
GETMAINed. 

   What are you doing in the SRB that requires this storage to be fixed 
in 31-bit real storage?

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

> I am getting an error for PGSER Fix that the storage has not been 
getmain'ed
> 
> I have tried different subpool(s)  0 and 10 with same result AND same
> address was returned
> 
> Here is the storage macro whose storage I am trying to fix
> 
>  USING VALSTOR,R3 
>  LAR0,4095 GET LENGTH 
>  AHR0,=H'1' 
>  STORAGE OBTAIN,   X
>LENGTH=(R0),X
>ADDR=(R7),  X
>BNDRY=PAGE, X
>SP=10,  X
>LOC=(31,31) 
>  * 
>  *   Page Fix Ws till SRB completes 
>  * 
>   LRR7,R13 Point to beg of WS 
>   LAR8,4095(,R7)   4K 
>   LAR8,1(,R8) 
> 
> 
>  * 
> 
>   PGSER R, X
> FIX, X
> A=(R7), X
> EA=(R8), X
> ECB=0 



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

PGSER FIX returns CC = 18A Reason=35000301

[Joe Reichman]

Hi,

 

 

I am getting an error for PGSER Fix that the storage has not been getmain'ed

 

I have tried different subpool(s)  0 and 10 with same result AND same
address was returned

 

Here is the storage macro whose storage I am trying to fix

 

 

 USING VALSTOR,R3   

 LAR0,4095 GET LENGTH   

 AHR0,=H'1' 

 STORAGE OBTAIN,   X

   LENGTH=(R0),X

   ADDR=(R7),  X

   BNDRY=PAGE, X

   SP=10,  X

   LOC=(31,31)  

 

 

 *  

 *   Page Fix Ws till SRB completes 

 *  

  LRR7,R13 Point to beg of WS   

  LAR8,4095(,R7)   4K   

  LAR8,1(,R8)   

 

 

 

 *   

  PGSER R,  X

FIX,X

A=(R7), X

EA=(R8),X

ECB=0


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