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
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
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
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
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
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),
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
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
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
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
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
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
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
: 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
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
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
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).
...@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
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
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.
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
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.
, 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
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
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
: 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
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
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
@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
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
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
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
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
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
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
: 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
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
, 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
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
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
--
@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
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
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
43 matches
Mail list logo
