-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mike Schwab
Sent: Monday, March 04, 2013 23:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Paging Behaviour; was: Re: DFSORT Weirdness
When we have done PAGEADD and PAGEDELs for Volume
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ted MacNEIL
Sent: Tuesday, March 05, 2013 00:12
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Paging Behaviour; was: Re: DFSORT Weirdness
your case I would hypethosis it tries the first page dataset on a
volume and only uses the second if the first one
@LISTSERV.UA.EDU
Date: Tue, 5 Mar 2013 10:45:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Paging Behaviour; was: Re: DFSORT Weirdness
Not true:
Pre-PAV, you could(should) have only 1 page dataset per volume.
With PAV
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ted MacNEIL
Sent: Tuesday, March 05, 2013 15:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Paging Behaviour; was: Re: DFSORT Weirdness
That's what I said.
You'd get a message along the lines
Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Paging Behaviour; was: Re: DFSORT Weirdness
I don't understand what you mean.
I said that you were always able to put more than one page dataset on a
volume, but that is was stongly not recommended in the pre-PAV period
@LISTSERV.UA.EDU] On Behalf
Of Patrick Falcone
Sent: Monday, March 04, 2013 03:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Hmm...I've been following this as well. So I'm wondering what affect
dynamically cutting over the disk subsystem by delete/draining from old aux.
while adding new
AFAIK, ASM has always [1] worked this way.
Page slots seem to be allocated in a round-robin fashion so that
Slot usage (not percentage) should be roughly equal across all local page data
sets.
[1] This may not have been true for some of the early releases of MVS (think
pre-ESA).
HTH
snip
a few weeks ago, so much goes on but so little time to handle...
From: Vernooij, CP - SPLXM kees.verno...@klm.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, March 4, 2013 3:44 AM
Subject: Re: DFSORT Weirdness
Yes!
Page dataset utilization is not what you expect
IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on
03/04/2013 10:50:22 AM:
If all page data sets are present at an IPL they will presumably get
approximately equal, round-robin use. If not, i.e., if some of them
are added after that IPL, the added ones will perhaps be less used,
:Paging Behaviour; was: Re: DFSORT Weirdness
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
All data sets are the same size at 5,008 cylinders, half of a 3390-9.
LOCAL 55% OK 1208 SYS1.PAGELOC0
LOCAL 34% OK 1208 SYS1.PAGELOC1
LOCAL 51% OK 1308
When we have done PAGEADD and PAGEDELs for Volume migrations to new
UCBs, what it does is balance by I/O. While the PAGEDELS are going,
as soon as one write is completed, the next write starts, pretty much
round robin. In your case I would hypethosis it tries the first page
dataset on a volume
your case I would hypethosis it tries the first page dataset on a volume and
only uses the second if the first one is still busy.
I don't know how it works post-PAV.
But, before that you could only have one active PAGE D/S per pack.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL
Yes Jim, that pretty much sums it up. We essentially plugged in a
new disk drive and suddenly DFSORT didn't work the way it used to.
Despite everything everyone says, something else is influencing
DFSORT's decisions on how much storage to use and where it's going
to get it. We do know
/developerworks/mydeveloperworks/blogs/MartinPacker
From: Jim Mulder d10j...@us.ibm.com
To: IBM-MAIN@listserv.ua.edu,
Date: 03/03/2013 09:19 PM
Subject:Re: DFSORT Weirdness
Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
Yes Jim, that pretty much sums it up
One thing that's worth pointing out - and is relevant to DFSORT and
memory
in general but possibly not this situation in particular - is that Flash
Express capacity is not regarded as free or otherwise for the purposes
of
STGTEST SYSEVENT.
This is, to me, a significant benefit of Flash
of things.
Thanks for your input Jim.
From: Jim Mulder d10j...@us.ibm.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sunday, March 3, 2013 4:19 PM
Subject: Re: DFSORT Weirdness
Yes Jim, that pretty much sums it up. We essentially plugged in a
new disk drive
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Saturday, March 02, 2013 01:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
That's just crazy talk. While there might be some load balancing
related
http://www-01.ibm.com/support/docview.wss?uid=isg1II13495
On Thu, Feb 28, 2013 at 11:29 AM, Roberto Halais
roberto.hal...@gmail.com wrote:
We had a similar situation and ended coding the sort parms:
EXPOLD=0
EXPMAX=50%
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get
The point I was making about crazy talk was to dispel the notion that was
presented in two posts that ASM takes the size of the smallest data set, and
uses only that amount in larger data sets. That is an incorrect notion. ASM is
quite willing to use all of the slots in any page data set
Engineering
State of Delaware
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, CP - SPLXM
Sent: Friday, March 01, 2013 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Anne,
Just for the picture: how much memory
: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Adams, Anne (DTI)
Sent: Friday, March 01, 2013 13:24
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
The LPAR has 14GB of memory and the six page data sets have (yikes!) five
different sizes (1000, 1000, 1500
That's just crazy talk. While there might be some load balancing related
motivations for using similar sized page data sets, ASM most
certainly uses the full capacity of all of the data sets
Okay.
Maybe things have changed.
Maybe my mind has gone.
When I first started in Performance, we were
.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Adams, Anne (DTI)
Sent: Friday, March 01, 2013 7:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
The LPAR has 14GB of memory and the six page data sets have (yikes!) five
, March 01, 2013 15:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
That's just crazy talk. While there might be some load balancing
related motivations for using similar sized page data sets, ASM most
certainly uses the full capacity of all of the data sets
Okay.
Maybe things have
@listserv.ua.edu,
Date: 03/01/2013 08:23 AM
Subject: Re: DFSORT Weirdness
Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
The LPAR has 14GB of memory and the six page data sets have (yikes!)
five different sizes (1000, 1000, 1500, 2000, 2500, and 3000
cylinders). Apparently the statement
@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Yes, I do remember all these things, but they are not relevant here. As
you say things have changed and the topic is now the current paging
situation.
Kees.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Betten
Sent: Friday, March 01, 2013 9:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
I've been working on the ETR with our L2 support and waiting for some doc to
confirm my assumptions. But I figure I better update
fast enough.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Thursday, February 28, 2013 10:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
-cut--
That's just crazy talk. While there might
@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Jim,
So I don't have to keep my local page datasets all the same size anymore ?
(Like many this was a rule I had ingrained to always have all local pages
datasets the same size)
Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925
-MAIN@LISTSERV.UA.EDU,
Date: 03/01/2013 06:58 AM
Subject:Re: DFSORT Weirdness
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
Perhaps they don't have all the information. This occurs even when AUX
subsystem is at 0%. The first time it occurred, the AUX subsystem
, March 01, 2013 22:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
I'm following this thread with rapt attention. We have what I believe to
be the same problem. I never before associated it with DASD architecture
nor with a particular product like DFSORT. Our development system gets
In 39874b7a8e2cdd419863d9abff6389e8153...@wil-exmbx04.bbtnet.com, on
03/01/2013
at 02:21 PM, DiBianca, Robert rdibia...@bbandt.com said:
Another item about paging is that if a task has pages sent to the
page dataset, that page is not freed until the task ends.
Or the task frees the virtual
,
and it looks like he's using a bit less than half of it.
--
Tom Marchant
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Skip Robinson
Sent: Friday, March 01, 2013 22:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
I'm
Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: Tom Marchant m42tom-ibmm...@yahoo.com
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 03/01/2013 02:46 PM
Subject:Re: DFSORT Weirdness
Sent
That's just crazy talk. While there might be some load balancing
related motivations for using similar sized page data sets, ASM most
certainly uses the full capacity of all of the data sets when
calculating auxiliary storage shortage thresholds.
It might be obsolete talk. (Now I feel
That said, there may have been (and may still be) *performance-related*
reasons for using similar sized paged data sets.
Capacity planning and system tuning of that nature is not my area of
expertise.
I was always taught from the performance related side to keep them the same
size.
I see
Hello friends,
We're experiencing some weird DFSORT behavior after replacing our DS8100 with a
DS8800. Immediately after we configured and then moved our page datasets to a
DS8800, a number of DFSORT jobs started consuming all available (and sometimes
not so available) memory. We noticed in
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Adams, Anne (DTI)
Sent: Thursday, February 28, 2013 15:27
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DFSORT Weirdness
Hello friends,
We're experiencing some weird DFSORT behavior after replacing our DS8100
Adams, Anne wrote:
We're experiencing some weird DFSORT behavior after replacing our DS8100 with
a DS8800. Immediately after we configured and then moved our page datasets to
a DS8800, a number of DFSORT jobs started consuming all available (and
sometimes not so available) memory. We noticed
.
Anne R. Adams
DTI, Systems Engineering
(302) 298 - 3196
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: Thursday, February 28, 2013 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Adams
@LISTSERV.UA.EDU] On Behalf
Of Adams, Anne (DTI)
Sent: Thursday, February 28, 2013 15:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Changes in paging activity? Okay, THAT did change when this occurred. We page
like hell bent for leather. Our page data sets fill up like crazy and NEVER
Kees Vernooij wrote:
Again: the fact that DFsort acts differently on the new device could be caused
by CFW. With CFW dfsort could decide to use SORTWKs, without CFW DFSORT could
decide that this is too slow and use memory.
Very true! Will the DFSORT gurus answer on your statement this or next
] On Behalf
Of Elardus Engelbrecht
Sent: Thursday, February 28, 2013 10:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Kees Vernooij wrote:
Again: the fact that DFsort acts differently on the new device could be caused
by CFW. With CFW dfsort could decide to use SORTWKs, without CFW
Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: Thursday, February 28, 2013 16:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Kees Vernooij wrote:
Again: the fact that DFsort acts differently on the new device could be caused
by CFW. With CFW
) anne.ad...@state.de.us
To: IBM-MAIN@listserv.ua.edu,
Date: 02/28/2013 10:56 AM
Subject: Re: DFSORT Weirdness
Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
Thanks, I felt so alone. Like we were the only ones having this problem.
Checking into the Cache Fast Write on both the old
) 298 - 3196
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, CP - SPLXM
Sent: Thursday, February 28, 2013 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
I have seen DB2 utilities with large sorts (reorgs
: DFSORT Weirdness
Anne,
I've been discussing this with the DFSORT L2 rep that's working on
your problem. I don't believe CFW is related to this. I think I have an
idea of what's going on, but I'd rather work the problem through our
support process and then once we are sure of the cause
Of Roberto Halais
Sent: Thursday, February 28, 2013 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
We had a similar situation and ended coding the sort parms:
EXPOLD=0
EXPMAX=50%
On Thu, Feb 28, 2013 at 12:33 PM, Adams, Anne (DTI)
anne.ad...@state.de.uswrote:
Thanks Dave
Yeah, we've been told to do the same thing, but I need to know why
this suddenly happened. All we did was move our page data sets to the
DS8800.
Did the move preserve the number of page data sets, and the size of
the page data sets? Was the total amount of page data set space the
same
just aren't going fast enough.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Mulder
Sent: Thursday, February 28, 2013 11:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Yeah, we've been told to do the same thing
@LISTSERV.UA.EDU] On Behalf
Of Jerry Whitteridge
Sent: Thursday, February 28, 2013 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Anne -
Jim brings up a good point. Are all of your Page Datasets the same size on the
new box ?
If you have page Datasets allocated of different sizes then you
-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Thursday, February 28, 2013 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Yeah, we've been told to do the same thing, but I need to know why
this suddenly happened. All we did was move our page data sets to the
DS8800
(DTI)
Sent: Thursday, February 28, 2013 2:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
No, at least one of the page data sets was larger during the initial
migration.
Also, as the page datasets fill up they'll add additional ones of varying
sizes.
Anne R. Adams
DTI
I don't remember if PAGEDEL on smallest will allow reallocation. Might take
IPL.
In a message dated 2/28/2013 5:05:28 P.M. Central Standard Time,
gib...@wsu.edu writes:
The smallest will generally drive the allocation of all
IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
No, at least one of the page data sets was larger during the initial migration.
Also, as the page datasets fill up they'll add additional ones of varying sizes.
Anne R. Adams
DTI, Systems Engineering
State of Delaware
-Original Message
All page D/S should be the same size (along with any to add later).
The ASM uses the smallest times the number attempting to (in
general) fill to a max of 65% (iirc).
That's just crazy talk. While there might be some load balancing
related motivations for using similar sized page data
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFSORT Weirdness
Ok - this is EXACTLY what we're seeing now. The one issue is that when the page
data sets fill up, they never get emptied and we end up having to add new ones.
What do people do? We can't IPL every week or go on adding page datasets
57 matches
Mail list logo
