Re: Limit number of frames of real storage per job
Thanks John. It's very useful to hear from the experts. A couple of other comments about garbage collection based on my experiences: - gencon is the current default. Don't automatically change to optthruput without measuring just because it sounds right for a batch job. It depends on the allocation patterns, but for my batch jobs (many short lived objects) the default gencon seems much better. - Left to its own devices, Java will grow or shrink the heap based on GC results to try to maximize performance. I would hope that in most cases this is better than manually controlling the size, although I haven't tried to measure it. - One thing that is unclear in much of the documentation is what some of the strategies are trying to optimize. The strategies targeted at response time sensitive applications are clear - they are trying to minimize GC pause time. Strategies like optthruput are not so clear - optimize throughput vs. what? The documentation sounds like maximum work in minimum elapsed time but many people would want to minimize CPU time, at the expense of elapsed time if necessary. Andrew Rowley Black Hill Software On 08/08/2015 08:03 PM, John Eells wrote: Marcel Mitran, an IBM Distinguished Engineer working on Java, asked me to post this in response to this thread: Andrew's advice is sound. Over-allocating the Java heap is not desirable for many reasons. The JVM's heap and gc policies should be appropriately tuned. For batch applications, where longer pause-times are typically okay to trade-off in exchange for minimal CPU and elapsed time execution, the optThroughput or gencon policies are likely most appropriate (http://www.ibm.com/developerworks/library/j-ibmjava2/). IBM Health Center offers some pretty good tooling to help tune the garbage collector (http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
In 2e88a8852862714ebb4be675da0ec68329463...@505mbx2.corp.vnw.com, on 08/08/2015 at 12:16 AM, Glen Hermannsfeldt (Contractor) c-gl...@livingcomputermuseum.org said: One that I have always wondered about, PL/I (F) at the end of a compile run, tells how much memory it used out of the total available. Does it find out how much is available without paging in all those pages? PL/1 (F) is part of OS/360, which doesn't do paging, although you can run it under , ehich does. Does PL/1 (F) report storage at a micro level or at a macro level? If it chases he FQE chain then there will be paging under, e.g., SVS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Marcel Mitran, an IBM Distinguished Engineer working on Java, asked me to post this in response to this thread: Andrew's advice is sound. Over-allocating the Java heap is not desirable for many reasons. The JVM's heap and gc policies should be appropriately tuned. For batch applications, where longer pause-times are typically okay to trade-off in exchange for minimal CPU and elapsed time execution, the optThroughput or gencon policies are likely most appropriate (http://www.ibm.com/developerworks/library/j-ibmjava2/). IBM Health Center offers some pretty good tooling to help tune the garbage collector (http://www.ibm.com/developerworks/java/jdk/tools/healthcenter/). and...@blackhillsoftware.com (Andrew Rowley) wrote: I have seen the advice to avoid garbage collection in batch from IBMers before. I don't understand it, and I am curious to know where it is coming from. I doubt it is endorsed by the JVM developers. I suspect it might just be that suddenly we can measure memory management overhead, where it is more difficult in other languages. Garbage collection is Java's way of returning unused memory for reuse. You could reduce memory management overhead of a batch C++ program by removing all delete statements, and increasing the virtual storage available until it never ran out. You COULD, but no-one would recommend it as good practice. Overallocating the heap to avoid garbage collection is basically the same thing. snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
allan.stal...@kbmg.com (Staller, Allan) writes: There can also be performance advantages from GC. GC moves objects together in storage, making it much more likely that your application data will be in the processor caches. If GC keeps your data in processor cache it will perform much better than if it's scattered across a GB of storage. apl\360 would allocate new storage for every assignment statement, quickly using every available location in workspace ... and then it would collect everything in contiguous storage (garbage collect) and then start all over again.. This wasn't too bad with apl\360 typically 16kbyte (sometimes 32kbyte) workspaces there were swapped as integral unit. the initial port of apl\360 to cp67/cms for cms\apl was something of a problem because it allowed workspaces that were the size of virtual memory ... and strategy would quickly result in page thrashing (repeatedly touching every virtual page regardless of actual programdata size). before release of cms\apl, this all had to be reworked in order to reduce the massive page thrashing. Besides doing virtual machines, cp67/cms, the technology for the internal network (and corporate sponsored univ bitnet ... where ibm-main originated), GML, and lots of other things ... the science center http://www.garlic.com/~lynn/subtopic.html#545tech also did a number of performance analysis tools. One did processing storage use analysis ... which was used for analyzing cms\apl and bunch of other things. It was also used extensively inside ibm by most product groups in their transition to virtual memory operation (would identify hot-spot instruction use as well as hot-spot storage use) ... and eventually released to customers as VS/Repack (which attempt semi-automated program reoganization to improve operation in virtual memory environment). references to internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet references to bitnet http://www.garlic.com/~lynn/subnetwork.html#bitnet references to gml (sgml, html, etc) http://www.garlic.com/~lynn/submain.html#sgml a major factor in the motivation in transition from os/360 MVT to virtual memory OS/VS2 was significant problems with the way MVT managed real storage, GETMAIN, etc ... regions had to typically be four times larger than really needed. The analysis showed that typical 370/165 MVT 1mbyte machine only supported four regions. A virtual memory MVT on 370/165 1mbyte machine could support 16 regions with little or no paging (aka keep all the in-use data in the 370/165 1mbyte processor cache). Old reference to study motivating to move all 370 to virtual memory: http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Anne Lynn Wheeler wrote apl\360 would allocate new storage for every assignment statement, quickly using every available location in workspace ... and then it would collect everything in contiguous storage (garbage collect) and then start all over again.. This wasn't too bad with apl\360 typically 16kbyte (sometimes 32kbyte) workspaces there were swapped as integral unit. the initial port of apl\360 to cp67/cms for cms\apl was something of a problem because it allowed workspaces that were the size of virtual memory ... and strategy would quickly result in page thrashing (repeatedly touching every virtual page regardless of actual programdata size). One that I have always wondered about, PL/I (F) at the end of a compile run, tells how much memory it used out of the total available. Does it find out how much is available without paging in all those pages? Seems to be something that MVT would not notice, but could be very Important on VS systems. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
The usual C malloc() keeps track of allocated memory with data just before each allocated block. As well as I understand it, GETMAIN works similarly. (snip) I believe that there have been some improvements along the way, but don't know about them. At least since MVS/XA (circa 1982), VSM control information is kept in cell pool extents located in ELSQA. In the OS/VS2 days, I had the manuals describing the way OS/360 does things like GETMAIN. Back when you could almost understand them without a lot of studying. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On 6/08/2015 12:49 PM, Timothy Sipples wrote: All that said, I see way too many cases of operators/sysprogs/managers perversely trying to economize on memory, some perhaps remembering the good old days when Hello World! required only a few bytes. For better or worse, that hasn't been true for at least a couple decades. Suck it up and spend the memory.:-) I'm not sure if I agree with that. Everybody knows that Java is a massive memory hog, and not just on z/OS. IBM knows it, and thank goodness they're working on things like multi-tenated JVMs to help relieve the pressure. Customers should demand innovation from vendors so their software doesn't hog resources instead of just sucking it up and buying more memory. One of the reasons that nginx has displaced Apache HTTP server is because it uses significantly less memory. If you look at big data open source projects you will notice the trend of replacing back-ends running on JVMs with new systems built using new languages like Googles golang. The reason is because golang uses significantly less resources (RAM) and you can then use that RAM to provision more VMs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
There have been lots of war stories from some of the big JVM users like Twitter where long running GC cycles have resulted in fail-over being triggered where a node has been marked as unresponsive. In distributed systems this can lead to serious problems similar to network partitions. It's no secret that languages like Java that use non-deterministic garbage collection have issues and are unsuitable for certain types of applications. A case in point are systems where human safety is involved like avionics or medical hardware. Would you want to be hooked up to a life support machine where a GC cycle can disrupt the reliability of the system? To be fair to IBM they are one of the major innovators in JVM technology. We've had shared classes since Java 5 and with mutli-tenanted JVMs coming and other good stuff like packed-objects on the horizon we're fortunate to have a vendor that is putting serious RD into a technology that is critical to the longevity of our platform. Having said that we've been backed into a corner where all we have on z/OS is Java for modernizing our applications. Other platforms, including zLinux have more choice. zLinux now has Node.js which can totally nuke a typical one-thread-per-connection Java web application for speed and memory. Java isn't a new technology, and while it may be a fine technology it's not cutting edge compared to what's available on other platforms. From a vendor perspective if it wasn't for zIIP offload I would much rather use C++. Modern C++ has deterministic GC and has features such as type inference, lambdas and other goodies years before Java 8. The zIIP is what forces us to use Java. Application developers are different because they have a different set of requirements, such as skills and familiarity. On 7/08/2015 8:14 PM, Staller, Allan wrote: Would'nt the garbage collection cause page-in references as objects are collected and co-located? Thus negatively affecting performance on page sensitive (e.g. CICS) middleware/applications. Seems the advice to avoid garbage collection is sound to me (from a performance perspective). snip I have seen the advice to avoid garbage collection in batch from IBMers before. I don't understand it, and I am curious to know where it is coming from. I doubt it is endorsed by the JVM developers. I suspect it might just be that suddenly we can measure memory management overhead, where it is more difficult in other languages. Garbage collection is Java's way of returning unused memory for reuse. You could reduce memory management overhead of a batch C++ program by removing all delete statements, and increasing the virtual storage available until it never ran out. You COULD, but no-one would recommend it as good practice. Overallocating the heap to avoid garbage collection is basically the same thing. Applications tend to evolve and grow over time. If you deliberately set up your application to avoid GC, you may be in for a rude shock when the application grows and one day GC is triggered. There can also be performance advantages from GC. GC moves objects together in storage, making it much more likely that your application data will be in the processor caches. If GC keeps your data in processor cache it will perform much better than if it's scattered across a GB of storage. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have not looked at the latest info but I still believe there is a *LIMIT* to the amount of MS that one can buy per box. I also think there is a limit to MVS MS. I don't recall what it is but (they did increase it) there is still a practical limitation as to MVS MS. I am not suggesting that the subject is correct but realistically MVS can only handle so much. For a z13 machine, the limits are 10TB on the box, and 4TB in a z/OS partition. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On Fri, 7 Aug 2015 12:55:49 -0400, John Eells wrote: (Jim Mulder) wrote: For a z13 machine, the limits are 10TB on the box, and 4TB in a z/OS partition. ...on z/OS V2.2, and planned for V2.1 at V2.2 GA. Still 1TB for z/OS V1.13. 7) Provide a decade of addressing. Computers never have enough address space. -- Gordon Bell, 1989. Cited in: http://users.ece.cmu.edu/~koopman/titan/rules.html And he is reported to have said (citation needed) that the hardest architectural shortcoming to overcome is too few address bits. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
The usual C malloc() keeps track of allocated memory with data just before each allocated block. As well as I understand it, GETMAIN works similarly. As with the note about garbage collection, that tends to cause a lot of page-in references going through the linked-list of memory blocks. I believe that there have been some improvements along the way, but don't know about them. At least since MVS/XA (circa 1982), VSM control information is kept in cell pool extents located in ELSQA. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On 8/7/2015 at 12:28 PM, Jim Mulder d10j...@us.ibm.com wrote: For a z13 machine, the limits are 10TB on the box, and 4TB in a z/OS partition. Is the 4TB a PR/SM limitation? Or can you define even larger LPARs? The supported limits for Linux are considerably higher than 4TB. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
d10j...@us.ibm.com (Jim Mulder) wrote: For a z13 machine, the limits are 10TB on the box, and 4TB in a z/OS partition. ...on z/OS V2.2, and planned for V2.1 at V2.2 GA. Still 1TB for z/OS V1.13. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
The usual C malloc() keeps track of allocated memory with data just before each allocated block. As well as I understand it, GETMAIN works similarly. As with the note about garbage collection, that tends to cause a lot of page-in references going through the linked-list of memory blocks. I believe that there have been some improvements along the way, but don't know about them. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Friday, August 7, 2015 5:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job Would'nt the garbage collection cause page-in references as objects are collected and co-located? Thus negatively affecting performance on page sensitive (e.g. CICS) middleware/applications. Seems the advice to avoid garbage collection is sound to me (from a performance perspective). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On Thu, Aug 6, 2015 at 4:47 PM, Cheryl Watson che...@watsonwalker.com wrote: Hi John, You might consider changing modifying your stance when it comes to the z13 processors. Although the z13 actually has a slower chip, the processor is faster (partly) because of how they utilize memory. In the z13, IBM has lowered the price of storage so that you can get about three times the amount of storage for the same price as you're spending today. And, in fact, when going to the z13, you should consider doing exactly that! Get triple the memory you're using today (for the same price). The CPU savings will definitely be worth it. I agree with Barry's statement about memory (yes, John, you remembered correctly). And if you study how IBM runs their benchmarks, their results are obtained by running the models with no constraints, such as no paging. So if you want to get similar results, it's worth getting enough memory so that there are no constraints. Best regards, Cheryl I totally agree with you. However, management here has decided to sunset the z. Period. No discussion. Even if it ends up costing more money after it is converted to the cloud, though they insist that it won't. Long term, I think the company wants to cloud-source all of IT. Or at least all of the infrastructure such as servers. I don't have any idea about desktop support, help desk, et al. Lack of need to know. My dream job would be one where I'm a sysprog-equivalent at a company which has 1+ z13 running z/OS, z/VM, and z/Linux and would allow me to get my fingers into each of them, at least a bit. Oh, and no PHBs! -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On Fri, 7 Aug 2015 10:59:00 +1000, Andrew Rowley wrote: There can also be performance advantages from GC. Were one to be slightly nefarious, one might suggest that if the JVM was doing its (GC) job properly, there would be very little code left to run. Not an intrinsic shortcoming of the language, just lame implementations foisted on the users. Reminds me of 14 year old kids writing VB for businesses years ago. But back to the thread - what do you reckon containers might offer z/OS ?. No I'm not just think of docker, but cgroups. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Would'nt the garbage collection cause page-in references as objects are collected and co-located? Thus negatively affecting performance on page sensitive (e.g. CICS) middleware/applications. Seems the advice to avoid garbage collection is sound to me (from a performance perspective). snip I have seen the advice to avoid garbage collection in batch from IBMers before. I don't understand it, and I am curious to know where it is coming from. I doubt it is endorsed by the JVM developers. I suspect it might just be that suddenly we can measure memory management overhead, where it is more difficult in other languages. Garbage collection is Java's way of returning unused memory for reuse. You could reduce memory management overhead of a batch C++ program by removing all delete statements, and increasing the virtual storage available until it never ran out. You COULD, but no-one would recommend it as good practice. Overallocating the heap to avoid garbage collection is basically the same thing. Applications tend to evolve and grow over time. If you deliberately set up your application to avoid GC, you may be in for a rude shock when the application grows and one day GC is triggered. There can also be performance advantages from GC. GC moves objects together in storage, making it much more likely that your application data will be in the processor caches. If GC keeps your data in processor cache it will perform much better than if it's scattered across a GB of storage. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
(I'm traveling on Friday.) I've heard that during Superbowl commercial breaks, municipal water pressure drops measurably. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Thursday, August 06, 2015 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have heard that also about the Beatles on Ed Sullivan, the MASH episode where Col Blake was killed, and the MASH finale itself Chris hoelscher Technology Architect Database Infrastructure Services Technology Solution Services 123 East Main Street Louisville, KY 40202 choelsc...@humana.com Humana.com (502) 714-8615 (502) 476-2538 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: Thursday, August 06, 2015 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Limit number of frames of real storage per job (I'm traveling on Friday.) I've heard that during Superbowl commercial breaks, municipal water pressure drops measurably. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Thursday, August 06, 2015 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
At least recognize it's a tuning opportunity. We lost some granularity going to WLM but there are still knobs in place to effect thruput. Cheryl's Goal Tender (at _www.watsonwalker.com_ (http://www.watsonwalker.com) ) product can tell you if your perceptions are meeting your expectations. Without more information it's difficult to say, more memory, more CPUs, zIIPs or SSD will give the most long term benefit. In a message dated 8/6/2015 1:59:11 P.M. Central Daylight Time, johnmattson...@gmail.com writes: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Well, I can disagree with that on a practical level to some extent. Upgrading memory can sometimes, cost wise, be more like needing so much more electric power that the power company needs to run a higher capacity line to your business and you must then install better / new equipment to support it. It might be cheaper to just find out how to decrease your power (memory) requirements. Perhaps by doing something differently. And I shudder to think what would happen here if every toilet were flushed at the same instant. On Thu, Aug 6, 2015 at 1:58 PM, John Mattson johnmattson...@gmail.com wrote: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Hi John, You might consider changing modifying your stance when it comes to the z13 processors. Although the z13 actually has a slower chip, the processor is faster (partly) because of how they utilize memory. In the z13, IBM has lowered the price of storage so that you can get about three times the amount of storage for the same price as you're spending today. And, in fact, when going to the z13, you should consider doing exactly that! Get triple the memory you're using today (for the same price). The CPU savings will definitely be worth it. I agree with Barry's statement about memory (yes, John, you remembered correctly). And if you study how IBM runs their benchmarks, their results are obtained by running the models with no constraints, such as no paging. So if you want to get similar results, it's worth getting enough memory so that there are no constraints. Best regards, Cheryl Cheryl Watson Watson Walker, Inc. 100 Central Ave, Suite 1013 Sarasota, FL 34236 P-941-924-6565, F-941-924-4892 www.watsonwalker.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Thursday, August 6, 2015 3:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job Well, I can disagree with that on a practical level to some extent. Upgrading memory can sometimes, cost wise, be more like needing so much more electric power that the power company needs to run a higher capacity line to your business and you must then install better / new equipment to support it. It might be cheaper to just find out how to decrease your power (memory) requirements. Perhaps by doing something differently. And I shudder to think what would happen here if every toilet were flushed at the same instant. On Thu, Aug 6, 2015 at 1:58 PM, John Mattson johnmattson...@gmail.com wrote: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have not looked at the latest info but I still believe there is a *LIMIT* to the amount of MS that one can buy per box. I also think there is a limit to MVS MS. I don't recall what it is but (they did increase it) there is still a practical limitation as to MVS MS. I am not suggesting that the subject is correct but realistically MVS can only handle so much. Ed On Aug 6, 2015, at 1:58 PM, John Mattson wrote: As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I have seen the advice to avoid garbage collection in batch from IBMers before. I don't understand it, and I am curious to know where it is coming from. I doubt it is endorsed by the JVM developers. I suspect it might just be that suddenly we can measure memory management overhead, where it is more difficult in other languages. Garbage collection is Java's way of returning unused memory for reuse. You could reduce memory management overhead of a batch C++ program by removing all delete statements, and increasing the virtual storage available until it never ran out. You COULD, but no-one would recommend it as good practice. Overallocating the heap to avoid garbage collection is basically the same thing. Applications tend to evolve and grow over time. If you deliberately set up your application to avoid GC, you may be in for a rude shock when the application grows and one day GC is triggered. There can also be performance advantages from GC. GC moves objects together in storage, making it much more likely that your application data will be in the processor caches. If GC keeps your data in processor cache it will perform much better than if it's scattered across a GB of storage. On the other points: Stess testing - memory management is usually an important factor in application performance, so I'm not sure how valid any stress test that avoided garbage collection would be. (Processor cache effects etc. as much as GC overhead). Memory leaks - this applies to any language - if the memory isn't released, of course you need enough virtual storage to support it between restarts. Page outs - paging Java out is very different to other applications due to the GC memory access pattern. Yes, any inactive application will be subject to page out (maybe? I have seen some information about page fixed pages for Java - I don't know anything about it though). What you don't want is portions of the heap paged out from an active application. When Java performs a GC it is going to touch every page in the heap* - so if you have 200MB paged out and an innocent 50 byte memory allocation triggers GC it has to wait for 200MB of pages to be paged in one by one before the allocation completes (assuming Java/zOS don't recognize and optimize this page-in pattern). This is different to other languages where pages will be paged in one at a time as required, and only if they have active data. I'm not saying to economize on real storage, on the contrary. The original poster asked about testing Java applications with a shortage of real storage - my response is that the performance will probably be unacceptable and it's not worth testing - just make sure you DO have enough real storage for the application. On this side track of heap size and garbage collection my advice is: 1) Do not fear garbage collection. It is part of a normal Java application. It does need to be carefully tuned for response time sensitive applications, but for these applications any paging of the Java heap will likely be disastrous. 2) Do not allocate a heap so large that you risk paging instead of GC. Paging is far worse than GC for Java performance. n.b. the definition of a too large heap is a moving target. I would say it is enough storage inactive for long enough that parts of the heap might be paged out. It would be unusual for a few hundred MB in a normal batch job to be an issue. Regards Andrew Rowley Black Hill Software * My understanding of what happens. I'm happy to be corrected by someone with more knowledge of GC strategies and internals. On 6/08/2015 14:49, Timothy Sipples wrote: I agree with Andrew Rowley's advice so long as it's properly understood to be *general* advice -- rules of thumb. There are some very interesting exceptions. (Aren't there always? :-)) Regarding making the Java heap too large, there are some use cases -- Java batch, notably -- where you really do want to make the heap too large, or at least slightly too large. If the JVM is transitory, and if you can avoid any/all garbage collection during the transitory life of the program, that might be a perfectly wonderful, optimal outcome. It depends. Another potential scenario is stress testing, perhaps during the initial phases, when you're trying to understand the performance and scalability characteristics of an application before allowing garbage collection to interfere with your assessments. (Maybe you don't have the best measurement tools?) Or you're simply trying to determine how much is too much, so you start with too much in your testing. Maybe you have a defective application that's got a memory leak, and garbage collection eventually cannot accomplish anything. The application instance then abends. But to avoid restarting the application instance too frequently you throw too much memory at the application instance(s) until you and/or the vendor can fix the leak. (Been there.) (It depends on your point of view what
Re: Limit number of frames of real storage per job
Well, it doesn't break sewers. http://www.snopes.com/sports/football/flush.asp England turns on 1.75 million TEA KETTLES at the end of Eastenders each weekday. FIVE hydroelectric plants go from 0% to 100% in 5 minutes to power them. http://www.geek.com/news/tea-time-in-britain-causes-predictable-massive-surge-in-electricity-demand-1535023/ After Tiny Tim got married on the Tonight Show, so many americans turned of their TVs and lights the power reduction almost tripped off the power grid. http://www.themcdonnellgroup.com/smart-grid-blog/tiptoe-through-the-smart-grid-part-ii.html On Thu, Aug 6, 2015 at 4:42 PM, J O Skip Robinson jo.skip.robin...@sce.com wrote: (I'm traveling on Friday.) I've heard that during Superbowl commercial breaks, municipal water pressure drops measurably. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Thursday, August 06, 2015 2:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job http://www.lucidenergy.com/how-it-works/ More power! In a message dated 8/6/2015 2:48:49 P.M. Central Daylight Time, john.archie.mck...@gmail.com writes: And I shudder to think what would happen here if every toilet were flushed at the same instant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
As I remember from Barry Merrill... memory should be treated like electricity or plumbing. You should never run out. To put it another way, if you are doing physical paging, buy more memory. It is cheap by comparison to the I/O and cycles needed for physical paging. (Hopefully this has not changed since the last time I was luck enough to hear Barry speak, and hopefully I paraphrased him correctly.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Andrew Rowley wrote: I'm not sure if you can artificially limit the frames available, but I would expect that the effect of paging on a Java application would be BAD. Very bad. Of course! Java needs to perform regular garbage collection. A la Commodore 64 garbage collection I still have bad dreams of that infamous C64 garbage collection... ;-) (I'm not sure whether z/OS is smart enought to recognise the pattern and bring pages back in before they are required) It would be interesting of z/OS can do that. Peter Relson? John Eells? Jim Mulder? What do you say about that? I know IEBGENER, DFSORT and ICETOOL do their checking of storage (memory and temp workspace) and then do with whatever is available. I wouldn't bother testing - I would just say that sufficient memory is required to execute in real storage. Agreed - actually if you have too few memory, you can't do anything. Increase as needed and retry. If I want to do any testing, I will do it in a sandbox with a small configurable memory. (CF STOR,etc.) Another consequence of this behaviour is that you should not make the Java heap too large. Good point. I have written it up in my notes. Thanks! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Blockpaging: paging groups of related pages in and out. Although I don't know if this applies to this situation. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: 05 August, 2015 10:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job Andrew Rowley wrote: I'm not sure if you can artificially limit the frames available, but I would expect that the effect of paging on a Java application would be BAD. Very bad. Of course! Java needs to perform regular garbage collection. A la Commodore 64 garbage collection I still have bad dreams of that infamous C64 garbage collection... ;-) (I'm not sure whether z/OS is smart enought to recognise the pattern and bring pages back in before they are required) It would be interesting of z/OS can do that. Peter Relson? John Eells? Jim Mulder? What do you say about that? I know IEBGENER, DFSORT and ICETOOL do their checking of storage (memory and temp workspace) and then do with whatever is available. I wouldn't bother testing - I would just say that sufficient memory is required to execute in real storage. Agreed - actually if you have too few memory, you can't do anything. Increase as needed and retry. If I want to do any testing, I will do it in a sandbox with a small configurable memory. (CF STOR,etc.) Another consequence of this behaviour is that you should not make the Java heap too large. Good point. I have written it up in my notes. Thanks! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On 5/08/2015 18:45, Elardus Engelbrecht wrote: A la Commodore 64 garbage collection I still have bad dreams of that infamous C64 garbage collection... ;-) Not that I'm saying garbage collection is bad... every language has overhead from tracking free and in use memory. Java defers that overhead to garbage collection time instead of doing it continuously. What IS bad is when it needs to check which objects are still referenced, and half the address space is paged out. Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Andrew Rowley wrote: A la Commodore 64 garbage collection I still have bad dreams of that infamous C64 garbage collection... ;-) Not that I'm saying garbage collection is bad... every language has overhead from tracking free and in use memory. Java defers that overhead to garbage collection time instead of doing it continuously. Indeed. I'll RTFM about Java and garbage collections. Thanks! What IS bad is when it needs to check which objects are still referenced, and half the address space is paged out. Ouch. I also observed that when referring a large table or array and parts of it need to be swapped in/out. Thanks for your notes. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Paging like this also occurred when running a paging OS under (z/)VM(/VSE). If you made the MVS space too large, VM would be paging out the least recently used frame to make room for MVS to page in an even older frame to use for the next frame. On Wed, Aug 5, 2015 at 3:45 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Andrew Rowley wrote: I'm not sure if you can artificially limit the frames available, but I would expect that the effect of paging on a Java application would be BAD. Very bad. Of course! Java needs to perform regular garbage collection. A la Commodore 64 garbage collection I still have bad dreams of that infamous C64 garbage collection... ;-) (I'm not sure whether z/OS is smart enought to recognise the pattern and bring pages back in before they are required) It would be interesting of z/OS can do that. Peter Relson? John Eells? Jim Mulder? What do you say about that? I know IEBGENER, DFSORT and ICETOOL do their checking of storage (memory and temp workspace) and then do with whatever is available. I wouldn't bother testing - I would just say that sufficient memory is required to execute in real storage. Agreed - actually if you have too few memory, you can't do anything. Increase as needed and retry. If I want to do any testing, I will do it in a sandbox with a small configurable memory. (CF STOR,etc.) Another consequence of this behaviour is that you should not make the Java heap too large. Good point. I have written it up in my notes. Thanks! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I agree with Andrew Rowley's advice so long as it's properly understood to be *general* advice -- rules of thumb. There are some very interesting exceptions. (Aren't there always? :-)) Regarding making the Java heap too large, there are some use cases -- Java batch, notably -- where you really do want to make the heap too large, or at least slightly too large. If the JVM is transitory, and if you can avoid any/all garbage collection during the transitory life of the program, that might be a perfectly wonderful, optimal outcome. It depends. Another potential scenario is stress testing, perhaps during the initial phases, when you're trying to understand the performance and scalability characteristics of an application before allowing garbage collection to interfere with your assessments. (Maybe you don't have the best measurement tools?) Or you're simply trying to determine how much is too much, so you start with too much in your testing. Maybe you have a defective application that's got a memory leak, and garbage collection eventually cannot accomplish anything. The application instance then abends. But to avoid restarting the application instance too frequently you throw too much memory at the application instance(s) until you and/or the vendor can fix the leak. (Been there.) (It depends on your point of view what too much means in these cases. Theoretically such a defective application requires an infinite amount of heap, so it can never have too much.) There are situations when it can be perfectly reasonable to page out. Examples: development and test environments, and cloned execution instances when you don't need all the clones running but would like to have some paged in as demand warrants. Basically anything/everything that is highly transient, with temporary and occasional demand, but you want to avoid full startup. It's really thrashing that you want to avoid. Though paging might be necessary to produce thrashing, it's not sufficient. All that said, I see way too many cases of operators/sysprogs/managers perversely trying to economize on memory, some perhaps remembering the good old days when Hello World! required only a few bytes. For better or worse, that hasn't been true for at least a couple decades. Suck it up and spend the memory. :-) Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Limit number of frames of real storage per job
Hi I would like to ask more experienced sysprogs regarding real storage manager. Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. The reason why I need it; I would like to test the performance of a (Java) application in case of lack of frames of real storage. In case of shortage of real storage a paging is expected. And I would like to simulate this situation to see impact a performance of the Java application. I have found MCCAFCTH (defined in IEAOPTxx) but this seems to be LPAR (not job) specifics and moreover this defines length of available frame queue (not number of frames per job). Thx for hints. Regards Vitek -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
MCCAFCTH is not applicable in this case. You are correct that this is a LPAR level control. The only out of the box solution I can think of is to run the job V=R' . See VRREGN in SYS1.PARMLIB(IEASYS00). NOTE: An IPL is*REQUIRED* to change this value. Of course, you could write a driver program to do what you want. i.e. obtain the real storage and then invoke JAVA. JZOS *may* be of some help here. HTH, snip I would like to ask more experienced sysprogs regarding real storage manager. Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. The reason why I need it; I would like to test the performance of a (Java) application in case of lack of frames of real storage. In case of shortage of real storage a paging is expected. And I would like to simulate this situation to see impact a performance of the Java application. I have found MCCAFCTH (defined in IEAOPTxx) but this seems to be LPAR (not job) specifics and moreover this defines length of available frame queue (not number of frames per job). Thx for hints. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Your test cannot be done by limiting the real storage of an individual job. Paging is done by the system in response to the real storage usage of the entire system. If you want to test the Java application is a storage constrained environment, you must make the system storage constraint. This can be done by CONFIGing some storage offline, which you must have made reconfigurable. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vlcek, Vitezslav Vit Sent: 04 August, 2015 16:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Limit number of frames of real storage per job Hi I would like to ask more experienced sysprogs regarding real storage manager. Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. The reason why I need it; I would like to test the performance of a (Java) application in case of lack of frames of real storage. In case of shortage of real storage a paging is expected. And I would like to simulate this situation to see impact a performance of the Java application. I have found MCCAFCTH (defined in IEAOPTxx) but this seems to be LPAR (not job) specifics and moreover this defines length of available frame queue (not number of frames per job). Thx for hints. Regards Vitek -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
1. IiRC, V=R is no longer supported. I could be wrong -- it happens sometimes. 2. The reason for the 'high' frame count is because the job needs them. Limiting them, yourself if it were possible, would strangle the job. z/OS (srm/wlm) knows best as to who needs what and, in general, it's better not to second guess. - -teD - Original Message From: Staller, Allan Sent: Tuesday, August 4, 2015 10:56 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Limit number of frames of real storage per job MCCAFCTH is not applicable in this case. You are correct that this is a LPAR level control. The only out of the box solution I can think of is to run the job V=R' . See VRREGN in SYS1.PARMLIB(IEASYS00). NOTE: An IPL is*REQUIRED* to change this value. Of course, you could write a driver program to do what you want. i.e. obtain the real storage and then invoke JAVA. JZOS *may* be of some help here. HTH, snip I would like to ask more experienced sysprogs regarding real storage manager. Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. The reason why I need it; I would like to test the performance of a (Java) application in case of lack of frames of real storage. In case of shortage of real storage a paging is expected. And I would like to simulate this situation to see impact a performance of the Java application. I have found MCCAFCTH (defined in IEAOPTxx) but this seems to be LPAR (not job) specifics and moreover this defines length of available frame queue (not number of frames per job). Thx for hints. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
V=R won't help anyway since every virtual page is backed by a real page, hence no paging. Dennis Roach, CISSP, PMP IT Security Administration Senior Analyst 2727 Allen Parkway, Wortham Building 3rd Floor, Houston, TX 77019 Work: 713-831-8799 Cell: 713-591-1059 Email: dennis.ro...@aig.com Report information security incidents to: aiglr_security_incide...@aig.com and (818) 673-4030 All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Tuesday, August 04, 2015 12:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job eamacn...@yahoo.ca (Ted MacNEIL) wrote: 1. IiRC, V=R is no longer supported. I could be wrong -- it happens sometimes. snip V=R remains supported. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
I'm not sure if you can artificially limit the frames available, but I would expect that the effect of paging on a Java application would be BAD. Very bad. Java needs to perform regular garbage collection. Garbage collection is likely to touch most of the frames in the address space. It is designed to be fast, but obviously waiting for a page in will delay it. Waiting for multiple page-ins (I'm not sure whether z/OS is smart enought to recognise the pattern and bring pages back in before they are required) will be very slow. If other pages from your application are paged out to allow pages to be brought in it's even worse because they will probably need to be paged straight back in again i.e. thrashing. I wouldn't bother testing - I would just say that sufficient memory is required to execute in real storage. Another consequence of this behaviour is that you should not make the Java heap too large. You want the heap small enough that garbage collection happens often enough to keep those pages in storage. If you have a massive heap that is not collected for a long time and z/OS pages some of it out, the eventual garbage collection will be very slow. Actually one way to test might be to make the Java heap larger than real storage, then create and delete objects to consume it... Andrew Rowley Black Hill Software On 5/08/2015 0:13, Vlcek, Vitezslav Vit wrote: Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. The reason why I need it; I would like to test the performance of a (Java) application in case of lack of frames of real storage. In case of shortage of real storage a paging is expected. And I would like to simulate this situation to see impact a performance of the Java application. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
eamacn...@yahoo.ca (Ted MacNEIL) wrote: 1. IiRC, V=R is no longer supported. I could be wrong -- it happens sometimes. snip V=R remains supported. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
In some cases, the amount real storage occupied by an application can be influenced by the app itself. When we were rolling out DB2 V10, one smallish LPAR ran so short of real storage that it crashed. I even added some real storage to no avail. IBM finally recommended changes to DB2 run-time parms, and the problem went away. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Henry Sent: Tuesday, August 04, 2015 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Limit number of frames of real storage per job On Tue, 4 Aug 2015 14:13:57 +, Vlcek, Vitezslav Vit vitezslavvit.vl...@ca.com wrote: Hi I would like to ask more experienced sysprogs regarding real storage manager. Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. As others have told you it is at the system level. One way to this is to use a program to pagefix a large amount of frames to a utility job and then you can cause paging for your test job. Of course this should be done on a sandbox lpar. Check out CBT Tape file 19 PAGEFIX This utility allows an installation to * FILE 019 //* effectively dynamically remove storage * FILE 019 //* from the system. This can be either to* FILE 019 //* reserve it for some future use or to * FILE 019 //* determine the effects that a major new * FILE 019 //* application may have on paging.* FILE 019 //* * FILE 019 Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
Okay. I knew I might have been wrong. - -teD - Original Message From: John Eells Sent: Tuesday, August 4, 2015 13:01 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Limit number of frames of real storage per job eamacn...@yahoo.ca (Ted MacNEIL) wrote: 1. IiRC, V=R is no longer supported. I could be wrong -- it happens sometimes. snip V=R remains supported. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Limit number of frames of real storage per job
On Tue, 4 Aug 2015 14:13:57 +, Vlcek, Vitezslav Vit vitezslavvit.vl...@ca.com wrote: Hi I would like to ask more experienced sysprogs regarding real storage manager. Is it possible to limit number of frames of real storage on job level? The MEMLIMIT/REGION parameters limit virtual memory of whole address space however I would like to limit the only real memory while the virtual memory remain as it is. As others have told you it is at the system level. One way to this is to use a program to pagefix a large amount of frames to a utility job and then you can cause paging for your test job. Of course this should be done on a sandbox lpar. Check out CBT Tape file 19 PAGEFIX This utility allows an installation to * FILE 019 //* effectively dynamically remove storage * FILE 019 //* from the system. This can be either to* FILE 019 //* reserve it for some future use or to * FILE 019 //* determine the effects that a major new * FILE 019 //* application may have on paging.* FILE 019 //* * FILE 019 Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
