Thanks! I'm trying to catch potential problems, not create complexity! :-)
Would not have to front-end the macro -- I do all the GETs and FREEs in a subroutine. I could do it there. Would need to use CS as there are lots of processes doing the GETs plus one doing the FREEs. I could increment the GET count with CS and decrement the free count just with normal arithmetic. Subtract free count from get count, and if the result is wildly negative, add 2 billion. (Might not be quite right. I would have to think it through.) Actually, "cells in use" is not the number I really want, although it would certainly point to a problem if it were much larger than "events in queue." The number I really want is "cells allocated (cells in use + free cells)." I don't want to add a whole lot of complexity just to keep an eye out for a potential problem. I will probably just sit tight if there is not something better than the LIST solution I proposed below. Want to hear what Jim has to say on that, especially whether my formula will work, or whether expansions are not 1:1 with extents. If not, I suppose that sum( (extent_end - extent_start) / cell_length ) should work. Perhaps the formula needs tweaking for non-cell overhead. Am I the only one who finds the incompatibility between CPOOL and callable not as clear as it could be? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Scott Sent: Wednesday, May 30, 2012 2:36 PM To: [email protected] Subject: Re: Cell pool questions 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? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
