Post by Igorthe FUP INFO <file name>, EXTENTS command lists the extents and starting page as expected, but only on Enscribe files.
It's not working on OSS files. The output is even equal if used with DETAIL and EXTENTS option. Any idea why?
-info $DATA05.ZYQ00001.Z00008N1, extents
$DATA05.ZYQ00001.Z00008N1 27 Jun 2017, 16:06
OSS
PATH: /home/dev0/base24_eps_111_bu11o.tar
OWNER {intentionally hidden by me}
SECURITY: -rw-r--r--
CREATION DATE: 13 May 2015, 12:16
ACCESS TIME: 1 Jun 2017, 22:32
EOF: 866703872
-info $DATA05.ZYQ00001.Z00008N1, detail
$DATA05.ZYQ00001.Z00008N1 27 Jun 2017, 16:06
OSS
PATH: /home/dev0/base24_eps_111_bu11o.tar
OWNER {intentionally hidden by me}
SECURITY: -rw-r--r--
CREATION DATE: 13 May 2015, 12:16
ACCESS TIME: 1 Jun 2017, 22:32
EOF: 866703872
I have only speculation about this. I do not know how space allocation for OSS files is done.
As I understand it, disk space allocation on typical Unix systems is done a bit different than the way it is is done for Guardian files. I do not remember the details, but it involves something like progressively larger blocks of space being allocated to a file automatically as it grows. I suppose that when OSS was implemented, something about the way space is allocated to OSS files was done differently enough that the usual way FUP obtained or displayed the extent information did not work, and it was not considered important enough to write the additional code that would have been needed to display the disk space allocation information for OSS files.
Back to your original question. Yes, the way you asked the question originally was not very clear. In theory, there could be a performance advantage in some circumstances if a file's extents were contiguous on disk. That usually is overwhelmed by other factors that affect performance a lot more, so people usually do not make much effort to keep the extents of a file together on disk.
The main issue that led to creation of DCOM is that, as I imagine you understand, when the free space is fragmented, it might be impossible to create a given file because, even though there is plenty of free space available, there are no fragments large enough to contain the primary extent requested for the file. The same thing can prevent a file from growing into a new extent. DCOM moves around the extents of files on the disk, trying to end up with fewer but larger fragments of free space on the disk. It can only move extents of files that are not open (and I have a feeling there is some other restriction that I am not thinking of at the moment), so it cannot always make much progress on consolidating the free space on a disk.
The error you mention you got when running DCOM seems to indicate that DCOM detected a problem with the data on the disk, either a disk I/O error or some invalid data in the disk directory or a file label. I don't know whether you have looked into that further, but it seems to me to be something you should check, since it might mean some of the data on that disk is in danger of being lost or corrupted.
Before DCOM was created, the way to clear up fragmentation on a disk was to do a full backup of the disk to tape, relabel the disk, which makes it completely empty, then restore the full backup that you just made. That ensured that all the free space on the disk was in one large fragment, but is a slow and error-prone procedure. I do not recommend trying that today for most situations. Something that you could do if the disk is in a state that DCOM cannot work on it would be to choose a couple fairly large files, DUP them to another disk (or back them up to tape), purge those files, shut down as many of the programs using the disk as possible, then try to run DCOM. Then you can DUP the files you moved back to the disk, if you want to keep them on that disk. But before you do something like this, check into the reason that DCOM reported that error you mentioned and correct it before trying to reorganize the free space on that disk.