INFO-VAX Wed, 17 Jan 2007 Volume 2007 : Issue 33 Contents: Re: "no such file" from one node only Re: "no such file" from one node only Re: "no such file" from one node only Re: "no such file" from one node only Re: "no such file" from one node only (Update) Re: Is this a (permanent) disk failure? Re: (Update) Re: Is this a (permanent) disk failure? Acc#2049850557 Activation Code Please Re: Blast from the 1988s (DEC proposal) Re: Diskmizer 2.1 License Hello- ITRC? Anybody home? Re: special deal DS10 for under $1400 Re: special deal DS10 for under $1400 Re: Who has a record locked ---------------------------------------------------------------------- Date: 16 Jan 2007 11:01:21 -0800 From: "BIO" Subject: Re: "no such file" from one node only Message-ID: <1168974080.883808.32650@51g2000cwl.googlegroups.com> The directory/file_id does in fact show the same id's on both nodes. But a dump/dire (of the files that can be seen) reveals some kind of error with the directory: %DUMP-E-JUNKINDIR, directory format error encountered at byte offset 0 - dump aborting So I guess I will have to recreate the directory, and move the files. Thank you Hein, at least I know what I have to do now, but do you have a theory as to why the view is different from each node? Ingemar Hein RMS van den Heuvel wrote: > The critical information missing from the topic is a 'simple' > directory: > > $DIRECTORY/FILE_ID ... > > Nothin more, nothing less. > That will show you whether the system is looking for the right file or > not and thus tell you whether to suspect the directory or deeper down. > > You may also want to use DUMP/DIRE > > hth, > Hein. > > > BIO wrote: > > OpenVMS V7.1-2 cluster w/ 2 alphas > > > > on one node (G): > > $ sho sym dir > > DIR == "DIRE/SIZE=ALLO/DATE=MODIF/PROT/WIDTH=(FILENAME=24,SIZE=8)" > > $ dir glauto:ddsinv-ar > > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > > DDSINV-AR.SFD;2 86 16-JAN-2007 04:48:45.76 > > (RWED,RWED,RWED,) > > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > > (RWED,RWED,RWED,) > > Total of 2 files, 2494 blocks. > > $ > > > > whereas on the other node (A): > > $ dir glauto:ddsinv-ar > > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > > DDSINV-AR.SFD;2 no such file > > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > > (RWED,RWED,RWED,) > > Total of 2 files, 2408 blocks. > > $ > > > > The glauto and gl_data_root logicals are the same on both nodes, but > > note that only ONE of these TWO files (in the same directory) has a > > problem, so any issues with the disk directory structure should affect > > both files the same, no?; there are numerous other files in this > > directory and those are all visible from both nodes; and, no, there are > > no concealed or rooted directories on this disk. > > I have already $ ANAL/DISK/REPAIR with no effect. > > > > I suppose I will have to delete or set file/remove the problematic one, > > but I'd like to understand what is causing the > > problem. Has anyone seen anything like this? Is there a fix (short of a > > reboot, which is not an option right now)? > > > > Ingemar ------------------------------ Date: Tue, 16 Jan 2007 14:29:06 -0500 From: norm.raphael@metso.com Subject: Re: "no such file" from one node only Message-ID: "BIO" wrote on 01/16/2007 02:01:21 PM: > The directory/file_id does in fact show the same id's on both nodes. > But a dump/dire (of the files that can be seen) reveals some kind of > error with the directory: > %DUMP-E-JUNKINDIR, directory format error encountered at byte offset 0 > - dump aborting > > So I guess I will have to recreate the directory, and move the files. > > Thank you Hein, at least I know what I have to do now, but do you have > a theory as to why the view is different from each node? One Node may have a cached view of the directory file from prior to the corruption, while the other has/had to go the disk and read. > > Ingemar > > Hein RMS van den Heuvel wrote: > > The critical information missing from the topic is a 'simple' > > directory: > > > > $DIRECTORY/FILE_ID ... > > > > Nothin more, nothing less. > > That will show you whether the system is looking for the right file or > > not and thus tell you whether to suspect the directory or deeper down. > > > > You may also want to use DUMP/DIRE > > > > hth, > > Hein. > > > > > > BIO wrote: > > > OpenVMS V7.1-2 cluster w/ 2 alphas > > > > > > on one node (G): > > > $ sho sym dir > > > DIR == "DIRE/SIZE=ALLO/DATE=MODIF/PROT/WIDTH=(FILENAME=24,SIZE=8)" > > > $ dir glauto:ddsinv-ar > > > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > > > DDSINV-AR.SFD;2 86 16-JAN-2007 04:48:45.76 > > > (RWED,RWED,RWED,) > > > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > > > (RWED,RWED,RWED,) > > > Total of 2 files, 2494 blocks. > > > $ > > > > > > whereas on the other node (A): > > > $ dir glauto:ddsinv-ar > > > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > > > DDSINV-AR.SFD;2 no such file > > > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > > > (RWED,RWED,RWED,) > > > Total of 2 files, 2408 blocks. > > > $ > > > > > > The glauto and gl_data_root logicals are the same on both nodes, but > > > note that only ONE of these TWO files (in the same directory) has a > > > problem, so any issues with the disk directory structure should affect > > > both files the same, no?; there are numerous other files in this > > > directory and those are all visible from both nodes; and, no, there are > > > no concealed or rooted directories on this disk. > > > I have already $ ANAL/DISK/REPAIR with no effect. > > > > > > I suppose I will have to delete or set file/remove the problematic one, > > > but I'd like to understand what is causing the > > > problem. Has anyone seen anything like this? Is there a fix (short of a > > > reboot, which is not an option right now)? > > > > > > Ingemar > ------------------------------ Date: 16 Jan 2007 12:54:25 -0800 From: "AEF" Subject: Re: "no such file" from one node only Message-ID: <1168980865.295100.45670@38g2000cwa.googlegroups.com> norm.raphael@metso.com wrote: > "BIO" wrote on 01/16/2007 02:01:21 PM: > > > The directory/file_id does in fact show the same id's on both nodes. > > But a dump/dire (of the files that can be seen) reveals some kind of > > error with the directory: > > %DUMP-E-JUNKINDIR, directory format error encountered at byte offset 0 > > - dump aborting > > > > So I guess I will have to recreate the directory, and move the files. > > > > Thank you Hein, at least I know what I have to do now, but do you have > > a theory as to why the view is different from each node? > > One Node may have a cached view of the directory file from prior to > the corruption, while the other has/had to go the disk and read. I find this puzzling. Since the problem system can read the correct FID from the directory, then doesn't that mean the problem lies with the file header? But the directory still has some corruption in it. So maybe both are corrupted? Has the original poster checked for disk errors with SHOW ERROR or SH DEV D? Or perhaps a run of ANAL/DISK may show some useful clues. Just some ideas. AEF > > > > > > Ingemar > > > > Hein RMS van den Heuvel wrote: > > > The critical information missing from the topic is a 'simple' > > > directory: > > > > > > $DIRECTORY/FILE_ID ... > > > > > > Nothin more, nothing less. > > > That will show you whether the system is looking for the right file or > > > not and thus tell you whether to suspect the directory or deeper down. > > > > > > You may also want to use DUMP/DIRE > > > > > > hth, > > > Hein. > > > > > > > > > BIO wrote: > > > > OpenVMS V7.1-2 cluster w/ 2 alphas > > > > > > > > on one node (G): > > > > $ sho sym dir > > > > DIR == "DIRE/SIZE=ALLO/DATE=MODIF/PROT/WIDTH=(FILENAME=24,SIZE=8)" > > > > $ dir glauto:ddsinv-ar > > > > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > > > > DDSINV-AR.SFD;2 86 16-JAN-2007 04:48:45.76 > > > > (RWED,RWED,RWED,) > > > > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > > > > (RWED,RWED,RWED,) > > > > Total of 2 files, 2494 blocks. > > > > $ > > > > > > > > whereas on the other node (A): > > > > $ dir glauto:ddsinv-ar > > > > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > > > > DDSINV-AR.SFD;2 no such file > > > > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > > > > (RWED,RWED,RWED,) > > > > Total of 2 files, 2408 blocks. > > > > $ > > > > > > > > The glauto and gl_data_root logicals are the same on both nodes, but > > > > note that only ONE of these TWO files (in the same directory) has a > > > > problem, so any issues with the disk directory structure should > affect > > > > both files the same, no?; there are numerous other files in this > > > > directory and those are all visible from both nodes; and, no, there > are > > > > no concealed or rooted directories on this disk. > > > > I have already $ ANAL/DISK/REPAIR with no effect. > > > > > > > > I suppose I will have to delete or set file/remove the problematic > one, > > > > but I'd like to understand what is causing the > > > > problem. Has anyone seen anything like this? Is there a fix (short of > a > > > > reboot, which is not an option right now)? > > > > > > > > Ingemar > > ------------------------------ Date: Tue, 16 Jan 2007 17:48:09 -0500 From: JF Mezei Subject: Re: "no such file" from one node only Message-ID: <45ad5665$0$9460$c3e8da3@news.astraweb.com> BIO wrote: > $ dir glauto:ddsinv-ar > Directory GL_DATA_ROOT:[GLDATA.GL_INTERFACE] > DDSINV-AR.SFD;2 no such file > DDSINV-AR.SF_ERROR;1 2408 16-JAN-2007 04:50:22.40 > (RWED,RWED,RWED,) > Total of 2 files, 2408 blocks. > $ > I suppose I will have to delete or set file/remove the problematic one, > but I'd like to understand what is causing the > problem. I would not delete or touch it until you understand what happened. You may have other files on your disk that are also "broken". And disk caches tend to make the problem appear to be progressive. You need to do due diligence for this. SHOW LOG/FULL GL_DATA_ROOT on both nodes. Make sure that the device specification is the very same and that one node doesn't have some logical that redefines the device to go somewhere else. DIR/FULL GL_DATA_ROOT:[GLDATA]GL_INTERFACE.DIR;* on both nodes and make sure: that the GL_INTERFACE.DIR file is truly the same (FILE_ID and device as well as other parameters). On the node where the file is still there, do a SET FILE/ENTER to create a new pointer to the file in a different directory. Then on the node where the problem exists, look to see if the file is now available in that different directory. ------------------------------ Date: 16 Jan 2007 14:59:54 -0800 From: "Hein RMS van den Heuvel" Subject: Re: "no such file" from one node only Message-ID: <1168988394.435883.9940@v45g2000cwv.googlegroups.com> AEF wrote: > norm.raphael@metso.com wrote: > > "BIO" wrote on 01/16/2007 02:01:21 PM: > > > > > The directory/file_id does in fact show the same id's on both nodes. : > I find this puzzling. Since the problem system can read the correct FID > from the directory, then doesn't that mean the problem lies with the > file header? But the directory still has some corruption in it. So > maybe both are corrupted? I think the file is fine, but the corrupted directory, at some point in time, returned an invalid id, even though it seems valid now. As suggested, maybe 1 bad read loaded bad data into a cache, and some got refreshed since. It's pointless to speculate what further oddities may happen after a corruption. It's unlikely that two not-so-related error happened at the same time. So the beginning of the directory was corrupted. Next step woudl be to try the target block itself. Best I can think of, you need a roundabout approach. On a 'good' node: $SEARCH/NUM/FORM=NON suspect.dir suspect.dat $! Look at Record Number from search: recnum $DUMP/RECORD=(COUNT=1,START='recnum;) $! Look mostly are RFA in dump header, and a little at the data $! Convert first hex fields in RFA to decimal: vbn On 'bad' node: $DUMP/DIREC/BLOC=(COUNT=1,START='vbn') suspect.dir You might want to dump more blocks, but this is the one to focus on. I've heard about rare cases of shadowing goign awry were the system thought it succesfully created a two identical copies of the data on each disk, but one stayed as old data (prior version of similar data, or old file 'shining through' for new allocation). After that, it becomes a guessing game whether you a read will come from the bad disk or good disk. A subsequent update can fix or break it for all! Cheers, Hein. ------------------------------ Date: 16 Jan 2007 17:32:58 -0800 From: TFTAJLLYMXZP@spammotel.com Subject: (Update) Re: Is this a (permanent) disk failure? Message-ID: <1168997577.983486.30220@q2g2000cwa.googlegroups.com> Strangely, the disk in question mounted without complaint today. I had left the machine powered down for two days because of other priorites around here, and because the machine failed to complete the initial boot cycle - stopping before reaching the ">>>" prompt - immediately after my last posts on this topic. Well, today I can report that all is again well. Like most of us, there's nothing like a little nap to improve our disposition. I had slid the machine over a few feet the day I noticed the drive had gone down, so it appears that all has settled in at the new location. Hard to know, exactly, but all's well that ends well. Thanks to everyone who offerred ideas on this. Cheers, Alder David J Dachtera wrote: > TFTAJLLYMXZP@spammotel.com wrote: > > > > $ MOUNT/SYSTEM/QUOTA/NOASSIST DKA100: USR > > %MOUNT-F-MEDOFL, medium is offline > > > > And then, > > $ SHO DEV DK > > ... > > SZEGED$DKA100: Online 0 > > ... > > > > Michael Moroney wrote: > > > Repeat the MOUNT command with /NOASSIST and see what error is reported. > > That "online" indication is indeed misleading since the system really has no way > way of knowing whether the device is actually "online" or not without explicitly > polling it for that information, which I'm fairly certain it doesn't. Put an > older tape drive off-line, for example, and the indication at VMS doe snot > change. Likewise, older disk drives (RA8x, etc.). > > About the only time I see an "offline" indication is when all of the paths to a > fibre channel disk/tape fail. > > -- > David J Dachtera > dba DJE Systems > http://www.djesys.com/ > > Unofficial OpenVMS Marketing Home Page > http://www.djesys.com/vms/market/ > > Unofficial Affordable OpenVMS Home Page: > http://www.djesys.com/vms/soho/ > > Unofficial OpenVMS-IA32 Home Page: > http://www.djesys.com/vms/ia32/ > > Unofficial OpenVMS Hobbyist Support Page: > http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 17 Jan 2007 00:17:48 -0500 From: "Richard B. Gilbert" Subject: Re: (Update) Re: Is this a (permanent) disk failure? Message-ID: TFTAJLLYMXZP@spammotel.com wrote: > Strangely, the disk in question mounted without complaint today. I had > left the machine powered down for two days because of other priorites > around here, and because the machine failed to complete the initial > boot cycle - stopping before reaching the ">>>" prompt - immediately > after my last posts on this topic. > > Well, today I can report that all is again well. Like most of us, > there's nothing like a little nap to improve our disposition. I had > slid the machine over a few feet the day I noticed the drive had gone > down, so it appears that all has settled in at the new location. Hard > to know, exactly, but all's well that ends well. > > Thanks to everyone who offerred ideas on this. > > Cheers, > > Alder I hope you are making regular backups of this disk. Your problems may be been due to a chance glitch that will never happen again but I wouldn't count on it. If it were mine and at a commercial site, I'd have it replaced or move it to somewhere that was not critical. You DON'T want to have your pager go off at three AM some morning and learn that the disk has failed, cannot be revived, and has hosed a critical job! ------------------------------ Date: Wed, 17 Jan 2007 03:26:30 GMT From: Kelvin Subject: Acc#2049850557 Activation Code Please Message-ID:

