1 INFO-VAX	Sat, 24 Dec 2005	Volume 2005 : Issue 714       Contents:) Re: Deleting alias files (blocks deleted) % Question about large numbers of Locks   F ----------------------------------------------------------------------    Date: 23 Dec 2005 14:14:13 -0800$ From: "AEF" <spamsink2001@yahoo.com>2 Subject: Re: Deleting alias files (blocks deleted)C Message-ID: <1135376053.396957.144090@g44g2000cwa.googlegroups.com>   
 AEF wrote: > David J Dachtera wrote:  [...] J > > I've seen a fair few systems where VMS$COMMON has an identity crisis -D > > thinks it's name (in the header) is SYSCOMMON, and in some casesJ > > [SYS0.SYSCOMMON] is the "real" directory and [VMS$COMMON] is the alias6 > > (good luck trying to do a VMS upgrade on *THAT*!). > C > IIRC this results from restoring a system disk with an old enough G > version of BACKUP. The first occurrence of a file becomes the primary G > file even if it was originally the alias. In this case, VMSCOMMON.DIR G > is originally primary. But during the restore, [SYS0]SYSCOMMON.DIR is E > restored first, and because of the bug it is created as the primary B > entry. I think this was fixed around VMS V6.2 as I recall seeingH > something about it in those release notes. I think the cure is simple:H > rename VMS$COMMON.DIR to SYSCOMMON and back to VMS$COMMON!. I'll check% > the release notes at work tomorrow.   D VAX/VMS V6.2 Release Notes Sec. 3.3.1.9 VMS$COMMON.DIR File: Restore problems  G To paraphrase, it says that BACKUP before VMS/VAX V5.5-2 and before VMS . Alpha V1.5 did not restore this file properly.  D The only problem that results is that commands like SHOW ENTRY/FILES; and certain lexcial functions (F$GETQUI comes to mind) show ? "[SYSCOMMON" instead of "[VMS$COMMON" as the leading portion of 4 file-specs. The system disk is unaffected otherwise.  F [This is consistent with my memory that the first occurrence of a fileC during a restore becomes the primary, even if it was originally the  alias.]   F It gives a solution involving SET FILE/ENTER and SET FILE/REMOVE but IG think the easier solution renaming VMS$COMMON.DIR to SYSCOMMON and back G is easier and works just as well. Maybe there's a scenario in which you 4 need the SET FILE version, but I am not aware of it.   AEF    ------------------------------    Date: 23 Dec 2005 19:41:30 -0800 From: rcbryan@hotmail.com . Subject: Question about large numbers of LocksC Message-ID: <1135395690.722107.100920@g47g2000cwa.googlegroups.com>   D I am working on a system that has between 1400 and 1500 processes onC two nodes of a cluster.  Currently, all the processes read a common F file every so often to see about changes in their state.  The state of? the processes change very seldom, ten changes in a day (for all C processes) would be a lot.   This type of thing pains me no end.  I B think this could be implemented with locks with blocking ASTs.  ItF would be nice if I could address each process individually which wouldG mean on the order of 1500 locks on the cluster.  One advantage of using E individual locks is the amount of data required by each process would F fit in a lock value block and I would not need the disk access at all.  C Am I asking for headaches by having that many locks?   What type of B overhead can I expect?  Would I do better to have one big lock andF notify all processes to read the state file at the same time?  I couldG easily divide things into four big pieces but that still leaves several E hundred processes getting ASTs and reading the file at the same time.   G The system is a left over from the late 80s and early 90s.  Originally, > it had a few dozen processes.  It was perfectly acceptable forD everybody to read the file back in those days.  These days we have aF really awesome GS1280 that has plenty of CPU time but it is not magic.G If we use huge amounts of CPU time on overhead activities like this, it & is a matter of time before we run out.  # Thank you in advance for your input 	 /RC Bryan    ------------------------------   End of INFO-VAX 2005.714 ************************