In <[EMAIL PROTECTED]>, on
05/11/2006
at 07:13 PM, Art Celestini <[EMAIL PROTECTED]> said:
>In a program that writes to disk using EXCP, the setup of IOBSEEK
>before each write, for example, is done based on the contents of the
>extent list.
True, but most programs either look explicitly at
On May 12, 2006, at 1:45 PM, Edward Jaffe wrote:
--
SNIP-
You haven't been paying attention, have you Eg?
What's being discussed here is not some sort of daily or hourly
mass reorg. Rather, the discussion centers arou
Ed Gould wrote:
On May 12, 2006, at 10:48 AM, Mark Thomen wrote:
Let me say it again: There is NO EXTENT CONSOLIDATION for non-VSAM data
sets. Therefore, there is no reason to worry about them. It is very
unlikely we will implement that feature for non-VSAM.
Mark,
IIRC FDR does it extreme
On May 12, 2006, at 10:48 AM, Mark Thomen wrote:
"Art Celestini" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
Mark:
Ben Alford was lamenting the fact that Extent Consolidation only
worked
for VSAM. I was speculating that IBM might not have wanted to simply
enable it for
But, since you say it's unlikely you'll do it for non-VSAM,
it might not be a bad idea for an ISV product ...
Since you asked, COMPAKTOR (FDRCPK ala FASTCPK) has been combining
extents for 20 years for non-VSAM and a little less for VSAM.
To the best of my knowledge, DFSMSdss DEFRAG may make
Yes Mark, the whole discussion was based on a lot of wishful
thinking on our part.
But, since you say it's unlikely you'll do it for non-VSAM,
it might not be a bad idea for an ISV product ... ;-)
At 11:48 AM 5/12/2006, Mark Thomen wrote:
>[...snip...]
>
>Let me say it again: There is NO EXT
"Art Celestini" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Mark:
>
> Ben Alford was lamenting the fact that Extent Consolidation only worked
> for VSAM. I was speculating that IBM might not have wanted to simply
> enable it for non-VSAM because it might break some applicati
I just want to thank everyone for this discussion, especially Mark Thomen.
I have noticed some strange allocations with DB2 datasets, and now
understand what is happening.
It is a little unnerving to look at an IDCAMS LISTCAT and see mutliple
extents, with each one a different size. Especially w
I suppose letting the new space be described by a new entry in the extent
list would resolve the situation I described, but might not other issues
surface when the number of entries exceeds 15 (a different condition that
could cause the program to choke)? Probably less likely to really create
a
On Thu, 11 May 2006 19:13:58 -0400 Art Celestini <[EMAIL PROTECTED]>
wrote:
:>My "suggestion" as to how to safely implement Extent Consolidation for
:>non-VSAM data sets opened for EXCP, would be to include a mechanism
:>where the program could indicate to the system that it is prepared to
:>re
Mark:
Ben Alford was lamenting the fact that Extent Consolidation only worked
for VSAM. I was speculating that IBM might not have wanted to simply
enable it for non-VSAM because it might break some applications. One
scenario that crossed my mind is as follows:
In a program that writes to d
"Binyamin Dissen" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Wed, 10 May 2006 19:06:47 -0400 Art Celestini <[EMAIL PROTECTED]>
> wrote:
>
> :>I think it's actually non-VSAM, and it's because a lot of applications
> :>using EXCP or lower would break.
>
> :>Such programs no
On Wed, 10 May 2006 19:06:47 -0400 Art Celestini <[EMAIL PROTECTED]>
wrote:
:>I think it's actually non-VSAM, and it's because a lot of applications
:>using EXCP or lower would break.
:>Such programs normally issue an EOV to cause allocation of a new extent
:>for an output data set. I suspect
I think it's actually non-VSAM, and it's because a lot of applications
using EXCP or lower would break.
Such programs normally issue an EOV to cause allocation of a new extent
for an output data set. I suspect most apps would then expect to find
a new extent in the extent list (not more space
14 matches
Mail list logo
