Re: What size memory object backs an IARCP64

[Peter Relson]

>There is an parm that sets the number of
>memory large pages at IPL time.
True, but not relevant to the question, in general.

The specific answer is "1M memory object". This is why the cellsize is 
limited to 520192.  And of course you cannot get a memory object smaller 
than 1M.

There is nothing particularly special about IARCP64. It invokes IARV64 
under the covers when it needs to expand.
The rules for objects obtained by IARV64 (such as application of MEMLIMIT) 
apply to IARCP64.

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: What size memory object backs an IARCP64

[Mike Schwab]

Processor memory and possibly local paging datasets (if the large
pages can be paged).  And there is an parm that sets the number of
memory large pages at IPL time.

On Thu, Jan 3, 2013 at 3:52 PM, Donald Likens  wrote:
> I did not see the documentation for how many cell were obtained when you 
> built a cell pool with IARCP64. The other thing I did not see documented was 
> how many expansions were made if EXPAND=YES was coded. So I ran some tests:
>
> I first proved that it used a megabyte if EXPAND=NO (it got 2 520192 size 
> cells before I received a bad return code). The fact is I didn't check this 
> LISTSRV first.
>
> My second test was with EXPAND=YES. With this option I got 800 520192 size 
> cells before I received a bad return code. My MEMLIMIT is MEMLIMIT(01024M), 
> so I reason the maximum number of expansions is 400M. Seems like a weird 
> number to be. So I set my MEMLIMIT up. My last test I got 28,097 cells. I am 
> afraid to go higher. Is there a limit of how many expansions are made (other 
> than MEMLIMIT that is)?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: What size memory object backs an IARCP64

[Donald Likens]

I did not see the documentation for how many cell were obtained when you built 
a cell pool with IARCP64. The other thing I did not see documented was how many 
expansions were made if EXPAND=YES was coded. So I ran some tests:

I first proved that it used a megabyte if EXPAND=NO (it got 2 520192 size cells 
before I received a bad return code). The fact is I didn't check this LISTSRV 
first.

My second test was with EXPAND=YES. With this option I got 800 520192 size 
cells before I received a bad return code. My MEMLIMIT is MEMLIMIT(01024M), so 
I reason the maximum number of expansions is 400M. Seems like a weird number to 
be. So I set my MEMLIMIT up. My last test I got 28,097 cells. I am afraid to go 
higher. Is there a limit of how many expansions are made (other than MEMLIMIT 
that is)?

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

Re: What size memory object backs an IARCP64

[Peter Relson]

Primary and secondary cell counts are not provided on IARCP64 simply 
because the value of providing such a thing is far less (if there was any 
at all) than the cost of providing it. It makes sense for CPOOL because 
GETMAIN (STORAGE OBTAIN) is in 8-byte increments. But storage above-2G is 
in 1M increments even if you only want 8 bytes. Once you have to get 1M 
anyway, do you really care about primary vs secondary? There is danger in 
presuming that "old needs" apply to "new situations".

Whether IBM's documentation is deficient our not, the fact is that the 
official documentation -- namely things that you can rely upon and we will 
take an APAR to correct (whether that be a correction in code or a 
correction in the documentation) -- is what is in the books, not what 
might or might not be in a macro prolog.

It is not infrequent that additional data that is in a macro prolog and 
not in a book is not part of the intended programming interface.

And it is all to frequent that useful and necessary data is in neither a 
macro prolog nor a book.

The thing I happen to prefer about macro prologs is that the syntax 
diagrams of many of the newer macros are hierarchical and (to me) easier 
to understand than the "brackets and braces" style of most of the IBM 
books, when it comes to what is required with what. New major functional 
areas may have their own books and use railroad-track syntax diagrams 
which, while cumbersome, at least do let you see the complete syntax too. 
It is quite unlikely that the large amount of resources to change from 
brackets and braces to either other style will be allotted.

