INFO-VAX Wed, 11 Apr 2007 Volume 2007 : Issue 200 Contents: ftp: display some text and close session Re: ftp: display some text and close session Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: MicroVAX II chiller theatre Re: More bollocks from biggots Re: More on why Javascript is evil Re: OT: 216 Billion Americans Squirrels Are Scientifically Illiterate (Part 36) Re: Quick Sanity Check: Itanium-II ZX2000 Re: Quick Sanity Check: Itanium-II ZX2000 Re: Quick Sanity Check: Itanium-II ZX2000 Re: Quick Sanity Check: Itanium-II ZX2000 Re: Quick Sanity Check: Itanium-II ZX2000 Re: script to FTP file Re: script to FTP file Re: script to FTP file Re: script to FTP file SDLT 1 tape cartridge longevity? Re: SDLT 1 tape cartridge longevity? Re: SDLT 1 tape cartridge longevity? ---------------------------------------------------------------------- Date: 11 Apr 2007 08:04:39 -0700 From: "Pierre" Subject: ftp: display some text and close session Message-ID: <1176303879.564255.135040@d57g2000hsg.googlegroups.com> hi, I would like for a some users, when they connect with ftp, display some text explainig why they can no longer do that and then close the session. is this possible ? $ ucx show vers Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2 on a COMPAQ AlphaServer DS20E 666 MHzP running OpenVMS V7.2-1 TIA, Pierre ------------------------------ Date: Wed, 11 Apr 2007 12:27:29 -0400 From: norm.raphael@metso.com Subject: Re: ftp: display some text and close session Message-ID: "Pierre" wrote on 04/11/2007 11:04:39 AM: > hi, > > I would like for a some users, when they connect with ftp, display > some text explainig why they can no longer do that and then close the > session. > > is this possible ? Write a small program (or us a DCL symbol) to deliver your message and set that up as a substitute for those users at login. That way you will not incur network overhead. (I do this with a little BASIC program when I need to shut something off during testing or upgrades. It saves me from trying to find all references to the something, and when I'm done I just rename or delete the substitute exe.) > > $ ucx show vers > > Compaq TCP/IP Services for OpenVMS Alpha Version V5.3 - ECO 2 > on a COMPAQ AlphaServer DS20E 666 MHzP running OpenVMS V7.2-1 > > TIA, > Pierre > ------------------------------ Date: Wed, 11 Apr 2007 00:53:49 -0600 From: Jeff Campbell Subject: Re: MicroVAX II chiller theatre Message-ID: <1176274511_2915@sp12lax.superfeed.net> Curtis Rempel wrote: > Curtis Rempel wrote: > > >> For laughs, I built a TK50 STABACKIT on another system and the TK50 comes >> to life when I boot from it indicating that the TQK50 is alive, just as >> the DEQNA, however, it also fails with DEVOFFLINE after spinning the tape >> a bit: >> >>>>> boot mua0 >> 2.. >> ?4D DEVOFFLINE, MUA0 >> ?06 HLT INST >> PC = 00000E0A >> Failure. >> It's curious that both _DUA0_ and MUA0 result in DEVOFFLINE when booting. >> >> I was about ready to declare the RD53 dead, but after seeing this, I'm not >> so sure any more. > > As a followup to my own posting, I took the TK50 apart after it decided not > to let go of the tape. Handy little hole in the PCB for a screwdriver to > unwind a stuck TK50! > > Anyway, after cleaning the tape path, I decided to boot s/a backup again and > this time it worked (almost): > >>>> BOOT MUA0 > > 2..1..0.. > > > OpenVMS (TM) VAX Version V7.3 Major version id = 1 Minor version id = > 0 > %WBM-I-WBMINFO Write Bitmap has successfully completed initialization. > PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 10-APR-2007 19:48 > > Configuring devices . . . > Now configuring HSC, RF, and MSCP-served devices . . . > > Please check the names of the devices which have been configured, > to make sure that ALL remote devices which you intend to use have > been configured. > > If any device does not show up, please take action now to make it > available. > > > Available device DUA0: device type RD53 > Available device MUA0: device type TK50 > > Enter "YES" when all needed devices are available: YES > %BACKUP-I-IDENT, Stand-alone BACKUP T7.2; the date is 10-APR-2007 > 19:50:09.05 > $ BACKUP/IMAGE DUA0: MUA0:DUA0.BCK/SAVE_SET > %BACKUP-F-NOINDEXF, no valid index file header found on DUA0: > -SYSTEM-F-VOLINV, volume is not software enabled > If you do not want to perform another standalone BACKUP operation, > use the console to halt the system. > > If you do want to perform another standalone BACKUP operation, > ensure the standalone application volume is online and ready. > Enter "YES" to continue: > > > So, VMS sees DUA0: alright but complains that it can't back it up. Maybe > there is nothing on the disk and the disk is actually working after all. > The same repetitive brief flashing of the Ready light and arm motion sounds > happen as they do when trying to boot DUA0. Glad to see you got this far! 8-) The -F- messages from SAB are telling you that the RD53 is not online; that is, spinning and heads loaded over cylinder zero. SAB tries to read the index file, but the device is not online to the controller, hence not enabled. The common RD53 spin up and down cycling is almost always due to a 'sticky' voice coil actuator arm landing pad. The head slider arm is retracted at power down. It rests against a cushioning pad. These pads deteriorate with age. If the drive is allowed to sit unused for a while the pad will glue itself to the arm. The drive spin up and down cycling occurs when the drive spins up to the speed that the heads can be safely loaded, but the voice coil servo current limits trying to 'unstick' the arm from the landing pad. It stalls and the drive firmware resets and tries again... and again... 8-) Since the drive is otherwise unusable, you might try removing the top cover and manually unsticking the actuator arm. I don't think this will violate the warranty... 8-) > > Seems as though the Q-bus is operating correctly now that I moved the cards > up one slot and set the RQDX2 back to factory. The DEQNA works (at least > as far as to be refused into a cluster) and the TK50 is alive now. VMS > sees the RD53 via s/a backup so I would think at this point the RD53 is > either unstructured or has a hardware fault. It's also possible the RQDX2 is fubar. > > Are there any diags I could run to figure out which? I don't have any TK50 > diag media. > > If all else fails, I suppose I could just turn it into an academic exercise > (and forego any potential winning lottery numbers on the drive) to see if > the drive is alive by trying to restore something via s/a backup to it and > see what happens. :-) You might try NetBSD... one of your systems members could act as a boot server. You wouldn't necessarily need local disk though better if the RD53 was working. Ebay is every now and then a source of QBUS SCSI interfaces and drives. You may want to replace the RQDX2/RD53 subsytem in any case. Jeff ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- ------------------------------ Date: Wed, 11 Apr 2007 11:54:49 GMT From: ChrisQuayle Subject: Re: MicroVAX II chiller theatre Message-ID: Jeff Campbell wrote: > The common RD53 spin up and down cycling is almost always due to a > 'sticky' voice coil actuator arm landing pad. The head slider arm is > retracted at power down. It rests against a cushioning pad. These pads > deteriorate with age. If the drive is allowed to sit unused for a while > the pad will glue itself to the arm. The drive spin up and down cycling > occurs when the drive spins up to the speed that the heads can be safely > loaded, but the voice coil servo current limits trying to 'unstick' the > arm from the landing pad. It stalls and the drive firmware resets and > tries again... and again... 8-) Before you take the lid off, which may be final, lift the disk control board (2 screws at one end, then the board hinges up) and check the state of the grounding ball carbon wiper on the spindle. This is sometimes greased to reduce noise and can dry out over the years, increasing spindle friction. This causes execessive drive current on the spindle motor and can result in the motor spinning down. Put a dab of oil or silicon grease on the carbon wiper, reassemble and try again. If this doesn't work, try physically shaking / rotating the drive hard in the direction of spindle rotation. Pretty extreme, but not so bad as lifting the cover... Chris ------------------------------ Date: Wed, 11 Apr 2007 16:33:10 +0300 From: =?ISO-8859-1?Q?Uusim=E4ki?= Subject: Re: MicroVAX II chiller theatre Message-ID: <461ce31a$0$31533$9b536df3@news.fv.fi> ChrisQuayle wrote: > Jeff Campbell wrote: > >> The common RD53 spin up and down cycling is almost always due to a >> 'sticky' voice coil actuator arm landing pad. The head slider arm is >> retracted at power down. It rests against a cushioning pad. These pads >> deteriorate with age. If the drive is allowed to sit unused for a while >> the pad will glue itself to the arm. The drive spin up and down cycling >> occurs when the drive spins up to the speed that the heads can be safely >> loaded, but the voice coil servo current limits trying to 'unstick' the >> arm from the landing pad. It stalls and the drive firmware resets and >> tries again... and again... 8-) > > Before you take the lid off, which may be final, lift the disk control > board (2 screws at one end, then the board hinges up) and check the > state of the grounding ball carbon wiper on the spindle. This is > sometimes greased to reduce noise and can dry out over the years, > increasing spindle friction. This causes execessive drive current on the > spindle motor and can result in the motor spinning down. Put a dab of > oil or silicon grease on the carbon wiper, reassemble and try again. > > If this doesn't work, try physically shaking / rotating the drive hard > in the direction of spindle rotation. Pretty extreme, but not so bad as > lifting the cover... > > Chris My colleagues and I have sometimes succeeded to get stuck disks to work by giving them a sharp punch in the side e.g. with a wooden hammer. Explicitely the side which is in 90 degrees angle towards the spindle. Usually the taller side of the cover. I know that this might sound really extreme, but sincerely said this method has worked more than once and never rendered a disk unusable. Kari ------------------------------ Date: Wed, 11 Apr 2007 14:50:28 GMT From: Curtis Rempel Subject: Re: MicroVAX II chiller theatre Message-ID: Chris Scheers wrote: [ snip ] > Assuming that you have a BA23 chassis, the Q-bus is a serpentine bus. I > don't remember for sure where the serpentine starts (I think it is slot > 3), but it weaves up and down between the top and bottom of the slots. > > If you put in a full height board, you don't need to worry about it as > the board should have continuity circuitry for both the top (AB) and > bottom (CD) of the slot. Yep, the RQDX2 is a full height board. > But if you have a half height board alone in a slot (even the last slot > you use), you need to have a grant card in the other half of the slot > (if not the last slot) or make sure the card is in the right part (top > or bottom) if in the last slot. The slot above the RQDX2 has two half height cards, the TQK50 and the DEQNA, both of which are now verified to be working. > The most common failure mode for an RD53 is what I call the spin up/spin > down problem. The RD53 will try to spin up and after about 20 seconds > it is not quite up to speed and then spins itself back down. This may > or may not repeat. I don't hear any evidence of it spinning down. > You mentioned repetitive disk activity. Does this occur in response to > the BOOT command or do you still observe it when waiting at the prompt? In response to the BOOT command. > If at the prompt, the drive is probably spinning itself up and down. > Such a drive needs to be replaced or repaired. > > If the activity is in response to the BOOT command, the drive may be good. I'm still crossing my fingers! > Good luck! and a heavy dose of some arthritic pain reliever after so many times of inserting/removing and clamping/unclamping those boards ... ------------------------------ Date: Wed, 11 Apr 2007 15:02:21 GMT From: Curtis Rempel Subject: Re: MicroVAX II chiller theatre Message-ID: <1M6Th.64963$__3.24367@edtnps90> Jeff Campbell wrote: [ snip ] >>>>> BOOT MUA0 >> >> 2..1..0.. >> >> >> OpenVMS (TM) VAX Version V7.3 Major version id = 1 Minor version >> id = >> 0 >> %WBM-I-WBMINFO Write Bitmap has successfully completed initialization. >> PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 10-APR-2007 19:48 >> >> Configuring devices . . . >> Now configuring HSC, RF, and MSCP-served devices . . . >> >> Please check the names of the devices which have been configured, >> to make sure that ALL remote devices which you intend to use have >> been configured. >> >> If any device does not show up, please take action now to make it >> available. >> >> >> Available device DUA0: device type RD53 >> Available device MUA0: device type TK50 >> >> Enter "YES" when all needed devices are available: YES >> %BACKUP-I-IDENT, Stand-alone BACKUP T7.2; the date is 10-APR-2007 >> 19:50:09.05 >> $ BACKUP/IMAGE DUA0: MUA0:DUA0.BCK/SAVE_SET >> %BACKUP-F-NOINDEXF, no valid index file header found on DUA0: >> -SYSTEM-F-VOLINV, volume is not software enabled >> If you do not want to perform another standalone BACKUP operation, >> use the console to halt the system. >> >> If you do want to perform another standalone BACKUP operation, >> ensure the standalone application volume is online and ready. >> Enter "YES" to continue: >> >> >> So, VMS sees DUA0: alright but complains that it can't back it up. Maybe >> there is nothing on the disk and the disk is actually working after all. >> The same repetitive brief flashing of the Ready light and arm motion >> sounds happen as they do when trying to boot DUA0. > > Glad to see you got this far! 8-) I'm either stubborn or insane I guess ... > The -F- messages from SAB are telling you that the RD53 is not online; > that is, spinning and heads loaded over cylinder zero. SAB tries to read > the index file, but the device is not online to the controller, hence > not enabled. Sounding more like a hardware problem with the drive then I guess. > The common RD53 spin up and down cycling is almost always due to a > 'sticky' voice coil actuator arm landing pad. The head slider arm is > retracted at power down. It rests against a cushioning pad. These pads > deteriorate with age. If the drive is allowed to sit unused for a while > the pad will glue itself to the arm. The drive spin up and down cycling > occurs when the drive spins up to the speed that the heads can be safely > loaded, but the voice coil servo current limits trying to 'unstick' the > arm from the landing pad. It stalls and the drive firmware resets and > tries again... and again... 8-) Hmmm... but it doesn't sound like it is spinning up and down. On power on, it spins up and I don't ever heard it spinning down. Just faint and brief arm movement sounds which are repeated at regular intervals for about a minute or so when issuing a BOOT command or when s/a backup tries to access the drive. If the drive was operating correctly and there was nothing on the drive, I would have expected the BOOT command to produce a message indicating that it could not find a boot block or something like that. Since it takes about a minute for the BOOT command to fail, all the while the drive is repeatedly trying to do something, I think the drive is likely hosed. > Since the drive is otherwise unusable, you might try removing the top > cover and manually unsticking the actuator arm. Interesting as this may sound, I'm not sure it's actually stuck if the drive isn't spinning up/down? Or do you think it's still worth the risk taking off the cover? > I don't think this will violate the warranty... 8-) > >> >> Seems as though the Q-bus is operating correctly now that I moved the >> cards >> up one slot and set the RQDX2 back to factory. The DEQNA works (at least >> as far as to be refused into a cluster) and the TK50 is alive now. VMS >> sees the RD53 via s/a backup so I would think at this point the RD53 is >> either unstructured or has a hardware fault. > > It's also possible the RQDX2 is fubar. Possibly, although I think I'm almost at the end of my adventure here in terms of time and effort. ------------------------------ Date: Wed, 11 Apr 2007 15:31:02 GMT From: Curtis Rempel Subject: Re: MicroVAX II chiller theatre Message-ID: Steven M. Schweda wrote: [ snip ] >> Still am wondering about those two jumpers side by side on the RQDX2 and >> not >> labelled. Can't find any reference to them anywhere. > > Those should be the ones labeled W3 and W4 in the book, which shows > them installed (like W2 and W1, near the A12 jumper). They are both installed. > From: Chris Scheers > >> Assuming that you have a BA23 chassis, the Q-bus is a serpentine bus. I >> don't remember for sure where the serpentine starts (I think it is slot >> 3), but it weaves up and down between the top and bottom of the slots. > > Pay attention: > >> http://antinode.org/dec/qbus_serpentine.html Yes, this should be fine as slots 1-3 are CPU/memory, slot 4 has the two half height cards (TQK50 and DEQNA) and slot 5 is the full height RQDX2. ------------------------------ Date: Wed, 11 Apr 2007 15:43:10 GMT From: Curtis Rempel Subject: Re: MicroVAX II chiller theatre Message-ID: Uusimäki wrote: > ChrisQuayle wrote: [ snip ] >> If this doesn't work, try physically shaking / rotating the drive hard >> in the direction of spindle rotation. Pretty extreme, but not so bad as >> lifting the cover... >> >> Chris > > My colleagues and I have sometimes succeeded to get stuck disks to work > by giving them a sharp punch in the side e.g. with a wooden hammer. > Explicitely the side which is in 90 degrees angle towards the spindle. > Usually the taller side of the cover. > > I know that this might sound really extreme, but sincerely said this > method has worked more than once and never rendered a disk unusable. > > > Kari I've seen a lot of DEC field service tricks, but not that one! I'll put that one at the end of my list and report back if it actually works. :-) ------------------------------ Date: 11 Apr 2007 15:55:52 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: MicroVAX II chiller theatre Message-ID: <584eo8F2f24khU1@mid.individual.net> In article , Curtis Rempel writes: > Uusimäki wrote: > >> ChrisQuayle wrote: > > [ snip ] > >>> If this doesn't work, try physically shaking / rotating the drive hard >>> in the direction of spindle rotation. Pretty extreme, but not so bad as >>> lifting the cover... >>> >>> Chris >> >> My colleagues and I have sometimes succeeded to get stuck disks to work >> by giving them a sharp punch in the side e.g. with a wooden hammer. >> Explicitely the side which is in 90 degrees angle towards the spindle. >> Usually the taller side of the cover. >> >> I know that this might sound really extreme, but sincerely said this >> method has worked more than once and never rendered a disk unusable. >> >> >> Kari > > I've seen a lot of DEC field service tricks, but not that one! I'll put > that one at the end of my list and report back if it actually works. :-) I cabn verify that the method does, in fact, work. However, it only works when the failure is due to "stiction" and based on his description, I don't think that is his problems. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 11 Apr 2007 17:06:30 +0100 From: "R.A.Omond" Subject: Re: MicroVAX II chiller theatre Message-ID: Curtis Rempel wrote: > Anyway, after cleaning the tape path, I decided to boot s/a backup again and > this time it worked (almost): > > >>>>BOOT MUA0 > > > 2..1..0.. > > > OpenVMS (TM) VAX Version V7.3 Major version id = 1 Minor version id = > 0 > %WBM-I-WBMINFO Write Bitmap has successfully completed initialization. > PLEASE ENTER DATE AND TIME (DD-MMM-YYYY HH:MM) 10-APR-2007 19:48 > > Configuring devices . . . > Now configuring HSC, RF, and MSCP-served devices . . . > > Please check the names of the devices which have been configured, > to make sure that ALL remote devices which you intend to use have > been configured. > > If any device does not show up, please take action now to make it > available. > > > Available device DUA0: device type RD53 > Available device MUA0: device type TK50 > > Enter "YES" when all needed devices are available: YES > %BACKUP-I-IDENT, Stand-alone BACKUP T7.2; the date is 10-APR-2007 > 19:50:09.05 > $ BACKUP/IMAGE DUA0: MUA0:DUA0.BCK/SAVE_SET > %BACKUP-F-NOINDEXF, no valid index file header found on DUA0: > -SYSTEM-F-VOLINV, volume is not software enabled > If you do not want to perform another standalone BACKUP operation, > use the console to halt the system. > > If you do want to perform another standalone BACKUP operation, > ensure the standalone application volume is online and ready. > Enter "YES" to continue: > > > So, VMS sees DUA0: alright but complains that it can't back it up. Maybe > there is nothing on the disk and the disk is actually working after all. > The same repetitive brief flashing of the Ready light and arm motion sounds > happen as they do when trying to boot DUA0. > > Seems as though the Q-bus is operating correctly now that I moved the cards > up one slot and set the RQDX2 back to factory. The DEQNA works (at least > as far as to be refused into a cluster) and the TK50 is alive now. VMS > sees the RD53 via s/a backup so I would think at this point the RD53 is > either unstructured or has a hardware fault. > > Are there any diags I could run to figure out which? I don't have any TK50 > diag media. > > If all else fails, I suppose I could just turn it into an academic exercise > (and forego any potential winning lottery numbers on the drive) to see if > the drive is alive by trying to restore something via s/a backup to it and > see what happens. :-) I can't believe noone's mentioned this already. There's probably not a file-system on the RD53. Simple as that. Suggestion: to check if the disk is readable, use BACKUP/PHYSICAL instead of /IMAGE, which can only work if there's a recognised file-system on it. Once you've done that, feel free to overwrite the disk if you can. ------------------------------ Date: Wed, 11 Apr 2007 08:44:37 +0200 From: =?UTF-8?B?SmVhbi1GcmFuw6dvaXMgUGnDqXJvbm5l?= Subject: Re: More bollocks from biggots Message-ID: <461c83ea$0$29100$426a74cc@news.free.fr> [snip] >> [Best] workaround: >> - use XML as transport > > God help us! > The paper don't say that the best workaround is to use a XML representation, it rather suggest as a simple workaround to only respond to post method, not to get method. """ A server can mount a defense against JavaScript Hijacking by responding to only HTTP POST requests and not responding to HTTP GET requests. This is a defensive technique because the