INFO-VAX Tue, 14 Aug 2007 Volume 2007 : Issue 444 Contents: Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Alpha/Integrity Dead Pool Re: Backup save set compression Re: Backup save set compression Re: Backup save set compression Re: Backup save set compression Re: Backup save set compression Re: Computerworld article Re: Computerworld article Re: Computerworld article DS10L suddenly cannot get to the SRM prompt In stock - Hobbyist DS20e systems Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? MACRO port Re: MACRO port Re: MACRO port Re: MACRO port Re: MACRO port Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Node & Port allocation classes on a new cluster Re: Oldest Alpha for upgrade to Integrity Re: Oldest Alpha for upgrade to Integrity PCI slots on an ES40 Re: PCI slots on an ES40 Re: PCI slots on an ES40 Re: PCI slots on an ES40 Re: PCI slots on an ES40 Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: X Window Servers ---------------------------------------------------------------------- Date: 14 Aug 2007 12:06:13 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Alpha/Integrity Dead Pool Message-ID: <5idk5lF3ol7n2U1@mid.individual.net> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article , "FredK" writes: >> >> Fortunately, lots of people are buying them. Intel and HP have committed to >> Itanium long term. HP-UX, VMS and NSK are committed to Itanium. MS and >> Windows are committed to it. We have a strong Linux program for Integrity. > > A commitment from MS isn't worth the Word document it's written in. That's funny. I can't recall MS ever killing a product that was on a long range schedule for development. Unlike some other company I can think of who killed their main product while they had people out in the field telling people about it's long range plans and that no\ one was going to be able to catch up to it anyway. 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: Tue, 14 Aug 2007 09:26:18 -0400 From: JF Mezei Subject: Re: Alpha/Integrity Dead Pool Message-ID: <10add$46c1ad7d$cef8887a$30187@TEKSAVVY.COM> Main, Kerry wrote: > I am not saying this did not occur as I also know of incidents like this, but lets face it - when you are dealing with large companies, unless you ask for an official response in writing, depending on which BU the person you are talking to belongs to, you will get a slightly different view of the universe. You had it correctly a few days ago, but you are back to having one long line per paragraph instead of a line for each line of text. Why did you change it back to the bad config when you had it right at one point ? manually quoting you: > As Fred stated, lots of companies are buying Integrity because the >bottom line is that the 3 year maint savings alone is often enough to >pay the migration and porting costs. The people for whom the migration costs are low enough to justify the move to that IA64 thing right away is a subset of the remaining VMS installed base: Those for whom it makes sense. One still needs to do due diligence to find out if your migration costs are lower than the maintenance savings. It isn't a given that this applies to all customers. And you're not going to see IA64 sales for customers for whom the migration currently doesn't make sense. ------------------------------ Date: Tue, 14 Aug 2007 09:37:25 -0400 From: "FredK" Subject: Re: Alpha/Integrity Dead Pool Message-ID: "Phillip Helbig---remove CLOTHES to reply" wrote in message news:f9q78i$u66$3@online.de... > In article , "FredK" > writes: > >> Fortunately, lots of people are buying them. Intel and HP have committed >> to >> Itanium long term. HP-UX, VMS and NSK are committed to Itanium. MS and >> Windows are committed to it. We have a strong Linux program for >> Integrity. > > Not to doubt you for a moment, Fred, but it IS difficult to explain how > that commitment differs from commitments to ALPHA which were not > realised. > > When I started out with VMS, 15 years ago, people said there is no > future in that. I now have a VMS job, making more money than those > nay-sayers are making now. I personally plan to stay with VMS at home > until I die (perhaps even longer) and probably have enough spare > hardware to realise this. > > Personally, I think that VMS will be around in a form which is usable > for me for as long as I need it (which, sadly, might not be true for all > compilers). > > For many folks, it's like my experience at CeBit (largest computer fair > in the world) back around 1995 or so. Official Digital representatives > there said stuff like "this isn't VMS; this is high-end stuff; this is > unix" (referring to a simulation/game running on some ALPHAservers) and > said that "VMS isn't being developed anymore within DEC". I mentioned > that in this newsgroup and someone from DEC actually rang me up and > apologised. I accepted the apology and am still working with VMS, but > how many people have DIGITAL EMPLOYEES (not to mention Compaq or HP > employees) turned away from VMS through comments like this? > OK. Lengthy post follows. It does not represent any opinion other than my own. Time has moved on. We aren't DEC. We aren't Compaq. We are part of HP. The execs that were running either of the companies are mostly gone. In the late 80's the RISC revolution left the VAX in the dust, and almost killed VMS. It took too long to come up with the nVAX or anything that could compete in performance. The switch to Alpha was costly - but was the realization that the VAX architecture trapped us performance wise. There are people who are happily and unhappily trapped on VAX - but there was little choice but to get past the VAX limitations. Along the way, all the smart people saw the growth curves of UNIX and then NT as showing how they would consume the market - and they all wanted to catch the sales curves. Were they right? Well, in general - yes - the market did mostly go to UNIX, then to Windows, and now bleeding a little into the "New UNIX" (Linux). Windows *owns* the desktop market. The UNIX workstation market collapsed. Was DEC wrong to have "blinked" instead of making an even stronger committment to VMS? Good question for a discussion over a beer - but it is just speculation and "what if's". But the shift to UNIX and Windows didn't make VMS go away - because so far they have not yet caught VMS in certain aspects - especially where high-reliability was concerned - and because of a large and sucessful customer base who rely on its features. The only thing that will cause VMS to go away, is if customers simply stop buying new VMS systems to a point that it isn't profitable to keep an engineering group around. Pretty simple. Right now we are on the "X" where curves for Alpha (going away) and Integrity are crossing - and no amount of wishing will change the direction of Alpha - or the choice of Itanium. The switch to IPF was the realization that investment in chip FABs was too high to be sustained by individual computer companies in the long run. Now, the pocket protector set can complain about EPIC. With little doubt IPF was initially very disappointing performance wise. A case can be made that in retrospect, the 64-bit x86 might have been a better choice for VMS - but it wasn't a choice when the decision was made. Nor is it a reasonable choice for big-endian UNIX implementations and user bases. But we are in late 2007. IPF performance is in general more than adequate for most of the customer base as an Alpha replacement. In fact, performance of CPUs in general seems to have hit a wall at the current transistor sizes and power - and you see a general shift to multi-cores and multi-threads (which makes life interesting, because software and programmers still have yet to find ways to exploit parallelism simply and automatically) across every architecture. Today we have a very solid set of Integrity servers that provide the same and better levels of performance and reliability as the Alpha for most workloads, and the systems in the labs (and changes to specific VMS bottlenecks left over from the initial port) continue to remove the use of the word "most" in this sentence. The hardware is cheaper, and if you take advantage of Alpha Retain Trust to trade in your licenses - it is a very, very attractive upgrade. I hear less uncertaintly or concern from customers I directly deal with, than from hobbiests like JF - who don't have an iron in the fire. JF has things exactly backwards regarding the "future" of VMS and how to get the attention of management in a positive way. If you want to make a statement that management will sit up and take notice of - buy an Itanium server. Nothing gets noticed more than a "spike" in the growth curve. ------------------------------ Date: 14 Aug 2007 14:39:57 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Alpha/Integrity Dead Pool Message-ID: <5idt5tF3ndgt0U1@mid.individual.net> In article , "FredK" writes: > > But we are in late 2007. IPF performance is in general more than adequate Hmmm..... So "in general more than adequate" is an acceptable level? Ok everyone, jump on the Unix bandwagon cause the industry has long ago decided it is "in general more than adequate"!! :-) Fred, you should go into politics or sales. You can paint a rosy picture no matter how bad a decision is. 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: Tue, 14 Aug 2007 11:20:54 -0400 From: "FredK" Subject: Re: Alpha/Integrity Dead Pool Message-ID: "Bill Gunshannon" wrote in message news:5idt5tF3ndgt0U1@mid.individual.net... > In article , > "FredK" writes: >> >> But we are in late 2007. IPF performance is in general more than >> adequate > > Hmmm..... So "in general more than adequate" is an acceptable level? Sure, for various definitions of acceptable. Specific Alphas still have specific advantages in specific uses. Customers maxing out a GS1280 may or may not see better performance on a SuperDome depending on *why* they are maxing out the GS1280. A customer doing some very specific IO workload on an ES45 might not get a gain from an ES47 or an Integrity server because the ES45 was a PIO monster performer. So. Your milage may vary - today. But the need to hedge performance claims across the board is rapidly declining as the HW gets faster, and as VMS goes back and addresses performance problems in our port. > Fred, you should go into politics or sales. You can paint a rosy > picture no matter how bad a decision is. > Couldn't stand pre-sales, let alone sales. Couldn't do politics because I would not be able to try to please everyone all the time - despite the accusation. I could sit here and whine about many decisions I disagreed with in the 28 years that I worked for DEC/Compaq and now HP - heck VWS kicked X11's butt. Sometimes I was right, sometimes I was wrong. But I don't have a way-back machine, and I don't have a magic wand. Dwelling on "what if" is great over a beer - but except for venting it isn't productive. Some people here want to dwell on decisions that have been made a long time ago - that in *this* reality are not going to be revisited or undone. Some of the decisions have been painful to a lot of people. But as they say - it is what it is. We are here. We have a new management team. We have specific givens. The givens aren't as bad as the nay-sayers would like to believe and actually quite good in most respects. If you've decided you can't trust HP about VMS or Integrity, then there is probably very little we or I can do to change your mind. From my viewpoint, HP seems to be prepared to keep investing in VMS as long as there is a profitable business in doing so - no religion - and the investment will be a direct reflection on how well VMS continues to sell. They don't do general advertising for BCS hardware - but VMS is included in the things we do - like the Bullet Proof video. Integrity is high quality, and outperforms most Alpha configurations today, and will only get faster, more powerful and cheaper (and I've seen both the Intel and HP roadmaps). HP has bet the BCS chunk of their business on IPF, and Intel has invested a lot of money in a roadmap to the high-end server space. Stay with VAX. Stay with Alpha. We'll support you until the alpha particles finally kill all the chips. They were both great for their times. If you want to stay with VMS in the future - Integrity is the future - and for the most part there is no reason to try and figure out how to keep a DS15 alive forever because FUD from people like JF has scared you off from moving to Integrity. So, with that I am done "debating" the issue. Take what I write as you wish. I have tried to shut up and just work. And with that... I return to work (a writeup on a customer who is making plans to move to Integrity and what their long term needs are, and then back to coding up some new VMS features). ------------------------------ Date: Tue, 14 Aug 2007 11:55:14 +0200 From: "P. Sture" Subject: Re: Backup save set compression Message-ID: In article , "Scott Greig" wrote: > Hello all: > > The Alpha 8.3 patch site lists a new Backup patch > (VMS83A_BACKUP-V0300) that describes a fix > for a problem concerning the use of the /Journal > switch and the /Data_Format=Compressed switch. > > The /Data_Format switch???!!!??? > > So, I tried it out - and achieved a 67% compression > rate for the output save set (138087 blocks with > compression, 412461 blocks without.) > > HELP BACKUP does not mention this switch. > > My question - when was this implemented, and > how reliable is the output save set? > It's described in Guy Peleg's presentations available at http://deathrow.vistech.net/ The links are in the paragraph titled "Getting the most out of OpenVMS 8.3" -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Tue, 14 Aug 2007 14:02:33 +0300 From: "Guy Peleg" Subject: Re: Backup save set compression Message-ID: <46c17fb5$0$16340$88260bb3@free.teranews.com> "Scott Greig" wrote in message news:f9pru1$2gei$1@sxnews1.qg.com... > Hello all: > > The Alpha 8.3 patch site lists a new Backup patch > (VMS83A_BACKUP-V0300) that describes a fix > for a problem concerning the use of the /Journal > switch and the /Data_Format=Compressed switch. > > The /Data_Format switch???!!!??? This is a mistake. /DATA_FORMAT=COMPRESS should not have been documented. It is very reliable, and as mentioned by Ian, it uses ZLIB as the compression engine. It has one major limitation, it can only compress savesets when writing to disks. Writing compressed savesets to Tapes is not supported. .... and AFAIK, VMS engineering use it. > > So, I tried it out - and achieved a 67% compression > rate for the output save set (138087 blocks with > compression, 412461 blocks without.) > > HELP BACKUP does not mention this switch. > > My question - when was this implemented, and > how reliable is the output save set? Introduced with OpenVMS V8.3. It's an undocumented feature....use it at your own risk. > > Cheers, > Scott > > > -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Tue, 14 Aug 2007 13:23:37 -0400 From: "Scott Greig" Subject: Re: Backup save set compression Message-ID: "Guy Peleg" wrote in message news:46c17fb5$0$16340$88260bb3@free.teranews.com... > > "Scott Greig" wrote in message > news:f9pru1$2gei$1@sxnews1.qg.com... >> Hello all: >> >> The Alpha 8.3 patch site lists a new Backup patch >> (VMS83A_BACKUP-V0300) that describes a fix >> for a problem concerning the use of the /Journal >> switch and the /Data_Format=Compressed switch. >> >> The /Data_Format switch???!!!??? > > This is a mistake. /DATA_FORMAT=COMPRESS should not have been > documented. It is very reliable, and as mentioned by Ian, it uses > ZLIB as the compression engine. It has one major limitation, it can > only compress savesets when writing to disks. Writing compressed savesets > to Tapes is not supported. Further to this - it seems that I cannot even $ COPY the saveset to a tape - I get $ dir/fu sys$sysdevice:[000000]qq.bck Directory SYS$SYSDEVICE:[000000] QQ.BCK;1 File ID: (6180,230,0) Size: 8364/8365 Owner: [1,1] Created: 14-AUG-2007 11:18:28.79 Revised: 14-AUG-2007 11:18:37.99 (1) Expires: Backup: Effective: Recording: Accessed: Attributes: Modified: Linkcount: 1 File organization: Sequential Shelved state: Online Caching attribute: No_caching File attributes: Allocation: 8365, Extend: 0, Global buffer count: 0 No version limit Record format: Variable length, maximum 32256 bytes, longest 32256 bytes Record attributes: None RMS attributes: None Journaling enabled: None File protection: System:RWED, Owner:RWED, Group:, World: Access Cntrl List: None Client attributes: None Total of 1 file, 8364/8365 blocks. $ init mka600: save/media=compact $ mount mka600: save/media=compact %MOUNT-I-MOUNTED, SAVE mounted on _GEMAXP$MKA600: $ copy sys$sysdevice:[000000]qq.bck mka600:/log %COPY-E-OPENOUT, error opening MKA600:[SCOTT.CLIENTS.DND]QQ.BCK;1 as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-BADATTRIB, bad attribute control list %COPY-W-NOTCOPIED, SYS$SYSDEVICE:[000000]QQ.BCK;1 not copied What's wrong here? Scott > > .... and AFAIK, VMS engineering use it. >> >> So, I tried it out - and achieved a 67% compression >> rate for the output save set (138087 blocks with >> compression, 412461 blocks without.) >> >> HELP BACKUP does not mention this switch. >> >> My question - when was this implemented, and >> how reliable is the output save set? > > Introduced with OpenVMS V8.3. It's an undocumented > feature....use it at your own risk. > >> >> Cheers, >> Scott >> >> >> > > > > -- > Posted via a free Usenet account from http://www.teranews.com > ------------------------------ Date: Tue, 14 Aug 2007 12:31:50 -0500 From: Ron Johnson Subject: Re: Backup save set compression Message-ID: On 08/14/07 06:02, Guy Peleg wrote: > "Scott Greig" wrote in message > news:f9pru1$2gei$1@sxnews1.qg.com... >> Hello all: >> >> The Alpha 8.3 patch site lists a new Backup patch >> (VMS83A_BACKUP-V0300) that describes a fix >> for a problem concerning the use of the /Journal >> switch and the /Data_Format=Compressed switch. >> >> The /Data_Format switch???!!!??? > > This is a mistake. /DATA_FORMAT=COMPRESS should not have been > documented. Why not? > It is very reliable, and as mentioned by Ian, it uses > ZLIB as the compression engine. It has one major limitation, it can > only compress savesets when writing to disks. Writing compressed savesets > to Tapes is not supported. That makes sense... -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Tue, 14 Aug 2007 19:35:58 +0200 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: Backup save set compression Message-ID: <46c1e7ff$0$241$e4fe514c@news.xs4all.nl> > What's wrong here? There's probably a record of less than 14 bytes in lenght in the file, and the VMS i/o subsystems rejects that for tapes. And yes, that's documented. Talking about data compression, there's a big gotcha when you use it. If you create a compressed saveset on disk, and copy it to another system with ftp (binary copy), and copy it back you can't restore it. The records for a compressed saveset are now variable length, and ftp has a problem with that in binary mode. And if you use text mode you will get a problem for sure. Also, after restoring, backup/repair does not know how to handle compressed savesets. I ended up doing a 'set file/attr=(rfm=fix,rat=none,mrs=512,lrl=512)' on the saveset before copying, and a 'set file/attr=(rfm=var,rat=none,mrs=32256,lrl=32256)' when I want to restore it. I found this out when testing backup procedures. You see, anyone can create a backup, but restoring is another art. Testing if you can reaaly restore it may pay off! Jur. Scott Greig wrote: > "Guy Peleg" wrote in message > news:46c17fb5$0$16340$88260bb3@free.teranews.com... >> "Scott Greig" wrote in message >> news:f9pru1$2gei$1@sxnews1.qg.com... >>> Hello all: >>> >>> The Alpha 8.3 patch site lists a new Backup patch >>> (VMS83A_BACKUP-V0300) that describes a fix >>> for a problem concerning the use of the /Journal >>> switch and the /Data_Format=Compressed switch. >>> >>> The /Data_Format switch???!!!??? >> This is a mistake. /DATA_FORMAT=COMPRESS should not have been >> documented. It is very reliable, and as mentioned by Ian, it uses >> ZLIB as the compression engine. It has one major limitation, it can >> only compress savesets when writing to disks. Writing compressed savesets >> to Tapes is not supported. > > Further to this - it seems that I cannot even $ COPY the saveset > to a tape - I get > > $ dir/fu sys$sysdevice:[000000]qq.bck > Directory SYS$SYSDEVICE:[000000] > QQ.BCK;1 File ID: (6180,230,0) > Size: 8364/8365 Owner: [1,1] > Created: 14-AUG-2007 11:18:28.79 > Revised: 14-AUG-2007 11:18:37.99 (1) > Expires: > Backup: > Effective: > Recording: > Accessed: > Attributes: > Modified: > Linkcount: 1 > File organization: Sequential > Shelved state: Online > Caching attribute: No_caching > File attributes: Allocation: 8365, Extend: 0, Global buffer count: 0 > No version limit > Record format: Variable length, maximum 32256 bytes, longest 32256 bytes > Record attributes: None > RMS attributes: None > Journaling enabled: None > File protection: System:RWED, Owner:RWED, Group:, World: > Access Cntrl List: None > Client attributes: None > Total of 1 file, 8364/8365 blocks. > $ init mka600: save/media=compact > $ mount mka600: save/media=compact > %MOUNT-I-MOUNTED, SAVE mounted on _GEMAXP$MKA600: > $ copy sys$sysdevice:[000000]qq.bck mka600:/log > %COPY-E-OPENOUT, error opening MKA600:[SCOTT.CLIENTS.DND]QQ.BCK;1 as output > -RMS-E-CRE, ACP file create failed > -SYSTEM-F-BADATTRIB, bad attribute control list > %COPY-W-NOTCOPIED, SYS$SYSDEVICE:[000000]QQ.BCK;1 not copied > > What's wrong here? > > Scott > >> .... and AFAIK, VMS engineering use it. >>> So, I tried it out - and achieved a 67% compression >>> rate for the output save set (138087 blocks with >>> compression, 412461 blocks without.) >>> >>> HELP BACKUP does not mention this switch. >>> >>> My question - when was this implemented, and >>> how reliable is the output save set? >> Introduced with OpenVMS V8.3. It's an undocumented >> feature....use it at your own risk. >> >>> Cheers, >>> Scott >>> >>> >>> >> >> >> -- >> Posted via a free Usenet account from http://www.teranews.com >> > > ------------------------------ Date: 14 Aug 2007 07:45:42 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Computerworld article Message-ID: In article <1y6wi.86$1E1.62@newsfe12.lga>, VAXman- @SendSpamHere.ORG writes: > > http://tmesis.com/drat.html Is that the real Marvin, or just an bored Elvis impersonator? ------------------------------ Date: Tue, 14 Aug 2007 13:14:37 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Computerworld article Message-ID: <1Vhwi.7$vd7.0@newsfe12.lga> In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > >In article <1y6wi.86$1E1.62@newsfe12.lga>, VAXman- @SendSpamHere.ORG writes: >> >> http://tmesis.com/drat.html > > Is that the real Marvin, or just an bored Elvis impersonator? :D It's a link to a site chock full of Marvin the Martian .WAVs so I would assume they were collected from the classic cartoons. Marvin is sort of a poke at an old college buddy of mine (and best man at my wedding) who had a voice just like MtM! I've had a lot of interesting friends during my tenure on this spinning and revolving glob of stellar effluent. FYI, this 'leach' is an old friend of mine. http://tmesis.com/leach.html -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: 14 Aug 2007 12:30:52 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Computerworld article Message-ID: In article <1Vhwi.7$vd7.0@newsfe12.lga>, VAXman- @SendSpamHere.ORG writes: > It's a link to a site chock full of Marvin the Martian .WAVs so I would > assume they were collected from the classic cartoons. Marvin is sort of > a poke at an old college buddy of mine (and best man at my wedding) who > had a voice just like MtM! I've had a lot of interesting friends during > my tenure on this spinning and revolving glob of stellar effluent. Yeah, the first site I found doing a Google search had those .WAVs and I found that sound on it. It looks legit. ------------------------------ Date: Tue, 14 Aug 2007 14:12:33 +0100 From: Anton Shterenlikht Subject: DS10L suddenly cannot get to the SRM prompt Message-ID: <20070814131233.GA50468@mech-aslap33.men.bris.ac.uk> I've used this ds10l with little problems for some time. It has a scsi disk, version 7.3 firmware and I run freebsd on it (the single point of failure cluster frontend). I noticed that something was wrong when I could not use it's com1 (rmc) port for connecting to another ds10l with cu. I could not get rid of /dev/cuad0: device busy. I tried to restart this ds10l and now I get stuck at the power-up sequence: RMC>reset Returning to COM port *** keyboard not plugged in... 1024 Meg of system memory probing hose 0, PCI probing PCI-to-ISA bridge, bus 1 bus 0, slot 9 -- ewa -- DE500-BA Network Controller bus 0, slot 11 -- ewb -- DE500-BA Network Controller bus 0, slot 13 -- dqa -- Acer Labs M1543C IDE bus 0, slot 13 -- dqb -- Acer Labs M1543C IDE bus 0, slot 17 -- pka -- NCR 53C895 initializing GCT/FRU at 3ff40000 The system does not move beyond this point. Can this be some sort of hardware failure? the RMC status does not indicate any problems: PLATFORM STATUS ⌡0mFirmware Revision: V1.1 Server Power: ON RMC Halt: Deasserted RMC Power Control: ON Power Supply: OK System Fans: OK CPU Fan: OK Temperature: 40.0╟C⌡0m (warnings at 55.0╟C, power-off at 60.0╟C) Escape Sequence: ^[^[RMC Remote Access: Disabled RMC Password: not set Alert Enable: Disabled Alert Pending: ⌡0;1;5mYES⌡0m Init String: Dial String: Alert String: Com1_mode: SNOOP Last Alert: ⌡0;1mAC Loss⌡0m Watchdog Timer: 60 seconds Autoreboot: OFF Logout Timer: 20 minutes User String: RMC> The temperature is a bit high now because I opened the box. No amber light is on, although the leftmost, environmental LED flashes several times just after powering the system on. Can this be an indication of hardware failure? Are there any recommended steps to track down the problem? I'd like to check the com ports setup, but since I cannot even get to the prompt.. thanks a lot -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 ------------------------------ Date: Tue, 14 Aug 2007 09:14:53 -0400 From: "David Turner, Island Computers" Subject: In stock - Hobbyist DS20e systems Message-ID: We have Hobbyist/Disaster Recovery DS20e now in stock These systems are in great condition and very reliable!!! These do not include licenses Base system with 1 667Mhz CPU Dual Power Supplies 2GB Memory BA610-6D Disk Cage On Board SCSI LVD Controllers (2) 2 x HP 36GB Hot Plug Disks Ethernet 10/100 CDROM and Floppy Drive No R/M or Pedestal Kit included Only $2995 -- David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404 T: 877-6364332 x201 Intl: 001 912 447 6622 E: dturner@islandco.com F: 912 201 0402 W: http://www.islandco.com ------------------------------ Date: Tue, 14 Aug 2007 08:17:04 -0600 From: Keith Parris Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: David J Dachtera wrote: > It now appears there never was an intent to continue VMS past Itanic. I've seen public statements that the work done for the Itanium port makes future ports easier, and even that HP _expects_ to port to other architectures in the future -- that's just the way things go: whole new sets of CPU architectures/technology arise in the industry every decade or so. > HP's > intent was to supplant VMS with UX and the only way to do that was to eliminate > VMS's operating platforms: first Alpha as a condition of the Compaq merger, now > Itanic, apparently the hidden part of agenda. There's a fatal flaw in this logic: HP-UX runs on Itanium too, so eliminating Itanium would eliminate the HP-UX platform too. Better find a better hypothesis. :-) ------------------------------ Date: Tue, 14 Aug 2007 07:39:22 -0700 From: "Tom Linden" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris wrote: > There's a fatal flaw in this logic: HP-UX runs on Itanium too, so > eliminating Itanium would eliminate the HP-UX platform too. Better find > a better hypothesis. I imagine that it would not be too difficult to port HP-UX to another platform -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 14 Aug 2007 11:21:43 -0400 From: "FredK" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: "Tom Linden" wrote in message news:op.tw10bwnqhv4qyg@murphus.linden... > On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris > wrote: > >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so >> eliminating Itanium would eliminate the HP-UX platform too. Better find >> a better hypothesis. > > I imagine that it would not be too difficult to port HP-UX to another > platform > And that Big-Endian platform would be? ------------------------------ Date: Tue, 14 Aug 2007 12:15:13 -0500 From: Ron Johnson Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On 08/14/07 09:39, Tom Linden wrote: > On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris > wrote: > >> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so >> eliminating Itanium would eliminate the HP-UX platform too. Better >> find a better hypothesis. > > I imagine that it would not be too difficult to port HP-UX to another > platform I think it would be simpler to harden & add features to Linux (both kernel and userland). -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Tue, 14 Aug 2007 12:28:21 -0500 From: Ron Johnson Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On 08/14/07 10:21, FredK wrote: > "Tom Linden" wrote in message > news:op.tw10bwnqhv4qyg@murphus.linden... >> On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris >> wrote: >> >>> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so >>> eliminating Itanium would eliminate the HP-UX platform too. Better find >>> a better hypothesis. >> I imagine that it would not be too difficult to port HP-UX to another >> platform >> > > And that Big-Endian platform would be? Most processors are big- or bi-endian. The only processor families that I can find which is only little-endian are Intel's 8* series (and "clones", of course). -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Tue, 14 Aug 2007 13:33:17 -0400 From: "FredK" Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: "Ron Johnson" wrote in message news:VClwi.131195$BX3.82037@newsfe13.lga... > On 08/14/07 10:21, FredK wrote: >> "Tom Linden" wrote in message >> news:op.tw10bwnqhv4qyg@murphus.linden... >>> On Tue, 14 Aug 2007 07:17:04 -0700, Keith Parris >>> wrote: >>> >>>> There's a fatal flaw in this logic: HP-UX runs on Itanium too, so >>>> eliminating Itanium would eliminate the HP-UX platform too. Better find >>>> a better hypothesis. >>> I imagine that it would not be too difficult to port HP-UX to another >>> platform >>> >> >> And that Big-Endian platform would be? > > Most processors are big- or bi-endian. The only processor families > that I can find which is only little-endian are Intel's 8* series > (and "clones", of course). > Golly. OK. So should it be POWER? Or SPARC? That HP-UX ports to? ------------------------------ Date: Tue, 14 Aug 2007 06:40:30 -0700 From: issinoho Subject: MACRO port Message-ID: <1187098830.807660.104170@d55g2000hsg.googlegroups.com> I am porting an application from VAX to I64 which contains a tiny amount of MACRO. I do not want the functionality of the application to change; I also want to minimise code changes. I have a MACRO module which appears to be crashing the system (the reason it is doing this and the relative merit of the act is beyond the scope of this discussion). Code follows, .title death .entry death,^m<> $cmkrnl_s routin=kill_system ret .entry kill_system,^m<> $BUG_CHECK 1000,FATAL .end The MACRO compile on I64 fails as follows, $BUG_CHECK 1000,FATAL ^ %IMAC-E-DATINCODE, data in code stream Short question: can I replace this line of code with an equivalent compilable alternative? HP C V7.2-001 on OpenVMS IA64 V8.3 Thanks. ------------------------------ Date: Tue, 14 Aug 2007 10:01:30 -0400 From: "FredK" Subject: Re: MACRO port Message-ID: Remove the "$" BUG_CHECK 1000, FATAL The macro takes 3 parameters, the first is the error, the second is the type (FATAL causes a HALT) and an optional parameter of REBOOT or COLD_BOOT (REBOOT is needed for non-fatal errors). $ LIB/EX:BUG_CHECK/OUT=BC.MAR SYS$LIBRARY:LIB.MLB I believe the new macro makes a PAL call that actually does it. "issinoho" wrote in message news:1187098830.807660.104170@d55g2000hsg.googlegroups.com... >I am porting an application from VAX to I64 which contains a tiny > amount of MACRO. > I do not want the functionality of the application to change; I also > want to minimise code changes. > > I have a MACRO module which appears to be crashing the system (the > reason it is doing this and the relative merit of the act is beyond > the scope of this discussion). Code follows, > > .title death > > .entry death,^m<> > > $cmkrnl_s routin=kill_system > > ret > > .entry kill_system,^m<> > > $BUG_CHECK 1000,FATAL > > .end > > > The MACRO compile on I64 fails as follows, > > $BUG_CHECK 1000,FATAL > > ^ > > %IMAC-E-DATINCODE, data in code stream > > > Short question: can I replace this line of code with an equivalent > compilable alternative? > > HP C V7.2-001 on OpenVMS IA64 V8.3 > > Thanks. > ------------------------------ Date: Tue, 14 Aug 2007 07:09:50 -0700 From: issinoho Subject: Re: MACRO port Message-ID: <1187100590.237856.127050@19g2000hsx.googlegroups.com> On Aug 14, 3:01 pm, "FredK" wrote: > Remove the "$" > > BUG_CHECK 1000, FATAL > > The macro takes 3 parameters, the first is the error, the second is the type > (FATAL causes a HALT) and an optional parameter of REBOOT or COLD_BOOT > (REBOOT is needed for non-fatal errors). > > $ LIB/EX:BUG_CHECK/OUT=BC.MAR SYS$LIBRARY:LIB.MLB > > I believe the new macro makes a PAL call that actually does it. > > "issinoho" wrote in message > > news:1187098830.807660.104170@d55g2000hsg.googlegroups.com... > > >I am porting an application from VAX to I64 which contains a tiny > > amount of MACRO. > > I do not want the functionality of the application to change; I also > > want to minimise code changes. > > > I have a MACRO module which appears to be crashing the system (the > > reason it is doing this and the relative merit of the act is beyond > > the scope of this discussion). Code follows, > > > .title death > > > .entry death,^m<> > > > $cmkrnl_s routin=kill_system > > > ret > > > .entry kill_system,^m<> > > > $BUG_CHECK 1000,FATAL > > > .end > > > The MACRO compile on I64 fails as follows, > > > $BUG_CHECK 1000,FATAL > > > ^ > > > %IMAC-E-DATINCODE, data in code stream > > > Short question: can I replace this line of code with an equivalent > > compilable alternative? > > > HP C V7.2-001 on OpenVMS IA64 V8.3 > > > Thanks. No luck, removing the "$" results in, BUG_CHECK 1000,FATAL ^ %IMAC-E-UNRECSTMT, unrecognized statement ------------------------------ Date: Tue, 14 Aug 2007 10:21:34 -0400 From: "FredK" Subject: Re: MACRO port Message-ID: What does the MACRO compile line look like? Make sure it has "+ SYS$LIBRARY:LIB.MLB/LIB" as part of it. "issinoho" wrote in message news:1187100590.237856.127050@19g2000hsx.googlegroups.com... > On Aug 14, 3:01 pm, "FredK" wrote: >> Remove the "$" >> >> BUG_CHECK 1000, FATAL >> >> The macro takes 3 parameters, the first is the error, the second is the >> type >> (FATAL causes a HALT) and an optional parameter of REBOOT or COLD_BOOT >> (REBOOT is needed for non-fatal errors). >> >> $ LIB/EX:BUG_CHECK/OUT=BC.MAR SYS$LIBRARY:LIB.MLB >> >> I believe the new macro makes a PAL call that actually does it. >> >> "issinoho" wrote in message >> >> news:1187098830.807660.104170@d55g2000hsg.googlegroups.com... >> >> >I am porting an application from VAX to I64 which contains a tiny >> > amount of MACRO. >> > I do not want the functionality of the application to change; I also >> > want to minimise code changes. >> >> > I have a MACRO module which appears to be crashing the system (the >> > reason it is doing this and the relative merit of the act is beyond >> > the scope of this discussion). Code follows, >> >> > .title death >> >> > .entry death,^m<> >> >> > $cmkrnl_s routin=kill_system >> >> > ret >> >> > .entry kill_system,^m<> >> >> > $BUG_CHECK 1000,FATAL >> >> > .end >> >> > The MACRO compile on I64 fails as follows, >> >> > $BUG_CHECK 1000,FATAL >> >> > ^ >> >> > %IMAC-E-DATINCODE, data in code stream >> >> > Short question: can I replace this line of code with an equivalent >> > compilable alternative? >> >> > HP C V7.2-001 on OpenVMS IA64 V8.3 >> >> > Thanks. > > > No luck, removing the "$" results in, > > BUG_CHECK 1000,FATAL > > ^ > > %IMAC-E-UNRECSTMT, unrecognized statement > > ------------------------------ Date: Tue, 14 Aug 2007 07:33:35 -0700 From: issinoho Subject: Re: MACRO port Message-ID: <1187102015.331630.199230@22g2000hsm.googlegroups.com> On Aug 14, 3:21 pm, "FredK" wrote: > What does the MACRO compile line look like? > > Make sure it has "+ SYS$LIBRARY:LIB.MLB/LIB" as part of it. > > "issinoho" wrote in message > > news:1187100590.237856.127050@19g2000hsx.googlegroups.com... > > > On Aug 14, 3:01 pm, "FredK" wrote: > >> Remove the "$" > > >> BUG_CHECK 1000, FATAL > > >> The macro takes 3 parameters, the first is the error, the second is the > >> type > >> (FATAL causes a HALT) and an optional parameter of REBOOT or COLD_BOOT > >> (REBOOT is needed for non-fatal errors). > > >> $ LIB/EX:BUG_CHECK/OUT=BC.MAR SYS$LIBRARY:LIB.MLB > > >> I believe the new macro makes a PAL call that actually does it. > > >> "issinoho" wrote in message > > >>news:1187098830.807660.104170@d55g2000hsg.googlegroups.com... > > >> >I am porting an application from VAX to I64 which contains a tiny > >> > amount of MACRO. > >> > I do not want the functionality of the application to change; I also > >> > want to minimise code changes. > > >> > I have a MACRO module which appears to be crashing the system (the > >> > reason it is doing this and the relative merit of the act is beyond > >> > the scope of this discussion). Code follows, > > >> > .title death > > >> > .entry death,^m<> > > >> > $cmkrnl_s routin=kill_system > > >> > ret > > >> > .entry kill_system,^m<> > > >> > $BUG_CHECK 1000,FATAL > > >> > .end > > >> > The MACRO compile on I64 fails as follows, > > >> > $BUG_CHECK 1000,FATAL > > >> > ^ > > >> > %IMAC-E-DATINCODE, data in code stream > > >> > Short question: can I replace this line of code with an equivalent > >> > compilable alternative? > > >> > HP C V7.2-001 on OpenVMS IA64 V8.3 > > >> > Thanks. > > > No luck, removing the "$" results in, > > > BUG_CHECK 1000,FATAL > > > ^ > > > %IMAC-E-UNRECSTMT, unrecognized statement Thanks, Fred, that did it. Cheers. ------------------------------ Date: Tue, 14 Aug 2007 02:33:19 -0700 From: issinoho Subject: Node & Port allocation classes on a new cluster Message-ID: <1187083999.469368.171760@l70g2000hse.googlegroups.com> Chaps, can I borrow your intellect for a few moments please. I have been through the Clustering manuals and various posts here but am still not 100% sure how this all works. I currently have 2 rx2660 unclustered both connected multi-path to a dual controller MSA1000 rack. I have one LUN which will contain shared data, another to become a quorum disk. Both servers have the same disk profile as follows, Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt NODE1$DKA800: Mounted 0 I64_V83 53579760 604 1 NODE1$DNA0: Online wrtlck 0 $1$DGA1501: (NODE1) Mounted 0 DATADISK 273834144 11 1 $1$DGA1502: (NODE1) Mounted 0 QUORUMDISK 142254000 1 1 I am planning the clustering of these servers using the quorum disk and would like clarification of the following. As the servers have the same system disk name (DKA800) do they need a different node allocation class to uniquely serve them up using MSCP; or if I don't use node allocation will the current NODE$DISK notation be sufficient to achieve this. Should I avoid the allocation class of '1' since this is already assigned to the FC disks? In this instance do I need to use port allocation classes? The CLUSTER_CONFIG routine seems a lot 'scarier' since I last used it (about V6.2) and I don't want to get this wrong. Many thanks. ------------------------------ Date: Tue, 14 Aug 2007 09:12:51 -0400 From: "Jilly" Subject: Re: Node & Port allocation classes on a new cluster Message-ID: <46c1aa27$0$7532$ec3e2dad@news.usenetmonster.com> "issinoho" wrote in message news:1187083999.469368.171760@l70g2000hse.googlegroups.com... > Chaps, can I borrow your intellect for a few moments please. > I have been through the Clustering manuals and various posts here but > am still not 100% sure how this all works. > > I currently have 2 rx2660 unclustered both connected multi-path to a > dual controller MSA1000 rack. I have one LUN which will contain shared > data, another to become a quorum disk. > > Both servers have the same disk profile as follows, > > Device Device Error Volume Free > Trans Mnt > > Name Status Count Label Blocks > Count Cnt > > NODE1$DKA800: Mounted 0 I64_V83 > 53579760 604 1 > > NODE1$DNA0: Online wrtlck 0 > > $1$DGA1501: (NODE1) Mounted 0 DATADISK > 273834144 11 1 > > $1$DGA1502: (NODE1) Mounted 0 QUORUMDISK > 142254000 1 1 > > I am planning the clustering of these servers using the quorum disk > and would like clarification of the following. > > As the servers have the same system disk name (DKA800) do they need a > different node allocation class to uniquely serve them up using MSCP; > or if I don't use node allocation will the current NODE$DISK notation > be sufficient to achieve this. > > Should I avoid the allocation class of '1' since this is already > assigned to the FC disks? > > In this instance do I need to use port allocation classes? > > The CLUSTER_CONFIG routine seems a lot 'scarier' since I last used it > (about V6.2) and I don't want to get this wrong. > > Many thanks. > For this cluster you will only need a non-zero system allocation class if you wish to use host based volume shadowing. If you do wish to use shadowing then yes each system will need to have an allocation class. When I set up clusters I always use the following rules 1) If Port Allocation Class (PAC) is needed then it should be used on all nodes 2) HSx widgets should start at allocation class 255 and work down 3) System allocation class should start at 10 and work up as a multiple of 10 UNLESS overridden by MSCP requirements for HSx served devices 4) Shared SCSI ports should have PAC = 2 thru 7 as needed 5) System controllers should have the system allocation class plus a number ie node A = 10 then DQA = 11 DQB = 12 PKA = 13 So for your cluster, node A would have ALLOCLASS = 10 & node B would be 20 under my guidelines. Your cluster would work fine if A = 216 & B = 44 or even if A=1 & B=2. What you cannot have is A=B=n since that would create multiple $n$DKA800 pointing to different devices (with MSCP serving enabled). ------------------------------ Date: Tue, 14 Aug 2007 06:34:46 -0700 From: issinoho Subject: Re: Node & Port allocation classes on a new cluster Message-ID: <1187098486.363677.205130@g4g2000hsf.googlegroups.com> On Aug 14, 2:12 pm, "Jilly" wrote: > "issinoho" wrote in message > > news:1187083999.469368.171760@l70g2000hse.googlegroups.com... > > > > > Chaps, can I borrow your intellect for a few moments please. > > I have been through the Clustering manuals and various posts here but > > am still not 100% sure how this all works. > > > I currently have 2 rx2660 unclustered both connected multi-path to a > > dual controller MSA1000 rack. I have one LUN which will contain shared > > data, another to become a quorum disk. > > > Both servers have the same disk profile as follows, > > > Device Device Error Volume Free > > Trans Mnt > > > Name Status Count Label Blocks > > Count Cnt > > > NODE1$DKA800: Mounted 0 I64_V83 > > 53579760 604 1 > > > NODE1$DNA0: Online wrtlck 0 > > > $1$DGA1501: (NODE1) Mounted 0 DATADISK > > 273834144 11 1 > > > $1$DGA1502: (NODE1) Mounted 0 QUORUMDISK > > 142254000 1 1 > > > I am planning the clustering of these servers using the quorum disk > > and would like clarification of the following. > > > As the servers have the same system disk name (DKA800) do they need a > > different node allocation class to uniquely serve them up using MSCP; > > or if I don't use node allocation will the current NODE$DISK notation > > be sufficient to achieve this. > > > Should I avoid the allocation class of '1' since this is already > > assigned to the FC disks? > > > In this instance do I need to use port allocation classes? > > > The CLUSTER_CONFIG routine seems a lot 'scarier' since I last used it > > (about V6.2) and I don't want to get this wrong. > > > Many thanks. > > For this cluster you will only need a non-zero system allocation class if > you wish to use host based volume shadowing. If you do wish to use > shadowing then yes each system will need to have an allocation class. When > I set up clusters I always use the following rules > > 1) If Port Allocation Class (PAC) is needed then it should be used on all > nodes > 2) HSx widgets should start at allocation class 255 and work down > 3) System allocation class should start at 10 and work up as a multiple of > 10 UNLESS overridden by MSCP requirements for HSx served devices > 4) Shared SCSI ports should have PAC = 2 thru 7 as needed > 5) System controllers should have the system allocation class plus a number > ie node A = 10 then DQA = 11 DQB = 12 PKA = 13 > > So for your cluster, node A would have ALLOCLASS = 10 & node B would be 20 > under my guidelines. Your cluster would work fine if A = 216 & B = 44 or > even if A=1 & B=2. What you cannot have is A=B=n since that would create > multiple $n$DKA800 pointing to different devices (with MSCP serving > enabled). So, just to be clear... I am not using Volume Shadowing so I can use a non-zero host allocation and I don't require port allocation? Correct? ------------------------------ Date: Tue, 14 Aug 2007 15:50:05 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: Node & Port allocation classes on a new cluster Message-ID: issinoho writes: >On Aug 14, 2:12 pm, "Jilly" wrote: >> 4) Shared SCSI ports should have PAC = 2 thru 7 as needed You may want to skip 2 if you ever wish to use fibrechannel magtapes. >> 5) System controllers should have the system allocation class plus a number >> ie node A = 10 then DQA = 11 DQB = 12 PKA = 13 >> >> So for your cluster, node A would have ALLOCLASS = 10 & node B would be 20 >> under my guidelines. Your cluster would work fine if A = 216 & B = 44 or >> even if A=1 & B=2. What you cannot have is A=B=n since that would create >> multiple $n$DKA800 pointing to different devices (with MSCP serving >> enabled). Yes, setting up a cluster to have a simple pattern like this makes it much easier to keep track of things. >So, just to be clear... >I am not using Volume Shadowing so I can use a non-zero host >allocation and I don't require port allocation? >Correct? I think you are asking if you can use a zero host allocation class, not nonzero? Yes. If you do, your system disks will show up as NODE1$DKA800: and NODE2$DKA800. You can also use two (different) host allocation classes, such as 10 and 20. Do you expect to ever expand the cluster? Be sure the two system disks have different labels before you do anything. You can't have two different disks system mounted with the same label, even if neither system ever uses the other's disk. There is plenty of other work needed to configure a cluster, of course. ------------------------------ Date: Tue, 14 Aug 2007 09:46:08 -0400 From: "FredK" Subject: Re: Oldest Alpha for upgrade to Integrity Message-ID: "tadamsmar" wrote in message news:1187019709.710397.207640@w3g2000hsg.googlegroups.com... > On Aug 10, 3:06 pm, bro...@cuebid.zko.hp.nospam (Rob Brooks) wrote: >> tadamsmar writes: >> > Does the AlphaStation 400, AlphaServer 800 and the DS10 support VMS >> > 8.3 or some version that Integrity also supports? >> >> Yes >> >> > I was wondering if I can upgrade my older Alphas to a common version >> > with Integrity. >> > Is there a web page that shows what hardware will run what versions of >> > VMS? >> >> While there have been a few VAX models that have been dropped along the >> way, >> no Alpha hardware has been dropped from support. In this context, I'm >> talking >> about models that were properly sold with VMS, not oddball things like >> the >> multia, or the early EV3-based systems. > > I know you are wrong about this from my direct experience. The first > Alpha we bought was an AXP 150 sold with VMS from DEC. I ended up > surplussing it since it was dropped by 7.3.2. > > I think it may have been delivered with NT on it, but DEC sold us the > system and the media. > The limitations in support in general have had to do mostly with memory constraints. VMS on Alpha initially ran with 16mb, but today we require 64mb IIRC. You can tweak things in SYSGEN and what software you load to make it run with small memories - but we don't support it. The AXP150 (aka AlphaPC, aka Jensen) was an attempt to create a system out of standard PC giblets. EISA bus. Junk IO. Small memory. VMS was initially split on if or how to support it (it was designed for NT). Eventually we decided to support it as a server, and then at the last minute decided to support it as a workstation as well. Given the ability to pick up DS10's on the used market cheap - I can't imagine wanting to continue to use one. ------------------------------ Date: Tue, 14 Aug 2007 09:47:35 -0400 From: "FredK" Subject: Re: Oldest Alpha for upgrade to Integrity Message-ID: "Phillip Helbig---remove CLOTHES to reply" wrote in message news:f9q7i3$u66$5@online.de... > In article , brooks@cuebid.zko.hp.nospam > (Rob Brooks) writes: > >> While there have been a few VAX models that have been dropped along the >> way, >> no Alpha hardware has been dropped from support. In this context, I'm >> talking >> about models that were properly sold with VMS, not oddball things like >> the >> multia, or the early EV3-based systems. >> >> I think you are making this task seem much harder than it really is. > > The Tadpole is another oddball. > Correct. I have booted 8.3 on my Multia - so it does work - but the platform itself was retired at V7.3-2 (IIRC). ------------------------------ Date: Tue, 14 Aug 2007 08:57:27 +0100 From: "chris" Subject: PCI slots on an ES40 Message-ID: <46c15cd9$1_1@glkas0286.greenlnk.net> Does anyone know how to bring up the number of available PCI slots on an ES40 , using vms ver 7.3. Cheers Chris ------------------------------ Date: Tue, 14 Aug 2007 08:39:00 -0400 From: "Richard B. Gilbert" Subject: Re: PCI slots on an ES40 Message-ID: <46C1A264.70004@comcast.net> chris wrote: > Does anyone know how to bring up the number of available PCI slots on an > ES40 , using vms ver 7.3. > > Cheers > > Chris > > AFAIK, that's not something the O/S can tell you. If you know which model you have, and are able to correctly interpret the output of SHOW DEVICE, you can make a pretty good guess. One model had three slots and the other, ten. It's a lot easier to go to the back of the rack and look! ------------------------------ Date: Tue, 14 Aug 2007 14:05:59 +0100 From: "chris" Subject: Re: PCI slots on an ES40 Message-ID: <46c1a529$1_1@glkas0286.greenlnk.net> > It's a lot easier to go to the back of the rack and look! In the end thats what i ended up doing :) "Richard B. Gilbert" wrote in message news:46C1A264.70004@comcast.net... > chris wrote: >> Does anyone know how to bring up the number of available PCI slots on an >> ES40 , using vms ver 7.3. >> >> Cheers >> >> Chris > > AFAIK, that's not something the O/S can tell you. If you know which model > you have, and are able to correctly interpret the output of SHOW DEVICE, > you can make a pretty good guess. One model had three slots and the > other, ten. > > It's a lot easier to go to the back of the rack and look! > ------------------------------ Date: Tue, 14 Aug 2007 07:23:56 -0700 From: "Tom Linden" Subject: Re: PCI slots on an ES40 Message-ID: On Tue, 14 Aug 2007 00:57:27 -0700, chris wrote: > Does anyone know how to bring up the number of available PCI slots on an > ES40 , using vms ver 7.3. > > Cheers > > Chris > > Open the doors to the backplane and have a look. If you have 3 PCI connectors at one end of the bus and three at the other, with the four in the middle missing then you have a model one, and that is all you get. Otherwise it is a model 2 and you shouldn't have to do anything to get an iserted card to be recognized. Just out of curiosity, not that I would ever try it, but could you insert connectors in those positions (yes I know you would have to suck out the solder) and have them functional? -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 14 Aug 2007 10:38:21 -0400 From: "Richard B. Gilbert" Subject: Re: PCI slots on an ES40 Message-ID: <46C1BE5D.5010202@comcast.net> Tom Linden wrote: > On Tue, 14 Aug 2007 00:57:27 -0700, chris > wrote: > >> Does anyone know how to bring up the number of available PCI slots on an >> ES40 , using vms ver 7.3. >> >> Cheers >> >> Chris >> >> > > Open the doors to the backplane and have a look. If you have 3 PCI > connectors > at one end of the bus and three at the other, with the four in the > middle missing > then you have a model one, and that is all you get. Otherwise it is a > model 2 > and you shouldn't have to do anything to get an iserted card to be > recognized. > > Just out of curiosity, not that I would ever try it, but could you > insert connectors > in those positions (yes I know you would have to suck out the solder) > and have them > functional? > > > Subject to correction by someone who knows what he's talking about, I believe that the answer is no. A PCI bus needs a "bridge" between every three or four slots. If the connectors aren't installed, it's a fair bet that the "bridge" chip is not installed either. ------------------------------ Date: Mon, 13 Aug 2007 23:23:24 -0700 From: Joe Bloggs Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On Sun, 12 Aug 2007 21:07:40 -0500, Ron Johnson wrote: >What your friend needs are: > >1. Good Googling skills (most answers *really are* out there), and >2. a spirit of exploration. > >Or... an angel to set it up for him. (That's what I did back in 2000.) > >> His answer means that it is fairly well known that VMS has good >> documentation. Should new owners of VMS wish to market VMS, perhaps that >> is one key aspect they could target since it seems to be a known force >> for VMS and would definitely strike a raw nerve to those trying Linux out. Using Google for linux docs is all well and fine, but do allow for substantial time wasted by incorrect, and flat-out wrong documentation. As consequence, if you've got something tricky and/or critical to do on linux, you might well have to consider not doing it at all. ... ------------------------------ Date: Tue, 14 Aug 2007 14:18:02 +0200 From: "P. Sture" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: In article , Joe Bloggs wrote: > On Sun, 12 Aug 2007 21:07:40 -0500, Ron Johnson > wrote: > > > >What your friend needs are: > > > >1. Good Googling skills (most answers *really are* out there), and > >2. a spirit of exploration. > > > >Or... an angel to set it up for him. (That's what I did back in 2000.) > > > >> His answer means that it is fairly well known that VMS has good > >> documentation. Should new owners of VMS wish to market VMS, perhaps that > >> is one key aspect they could target since it seems to be a known force > >> for VMS and would definitely strike a raw nerve to those trying Linux out. > > > Using Google for linux docs is all well and fine, > but do allow for substantial time wasted by incorrect, > and flat-out wrong documentation. I had experience of that when I had no internet connection at home. Each cul-de-sac meant another day elapsed. Even having a couple of Unix folks in my team, whose experience I could tap, didn't help for things which Linux "does differently". With the benefit of hindsight, I could have easily continued without an internet connection at home for much longer without my foray into Linux, so in that sense it actually cost me quite a lot of money. > As consequence, if you've got something tricky and/or > critical to do on linux, you might well have to consider > not doing it at all. ... During the time I was trying Linux, I couldn't find any decent spreadsheet-cum-wordprocessing software. Even commercial packages were unstable. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Tue, 14 Aug 2007 09:41:09 -0500 From: "Paul Raulerson" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: <004a01c7de81$27d4bf70$777e3e50$@com> > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: Sunday, August 12, 2007 8:42 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > > david20@alpha2.mdx.ac.uk wrote: > > It may seem a bit paradoxical but the reason why there haven't been > tons of > > independently wriiten VMS books is that they weren't needed. VMS has > always had > > tons of excellent documentation. > > > A friend, brought up on Windows, is switching to Linux. He told me that > he was having a hard time. My response was that to learn a new OS, you > need good documentation. His response "I can tell you come from a VMS > world". > > His answer means that it is fairly well known that VMS has good > documentation. Should new owners of VMS wish to market VMS, perhaps > that > is one key aspect they could target since it seems to be a known force > for VMS and would definitely strike a raw nerve to those trying Linux > out. VMS has "good documentation", meaning documentation that covers almost anything you can do with the OS, because the OS is pretty much mon-centric. The same is true of z/OS of course. With Unix - any UNIX or variant - you have not just one development source, but thousands. 10'sof thousands in the case of variants like Linux. Most things, certainly most things that are useful, are documented. There is a manual page for almost everything of course. That which is not well documented is either used by a small portion of the community (who don't feel the need for more documentation) or is just not popular or used enough to worry about. This is not something that can be used a relative scale to say VMS (or z/OS) is BETTER than Linux - it is much more a difference of kind. If VMS was popular enough to have as many people developing for it as say, Linux, then you would see the same problem. I would *love* to see VMS with the same problem, but it won't happen. Costs too much to be that popular, and yes, even with Hobbist licenses, there are restrictions that make free developers feel - well - restricted. :) -Paul ------------------------------ Date: Tue, 14 Aug 2007 14:49:11 GMT From: VAXman- @SendSpamHere.ORG Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: In article <004a01c7de81$27d4bf70$777e3e50$@com>, "Paul Raulerson" writes: {...snip...} >If VMS was popular enough to have as many people developing for it as say, >Linux, then you would see the same problem. What same problem? -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Tue, 14 Aug 2007 09:50:50 -0500 From: "Paul Raulerson" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: <004c01c7de82$822e36d0$868aa470$@com> > -----Original Message----- > From: Main, Kerry [mailto:Kerry.Main@hp.com] > Sent: Sunday, August 12, 2007 11:15 PM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: Wonderful things happen to an OS when it has an internal > champion > > > -----Original Message----- > > From: Paul Raulerson [mailto:paul@raulersons.com] > > Sent: August 9, 2007 12:28 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: Wonderful things happen to an OS when it has an internal > > champion > > > > > > > >To this day IBM does not have a distributed lock manager nor a > > >distributed transaction manager. Both of which are required to > > >perform fault tolerant transactions. > > > > UH- CICS, now known as "Transaction Server" has been around near on > 40 > > years now and supportd distributed confgurations as well as isloated > > configurations. A very large percentage of anything like real time > > financial transacitons in the world goes through CICS. The HP ADCM > > product is somewhat similar. > > > > This is something that VMS does well, don't take me wrong, but how > does > > it do it differently or better than IBM? I see VMS has fitting in > much > > better in smaller, "batch" distributed systems, with many smaller > nodes > > sized appropriately to the location. You can do that with IBM gear of > > course, but it scales differently. > > > > Or to say that differently, VMS scales like a micro z/OS into many > > situations, with appropriate security and processing power. z/OS just > > doesn't scale *down* all that well, because it takes significant > skill > > just to get it installed, much less operating with tuned specs. VMS > is > > much easier indeed. A BIG selling point in the SMB market place. > > > > Even though there are some very large VMS sites out there (I'm > > impressed) I'm not sure that VMS is the target of choice for VL > > environments. I am willing to be convinced otherwise. :) > > > > Well, I guess the answer to this would depend on whether you consider > the mission critical processing environments for VL banks, stock > exchange and other financial systems, lotteries, gaming systems, > telecom (like the one supporting American Idol), health companies, > insurance companies, retail, semiconductor mfging (e.g. Intel and most > other top chip makers). > > One OpenVMS environment I know of actually handles trillions of USD $'s > *per day* through its circuits. > > So, I guess you would have to define what you think is a VL > environment. > > :-) LOL! Fair enough - Data Centers handling upwards of 5+ billion transactions per day is probably pretty close. Think in terms of American Express, which handles not only credit card, but annuity fund, retirement fund, and a dozen or so other financial transaction types. That's probably on the same scale as the center you are thinking of. But what I really meant was a a "target", meaning one of the regularly considered options to put together a new, or expand an existing data center. In that, I was just expressing ignorance of how many new bids per year HP puts out for those kinds of centers. -Paul > > [snip] > > Regards > > > Kerry Main > Senior Consultant > HP Services Canada > Voice: 613-592-4660 > Fax: 613-591-4477 > kerryDOTmainAThpDOTcom > (remove the DOT's and AT) > > OpenVMS - the secure, multi-site OS that just works. > > > ------------------------------ Date: 14 Aug 2007 12:24:10 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: In article <004a01c7de81$27d4bf70$777e3e50$@com>, "Paul Raulerson" writes: > That which is not well documented is either > > used by a small portion of the community (who don't feel the need for more > documentation) or is just not popular or used enough to worry about. That which is not documented is not documented. It doesn't matter to me how few people wanted to use it, it only mattered that I needed information to use the product as described and it wasn't there. > This is not something that can be used a relative scale to say VMS (or z/OS) > is BETTER than Linux - it is much more a difference of kind. Useable is always better than not useable. > If VMS was popular enough to have as many people developing for it as say, > Linux, then you would see the same problem. Back when VMS was exceedingly popular it didn't have that problem. There's no reason why the Linux kernel, which is stable and controlled by Linus, the gnu utilities that run on top of it, which are fairly stable and well controlled by gnu, or any commercial UNIX can't be well documented; they just aren't. ------------------------------ Date: Tue, 14 Aug 2007 09:14:45 +0200 From: Michael Kraemer Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: Richard B. Gilbert schrieb: > Doug Phillips wrote: > >> >> Yep. DEC let Sun become what it is today by not closing that door. The >> VAXstation CAD/CAM systems my customers had back then were *all* >> replaced with cheaper and faster Sun's. And from there Sun grew. >> > > Yup! Faster and cheaper beats better every time!!! > Define "better". The RISC boxes in question here were at least as capable as the VAXen to do the job. ------------------------------ Date: Tue, 14 Aug 2007 11:18:36 +0000 From: "Main, Kerry" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: > -----Original Message----- > From: Doug Phillips [mailto:dphill46@netscape.net] > Sent: August 13, 2007 4:24 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > > On Aug 13, 2:58 pm, "Main, Kerry" wrote: > > -----Original Message----- > > > From: Doug Phillips [mailto:dphil...@netscape.net] > > > Sent: August 13, 2007 3:40 PM > > > To: Info-...@Mvb.Saic.Com > > > Subject: Re: Wonderful things happen to an OS when it has an > internal > > > champion > > > > [snip] > > > > > > > > > > > > > > Here are just a few recent examples of OpenVMS clustering by what > > > would be > > > > considered SMB companies: > > > > > >http://h71028.www7.hp.com/ERC/downloads/4AA0- > > > > 7388EEE.pdf(full)http://h71028.www7.hp.com/erc/library/GetPage.aspx?pag > > > eid=3D496911(condensed) > > > > > >http://h71028.www7.hp.com/ERC/downloads/5983-2346EN.pdf > > > > > >http://h71028.www7.hp.com/ERC/downloads/4AA0-3672ENE.pdf > > > > > >http://h71028.www7.hp.com/ERC/Downloads/4AA0-8708EEW.pdf > > > > > > Imagine a company wanting rock solid, very high stable > applications > > > with ultra-high security that does not require 5-20 security > patches > > > per month - what a novel idea! > > > > > > :-) > > > > > Without seeing the financials (which are usually not easy to find > for > > > private companies), those don't look like "$2 mil.revenue/year" > > > operations. That's what we were discussing. > > > > > AFA clustering, I don't think anyone is arguing the benefits; just > the > > > cost. > > > > A few of the examples provided were clustered rx2620's .. > > > > Low end servers with clustering which to me says SMB type > environment. > > > > As it does to me. But SMB covers a wide revenue range and I guess > you'll just have to read the discussion to understand why the examples > you gave probably don't apply. > In your view ... > I will say that revenue isn't the only gauge to use when determining > the need for clustering. Just as number of servers and load per isn't > the only gauge to use for consolidation; If it were, then you'd > recommend "against" clustering of any sort. Neither clusters nor > consolidation are universal solutions. > Of course revenue is not the *only* consideration for clustering. The typical primary driver is risk to the business and the financial impact= of a particular server being offline for whatever reason - planned or unplanne= d. It is a trade-off in terms of complexity and additional cost vs additional availability. This is applicable for the all levels of business regardless of whether it = is SMB or Enterprise. However, one additional consideration - when you consolidate servers to sav= e IT $'s, the impact of a single server being offline is a lot higher than in= a distributed world, so that's why additional availability steps are required (like clustering). Many Customers view the stability of OpenVMS being so high that they feel t= hey do not need to cluster their servers. OpenVMS Cust's also do not have to de= al with monthly security patches as some other platforms do. Certainly nothing wrong with that - that's their decision. Re: your comment "Neither clusters nor consolidation are universal solution= s." Who said they were? Consolidation is a strategy and clusters are a technology to support that strategy. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Tue, 14 Aug 2007 08:33:44 -0400 From: "Richard B. Gilbert" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <46C1A128.1090008@comcast.net> Michael Kraemer wrote: > Richard B. Gilbert schrieb: > >> Doug Phillips wrote: >> >>> >>> Yep. DEC let Sun become what it is today by not closing that door. The >>> VAXstation CAD/CAM systems my customers had back then were *all* >>> replaced with cheaper and faster Sun's. And from there Sun grew. >>> >> >> Yup! Faster and cheaper beats better every time!!! >> > > Define "better". The RISC boxes in question here were at least as capable > as the VAXen to do the job. > A box is a box! (Unless it's a Commodore). I was speaking of the "system"; e.g. box + O/S. ------------------------------ Date: Tue, 14 Aug 2007 09:42:27 -0500 From: "Paul Raulerson" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: <004b01c7de81$56d5ad20$04810760$@com> Well-- the original POWER specification was done by IBM, Motorola, and Apple. Does that give you a bit more confidence? :) > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: Sunday, August 12, 2007 9:25 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > > On 08/12/07 17:58, Paul Raulerson wrote: > > > >>> x86 comes to mind, but if there were a spin > >>> to address > >>> the hardware sales angle, Power might be a tempting target. More > like > >> a VAX > >>> than the > >>> x86 is anyway... :) > >> You mean "more like Alpha" I think? Power is RISC. I don't know > Power > >> intimately, but do I know it's a completely different beast. With > >> Apple moving to X86-64, I can't guess what IBM's plans might be for > >> Power. I know IBM is helping push x86 performance up the scale. If > it > >> were up to me (which it isn't) I wouldn't port to Power. Then again, > I > >> don't know how Cell might factor into it all. > >> > > Nope - I meant more like a Vax. An ancestor of the PowerPC chip is > the 680x0 > > line, so you find the way registers are used and such more like the > Vax than > > I don't *doubt* you, but have never read even a whisper that the 68K > line had any kind of influence over the Power, other than generic > stuff like "orthogonal instructions are a Good Thing". > > > like the PC. Also, more like a mainframe, but for slightly different > > reasons. > > -- > Ron Johnson, Jr. > Jefferson LA USA > > Give a man a fish, and he eats for a day. > Hit him with a fish, and he goes away for good! ------------------------------ Date: Tue, 14 Aug 2007 09:57:19 -0500 From: "Paul Raulerson" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: <004d01c7de83$6a41aec0$3ec50c40$@com> > -----Original Message----- > From: Michael Kraemer [mailto:M.Kraemer@gsi.de] > Sent: Monday, August 13, 2007 7:08 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > > Paul Raulerson schrieb: > > > > > Nope - I meant more like a Vax. An ancestor of the PowerPC chip is > the 680x0 > > line, > > Nope, the PPC has nothing in common with the 68k, except Motorola being > one of its parent companies. PPC inherited the bus interface from > (now dead) Motorola's own 88k RISC chips, and they made sure that > PPC would be able to exist in the embedded space as a successor to the > 68k. > The 68K was distinctly PDP-11 oriented, and yes, a lot of that orientation can across in the Power design. The s/390 arch, is much more like CISC than an x86 chip, as is a VAX. I had friends who worked on that chip in the old days - and their opinion differs from yours. So does my own, but the way. :) -Paul > > so you find the way registers are used and such more like the Vax > than > > > > like the PC. Also, more like a mainframe, but for slightly different > > reasons. > > PPC instruction set reminds me much more of x86 and S/370, > except for the wealth of registers. 68k is more VAX-like, i.e. > extremely CISCish. ------------------------------ Date: Tue, 14 Aug 2007 08:08:58 -0700 From: "Tom Linden" Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: On Tue, 14 Aug 2007 07:42:27 -0700, Paul Raulerson wrote: > Well-- the original POWER specification was done by IBM, Motorola, and > Apple. Does that give > you a bit more confidence? Yes, but it was largely based on RISC-6000 specs, which was done solely (and well) by IBM -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Tue, 14 Aug 2007 08:11:49 -0700 From: FrankS Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1187104309.446914.197600@l70g2000hse.googlegroups.com> On Aug 14, 10:41 am, "Paul Raulerson" wrote: > Costs too much to be that popular, and yes, even with Hobbist licenses, > there are restrictions that make free developers feel - well - restricted. I haven't done an apples-to-apples comparison, but curiosity made me check the HP Configurator web site the other day. A two-CPU license + media was only around $2k (IIRC) for the Itanium license. I have no clue what an Alpha license costs these days. Honestly, for my wallet $2k isn't all that terrible. Again, I haven't checked the details or compared the cost of, say, RedHat but it doesn't seem out of line for everything that OpenVMS brings to the table. I also didn't check the cost of layered product and compiler licenses that might be needed to put together a development platform. My guess is that the issue isn't cost that makes OpenVMS unpopular -- the Itanium system prices are certainly reasonable at around $6k with licenses for an entry level server. The lack of popularity is IMHO based on the long-complained- of lack of any noticeable marketing effort by HP and Compaq before them. ------------------------------ Date: Tue, 14 Aug 2007 10:48:20 -0700 From: Doug Phillips Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1187113700.404433.89490@m37g2000prh.googlegroups.com> On Aug 14, 6:18 am, "Main, Kerry" wrote: > > -----Original Message----- > > From: Doug Phillips [mailto:dphil...@netscape.net] > > Sent: August 13, 2007 4:24 PM > > To: Info-...@Mvb.Saic.Com > > Subject: Re: Wonderful things happen to an OS when it has an internal > > champion > > > On Aug 13, 2:58 pm, "Main, Kerry" wrote: > > > -----Original Message----- > > > > From: Doug Phillips [mailto:dphil...@netscape.net] > > > > Sent: August 13, 2007 3:40 PM > > > > To: Info-...@Mvb.Saic.Com > > > > Subject: Re: Wonderful things happen to an OS when it has an > > internal > > > > champion > > > > [snip] > > > > > > Here are just a few recent examples of OpenVMS clustering by what > > > > would be > > > > > considered SMB companies: > > > > > >http://h71028.www7.hp.com/ERC/downloads/4AA0- > > > 7388EEE.pdf(full)http://h71028.www7.hp.com/erc/library/GetPage.aspx?pag > > > > eid=496911(condensed) > > > > > >http://h71028.www7.hp.com/ERC/downloads/5983-2346EN.pdf > > > > > >http://h71028.www7.hp.com/ERC/downloads/4AA0-3672ENE.pdf > > > > > >http://h71028.www7.hp.com/ERC/Downloads/4AA0-8708EEW.pdf > > > > > > Imagine a company wanting rock solid, very high stable > > applications > > > > with ultra-high security that does not require 5-20 security > > patches > > > > per month - what a novel idea! > > > > > > :-) > > > > > Without seeing the financials (which are usually not easy to find > > for > > > > private companies), those don't look like "$2 mil.revenue/year" > > > > operations. That's what we were discussing. > > > > > AFA clustering, I don't think anyone is arguing the benefits; just > > the > > > > cost. > > > > A few of the examples provided were clustered rx2620's .. > > > > Low end servers with clustering which to me says SMB type > > environment. > > > As it does to me. But SMB covers a wide revenue range and I guess > > you'll just have to read the discussion to understand why the examples > > you gave probably don't apply. > > In your view ... > Darn, Kerry. It's real hard to reply to this if you aren't going read the thread and stay in the context of the discussion, so I'll try to repeat some of it so you don't have to go back and find it. Here's a bit from the post that started this branch of the thread: ### > >[attribution removed] > > > I've spent 20 years in this field on OpenVMS and other platforms. > > > I've never been to an OpenVMS shop for any company grossing >$2mil in > > > sales which wasn't fully using a cluster. ### In my reply to that statement I said I've seen *lots more* OpenVMS shops in the $2mil/year range that were *not* clustered than ones that were, and you posted examples of clustered SMB companies that I suspect fall considerably above the $2mil/year we were discussing. My point is not about the benefits or value of clustering. It's about affordability. I think clustering is *good* and I think VMS does it right. An Alpha clustering license costs close to $20,000/per on the *low* end. I'm not that familiar yet with Itanium pricing, but the last I looked you needed the MCOE license, and from what I recall that is also quite expensive (and is per processor.) So, a $2mil/year company with a high profit margin and whose business depends on 24/7 operation will find the cost of VMS clustering justifiable. The majority of businesses that size will not. If you disagree with that, please explain your reasons. 88 ------------------------------ Date: Tue, 14 Aug 2007 08:30:54 -0700 From: David Mathog Subject: Re: X Window Servers Message-ID: Brian Tillman wrote: > "Dave Harrold" wrote in message > news:5i19nuF3ldpjoU1@mid.individual.net... > >> I use XMing on my home PC. >> >> http://sourceforge.net/projects/xming > > I'll look into it. Thanks. Look carefully. Xming had (has?) an issue with some machines, notably the AMD K8's I use, where it starts randomly pasting stuff into every open window. VERY dangerous. See: http://sourceforge.net/forum/forum.php?thread_id=1665559&forum_id=527810 Aside from that show stopper, Xming worked well for me. Regards, David Mathog ------------------------------ End of INFO-VAX 2007.444 ************************