FWIW, IARCP64 might not have been a good one to complain about. Before 
complaining about IARCP64, did anyone actually compare the book to the 
macro prolog before making sweeping generalizations? I ask this because 
this macro happens to be one for which the book chapter was, to a large 
extent, created from the same source that produced the macro prolog. The 
book chapter for this macro might even be more correct than the macro 
prolog. Still, there's always the possibility of errors, and always plenty 
of opportunity for improving documentation.  Taking IARCP64 as an example, 
it might be worth having a discussion of things that you the users prefer 
in the macro prolog "style" to the book chapter "style".  And I'm also 
curious about omissions you might find. For example, it is fully 
intentional that the modify form is not part of the book chapter - if 
anything, the macro is in error in not preventing MF=M from being 
specified. Feel free to send me notes offline (or, if you think the 
discussion will be helpful to the group, post there).

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: What size memory object backs an IARCP64

[Scott Ford]

Shmuel,

Very wise, I feel the way only because I have customers who have seemed to 
forgotten how to read a manual. There are questions raised by reading the 
manual or by installations doing implementations. After working for IBM 
consulting we had a SOW , anything above and beyond aw billable. To me that's 
fair.

Scott ford
www.identityforge.com

On Aug 26, 2012, at 9:53 AM, "Shmuel Metz (Seymour J.)" 
 wrote:

> In
> ,
> on 08/25/2012
>   at 09:03 AM, John Gilmore  said:
> 
>> These things said, I agree with Shane that those of us who have 
>> used and know something about the above-the-bar facilities that 
>> IBM is making available have an obligation to be helpful to 
>> colleagues who have less experience with them.
> 
> But no obligation to be helpful to all colleagues. It's perfectly
> reasonable to be more helpful to those who have already done their
> homework. Further, it is not clear that looking things up for others
> instead of directing them to the source is helpful in the long run.
> 
> -- 
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
> 
> --
> 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: What size memory object backs an IARCP64

[Shmuel Metz (Seymour J.)]

In
,
on 08/25/2012
   at 09:03 AM, John Gilmore  said:

>These things said, I agree with Shane that those of us who have 
>used and know something about the above-the-bar facilities that 
>IBM is making available have an obligation to be helpful to 
>colleagues who have less experience with them.

But no obligation to be helpful to all colleagues. It's perfectly
reasonable to be more helpful to those who have already done their
homework. Further, it is not clear that looking things up for others
instead of directing them to the source is helpful in the long run.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: What size memory object backs an IARCP64

[Binyamin Dissen]

On Sat, 25 Aug 2012 18:57:21 + Rob Scott 
wrote:

:>John - maybe you have a better version of the IARCP64 macro than me - but I 
do not see any explicit documentation about the extent size in the macro prolog 
at all (my version is from z/OS 1.13).

:>Perhaps you could point us to the line number in the SYS1.MACLIB(IARCP64) 
member that contains the documentation?

You may see it when he bends over.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: What size memory object backs an IARCP64

[Rob Scott]

John - maybe you have a better version of the IARCP64 macro than me - but I do 
not see any explicit documentation about the extent size in the macro prolog at 
all (my version is from z/OS 1.13).

Perhaps you could point us to the line number in the SYS1.MACLIB(IARCP64) 
member that contains the documentation?

I am aware of the 1Mb extent size due to a presentation I read about IARCP64 a 
couple of years ago, however as far as I can tell, it is not mentioned in 
either the macro prolog or the Assembler Service Reference manual.

I do not believe that Dave Day's post was unreasonable at all - and its 
sentiments about controlling the extent size were (IMHO) sensible for someone 
converting from 31-bit CPOOL usage.


Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: 25 August 2012 14:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What size memory object backs an IARCP64

I confess to some dissatisfaction with both the tone and the substance of Mr 
Day's OP.

He was seeking to use a facility about which he clearly knew nothing in detail 
while|whilst complaining that its syntax was not identical to that of its [very 
approximate] AMODE(31) analogue.

Moreover, the prolog[ue] is in the macro; and my advice that it read it was 
thus straightforward.  Moreover again, this advice is not novel.  Several IBM 
contributors here and on the assembler list have noted that the 'prologs' 
should be consulted for detailed information of this kind.

I should have been prepared to walk him through the use of IARCP64 if he had 
first made even the minimal appropriate effort to understand it.  Things are 
bigger above the bar; he clearly had no grasp of this notion; and without it I 
judged that he was not likely to make much progress.

These things said, I agree with Shane that those of us who have used and know 
something about the above-the-bar facilities that IBM is making available have 
an obligation to be helpful to colleagues who have less experience with them.

