Bill is correct. The series 37 in my basement has run into this problem in
the past - you don't have enough free space to VINIT CONDENSE or SYSDUMP.
You can STORE (or at least I could), and before doing anything else, please
store @[log in to unmask]@ to be on the safe side. Also, read all of the following before
you begin.
I'm sure you have probably already done so, but just to jog your memory,
SWITCHLOG and then PURGE all but the current log file (PURGE [log in to unmask]
on 3P or later). Next, purge your [log in to unmask] files. Next, find and
purge all the editor K####### files. Print or purge all the spoolfiles.
How much disc space do you have? If there is a significant improvement,
try another VINIT CONDENSE. If not, STORE the least important account to
tape, validate the tape, LISTF @[log in to unmask],2;*LP to your printer, print the
LISTF output, then purge the account (you may need the LISTF later).
Now VINIT CONDENSE. My personal experience is that if the system is very
low on disc space, a VINIT CONDENSE will make only a minor improvement the
first time through. So, when the first VINIT CONDENSE completes, do
another and then another. Three passes appears to be optimal (at least on
my system). Now, try (notice I said "try") to restore the account you
stored to tape. If you are lucky it will fit (I haven't always been that
lucky). If the account won't restore, you may have to restore individual
files to specific disc LDEVs to get them back on the system.
Okay, what was the LISTF ,2 for? Well, the last time I tried this, the
files happened to be restored in an order in which the largest files just
so happened to be restored AFTER the smaller files, and the extent sizes of
the larger files were larger than the largest contiguous area on any of the
drives, so they couldn't be restored. Net result? I purged the account
and then went through the LISTF listing to find the files with large extent
sizes. I created an "indirect" file listing those files and specified the
indirect file in the first restore. Bingo! The files restored. A second
restore of @[log in to unmask] with the KEEP option restored the remainder of the
account.
Good luck!
John
At 6/23/98 03:04 PM , Bill Lancaster wrote:
>Tony,
>
>VINIT (as well as any disk condense program) works best when there is
>enough disk space to use as temporary storage to be able to move things
>around (not well said, grammatically, but you get the point). You need to
>free up some space, VINIT CONDENSE, and move on. The problem is that you
>don't have enough free space of large enough pieces to do what you need to
do.
>
>Bill
>
>
>At 11:41 AM 6/23/98 -0700, John D. Alleyn-Day wrote:
>>One of my clients (who lurks on this list) has a major problem with their
>>backup on an old MPE/V machine. The backup fails with "OUT FO DISC SPACE".
>> The system disc is horribly fragmented with the largest chunk being around
>>1300 sectors. Since SL.PUB.SYS is a whole lot bigger than this, I'm
>>presuming this is the problem. Running VINIT CONDENSE three times hasn't
>>made a dent in the fragmentation. Anybody got any suggestions on how to
>>clean up the disc and recover from this - apart from doing a "store @[log in to unmask]@"
>>and a reload? The other possibility I have in mind is to change the backup
>>to a simple store, but this doesn't solve the long-term problem as it makes
>>reconfiguring impossible.
>>
>>
>>John D. Alleyn-Day
>>Alleyn-Day International
>>408-286-6421 408-286-6474 (Fax)
>>[log in to unmask] http://www.Alleyn-Day.com
>>"The man that never made a mistake never made anything"
>>
>>
>
--------------------------------------------------------------
John Korb email: [log in to unmask]
Innovative Software Solutions, Inc.
The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.
|
