Charles You could solve this requirement using a code solution - for example :
(1) Design a common structure for a "cell pool identifier" - something that includes the cell pool id and some double-word count fields for "GET" and "FREE" operations (2) Build a macro to front-end the CPOOL GET and CPOOL FREE services (eg #CPOOL GET and #CPOOL FREE) that take a pointer to the structure in (1) as a parameter (3) Inside the macro, issue the real CPOOL GETs and FREEs - however you can now maintain the GET and FREE count fields using CSG (4) Write your own service to list/dump the contents of the structures in (1) for diagnostic purposes Obviously the above is simplistic and you could get into a more elegant solution depending on the environment that you are working in. If the program is running in a server, then perhaps you could consider a separate TCB acting as a storage manager (SM) and all other TCBs having some sort of API to GET and FREE cells from within defined pools. If so, the SM TCB could use callable cell pool services to manage the pools and the APIs could just manage your own free cell queue(s). The big advantage of callable cell pool services is the ability to contract the pools if required. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: 30 May 2012 21:09 To: [email protected] Subject: Re: Cell pool questions Jim, thanks. Wow, I totally did not get that. I saw it as two different APIs to the same core service, like the C and assembler APIs to TCP/IP. Not sure if it is just me, but you might want to make that clearer in the documentation, seeing as both are called "Cell Pool Services." I almost did not bother to ask question (1.) as it seemed so obvious that the answer was Yes. Okay, moving right along ... re-formulating the question: Is there any way to determine the number of cells in a CPOOL cell pool? I have a cell pool with a primary and a secondary count. It occurs to me that if, for example, I had a bug in which one time in ten I failed to return a cell to the pool, that I would have no indication of a problem until I got an SC78 abend, which might take quite a while. I am kind of inferring that I could do a LIST and get the number of extents from work area Word 3 (possibly iteratively based on Word 1), from which I guess I could determine the pool size as primary + (secondary * (extents - 1)). Is that correct? Or is there not a one-to-one between pool expansions and extents? Is there a better way? Actually, I now see that that method won't work very well because I have no way of making sure that there would be no intervening GET requests. The GET requests come from asynchronous processes which the main task has no ability to pause. I guess I could just make sure the work area was large enough to get all of the extents in a single call? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jim Mulder Sent: Wednesday, May 30, 2012 12:23 PM To: [email protected] Subject: Re: Cell pool questions > 1. Can I mix CPOOL and CSRPxxxx calls on the same cell pool? Could one for > example use CPOOL GET for performance, and CSRPQPL to obtain > statistics that > are not available through CPOOL? I already have working CPOOL macro code, > but I would like to get the CSRQPL statistics. Can I do so without having to > re-write my working CPOOL macro code? > > 2. Assuming the answer to (1.) is Yes, what CSRPQPL calls "anchor_addr" -- > is that the same datum that CPOOL calls "pool id"? No, CPOOL and CSRPxxxx are completely different services, which have no relation to each other. ---------------------------------------------------------------------- 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