Excluding Shane's post from this stricture explicitly, I must also confess that 
I have little patience with a class of other posts that seem to me to be 
insular, suspiciously unanimous, risk-averse, and mediocre.  I shall try to do 
better.

John Gilmore, Ashland, MA 01721 - USA

--
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: What size memory object backs an IARCP64

[John Gilmore]

Mr. Day,

I agree that further exchanges between us would not be useful: your
judgment that you can learn nothing from me is almost certainly
correct.  I shall not comment on one of your posts again.

--jg

On 8/25/12, Dave Day  wrote:
> Mr. Gilmore,
>
>  You are so out of line on this that it is pathetic.
>
>  For me to try to discover if there is some way to influence memory
> allocation is a reasonable approach to writing code.  The fewer
> the number of times my code runs thru allocation, the better it will
> perform.
>
>  CPOOL services provides this for 31 bit users.  When I did not see
> anything for IARCP64, I thought I was missing something, somewhere.
>
>  You're 1st response about EXPAND= indicated you did not understand
> the reason/purpose of the original post.
>  You're 2nd response to check the prologue is inaccurate, from the
> standpoint  of the original post.  There is nothing in the prologue
> that indicates the size of the memory object.  I've read it, and I saw
> nothing.  This is on a 1.12 ADCD system.  Possibly there is on some
> system you have access to, but not on mine.
>
>  And now this.
>
>  The last time you and I had any direct contact on this list was
> some years back, during a discussion about hooking PC's.  I questioned some
> assertions you were making, and the next thing I got from you was a
> private email where you indicated that what you were doing was
> modifying the default assembler action to insert your code into the code
> path for a PC at assembly timehardly the equivalent of code that
> goes into
> a running system and places itself in the code path of of executed
> Program Calls.
>
>  Subsequent to that interchange for some period, I deleted from my
> in-box anything emanating from you.  Some time back I was reading a post
> by someone else where they complimented you on your mastery of the
> English language, and stated they always enjoyed reading your posts if
> for no
> other reason than it sent them to a dictionary and they always learned
> something.   So, with that in mind, I started reading some of your posts.
> And I have to admit, you are able to use the language to a degree that
> few have achieved.
>
>  If you don't like the content of someone's post, the proper thing
> to do is to ignore it.  It is obvious that your language skills far
> exceed your programming skill
> and experience, and from time to time you display that.
>
>  I don't know what happened this time to cause you to dump on me.
> Perhaps you are just getting older, the body is wearing out, and it is
> giving
> you some discomfort when you remove it from your anus to go about your
> daily chores.
>
>  --Dave Day
>
>
> On 8/25/2012 8:03 AM, John Gilmore wrote:
>> I confess to some dissatisfaction with both the tone and the substance
>> of Mr Day's OP.
>>
>> He was seeking to use a facility about which he clearly knew nothing
>> in detail while|whilst complaining that its syntax was not identical
>> to that of its [very approximate] AMODE(31) analogue.
>>
>> Moreover, the prolog[ue] is in the macro; and my advice that it read
>> it was thus straightforward.  Moreover again, this advice is not
>> novel.  Several IBM contributors here and on the assembler list have
>> noted that the 'prologs' should be consulted for detailed information
>> of this kind.
>>
>> I should have been prepared to walk him through the use of IARCP64 if
>> he had first made even the minimal appropriate effort to understand
>> it.  Things are bigger above the bar; he clearly had no grasp of this
>> notion; and without it I judged that he was not likely to make much
>> progress.
>>
>> These things said, I agree with Shane that those of us who have used
>> and know something about the above-the-bar facilities that IBM is
>> making available have an obligation to be helpful to colleagues who
>> have less experience with them.
>>
>> Excluding Shane's post from this stricture explicitly, I must also
>> confess that I have little patience with a class of other posts that
>> seem to me to be insular, suspiciously unanimous, risk-averse, and
>> mediocre.  I shall try to do better.
>>
>> John Gilmore, Ashland, MA 01721 - USA
>>
>> --
>> 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: What size memory object backs an IARCP64

[Dave Day]

Mr. Gilmore,

You are so out of line on this that it is pathetic.

For me to try to discover if there is some way to influence memory 
allocation is a reasonable approach to writing code.  The fewer
the number of times my code runs thru allocation, the better it will 
perform.


CPOOL services provides this for 31 bit users.  When I did not see 
anything for IARCP64, I thought I was missing something, somewhere.


