>I am used the storage macro and the 64 bit version of that is IARST64
That's not how I think of it. Maybe, stretching, you could say that that
is so for sizes <= 128K and other limitations.
>It works like storage macro accessing an other address space storage in
AR mode
Unless I am
Thanks
I think and it is correct the way you ( just an assumption ) designed it
That for what I want to do I need IARST64 as opposed to IARV64
I am used the storage macro and the 64 bit version of that is IARST64
It works like storage macro accessing an other address space storage in AR
The control structures for the pool are in the space (address space or
data space) identified by the ALET parameter.
The service returns the address of the cell. It is up to you to have set
things up so that use of the provided ALET works in whatever environment
you are calling the service.
Peter
I meant IBMMAIN as this isnt assembler an question
I didn’t know how to delete the one I posted on the assembler list Serv
I read
Your share presentation “ Does my address space have enough storage for me “
And
The assembler services guide chapter 13 callable cell pool services “
Isn't it considered poor form to post the same thing on multiple
listserv's?
>there is one alet and pointers to the anchor, extent and cells
No there isn't. There is one ALET (described as the "control ALET") and a
pointer to the anchor and an output pointer to the returned cell.
>How can it
I'm looking at the Parms for this call there is one alet and pointers to the
anchor, extent and cells
How can it be the anchor extents in address space and the cells in other
More so can you call CSRC4GET From address space A were the cells reside in
B Thanks
On Mon, 24 Feb 2020 at 08:43, Peter Relson wrote:
> The information provided so far does not show doing some sort of "OKSWAP"
> afterwards. It would be inappropriate to leave the space non-swappable.
Just as it would be inappropriate to make it swappable if it was
non-swappable to start with.
I do the okswap after I do a get from the cell pool
Thanks
> On Feb 24, 2020, at 8:43 AM, Peter Relson wrote:
>
> I agree with Rob and Binyamin in worrying about a design that imposes
> non-swappability on someone else's address space.
> I'll point out that in general TRANSWAP involves
I agree with Rob and Binyamin in worrying about a design that imposes
non-swappability on someone else's address space.
I'll point out that in general TRANSWAP involves "swap in" and "don't
allow subsequent swap-out" and "wait for completion by ECB".
You can't do the wait for completion from an
:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cell Pool Services CSRC4EXP
EXTERNAL EMAIL
I accessing the other address space in AR 99 % of the time I won’t have issues
from those time that I do and get s0c4
In my recovery I will try to issue an SRB to sysevent swap back in
If I’m
I accessing the other address space in AR 99 % of the time I won’t have issues
from those time that I do and get s0c4
In my recovery I will try to issue an SRB to sysevent swap back in
If I’m unsuccessful I’ll bypass the process
It’s a much better choice for me than using an SRB
> On Feb
On Sun, 23 Feb 2020 15:44:12 -0500 Joseph Reichman
wrote:
:>All I can say is you are right these are 1% chance that I can program for I
need access to the other address space with little overheard I understand the
risk involved
:>As long as can address it with a recovery routine its a much
All I can say is you are right these are 1% chance that I can program for I
need access to the other address space with little overheard I understand the
risk involved
As long as can address it with a recovery routine it’s a much better choice
than a SRB
> On Feb 23, 2020, at 2:50 PM,
nd
> >
> > thanks
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List On
> Behalf Of Rob Scott
> > Sent: Sunday, February 23, 2020 1:34 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Cell Pool Services CSRC4EXP
> >
&g
as it avoids
> these problems
>
>
> Can I ask where and when is your XMEM session in share I would like to see if
> I can attend
>
> thanks
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of
> Rob Scott
> Sent: Sunday, Feb
On Sun, 23 Feb 2020 12:16:28 -0500 Joseph Reichman
wrote:
:>SRB and PC are sometimes not particle
Such as? Give a case.
:>AR mode has its risk best to have a recovery
True for most things.
:>Routine to address the rare case and maybe issue a SRB to swap back in Im
not at that point yet
t;
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
:>Behalf Of Joseph Reichman
:>Sent: Sunday, February 23, 2020 7:43 AM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: Cell Pool Services CSRC4EXP
:>
:>Then me ju
On Behalf Of Rob
Scott
Sent: Sunday, February 23, 2020 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cell Pool Services CSRC4EXP
Personally I think that if your design requires you to alter the attributes of
an address space which is not under your control, then it is likely that the
design
session in share I would like to see if
I can attend
thanks
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Rob
Scott
Sent: Sunday, February 23, 2020 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cell Pool Services CSRC4EXP
Personally I think that if your design
not "smell right" to me.
Rob Scott
Rocket Software
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Joseph Reichman
Sent: Sunday, February 23, 2020 3:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cell Pool Services CSRC4EXP
EXTERNAL EMAIL
Then me just say
l use software.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joseph Reichman
> Sent: Sunday, February 23, 2020 7:43 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Cell Pool
MAIN@LISTSERV.UA.EDU] On
Behalf Of Joseph Reichman
Sent: Sunday, February 23, 2020 7:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cell Pool Services CSRC4EXP
Then me just say what I do in the SRB
The following
XR R1,R1 Clear R1 as we cann't wait in
SRB mode
no;
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Peter Relson
Sent: Sunday, February 23, 2020 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Cell Pool Services CSRC4EXP
Should just say data space
Your logic confounds me. It can certainly be an address
Should just say data space
Your logic confounds me. It can certainly be an address space. Whether it
is an address space or data space, you have to do things right.
page 217 ( chapter 13) of the assembler services guide
Page and chapter references don't work too well if someone is
Peter
I understand what you are saying in regards
That it is not appropriate to address the target address space via alet
As I saw Rob Scott’s post regarding the share session talking about xmem
The diagram on page 217 ( chapter 13) of the assembler services guide is than
some what erroneous
It would seem then if I would I want to have the actual storage in the
target address space I would have to schedule an SRB
I could then issue CSRCxGET from a from that address space the cell
returned could be addressed in AR mode with using the ALET
Having no idea what the "target address
Peter
Thanks it would seem then if I would I want to have the actual storage in the
target address space I would have to schedule an SRB
I could then issue CSRCxGET from a from that address space the cell returned
could be addressed in AR mode with using the ALET
> On Feb 21, 2020, at
What is the question? There is no question within the post.
The cell storage (as opposed to the storage for the control structures
managing the cell storage, which can be thought of as the "anchor" and the
"extent") is not touched by the service. There is one ALET used for the
suite of
The documentation for cell pool services the anchor and extent can reside in
one address space while the actual storage in other address space and I
guess than the ALET parm would specify what address space/data space the
anchor/extent reside
If however the Cell pool storage as well reside
29 matches
Mail list logo
