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 the
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
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
Actually I was lamenting that the VSAM Extent Consolidation doesn't
work for non-system managed datasets, not that it didn't work on
non-VSAM datasets.
Ben Alford Enterprise Systems Programming
University of Tennessee
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
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 applications. One
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
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
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
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
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 most
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
VSAM Extent Consolidation is documented in the DFSMS Using Data Sets
manual and is listed as a change for z/OS V1.5. According to apar OA7989
this feature could cause a problem when a VSAM dataset from z/OS V1.5 or
up was shared with z/OS V1.4, which did not have the same support. The
apar
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