You're 1st response about EXPAND= indicated you did not understand 
the reason/purpose of the original post.
You're 2nd response to check the prologue is inaccurate, from the 
standpoint  of the original post.  There is nothing in the prologue
that indicates the size of the memory object.  I've read it, and I saw 
nothing.  This is on a 1.12 ADCD system.  Possibly there is on some

system you have access to, but not on mine.

And now this.

The last time you and I had any direct contact on this list was 
some years back, during a discussion about hooking PC's.  I questioned some
assertions you were making, and the next thing I got from you was a 
private email where you indicated that what you were doing was
modifying the default assembler action to insert your code into the code 
path for a PC at assembly timehardly the equivalent of code that 
goes into
a running system and places itself in the code path of of executed 
Program Calls.


Subsequent to that interchange for some period, I deleted from my 
in-box anything emanating from you.  Some time back I was reading a post
by someone else where they complimented you on your mastery of the 
English language, and stated they always enjoyed reading your posts if 
for no
other reason than it sent them to a dictionary and they always learned 
something.   So, with that in mind, I started reading some of your posts.
And I have to admit, you are able to use the language to a degree that 
few have achieved.


If you don't like the content of someone's post, the proper thing 
to do is to ignore it.  It is obvious that your language skills far 
exceed your programming skill

and experience, and from time to time you display that.

I don't know what happened this time to cause you to dump on me.  
Perhaps you are just getting older, the body is wearing out, and it is 
giving
you some discomfort when you remove it from your anus to go about your 
daily chores.


--Dave Day


On 8/25/2012 8:03 AM, John Gilmore wrote:

I confess to some dissatisfaction with both the tone and the substance
of Mr Day's OP.

He was seeking to use a facility about which he clearly knew nothing
in detail while|whilst complaining that its syntax was not identical
to that of its [very approximate] AMODE(31) analogue.

Moreover, the prolog[ue] is in the macro; and my advice that it read
it was thus straightforward.  Moreover again, this advice is not
novel.  Several IBM contributors here and on the assembler list have
noted that the 'prologs' should be consulted for detailed information
of this kind.

I should have been prepared to walk him through the use of IARCP64 if
he had first made even the minimal appropriate effort to understand
it.  Things are bigger above the bar; he clearly had no grasp of this
notion; and without it I judged that he was not likely to make much
progress.

These things said, I agree with Shane that those of us who have used
and know something about the above-the-bar facilities that IBM is
making available have an obligation to be helpful to colleagues who
have less experience with them.

Excluding Shane's post from this stricture explicitly, I must also
confess that I have little patience with a class of other posts that
seem to me to be insular, suspiciously unanimous, risk-averse, and
mediocre.  I shall try to do better.

John Gilmore, Ashland, MA 01721 - USA

--
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: What size memory object backs an IARCP64

[John Gilmore]

I confess to some dissatisfaction with both the tone and the substance
of Mr Day's OP.

He was seeking to use a facility about which he clearly knew nothing
in detail while|whilst complaining that its syntax was not identical
to that of its [very approximate] AMODE(31) analogue.

Moreover, the prolog[ue] is in the macro; and my advice that it read
it was thus straightforward.  Moreover again, this advice is not
novel.  Several IBM contributors here and on the assembler list have
noted that the 'prologs' should be consulted for detailed information
of this kind.

I should have been prepared to walk him through the use of IARCP64 if
he had first made even the minimal appropriate effort to understand
it.  Things are bigger above the bar; he clearly had no grasp of this
notion; and without it I judged that he was not likely to make much
progress.

These things said, I agree with Shane that those of us who have used
and know something about the above-the-bar facilities that IBM is
making available have an obligation to be helpful to colleagues who
have less experience with them.

Excluding Shane's post from this stricture explicitly, I must also
confess that I have little patience with a class of other posts that
seem to me to be insular, suspiciously unanimous, risk-averse, and
mediocre.  I shall try to do better.

John Gilmore, Ashland, MA 01721 - USA

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

Re: What size memory object backs an IARCP64

[Rob Scott]

All IARCP64 pool extents are 1Mb in size - therefore there is no need for 
PCELLCT/SCELLCT

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Day
Sent: 24 August 2012 22:11
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What size memory object backs an IARCP64

 The 1.12 manual I looked at has the following.  Doesn't say a bleeping 
