INFO-VAX Sat, 18 Oct 2008 Volume 2008 : Issue 563 Contents: Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: Bypass mount/system request at boot time? Re: DECServer 900 TM User Guide wanted Re: DS10 front access storage cage (3X-BA10B-AA) Re: PC Systems for sale Re: PC Systems for sale ---------------------------------------------------------------------- Date: Sat, 18 Oct 2008 04:39:40 -0700 (PDT) From: AEF Subject: Re: Bypass mount/system request at boot time? Message-ID: <5ab9ded7-8fed-409e-8e0a-dc52d833872e@u75g2000hsf.googlegroups.com> On Oct 15, 4:03 pm, PR wrote: > On Oct 15, 7:29 am, koeh...@eisner.nospam.encompasserve.org (Bob > > Koehler) wrote: > > In article <0f71d7a7-45cf-4f1a-8caa-24a40e8a7...@b31g2000prf.googlegroups.com>, PR writes: > > > > Is there any easy way around this? Will just pulling the drive enable > > > it to bypass? > > > Pulling the drive will cause the mount to fail. If there is > > sufficient error handling in systartup_vms.com, that will do as > > a quick fix from far away. > > > The real fix, of course, would require access to the console. > > > I assume your client doesn't know enough to carry that out for > > you over the phone? > > I was nervous asking them to pull the drive, *after* I powered the > machine off via the MP console. :) > > -Paul Is there some reason JF's solution wouldn't work? You execute a minimum boot, then edit SYSTARTUP_VMS.COM and comment out the command that attempts to MOUNT the messed-up disk, and then reboot normally. You will, of course, have to use a line editor, such as EDT! AEF ------------------------------ Date: Sat, 18 Oct 2008 07:13:42 -0700 (PDT) From: PR Subject: Re: Bypass mount/system request at boot time? Message-ID: <634e7f9c-502b-4099-a7bf-62c72a74dab4@k16g2000hsf.googlegroups.com> On Oct 18, 6:39=A0am, AEF wrote: > On Oct 15, 4:03 pm, PR wrote: > > > > > On Oct 15, 7:29 am, koeh...@eisner.nospam.encompasserve.org (Bob > > > Koehler) wrote: > > > In article <0f71d7a7-45cf-4f1a-8caa-24a40e8a7...@b31g2000prf.googlegr= oups.com>, PR writes: > > > > > Is there any easy way around this? Will just pulling the drive enab= le > > > > it to bypass? > > > > =A0 =A0Pulling the drive will cause the mount to fail. =A0If there is > > > =A0 =A0sufficient error handling in systartup_vms.com, that will do a= s > > > =A0 =A0a quick fix from far away. > > > > =A0 =A0The real fix, of course, would require access to the console. > > > > =A0 =A0I assume your client doesn't know enough to carry that out for > > > =A0 =A0you over the phone? > > > I was nervous asking them to pull the drive, *after* I powered the > > machine off via the MP console. :) > > > -Paul > > Is there some reason JF's solution wouldn't work? > > You execute a minimum boot, then edit SYSTARTUP_VMS.COM and comment > out the command that attempts to MOUNT the messed-up disk, and then > reboot normally. You will, of course, have to use a line editor, such > as EDT! > > AEF No, it would have worked just fine. However: (1) It was getting pretty late at night, this issue popped up at the end of an 17 hour day for me. (2) Doing a conversational boot under IA64 is slightly more complex than under Alphas, and though I had the instructions, it was far easier to have them pull the drive (sqeeze the latch, pull out the lever, and pull gently till it moves 3 inches... :) It was also less prone to error on my part. (3) I was unsure enough of the right way to do this that I asked the folks here, introducing a time delay. I am glad I did by the way. But the bad part is the delay caused the client's frustration level to rise. If I had done the conversational boot 5 minutes after they called, all would have been well. In my defense there, I did not find out the facts for near on 30 minutes; I had never seen a drive fail in such a way as to cause this particular kind of behavior. Either a drive fails and the system bypasses it, or it works. This looked like the drive was working, but the system could not mount it. It did not make sense until I found about the goofball who linux formatted it. By then, *I* was tired and a little confused. :) (4) Pulling the drive involved the client (just a little :) and allowed a near panicked client to feel that they had personally been involved in fixing it. The last point has nothing to do with the technical solution of course, but it never really hurts to help someone feel a bit better. Especially true if that someone is a client. By the way, I took the consensus view here and sent the client a bill yesterday for an hour of time. The offer stands for anyone here who helped; if you would enjoy a six pack of your favorite brew on me, just drop me a private e-mail with your address - or a paypal address to send the cost of a six pack to. Paul ------------------------------ Date: Sat, 18 Oct 2008 14:42:36 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Bypass mount/system request at boot time? Message-ID: <00A81496.B315891F@SendSpamHere.ORG> In article <634e7f9c-502b-4099-a7bf-62c72a74dab4@k16g2000hsf.googlegroups.com>, PR writes: >{...snip...} >(2) Doing a conversational boot under IA64 is slightly more complex >than under Alphas, and though I had the instructions, > it was far easier to have them pull the drive (sqeeze the latch, >pull out the lever, and pull gently till it moves 3 inches... :) Huh? I have aliases established on my Itanium for boot: Shell> alias b : fs0:\efi\vms\vms_loader.efi bo : fs0:\efi\vms\vms_loader.efi boo : fs0:\efi\vms\vms_loader.efi boot : fs0:\efi\vms\vms_loader.efi So booting would be no different than on Alpha: IA64: Shell> boot -flags 0,1 ALpha: >>> boot -flags 0,1 You could probably just define an alias such as 'conboot' to simplify the conversation booting of the Itanium. I have also added items to the boot menu. Each of my 3 drives contain a version of OpenVMS Itanium (V8.2, V8.3 and V8.3-1H1). I have menu items for each version as well as conversational variants. I almost never use them as I have the EFI Shell [Built In] defined first, so the system will always drop to the Shell> prompt. Save for the obnoxious 'chalkboard' color scheme of the Itanium console, I don't find it anymore difficult than that of the Alpha SRM. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Sat, 18 Oct 2008 08:20:09 -0700 (PDT) From: PR Subject: Re: Bypass mount/system request at boot time? Message-ID: On Oct 18, 9:42=A0am, VAXman- @SendSpamHere.ORG wrote: > In article <634e7f9c-502b-4099-a7bf-62c72a74d...@k16g2000hsf.googlegroups= .com>, PR writes: > > >{...snip...} > >(2) Doing a conversational boot under IA64 is slightly more complex > >than under Alphas, and though I had the instructions, > > =A0 =A0 =A0it was far easier to have them pull the drive (sqeeze the la= tch, > >pull out the lever, and pull gently till it moves 3 inches... :) > > Huh? =A0 > > I have aliases established on my Itanium for boot: > > Shell> alias > =A0 =A0 b =A0 =A0: fs0:\efi\vms\vms_loader.efi > =A0 =A0 bo =A0 : fs0:\efi\vms\vms_loader.efi > =A0 =A0 boo =A0: fs0:\efi\vms\vms_loader.efi > =A0 =A0 boot : fs0:\efi\vms\vms_loader.efi > > So booting would be no different than on Alpha: > > IA64: Shell> boot -flags 0,1 > ALpha: >>> boot -flags 0,1 > > You could probably just define an alias such as 'conboot' to simplify the > conversation booting of the Itanium. =A0 > > I have also added items to the boot menu. =A0Each of my 3 drives contain = a > version of OpenVMS Itanium (V8.2, V8.3 and V8.3-1H1). =A0I have menu item= s > for each version as well as conversational variants. =A0I almost never us= e > them as I have the EFI Shell [Built In] defined first, so the system will > always drop to the Shell> prompt. > > Save for the obnoxious 'chalkboard' color scheme of the Itanium console, > I don't find it anymore difficult than that of the Alpha SRM. > > -- > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME= SIS(dot)COM > > ... pejorative statements of opinion are entitled to constitutional prote= ction > no matter how extreme, vituperous, or vigorously expressed they may be. (= NJSC) > > Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article = outside > of usenet _must_ include its contents in its entirety including this copy= right > notice, disclaimer and quotations. Client site Brian- the default boot item in the EFI is to boot the normal VMS system. No operator intervention involved, no other obvious options available. I think I will come up with a boot option to do as you suggest though. I wish there was a way to password protect boot options, then I could label it 'MAINTENANCE LOGIN - PASSWORD REQUIRED' or something like that. You would feel right at home on my development systems though. :) ------------------------------ Date: Sat, 18 Oct 2008 17:27:41 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Bypass mount/system request at boot time? Message-ID: <00A814AD.C27F97D4@SendSpamHere.ORG> In article , PR writes: >On Oct 18, 9:42=A0am, VAXman- @SendSpamHere.ORG wrote: >> In article <634e7f9c-502b-4099-a7bf-62c72a74d...@k16g2000hsf.googlegroups= >..com>, PR writes: >> >> >{...snip...} >> >(2) Doing a conversational boot under IA64 is slightly more complex >> >than under Alphas, and though I had the instructions, >> > =A0 =A0 =A0it was far easier to have them pull the drive (sqeeze the la= >tch, >> >pull out the lever, and pull gently till it moves 3 inches... :) >> >> Huh? =A0 >> >> I have aliases established on my Itanium for boot: >> >> Shell> alias >> =A0 =A0 b =A0 =A0: fs0:\efi\vms\vms_loader.efi >> =A0 =A0 bo =A0 : fs0:\efi\vms\vms_loader.efi >> =A0 =A0 boo =A0: fs0:\efi\vms\vms_loader.efi >> =A0 =A0 boot : fs0:\efi\vms\vms_loader.efi >> >> So booting would be no different than on Alpha: >> >> IA64: Shell> boot -flags 0,1 >> ALpha: >>> boot -flags 0,1 >> >> You could probably just define an alias such as 'conboot' to simplify the >> conversation booting of the Itanium. =A0 >> >> I have also added items to the boot menu. =A0Each of my 3 drives contain = >a >> version of OpenVMS Itanium (V8.2, V8.3 and V8.3-1H1). =A0I have menu item= >s >> for each version as well as conversational variants. =A0I almost never us= >e >> them as I have the EFI Shell [Built In] defined first, so the system will >> always drop to the Shell> prompt. >> >> Save for the obnoxious 'chalkboard' color scheme of the Itanium console, >> I don't find it anymore difficult than that of the Alpha SRM. >> >> -- >> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0 =A0VAXman(at)TME= >SIS(dot)COM >> >> ... pejorative statements of opinion are entitled to constitutional prote= >ction >> no matter how extreme, vituperous, or vigorously expressed they may be. (= >NJSC) >> >> Copr. 2008 Brian Schenkenberger. =A0Publication of _this_ usenet article = >outside >> of usenet _must_ include its contents in its entirety including this copy= >right >> notice, disclaimer and quotations. > >Client site Brian- the default boot item in the EFI is to boot the >normal VMS system. No operator intervention involved, no other obvious >options available. I think I will come up with a boot option to do >as you suggest though. You can add multiple items. The first one is the one that the console times out on and executes. If someone has console access, then, after the initial system checks, the menu would appear. Simply arrow down to the conversation boot and hit enter. This does NOT affect the default boot configuration now in place. >I wish there was a way to password protect boot options, then I could >label it 'MAINTENANCE LOGIN - PASSWORD REQUIRED' or something like >that. > >You would feel right at home on my development systems though. :) OK. Let me at 'em! :D -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ Date: Sat, 18 Oct 2008 05:20:57 -0700 (PDT) From: mancmar@googlemail.com Subject: Re: DECServer 900 TM User Guide wanted Message-ID: <242f0320-c16c-415b-97b5-01358d65dcfb@d1g2000hsg.googlegroups.com> On Oct 17, 8:43=A0pm, syslost wrote: > Does anyone have a link to a user guide for the DECServer 900TM (DSRVZ- > MC) http://vt100.net/manx/ has the installation guide which will explain the basics; most of the 90/900 were basically the same (apart from the 90L !) so the other DECserver manuals may assist I'd have expected them to be available from the http://www.vnetek.com page as I'm fairly sure dnpg hosted the pdfs of most of the manuals before they were merged with Vnetek, but I can't find a link. ------------------------------ Date: Sat, 18 Oct 2008 11:56:39 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: DS10 front access storage cage (3X-BA10B-AA) Message-ID: In article <57SdnUeNlY1pkWTVnZ2dnUVZ_t3inZ2d@comcast.com>, "Richard B. Gilbert" writes: > > Just today, I saw a sign advertising a 1-TB USB drive for EUR 99.95. > > Yes, but does it work with VAX/Alpha/Itanic VMS? Since it's USB, my guess is at most Itanium, but since that is "industry-standard" OF COURSE it will work. :-| ------------------------------ Date: Sat, 18 Oct 2008 04:24:52 -0700 (PDT) From: urbancamo Subject: Re: PC Systems for sale Message-ID: <43d9c7dc-0d01-466c-8249-01cfc18c46f5@l77g2000hse.googlegroups.com> Well, I normally don't take the bait on discussions like this - I tend to sit back and just have a good laugh. There seems to be precious little of the 'best tool for the job' mentality. This applies in every decision that an adult makes. In the working world it is an unfortunate reality that we don't always get the choose the most productive environment and tools for us as individuals. As an example, I use a sun thin client to connect to a sun server, then start an RDP session onto a Windows box. This is where the development tools are installed that I am expected to use. From my position, I'd rather develop under UNIX, because the UNIX toolset is familiar to me and designed for an experience user. However, from a company perspective, their normal users have been exposed primarily to Windows. I understand that there are sound business reasons for them to use Windows for non-development office staff. It's my job to convince them that the benefits of our team using UNIX to develop under outweigh the disadvantages. Windows is the environment of choice for most companies simply because it is the dominant operating system, and therefore requires the least investment in retraining. More companies are appreciating however that Linux is now significantly closer in terms of the user interaction experience and toolset (OpenOffice/StarOffice) for office workers that the cost of retraining is low enough to make the other benefits (stability, manageability, etc) outweigh the disadvantages. The increasing use of open source software also allows companies to switch between environments without loosing functionality. For example, as most development tools I use run on a Java platform I can happily switch between Windows and Linux with very little disruption. The problem I see from the OpenVMS perspective is that open source development has left the platform behind. I believe the reason for this is the same reason why most computers have an Intel x86 processor. I think we've just gone too far now to reach a critical mass where there is enough open source software ported to OpenVMS to get users back on. Specialized use is an entirely different scenario. If you want a server with excellent stability and security then OpenVMS is a good choice. In my spare time I primarily use Linux and OpenVMS. I have two options. I can use my Linux box as a desktop and remotely display my OpenVMS desktop, or use the OpenVMS box directly. However, as the ZX6000 I use does not support DVI I tend to use my Linux box as a desktop because the display is much crisper. I also note that I guess what I'm trying to say here that everyone on this list probably has their own set of requirements and I don't see arguing about them is getting us anywhere. I struggle enough with my own conflicting requirements. I love DEC kit and OpenVMS because I have history with them and appreciate them both as fine examples of engineering. However, I have to support a family and that means working with operating systems and hardware that I consider inferior. Mark. p.s. I got caught by the OpenVMS relicensing issue the other day. As I only had a VT terminal at hand I typed the values in by hand. No big deal. I love command line interfaces as they can be much more productive for experienced users. I worked on a GUI replacement for a call centre application and the reason was not productivity but ease of training. The experienced users of the green screen application were phenomenally quick as was the application. The GUI replacement was incredibly slow and frustrating for the experienced users. At the end of the day, however, the replacement remained because it took 3 months training to get up to speed with the GUI app and a year with the green screen app. The average employment duration of an operative had dropped from ten years to three years, so a year of training was just too costly. ------------------------------ Date: Sat, 18 Oct 2008 11:47:26 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: PC Systems for sale Message-ID: <00A8147E.3A19B09D@SendSpamHere.ORG> In article <43d9c7dc-0d01-466c-8249-01cfc18c46f5@l77g2000hse.googlegroups.com>, urbancamo writes: >Well, I normally don't take the bait on discussions like this - I tend >to sit back and just have a good laugh. >There seems to be precious little of the 'best tool for the job' >mentality. This applies in every decision that an adult makes. You're one of the placid flock then. >In the working world it is an unfortunate reality that we don't always >get the choose the most productive environment and tools for us as >individuals. As an example, I use a sun thin client to connect to a >sun server, then start an RDP session onto a Windows box. This is >where the development tools are installed that I am expected to use. >From my position, I'd rather develop under UNIX, because the UNIX >toolset is familiar to me and designed for an experience user. >However, from a company perspective, their normal users have been >exposed primarily to Windows. I understand that there are sound >business reasons for them to use Windows for non-development office >staff. It's my job to convince them that the benefits of our team >using UNIX to develop under outweigh the disadvantages. > >Windows is the environment of choice for most companies simply because >it is the dominant operating system, and therefore requires the least >investment in retraining. More companies are appreciating however that >Linux is now significantly closer in terms of the user interaction >experience and toolset (OpenOffice/StarOffice) for office workers that >the cost of retraining is low enough to make the other benefits >(stability, manageability, etc) outweigh the disadvantages. The >increasing use of open source software also allows companies to switch >between environments without loosing functionality. For example, as >most development tools I use run on a Java platform I can happily >switch between Windows and Linux with very little disruption. The self-fulfilling prophecy and profit-sea arguments again. Yawn. >The problem I see from the OpenVMS perspective is that open source >development has left the platform behind. I believe the reason for >this is the same reason why most computers have an Intel x86 >processor. I think we've just gone too far now to reach a critical >mass where there is enough open source software ported to OpenVMS to >get users back on. Open source is not *open* source. >Specialized use is an entirely different scenario. If you want a >server with excellent stability and security then OpenVMS is a good >choice. > >In my spare time I primarily use Linux and OpenVMS. I have two >options. I can use my Linux box as a desktop and remotely display my >OpenVMS desktop, or use the OpenVMS box directly. However, as the >ZX6000 I use does not support DVI I tend to use my Linux box as a >desktop because the display is much crisper. I also note that > >I guess what I'm trying to say here that everyone on this list >probably has their own set of requirements and I don't see arguing >about them is getting us anywhere. I struggle enough with my own >conflicting requirements. I love DEC kit and OpenVMS because I have >history with them and appreciate them both as fine examples of >engineering. However, I have to support a family and that means >working with operating systems and hardware that I consider inferior. Use what you will. I just don't think comp.os.vms should be the bill- board for sleazy Micro$oft warez and those pandering for it. >p.s. I got caught by the OpenVMS relicensing issue the other day. As I >only had a VT terminal at hand I typed the values in by hand. No big >deal. I love command line interfaces as they can be much more >productive for experienced users. The VMS PAK thing is nothing. The same BS is used in Weendoze too. I haven't seen anyone complain about needing another machine to enter the gobbledegook that is a Weendoze license checksum. >I worked on a GUI replacement for a call centre application and the >reason was not productivity but ease of training. The experienced >users of the green screen application were phenomenally quick as was >the application. The GUI replacement was incredibly slow and >frustrating for the experienced users. At the end of the day, however, >the replacement remained because it took 3 months training to get up >to speed with the GUI app and a year with the green screen app. The >average employment duration of an operative had dropped from ten years >to three years, so a year of training was just too costly. That's an app. I don't see how a poorly designed or well designed app correlates to VMS. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM ... pejorative statements of opinion are entitled to constitutional protection no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC) Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside of usenet _must_ include its contents in its entirety including this copyright notice, disclaimer and quotations. ------------------------------ End of INFO-VAX 2008.563 ************************