On Thu, Mar 3, 2016 at 3:40 PM, Scott Ford <[email protected]> wrote:

> Hey John,
>
> Yeah both ....we have a assembler routine that reads the subpool entries (
> all that are there ) into a large array/table.
> But I have customers nervous that cant tell how much is in use or whats in
> the subpool.
>

​Well, I guess that means that your code does some sort of "suballocation".
I guess you need to keep some sort of statistics for this in the subpool. I
don't know if I would call this "disturbing" the subpool, but it definitely
updates the statistics block portion. Or <shudder/> your code could write
an SMF record every time it does a read / write / allocate / free and then
post process the SMF information. Uh, I'd make this "logging" optional.​



>
> So thats my situation, I figure dataspace is better. Our exits feed the
> RACF events to the subpool.
>

​I don't really see where disturbing memory in a dataspace is better. But
it certainly helps in the area of conserving virtual storage. Personally,
I'm still found of using HVCOMMON and stating the requirements (so that
PARMLIB can be updated). AMODE(64) is the wave of the future. And is much
easier, IMO, that message around with AR mode.

OOPS, time to start shutting down to go home (stopping on the way to get a
__PIZZA__!!!)​



>
> Scott
>
> On Thu, Mar 3, 2016 at 4:37 PM, John McKown <[email protected]>
> wrote:
>
> > On Thu, Mar 3, 2016 at 3:29 PM, Scott Ford <[email protected]> wrote:
> >
> > > All,
> > >
> > > We in our product build a cache area in Subpool 231.  It is build
> using a
> > > standard
> > > 'Storage Obtain' and use a token to anchor it. I need to monitor the
> > usage.
> > > I am not sure if I can without disturbing it. Am I correct in this
> > > assumption ?
> > >
> > > Scott
> > >
> >
> > B
> > ​y monitor, I take it you mean somehow trace when it is read or written?
> Or
> > do you mean that you want to know how entries in the cache are added &
> > deleted to watch something like a "high water mark" of how much of the
> > cache is used over time?
> >
> >
> > --
> > A fail-safe circuit will destroy others. -- Klipstein
> >
> > Maranatha! <><
> > John McKown
> >
>



-- 
A fail-safe circuit will destroy others. -- Klipstein

Maranatha! <><
John McKown

Reply via email to