thing about the original size.  I wish to move some pools above the bar, and 
have some idea of how many I will need, in each. I would like to be able to 
indicate that at the beginning, but it doesn't appear to be possible.

  --Dave
,EXPAND=YES
,EXPAND=NO
When REQUEST=GET is specified, a required parameter that indicates whether to 
attempt expanding the pool if there is no available cell.
,EXPAND=YES
This parameter tries expanding.
,EXPAND=NO
This parameter does not try expanding.
,TRACE=
On 8/24/2012 4:04 PM, John Gilmore wrote:
> Look at EXPAND=NO|YES
>
> --jg
>
>

--
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: What size memory object backs an IARCP64

[Shane Ginnane]

On Fri, 24 Aug 2012 19:42:08 -0400, John Gilmore wrote:

>As usual for macros of this class, usable only in assembly language
>and PL/X, the only really good, usually very current documentation is
>in the prolog of the macro itself.
>
>Read it.  Then ask questions.

That might just be a less than acceptable answer John.
Whilst I accept that anyone playing in this pond has access to the required 
resources, those of us amongst the interested observers that intermittently 
lose access to licensed systems might also like to know the (complete) answer.

I'm a great believer in RTFM (or suitable analogue), but I'd also like to have 
access to the same - all the time.
That's a f*ck-up on IBMs behalf I know, but we can all help each other here too.

Shane ...

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

Re: What size memory object backs an IARCP64

[John Gilmore]

IARCP64 can allocate pools comprised of cells ranging in size from 1
byte to 512 Kib.

Its design is different from that of the analogous AMODE(31)
facilities and in some ways better.

As usual for macros of this class, usable only in assembly language
and PL/X, the only really good, usually very current documentation is
in the prolog of the macro itself.

Read it.  Then ask questions.

--jg

On 8/24/12, Dave Day  wrote:
>  The 1.12 manual I looked at has the following.  Doesn't say a
> bleeping thing about the original size.  I wish to move some pools above
> the bar, and have some idea of how many I will need, in each. I would
> like to be able to indicate that at the beginning, but it doesn't appear
> to be possible.
>
>   --Dave
> ,EXPAND=YES
> ,EXPAND=NO
> When REQUEST=GET is specified, a required parameter that indicates whether
> to attempt expanding the pool if there is no available cell.
> ,EXPAND=YES
> This parameter tries expanding.
> ,EXPAND=NO
> This parameter does not try expanding.
> ,TRACE=
> On 8/24/2012 4:04 PM, John Gilmore wrote:
>> Look at EXPAND=NO|YES
>>
>> --jg
>>
>>
>
> --
> 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: What size memory object backs an IARCP64

[Dave Day]

The 1.12 manual I looked at has the following.  Doesn't say a 
bleeping thing about the original size.  I wish to move some pools above 
the bar, and have some idea of how many I will need, in each. I would 
like to be able to indicate that at the beginning, but it doesn't appear 
to be possible.


 --Dave
,EXPAND=YES
,EXPAND=NO
When REQUEST=GET is specified, a required parameter that indicates whether
to attempt expanding the pool if there is no available cell.
,EXPAND=YES
This parameter tries expanding.
,EXPAND=NO
This parameter does not try expanding.
,TRACE=
On 8/24/2012 4:04 PM, John Gilmore wrote:

Look at EXPAND=NO|YES

--jg




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

Re: What size memory object backs an IARCP64

[John Gilmore]

Look at EXPAND=NO|YES

--jg

On 8/24/12, Dave Day  wrote:
>  On CPOOL BUILD, one specifies PCELLCT and SCELLCT to tell z/OS how
> to build the pool.  There doesn't appear to be any equivalent for
> IARCP64 REQUEST=BUILD.  No way to communicate to z/OS how many you think
> you will need?  I must be missing something here.
>
>  --Dave
>
> --
> 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

What size memory object backs an IARCP64

[Dave Day]

On CPOOL BUILD, one specifies PCELLCT and SCELLCT to tell z/OS how 
to build the pool.  There doesn't appear to be any equivalent for 
IARCP64 REQUEST=BUILD.  No way to communicate to z/OS how many you think 
you will need?  I must be missing something here.


--Dave

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