Am 30.12.2019 um 17:05 schrieb <midrangel@xxxxxxxxxxxxxxxxx> <midrangel@xxxxxxxxxxxxxxxxx>:
While I can speculate all day about why you would want that memory management granularity, I can tell you work management is not going to accomplish what I think you are suggesting below.
Now I'm even more confused. What's the point in having memory pools, then?
Why do I want it: I want to reduce ODBC connection impact. That is, if inserts have been running for a while, my interactive job seemingly gets swapped out and I need to wait for it to be paged back into memory. I want to suppress this wait time to an unavoidable minimum. Maybe we're not talking about the same thing?
I guess that just that is what Frank Soltis and his guys envisioned from the beginning in S/38: To keep response times low, confine jobs competing for (back then ridiculously expensive and thus scarce) memory resources into a single entity, an SBS, so the whole machine won't thrash but just jobs in the aforementioned SBS. Which is also bad in itself, because disk activity will be high and affect other jobs in other subsystems. This can be circumvented only by moving every object that SBS is utilizing into a separate ASP. Right?
What's your opinion?
PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.