Amazing Hot Sexy! Free Videos! http://ghetonews.com Free Images! These videos are hotter than a 3 week crash course in MK-Ultra 90!

Al-Zulu

 

------------------------------ Date: Wed, 17 Jan 2007 04:24:17 +0100 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: Blast from the 1988s (DEC proposal) Message-ID: <45ad96e1.524144494f47414741@radiogaga.harz.de> Mark Daniel wrote: > I'm (idly) curious about design limitations [...] on cluster size. > Things like the 65k DECnet node limit. IIRC, the cluster manual says the architectural limit is 255 nodes. cu, Martin -- | Martin Vorlaender | OpenVMS rules! OpenVMS: When you | work: mv@pdv-systeme.de KNOW where you want | http://www.pdv-systeme.de/users/martinv/ to go today. | home: martin@radiogaga.harz.de ------------------------------ Date: Wed, 17 Jan 2007 01:10:18 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Diskmizer 2.1 License Message-ID: <00A61D32.CED7549A@SendSpamHere.ORG> In article <1168923146.468998.165670@38g2000cwa.googlegroups.com>, "bclaremont" writes: > > >Hi, > >Anyone know where I might lay hands on a Diskmizer 2.1 license good for >50 units? I have the product installed on a MicroVAX II/GPX running >VMS 5.5. I upgraded the CPU and memory to a straight MicroVAX II, >which had the unfortunate side effect of changing the Diskmizer license >requirements from 10 Type F units to 50. I worked on Diskmizer at one time. I don't know if it is actively being sold these days. Bruce, if you contact Stan Quayle he might have a workaround for your problem and it'll put some money in my pocket too! :D -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Tue, 16 Jan 2007 13:10:03 -0800 From: DeanW Subject: Hello- ITRC? Anybody home? Message-ID: <3f119ada0701161310k56eb752j85904c30bfc682b3@mail.gmail.com> I prefer to download patch kits directly to the machine that needs them whenever possible. Partly this is to reduce the chances of the bits getting munged up on the wire, partly to avoid chances of the bits getting munged up on a non-VMS machine, and partly to make most efficient use of resources (bandwidth and my time). ITRC has an option to download a script that will then download your files. I thought that would be cool. And it would, if it ran on VMS (the platform for which I'm downloading patches.) But it's a *nix-y shell script. Little good *that* does me. So, I'm using CSWB to yank 'em down to my local hobbyist box, then I'll decnet-over-IP them to the box they're going to. FWIW, Verizon's FiOS service with fiber optic cable to the demarc does not suck. ;) -- Dean Woodward =o&o dean.woodward@gmail.com ------------------------------ Date: Tue, 16 Jan 2007 19:01:06 -0500 From: "David Turner, Island Computers US Corp" Subject: Re: special deal DS10 for under $1400 Message-ID: oops Or a barebones for only $1400 DS10 466Mhz 256MB Dual NIC 10/100 Call now ! 912-447 6622 "David Turner, Island Computers US Corp" wrote in message news:tFdrh.1912$To.605@bigfe9... > VMS Special for January ONLY > > Alphaserver DS10 46Mhz EV6 > 256MB Memory > Dual Front Hot Pluggable Slots > Dual 18GB 15KRPM > CDROM > Dual NIC 10/100 > U160 SCSI Controller > Set up for VMS But no License > > Only $1799 > > > Call now !!!! > ------------------------------ Date: Tue, 16 Jan 2007 16:08:21 -0800 From: Alan Frisbie Subject: Re: special deal DS10 for under $1400 Message-ID: <1168992558.979687@smirk> David Turner, Island Computers US Corp wrote: > VMS Special for January ONLY > > Alphaserver DS10 46Mhz EV6 > 256MB Memory > Dual Front Hot Pluggable Slots > Dual 18GB 15KRPM > CDROM > Dual NIC 10/100 > U160 SCSI Controller > Set up for VMS But no License > > Only $1799 How much with a license? Alan ------------------------------ Date: Tue, 16 Jan 2007 18:46:15 -0500 From: Dave Froble Subject: Re: Who has a record locked Message-ID: Michael D. Ober wrote: > I occasionally need to be able to find out which process has a specific RMS > record locked in an indexed file. Basically, our system uses pessimistic > locking and I need to be able to figure out who is locking individual > records and then going to lunch. > > Thanks, > Mike Ober. > > There are a number of utilities at the freeware site that will help with this. RMS_LOCKS submitted by me, which can take a snapshot of the DLM database and display all or blocked locks, a utility by David Sneldon which has some good selection capability, and a few more. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 ------------------------------ End of INFO-VAX 2007.033 ************************