Azog-Thoth@cup.portal.com (William Thomas Daugustine) (01/24/91)
Please pardon me for cross-posting like this, but it seemed approciate Anyways... I have some questions regard a _delete_ files space allocation. First, tho, a bit of what is happening: We use a file (those who use DRA Atlas software should be familiar with my examples), that logs users transactions, so in the event of data loss, we can rebuild our databases from this log file. At the end of each week, reports are run off the file, and its deleted, and a fresh file is created. We see files sizes grow from 0 blocks to over 100,000 by the end of the week. Before the file gets deleted, when I do a $ DIR/SIZE=ALL of this file, what I see is this: DRA_LOGGER.LFL;1 102543/103582 And after we do our weekly delete: DRA_LOGGER.LFL;1 0/103582 As you can see, the new file still has the max space allocated to it. This is not a good thing, considering the largish amount of space its getting allocated, it eats up room on the drive (which happens to be our system pack). Why does this happen? There is a real to life delete in the weekly procedure: $ DELETE DRA_LOGGER_FILE;* (dra_logger_file is just a logical that points to the above file.). Is there anyway I can deallocate this space. Of course, one might argue why deallocate the space, when as the file grows, itll be reallocated to it. But I dont mind if that happens. We still need that breathing room that it can give us (as an aside, to the above argument. VMS seems to need at least 750 blocks on the system drive for it to function? At one point, because of this allocation, we reached under 300 blocks free (this is an RA82), and the system pretty much stopped until room was made. Each process was in a SUSP state...) Thanx Billy D'Augustine Azog-Thoth@cup.portal.com