In
of87d06c78.43f4a289-on80257cc2.002a9f6c-80257cc2.002c3...@uk.ibm.com,
on 04/22/2014
at 09:02 AM, Martin Packer martin_pac...@uk.ibm.com said:
VIO has, in any case, been seen as CPU expensive. Because it's
simulating a device. I would, however, quite like to see VIO in
Memory reborn - with
...@patriot.net
To: IBM-MAIN@listserv.ua.edu
Date: 23/04/2014 12:20
Subject:Re: SORT ando MEMLIMIT best practice
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
In
of87d06c78.43f4a289-on80257cc2.002a9f6c-80257cc2.002c3...@uk.ibm.com,
on 04/22/2014
at 09:02 AM
Of Martin Packer
Sent: Wednesday, April 23, 2014 13:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT ando MEMLIMIT best practice
I don't disagree: I didn't really talk implementation but I want to see very
large temp data sets in memory, controlled via DFSMS and not too expensive.
First step is very
On 4/22/2014 4:58 PM, Shane Ginnane wrote:
Linux (on x86_64) has been doing it forever - goes even further, allowing
reference to a 32 Gig heap rather than just 4 Gig.
z/OS Java compressed references also go to 32G. (The USE2GTO32G= keyword
on the IARV64 macro should provide valuable insight
I don't know.
Regards,
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Scott Ford
Sent: Friday, April 18, 2014 16:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MEMLIMIT best practice
Kees:
is there any way programmatically
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Friday, April 18, 2014 16:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SORT ando MEMLIMIT best practice
o What are the consequences of allocating SORTWKn to VIO?
DFSORT
...@klm.com
To: IBM-MAIN@listserv.ua.edu
Date: 22/04/2014 07:40
Subject:Re: SORT ando MEMLIMIT best practice
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
On Mon, 21 Apr 2014 23:03:24 +0100, Martin Packer martin_pac...@uk.ibm.com
wrote:
I think the term pointer compression is relevant here - to java heap
just above 2GB.
Yes. Very clever. I was trying to find a link to post and found this:
On Tue, 22 Apr 2014 08:46:40 -0500, Mark Zelden wrote:
On Mon, 21 Apr 2014 23:03:24 +0100, Martin Packer wrote:
I think the term pointer compression is relevant here - to java heap
just above 2GB.
Yes. Very clever.
...
I didn't realize it was being done on other platforms also.
Linux (on
On Mon, 21 Apr 2014 07:01:50 -0500, Tom Marchant wrote:
On Fri, 18 Apr 2014 14:07:29 -0500, Paul Gilmartin wrote:
Are there separate pools of real storage for above the bar and below the bar?
Pools? No. Pools are a software concept.
Real storage with real addresses 2 GiB are below the bar.
On Mon, 21 Apr 2014 11:44:01 -0500, Paul Gilmartin wrote:
On Mon, 21 Apr 2014 07:01:50 -0500, Tom Marchant wrote:
Real storage with real addresses 2 GiB are below the bar.
Real storage with real addresses 2 GiB are above the bar.
ITYM = 2 GiB
Right.
But what do you call real storage with a
On Mon, 21 Apr 2014 11:44:01 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
On Mon, 21 Apr 2014 07:01:50 -0500, Tom Marchant wrote:
On Fri, 18 Apr 2014 14:07:29 -0500, Paul Gilmartin wrote:
Are there separate pools of real storage for above the bar and below the bar?
Pools? No. Pools are a
:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Mark Zelden m...@mzelden.com
To: IBM-MAIN@listserv.ua.edu
Date: 21/04/2014 19:19
Subject:Re: SORT ando MEMLIMIT best practice
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
paulgboul...@aim.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, April 18, 2014 2:07:29 PM
Subject: Re: SORT ando MEMLIMIT best practice
On Fri, 18 Apr 2014 17:54:01 +, DASDBILL2 dasdbi...@comcast.net
wrote:
... Giving a gazillion bytes above the bar to process X does not
necessarily mean
best practice
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
On 4/18/2014 12:02 PM, Martin Packer wrote:
BTW SMF 30 also has the limit and how obtained in it. So you can see
what
an individual job / address space can get at and why.
As one might imagine, the system
/2014 00:34
Subject:Re: MEMLIMIT best practice
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
On 4/4/2014 12:47 PM, R.S. wrote:
I'm looking for some ROT (rule of thumb) for MEMLIMIT.
What I learnt:
- default limit is set in SMFPRMxx
- the limit can be affected
W dniu 2014-04-18 01:25, Ed Jaffe pisze:
On 4/4/2014 12:47 PM, R.S. wrote:
I'm looking for some ROT (rule of thumb) for MEMLIMIT.
What I learnt:
- default limit is set in SMFPRMxx
- the limit can be affected by IEFUSI or other exit (this is not my
case)
- REGION=0 implies default MEMLIMIT
We have 4G, not from recommendations, but from experience. CICS 5.x required
this.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of R.S.
Sent: Friday, April 18, 2014 11:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MEMLIMIT best
Of Vernooij, CP
(SPLXM) - KLM
Sent: Friday, April 18, 2014 4:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MEMLIMIT best practice
We have 4G, not from recommendations, but from experience. CICS 5.x required
this.
Kees.
-Original Message-
From: IBM Mainframe Discussion List
Correct, CICS 4.1 requires 4G.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Chase, John
Sent: Friday, April 18, 2014 13:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MEMLIMIT best practice
CICS TS 5.1 requires MEMLIMIT=6G
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Chase, John
Sent: Friday, April 18, 2014 13:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: MEMLIMIT best practice
CICS TS 5.1 requires MEMLIMIT=6G, according to the doc:
http://pic.dhe.ibm.com
On 2014-04-18, at 03:48, R.S. wrote:
W dniu 2014-04-18 01:25, Ed Jaffe pisze:
On 4/4/2014 12:47 PM, R.S. wrote:
If you specify absolutely nothing about MEMLIMIT anywhere, the
system-provided default is 2G so obviously you can't go wrong with that in
SMFPRMxx.
Right. IBM's provided
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin
On 2014-04-18, at 03:48, R.S. wrote:
W dniu 2014-04-18 01:25, Ed Jaffe pisze:
On 4/4/2014 12:47 PM, R.S. wrote:
If you specify absolutely nothing about MEMLIMIT anywhere, the
I do not remember that IBM has ever characterized its defaults as
'optimal', whatever that may mean without context. What it does try
to do---with, I think, reasonable success---is to provide defaults
that are innocuous in the sense that they do not give trouble for most
jobs most of the time.
My IEFUSI still prevents REGION=0M for all but STCs. Sort of worthless these
days on
95% of the systems, but I actually still have some small monoplex LPARs that
only have 1.2G - 2G, so the old region=0M and variable length getmain issue
is still a valid concern for those LPARs. Actually,
Paul Gilmartin wrote:
R.S. wrote:
If you specify absolutely nothing about MEMLIMIT anywhere, the
system-provided default is 2G so obviously you can't go wrong with that in
SMFPRMxx.
Right. IBM's provided defaults are always optimal.
Agreed. But, as John Gilmore said, IBM's defaults are
/storage/dfsort/
IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on
04/18/2014 01:15:51 PM:
From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@listserv.ua.edu,
Date: 04/18/2014 01:16 PM
Subject: Re: SORT ando MEMLIMIT best practice
Sent by: IBM Mainframe
function?
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Betten
Sent: Friday, April 18, 2014 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SORT ando MEMLIMIT best practice
DFSORT does look at available resources before
:37:02 PM:
From: Gibney, Dave gib...@wsu.edu
To: IBM-MAIN@listserv.ua.edu,
Date: 04/18/2014 01:37 PM
Subject: Re: SORT ando MEMLIMIT best practice
Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
I don't wish to start a SORT war. :)
Syncsort has the GDSM STC which
MEMLIMIT best practice
On 2014-04-18, at 03:48, R.S. wrote:
W dniu 2014-04-18 01:25, Ed Jaffe pisze:
On 4/4/2014 12:47 PM, R.S. wrote:
If you specify absolutely nothing about MEMLIMIT anywhere, the
system-provided default is 2G so obviously you can't go wrong with that in
SMFPRMxx
On 4/18/2014 7:07 AM, Scott Ford wrote:
is there any way programmatically that MEMLIMIT can be queried to determine the
value ?
6 RAXLVMemLim Bit(64) RXZ,/* Address Space Memory
limit in MB@P8C*/
--
Edward E Jaffe
Phoenix Software
Ed,
Thank you, just what I needed. Much appreciated
Scott ford
www.identityforge.com
from my IPAD
On Apr 18, 2014, at 2:18 PM, Ed Jaffe edja...@phoenixsoftware.com wrote:
On 4/18/2014 7:07 AM, Scott Ford wrote:
is there any way programmatically that MEMLIMIT can be queried to determine
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: Ed Jaffe edja...@phoenixsoftware.com
To: IBM-MAIN@listserv.ua.edu
Date: 18/04/2014 19:18
Subject:Re: MEMLIMIT best practice
Sent by:IBM Mainframe
On Fri, 18 Apr 2014 17:54:01 +, DASDBILL2 dasdbi...@comcast.net wrote:
... Giving a gazillion bytes above the bar to process X does not necessarily
mean that process X will ruin system performance. The gazillion bytes could
also have come from below the bar (for some values of
The gazillions of bytes above the bar is great, but I still have customers who
complaint because we run ALL31 or AMODE 31 or RMODE 31. I attribute this to
unchanged legacy programs over the years.
Scott ford
www.identityforge.com
from my IPAD
On Apr 18, 2014, at 3:07 PM, Paul Gilmartin
:07:29 PM
Subject: Re: SORT ando MEMLIMIT best practice
On Fri, 18 Apr 2014 17:54:01 +, DASDBILL2 dasdbi...@comcast.net wrote:
... Giving a gazillion bytes above the bar to process X does not necessarily
mean that process X will ruin system performance. The gazillion bytes could
also
/
IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on
04/18/2014 01:15:51 PM:
From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
To: IBM-MAIN@listserv.ua.edu,
Date: 04/18/2014 01:16 PM
Subject: Re: SORT ando MEMLIMIT best practice
Sent by: IBM Mainframe Discussion List
W dniu 2014-04-18 16:31, Paul Gilmartin pisze:
On 2014-04-18, at 03:48, R.S. wrote:
W dniu 2014-04-18 01:25, Ed Jaffe pisze:
On 4/4/2014 12:47 PM, R.S. wrote:
If you specify absolutely nothing about MEMLIMIT anywhere, the system-provided
default is 2G so obviously you can't go wrong with
On 4/18/2014 12:02 PM, Martin Packer wrote:
BTW SMF 30 also has the limit and how obtained in it. So you can see what
an individual job / address space can get at and why.
As one might imagine, the system control block also contains the source
of the MEMLIMIT:
6 RAXLVMemLimS FIXED(8) RXZ,
On 4/4/2014 12:47 PM, R.S. wrote:
I'm looking for some ROT (rule of thumb) for MEMLIMIT.
What I learnt:
- default limit is set in SMFPRMxx
- the limit can be affected by IEFUSI or other exit (this is not my case)
- REGION=0 implies default MEMLIMIT ignore (MEMLIMIT=inifinity)
- gotcha:
I'm looking for some ROT (rule of thumb) for MEMLIMIT.
What I learnt:
- default limit is set in SMFPRMxx
- the limit can be affected by IEFUSI or other exit (this is not my case)
- REGION=0 implies default MEMLIMIT ignore (MEMLIMIT=inifinity)
- gotcha: MEMLIMIT=0 does not mean infinity, it really
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of R.S.
I'm looking for some ROT (rule of thumb) for MEMLIMIT.
What I learnt:
- default limit is set in SMFPRMxx
- the limit can be affected by IEFUSI or other exit (this is not my case)
- REGION=0 implies default
42 matches
Mail list logo
