Hi John, We (I) had an idea similar to this several years back and now we are already sort of doing this with both our SyzCMD/z and SyzMPF/z products. They allow the user (or via automation) to create a memory area that we assign the name/token pair to, then we allow that area to be used by any other part of our software. (At first) It was great, and it gave us 16 whole bytes :) and it was user-select-able to be persistent for just the "job" that created it (or on who's behalf it was created) or until the next IPL. As I mentioned, it used to be limited to that 16 byte area, but when several customers said they wanted "a little bit" more, we made the size (almost) unlimited by playing with the way IBM handled the name/tokens. But as that space used is still within ECSA, you still have to be 'reasonable' on size, so we placed a arbitrary user- select-able limit of anywhere between 128 bytes to 2K limit on the spaces we created as well as the "total" space that can be used in this way (I think we limit it to no more than 20 MB total or to within 20% of exhausting their available ECSA (80% used max) (whichever is lower)). We now have a new version that we are getting ready to ship (in February or March) that has added the capability of keeping this area in a "Space" (sort of like shared temp data space/hiper space) and it allows us to take away most of the limits on size. It requires a special little started task that owns the space and does all of the real work, and incidentally makes management relatively simple. It's not quite as fast as having the data in ECSA (and we still allow, and actually prefer clients use that option), but has the advantage of being allowed to be much bigger.
I think that the "hard" part was working out how to do the clean-up side of things and also how to make sure that we 1) didn't let someone get carried away and fill up ECSA and 2) have a way to, both on demand and periodically, perform a "sanity check" or "garbage collection" so that we don't leave stuff sitting around that should no longer be there. That necessitated adding an additional option when the data was created (besides JOB duration and permanent duration) that was a "Variable" duration which the creator can use to set an "expiration limit" such that even if the JOB had not yet completed (some jobs can run for months), or in the case where the data needed to be semi-permanent, that we had a way to remove it "semi-automatically". We are also providing an "sort of" API that will allow the sites to access this data from within their own code. I want to call it an API because that makes it sound sexy, but truly it's just a called program. So, while it doesn't do exactly what you were looking for, it does allow that type of functionality. At some point we are hoping to be able to allow direct access to the storage space, but we are probably still a ways off on that, and I have no idea who would even have a need for it right now. It would just be kind of cool. Brian Westerman Syzygy Incorporated ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
