The basic problem is that any control scheme I put in place to protect my system is not perfect. The control scheme cannot be made foolproof because fools are too ingenious.
I can take the current production environment and empirically determine the virtual storage profile of everything in it. From that, I can determine a set of likely virtual storage thresholds. I can then, with some "negotiation", arrive at a cost-acceptable paging configuration that supports that set of thresholds. Anyone attempting to go "one step over the line" needs then to go to "Management With A Capital M" (the folks with the BIG checkbook) and win "authorization" to be exempted from the threshold so that I can adjust the physical configuration to support it. Yikes - did I, a bit-twiddler, just invoke the concept of "management control" in a technical discussion? Oh, the shame. The critical production application that all of a sudden needs "goo-gobs of gogglebytes" at o'dark thirty - is broken. At least, that'd be my base assumption until proven otherwise. Or, it may be that a customer has gotten "creative" and discovered a whole new way to (ab)use the application - the law of unintended consequences remains in full force and effect. OODA! (google "ooda loop"). I'm very happy to say that (more than one) "Joe" works here. Joe is most definitely no dope - I've seen what Joe can do. I like Joe - Joe's "creative exploits" provide me with both intellectual stimulation and job security. Thus far, I've been lucky that my primitive controls using "old mechanisms of very limited flexibility or usefulness" (because that's what's available) have caught Joe's more creative exploits in the sandbox and/or development environments. But, it's early in the day and Joe's not yet arrived at work. And DB2 (and probably a few other things) can happily bypass any MEMLIMIT I set and there's nothing I can do about it. Joe's been able to "tame and domesticate" some of those creative exploits - and thus add considerable value. I'm pretty sure the rest of Joe's "creative exploits" will likely surface again someday - and as technology evolves, maybe they'll fit better then. The only constant is change, and its rate is infinitely variable. Today's thresholds might not fit tomorrow's reality. Might not fit today's reality - today's not over yet. Tom Puddicombe Mainframe Performance & Capacity Planning CSC 71 Deerfield Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | [email protected] | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Chris Craddock <[email protected]> Sent by: IBM Mainframe Discussion List <[email protected]> 07/29/2009 01:51 AM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: Suggested MEMLIMIT value for SMFPRMx On Tue, Jul 28, 2009 at 4:32 PM, Martin Packer <[email protected]>wrote: > I've spoken about the "Denial Of Service Attack" possibility many times in > the past. I believe it to be real (if you'll pardon the pun). :-) > IEFUSI/MEMLIMIT have to be effective to contain that. It's not, as has > been said, a decision for end user groups / businesses but rather it's > basic technical hygiene. > The basic problem is that there is no empirical way to distinguish between a legitimate critical business function that needs a few more gogglebytes "right now!" and Joe Dope the app dev whiz kid trying to run a squillion objects in his jvm in twenty batch jobs "coz its cool". IEFUSI and all of the other arcane mechanisms are of very questionable value in each case. Chances are good they would reject the first (legitimate) use and not stop Joe the Dope.. They get in the way of legitimate resource usage and since they require source code modification, assembly and dynamic replacement to get past a middle of the night "oops", they are probably not the best way to tackle the problem. These are old mechanisms of very limited flexibility or usefulness. The z community needs better ones now. It is long past time that the OS began to take care of these resource management issues itself instead of making the system programmer and application programmer play this inane game of guessing how much (virtual!!!) memory a given application is going to use. There is no correct answer. -- This email might be from the artist formerly known as CC (or not) You be the judge. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
