Contiguous space in a disk on VMS

[Sk Noorul Hassan]

Hi all,

What are the ways to know the available contiguous space in a disk on VMS ?

[John Abbott_2]

There are lots of possible reponses to this, but I guess an easy reply is to consider using a good tool from the VMS freeware collection, like this:

http://h71000.www7.hp.com/freeware/freeware70/dfu/

[Marc Van den Broeck]

Hi,

Use DEFRAG SHOW disc_name/VOL

Rgds
Marc

[John Abbott_2]

For the freeware DFU too use

$ MCR DFU
DFU> report device
.
.
output here that gives lots of juicy info, look under the Free space stats for what you're after.
.
DFU> ^Z

[Wim Van den Wyngaert]

Without tools : make an fdl that created a file of size x with option contiguous.
If create/fdl fails then the space isn't available. Don't forget to delete the file afterwards.

Wim

[Hein van den Heuvel]

DFU is the preferred tool. Eveery system manager should know to use it.


Anyway, even with the tools, when running in a cluster you may want to instruct the system to allocate a large contiguous chunk before reporting. Why? Well each cluster node can (will) have a freeblock cache on the volume which may fragment the freespace for 'others'.
My favourite command for this: $COP/CONT/ALL=999999999 NL: tmp.tmp


Please help us understand why you think you need to know the largests contiguous chunk. Very few software cares about this anymore. Directories need to be contiguous. And I believe there is one database out there, not oracle, that requires it.

hth,
Hein.

[Sk Noorul Hassan]

I have no DFU loaded in the system. so, I have to go as suggested by WIM, or is there any other way ?

[Wim Van den Wyngaert]

The solution of Hein does the same.

You could write a procedure :

$ set noon
$cnt=1000000 ! or whatever
$b:
$ def/us sys$output nl:
$ def/us sys$error nl:
$ copy/cont/alloc='cnt' nl: xxx.lis
$ if $status
$ then
$ write sys$output "''cnt'"
$ del xxx.lis.*
$ else
$ cnt=cnt - 10000 ! or whatever
$ goto b
$ endif

[Hein van den Heuvel]

I suppose you could 'binary search' for the moment where a large contiguous file create starts to work. Not too hard, notably not with my $COPY techinque as you do not need a temp FDL file for that. Start with 2,000,000 blocks (less than 1TB), divide your way down and back up again.

And you could read [000000]bitmap.sys and count bits.

But WHY do you need to know? If it is for a file create, then just try that size.

If it is for a report, then for starters it is a pretty lame/ useless number and it may be good enough to report "Largest contig free space over 500MB", or over 100MB or whatever.

If it is for a serious report, then just knowing the largest chunk is probably not good enough anyway.

You could see whether the more official tool DFO provided teh data needed. It's reporting functions are free.

But anyway, you HAVE to get DFU on the box.

No self respecting OpenVMS syystem manager can live without. It's free, it's good, it's been around, it's highly available, and it has been written/maintained by a Dutch guy... it doesn't get any better!

Cheers,
Hein.

[Wim Van den Wyngaert]

But DFU is not standard. I want to challenge a newbe in this company to get a version downloaded from the internet on the VMS node. Security doesn't allow it.

IMHO : HP should have made the info available thru lexicals long time ago.


Wim