INFO-VAX Sat, 16 Jun 2007 Volume 2007 : Issue 326 Contents: Re: Another opportunity Re: Another opportunity RE: Anyone know why the Alpha market is so so quiet? RE: Anyone know why the Alpha market is so so quiet? Re: Hubble/OpenVMS to continue thru at least 2013 - 23 years! OpenVMS hobbyist license woes Re: OpenVMS hobbyist license woes Re: OpenVMS hobbyist license woes Re: OpenVMS hobbyist license woes Re: Same system disk for multiple architectures ? Re: Same system disk for multiple architectures ? Re: TCPIP Services SFTP Re: TCPIP Services SFTP Re: TCPIP Services SFTP Re: Thanks for the Help Robert ! Re: VMS analogue of FBSD and linux hier(7) man pages Re: Why partitioned disks on VMS would be useful ---------------------------------------------------------------------- Date: Sat, 16 Jun 2007 11:31:11 GMT From: Vance Haemmerle Subject: Re: Another opportunity Message-ID: <3SPci.40736$5j1.3916@newssvr21.news.prodigy.net> david20@alpha2.mdx.ac.uk wrote: > > Version 8.2 and later of OPENVMS don't require the Open3D license for 3D > support and don't support installation of the Open3D layered product which is > probably why it isn't on the hobbyist CD. Unfortunately OpenVMS 8.2 also > dropped support for some graphics cards. > see > http://h71000.www7.hp.com/doc/82FINAL/6674/6674pro_retired.html#retirementch > > and > > http://h71000.www7.hp.com/doc/82FINAL/6674/6674pro_hardware2.html#graphicsboards > > This appears to be another HP development since under COMPAQ and DEC VMS was > well known for it's continued support for decades old hardware with the > latest versions of the OS. > I have a DEC 3000/900 with a ZLX-E2. I guess I'll never go to 8.2. Thanks for pointing this out. ------------------------------ Date: Sat, 16 Jun 2007 05:42:53 -0700 From: Vance Haemmerle Subject: Re: Another opportunity Message-ID: Stephen Hoffman wrote: > Tru64 UNIX retired all DEC 3000 boxes and slews of controllers, which > caused a minor uproar. > What gets me is that the last to support these is Tru64 version 5.1 and only 5.1A and 5.1B have aggregate patch kits. ------------------------------ Date: Sat, 16 Jun 2007 12:27:39 -0400 From: "Main, Kerry" Subject: RE: Anyone know why the Alpha market is so so quiet? Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: June 15, 2007 9:29 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Anyone know why the Alpha market is so so quiet? >=20 > On 06/15/07 18:44, David J Dachtera wrote: > > Dave Froble wrote: > >> John Smith wrote: > >> > >>> 4) What about staff retention - have they mentioned that their > staff may > >>> want to have relevant *marketable* experience with the > technologies that can > >>> get them new jobs if the company downsizes/outsources them? I'm > sure that > >>> has to be in the minds of everyone in the IT divisions except > perhaps the > >>> CIO. > >> I see this argument used all the time. Frankly, I don't understand > it. > >> Is it part of an employer's responsibility to train employees for > >> their next job? > > > > It depends. > > > > Part of keeping good people includes training them to be more and > more > > productive. It's common knowledge that keeping good people is > cheaper and less > > risky than turning staff over just because of technology changes. >=20 > However, replacing a $100,000 employee with "lots of process > knowledge that might not be so useful anymore" with a $60,000 "knows > the new tech" new hire is easier for the employer. >=20 Bottom line question is whether it is easier to train the old employee with new technologies and keep that invaluable experience, or teach the rookie about all of the business, support, app development processes that the Company uses. Since almost all environments requires some interfaces between the old and new applications, teaching the existing employee the new skills is an order of magnitude cheaper than hiring some rookie.=20 Especially if the old-new interfaces are required, because developing these often requires a good understanding of the old environment and the new technologies. And I know it is not to common these days, but I would also ask if the new technologies really add value or is it being driven by hype in the App / EA groups or consultants on board who want to expand their CV's? Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 16 Jun 2007 12:18:12 -0400 From: "Main, Kerry" Subject: RE: Anyone know why the Alpha market is so so quiet? Message-ID: > -----Original Message----- > From: John Smith [mailto:a@nonymous.com] > Sent: June 13, 2007 1:07 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Anyone know why the Alpha market is so so quiet? >=20 > Main, Kerry wrote: > >> -----Original Message----- > >> From: Arne Vajh=F8j [mailto:arne@vajhoej.dk] > >> Sent: June 9, 2007 3:07 PM > >> To: Info-VAX@Mvb.Saic.Com > >> Subject: Re: Anyone know why the Alpha market is so so quiet? > >> > >> Dr. Dweeb wrote: > >>> Main, Kerry wrote: > >>>> As I mentioned earlier, it is not the roll-out of the patches > that > >> is > >>>> the issue. Heck, that is relatively minor as you can even easily > do > >>>> this with all of the Windows security patches. > >>>> > >>>> The big issue by far is the re-certification and testing of > >> important > >>>> business applications with all of the monthly OS security > patches. > >>>> > >>>> For small and some medium businesses with small numbers of users, > >>>> this is not an issue as they simply apply the patch and reboot. > If > >> a > >>>> OS security patch breaks the kernel or an application, then they > >> can > >>>> simply roll-back with minimal impact as the numbers of users are > >> not > >>>> that large. > >>>> > >>>> That is usually not the case with large IT environments with > >> mission > >>>> critical environments. > >> > >>> OK. Just so you guys "get it", here is a real example. > >>> > >>> A system software upgrade is tested and validated. To be deployed > >> at 8 > >>> different sites over a period of 1 year, sheduled deployment > >> determined by > >>> PM downtime of 24*7 manufacturing operations - which by its nature > >> is > >>> planned a long way in advance. > >>> > >>> 2 smaller sites go live before a memory leak rears its ugly head > in > >> a large > >>> site, number 3, crashing the application and stalling part of the > >> factory > >>> shipping processes. The resulting cleanup operation consumes DBA > >> and > >>> sysadmin time at every occurrance and occurs at different > intervals > >>> depending on the transaction volume of the factory - the larger > the > >> factory, > >>> the larger the problem. We are talking daily on a large factory. > >>> > >>> The IT troubleshooters get on the job and isolate the error, > create > >> a simple > >>> reproducer and report it as priority 1 bug to the supplier, who > duly > >> fix it > >>> within 3 days! The IT guys check out the reproducer and the > >> instances of > >>> live code where the problem was evident and verify that the > supplier > >> patch > >>> has indeed solved the problem. > >>> > >>> Q1: Which version of the software was installed at the following 5 > >> sites? > >>> Q:2 When was the software updated at the 3 already installed > sites? > >>> > >>> A1: The broken version. > >>> A2: Never (yet) > >>> > >>> In order to release a systems software upgrade, the entire > >> application must > >>> pass certification. This is an $7B pr. year manufacturing company > - > >> a > >>> houshold name - SOX compliant and accutely aware of the necessity > >> for > >>> application certification before deployment. > >>> > >>> Why you ask? > >>> > >>> Because the cost of bringing a larger factory down completely is > >> like > >>> $50,000 per hour, while the cost of having a DBA cleanup the > stalls > >> is zero, > >>> because he is already sitting there and it is in his job > >> description. The > >>> risk is evaluated, the costs apportioned and the decision made. A > >>> management no-brainer, because the certification requirement and > >> procedures > >>> are very clear and unambiguous. As bizarre as it seems, this is > the > >> daily > >>> life of people who maintain and operate the big iron that controls > >> large > >>> manufacturing - not just that particular site. > >>> > >>> When the application is recertified on the patched vendor > software, > >> the > >>> patch to the vendor software will be applied to the production > >> environment > >>> in a controlled and phased manner - not before. > >>> > >>> Here endeth the lesson in reality for you guys who wouldn't know a > >> real > >>> high-availability corporate production environment if it landed on > >> your > >>> head! > >> > >> But the conclusion is that Kerry arguments against Linux does not > >> hold water. > >> > >> Because if those systems where running Linux - how many security > >> patches would have been installed on them in that period ? > >> > >> Arne > > > > Thank you - you just made my point. > > > > :-) > > > > With 5-20 Linux (and Windows) security patches being released each > > and every month, this company would not get approval from the > > business units to test and apply all these patches against all the > > important apps, so the business would have to risk not being hacked > > with all of these well documented security patches not being > applied. > > > > With 50-60% of all security issues being internal related, that is a > > huge risk. > > > > And think about this in the financial sector with systems running > > billions (and in some OpenVMS systems, trillions) of $'s through > > their systems daily, weekly, monthly. With all of the internal > people > > taking laptops, PDA's back and forth to home, on the road and work > > etc all open for Trojans, worms etc that are looking for systems > with > > documented holes to exploit. > > > > It really blows me away that serious financial institutions can > > justify moving to Linux (Windows) with so many monthly security > > patches being released each and every month. > > > > I can only believe that the managers involved have no idea of the > > security issues their techies or those pushing these platforms are > > exposing the business to. > > > > Personally speaking, I would have to ask "how can these financial > and > > mission critical environments afford these platforms?" >=20 >=20 > So let me ask you these questions about this alleged incredulous > actions by > financial institutions and other bet-your-business companies: >=20 > In your travels and engagements with these organizations, *what* > rationale > have they told you was behind their decision to turf VMS out? >=20 > 1) Does it have anything to do with the fact that certain critical > applications are no longer available or supported on VMS, (eg. SWIFT, > etc....)? >=20 > 2) If their rationales are related to question 1) above, then have > they told > you that since their critical applications or tools aren't available > on VMS, > then they have no choice but to pay the price of patch-of-the-hour > environments. >=20 > 3) Have they told you that it's because HP doesn't convince them that > VMS > has any forseeable future, ie. doubts about VMS & Itanic EOL > scenarios? >=20 > 4) What about staff retention - have they mentioned that their staff > may > want to have relevant *marketable* experience with the technologies > that can > get them new jobs if the company downsizes/outsources them? I'm sure > that > has to be in the minds of everyone in the IT divisions except perhaps > the > CIO. >=20 > 5) Have they told you it's because the CEO keeps reading about Linux > or > Windows doing X, Y & Z applications elsewhere and wonders why his > company > isn't doing the same? >=20 >=20 >=20 > How many of your off-VMS onto-Linux customers have come back to you at > the > end of the migration and said "We never should have switched"? >=20 As someone stated, switching is tough enough, but switching back = typically means someone got fired.=20 Hence, unless the App or security breach is major, you will seldom hear = about all those long nights that the operations and App folks spend = keeping the App environment looking "normal". Not sure about Linux, but I know of a few OpenVMS to Windows to OpenVMS = large accounts. For one, think big military hospitals. Could not deal = with archaic fail-over clustering and so many viruses and security = patches. Also about 18 months ago, a big high profile financial institution went = live on Windows and by noon same day had switched back. Not sure if they = ever tried to flip again or not. Also a manufacturing environment - SCADA with OpenVMS Integrity .. don't = get much more critical than these environments. Here is a link on their = web site (not HP). Reference: http://www.vista-control.com/itanium_success.htm=20 " Los Alamos, February 15th. 2007 After implementing mission-critical = systems on Windows-based computers for many years, a customer = experienced a virus in one of these systems that shut down production = for two days while the infected systems were diagnosed, restored and = tested. The impact was that plant production was severely impacted at no = small cost. Despite internal opposition because of the established = standard, Vsystem on HP Itanium servers running OpenVMS was chosen for = the next system to be replaced." .. " Customers have also proved that the better a production system is = instrumented, the better the plant can be operated, increasing = productivity and quality. In addition, problems can be successfully = diagnosed and corrected when the historian holds an excellent data = record of the period leading up to and through the problem. This = invariably requires that the operating system have excellent determinism = to capture fast data. OpenVMS on Itanium has been proven to meet this = requirement." >=20 > So how about this -- since you've had experience with many of these > situations, --create a no-names list you can post here with the > following > attributes: >=20 So you assume there is some master list or DB somewhere in the universe = that lists this and that I have access to this? [snip..] As I mentioned before, part of the problem is that experienced Techies = and managers are to afraid to speak up and use their experience to ask a = few simple questions about changing. They are to afraid they might get = labelled with the dino label. Bit OT, but issue is related .. Kind of like with SOA, J2EE and .Net = these days .. how many App or techie folks are afraid to ask if these = technologies (with all that OO brings) are really the right direction = for their company?=20 It might be, but few ever ask the tough questions about all the = downsides of these new technologies. Can't ask the tough questions, because who wants the dino label? Better = to keep quiet and jump on the "grass is greener on the other side" = bandwagon.. Course, then years of frustration, blown budgets and all sorts of finger = pointing begins. Ah yes, gotta love the world of corporate politics. :-) Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 16 Jun 2007 06:05:41 -0700 From: Neil Rieck Subject: Re: Hubble/OpenVMS to continue thru at least 2013 - 23 years! Message-ID: <1181999141.069864.301310@q69g2000hsb.googlegroups.com> On Jun 15, 3:09 pm, Mark McIntyre wrote: > [...snip...] > > >>>http://sunset.usc.edu/gsaw/gsaw2004/s7/burch.pdf > Yikes. Even NASA can't afford to support OpenVMS :-) NSR ------------------------------ Date: Sat, 16 Jun 2007 06:45:20 -0700 From: rtk Subject: OpenVMS hobbyist license woes Message-ID: <1182001520.740167.17330@q19g2000prn.googlegroups.com> I have an AlphaServer 1000 4/200 that I am trying to get running again. I registered and got an OpenVMS hobbyist license and purchased the media kit. I run through the install of OpenVMS 7.3 and everything seems fine. I've actually done this twice. The first time I tried entering the license during install and got errors. I then re-installed (doing an initialization of the disk) and did not enter the license during install. I installed everything in the base install except the DECnet stuff as I plan on only using TCP/IP. After the reboot when install is done I logged into the console as SYSTEM and entered the license for OpenVMS _exactly_ as it was given in the email. I got not error message so I thought the license "took". I then rebooted the machine and it went to the DECwindows logon prompt. HOWEVER, if I log on at DECwindows as SYSTEM I get a pop-up message saying the "LMF license check failed" and I'm sent back to the logon screen. Questions: Why won't it let me logon? How do I get to the console (ie, non-DECwindows) logon to fix this without re-installing everything? As background, I used VMSes twenty years ago when in grad school and haven't touched one since and remember very little. If anyone knows of "An Idiot's Guide to OpenVMS" I'd appreciate hearing about it. Thanks! Ron ------------------------------ Date: Sat, 16 Jun 2007 09:12:13 -0500 From: "Craig A. Berry" Subject: Re: OpenVMS hobbyist license woes Message-ID: In article <1182001520.740167.17330@q19g2000prn.googlegroups.com>, rtk wrote: > I have an AlphaServer 1000 4/200 that I am trying to get running > again. I registered and got an OpenVMS hobbyist license and purchased > the media kit. > > I run through the install of OpenVMS 7.3 and everything seems fine. > I've actually done this twice. The first time I tried entering the > license during install and got errors. I then re-installed (doing an > initialization of the disk) and did not enter the license during > install. I installed everything in the base install except the DECnet > stuff as I plan on only using TCP/IP. > > After the reboot when install is done I logged into the console as > SYSTEM and entered the license for OpenVMS _exactly_ as it was given > in the email. I got not error message so I thought the license > "took". I then rebooted the machine and it went to the DECwindows > logon prompt. > > HOWEVER, if I log on at DECwindows as SYSTEM I get a pop-up message > saying the "LMF license check failed" and I'm sent back to the logon > screen. > > Questions: > > Why won't it let me logon? > How do I get to the console (ie, non-DECwindows) logon to fix this > without re-installing everything? > > As background, I used VMSes twenty years ago when in grad school and > haven't touched one since and remember very little. If anyone knows > of "An Idiot's Guide to OpenVMS" I'd appreciate hearing about it. Did you get layered product licenses as well as the base license? There is a bit of a bootstrapping problem in that you can't ftp over the command procedure containing the LICENSE REGISTER commands until you've already installed the license for (at least) TCP/IP and you really don't want to type in the license keys for all 100 or so layered products. You're probably best off booting without DECwindows until you get the license for it installed, then manually registering the PAK for TCP/IP, logging into the console and configuring TCP/IP, then transferring the layered product licenses over. You'll want to read the section in the FAQ on doing a minimum boot for situations just like this where you don't have licenses installed: http://www.hoffmanlabs.net/vmsfaq/vmsfaq_007.html#index_x_454 -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Sat, 16 Jun 2007 09:20:46 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: OpenVMS hobbyist license woes Message-ID: <07061609204663_202003EE@antinode.org> From: rtk > After the reboot when install is done I logged into the console as > SYSTEM and entered the license for OpenVMS _exactly_ as it was given > in the email. I got not error message so I thought the license > "took". I then rebooted the machine and it went to the DECwindows > logon prompt. > > HOWEVER, if I log on at DECwindows as SYSTEM I get a pop-up message > saying the "LMF license check failed" and I'm sent back to the logon > screen. > > Questions: > > Why won't it let me logon? It will let you log in, it just won't let you use DECwindows. No DW-MOTIF license. It's easier if you can just run ("@") that whole e-mail message with all the layered product PAK info. > How do I get to the console (ie, non-DECwindows) logon to fix this > without re-installing everything? You may need to do an interactive boot to let you disable the window system, so you can use the keyboard/graphics display as a "glass tty". A quick Google search for: vms OR openvms sysboot window_system found: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1016971 Skip down to where it says ">>> b -fl 0,1", and go from there, except instead of changing the password, you need to register the DW-MOTIF license. (I think. Only one way to find out.) ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Sat, 16 Jun 2007 10:41:29 -0700 From: rtk Subject: Re: OpenVMS hobbyist license woes Message-ID: <1182015689.431670.46400@e9g2000prf.googlegroups.com> On Jun 16, 8:12 am, "Craig A. Berry" wrote: > You'll want to read the section in the FAQ on doing a minimum boot for > situations just like this where you don't have licenses installed: > > http://www.hoffmanlabs.net/vmsfaq/vmsfaq_007.html#index_x_454 This was helpful. I am at least able to boot w/o DECwindows starting up. I manually entered the license information for DW-MOTIF using LICENSE and got no error. If I do a SHOW LICENSE I get: Product Producer Units Avail Activ Version Release Termination --------------------------------------------------------------------------------------------------------------------------- DW-MOTIF DEC 0 0 100 0.0 (none) 19-JUN-2008 OPENVMS-ALPHA DEC 0 0 A 0.0 (none) 19- JUN-2008 I still get the message on the license check failing when I logon at the DECwindows prompt. Also, I've looked through the license file and I don't see anything obviously related to TCP/IP. I'm sure it is something silly. All help appreciated! Ron ------------------------------ Date: Sat, 16 Jun 2007 10:56:21 +0200 From: Michael Unger Subject: Re: Same system disk for multiple architectures ? Message-ID: <5dhn45F34vdo8U2@mid.individual.net> On 2007-06-15 22:12, "Stephen Hoffman" wrote: > [...] > > Replacing the entire OpenVMS kernel was discussed, and prototyped. > (There's an engineering study that was published, and that is still > around. qv: A Model and Prototype of VMS Using the Mach 3.0 Kernel, the > filename is usually usenix_vms-on-mach.ps.) A lot of the references Google Search lists are unavailable now -- I've finally found that document at Nettverksgruppa [1]. > [...] VMSONE.COM [2] which is listed as well on Google seems to be down currently. Michael [1] [2] -- Real names enhance the probability of getting real answers. My e-mail account at DECUS Munich is no longer valid. ------------------------------ Date: Sat, 16 Jun 2007 12:24:47 +0200 From: "P. Sture" Subject: Re: Same system disk for multiple architectures ? Message-ID: In article <5dhn45F34vdo8U2@mid.individual.net>, Michael Unger wrote: > On 2007-06-15 22:12, "Stephen Hoffman" wrote: > > > [...] > > > > Replacing the entire OpenVMS kernel was discussed, and prototyped. > > (There's an engineering study that was published, and that is still > > around. qv: A Model and Prototype of VMS Using the Mach 3.0 Kernel, the > > filename is usually usenix_vms-on-mach.ps.) > > A lot of the references Google Search lists are unavailable now -- I've > finally found that document at Nettverksgruppa [1]. > > > [...] > > VMSONE.COM [2] which is listed as well on Google seems to be down currently. > > Michael > > [1] > [2] Thanks Michael. For those who can't read .PS files, I've put it up as a .PDF (188KB) at -- Paul Sture ------------------------------ Date: Sat, 16 Jun 2007 09:56:49 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCPIP Services SFTP Message-ID: > >> OK. The session I posted was to my V7.3-2 system with HP TCP/IP Services > >> for OpenVMS Alpha Version V5.4 - ECO 4. I will try this with a newer ver- > >> sion machine later today. Perhaps it's time to update the TCP/IP on this > >> particular machine. > > > >I don't see it with V7.3-2 and a newer ECO. > > Which ECO? I'll try the same and see if that fixes it. I'm at 5.4 ECO 6. I installed it a couple of weeks ago and everything seems to be OK. There is a known bug involving a sharable image (which goes by two different names as well); I saved the ones from ECO 5 and am using them. This is discussed at ITRC and I think has been discussed here. If you can't find it, let me know and I'll post the images involved. It has to do with name resolution NOT via DNS but via the local hosts database. ------------------------------ Date: Sat, 16 Jun 2007 12:24:27 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: TCPIP Services SFTP Message-ID: <%DQci.1$sV1.0@newsfe12.lga> In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > > >> >> OK. The session I posted was to my V7.3-2 system with HP TCP/IP Services >> >> for OpenVMS Alpha Version V5.4 - ECO 4. I will try this with a newer ver- >> >> sion machine later today. Perhaps it's time to update the TCP/IP on this >> >> particular machine. >> > >> >I don't see it with V7.3-2 and a newer ECO. >> >> Which ECO? I'll try the same and see if that fixes it. > >I'm at 5.4 ECO 6. > >I installed it a couple of weeks ago and everything seems to be OK. >There is a known bug involving a sharable image (which goes by two >different names as well); I saved the ones from ECO 5 and am using them. >This is discussed at ITRC and I think has been discussed here. If you >can't find it, let me know and I'll post the images involved. > >It has to do with name resolution NOT via DNS but via the local hosts >database. Oh. It's sooooooo much better now. Now I can't even log in via ssh. -- 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: Sat, 16 Jun 2007 12:49:25 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: TCPIP Services SFTP Message-ID: In article <%DQci.1$sV1.0@newsfe12.lga>, VAXman- @SendSpamHere.ORG writes: > > >In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: >> >> >>> >> OK. The session I posted was to my V7.3-2 system with HP TCP/IP Services >>> >> for OpenVMS Alpha Version V5.4 - ECO 4. I will try this with a newer ver- >>> >> sion machine later today. Perhaps it's time to update the TCP/IP on this >>> >> particular machine. >>> > >>> >I don't see it with V7.3-2 and a newer ECO. >>> >>> Which ECO? I'll try the same and see if that fixes it. >> >>I'm at 5.4 ECO 6. >> >>I installed it a couple of weeks ago and everything seems to be OK. >>There is a known bug involving a sharable image (which goes by two >>different names as well); I saved the ones from ECO 5 and am using them. >>This is discussed at ITRC and I think has been discussed here. If you >>can't find it, let me know and I'll post the images involved. >> >>It has to do with name resolution NOT via DNS but via the local hosts >>database. > >Oh. It's sooooooo much better now. Now I can't even log in via ssh. Nevermind. I searched some logging. New config files. sftp now EXITS when I enter sftp> exit -- 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: Sat, 16 Jun 2007 11:43:55 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Thanks for the Help Robert ! Message-ID: In article <4672fdab$1@flight>, Malcolm Dunnett wrote: > I too had a steep learning curve when I got my first Itanium, but >now that I've played around with them for a while I quite like the >management capabilities. Here's a URL that I guess needs more advertisement: http://docs.hp.com/ You won't find all of HP's documents here, but if you type the model name of any of the Integrity servers (for example rx3600) into the search box, it will return pretty much all of the available manuals for that system. (Along with some junk hits.) Consoles and firmware features are covered fairly well in these manuals. > I'm particularly fond of the remote console capability the MP >board provides, in fact it's the only console I have on them. Agreed. The MP outshines the remote management capabilities of pretty much all the alphas. > One thing I don't like is that if you lose the firmware you don't >have a failsafe loader like the Alphas did, you have to replace >the motherboard. An unfortunate design choice. On recent models, there's a backup ROM for some of the firmware components. Eventually there should be backup ROMs for almost everything. ------------------------------ Date: Sat, 16 Jun 2007 12:06:29 +0200 From: "P. Sture" Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: In article <+T3s37JdA2dP@eisner.encompasserve.org>, cornelius@encompasserve.org (George Cornelius) wrote: > In article , "P. Sture" > writes: > > In article <4670BCDF.3020600@comcast.net>, > > "Richard B. Gilbert" wrote: > >> How long would it take to boot thirteen nodes from the same system disk? > > Don't recall, but then my cluster has been up for awhile: > > View of Cluster from system ID 16604 node: ROSRVX 14-JUN-2007 > 09:46:59 > lqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqqqqklqqqqqqqqqqqqqqqqqqqk > x SYSTEMS x MEMBERS xx CLUSTER x > tqqqqqqqqwqqqqqqqqqqqqqqnqqqqqqqqqutqqqqqqqqqqqqqqqqqqqu > x NODE x SOFTWARE x STATUS xx FORMED x > tqqqqqqqqnqqqqqqqqqqqqqqnqqqqqqqqqutqqqqqqqqqqqqqqqqqqqu > x ROSRVX x VMS V7.3-2 x MEMBER xx 18-JUL-1998 23:22 x > x ROSRVC x VMS V7.3-2 x MEMBER xmqqqqqqqqqqqqqqqqqqqj > x ROSRVB x VMS V7.3-2 x MEMBER x > x ROSRVZ x VMS V7.3-2 x MEMBER x > x ROSRVN x VMS V7.3-2 x MEMBER x > x ROSRVY x VMS V7.3-2 x MEMBER x > x ROSRVM x VMS V7.3-2 x MEMBER x > mqqqqqqqqvqqqqqqqqqqqqqqvqqqqqqqqqj > > [here the boot disk only serves seven nodes]. > > The truth is it takes a long time to boot a single node, but that is > because STARTUP has to mount a _ton_ of FC based shadow sets and there > always seem to be path switches triggered by the mount operations. > I take it you did one or more rolling upgrades to achieve that cluster uptime and get to V7.3-2. > [...] > > > Caveat: before implementing DOSD, a workstation rebooting would initiate > > a full shadow copy. > > You did have volume shadowing licenses for the workstations, and were > setting up a path the the license database in SYLOGICALS, I assume? These workstations were MOP booted from a pair of 4100s. The 4100s had the shadowing licenses. > Or are you talking about the fact that the writes to SYSDUMP.DMP only > go to the original (boot) member, after which a shadow merge is forced > in order to get the shadow members back into synchronization? > That was it. The operator log would contain messages saying something like "shadow master has changed, the dumpfile WILL be written ...". -- Paul Sture ------------------------------ Date: Sat, 16 Jun 2007 15:14:44 +0200 From: "P. Sture" Subject: Re: Why partitioned disks on VMS would be useful Message-ID: In article <5dedvfF354er1U1@mid.individual.net>, Ken Fairfield wrote: > P. Sture wrote: > > In article , > > JF Mezei wrote: > > > >> AEF wrote: > >>> But half of your shadowing benefits are nullified. Normally in a 2- > >>> member shadow set, you can lose either member and you're still up. But > >>> here, if you lose the member with the unshadowed pagefile on it, > >>> you're down anyway! > >> > >> True, but during normal times, you get the performance benefits of > >> having local reads instead of having all your system disk MSCP served > >> from some other node. > > > > A decade or so ago, a former colleague spent a considerable amount of > > time setting up what he called a "Partial Local System Disk" on a large > > fleet of VAXstations. > > > > Simply put, he placed as many system and application objects as possible > > onto each workstation's local disks, using search lists as appropriate. > > This decreased the network bandwidth required to the extent of improved > > response times for a trading application. > > > > But this was in the days of 10Mb/s networks. It's likely not worth that > > amount effort nowadays - think identifying what needs to be updated > > every time a new version of VMS, layered software, or patches comes > > along. > > I did exactly the same thing when I was at SLAC...although I never > gave it a name... :-) One of the joys of working in a large corporate who liked such things ... :-) (as an aside, an anecdote there was the guy who on being asked if he wanted to work on the Taiwan team, asked if he should pack his swimming gear. Nope, Taiwan was just the name of the project.) > There were at least two issues that needed to be addressed. > > First, I needed a (semi-)automatic way to boot these satellites > *without* adding the local disk to SYS$SYSROOT, for instance, when > doing a VMS upgrade. I managed that with a test of the VMS version > string in SATELLITE_PAGE.COM, along with hard-coding whatever version > the local disk's images corresponded to. If the versions didn't > match, the local disk was left out of SYS$SYSROOT. I don't know how this was addressed, but I do remember thinking that identifying which objects were to be replaced was going to be labour intensive. > Second, I needed a not-too-manual method to copy key files from the > system disk to the satellites' local disks. That was just a smallish > bit of DCL that could be copied around and executed from SYSMAN. I had something which sounds similar for propagating stuff around multiple clusters. Special attention needed to be paid to whether stuff was destined for SYS$COMMON or SYS$SPECIFIC. > However, the biggest problem was booting all 30-or-so VAXstations > after an upgrade. Even pacing them in groups of 4 at a time, separated > by 5-10 minbutes, it turned out that "OPCOM storms" were my biggest > problem. :-( Once I got the correct OPC* logicals figured out, that > problem pretty much went away. :-) You have me wondering there... going back to the first upgrade I did to V6.2, a pair of Alphas stopped creating OPERATOR.LOG. It appears that the startup code was changed to say "we've got a graphics head therefore we are a workstation, and don't need operator logs". That would have solved your problem, but in our case, that pair of Alphas were servers where we wanted the logs. > These days, with 100Mb ethernet, I probably wouldn't bother with > all the trouble... > Agreed, although going back to earlier VAX models, the CPU could be a bottleneck for I/O (ACP and RMS processing). -- Paul Sture ------------------------------ End of INFO-VAX 2007.326 ************************