Understanding SYSLOST

Management of storage subsystems: SAN, volume shadowing, logical disks, file systems, and more.
User avatar

Topic author
issinoho
Master
Posts: 116
Joined: Wed Apr 05, 2023 9:22 am
Reputation: 0
Location: Glasgow, Scotland
Status: Offline
Contact:

Re: Understanding SYSLOST

Post by issinoho » Fri Jan 24, 2025 5:13 am

Wow, thanks for that amazingly detailed response. I'm sure many on here will have learned a lot from that - I have.

Code: Select all

$ mcr dfu directory /alias $1$dga1501:
Returns 100+ entries, and the one that accounts for the batch entry issue is there, i.e.

Code: Select all

$1$DGA1501:[000000]PROJECT.DIR;1 is alias for $1$DGA1501:[SYSLOST]PROJECT.DIR;1
And, worryingly, there are a whole bunch of system file aliases.

Code: Select all

$1$DGA1501:[000000]BACKUP.SYS;1 is alias for $1$DGA1501:[SYSLOST]BACKUP.SYS;1
$1$DGA1501:[000000]BADBLK.SYS;1 is alias for $1$DGA1501:[SYSLOST]BADBLK.SYS;1
$1$DGA1501:[000000]BADLOG.SYS;1 is alias for $1$DGA1501:[SYSLOST]BADLOG.SYS;1
$1$DGA1501:[000000]BITMAP.SYS;1 is alias for $1$DGA1501:[SYSLOST]BITMAP.SYS;1
$1$DGA1501:[000000]CONTIN.SYS;1 is alias for $1$DGA1501:[SYSLOST]CONTIN.SYS;1
$1$DGA1501:[000000]CORIMG.SYS;1 is alias for $1$DGA1501:[SYSLOST]CORIMG.SYS;1
$1$DGA1501:[000000]GPT.SYS;1 is alias for $1$DGA1501:[SYSLOST]GPT.SYS;1
$1$DGA1501:[000000]INDEXF.SYS;1 is alias for $1$DGA1501:[SYSLOST]INDEXF.SYS;1
$1$DGA1501:[000000]SECURITY.SYS;1 is alias for $1$DGA1501:[SYSLOST]SECURITY.SYS;1
$1$DGA1501:[000000]VOLSET.SYS;1 is alias for $1$DGA1501:[SYSLOST]VOLSET.SYS;1
$1$DGA1501:[SYSLOST.VMS$COMMON.SYSEXE]LMF$LICENSE.LDB;1 is alias for $1$DGA1501:[SYSLOST]LMF$LICENSE.LDB;1
$1$DGA1501:[SYSLOST.VMS$COMMON.SYSEXE]RIGHTSLIST.DAT;1 is alias for $1$DGA1501:[SYSLOST]RIGHTSLIST.DAT;1
$1$DGA1501:[SYSLOST.VMS$COMMON.SYSEXE]SYSUAF.DAT;1 is alias for $1$DGA1501:[SYSLOST]SYSUAF.DAT;1
$1$DGA1501:[SYSLOST.VMS$COMMON.SYSEXE]VMS$PASSWORD_HISTORY.DATA;1 is alias for $1$DGA1501:[SYSLOST]VMS$PASSWORD_HISTORY.DATA;1
$1$DGA1501:[SYSLOST.VMS$COMMON.SYSLIB]VMS$PASSWORD_DICTIONARY.DATA;1 is alias for $1$DGA1501:[SYSLOST]VMS$PASSWORD_DICTIONARY.DATA;1
$1$DGA1501:[VMS$COMMON.SYSEXE]LMF$LICENSE.LDB;1 is alias for $1$DGA1501:[SYSLOST]LMF$LICENSE.LDB;2
$1$DGA1501:[VMS$COMMON.SYSEXE]QMAN$MASTER.DAT;2 is alias for $1$DGA1501:[SYSLOST]QMAN$MASTER.DAT;2
$1$DGA1501:[VMS$COMMON.SYSEXE]QMAN$MASTER.DAT;1 is alias for $1$DGA1501:[SYSLOST]QMAN$MASTER.DAT;1
$1$DGA1501:[VMS$COMMON.SYSEXE]RIGHTSLIST.DAT;1 is alias for $1$DGA1501:[SYSLOST]RIGHTSLIST.DAT;2
$1$DGA1501:[VMS$COMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$QUEUES;2 is alias for $1$DGA1501:[SYSLOST]SYS$QUEUE_MANAGER.QMAN$QUEUES;2
$1$DGA1501:[VMS$COMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$QUEUES;1 is alias for $1$DGA1501:[SYSLOST]SYS$QUEUE_MANAGER.QMAN$QUEUES;1
$1$DGA1501:[VMS$COMMON.SYSEXE]SYSUAF.DAT;1 is alias for $1$DGA1501:[SYSLOST]SYSUAF.DAT;2
$1$DGA1501:[VMS$COMMON.SYSEXE]VMS$PASSWORD_HISTORY.DATA;1 is alias for $1$DGA1501:[SYSLOST]VMS$PASSWORD_HISTORY.DATA;2
$1$DGA1501:[VMS$COMMON.SYSEXE]VMSMAIL_PROFILE.DATA;1 is alias for $1$DGA1501:[SYSLOST]VMSMAIL_PROFILE.DATA;1
$1$DGA1501:[VMS$COMMON.SYSMGR]VMS$AUDIT_SERVER.DAT;1 is alias for $1$DGA1501:[SYSLOST]VMS$AUDIT_SERVER.DAT;1
$1$DGA1501:[VMS$COMMON.SYSLIB]VMS$PASSWORD_DICTIONARY.DATA;1 is alias for $1$DGA1501:[SYSLOST]VMS$PASSWORD_DICTIONARY.DATA;2
Given the above, AND that everything is working right now, AND this is a critical infrastructure system, what advice would you give?
OpenVMS Ambassador
DEC technology veteran since 1990
http://vamp.issinoho.com

User avatar

volkerhalle
Master
Posts: 216
Joined: Fri Aug 14, 2020 11:31 am
Reputation: 0
Status: Offline

Re: Understanding SYSLOST

Post by volkerhalle » Fri Jan 24, 2025 12:25 pm

NOTE:

2 'files' with the SAME FILE-ID are THE SAME FILE ! The FILE-ID points to the FILE HEADER in INDEXF.SYS, which describes the attributes and the contents of the file, i.e. the logical blocks (LBNs) on the disk allocated to that file.

In the file header (shown with $ DUMP/HEADER/BLOCK=COUNT=0 filename), there is a Back link file identification:, which is the FILE ID of the directory file, in which the filename for this file has been entered. The file header of that directory file can be shown with $ DUMP/ID=backlink_file_id/HEADER/BLOCK=COUNT=0 disk:

A file is entered into [SYSLOST] (by $ ANALYZE/DISK/REPAIR), if it's file name is not in any directory, so the file could not be found by searching for the file name.

It looks like all files on your disk are entered into [SYSLOST].

You need to check the 'special' files in [000000] if their backlink file IDs correctly point to [000000]000000.DIR (FID:4,4,0)

Volker.
Last edited by volkerhalle on Sat Jan 25, 2025 6:51 am, edited 1 time in total.


roberbrooks
VSI Expert
Valued Contributor
Posts: 83
Joined: Thu Jun 20, 2019 11:48 am
Reputation: 0
Location: Leverett, MA
Status: Offline

Re: Understanding SYSLOST

Post by roberbrooks » Fri Jan 24, 2025 11:04 pm

> The evolution of this storage class is the msa2060/msa2062 family which however do not appear to have
> been certified by VSI.

I have mentioned this to our (VSI) management that I'd like to get an MSA2060 in house to qualify.

We actually began qualifying it over three years ago, and discovered that (at the time) it had broken firmware that
led to reproducible data corruption. Our storage test engineer retired at the end of 2022, prior to any new firmware being given to us. HPE requested the loaner they had sent us to be returned to them.

I've heard through the grapevine that newer firmware has fixed that problem, but until we can verify it ourselves we
cannot qualify it.
--
-- Rob

User avatar

Topic author
issinoho
Master
Posts: 116
Joined: Wed Apr 05, 2023 9:22 am
Reputation: 0
Location: Glasgow, Scotland
Status: Offline
Contact:

Re: Understanding SYSLOST

Post by issinoho » Sat Jan 25, 2025 5:26 am

So given all the above, I'm not inclined to try to change anything here. There doesn't appear to be an easy way to break the alias (am I wrong?) leaving the original files intact, so we are where we are and I'm just going to leave the SYSLOST files well alone.
OpenVMS Ambassador
DEC technology veteran since 1990
http://vamp.issinoho.com


jon.pinkley
Contributor
Posts: 11
Joined: Sun Nov 10, 2024 4:15 pm
Reputation: 0
Status: Offline

Re: Understanding SYSLOST

Post by jon.pinkley » Fri Jan 31, 2025 12:46 am

issinoho wrote:
Sat Jan 25, 2025 5:26 am
So given all the above, I'm not inclined to try to change anything here. There doesn't appear to be an easy way to break the alias (am I wrong?) leaving the original files intact, so we are where we are and I'm just going to leave the SYSLOST files well alone.
Leaving it like it is may be ok for the short term, but it isn't good to leave it like it is for the long term.

This is especially true if you use purge, because OpenVMS (even 8.3 and 8.4) don't handle this in the way I would consider correct. At least it is very confusing. And a test i just did on a small LD device with ODS-5 and hard links enabled showed the same results as when using an ODS-2. John Briggs showed an example of this in this comp.os.vms thread Deleting alias files (blocks deleted)
https://groups.google.com/g/comp.os.vms/c/gLqmWwoXqZI

The most interesting part of the thread starts with Hein's post from Dec 20, 2005, 11:05:50 PM here: https://groups.google.com/g/comp.os.vms ... vTAtpRTrcJ

John Brigg's two examples start here: (this and the following post)
https://groups.google.com/g/comp.os.vms ... v6niXQRR0J

My recommendation would be to fix, but in your case manual intervention will probably be needed.

I would also recommend creating a couple of small 1000 block LD disk ($ LD help setup), initialize one with /struc=2 and the other with /structure=5/volume=hard, and then play with set file /enter and set file /remove (and delete and purge)

Here's a thread on how a common case of incorrect backlinks (vms$common.dir vs syscommon.dir) can be fixed.
https://forum.vmssoftware.com/viewtopic ... 1084#p2659

Oh, and I found this on bitsavers https://bitsavers.org/pdf/dec/vax/vms/t ... s_1990.pdf not light reading, but much easier to read than the Runoff for hardcopy printers version of the ODS-2 spec from 1985, which formed the basis of chapter two of EY-F575E-DP.

Here's a comand file I used to reproduce John Brigg's results, TEST_ALIAS.COM

Code: Select all

$ ver = 'f$verify(1)'
$ set noon
$! TEST_ALIAS.COM
$! Jon Pinkley - 2025-01-30 response to Understanding SYSLOST
$! see https://forum.vmssoftware.com/viewtopic.php?f=31&t=9364
$! demonstrate inconsistent behavior with alias entries, delete vs purge (based on John Brigg's posts comp.os.vms)
$! for more info, see these old comp.os.vms threads
$! Deleting alias files (blocks deleted) https://groups.google.com/g/comp.os.vms/c/gLqmWwoXqZI
$! ODS5 and hardlinks https://groups.google.com/g/comp.os.vms/c/TQhvQgqH5hs
$ this_proc=f$environment("procedure")
$ proc_dir = f$parse(this_proc,,,"device") + f$parse(this_proc,,,"directory")
$ orig_default = f$environment("default")
$ show symbol orig_default
$ show default
$ show symbol this_proc
$ show symbol proc_dir
$ set default 'proc_dir'
$ show default
$
$ this_pid = f$getjpi("","PID")
$ cnt = 0
$
$_credir_top:
$ dir_str = "TEST_''this_pid'_''cnt'"
$ if f$search("''dir_str'.DIR") .nes. ""
$ then
$   write sys$output "''dir_str'.DIR already exists, skipping"
$   cnt = cnt + 1
$   goto _credir_top
$ else
$   write sys$output "Creating [.''dir_str']"
$   create/dir [.'dir_str']/version_limit=2/log ! create a new directory, and set default version limit to 2 so new files created wi
ll have version limit in directory
$ endif
$
$ set default [.'dir_str'] ! make new subdirectoy the current work directory (default directory)
$ pipe dir/ful [-]'dir_str'.dir | search* sys$pipe " version"
$ dump/dir [-]'dir_str'.dir ! dump empty new directory
$ create a.a;1
$ DECK
a.a;1
$ EOD
$ set file/ent=b.b;1 a.a;1 ! create an alias for a.a;1 called b.b;1
$ dir/file
$ type a.a;1
$ type b.b;1
$ dump/dir [-]'dir_str'.dir
$! try to delete the alias
$ delete b.b;1/log
$ dir/file/date=(cre,mod)
$ dfu dir/dump [-]'dir_str'.dir
$ type a.a;1
$ type b.b;1
$! in this case it just removed the entry from the directory.
$ set file/ent=b.b a.a ! create an alias for a.a;1 called b.b;1
$ dir/file/date=(cre,mod)
$ create b.b;2 ! b.b;2
$ DECK
b.b;2
$ EOD
$ dump/dir [-]'dir_str'.dir
$ type a.a;1
$ type b.b;1
$ type b.b;2
$ pipe dump/head/bl=c:0 a.a;1 | search* sys$pipe "file ident","file name:","dump of"
$ pipe dump/head/bl=c:0 b.b;1 | search* sys$pipe "file ident","file name:","dump of"
$ pipe dump/head/bl=c:0 b.b;2 | search* sys$pipe "file ident","file name:","dump of"
$! try to delete the alias to see if having another version of the file makes a difference
$ delete b.b;1/log
$ dir/file/date=(cre,mod)
$ if f$search("a.a;1") .nes. ""
$ then
$ ! still did not delete the primary (a.a;1), just removed alias directory entry.
$ ! Add alials back again and see if purge does same thing; it is using the same image (DELETE).
$   set file/rem b.b;1 ! should already be gone
$   set file/ent=b.b;1 a.a;1 ! create an alias for a.a;1 called b.b;1
$ endif
$ dir/file/date=(cre,mod)
$ purge b.b/log
$ dir/file/date=(cre,mod)
$! but it does not, it deletes the primary entry and the file. I consider this a bug, but it won't be fixed.
$! Aliases should be used only with great caution.
$ if f$search("a.a;1") .eqs. ""
$ then
$ ! recreate a.a;1 and alias b.b;1
$   create a.a;1
$ DECK
a.a;1
$ EOD
$   set file/rem b.b;1
$   set file/ent=b.b;1 a.a;1 ! create an alias for a.a;1 called b.b;1
$ endif
$ dir/file
$ type a.a;1
$ type b.b;1
$ type b.b;2
$ dump/dir [-]'dir_str'.dir
$!now create a third version of b.b, which will invoke auto purge to 2 versions of b.b in the test.dir, but this is an "alias" and n
ot primary.
$ create b.b; ! b.b;3
$ DECK
b.b;3
$ EOD
$ dump/dir [-]'dir_str'.dir
$ type a.a;1
$ type b.b;1
$ type b.b;2
$ type b.b;3
$_cleanup:
$ set default 'orig_default'
$ show default
$ exit 1+0*f$verify(ver)
Added in 33 minutes 49 seconds:
Here's another thread on the old HP ITRC forum concerning what was apparently a system disk corruption due to a partitioned cluster. Hopefully you did not have any "%ANALDISK-W-MULTALLOC, file (file-id) filename.type;ver
multiply allocated blocks" errors, as those are a sign of serious corruption.

https://community.hpe.com/t5/operating- ... -p/4265788
Last edited by jon.pinkley on Fri Jan 31, 2025 12:48 am, edited 1 time in total.

User avatar

Topic author
issinoho
Master
Posts: 116
Joined: Wed Apr 05, 2023 9:22 am
Reputation: 0
Location: Glasgow, Scotland
Status: Offline
Contact:

Re: Understanding SYSLOST

Post by issinoho » Fri Jan 31, 2025 4:17 am

Many thanks, Jon.
OpenVMS Ambassador
DEC technology veteran since 1990
http://vamp.issinoho.com

Post Reply