I should have thought that Peter Relson's post had clarified these issues more than adequately.
IARCP64 makes above-the-bar storage available in chunks, one mibibyte at a time; and requesters must submanage this storage themselves. IARST64 submanages such chunks for you. Does the 'CP' in 'IARCP64' stand fror 'Cell Pool'? Does the 'ST' in 'IARST64' stand for 'STorage'? Maybe. What indeed is a cell pool? We all know what a buffer pool is; and perhaps its outstanding characteristic is that, since the units it manages are equal in size and thus interchangeable, it can be managed as a stack. This is clearly not the case with these 'cell pools'. They are heap-like rather than stack-like, and their name was thus ill-chosen. John Gilmore, Ashland, Ma 01721 - USA On 9/25/12, David Stokes <[email protected]> wrote: > Steve Comstock wrote: > Can anyone enlighten me about the function / purpose of IARST64? > > > Not that I've used it, but there certainly are several references to cells > in the IARST64 doc and no general description of use in the normal > documentation. I did find the following in zOS 1.10 Implementation Redbook, > which has a bit more information on the subject > > IARST64 This service enables the caller to request private or common > storage > in sizes > from 1 byte to 64 K. IARST64 is equivalent to GETMAIN and FREEMAIN, or > STORAGE OBTAIN or RELEASE for 64-bit storage, or GET and FREE 1 to 64K bytes > of private or common. > > It also seems to confirm the cellpool suspicion: > > IARST64 and IARCP64 service characteristics Both IARST64 and IARCP64 > services have the following common characteristics: > Pool extents are all 1 MB in size. > GET and FREE requests are branch entered. They run with just registers and > only program call when a new pool or new extent is needed. > They use a register interface and have no parameter list. > New pools and extents are implemented in a way that no actual lock or latch > is taken when the function is running. At the last moment, when everything > is settled and it is just required to insert the newly defined pool or > extent into the existing schemes, a Compare-and-Swap is issued. If it fails, > the loser has to clean up and reiterate its process, making another try to > acquire the required pool or extent. It is considered that such a “losing” > situation should rarely be happening. > IARST64 pools cannot be deleted. EOT will clean up a private pool. Common > pools are kept forever. Other characteristics that are shared in common by > IARCP64 and IARST64 are: > No contraction of pools is currently supported in z/OS V1R10. > Boundaries are forced to quadword, cache line, or page, depending on cell > size. > Trailers are used when they fit, to detect overruns. > Double free detected and rejected with abend. > > > > Date: Fri, 21 Sep 2012 10:06:31 -0600 > From: Steve Comstock <[email protected]> > Subject: Questions about IARST64 > > Well, I'm a bit confused by the docs on this service. > > In the Assembler Services Reference, the write up begins: > > "Use IARST64 to request 64-bit Storage Services." > > so I at first assumed this has nothing to do with cell pools but is an > alternative to IARV64 (no guard area, > etc.) > > But just a few lines deeper I see: > > "Note: There is diagnostic support for 64 bit cell pools, created by > IARST64..." > > so that sounds like cell pools. > > A few pages later I find this gem: > > "For storage that is larger than what IARCP64 supports, consider using > IARCP64 or IARV64 GETSTOR or GETCOMMON." > > Huh? If IARCP64 doesn't meet your needs use IARCP64? > > The IARST64 service is not referenced at all in the Assembler Services Guide > doc. > > > Can anyone enlighten me about the function / purpose of IARST64? > > Thanks. > > > > -- > > Kind regards, > > -Steve Comstock > The Trainer's Friend, Inc. > ************************************************* > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
