Problems detected with analyze/disk
anwa
After running anal/disk I have encountered some problems. I am running
VMS V8.3 on Itanium with ODS5 disks.
The faulty files are reported with only the "name+typ" parts of the
file spec. There are several names with the same name and version
number belonging to different users. There are also som corrupt(?)
file names.
- How do I find the correct file based on this information?
- Can I use the file-id (xxxx,yy,z) to access the files and copy/
delete them?
All hints greatly appreciated.
Anders Wallin
=========== partial extract from anal/disk ===========================
%ANALDISK-W-MULTALLOC, file (288980,11,0) TCPIP$REXEC_RUN.LOG;185
multiply allocated blocks
VBN 1 to 16
LBN 36358752 to 36358767, RVN 1
%ANALDISK-W-MULTALLOC, file (708146,53,0) °ç 0ê Pê
multiply allocated blocks
VBN 99681 to 99696
LBN 36358752 to 36358767, RVN 1
%ANALDISK-W-MULTALLOC, file (708146,53,0) °ç 0ê Pê
multiply allocated blocks
VBN 99697 to 99712
LBN 36358768 to 36358783, RVN 1
%ANALDISK-W-MULTALLOC, file (83148,96,0) INDATA.BCK;2
multiply allocated blocks
VBN 13953 to 13968
LBN 36358768 to 36358783, RVN 1
%ANALDISK-W-MULTALLOC, file (708146,53,0) °ç 0ê Pê
multiply allocated blocks
VBN 99713 to 99728
LBN 36358784 to 36358799, RVN 1
%ANALDISK-W-MULTALLOC, file (156375,23,0) MP_OHW.OPT;2
multiply allocated blocks
VBN 1 to 16
LBN 36358784 to 36358799, RVN 1
VAXman-
>Hi,
>
>After running anal/disk I have encountered some problems. I am running
>VMS V8.3 on Itanium with ODS5 disks.
>The faulty files are reported with only the "name+typ" parts of the
>file spec. There are several names with the same name and version
>number belonging to different users. There are also som corrupt(?)
>file names.
>
>- How do I find the correct file based on this information?
>- Can I use the file-id (xxxx,yy,z) to access the files and copy/
>delete them?
>
>All hints greatly appreciated.
>
>Anders Wallin
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>%ANALDISK-W-MULTALLOC, file (288980,11,0) TCPIP$REXEC_RUN.LOG;185
> multiply allocated blocks
> VBN 1 to 16
> LBN 36358752 to 36358767, RVN 1
> multiply allocated blocks
> VBN 99681 to 99696
> LBN 36358752 to 36358767, RVN 1
> multiply allocated blocks
> VBN 99697 to 99712
> LBN 36358768 to 36358783, RVN 1
>%ANALDISK-W-MULTALLOC, file (83148,96,0) INDATA.BCK;2
> multiply allocated blocks
> VBN 13953 to 13968
> LBN 36358768 to 36358783, RVN 1
> multiply allocated blocks
> VBN 99713 to 99728
> LBN 36358784 to 36358799, RVN 1
>%ANALDISK-W-MULTALLOC, file (156375,23,0) MP_OHW.OPT;2
> multiply allocated blocks
> VBN 1 to 16
> LBN 36358784 to 36358799, RVN 1
Are you running any third party software which accessed these disks?
$ SHOW LICENCE if you're not certain.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
http://www.quirkfactory.com/popart/asskey/eqn2.png
"Well my son, life is like a beanstalk, isn't it?"
CY
will not give anything?, on a san? did they do (assuming you are not
san master) anything? any analyze on the file just to get the really
good VMS hackers (and no I´m not one of them) started dir/full is
sorta ... no...
a m$ approach, all eco pacs in, latest version everywhere and so on.
Just my 2 cents...
//CY
anwa
We use the usual C/C++/MMS/LSE/RDB development software from HP/
Oracle.
Aditionally GNU-AWK, Make and some jsvn (Java based Subversion
client). Disks
are SAN disks.
My primary strategy is to get the disks repaired, and then keep a
close look
to make sure they behave as they should.
The problem in this case seems to get rid of files with "unprintable"
characters
in their names, with just access to the file-id. With a full file spec
I could have
used the recommended procedure to copy all multiple allocated files
and delete
all but one, then repair the disk. Just don't know how to do it fith
only file-id's.
Thanks for all input
Anders Wallin
VAXman-
>Hmm, TCPIP$REXEC_RUN.LOG should not be affected by 3:d party.. sho err
Wanna bet?
This is a classic footprint of at least one 3rd party application.
>will not give anything?, on a san? did they do (assuming you are not
>san master) anything? any analyze on the file just to get the really
>good VMS hackers (and no I=B4m not one of them) started dir/full is
>sorta ... no...
>
>a m$ approach, all eco pacs in, latest version everywhere and so on.
>
>Just my 2 cents...
Spend it wisely.
Peter Weaver
> characters
> in their names, with just access to the file-id. With a full file spec
> I could have
> used the recommended procedure to copy all multiple allocated files
> and delete
> all but one, then repair the disk. Just don't know how to do it fith
> only file-id's.
Since you have V8.3 and ODS5 you can do the following;
$ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[708146,53,0]
$ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[156375,23,0]
If the files are not on SYS$SYSDEVICE then substitute your disk name, the
"~" character is needed and you do not need any "*" characters in the
command. The confirm message will show you the device, directory, filename
followed by the FID in square brackets then the extension and version
number.
Peter Weaver
www.weaverconsulting.ca
Winner of the OpenVMS.org Readers' Choice Award for System
Management/Performance
http://www.linkedin.com/in/peterweaver
JF Mezei
> %ANALDISK-W-MULTALLOC, file (288980,11,0) TCPIP$REXEC_RUN.LOG;185
> multiply allocated blocks
> VBN 1 to 16
> LBN 36358752 to 36358767, RVN 1
> %ANALDISK-W-MULTALLOC, file (708146,53,0) �� 0� P�
> multiply allocated blocks
> VBN 99681 to 99696
> LBN 36358752 to 36358767, RVN 1
Second one is pretty strange since the file name is not valid.
DUMP /ID=(708146,53,0) sys$login:login.com will give you the file name
of the file, assuming your current directory is the same as that of the
device that holds that file ( it appears you still have to provide some
valid file name in the DUMP command as part of the CLI definition).
There is a utility called "DIX" which runs in X windows which allows you
to peruse the INDEXF.SYS file. You might be able to modify the records
of the offending files to mark them as deleted.
Say a phantom file has 100 allocated, 10 of which also belong to another
file. After doing it, an ANA/DISK/REPAIR would spot 90 deleted blocks
that can be freed and leave the other 10 belonging to the original file.
Normally, such errors should not happen. But we've all experienced a few
of those. But the ones you have seem odd in that the file names are
totally out of whack. Could be some software that is very low level and
which corrupts your indexf.
If you have that many, you might wish to backup/image and restore it.
Backup would recreate those phantom files in the new disk, but each
would have its own copy of the data, no shared blocks.
VAXman-
>> The problem in this case seems to get rid of files with "unprintable"
>> characters
>> in their names, with just access to the file-id. With a full file spec
>> I could have
>> used the recommended procedure to copy all multiple allocated files
>> and delete
>> all but one, then repair the disk. Just don't know how to do it fith
>> only file-id's.
>
>Since you have V8.3 and ODS5 you can do the following;
>
>$ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[708146,53,0]
>$ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[156375,23,0]
>
>If the files are not on SYS$SYSDEVICE then substitute your disk name, the
>"~" character is needed and you do not need any "*" characters in the
>command. The confirm message will show you the device, directory, filename
>followed by the FID in square brackets then the extension and version
>number.
I'd be leary of deleting files on a device/volume with reports of multiply
allocated blocks. You may not like the results.
I'd be looking for a _cause_ of these mulitply allocated blocks before I'd
begin zapping away files reported with them.
I've asked about 3rd party software but the original poster hasn't replied
with any further details.
VAXman-
Yup. I know one such product all too well.
>If you have that many, you might wish to backup/image and restore it.
>Backup would recreate those phantom files in the new disk, but each
>would have its own copy of the data, no shared blocks.
Sage advice. This condition is liable to only get worse. The sooner that
volume is backed up, the better the chances are of saving some of the data
on it.
Richard B. Gilbert
> In article <mailman.31.1258928922....@rbnsn.com>, "Peter Weaver" <info...@weaverconsulting.ca> writes:
>>> The problem in this case seems to get rid of files with "unprintable"
>>> characters
>>> in their names, with just access to the file-id. With a full file spec
>>> I could have
>>> used the recommended procedure to copy all multiple allocated files
>>> and delete
>>> all but one, then repair the disk. Just don't know how to do it fith
>>> only file-id's.
>> Since you have V8.3 and ODS5 you can do the following;
>>
>> $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[708146,53,0]
>> $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[156375,23,0]
>>
>> If the files are not on SYS$SYSDEVICE then substitute your disk name, the
>> "~" character is needed and you do not need any "*" characters in the
>> command. The confirm message will show you the device, directory, filename
>> followed by the FID in square brackets then the extension and version
>> number.
>
> I'd be leary of deleting files on a device/volume with reports of multiply
> allocated blocks. You may not like the results.
>
> I'd be looking for a _cause_ of these mulitply allocated blocks before I'd
> begin zapping away files reported with them.
>
> I've asked about 3rd party software but the original poster hasn't replied
> with any further details.
>
>
I'd be inclined to suspect that some application or DCL script is
playing fast and loose with the rules. This sort of thing is quite rare
on most systems. If I WANTED to multiply allocate blocks I'd really
have to work at it.
Michael Moroney
>I'd be inclined to suspect that some application or DCL script is
>playing fast and loose with the rules. This sort of thing is quite rare
>on most systems. If I WANTED to multiply allocate blocks I'd really
>have to work at it.
The quickest way to scrozzle a disk like that is a SCSI cluster
configuration with two hosts and the drive on a SCSI bus, with both hosts
mounting the disk without belonging to the same (or any) cluster, such as
VAXCLUSTER=0 or mis-set EXPECTED_VOTES and no cluster communication
between them.
Richard B. Gilbert
One COULD do it that way. To do it in ignorance of the consequences
would be pretty damned ignorant! What can I say about doing it on
purpose with full awareness of the probable consequences.
Richard B. Gilbert
I suspect that MOST of us would not even consider doing such a thing!
JF Mezei
> The quickest way to scrozzle a disk like that is a SCSI cluster
> configuration with two hosts and the drive on a SCSI bus, with both hosts
> mounting the disk without belonging to the same (or any) cluster,
One would need to find out if the user has found evidence of actual data
corruption. It is possible that the blocks that are multiply allocated
are only beyond end of file markers and would only start to matter/break
things if the user starts to add data to the both files, at which point
it would strt to overwrite data that is active in the other file.
Considering that the user seems to have a lot of instances of multiply
allocated blocks, one would need to find out which applications have
created files that conflict with bona fide files. or perhaps someone
played with Indexf.sys and undeleted many files whose allocations have
already been given to other files.
The user should really look at who the creators of those files is, who
they belong to, which directory they sit in and try to figure out if
there is something that systematically breaks the file system. Having a
couple of instances of multiply allocated blocks is one thing, but
having so many that you can't post the whole list here is another.
bart...@gmail.com
I have been in a situation where our SAN storage management team saw
it fit to allocate one ldev to both our VMS cluster AND some u*x
system. Luckily it was our test cluster, but very strange things
happened!
In other words, let the SAN people double check their configuration!
HTH,
Bart
anwa
As to 3:d party software:
We use the usual C/C++/MMS/LSE/RDB development software from HP/
Oracle.
Aditionally we use GAWK, Make, Emacs, Doxygen, jsvn (Java based
Subversionclient). There is also PERFDAT that looks at the disks.
Disks are SAN disks.
_ AW -
anwa
The files marked with MULTALLOC contained corrupted data.
There was an average of 5-20 corruptions on each disk.
Out of 15 disks on two clusters half had corruptions. Most are now
fixed but the ones with "unprintable" filenames remain. We will
probably be doing image backups to new disks to get rid of some of the
problems.
- AW -
JF Mezei
> We are currently double checking the SAN configuration.
> The files marked with MULTALLOC contained corrupted data.
> There was an average of 5-20 corruptions on each disk.
How often did you do ana/disk ? Is it possible that those accumulated
over the years undetected, or would they have happened all recently ?
Is it possible that they happened a long time ago and whatever
software/conditions caused that is no longer on your system ?
> Out of 15 disks on two clusters half had corruptions. Most are now
> fixed but the ones with "unprintable" filenames remain.
When you boot, do you have a /NOREBUILD paramater to the MOUNT command
in your boot up sequence ? Some site have this to allow system to return
to service faster, but if you don't do a SET VOLUME/REBUILD later on you
are liable to get some funky stuff. (no sure if this would result in
multiply allocated blocks though).
You should really track down any trend/common denominator for the
affected files. Creation dates, file onwers, and look inside contents to
spot if you see one application's data come out often. In other do some
forensics to find out what application was involved.
Doing a backup may eliminate existing events, but it may not prevent the
problem from reoccuring.
Did ANA/DISK uncover any other problems with the disk ?
Is it possible someone corrupted the bitmap.sys file, telling the system
that some blocks were free when they were not ? (for instance, restore
the file from an older backup).
Paul Sture
<26bea903-0ccc-4d5d...@h2g2000vbd.googlegroups.com>,
anwa <anders_...@yahoo.se> wrote:
> As to 3:d party software:
> We use the usual C/C++/MMS/LSE/RDB development software from HP/
> Oracle.
> Aditionally we use GAWK, Make, Emacs, Doxygen, jsvn (Java based
> Subversionclient). There is also PERFDAT that looks at the disks.
> Disks are SAN disks.
Is PERFDAT this product?
http://h71000.www7.hp.com/openvms/journal/v8/perfdat.pdf
--
Paul Sture
Paul Sture
"Peter Weaver" <info...@weaverconsulting.ca> wrote:
> > The problem in this case seems to get rid of files with "unprintable"
> > characters
> > in their names, with just access to the file-id. With a full file spec
> > I could have
> > used the recommended procedure to copy all multiple allocated files
> > and delete
> > all but one, then repair the disk. Just don't know how to do it fith
> > only file-id's.
>
> Since you have V8.3 and ODS5 you can do the following;
>
> $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[708146,53,0]
> $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[156375,23,0]
>
> If the files are not on SYS$SYSDEVICE then substitute your disk name, the
> "~" character is needed and you do not need any "*" characters in the
> command. The confirm message will show you the device, directory, filename
> followed by the FID in square brackets then the extension and version
> number.
>
Rather than deleting these files, I'd recommend following the steps
outlined in:
$ HELP/MESSAGE MULTALLOC
--
Paul Sture
Paul Sture
VAXman- @SendSpamHere.ORG wrote:
He has answered since then and the one that leapt out at me was PERFDAT.
That got me thinking about PerfectDisk, but it looks more like HP
PERFDAT:
http://h71000.www7.hp.com/openvms/journal/v8/perfdat.pdf
It gets interesting at the bottom of Page 5...
--
Paul Sture
anwa
ANAL/DISK has not been run (to my knowledge) for a long time so I
could not really say how old the errors are. That is partly the reason
for trying to get the disks into shape and running anal/disk
regularly.
There were other faults as well. The _most_ corrupted disk had:
(DELHEADER, MULTALLOC, BAD_DIRFIDSEQ, BADDIREN, LOSTHEADER).
The most common errors were DELHEADER and BADOWNER.
The systems have been used for development all the time and the
software tools used have been more or less stable over a long time.
There have been version upgrades, but that is about it.
VAXman-
PerfectDisk is pretty sound. I was thinking about some software working
at layers below the file system that corrupt things with this footprint.
>http://h71000.www7.hp.com/openvms/journal/v8/perfdat.pdf
>
>It gets interesting at the bottom of Page 5...
I'd started perusing that document but the images of the cheesy WEENDOZE
graphics in it were making me nauseous.
Bob Koehler
>
> After running anal/disk I have encountered some problems. I am running
> VMS V8.3 on Itanium with ODS5 disks.
> The faulty files are reported with only the "name+typ" parts of the
> file spec. There are several names with the same name and version
> number belonging to different users. There are also som corrupt(?)
> file names.
>
> - How do I find the correct file based on this information?
> - Can I use the file-id (xxxx,yy,z) to access the files and copy/
> delete them?
>
dump/header/block=start:0/identifier=(xxxx,yy,z) device:/page
I believe this requires read access to the index file. You will get
the file owner uic and the backlink file ID, which is the FID of the
directory where the file is entered. If there are aliases in other
directories, the backlink will be for the primary entry. You also
get the primary file name, not names used by aliases.
Bob Gezelter
anwa,
I would recommend extreme caution here. With all due respect, the
problem can be far more subtle than is clear from the responses that
have been posted.
Just because a small number of files PRESENTLY show multiple
allocations does not not mean that they are the only files affected by
this over the time that the problem has been happening. If file that
is subject to this is revised, the new copy may be correctly
allocated, but contain corrupted data. There are also other cases that
can happen.
I would counsel an immediate BACKUP/PHYSICAL of the affected drives to
secure media, followed by a careful audit of all files on the disks.
Since this is described as a development environment, I would be
particularly careful to verify that all source files are intact, and
can be recompiled (object and binary files are less important, they
should be able to be recreated).
Repair of multiple allocations is possible, although having dealt with
this class of problem, I do recommend caution and careful research. It
is far easier to have an accident and cause more damage than it is to
get things right in haste. The audit should also carefully attempt to
identify what is happening and take corrective action.
- Bob Gezelter, http://www.rlgsc.com
Richard B. Gilbert
> On Nov 22, 6:16 am, anwa <anders_s_wal...@yahoo.se> wrote:
>> Hi,
>>
>> After running anal/disk I have encountered some problems. I am running
>> VMS V8.3 on Itanium with ODS5 disks.
>> The faulty files are reported with only the "name+typ" parts of the
>> file spec. There are several names with the same name and version
>> number belonging to different users. There are also som corrupt(?)
>> file names.
>>
>> - How do I find the correct file based on this information?
>> - Can I use the file-id (xxxx,yy,z) to access the files and copy/
>> delete them?
>>
>> All hints greatly appreciated.
>>
>> Anders Wallin
>>
>> =========== partial extract from anal/disk ===========================
>>
>> %ANALDISK-W-MULTALLOC, file (288980,11,0) TCPIP$REXEC_RUN.LOG;185
>> multiply allocated blocks
>> VBN 1 to 16
>> LBN 36358752 to 36358767, RVN 1
>> multiply allocated blocks
>> VBN 99681 to 99696
>> LBN 36358752 to 36358767, RVN 1
>> multiply allocated blocks
>> VBN 99697 to 99712
>> LBN 36358768 to 36358783, RVN 1
>> %ANALDISK-W-MULTALLOC, file (83148,96,0) INDATA.BCK;2
>> multiply allocated blocks
>> VBN 13953 to 13968
>> LBN 36358768 to 36358783, RVN 1
>> multiply allocated blocks
>> VBN 99713 to 99728
>> LBN 36358784 to 36358799, RVN 1
>> %ANALDISK-W-MULTALLOC, file (156375,23,0) MP_OHW.OPT;2
>> multiply allocated blocks
>> VBN 1 to 16
>> LBN 36358784 to 36358799, RVN 1
>
> anwa,
>
> I would recommend extreme caution here. With all due respect, the
> problem can be far more subtle than is clear from the responses that
> have been posted.
>
> Just because a small number of files PRESENTLY show multiple
> allocations does not not mean that they are the only files affected by
> this over the time that the problem has been happening. If file that
> is subject to this is revised, the new copy may be correctly
> allocated, but contain corrupted data. There are also other cases that
> can happen.
>
> I would counsel an immediate BACKUP/PHYSICAL of the affected drives to
> secure media, followed by a careful audit of all files on the disks.
With that BACKUP/PHYSICAL you can always restore the original sad state
of affairs! If your efforts at repair make matters worse, you can
always restore and try something else.
An ANALYZE DISK_STRUCTURE should follow the backup in order to get a
reading on just what is wrong, files affected, etc. Files that appear
intact can be copied to another disk.
It may be helpful to keep a careful log. Record everything you do and
the result of each action.
Most of your data is probably still present and can probably be salvaged
if doing so is worth the time and effort. Direct your attention to data
written since the last known good backup.
<snip>
Bob Gezelter
wrote:
> Bob Gezelter wrote:
> > On Nov 22, 6:16 am, anwa <anders_s_wal...@yahoo.se> wrote:
> >> Hi,
>
> >> After running anal/disk I have encountered some problems. I am running
> >> VMS V8.3 on Itanium with ODS5 disks.
> >> The faulty files are reported with only the "name+typ" parts of the
> >> file spec. There are several names with the same name and version
> >> number belonging to different users. There are also som corrupt(?)
> >> file names.
>
> >> - How do I find the correct file based on this information?
> >> - Can I use the file-id (xxxx,yy,z) to access the files and copy/
> >> delete them?
>
> >> All hints greatly appreciated.
>
> >> Anders Wallin
>
> >> =========== partial extract from anal/disk ===========================
>
> >> %ANALDISK-W-MULTALLOC, file (288980,11,0) TCPIP$REXEC_RUN.LOG;185
> >> multiply allocated blocks
> >> VBN 1 to 16
> >> LBN 36358752 to 36358767, RVN 1
> >> multiply allocated blocks
> >> VBN 99681 to 99696
> >> LBN 36358752 to 36358767, RVN 1
> >> multiply allocated blocks
> >> VBN 99697 to 99712
> >> LBN 36358768 to 36358783, RVN 1
> >> %ANALDISK-W-MULTALLOC, file (83148,96,0) INDATA.BCK;2
> >> multiply allocated blocks
> >> VBN 13953 to 13968
> >> LBN 36358768 to 36358783, RVN 1
Richard,
Actually, while it may be influenced by the forensic component of my
practice, I tend to preserve the original corrupted volume "on the
shelf" and work on a copy. Thus the original is undoubtedly preserved
for whatever reason may become necessary.
Peter Weaver
> > > characters
> > > in their names, with just access to the file-id. With a full file spec
> > > I could have
> > > used the recommended procedure to copy all multiple allocated files
> > > and delete
> > > all but one, then repair the disk. Just don't know how to do it fith
> > > only file-id's.
> >
> > Since you have V8.3 and ODS5 you can do the following;
> >
> > $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[708146,53,0]
> > $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[156375,23,0]
> >
> > If the files are not on SYS$SYSDEVICE then substitute your disk name,
the
> > "~" character is needed and you do not need any "*" characters in the
> > command. The confirm message will show you the device, directory,
filename
> > followed by the FID in square brackets then the extension and version
> > number.
> >
>
> Rather than deleting these files, I'd recommend following the steps
> outlined in:
>
> $ HELP/MESSAGE MULTALLOC
>
Isn't that what the OP said they were doing? I was only addressing the
question about working with files that have corrupted names. Many people do
not know how to work with files using only the FID. Any DCL commends that
work with files (DIRECTORY, COPY, DELETE, TYPE, RENAME, PRINT etc.) should
working using the FID syntax. If you know the directory the file is in then
you can prefix the FID with the directory and the command will work a lot
faster than going through the whole directory structure. I'm not sure if
using the FID as part of the filename is even documented, but if you have
filenames that are not valid then using the FID syntax is the best way to
work with them.
Paul Sture
mor...@world.std.spaamtrap.com (Michael Moroney) wrote:
The first release of XFC did it in a cluster too :-(
IIRC it took several attempts to fix.
--
Paul Sture
Paul Sture
"Peter Weaver" <info...@weaverconsulting.ca> wrote:
> > > > The problem in this case seems to get rid of files with "unprintable"
> > > > characters
> > > > in their names, with just access to the file-id. With a full file spec
> > > > I could have
> > > > used the recommended procedure to copy all multiple allocated files
> > > > and delete
> > > > all but one, then repair the disk. Just don't know how to do it fith
> > > > only file-id's.
> > >
> > > Since you have V8.3 and ODS5 you can do the following;
> > >
> > > $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[708146,53,0]
> > > $ DELETE/CONFIRM/LOG SYS$SYSDEVICE:[0000000...]~[156375,23,0]
> > >
> > > If the files are not on SYS$SYSDEVICE then substitute your disk name,
> the
> > > "~" character is needed and you do not need any "*" characters in the
> > > command. The confirm message will show you the device, directory,
> filename
> > > followed by the FID in square brackets then the extension and version
> > > number.
> > >
> >
> > Rather than deleting these files, I'd recommend following the steps
> > outlined in:
> >
> > $ HELP/MESSAGE MULTALLOC
> >
>
> Isn't that what the OP said they were doing?
Apologies. I missed that bit.
> I was only addressing the
> question about working with files that have corrupted names. Many people do
> not know how to work with files using only the FID. Any DCL commends that
> work with files (DIRECTORY, COPY, DELETE, TYPE, RENAME, PRINT etc.) should
> working using the FID syntax. If you know the directory the file is in then
> you can prefix the FID with the directory and the command will work a lot
> faster than going through the whole directory structure. I'm not sure if
> using the FID as part of the filename is even documented, but if you have
> filenames that are not valid then using the FID syntax is the best way to
> work with them.
>
I for one didn't know or had forgotten that syntax. Many thanks for
pointing it out.
--
Paul Sture