Freezing operations of LPAR
Is it possible to freeze the operations of any LPAR ? I have 4 LPARs configured in my OS/390 system with production uncapped and other capped sometimes when there is heavy CPU requirement for Prod LPAR I have to bring down other 3 lpars so tht all MIPS will be used by Production alone but bringing down other lpars is time consuming. I wanted to Freeze the operations of other 3 LPARs using HMC so tht CPU will be free for production usage and once production requirement is over I can restored other LPAR operations. Is it possible without changing dynamically MIPS allocations ? Jacky -- 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
Re: LPAR Capping
On Sun, 1 Jan 2006 10:30:35 +1000, ibm-main [EMAIL PROTECTED] wrote: Seems you are trying to use for the wrong reason. Why don't weightings fulfil your requirements - especially if you are prepared to use the whole box ???. Soft capping is a *financial* contortion, not a technical aid to solving allocation issues. Yes Shane Gil has the same pb i have . I have too much power for our wallet . Soft capping is giving me 95 % of the time what i want . But sometimes one of my LPAR needs a lot of MIPS for few hours , at a time when another lpar is not busy ... and the one needing the horsepower ends up capped . So this is why i am also one of the people who likes the CF trick . Like Gill i'd like to be able to use a total amount not several LPAR amounts .. Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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
CPU Contention Issue
This is with reference to RMF Report analysis regarding MVS Busy and LPAR Busy parameter ... Attached is the RMF Report. Almost everyday we are facing CPU Contetion issues. From the report we can infer tht for most of the intervals there were 100% CPU Contention however is it possible to get exact reason for the CPU Contenction from RMF Report ?? Wht could be the reasons for CPU contention ? Are there any performance related parameters which need to consider while analysing these RMF reports ?? I heard some MVS performance parameters like ratio of LPAR to MVS Busy (by Peter Enrico) can anyone send me any reference material (by Peter Enrico) in tht regard ?? For some intervals ther is MVS Busy is 100 % where as LPAR Busy is 100%. Can we say tht thr is requirement of upgradation of CPU on the basis of these RMF Reports ?? We have 2 CICS regions out of which one CICS region uses C++ programmin while other uses COBOL programmin recently it has been observed tht COBOL CICS region is hoggin the CPU and which in turn affects C++ CICS region. Under what conditions we can say tht there is requirement of CPU Upgradation ?? what should be the policy of organisation for S/390 CPU Upgradation ? Jacky -- 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
Re: Capturing a reply id from a WTOR
Thanks for the insight. It is appreciated. Craddock, Chris wrote: That's a non-sequitur. The exit routine (typically) is NOT linked AC(1) because that is only relevant for job step programs. The exit routine must be loaded from an APF-authorized library, but that is primarily to ensure installation control over the software that gets control in exit points. The exit routine's authorization is dictated by what ever environmental state that exists when the exit is entered. Most system exits are entered in supervisor state (and key zero) and are therefore able to do anything they want. I have NO knowledge of HSM, but I would bet large that all of its exits are entered in supervisor state. If so, you have been solving a non-problem, lo these many years. Then it almost certainly is entered in sup state... but at a minimum it would be considered an authorized environment, either by JSCBAUTH being set as a result of the AC(1) job step program, or by running in a system key. Which address space is the local address space? The issuer of HRECALL? Or you could just bag the whole idea and implement a reliable signaling mechanism between HSM and your STC. Pause/Release services first became available in (I think) OS/390 2.5, if not earlier. They are available on every currently supported release. They are also a far superior mechanism for signaling between address spaces than dinking around with WTORs and (unserialized!!) ORE chains. You may still need to provide a mechanism for queuing requests from multiple callers unless (as you surmised) the exit is naturally serialized by HSM. CC -- 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
