<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: How to repair a corrupted BADBLK.SYS file in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202020#M105874</link>
    <description>&lt;P&gt;&amp;gt; [...] a corrupted [000000]BADBLK.SYS file. [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; I'll bite.&amp;nbsp; How, exactly, did you reach that conclusion?&amp;nbsp; As usual,&lt;BR /&gt;showing actual actions (commands) with their actual results (error&lt;BR /&gt;messages, ...) can be more helpful than vague descriptions or&lt;BR /&gt;interpretations.&amp;nbsp; Copy+paste is your friend.&lt;/P&gt;&lt;P&gt;&amp;gt; [...] BACKUP was unable to restore the file, [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; "unable" is not a useful problem description.&amp;nbsp; It does not say what&lt;BR /&gt;you did.&amp;nbsp; It does not say what happened when you did it.&amp;nbsp; See "As usual&lt;BR /&gt;[...]", above.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; My understanding of VMS file systems is, at best, vague, but I'd&lt;BR /&gt;expect a file like BADBLK.SYS to be handled exclusively by the file&lt;BR /&gt;system or other system software, and not to be susceptible to&lt;BR /&gt;manipulation by a user.&lt;/P&gt;&lt;P&gt;&amp;gt; [...] I don't want to restore the entire disk from the image&lt;BR /&gt;&amp;gt; save-set, [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; I would not be amazed if that were required.&lt;/P&gt;&lt;P&gt;&amp;gt; [...] since BADBLK.SYS is the only file that I found that was&lt;BR /&gt;&amp;gt; corrupted.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; "found" _how_, exactly?&lt;/P&gt;&lt;P&gt;&amp;gt; [...] ANALYZE/MEDIA [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; Might be worth a try, but I wouldn't expect much.&amp;nbsp; I thought that the&lt;BR /&gt;whole bad-bkock scheme applied only to obsolete hardware.&amp;nbsp; And that the&lt;BR /&gt;Bad Block Locator Utility (BAD) was data-destructive.&lt;/P&gt;</description>
    <pubDate>Sat, 02 Dec 2023 15:38:31 GMT</pubDate>
    <dc:creator>Steven Schweda</dc:creator>
    <dc:date>2023-12-02T15:38:31Z</dc:date>
    <item>
      <title>How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202005#M105873</link>
      <description>&lt;P&gt;I have a (Charon-VAX) emulated VAX 4000-90 system, with a system disk that has a corrupted [000000]BADBLK.SYS file. The system is running VAX/VMS V5.5-2H4.&lt;/P&gt;&lt;P&gt;I tried to restore it from an image backup save-set that was taken the day before the file was corrupted, but BACKUP was unable to restore the file, even though the file is clearly listed in the backup saveset listing, and the file was NOT marked NOBACKUP. In fact, my restore command (BACKUP/LOG &amp;lt;save-set&amp;gt;/SAVE/SELECT=[000000]*.SYS SYS$LOGIN:*.*) is ignoring all the *.SYS files directly under [000000] -- none of the other .SYS files can be copied from the save-set either. I can restore other files listed in the save-set, but not those. So now I'm trying to find another way to restore or repair this one file.&lt;/P&gt;&lt;P&gt;ANALYZE/DISK/REPAIR didn't even list BADBLK.SYS, so I'm wondering if I should use ANALYZE/MEDIA to re-create a brand new version of BADBLK.SYS. Or I should use any other method. I don't want to restore the entire disk from the image save-set, since BADBLK.SYS is the only file that I found that was corrupted..&lt;/P&gt;&lt;P&gt;Please advise.&lt;/P&gt;&lt;P&gt;Thanks in advance,&lt;/P&gt;&lt;P&gt;- Ron&lt;/P&gt;</description>
      <pubDate>Mon, 04 Dec 2023 04:21:27 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202005#M105873</guid>
      <dc:creator>rbeasley3</dc:creator>
      <dc:date>2023-12-04T04:21:27Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202020#M105874</link>
      <description>&lt;P&gt;&amp;gt; [...] a corrupted [000000]BADBLK.SYS file. [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; I'll bite.&amp;nbsp; How, exactly, did you reach that conclusion?&amp;nbsp; As usual,&lt;BR /&gt;showing actual actions (commands) with their actual results (error&lt;BR /&gt;messages, ...) can be more helpful than vague descriptions or&lt;BR /&gt;interpretations.&amp;nbsp; Copy+paste is your friend.&lt;/P&gt;&lt;P&gt;&amp;gt; [...] BACKUP was unable to restore the file, [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; "unable" is not a useful problem description.&amp;nbsp; It does not say what&lt;BR /&gt;you did.&amp;nbsp; It does not say what happened when you did it.&amp;nbsp; See "As usual&lt;BR /&gt;[...]", above.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; My understanding of VMS file systems is, at best, vague, but I'd&lt;BR /&gt;expect a file like BADBLK.SYS to be handled exclusively by the file&lt;BR /&gt;system or other system software, and not to be susceptible to&lt;BR /&gt;manipulation by a user.&lt;/P&gt;&lt;P&gt;&amp;gt; [...] I don't want to restore the entire disk from the image&lt;BR /&gt;&amp;gt; save-set, [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; I would not be amazed if that were required.&lt;/P&gt;&lt;P&gt;&amp;gt; [...] since BADBLK.SYS is the only file that I found that was&lt;BR /&gt;&amp;gt; corrupted.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; "found" _how_, exactly?&lt;/P&gt;&lt;P&gt;&amp;gt; [...] ANALYZE/MEDIA [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; Might be worth a try, but I wouldn't expect much.&amp;nbsp; I thought that the&lt;BR /&gt;whole bad-bkock scheme applied only to obsolete hardware.&amp;nbsp; And that the&lt;BR /&gt;Bad Block Locator Utility (BAD) was data-destructive.&lt;/P&gt;</description>
      <pubDate>Sat, 02 Dec 2023 15:38:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202020#M105874</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2023-12-02T15:38:31Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202021#M105875</link>
      <description>&lt;P&gt;Hello, Steve:&lt;/P&gt;&lt;P&gt;To answer your questions:&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I'll bite.&amp;nbsp; How, exactly, did you reach that conclusion?&amp;nbsp; As usual,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;showing actual actions (commands) with their actual results (error&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;messages, ...) can be more helpful than vague descriptions or&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;interpretations.&amp;nbsp; Copy+paste is your friend.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Answer: I used the ANALYZE/RMS command, as follows:&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;TXPRPI$ **bleep**/rms _TXPRPI$DKA0:[000000]BADBLK.SYS;1&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Check RMS File Integrity 2-DEC-2023 09:45:41.90 Page 1&lt;BR /&gt;_TXPRPI$DKA0:[000000]BADBLK.SYS;1FILE HEADER&lt;/P&gt;&lt;P&gt;File Spec: _TXPRPI$DKA0:[000000]BADBLK.SYS;1&lt;BR /&gt;File ID: (3,3,0)&lt;BR /&gt;Owner UIC: [1,1]&lt;BR /&gt;Protection: System: RWED, Owner: RWED, Group: RE, World:&lt;BR /&gt;Creation Date: 20-JUL-1993 10:22:54.21&lt;BR /&gt;Revision Date: 2-JUN-1998 08:42:24.32, Number: 7&lt;BR /&gt;Expiration Date: none specified&lt;BR /&gt;Backup Date: 24-NOV-2023 16:16:43.01&lt;BR /&gt;Contiguity Options: none&lt;BR /&gt;Performance Options: none&lt;BR /&gt;Reliability Options: none&lt;BR /&gt;Journaling Enabled: none&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;RMS FILE ATTRIBUTES&lt;/P&gt;&lt;P&gt;File Organization: sequential&lt;BR /&gt;Record Format: fixed&lt;BR /&gt;Record Attributes:&lt;BR /&gt;Maximum Record Size: 512&lt;BR /&gt;Longest Record: 512&lt;BR /&gt;Blocks Allocated: 17, Default Extend Size: 0&lt;BR /&gt;End-of-File VBN: 18, Offset: %X'0000'&lt;BR /&gt;File Monitoring: disabled&lt;BR /&gt;Global Buffer Count: 0&lt;BR /&gt;*** Attempt to read block with invalid VBN 13.&lt;BR /&gt;Unrecoverable error encountered in structure of file.The analysis uncovered 2 errors.&lt;/P&gt;&lt;P&gt;**bleep**/RMS _TXPRPI$DKA0:[000000]BADBLK.SYS;1&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;2.&amp;nbsp; &amp;gt; [...] BACKUP was unable to restore the file, [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; "unable" is not a useful problem description.&amp;nbsp; It does not say what&lt;BR /&gt;you did.&amp;nbsp; It does not say what happened when you did it.&amp;nbsp; See "As usual&lt;BR /&gt;[...]", above.&lt;/P&gt;&lt;P&gt;Answer: I issued the following commands in an attempt to copy BADBLK.SYS from the image save-set that was created the day before the corruption was discovered:&lt;/P&gt;&lt;P&gt;TXBCK1$ mount/for lma22:&lt;BR /&gt;%MOUNT-I-WRITELOCK, volume is write locked&lt;BR /&gt;%MOUNT-I-MOUNTED, VR0623 mounted on _$1$LMA22: (TXBCK1)&lt;BR /&gt;TXBCK1$ back/log LMA22:0234BA51113.FUL/save/sele=badblk.sys *.*&lt;BR /&gt;%BACKUP-W-NOFILES, no files selected from LMA22:[000000]0234BA51113.FUL;&lt;/P&gt;&lt;P&gt;Before I tried to pull a copy of BADBLK.SYS from that save-set, I issued a&lt;/P&gt;&lt;P&gt;"BACKUP/LIST=0234BA51113.LIS&amp;nbsp; &amp;nbsp;LMA22:0234BA51113.FUL/save" command to generate a listing of that save-set. I then issued a SEARCH command to verify that BADBLK.SYS was in the save-set:&lt;/P&gt;&lt;P&gt;TXBCK1$ sear 0234BA51113.lis badblk.sys&lt;BR /&gt;[000000]BADBLK.SYS;1 17 8-MAR-2007 08:00&lt;BR /&gt;TXBCK1$&amp;nbsp;&lt;/P&gt;&lt;P&gt;That's what I meant I stated that BACKUP was unable to restore the file. The file is clearly in the save-set, but the errror message from the "BACKUP/LOG" command suggests BACKUP was unable to find or select the file.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;3.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;gt; [...] since BADBLK.SYS is the only file that I found that was&lt;BR /&gt;&amp;gt; corrupted.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; "found" _how_, exactly?&lt;/P&gt;&lt;P&gt;ANSWER:&amp;nbsp; I ran a batch job that issues either a "ANALYZE/RMS" or an "ANALYZE/IMAGE" command on the latest version of each file (depending on if the file is an .EXE file or not) on the system disk&amp;nbsp; (excluding files that were previously discovered to have errors). BADBLK. SYS was the only file that had errors on the system disk.&amp;nbsp;&lt;/P&gt;&lt;P&gt;The ANALYZE/MEDIA command (by default) WILL detroy data on the disk -- unless you specify "/NOEXERCISE/BAD_BLOCKS"&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hope these explanations help.&lt;/P&gt;&lt;P&gt;- Ron&lt;/P&gt;</description>
      <pubDate>Sat, 02 Dec 2023 16:09:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202021#M105875</guid>
      <dc:creator>rbeasley3</dc:creator>
      <dc:date>2023-12-02T16:09:26Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202022#M105876</link>
      <description>&lt;P&gt;Steve,&lt;/P&gt;&lt;P&gt;After I submitted my response to you, I noticed some "&lt;SPAN&gt;**bleep**s that were inserted in my response in place of the word "ANALYZE". &lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;I have no idea how those **bleep** got in there.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;- Ron.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Sat, 02 Dec 2023 16:14:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202022#M105876</guid>
      <dc:creator>rbeasley3</dc:creator>
      <dc:date>2023-12-02T16:14:49Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202023#M105877</link>
      <description>&lt;P&gt;Ron,&lt;/P&gt;&lt;P&gt;the '*bleep*s are an attempot of the forum software against 'bad language' &lt;LI-EMOJI id="lia_winking-face" title=":winking_face:"&gt;&lt;/LI-EMOJI&gt;&lt;/P&gt;&lt;P&gt;You might want to read up on BADBLK.SYS in&amp;nbsp;&lt;A href="https://forum.vmssoftware.com/viewtopic.php?t=5902" target="_blank"&gt;(6926) Disk Bad Block Processing? - VSI OpenVMS Forum (vmssoftware.com)&lt;/A&gt;&lt;/P&gt;&lt;P&gt;There could be 'bad blocks' included in that file. If you'll read them, you could encounter disk read errors. Do you want that to happen ?&lt;/P&gt;&lt;P&gt;This file is one of the OpenVMS reserved file and best to be left alone. If it closely tied to the physical disk, on which it resides, so BACKUP and restore of that file would not make much sense.&lt;/P&gt;&lt;P&gt;Volker.&lt;/P&gt;</description>
      <pubDate>Sat, 02 Dec 2023 16:25:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202023#M105877</guid>
      <dc:creator>Volker Halle</dc:creator>
      <dc:date>2023-12-02T16:25:38Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202027#M105878</link>
      <description>&lt;P&gt;Hello, Volker.&amp;nbsp;&lt;/P&gt;&lt;P&gt;As far as the *bleep* are concerned, I think that must have happened because I abbreviated the "ANALYZE" command. It didn't occur to me that my abbreviation would be misinterpreted as "bad language". I assure you no "bad language" was intended in my posts.&lt;/P&gt;&lt;P&gt;The fact that BADBLK.SYS is a special file that gets created as part of the file system when disks are initialized is what I suspected as the reason why I couldnt' restore it. None of the other .SYS files under the MFD [000000] could be restored either for the same reason. So that answers that question.&lt;/P&gt;&lt;P&gt;Thanks for the link from VSI on BADBLK.SYS. I'll check it out.&lt;/P&gt;&lt;P&gt;It turns out this particular VAX is an emulated (Charon-VAX) system on a Windows host, so it doesn't have "real" (physical) RZ disks. So the whole concept of bad blocks may not apply in the same way as it would for a physical VAX. I'm going to check the Stromasys manuals to find out how BADBLK.SYS should be managed in an emulator environment (or even if it matters).&lt;/P&gt;&lt;P&gt;Thanks, again Volker for your help -- as always!!&lt;/P&gt;&lt;P&gt;- Ron Beasley&lt;/P&gt;</description>
      <pubDate>Sat, 02 Dec 2023 17:13:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202027#M105878</guid>
      <dc:creator>rbeasley3</dc:creator>
      <dc:date>2023-12-02T17:13:50Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202029#M105879</link>
      <description>&lt;P&gt;Ron,&lt;/P&gt;&lt;P&gt;as your BADBLK.SYS file contains &amp;gt; 0 blocks, you could try a&lt;/P&gt;&lt;P&gt;$ DUMP/HEAD/BLOCK=COUNT=0&amp;nbsp;&lt;SPAN&gt;_TXPRPI$DKA0:[000000]BADBLK.SYS&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;this will tell you the LBNs of those 'bad' blocks.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Creation Date: 20-JUL-1993 10:22:54.21&lt;BR /&gt;Revision Date: 2-JUN-1998 08:42:24.32, Number: 7&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;AFAIK, there was no CHARON-VAX back in 1993 or even 1998 (the first CHARON-VAX was sold in 2000) ! Maybe this file got copied during the physical disk migration to CHARON-VAX ?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Volker.&lt;/P&gt;</description>
      <pubDate>Sat, 02 Dec 2023 18:45:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202029#M105879</guid>
      <dc:creator>Volker Halle</dc:creator>
      <dc:date>2023-12-02T18:45:23Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202068#M105880</link>
      <description>&lt;P&gt;&amp;gt; It turns out this particular VAX is an emulated (Charon-VAX) system on&lt;BR /&gt;&amp;gt; a Windows host, [...]&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; I have a SIMH VAX on a Mac, running V7.3, which I thought was doing&lt;BR /&gt;nicely, but a quick **bleep**/DISK spewed a torrent of complaints:&lt;BR /&gt;%ANALDISK-W-MULTALLOC, %ANALDISK-W-LOSTHEADER, and ppssibly others.&amp;nbsp; Its&lt;BR /&gt;BADBLK.SYS was 9 blocks, and a DUMP of that included a few complaints&lt;BR /&gt;like this:&lt;/P&gt;&lt;P&gt;Dump of file DUA0:[000000]BADBLK.SYS;1 on 3-DEC-2023 20:34:48.24&lt;BR /&gt;File ID (3,3,0) End of file block 9 / Allocated 9&lt;/P&gt;&lt;P&gt;Virtual block number 6 (00000006), 512 (0200) bytes&lt;/P&gt;&lt;P&gt;%SYSTEM-F-ILLBLKNUM, illegal logical block number&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; This stuff was all created on this virtual system, no copying from&lt;BR /&gt;another system.&amp;nbsp; Perhaps repeated instances of shut-off rather than&lt;BR /&gt;shut-down cause more trouble than one might hope.&lt;/P&gt;</description>
      <pubDate>Mon, 04 Dec 2023 03:18:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202068#M105880</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2023-12-04T03:18:02Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202070#M105881</link>
      <description>&lt;P&gt;This quesiton, with much less details unfortunately, was cross-posted in the VSI Forum as:&lt;/P&gt;&lt;P&gt;&lt;A href="https://forum.vmssoftware.com/viewtopic.php?f=13&amp;amp;t=8919" target="_blank" rel="noopener"&gt;https://forum.vmssoftware.com/viewtopic.php?f=13&amp;amp;t=8919&lt;/A&gt;&lt;/P&gt;&lt;P&gt;My answer there was:&lt;/P&gt;&lt;DIV&gt;Huh? Is this question an early April Fools joke or apprentice rock fetch? Or simply overthinking things?&lt;BR /&gt;&lt;BR /&gt;ANALYZE/RMS on badblk.sys is utterly meaningless.&lt;BR /&gt;This file contains all the known bad blocks on the volume. It has no RMS structure as such to analyze and any chunk of block read is _supposed_ to give a hardware read error. As block allocations are whole clusters some blocks will be readable but have random contents.&lt;BR /&gt;&lt;BR /&gt;Don't worry, by happy.&lt;BR /&gt;Well... except that disks aren't supposed to have visible bad blocks no more, so if the badblk.sys file has any allocation then there may be a deeper, underlying issue.&lt;BR /&gt;&lt;BR /&gt;Hein.&lt;/DIV&gt;</description>
      <pubDate>Mon, 04 Dec 2023 03:38:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202070#M105881</guid>
      <dc:creator>Hein_vdHeuvel_d</dc:creator>
      <dc:date>2023-12-04T03:38:09Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202167#M105883</link>
      <description>&lt;P&gt;Hello, Volker.&lt;/P&gt;&lt;P&gt;The DUMP command showed only one LBN, which did turn out be bad. I re-ran the DUMP command, but without any qualifiers, and that's when I got the following error message for five (5) of the 17 virtual blocks in the file:&lt;/P&gt;&lt;P&gt;%SYSTEM-F-ILLBLKNUM, illegal logical block number&lt;/P&gt;&lt;P&gt;So the question now is how to fix it.&amp;nbsp; But beyond that,&amp;nbsp; here's another question:&lt;/P&gt;&lt;P&gt;Does BADBLK.SYS files even matter anymore? Is BADBLK.SYS even worth fixing?&lt;/P&gt;&lt;P&gt;The disk in question is an emulated RZ59, and the O/S is VAX/VMS v5.5-2H4, so I'm wondering if BADBLK.SYS files are even needed for this particular environment.&lt;/P&gt;&lt;P&gt;- Ron&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 04 Dec 2023 18:36:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202167#M105883</guid>
      <dc:creator>rbeasley3</dc:creator>
      <dc:date>2023-12-04T18:36:29Z</dc:date>
    </item>
    <item>
      <title>Re: How to repair a corrupted BADBLK.SYS file</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202171#M105884</link>
      <description>&lt;P&gt;Ron,&lt;/P&gt;&lt;P&gt;There is nothing to fix here. If you are concerned that you may have a block or two "tagged" as defective, perform an image backup/restore for that disk.&amp;nbsp; This will "initialize" the disk to be free from errors.&amp;nbsp; There is no reason to touch this file for any reason.&amp;nbsp; It has no meaning in the emulated environment.&lt;/P&gt;&lt;P&gt;The only way this was potentially modified would be if the .vdisk file that is the OpenVMS perceived "disk" were to be scanned by a virus scanner as corruption is possible in that case.&amp;nbsp; Ensure that there are no scans of these disks and all shouldbe well.&lt;/P&gt;&lt;P&gt;Dan&lt;/P&gt;</description>
      <pubDate>Mon, 04 Dec 2023 19:33:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/how-to-repair-a-corrupted-badblk-sys-file/m-p/7202171#M105884</guid>
      <dc:creator>abrsvc</dc:creator>
      <dc:date>2023-12-04T19:33:35Z</dc:date>
    </item>
  </channel>
</rss>

