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
-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
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
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 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
24 matches
Mail list logo
