1 INFO-VAX	Wed, 21 Aug 2002	Volume 2002 : Issue 459       Contents:0 Re: (O.T.?) Re: V7.3-1 and TIMA for FC Minimerge4 ??== Hardware upgrade for an Alpha Station 400 4/233# Re: attn: Paddy (re: DCL procedure) $ Re: DE101 - can it go to Full Duplex' Re: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap ' RE: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap ' Re: Fortune Magazine and a post-VMS rap  Re: Fortune Magazine wrapper Re: Fortune Magazine wrapper+ Re: Hoff, what is the status of your book ? + Re: Hoff, what is the status of your book ? - Re: How to "forward declare" a function in c? * Re: How to configure Reflection X-server ?$ Re: HP buying EMC. Is that true ????$ Re: HP buying EMC. Is that true ????$ RE: HP buying EMC. Is that true ????" Re: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly" RE: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly" Re: HP-Compaq Merger Went Smoothly@ Re: Licenses (was Re: Charon-VAX (was: [VAX] VMS to [Alpha]...))@ Re: Licenses (was Re: Charon-VAX (was: [VAX] VMS to [Alpha]...)) Re: Memory Slot? Re: New missive from HP  Re: New missive from HP  Re: New missive from HP  Re: New missive from HP  Re: New missive from HP  Re: New missive from HP  Re: NewHp & VMS Licensing  Re: OpenVMS + Joint STARS = Re: P.Thread: setting RR scheduling policy on default thread? / Re: Printing barcodes via postscript on OpenVMS / Re: Printing barcodes via postscript on OpenVMS  Re: Simple cluster Re: Simple cluster Re: Simple cluster Re: Simple cluster Re: Simple cluster Re: Simple cluster Re: Simple cluster Re: tcpware smtp  Re: total VMS newbie - pointers?  Re: total VMS newbie - pointers?$ Re: V7.3-1 and TIMA for FC Minimerge$ Re: V7.3-1 and TIMA for FC Minimerge$ RE: V7.3-1 and TIMA for FC Minimerge Re: VMS to OpenVMS conversion * Re: VMS upgrade with shadowed system disk.  F ----------------------------------------------------------------------  % Date: Tue, 20 Aug 2002 22:00:09 -0700 " From: Koloth <koloth@telocity.com>9 Subject: Re: (O.T.?) Re: V7.3-1 and TIMA for FC Minimerge , Message-ID: <3D631E59.5F85DC92@telocity.com>  : Paint it mauve.  I hear it get better throughput that way.   Larry Kilgallen wrote:   > In article <70EDC551EFE5684B9B3C8E5890F783633150DD@rlghncsxm20.usa.dce.usps.gov>, "Webb, William W - Raleigh, NC" <WWEBB1@email.usps.gov> writes: / > > I once described a star coupler to a PHB as  > > 6 > > "kind of a cube tap for the cluster interconnect". > >  > > :^)  > G > So you delight in torturing PHBs with technical terms like cube tap ?    ------------------------------  % Date: Tue, 20 Aug 2002 23:18:03 +0200 3 From: "Aus, Hans Magnus" <aus@vim.uni-wuerzburg.de> = Subject: ??== Hardware upgrade for an Alpha Station 400 4/233 B Message-ID: <aus-54E940.23180320082002@wrzx08.rz.uni-wuerzburg.de>  G What processor and hardware upgrades are possible for an Alpha Station  
 400 4/233?  F I've inherited the Alpha Station and am wondering if, for example, an H ALPHA EV6 FCO XP1000 (500MHz) CPU with board, P/N: EQ-01769-01 and P/N: < 54-25088-01:: XP1000-F001 FCO KIT  would fit and work in my < new-to-me-Alpha. The XP1000 is currently offered on ebay.de.  2 Where can I read about possible hardware upgrades?  # I've also inherited a DecPC axp150.    --  4 Hans Magnus Aus, Wuerzburg, aus@vim.uni-wuerzburg.de   ------------------------------   Date: 20 Aug 02 23:36:06 +0200) From: p_sture@elias.decus.ch (Paul Sture) , Subject: Re: attn: Paddy (re: DCL procedure)) Message-ID: <oeKhFj3XzONT@elias.decus.ch>   b In article <3d624a42$1@news.si.com>, "Brian Tillman" <tillman_brian@notnoone.notnohow.com> writes:@ >>I am stuck with a bl**dy Outlook account which they believe isH >>god-given.  At least I am connecting from a VMS box via Mozilla.  It'sJ >>like leaving the champagne drinking crowd and having to imbibe sulphuric >>acid.  > N > My complete sympathy.  In a couple of short months, I'll be in the positioinM > in which you've found yourself: having to use Outlook.  Moreover, our Email ; > will be outsourced to HP!  No more internal mail routers.  > M > If anyone can tell me how to get Exchange to deliver mail to me VMS account E > and still appear to be from the person who actually sent it, I'd be  > grateful.  > --C > Brian Tillman                   Internet: tillman_brian at si.com C > Smiths Aerospace                          tillman at swdev.si.com ? > 3290 Patterson Ave. SE, MS      Addresses modified to prevent > > Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@": >        This opinion doesn't represent that of my company >  >  --   __
 Paul Sture Switzerland    ------------------------------  % Date: Tue, 20 Aug 2002 20:33:26 +0200 , From: "Reinhard Eigner" <antispam@garnix.de>- Subject: Re: DE101 - can it go to Full Duplex / Message-ID: <aju1rm$d7p$02$1@news.t-online.com>   @ I've a PWS600au and this AlphaStation has an embedded Tulip NIC.D If I set the NIC to Full Duplex on the SRM the Full Duplex LED on my: switch doesn't light up and I get collisions on this port.= If  I set the card on auto_negotiation everything works fine. * The card switches itself to 100 MBit/s FD.   bye  Reinhard  D "Glen Martin" <glenmark@utxvms.cc.utexas.edu> schrieb im Newsbeitrag7 news:6e2f14f4.0208200836.22267f6f@posting.google.com... G > I have a couple of old AlphaServer 2100a systems running OpenVMS v6.2 F > which appear to have DE101 NICs (at least that is what is stamped onA > the outside of the cards). CLUE CONFIG lists them only as Tulip F > adapters. I've been trying to set them to Full-Duplex mode, both viaF > LANCP and via the EWA0_MODE environment variable within SRM, but theF > cards aren't going to full (the switch to which they connect are setF > to Full Duplex). Am I fighting an uphill battle? Do these cards evenF > support Full Duplex? Thus far, I've been unable to find this info at > Compaq's website.... >  > TIA  > Glen   ------------------------------  % Date: Tue, 20 Aug 2002 14:29:38 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 0 Subject: Re: Fortune Magazine and a post-VMS rap, Message-ID: <3D628A8F.ACC8B4A4@videotron.ca>   "Terry C. Shannon" wrote: K > We in Encompass mulled over the idea. Reason we scuttled DECUS is that to N > some of the Big Dogs in Houston, DECUS = VMS, which was not a Good Thing. (IJ > think VMS is a good thing, a lot of folks in Houston certainly did not!)  G As I recall, they wanted DECUS to include Compaq and Itug as well, so a J generic, meaningless term was found, with many countries finding their own meaningless name.   L But houston is no more. HP has its own user group.  Seems that ITUG has alsoL retained some life. So DECUS could be revived with a true mandate to supportM the ex-Digital products. Perhaps eventually, DECUS could become a "subsidiay" @ of Interex, but it should/could still retain its DECUS identity.  E Returning to "DECUS" on a worldwide basis would be a very good thing.    ------------------------------  % Date: Tue, 20 Aug 2002 14:18:20 -0500 $ From: "Art Beane" <beane@petris.com>0 Subject: Re: Fortune Magazine and a post-VMS rap7 Message-ID: <006501c2487e$58a03a10$342810ac@petris.com>    Terry said:   F "(I think VMS is a good thing, a lot of folks in Houston certainly did not!)"  E Unfortunately, the lots of folks in Houston who do don't get listened E to. Houston does have its fair share of VMS Ambassadors and dedicated 
 customers.   ------------------------------    Date: 20 Aug 2002 13:17:41 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris) 0 Subject: Re: Fortune Magazine and a post-VMS rap= Message-ID: <cf15391e.0208201217.5ac472fd@posting.google.com>   f "Terry C. Shannon" <terryshannon@attbi.com> wrote in message news:<eh679.42899$983.58105@rwcrnsc53>...N > But let's assume the day comes that HP-UX and the ongoing COE effort yield aA > UNIX that offers complete feature and function parity with VMS.   C I think there's something mixed up in the assumptions here, Terry.  F COE (now blossomed out in the form of the Unix Portability effort) hasD resulted in making it easier for Unix applications to run on VMS, byD virtue of adding features to VMS.  How does that in any way help put VMS features into Unix? . ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------    Date: 20 Aug 2002 14:28:05 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris) 0 Subject: Re: Fortune Magazine and a post-VMS rap= Message-ID: <cf15391e.0208201328.492e2848@posting.google.com>   f "Terry C. Shannon" <terryshannon@attbi.com> wrote in message news:<eh679.42899$983.58105@rwcrnsc53>...N > But let's assume the day comes that HP-UX and the ongoing COE effort yield aJ > UNIX that offers complete feature and function parity with VMS. Your VMSL > apps run in the environment. End users don't notice any difference. Ditto,N > more or less, for managers. This hypothetical day comes to pass right aroundL > the ~2006 timeframe of the post-Marvel, post-Superdome big-ass IPF server.N > If these assumptions come to pass, does it really matter what the underlying > OS is?  D This sounds very reminiscent of the folks high within Digital in theE early 90s who thought that if they could only get (what they saw as, D and coveted) the best features of VMS (like clustering) into DigitalB Unix, they could get all the VMS users to move to their platform. D They then proceeded to tell all the VMS users that VMS was dead, and@ that Unix was the way of the future, but not to worry -- all the8 features of VMS would be in Digital Unix, Real Soon Now.  F And again in the later 90s we heard the same song, second verse, onlyA this time Windows NT was the future (its design was based on VMS, C after all) and it would soon have all the functionality of VMS (and 8 Digital even provided Microsoft with well-researched andD well-engineered reference designs, software, code, patents, and even9 entire teams of engineers themselves to help them along).   F Users have seen what really happened, as opposed to what was predictedF and promised.  TruClusters are the best Unix clustering available, butC VMS users can somehow still tell the difference.  Where is Wolfpack F today, and 16-node Windows clusters?  Where is the DLM and the Cluster File System for Windows NT?   F I don't think VMS customers are likely to fall for this song and danceE again, even if HP-UX and Linux are the OS's featured in the third and  fourth verses.  D Marketeers think if they could only check off all the boxes in theirD (carefully-crafted) list on a PowerPoint slide, VMS users will flockC to migrate to whatever platform is being hyped as "the future" this  year.   A I think the basic problem is that people who propose this sort of E strategy don't really understand enough about VMS to know WHY its set E of features and functions are so valued by its customer base, and how F the synergy that is VMS is achieved from these features and functions.  ) And there's a huge, gaping chasm between: C > a UNIX that offers complete feature and function parity with VMS.  and:N > Your VMS apps run in the environment. End users don't notice any difference.  F The first can be 'achieved' with more slideware than engineering.  TheF latter is a whole lot harder, and the users would feel the pain of theD difference if only the first were delivered; the second is what they would really need.  E I have come to believe that moving all of VMS' features and functions F to Unix or NT probably isn't even technically feasible or practical inE any meaningful way, because of the wide differences in the underlying F design assumptions and philosophies, the different target markets, andC the resulting technical limitations of those OS platforms.  Running ? VMS itself on industry-standard hardware makes much more sense.   E I've come to the conclusion that it would take a new OS platform, one F designed for modern technology but compatible with the core VMS valuesF of careful design effort up-front, engineering excellence, intoleranceB of any hint of things like data corruption or security weaknesses,= extreme reliability, excellent documentation, seamless upward 5 compatibility, and so forth, to actually replace VMS. . ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  # Date: Wed, 21 Aug 2002 00:33:30 GMT * From: "Bill Todd" <billtodd@metrocast.net>0 Subject: Re: Fortune Magazine and a post-VMS rapB Message-ID: <udB89.111309$Fw3.4718107@bin2.nnrp.aus1.giganews.com>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0208201328.492e2848@posting.google.com...    ...   G > I've come to the conclusion that it would take a new OS platform, one H > designed for modern technology but compatible with the core VMS valuesH > of careful design effort up-front, engineering excellence, intoleranceD > of any hint of things like data corruption or security weaknesses,? > extreme reliability, excellent documentation, seamless upward 7 > compatibility, and so forth, to actually replace VMS.   K That sounds about right to me.  And it could probably meet COE standards as K well, pretty much as a by-product of offering what a universal system ought H to offer these days (if you don't make the system pretty universal, it'sL *really* hard to make the financial case for developing it at all - and it'sF not the kind of system one can expect open source advocates to build).  H If you hear of anyone credible embarking on such an effort, let me know.   - bill   ------------------------------  % Date: Tue, 20 Aug 2002 21:48:33 -0400 ( From: David Froble <davef@tsoft-inc.com>0 Subject: Re: Fortune Magazine and a post-VMS rap, Message-ID: <3D62F171.2010802@tsoft-inc.com>  @ > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message  G >>I've come to the conclusion that it would take a new OS platform, one H >>designed for modern technology but compatible with the core VMS valuesH >>of careful design effort up-front, engineering excellence, intoleranceD >>of any hint of things like data corruption or security weaknesses,? >>extreme reliability, excellent documentation, seamless upward 7 >>compatibility, and so forth, to actually replace VMS.   ( How would such a system differ from VMS?  ' Why couldn't VMS be the starting point?   Q I can see that VMS isn't 'popular' right now, and things that get 'hype' usually  I get followed regardless of worth.  Is it your idea that only a 'new' OS,  M proceeded by plenty of fanfair, could gain widespread acceptance.  I can see  E that, (Microsoft and windoz proved it), but I do have a problem with  P re-inventing the wheel, no matter how much it's happening in 'modern computing'.  ? One positive thing that would be possible is avoiding 'C'.  :-)   H In what environment would such an OS exist?  Intel?  Other?  Both?  All?  L It sure could be fun for some OS developers if they can get someone to fund 5 their fun.  I'm having a hard time seeing such occur.    Dave   ------------------------------  % Date: Tue, 20 Aug 2002 23:02:32 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> 0 Subject: RE: Fortune Magazine and a post-VMS rapT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266094C@kaoexc01.americas.cpqcorp.net>   Keith,   Good comments.=20   D With respect to the clustering comments, I suspect on the philosophyC side, it also comes down to the religious argument of which cluster D strategy is "better" i.e.. shared nothing vs. shared everything. =20  D NT/NSK/some UNIX's went the shared nothing route which meant the VMS5 cluster code was likely viewed as not that useful.=20   G OpenVMS/MVS (z/VM?) /Tru64 UNIX (future HP-UX) and Oracle 9i RAC/8i OPS ) have adopted the shared everything model.   E Now both strategies have advantages and disadvantages - it depends on G the application, how dynamic and predictable the business loads are and05 what level of availability you are trying to achieve.   H With shared nothing, you can not load balance across multiple servers atG multiple sites since by design, one server handles all the load for onegE set of resources in the cluster. It "serves" those resources to other D cluster members that request access - not unlike MSCP serving in the OpenVMS cluster world.=20a  H On the other hand, shared nothing does not have the "overhead" of a DLM.C In addition, the theory is that there is a better chance that those . resources being served will be cached locally.  C With shared nothing, adding a new server to the mix typically meansnE re-partitioning the workloads and a work stoppage, so if the workloadoE swings are very dynamic, or one workload component gets a much higherfD load than anticipated, this could be an issue in terms of horizontal& scaling. But, no DLM to "worry" about.  7 >>> VMS users can somehow still tell the difference.<<<?  @ Yep, things like clustered batch sub-systems, clustered securityG monitoring and clustered disk quota's are often taken for granted untilo it is to late.=20   C Or when VMS users discover that many UNIX SSI (single system image) C designs actually means the cluster common code might be on a commonaC disk, but each OS partition still needs its own boot disk/partitionVD (RAIDed for availability). Kind of like sys$common being on a common8 disk, but sys$specific portions having to be on separate disks/partitions.r  : All issues that get kind of lost in the OS marketing wars.   Regardsv  
 Kerry Main Senior ConsultantH Hewlett-Packard Canada! Consulting & Integration Services  Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----; From: Keith Parris [mailto:keithparris_NOSPAM@yahoo.com]=20  Sent: August 20, 2002 5:28 PMc To: Info-VAX@Mvb.Saic.Com 0 Subject: Re: Fortune Magazine and a post-VMS rap    < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message) news:<eh679.42899$983.58105@rwcrnsc53>...tI > But let's assume the day comes that HP-UX and the ongoing COE effort=20mG > yield a UNIX that offers complete feature and function parity with=20 J > VMS. Your VMS apps run in the environment. End users don't notice any=20I > difference. Ditto, more or less, for managers. This hypothetical day=200G > comes to pass right around the ~2006 timeframe of the post-Marvel,=20.J > post-Superdome big-ass IPF server. If these assumptions come to pass,=202 > does it really matter what the underlying OS is?  D This sounds very reminiscent of the folks high within Digital in theE early '90s who thought that if they could only get (what they saw as,RD and coveted) the best features of VMS (like clustering) into DigitalD Unix, they could get all the VMS users to move to their platform.=20D They then proceeded to tell all the VMS users that VMS was dead, and@ that Unix was the way of the future, but not to worry -- all the8 features of VMS would be in Digital Unix, Real Soon Now.  F And again in the later '90s we heard the same song, second verse, onlyG this time Windows NT was the future (its design was based on VMS, after0E all) and it would soon have all the functionality of VMS (and Digitala@ even provided Microsoft with well-researched and well-engineeredD reference designs, software, code, patents, and even entire teams of) engineers themselves to help them along).6  F Users have seen what really happened, as opposed to what was predictedF and promised.  TruClusters are the best Unix clustering available, butC VMS users can somehow still tell the difference.  Where is Wolfpack F today, and 16-node Windows clusters?  Where is the DLM and the Cluster File System for Windows NT?-  F I don't think VMS customers are likely to fall for this song and danceE again, even if HP-UX and Linux are the OS's featured in the third andD fourth verses.  D Marketeers think if they could only check off all the boxes in theirG (carefully-crafted) list on a PowerPoint slide, VMS users will flock toyF migrate to whatever platform is being hyped as "the future" this year.  A I think the basic problem is that people who propose this sort ofeH strategy don't really understand enough about VMS to know WHY its set ofF features and functions are so valued by its customer base, and how theB synergy that is VMS is achieved from these features and functions.  ) And there's a huge, gaping chasm between:iC > a UNIX that offers complete feature and function parity with VMS.g and:E > Your VMS apps run in the environment. End users don't notice any=20n
 > difference.e  F The first can be 'achieved' with more slideware than engineering.  TheF latter is a whole lot harder, and the users would feel the pain of theD difference if only the first were delivered; the second is what they would really need.  H I have come to believe that moving all of VMS' features and functions toG Unix or NT probably isn't even technically feasible or practical in anyaH meaningful way, because of the wide differences in the underlying designC assumptions and philosophies, the different target markets, and the>C resulting technical limitations of those OS platforms.  Running VMS$; itself on industry-standard hardware makes much more sense.a  E I've come to the conclusion that it would take a new OS platform, oneeF designed for modern technology but compatible with the core VMS valuesF of careful design effort up-front, engineering excellence, intoleranceB of any hint of things like data corruption or security weaknesses,= extreme reliability, excellent documentation, seamless upwardm5 compatibility, and so forth, to actually replace VMS... ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  # Date: Wed, 21 Aug 2002 02:50:03 GMTu* From: "Bill Todd" <billtodd@metrocast.net>0 Subject: Re: Fortune Magazine and a post-VMS rapB Message-ID: <vdD89.103317$2p2.4842328@bin4.nnrp.aus1.giganews.com>  5 "David Froble" <davef@tsoft-inc.com> wrote in messageg& news:3D62F171.2010802@tsoft-inc.com...B > > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message >hI > >>I've come to the conclusion that it would take a new OS platform, onehJ > >>designed for modern technology but compatible with the core VMS valuesJ > >>of careful design effort up-front, engineering excellence, intoleranceF > >>of any hint of things like data corruption or security weaknesses,A > >>extreme reliability, excellent documentation, seamless upwardn9 > >>compatibility, and so forth, to actually replace VMS.n > * > How would such a system differ from VMS?  J a)  It would jettison 25 years' worth of cruft.  Not only has the state ofL the art advanced considerably during those 25 years, but the approaches thatG were optimal 25 years ago are often not the approaches that are optimaliK today (or for tomorrow).  Both the file system and RMS are prime candidateseD for a complete re-work (I'm sure there are other equally significant@ examples, but those are the two I'm best qualified to evaluate).  H b) In the process, it would streamline the system considerably:  a greatI many tweaks that were necessary back in the days of very tight memory andiD disk space are completely irrelevant today (but still clutter up the interfaces).  % c) It would be owned by someone else.-   >a) > Why couldn't VMS be the starting point?   L Because of its current owner.  HP may not yet have been completely ruined byJ its management, but as long as that management remains in place there's noD hope for VMS (nor much hope for HP as a whole) - and there's also noG indication that HP would offer up VMS to some other party to work with.t   >eJ > I can see that VMS isn't 'popular' right now, and things that get 'hype' usuallyrJ > get followed regardless of worth.  Is it your idea that only a 'new' OS,J > proceeded by plenty of fanfair, could gain widespread acceptance.  I can seenF > that, (Microsoft and windoz proved it), but I do have a problem withF > re-inventing the wheel, no matter how much it's happening in 'modern computing'.4  H Unfortunately, the VMS wheel, while sturdy, is no longer anywhere nearlyH round (at least according to current definitions of what 'round' means).L And other wheels may be rounder but aren't as sturdy.  It's not so much thatL anything needs reinventing as that the existing state of the art needs to beE applied across an entire system - and VMS, Unix, and Windows all falluF sufficiently short of this goal that starting from scratch may well beD easier than trying to modify one of them to fit (and also avoids the3 political issues of strict backward compatibility).e   >oA > One positive thing that would be possible is avoiding 'C'.  :-)-  G Gee.  I guess PDP-11 systems were complete crap, then, being written inuI assembler and all.  So, for that matter, is much of VMS (being written ino C)..  H I'd be a lot more concerned with who was writing the code (and how theirF management organized their priorities) than in what language they were using.   >UJ > In what environment would such an OS exist?  Intel?  Other?  Both?  All?  H Portability across different hardware platforms is not only a virtue butK relatively inexpensive (both in development and at run time), if planned upp@ front.  And there's no lack of experience in how to go about it.   >pH > It sure could be fun for some OS developers if they can get someone to fund7 > their fun.  I'm having a hard time seeing such occur.    Me too, unfortunately.   - bill   ------------------------------  % Date: Tue, 20 Aug 2002 23:34:13 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca>e0 Subject: Re: Fortune Magazine and a post-VMS rap+ Message-ID: <3D630A2B.DDDD398@videotron.ca>    Bill Todd wrote:L > a)  It would jettison 25 years' worth of cruft.  Not only has the state ofN > the art advanced considerably during those 25 years, but the approaches thatI > were optimal 25 years ago are often not the approaches that are optimalh > today (or for tomorrow).  L Consider that I am running VMS 7.2 an ALL-IN-1 on a microvax II with 16 megs
 of memory.J Consider that I can run VMS 7.2, X-windows and Mosaic on a vaxstation 3100 also with 16 megs of memory.  M Now, look at the one attempt to rewrite VMS "from scratch" without any of itsnN overhead: NT. NT won't even boot with only 16 megs of memory, even less run on6 CPU that has about 30mhz of 8086 power. (microvax II).  J I have far more confidence in the Hoffs and Fred Kleinsorges of Digital inF slowly transforming VMS into a better performer than I would of anyone. building a new OS from scratch to emulate VMS.  L many may have problems with the slow file system and other weaknesses of VMSK compared to other, simpler operating systems. The engineers have often siad'M that they have plans to fix those problems and that they will eventually makeoM it to customers. The timing of this is a management issue, not an engineeringsM issue. If the owner of VMS wanted improvements to make it to VMS faster, thentA they would do what it takes to make it possible at a faster rate.e   ------------------------------  # Date: Tue, 20 Aug 2002 22:45:59 GMT # From: "John Smith" <a@nonymous.com> % Subject: Re: Fortune Magazine wrapperoI Message-ID: <HEz89.48735$8aG1.25721@news01.bloor.is.net.cable.rogers.com>   2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF40266093B@kaoexc01.americas.cpqcorp.net. .. John,r  * <<< How many CEO's CTO's, CFO's do that?>>  B None - that's why I and others extract them and send them to theseC folks. They are also printed as part of Customer proposals, demo's, 
 shows ect.  G Also, the PDF files allow Customers and ISV partners who are looking tonD justify OpenVMS enhancements and/or new application opportunities to4 show what other Customers have been able to achieve.  H Re: Marketing in WSJ .. Hey, nice ad suggestion - you have my vote. Only line I would change is:fA         "Reliability. Security. Interoperability. All on Industrye Standard Software."k  # Are you looking at a second career?a     ------------   Kerry...   Here's another ad for you:  /      There's been a lot of talk for a long timee/    about 'industry standard' operating systems.O  ,       If you think 'industry standard' means&            Windows, or unix, or Linux,&           then go ahead and suffer the3     crashes, viruses, and expense of lost business.g  )           On the other hand, if you think,-   that 'industry standard' means THE standard +      that operating systems should achieve,,#                then we should talk.-                       OpenVMS.#          The standard everyone elsea!              has been chasing for-                  over 25 years.                     Only from HP.  0 Copyright 2002, John Smith. ALL RIGHTS RESERVED.   ------------------------------  # Date: Wed, 21 Aug 2002 02:58:51 GMTr1 From: "David J. Dachtera" <djesys.nospam@fsi.net>_% Subject: Re: Fortune Magazine wrappers' Message-ID: <3D6306E7.B4497DE1@fsi.net>g   John Smith wrote:  > 2 > Copyright 2002, John Smith. ALL RIGHTS RESERVED.  B If "John Smith" is not your real name, your claim to copyright may unenforceable.   --   David J. Dachteraf dba DJE Systemsg http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/,   ------------------------------  % Date: Tue, 20 Aug 2002 22:19:41 +0100t1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk> 4 Subject: Re: Hoff, what is the status of your book ?6 Message-ID: <3D62C07C.56A473F2@ipl.demon.co.nospam.uk>  9 It's one of those balancing acts more than anything else.dE You reduce the number of staff that have been working with you a long E time then you may reduce your wages bill significantly, whilst upping # the cost of the severance packages.u  G Alternatively, one may continue to pay highly paid, highly experienced,hB highly skilled staff and have a lower bill for severance packages.  F Third option, of course, is to dispose of a few sales people (because,H after all, VMS would sell itself if it had the chance) in which case youE still have those highly skilled, highly talented Engineering guys andMH girls and you still have a pretty high severance bill for getting rid of7 the salesmen in the Armani suits and BMWs/Lexii etc....h  * You pays your money and takes your choice.    H An interesting side line is that I know of at least one company who madeE its secretary and administrator (the same person) redundant.  She wasxF the longest serving member of staff of the four people involved in theH company and got an appropriately sized redundancy payout.  Due to paying7 this, the company went bankrupt less than a year later!t   Steve.     Steve Reece, Systems Consultant,w Swindon, UK.   Nic Clews wrote: >  > Keith Parris wrote:s > >wz > > "John Smith" <a@nonymous.com> wrote in message news:<3%k49.303868$WJf1.154099@news01.bloor.is.net.cable.rogers.com>...O > > > What's the status of the VMS engineering group - adding staff or sheddingv > > > staff these days?e > > >uO > > > If HP is adding staff, then perhaps they truly believe that there will beiJ > > > some sort of sales growth, with or without marketing or advertising. > > >OQ > > > If there is normal attrition without replacement, or outright downsizing ofo4 > > > the group then one can draw other conclusions. > >uJ > > Last I heard, they had some openings they were actively in the processG > > of filling, some of which were back-filling for people who took the: > > early retirement package.S > > G > > Interestingly, fewer than 1 out of 4 of the people in the VMS grouppJ > > who were eligible for the early retirement financial incentive packageI > > chose to leave -- apparently there's too much interesting stuff goingiG > > on there right now to be able to convince folks to leave simply forn
 > > money! > I > But why would such a package be offered when experience is difficult totE > come by? I'd argue that you should try to keep on to the folks thatnD > really know what they are doing, rather than some Nintendo trained > college grad.s > C > Anyway, glad to see the staff saw more sense than the management.v >  > --A > Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencess > nclews at csc dot comt   -- oG "A shadow fell over her face; clear, as if the composure were rent likenE a veil.  And her lips parted, but only with a short intake of breath.eA Then she said, 'Well, then you are right.  Indeed, we are even.'" % 		Louis, "Interview with the Vampire"s   ------------------------------  % Date: Tue, 20 Aug 2002 21:43:44 -0400n) From: "Neil Rieck" <n.rieck@sympatico.ca>o4 Subject: Re: Hoff, what is the status of your book ?9 Message-ID: <yfC89.4151$xL1.786234@news20.bellglobal.com>e  + "Dirk Munk" <munk@home.nl> wrote in messagel. news:uyg49.91835$uV1.6582943@zwoll1.home.nl... >  > [...snip...] > L > Yes, I was refering to that book. From people with more intimate knowledge ofG > the VMS engineering group, I already heard that you have to cope withh amazing I > loads of work. That makes it all the more understandable that you don'tn have any+ > units of spare time left to write a book.o >o1 > Perhaps we need a cluster of cloned hoffs ? :-)e >uF > But anyway I will not withdraw my order of the book, and I will keep hoping thatr+ > one day my copy will fall on the doormat.t >2H This is something I might be interested in as well. What is the proposed& title so that others may pre-order it?  
 Neil Rieck Kitchener/Waterloo/Cambridge,h Ontario, Canada.! http://www3.sympatico.ca/n.rieck/V   ------------------------------  % Date: Tue, 20 Aug 2002 14:36:47 -0400k- From: JF Mezei <jfmezei.spamnot@videotron.ca>a6 Subject: Re: How to "forward declare" a function in c?, Message-ID: <3D628C3B.FF52BC18@videotron.ca>   Atlant Schmidt wrote:t@ > declarations. It's also nice to use the "Forward declarations"6 > section as a module Table-of-Contents, listing *ALL*7 > the routines, even if they aren't used ahead of their  > real declarations.    M CC/prototype creates a .CH file which has an automatic declaration of all theoG functions in that file (along with some crud that needs to be removed).o  D The declarations do not contain the variable names though, so from aE documentation point of view, it is less "complete" than when you justn7 copy/paste the function header to a section at the top.    ------------------------------    Date: 20 Aug 2002 22:25:22 -0700' From: amits_77@yahoo.com (Amit Sawhney)03 Subject: Re: How to configure Reflection X-server ?i= Message-ID: <71939fd6.0208202125.3056e8ae@posting.google.com>t  R "Jakob Erber" <erberj@yahoo.de> wrote in message news:<3d6207a7$1@news.post.ch>...E > > Do i need to run any application on my VMS server before startingi > > Reflections-X ?y >  > NoK > In the Reflexion X main window, you should see on the left side a list ofeJ > Operating system templates, which contains also an entry for VMS. Modify > this one for your needs.N > You can also adapt one of the session manager entries, to display a complete: > VMS Session Manager on your PC screen, thats, what I do. > 	 > regardsa >  > Jakobt  F I have already modified the vms.rxc file according to my needs but theF reflection x root window is only visible thing ..nothing else comes upF when i start.Even i have tried to configure using client wizard but no success till now please help) thanks in advanceh   regards    amit   ------------------------------  % Date: Tue, 20 Aug 2002 20:48:34 +0200d" From: "Hans Vlems" <hvlems@iae.nl>- Subject: Re: HP buying EMC. Is that true ???? 6 Message-ID: <aju2u8$1dsem6$1@ID-143435.news.dfncis.de>  = "Fabio Cardoso" <fabiopenvms@yahoo.com.br> schreef in bericht : news:20020820135714.23956.qmail@web20201.mail.yahoo.com...# > A Field Technician from HP/Compaql > told me about HP buying EMC. >l > Is this true ??1 >o	 > Regardsc >tK IIRC EMC bought Data General several years ago. If HP would buy EMC then it'L would merge DG and DEC legacies. Kind of l'histoire se repete, n'est ce pas?   ------------------------------  # Date: Tue, 20 Aug 2002 22:32:33 GMT.# From: "John Smith" <a@nonymous.com>l- Subject: Re: HP buying EMC. Is that true ????cI Message-ID: <5sz89.48600$8aG1.22202@news01.bloor.is.net.cable.rogers.com>a  ; "Fabio Cardoso" <fabiopenvms@yahoo.com.br> wrote in messageh: news:20020820135714.23956.qmail@web20201.mail.yahoo.com...# > A Field Technician from HP/Compaqe > told me about HP buying EMC. >  > Is this true ??n    L Not that I've heard. HP and EMC have licensed each other's API's in order toL provide management capabilities to each other's storage arrays but that's as& far as I think things have progressed.   ------------------------------  % Date: Tue, 20 Aug 2002 22:17:05 -0400v' From: "Main, Kerry" <Kerry.Main@hp.com> - Subject: RE: HP buying EMC. Is that true ????iT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266094B@kaoexc01.americas.cpqcorp.net>   Fabio,   Aren't rumours great ?  J As far as I know, this rumour was started when the following article was = posted on news.com :4 http://news.com.com/2117-1001-948239.html?tag=3DnisiI "To combat IBM, rivals Dell, Sun and EMC could forge tighter bonds with =aH each other in an alliance that could combine their strengths. Although =E the historical record for alliances isn't great, these arrangements = J don't involve the gut- wrenching reorganizations and gargantuan costs of = mergers.  E The possibility of a Dell-Sun-EMC triumvirate coming into existence =oG could in turn prompt HP to buy EMC. The merger would strengthen HP in =o. storage and deprive Dell of its closest ally."  I I somehow doubt this would ever happen, but then again, I also remember =nF saying as a Digital person "We are worth $10B - who has that kind of = money?"c  3 Now, let the follow-up rumour predictions begin ...a   :-)o   Regardsu    
 Kerry Main Senior Consultant- Hewlett-Packard Canada! Consulting & Integration Servicesc Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----8 From: Fabio Cardoso [mailto:fabiopenvms@yahoo.com.br]=20 Sent: August 20, 2002 9:57 AMs To: Info-VAX@Mvb.Saic.Com8) Subject: HP buying EMC. Is that true ????d    $ A Field Technician from HP/Compaq=20 told me about HP buying EMC.   Is this true ??    Regardsr   FC=20t   =3D=3D=3D=3D=3DoL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dw F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazile fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D   2 __________________________________________________ Do You Yahoo!?& HotJobs - Search Thousands of New Jobs http://www.hotjobs.com   ------------------------------  % Date: Tue, 20 Aug 2002 14:41:19 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>5+ Subject: Re: HP-Compaq Merger Went Smoothlyt, Message-ID: <3D628D4C.8CA221C9@videotron.ca>   Fred Kleinsorge wrote:L > products, and it's direction.  From a pure stock play perspective, Sun hasK > shown little evidence that it will make it's slight profit prediction foriM > the fiscal year ending in 2003.  Nor has the tech market shown any evidencex > of a turn around in general.  H However, two important stocks used by the wall street casino analysts toN determine the faith of "tech" are Cisco and Sun. When either report good news,N the stock goes up, when they report bad news, the stock market goes down. ThisQ was most certaintly the case during the .COM era and at least util very recently.h  K It is in that sense that Sun has a far more important position in the stock M market than HP which is all but ignored since it never sets market trends, ita trails them.   ------------------------------  # Date: Tue, 20 Aug 2002 17:39:35 GMTd5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> + Subject: Re: HP-Compaq Merger Went Smoothly 2 Message-ID: <r9v89.24$v17.768038@news.cpqcorp.net>  6 Andrew Harrison SUNUK Consultancy wrote in message ... >r >  >Fred Kleinsorge wrote:y >'9 >> Andrew Harrison SUNUK Consultancy wrote in message ...s >> >>>e> >>>I am not a stock analyst but given the fundamentals of both9 >>>busineses I know which one I would bet on for the nextm >>>6-12 months.' >>>p >>>  >>I >> Your confusing fundamentals with your personal opinion of the company,o it'sI >> products, and it's direction.  From a pure stock play perspective, Suno hasmL >> shown little evidence that it will make it's slight profit prediction forE >> the fiscal year ending in 2003.  Nor has the tech market shown anyt evidenceL >> of a turn around in general.  I would expect most tech stocks to flounder> >> until something starts driving a new growth spurt in sales. >> >a >rA >Fundamentals are revenue growth and market share growth. We haveiA >them you don't. Not cutting R&D and other longer term investmenti> >does have a short term impact but most experts agree that the? >companies that can do this and grow revenue and share during au< >downturn are the ones that come out of it in the best shape >when the recovery starts. >a  L I'll help you out.  Try quicken.com, plug in SUNW and click on Fundamentals.  K Reading your SEC filings, it also appears that while wanting to hold R&D ataK 10% of net revenue, you also plan on reducing your headcount 9%.  Not good.lK Are you too fat in management?  Too many salesmen?  Too many support staff?iH Too many engineers?  Where is the 9% comming from?  You are also closing facilities.o  F You show zero proof that there is any revenue growth going on at Sun -L again, click on fundamentals in quicken.com and look at "Growth Trends".   IH guess "hoping" to not lose money in a quarter versus losing money is theK right direction though - but I don't think you can project a trend based onm wishing.  : Some selected quotes from your own SEC quarterly report...  L "Over 90% of our products net revenue in the third quarter as well as in theH first nine months of both fiscal 2002 and 2001 was generated by ComputerJ Systems and Network Storage. Computer Systems and Network Storage consistsI primarily of servers, storage and desktop computers. Substantially all ofa the L decrease in products net revenue during the third quarter and the first nineF months of fiscal 2002, when compared with the corresponding periods of fiscalL 2001, was attributable to a decrease in revenues generated by our server andG storage products. Revenues from the sale of desktop systems representedoH approximately 9% and 14% of products net revenue in the third quarter of fiscalK 2002 and 2001, respectively, and 11% and 13% of products net revenue in therJ first nine months of fiscal 2002 and 2001, respectively. While our product mix C fluctuates from quarter to quarter, we expect over the long-term an 
 increasingK percentage of products net revenue will be from server and storage productsr andnD a decreasing percentage of products net revenue will be from desktop	 systems."t  L "In the third quarter of fiscal 2002, products gross margin decreased by 0.5K percentage point, as compared with the corresponding period of fiscal 2001.n TherL 0.5 percentage point decline in products gross margin was primarily a result ofK reductions in product pricing (normal price list reductions and competitive-E transaction pricing), which were substantially offset by decreases inm productmE costs (lower vendor product component costs and lower product quality- costs)."  L "In the first nine months of fiscal 2002, products gross margin decreased by 9.5@L percentage points, as compared with the corresponding period of fiscal 2001.G Substantially all of the 9.5 percentage point decline in products grosso marginK in the first nine months of fiscal 2002, as compared with the corresponding.L period of fiscal 2001, was due to: (1) reductions in product pricing (normalI price list reductions and competitive transaction pricing); (2) increaseduD product platform transition costs associated with the migration fromC UltraSPARC II to UltraSPARC III; and (3) lower volumes of productsnL manufactured. These impacts were exacerbated by a period of rapid decline in products net revenue."  4 "Adverse Business Conditions in Specific Industries.   We depend on theI telecommunications, financial services and manufacturing industries for aaH significant portion of our revenues. Significant reduction in technologyK capital spending in these industries caused by adverse economic conditions,yH such as we experienced over the last two quarters of fiscal 2001 and the first B three quarters of fiscal 2002, may continue to result in decreasedL revenues and earnings. Our revenues are dependent on the level of technology capitalaF spending in the United States and international economies. A number ofH companies recently filed for bankruptcy protection, and others announcedD significant reductions and deferrals in capital spending. If capital spendingI continues to decline in these industries over an extended period of time,I ourR1 business will continue to be adversely affected."   ! "Our stock price can be volatile.   J Our stock price, like that of other technology companies, can be volatile. ForsJ example, our stock price can be affected by many factors such as quarterlyE increases or decreases in our earnings; speculation in the investmenty	 communitymE about our financial condition or results of operations and changes inr revenueJB or earnings estimates, announcement of new products, technologicalI developments, alliances, acquisitions or divestitures by us or one of our-B competitors. In addition, general adverse macroeconomic and market
 conditionsH unrelated to our performance may also adversely affect our stock price."     >DK >> The longer the industry slump continues, the higher the probability thatcL >> only the strong (balance sheets) will survive.  Sun's current stock priceF >> and market capitalization may make it a target for a takeover - who knows -hE >> maybe Fujitsu will buy you - or some enterprising Defense industrye companyi >> might :-) >> >d@ >I doub't it Sun's stock is low because of the economic downturn= >very few companies have either the cash or the guts during ao= >downturn to stump up the kind of money needed for a purchaset9 >of this type in these market conditions. Nice FUDDY spino >though. >l  E *I'm* not the first - or the last - that has suggested that this is aeF possibility.  In fact you are wrong about it not being a good time forE aquisitions.  This is exactly the time where these things can happen.c  8 >As an alternative how about spinning out the profitable3 >printing business in HP and ditching the rest in a 8 >garage sale now that just might give your stock holders >a nice return.  >t   Nice try at FUD yourself.e  9 From your SEC filings - your employer takes us seriously:D  J "Our competitors are some of the largest, most successful companies in theF world. They include International Business Machines Corporation (IBM),K Hewlett-Packard Company (HP), Compaq Computer Corporation (Compaq), and EMCtL Corporation (EMC). Our future competitive performance depends on a number ofH factors, including our ability to: continually develop and introduce newK products and services with better prices and performance than those offered, byH our competitors; offer a wide range of products and solutions from small singleL processor systems to large complex enterprise level systems; offer solutions toF customers that operate effectively within a computing environment that includesD hardware and software from multiple vendors; offer products that are reliableI and that ensure the security of data and information; create products for  whichpK third party software vendors will develop a wide range of applications; andwH offer high quality products and services. Two of our competitors, HP andI Compaq, have merged, creating an entity that is significantly larger than  Sun.K To the extent that they are successful in integrating their businesses, theaI combined company could have greater access to resources, and our business  andaJ operating results could be adversely affected by the increased competitive pressures."d   ------------------------------  # Date: Tue, 20 Aug 2002 18:57:41 GMTt5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> + Subject: Re: HP-Compaq Merger Went Smoothlyt2 Message-ID: <Fiw89.26$v47.827535@news.cpqcorp.net>  = JF Mezei wrote in message <3D628D4C.8CA221C9@videotron.ca>...o >Fred Kleinsorge wrote: I >> products, and it's direction.  From a pure stock play perspective, Sund haslL >> shown little evidence that it will make it's slight profit prediction forE >> the fiscal year ending in 2003.  Nor has the tech market shown anye evidence >> of a turn around in general.- > I >However, two important stocks used by the wall street casino analysts tocI >determine the faith of "tech" are Cisco and Sun. When either report goody news,5J >the stock goes up, when they report bad news, the stock market goes down. ThisH >was most certaintly the case during the .COM era and at least util very	 recently.w >rL >It is in that sense that Sun has a far more important position in the stockK >market than HP which is all but ignored since it never sets market trends,o it
 >trails them.a  J Let's see, you are trying to say that the fact that Cisco and Sun were theF leading indicators in the dot.bomb somehow makes them "trend setters".E Interesting financial analysis.  Meaningless, but interesting in some,? historical way when we write the history of the dot.bomb years.e  I So how exactly does that relate to my comment?  Was there someplace I washF comparing Sun to HP?  HP has twice the market capitalization as Sun, I+ expect that HP can move the market as well.t   ------------------------------  % Date: Tue, 20 Aug 2002 16:12:53 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>i+ Subject: Re: HP-Compaq Merger Went Smoothly:, Message-ID: <3D62A2BC.23A46EDE@videotron.ca>   Fred Kleinsorge wrote:K > So how exactly does that relate to my comment?  Was there someplace I was H > comparing Sun to HP?  HP has twice the market capitalization as Sun, I- > expect that HP can move the market as well.'  M No , that was my point. The media and wall street casino analysts based their M guidance/recommendations on the guidance and performance of Sun and Cisco foriL the technology sector. This may not be as much the case today as it was lastK year. But HP wasn't in the ballpark of having the amount of influence Ciscoc and Sun had.  G Not too long before 9/11, I remember Chambers announcing that Cisco was I predicting a rise in sales,  and both the dow and nasdaq that day climbedmN furiously on those news, and it was reported as such on CNN ("climbed based on the positive news from cisco").8  J I am not saying that this is right. Just saying that this is/was the case.  N What this means is that the media and analysts are seing SUN and CISCO as moreI important than HP when the time comes to predicting the future since theye& are/were seen as leading the industry.   ------------------------------  # Date: Tue, 20 Aug 2002 21:15:28 GMTs5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>d+ Subject: Re: HP-Compaq Merger Went Smoothlya2 Message-ID: <Qjy89.33$iH6.251035@news.cpqcorp.net>  = JF Mezei wrote in message <3D62A2BC.23A46EDE@videotron.ca>...  >Fred Kleinsorge wrote:yL >> So how exactly does that relate to my comment?  Was there someplace I wasI >> comparing Sun to HP?  HP has twice the market capitalization as Sun, Ie. >> expect that HP can move the market as well. >cH >No , that was my point. The media and wall street casino analysts based their-J >guidance/recommendations on the guidance and performance of Sun and Cisco for<H >the technology sector. This may not be as much the case today as it was lastL >year. But HP wasn't in the ballpark of having the amount of influence Cisco
 >and Sun had.i >e  K So did pets.com, and other toes-up dot coms.  It had very little to do withe anything rational.  H >Not too long before 9/11, I remember Chambers announcing that Cisco wasJ >predicting a rise in sales,  and both the dow and nasdaq that day climbedL >furiously on those news, and it was reported as such on CNN ("climbed based on  >the positive news from cisco"). > K >I am not saying that this is right. Just saying that this is/was the case.  >jJ >What this means is that the media and analysts are seing SUN and CISCO as moreJ >important than HP when the time comes to predicting the future since they' >are/were seen as leading the industry.5  L I'm not quite sure that is the case today.  But in any case, I'm not exactlyL sure how this relates to anything I've said.  Someone - perhaps it was you -I suggested that HPQ stock was floundering, and SUNW was seing gains - welleG that is not true and easily verified as long as you factor out specifictA daily swings - over the last 3 months, 9 months or a year HPQ hasa2 outperformed SUNW.  Both unfortunately going down.  J Andrew, in his own special way tried to change the argument into somethingK else - market share and his own prognostications over the prospects for SUN.I and HP.  Of course, I think he cheated on the facts and resorted to fuzzyaJ data.  So I responded with some pointers to the actual financial data, andI the SUN quarterly filings that don't agree entirely with his optimism forn SUNs prospects.r   ------------------------------  % Date: Tue, 20 Aug 2002 17:25:57 -0400r' From: "Main, Kerry" <Kerry.Main@hp.com>c+ Subject: RE: HP-Compaq Merger Went SmoothlyeT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266094A@kaoexc01.americas.cpqcorp.net>   JF,   G Not that it is likely any argument will change your mind and I am not =o8 arguing for or against the Alpha cancellation, however -  I That particular RFP you referred to was based on the Govt moving from a =bG mainframe environment to a new SAP based solution that was integrated = G with all of the various pieces that it needed to. It was not based on =o' moving from a mainframe to Alpha/Tru64.e  I If they need more capacity in the short term, they can upgrade from the =k; 750Mhz cpu modules to the new 1.25Ghz GS Series modules. EV2  I If they need additional crunching capacity in 2-6 years, then EV7 based =s@ Tru64 UNIX servers will provide leading edge SAP performance.=20  < Might some adjustments be needed in 4-7 years (beyond EV7) ?  F Sure, but all large Govt dept's include major upgrades in their long =H range plans. For those Customers migrating from Tru64 UNIX to HP-UX on =G IPF (say in 4-6 years), they will also get a great deal of assistance == from HP.          
 Kerry Main Senior Consultanta Hewlett-Packard Canada! Consulting & Integration Servicesi Voice: 613-592-4660. Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20_ Sent: August 20, 2002 2:06 PM  To: Info-VAX@Mvb.Saic.Como+ Subject: Re: HP-Compaq Merger Went Smoothly-     "Main, Kerry" wrote:  J > Do you really think those at the top that signed the contract know the =   >difference between anH >Alpha or a SPARC or a Power4 or what the difference between HP-UX and = Solarisg
 and Tru64 is?d  I But they know that Compaq had committed to long term Alpha development, =wH and that Compaq broke that commitment months later. By now, they would =F also know that Compaq, as a corporation, was fully aware that it was =I lying to customers when it was making such commitments since it already =b+ knew that Alpha would be cancelled shortly.n  I Furthermore, Compaq lied to customers on June 25 when it announced that =tD Tru64 was to be ported to IA64 since Compaq, as a corporation, was =@ already engaged into the merger talks with Carly with detailed =4 discussions on product roadmaps already in progress.    J > So what do you say to Customers that bought lots of IBM disk drives in =   >the months leading up toa@ >the point where IBM sold its disk drive business to Hitachi?=20  G Disk drives are not an "architecture". You can replace drives without =@5 having to change your software, renegotiate licence =SJ agreements/transfers, recertify your application and mount a large scale =J migration in-house project. In the case of the Qu=E9bec government, they =I were embarking on a long term migration from IBM to Alpha-Tru64 and had = > the rug pulled from under them months after the project began.   ------------------------------  # Date: Tue, 20 Aug 2002 22:51:47 GMTs# From: "John Smith" <a@nonymous.com> + Subject: Re: HP-Compaq Merger Went SmoothlyeG Message-ID: <7Kz89.3449$bu81.3382@news02.bloor.is.net.cable.rogers.com>y  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D628D4C.8CA221C9@videotron.ca... > Fred Kleinsorge wrote:J > > products, and it's direction.  From a pure stock play perspective, Sun hasgI > > shown little evidence that it will make it's slight profit predictiona forrF > > the fiscal year ending in 2003.  Nor has the tech market shown any evidence  > > of a turn around in general. >eJ > However, two important stocks used by the wall street casino analysts toJ > determine the faith of "tech" are Cisco and Sun. When either report good news, K > the stock goes up, when they report bad news, the stock market goes down.i ThisI > was most certaintly the case during the .COM era and at least util verye	 recently.  >SG > It is in that sense that Sun has a far more important position in ther stockwL > market than HP which is all but ignored since it never sets market trends, it > trails them.   Nope. Cisco, Dell, and IBM.n   ------------------------------    Date: 20 Aug 2002 17:57:02 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)c+ Subject: Re: HP-Compaq Merger Went Smoothlyh= Message-ID: <cf15391e.0208201657.61030dad@posting.google.com>o   "Main, Kerry" <Kerry.Main@hp.com> wrote in message news:<BE56C50EA024184DAF48F0B9A47F5CF402660931@kaoexc01.americas.cpqcorp.netsJ > Well, given MVS (now called OS/390 I believe) environments are typicallyH > extremely heavy batch environments and given MVS  has extremely strongI > clustered batch solutions that can be balanced over multiple servers ataC > multiple sites (multi-site Parallel Sysplex is similar to OpenVMSd > multi-site clusters)  D You're being too kind to IBM, Kerry.  Based on the info at IBM's web site:s  B Don't confuse load balancing within a Parallel Sysplex at one siteF with a Geographicaly-Dispersed Parallel Sysplex (GDPS) configuration. D Introducing the second site appears to put one into a primary/backupB situation with respect to disks, which would seem to preclude loadF balancing of a given application across sites.  Failover to the secondC site involves a database restart (although a database recovery fromvF journals or logs is not needed, they say) and an application startup. > So systems at the remote site appear more likely to be runningE nothing, or test and development work at best, than actual productions	 workload.e  D There are two data replication methods possible in a GDPS multi-site? cluster, the hardware-based PPRC and the hardware-assisted XFC.   A When using PPRC as the disk mirroring method (which, like HBVS onsD OpenVMS, does not return I/O success status to the application untilE the data lands at both the local site and the remote site, too), GDPSeC clusters are limited to a maximum of 40 km, or about 26 miles (overiD fiber optics, not ATM, not DS-3) and allow one to achieve a RecoveryD Point Objective (RPO) of "minimal or no data loss", as IBM puts it. ? Reassuring, that.  Recovery Time Objective is 1 hour, they say.d  B When using XRC as the disk mirroring method, I/O success status isC returned to the application when the data reaches the local storages@ subsystem, with the writing of data to the remote site occurringE asynchronously.  The System Data Mover component of DFSMSdfp (and you9A thought our acronyms were bad?) is used to grab the data from thetD primary storage subsystem's cache and update the disks at the remoteD site.  This asynchronous replication method will result in some lostF data when the primary site fails, but the use of XRC does allow longerD distances between sites.  This gives an RPO of "less than 2 minutes"E of data lost, which they call "minimal data loss", and an RTO of 1 tou 2 hours.  F Compare this to an OpenVMS Disaster-Tolernat cluster: RPO of zero dataC loss, and an RTO in the single-digit seconds range, and support ford+ inter-site distances of 800 km (500 miles).o. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  # Date: Wed, 21 Aug 2002 02:07:46 GMTs* From: "Bill Todd" <billtodd@metrocast.net>+ Subject: Re: HP-Compaq Merger Went SmoothlyrB Message-ID: <SBC89.102848$2p2.4809800@bin4.nnrp.aus1.giganews.com>  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message7 news:cf15391e.0208201657.61030dad@posting.google.com...p4 > "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:<BE56C50EA024184DAF48F0B9A47F5CF402660931@kaoexc01.americas.cpqcorp.netL > > Well, given MVS (now called OS/390 I believe) environments are typicallyJ > > extremely heavy batch environments and given MVS  has extremely strongK > > clustered batch solutions that can be balanced over multiple servers atrE > > multiple sites (multi-site Parallel Sysplex is similar to OpenVMSe > > multi-site clusters) >lF > You're being too kind to IBM, Kerry.  Based on the info at IBM's web > site:a >rD > Don't confuse load balancing within a Parallel Sysplex at one siteG > with a Geographicaly-Dispersed Parallel Sysplex (GDPS) configuration.aF > Introducing the second site appears to put one into a primary/backupD > situation with respect to disks, which would seem to preclude loadH > balancing of a given application across sites.  Failover to the secondE > site involves a database restart (although a database recovery from G > journals or logs is not needed, they say) and an application startup.u@ > So systems at the remote site appear more likely to be runningG > nothing, or test and development work at best, than actual production  > workload.n  L Indeed.  But my impression (and I could easily be wrong) is that this simplyK reflects IBM's unwillingness to extend a single (non-GDPS) Parallel Sysplex H system across as large a geographic distance as some VMS clusters cross.  E In other words, I think the main difference is a distance limitation.pE Within IBM's more limited distance, a Sysplex offers the same kind ofrL non-stop operation that a VMS cluster offers.  Beyond that limit, IBM offersH only GDPS-style fail-over to a stand-by system (which I suppose could beF doing other useful work while waiting for the primary to fail, but notK accessing its local copy of the primary's database), while VMS still offersnI its normal non-stop clustering solution up to some higher distance limit.   L My even vaguer impression is that the lower IBM distance limit is associatedB with its hardware-level 'coupling facility' (CF) operations, whichL coordinate Sysplex activities in something like the way the distributed lockL manager does in a VMS cluster.  The CF potentially offers higher performanceL than DLM-style synchronization, but may have considerably tighter tolerancesK on comm delays.  I think a normal (non-GDPS) Sysplex can easily extend overeI campus distances, but something like 10 km may be its limit (you may haveaG encountered this in your reading in this area, which is likely far moree recent than mine).   > F > There are two data replication methods possible in a GDPS multi-siteA > cluster, the hardware-based PPRC and the hardware-assisted XFC.m >oC > When using PPRC as the disk mirroring method (which, like HBVS ontF > OpenVMS, does not return I/O success status to the application untilG > the data lands at both the local site and the remote site, too), GDPSaE > clusters are limited to a maximum of 40 km, or about 26 miles (overvF > fiber optics, not ATM, not DS-3) and allow one to achieve a RecoveryE > Point Objective (RPO) of "minimal or no data loss", as IBM puts it.mA > Reassuring, that.  Recovery Time Objective is 1 hour, they say.   H Most of which time may be due to operations (i.e., human) latency, sinceI that's a configuration where the remote system should just be able to run F normal reboot recovery on the database and run.  OTOH, with very largeL system caches (full of persistent dirty data that has yet to be written backK to the database, even though stabilized by log entries) the reboot recovery   process itself can take a while.  G My guess is that the 'minimal or no data loss' may reflect operation inwL which the remote system ACKs the data as soon as it receives it, rather thanK waiting for it to get to disk.  This would allow the transit time (at about L 10 us/mile, each way) to be overlapped with the primary system's disk-accessG latency even if that 'disk' is in fact solid-state.  As long as failurenL modes at the two locations are indeed truly independent, then one can assumeI that if the data arrives at the remote site then the probability that thetH primary will fail *right then* and also the remote site will fail in theD small fraction of a second before it gets that data to disk is trulyI negligible - but the 'minimal or' portion of the phrase may refer to thatt probability.   > D > When using XRC as the disk mirroring method, I/O success status isE > returned to the application when the data reaches the local storagesB > subsystem, with the writing of data to the remote site occurringG > asynchronously.  The System Data Mover component of DFSMSdfp (and youhC > thought our acronyms were bad?) is used to grab the data from theiF > primary storage subsystem's cache and update the disks at the remoteF > site.  This asynchronous replication method will result in some lostH > data when the primary site fails, but the use of XRC does allow longerF > distances between sites.  This gives an RPO of "less than 2 minutes"G > of data lost, which they call "minimal data loss", and an RTO of 1 to 
 > 2 hours.  @ One should remember that the 'data loss' is not random, but veryF specifically the minute or so (worst-case) worth of transactions:  theK recovered data is consistent, just not quite (by that amount of time) up tohI date.  And *typical* loss may be much less than that:  if they're pumpingaH out changes as fast as they can, then the only reason to get behind moreG than a few disk writes is because of a write burst that the remote link I can't handle at disk (or array) speed (presumably they provide a settable J limit that defaults to 2 minutes, and start throttling local operations if the link gets that far behind).e   >pH > Compare this to an OpenVMS Disaster-Tolernat cluster: RPO of zero data > loss  A At noted above, I suspect that the synchronous GDPS approach alsosA effectively has zero data loss:  if not, I'd be interested in thel" explanation of how it can lose it.  ? , and an RTO in the single-digit seconds range, and support for8- > inter-site distances of 800 km (500 miles).y  J Which generates a 1000-mile round-trip distance, or about 10 ms.  IIRC youL were the source of the information that it actually takes *2* round trips toI complete the write, which just about quadruples the write latency even if B you're using conventional disks to store the data; if you're usingH solid-state disks (or even just stable controller-level write-back cacheK that can make write latencies *appear* to be sub-millisecond as long as the.H write density doesn't overwhelm the cache), it increases perceived writeK latency by *well* over an order of magnitude.  My guess is that solid-statesK storage may be considerably more common in Sysplex environments than in VMSt systems.  J In other words, I suspect that a good many Sysplex installations would optD for asynchronous replication over such distances even if synchronousF (VMS-style) replication were available to them, simply for performanceK reasons.  And since performance is supposedly why Sysplex went the hardwarewL CF route rather than the DLM route (which they did evaluate), it's not clearL that IBM or its customers see VMS's single approach to the distance issue asE preferable (especially as there's essentially *no* distance limit foroK asynchronous replication, which IIRC VMS does not offer:  if it did, *then* I I'd start to consider VMS as having a clear advantage, because memory ande? processor advances do keep improving software DLM performance).p   - bill   ------------------------------    Date: 20 Aug 2002 14:58:26 -0700% From: whohe@whoever.com (DL Phillips) I Subject: Re: Licenses (was Re: Charon-VAX (was: [VAX] VMS to [Alpha]...)) = Message-ID: <af0dc2ea.0208201358.570feb4a@posting.google.com>   e Alan Greig <a.greig@virgin.net> wrote in message news:<te74mu0804o9hl99adcars24quthmjvb9h@4ax.com>...n >y@ > My recollection is that all Alphas sold in standard configs byB > DEC/Compaq came with some form of network integration license. IA > certainly recall our first machines (DEC 3000-400 April 1993 orsG > earlier) came with a license which allowed the use of UCX even though F > Alpha UCX was not yet out of beta test. Oh how our Unix support guysF > laughed when they discovered that DEC had released Alpha/VMS with noC > TCPIP support. IIRC Multinet (and/or TCPWARE) was out before UCX.t >    Alan,   B Thank you for your concern, but this Alpha was purchased sometime C in the late 1980's or early 1990's and it does not have UCX or NSA sC or any networking license other than DECNET End-Node. Trust me whenn I say I've searched.  H UCX had to be ordered as a separate line item then and on this system itG was not. That was standard practice with early VMS/AXP. My recollectionc< is that this little beauty started life with v1.(something).  E I vaguely remember upgrading it to v6(.2 I think) before someone else> took over those duties.s   -DLP   -------------------e   ------------------------------    Date: 20 Aug 2002 17:48:30 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)rI Subject: Re: Licenses (was Re: Charon-VAX (was: [VAX] VMS to [Alpha]...))w3 Message-ID: <l4vpHAWl2O0K@eisner.encompasserve.org>o  e In article <af0dc2ea.0208201358.570feb4a@posting.google.com>, whohe@whoever.com (DL Phillips) writes:   D > Thank you for your concern, but this Alpha was purchased sometime E > in the late 1980's or early 1990's and it does not have UCX or NSA f   Certainly not in the 1980's :-)a   ------------------------------  % Date: Wed, 21 Aug 2002 08:22:52 +0800n) From: "Steven Xie" <r33300@email.mot.com>j Subject: Re: Memory Slot?e+ Message-ID: <ajumhr$mab$1@newshost.mot.com>t  K That's really what I want, Thanks!!! Just wondering that why on the on-lines' help of lexical there is no such thing?    StevenK "Bart Z. Lederman" <lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com> wrote in 4 message news:djs89.14$pU6.506925@news.cpqcorp.net...6 > I'm not sure how much 'easier' it's going to be, but( > you can get information via a lexical. >M  > value = F$GETSYI ("BAL_SLOTS")! > value = F$GETSYI ("PROC_SLOTS")m >i4 > What comes back is one long string with all of the0 > values in HEX, which you will have to separate > and convert, as in >l+ >  WRITE SYS$OUTPUT F$GETSYI ("PROC_SLOTS")l" > 00000005000000280000005300000080 >e > This correspondts to:d >e > $ sho mem/slotB >               System Memory Resources on 20-AUG-2002 10:15:17.69 >=B > Slot Usage (slots):                Total        Free    Resident Swapped B >   Process Entry Slots                128          83          40 5sB >   Balance Set Slots                  126          88          38 0w >fA > You can see how the value returned has the figures for Swapped,h > Resident, Free and Total.  >  > --* >  B. Z. Lederman   Personal Opinions Only >e: >  Posting to a News group does NOT give anyone permission: >  to send me advertising by E-mail or put me on a mailing >  list of any kind. >d7 >  Please remove the "DISABLE-JUNK-EMAIL" if you have a=7 >  legitimate reason to E-mail a response to this post.  >    ------------------------------  % Date: Tue, 20 Aug 2002 22:42:53 +0100 1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>l  Subject: Re: New missive from HP5 Message-ID: <3D62C5ED.E3338C0@ipl.demon.co.nospam.uk>n  G I suspect that Terry is very right in this and would suspect that viewseA of members of HP or Compasq management being idiots are less thana
 helpful Bill.   F At times, we all disagree with decisions that are made.  Whether it beG the decision of the traffic warden to put the parking ticket on our car H or the boss at telling us we can't take the day off for the kids' sports? day or whatever.  It doesn't make them idiots, they just have as different opinion.  G I've had a conversation with someone close to those who know which goesDH some way to echoing Terry's comments.  The words "[such a rant] severely hurts VMS" stuck in my head.  E Is it just my memory that is failing when I think back to a time whennD most of what was on comp.os.vms was helpful, constructive, technical3 information rather than constant political battles?h  H Get a grip guys, the world's changed.  Arguments of whether manager X orD VP Y could have done things better probably won't get any of us veryG far.  Besides, HP didn't create any mess with VMS and the company whichaC might have done is now just a wholly owned subsidiary of HP so it'sc> unhelpful to be casting accusations around when there's little( foundation to the who did what and when.  3 In my opinion, speaking for myself and nobody else.r   Steve.       Bill Todd wrote: > > > "Terry C. Shannon" <terryshannon@attbi.com> wrote in message* > news:fuh89.105244$me6.13237@sccrnsc01... >  > ...w > K > > Positive action is indeed necessary, negative tone is contraproductive.  > K > 'Positive action' is what was tried for close to a decade before 6/25/01.0G > The results were monumentally ineffective.  Negative tone is not onlyjD > entirely appropriate at this point, but also the only avenue left. >  >  InaM > > fact, I have it on VERY reliable authority that a Level One (read MC) waswG > > ready to scuttle the whole damned VMS thing last fall after all thes	 > rantingi > > and raving.e > F > Which is not all that surprising:  he's clearly an idiot, and such a) > reaction would be consistent with that.g > N > Since the ranting and raving is not about to stop until such time as cHumPaqG > makes some real, as well as visible, effort to clean up the mess theyiJ > created over a year ago, your information will hardly reassure those who, > would hope for better times ahead for VMS. >  > - bill   -- SG "A shadow fell over her face; clear, as if the composure were rent like)E a veil.  And her lips parted, but only with a short intake of breath. A Then she said, 'Well, then you are right.  Indeed, we are even.'"o% 		Louis, "Interview with the Vampire"p   ------------------------------  # Date: Tue, 20 Aug 2002 23:01:28 GMTr# From: "John Smith" <a@nonymous.com>f  Subject: Re: New missive from HPF Message-ID: <cTz89.3467$bu81.731@news02.bloor.is.net.cable.rogers.com>  < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:fuh89.105244$me6.13237@sccrnsc01... >oL > Positive action is indeed necessary, negative tone is contraproductive. InK > fact, I have it on VERY reliable authority that a Level One (read MC) wasuE > ready to scuttle the whole damned VMS thing last fall after all thed rantinge
 > and raving.s >a7 > Obviously this did not happen, which is a Good Thing.l >l >t    L I think what that quite effectively demonstrates is the vacuum Compaq seniorJ management operated in when it came to understanding their customers, VMS,L and its place in the enterprise space. So in a fit of pique, MC comes within+ a whisker of slitting the company's throat?j  J In medical terms, operating this way is called schizophrenia...but there'sF medication for that. By the sounds of it, maybe Carly is a blessing in	 disguise.t  J BTW, haven't heard too much about good old MC these days. What's he up to?8 Hanging out with Dick Cheney in an undisclosed location?   ------------------------------  # Date: Wed, 21 Aug 2002 00:55:13 GMTh* From: "Bill Todd" <billtodd@metrocast.net>  Subject: Re: New missive from HPA Message-ID: <RxB89.91999$m91.4487366@bin5.nnrp.aus1.giganews.com>a  > "Steve Reece" <SYSTEM@ipl.demon.co.nospam.uk> wrote in message/ news:3D62C5ED.E3338C0@ipl.demon.co.nospam.uk...fI > I suspect that Terry is very right in this and would suspect that viewsaC > of members of HP or Compasq management being idiots are less thano > helpful Bill.P  H The point of trying to be 'helpful' is long past; in fact, it ran out onH 6/25/01.  The idea since that date is to ensure that their arrogance andL stupidity are kept fully in front of current and prospective customers, suchK that sufficient (entirely appropriate) financial pain occurs to *force* themK kind of changes that 'playing nice' has been utterly ineffective in causingo for close to a decade.   >2H > At times, we all disagree with decisions that are made.  Whether it beI > the decision of the traffic warden to put the parking ticket on our cartJ > or the boss at telling us we can't take the day off for the kids' sportsA > day or whatever.  It doesn't make them idiots, they just have ao > different opinion.  K Disagreeing per se is not what makes them idiots:  the relative *merits* ofeH the situation are what make them idiots.  I hope you're not one of thoseK sophomoric types who believes that everything is 'just a matter of opinion's. with no objective right or wrong, good or bad.   >MI > I've had a conversation with someone close to those who know which goesaJ > some way to echoing Terry's comments.  The words "[such a rant] severely > hurts VMS" stuck in my head.  H If that's true, it's just one more proof of the incompetence of those inL charge:  competent individuals view justifiable criticism as an opportunity,L not an annoyance.  You may choose just to accept their attitude and hope forC the best.  I do not:  some actions I simply do not find acceptable.e   >lG > Is it just my memory that is failing when I think back to a time when F > most of what was on comp.os.vms was helpful, constructive, technical5 > information rather than constant political battles?   G You can thank Compaq for the change.  And most of those responsible areo& still in positions of authority at HP.   > J > Get a grip guys, the world's changed.  Arguments of whether manager X orF > VP Y could have done things better probably won't get any of us veryI > far.  Besides, HP didn't create any mess with VMS and the company whichhE > might have done is now just a wholly owned subsidiary of HP so it's @ > unhelpful to be casting accusations around when there's little* > foundation to the who did what and when.  F If you believe there's 'little foundation', then you just haven't beenG paying attention.  And as noted above, many of the same individuals areiI still calling the plays - so the incompetence and perfidy haven't changeds even if the company name has.o   - bill   ------------------------------  % Date: Tue, 20 Aug 2002 21:52:11 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>t  Subject: Re: New missive from HP, Message-ID: <3D62F249.1C9D07AC@videotron.ca>   Steve Reece wrote:I > I've had a conversation with someone close to those who know which goeseJ > some way to echoing Terry's comments.  The words "[such a rant] severely > hurts VMS" stuck in my head.  H If your customers have rants against you, what should you do ? Tell yourI customers to shut up, go away, or do you listen to your customer and heed ? their suggestions and change the way you present your product ?e    I > far.  Besides, HP didn't create any mess with VMS and the company whichp= > might have done is now just a wholly owned subsidiary of HPh  M Sorry. HP bought Compaq lock stock and barrel. HP was fully aware of the JunedL 25 decision, and would have been aware of how poorly received it was by manyH customers, despite the failed propaganda attempst from Compaq to make it: appear that customers were happy and trusted their vendor.   M Then came the "ignore VMS" during Carly's pregnancy with "don't worry, on may)L 7th, we'll have a fully developped and extremely clear product roadmap whichE we have had plenty of time to prepare". Come may 7th ,a product whichcL generates huge sums of profits only gets one meaningless sentence. Worse, weK also get Stallard's memo that says that HP expects VMS customers to migratel over to HP-UX over time.  I We are not asking HP to spend inordinates amounts of money on VMS. We arecG asking for very simple stuff: honest handling of our favourite product.t  H If there aren't any employees who are aware of customer's sensitivities,L plenty of us have made plenty of suggestions on how thinsg should be handled# to reduce/eliminate customer rants.h  G If HP really wants VMS and would like to fix the problem of disgruntlednM customers, there are very simple solutions that don't cost much. It is just aiH matter of leadership and ensuring that no text/advertising go out to theM puhlic without being worsmithed by a VMS-aware person to ensure stuff such ast# Stallard's memo never go out again.e  H There are very simple solutions to the problem, but the onlyt conclusion8 possible is that HP choses NOT to enact those solutions.   ------------------------------  # Date: Wed, 21 Aug 2002 03:29:11 GMTb1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e  Subject: Re: New missive from HP' Message-ID: <3D630DFF.1F79E551@fsi.net>t   Steve Reece wrote: > I > I suspect that Terry is very right in this and would suspect that viewslC > of members of HP or Compasq management being idiots are less thanh > helpful Bill.   B I'd have to agree, but at the same time I've seen much evidence to support such a claim.(  H > At times, we all disagree with decisions that are made.  Whether it beI > the decision of the traffic warden to put the parking ticket on our car J > or the boss at telling us we can't take the day off for the kids' sportsA > day or whatever.  It doesn't make them idiots, they just have ar > different opinion.   Hold that thought...  I > I've had a conversation with someone close to those who know which goessJ > some way to echoing Terry's comments.  The words "[such a rant] severely > hurts VMS" stuck in my head.  5 Well, now we start to get to the root of the problem.o  G IMHO, it appears to be a case of the effect being blamed FOR the cause,i3 rather than the effect being blamed *ON* the cause.s  H Example: Were the colonists at fault for staging the Boston Tea Party or4 was the Crown at fault for imposing unfair taxation?  D Example: Was America at fault for building the World Trade Center or@ were the terrorists at fault for destroying it? (Warning: loaded
 question!)  F Question: Is it "our" fault for complaining about the mismanagement ofD VMS or is it HP/Q's fault for trying to kill their own cash-cow (and+ destroying our livelihoods in the process)?o  E It might be nice to have the cart in front of the horse - the sceneryeB would be a lot better, as would the aroma. Volkswagen, the RenaultC Dauphine and even the Chevrolet Covair tried to do exactly that, innH their own way. I rather doubt that it will ever be practical with horses7 and carts, however. Cars are another question entirely.   H HP/Q *KNOWS* how to stop the, as some put it, "whining": market the hellH out of VMS and make profits they can only dream of otherwise. Of course,H everyone knows that will never happen. At least, not until there is some( positive resolution to the IPF question.  2 Does Bill Gates have *EVERY*one *THAT* bamboozled?  G > Is it just my memory that is failing when I think back to a time whentF > most of what was on comp.os.vms was helpful, constructive, technical5 > information rather than constant political battles?o > ' > Get a grip guys, the world's changed.c  C Indeed it has. Windows licensing policies are now costing it market - share, with Linux ascending to fill the void.s  H What better time to pull VMS's head out of, erm, the sand(! Yeah, that's$ it!) and get on the New Gravy Train?  0 Now, back to the issue of difference of opinion.  H As Terry pointed out, people in position to actually do it view "killingH the goose that lays the golden eggs" as a good thing, while the world isC still on a gold standard (more or less). Some (many? ...very many?)s would disagree.e  C ...and yes, MC can do as he damned well pleases. After all, Carly'sp7 gotta take the heat from the stockholders now, not him.n   --   David J. DachteraM dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Wed, 21 Aug 2002 00:02:15 -04000- From: JF Mezei <jfmezei.spamnot@videotron.ca>c  Subject: Re: New missive from HP, Message-ID: <3D6310BC.80F42C68@videotron.ca>   "David J. Dachtera" wrote:J > HP/Q *KNOWS* how to stop the, as some put it, "whining": market the hell@ > out of VMS and make profits they can only dream of otherwise.   L Right now, I would say that they wouldn't need to market the hell out of MS.N Expectations have been lowered to a pont where an very public  acknowledgementH by Carly on TV that HP intends to leverage the full potential of VMS andL unleash it as a weapon against its competitors because none of their systemsK cab approach VMS's clustering capabilities would go a VERY long way towardssF reassuring VMS customers that HP does intend to do something with VMS.  L But as long as VMS is being ignored by upper management, then any attempt byK the lower grunts will have limited impact because while we appreciate theirvK efforts, we still do not trust the upper management who are known for theire$ ability to pull stunts like June 25.   ------------------------------  % Date: Tue, 20 Aug 2002 21:35:50 -0400.) From: "Neil Rieck" <n.rieck@sympatico.ca>A" Subject: Re: NewHp & VMS Licensing9 Message-ID: <a8C89.4141$xL1.782582@news20.bellglobal.com>   3 >"Main, Kerry" <Kerry.Main@hp.com> wrote in messageeL >news:BE56C50EA024184DAF48F0B9A47F5CF402660942@kaoexc01.americas.cpqcorp.net ...- >Neil, >- [...snip...] >2I >Re: Herzberg Rd sign - well, I was in that office a few days ago and did:I >not notice it, so I am assuming it still says Compaq. I do know they are-5 >looking at getting it changed pretty quickly though.c >< [...snip...]  F I had spent quite a bit of time (16 weeks total) there in the customerE education center in the mid 1980s.  Because of those fond memories, ImI decided to drive past the building two weeks ago while on vacation. I was K surprised to see that 3 out of the 4 buildings of that campus were occupied ' by other companies. How times change...S  
 Neil Rieck Kitchener/Waterloo/Cambridge,R Ontario, Canada.! http://www3.sympatico.ca/n.rieck/m   ------------------------------  # Date: Tue, 20 Aug 2002 22:33:26 GMTo# From: "John Smith" <a@nonymous.com> " Subject: Re: OpenVMS + Joint STARSH Message-ID: <Wsz89.48612$8aG1.1520@news01.bloor.is.net.cable.rogers.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:Tvu89.20$bX6.579606@news.cpqcorp.net... > ! > Alan Greig wrote in message ... C > >In article <1ws89.15$AT6.492702@news.cpqcorp.net>, "Fred says...  > >>J > >>Ah...  That's a year old story.  Not to say it wasn't good, or that we doL > >>not continue to work with NG in Melbourne on the next generation planes. > >_3 > >Just don't mention the anti-grav engines ok? :-)h > >r >pL > Mentioning the anti-grav is OK, as are the dilithium crystals - that's allI > unclassified/declassified.  But *never* mention the trans-warp conduit.     . Or the restaurant at the edge of the universe.   ------------------------------    Date: 20 Aug 2002 21:36:44 -0700 From: ohm62@hotmail.com (OHM) F Subject: Re: P.Thread: setting RR scheduling policy on default thread?= Message-ID: <9d337b47.0208202036.3b4883ba@posting.google.com>B  f David Butenhof <David.Butenhof@hp.com> wrote in message news:<4Zb69.27$4r7.763022@news.cpqcorp.net>... > OHM wrote: > H > > This looks like working alright most of the time.  I get things hungC > > once in a while, and I suspect the scheduling policy differencenH > > between the main thread and the spawned ones.  Could the main threadI > > in throughput prevent the RR ones from running, when it waits for RMSe, > > I/O completion, in spite of the upcalls? > J > First off, if you're using asynchronous RMS, then the issuing thread is N > blocking on the condition variable in user space, not on the RMS call. Even E > without upcalls that would get the issuing thread "out of the way".m  ; Indeed!  That's precisely why I converted the RMS I/Os fromeC synchronous to asynchronous...  I must have been tired when writing & this; looks like I mixed it all up ;-)  N > You'd need to examine the thread scheduling information while you're "hung" % > to see where they're "hanging out".o  A 2 threads were waiting on the same mutex, and I could not see thei? owner of it (BTW, is there any way to visualize the PC for each F individual thread with SDA?)  Other threads were waiting on their mainA loop conditions, as they normally do when waiting for some work. oD Traces would not point out any wrong sequence in acquiring/releasingE mutexes, nor any circular dependancy.    Hopefully, this new hint youg> just gave me about PTHREAD_MUTEX_ERRORCHECK will help when the deadlock happens again...e  
 Thanks again,   
   -- Olivier.    ------------------------------  # Date: Tue, 20 Aug 2002 18:21:28 GMTs From: system@SendSpamHere.ORGi8 Subject: Re: Printing barcodes via postscript on OpenVMS0 Message-ID: <00A12BDD.564C2104@SendSpamHere.ORG>  c In article <ajtm85$3c236@eccws12.dearborn.ford.com>, "Toine Dirven" <tdirven@volvocars.com> writes:t >Hello,  >rE >I want to print barcodes on our laserprinters via our Alpha servers.1H >I want to develop an application on OpenVMS that creates the postscript >file.+ >I will print this file to an laserprinter. . >Has anyone examples or experience with this ?1 >Where can I find postscript fonts for barcodes ?n >Please help me. >. >e >Best regards, >o
 >Toine Dirveny >Volvo Cars Gent >p >t  > I've created my own postscript font to do Code-39 and extended= Code-39 barcodes as well as PostNet codes for mailing lables. > I've not needed to create UPC codes so I've not created a font definition for them.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMa            w5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Tue, 20 Aug 2002 14:44:50 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>e8 Subject: Re: Printing barcodes via postscript on OpenVMS, Message-ID: <3D628E1E.BA91D2C2@videotron.ca>   Toine Dirven wrote:MF > I want to print barcodes on our laserprinters via our Alpha servers.I > I want to develop an application on OpenVMS that creates the postscripth > file.e    , You can start with http://www.barcode-1.net/  $ I also got some postscript fonts at:  1 http://www.centprod.demon.co.uk/download/ean13.ps-  ) Not sure if that site is still up though.    ------------------------------    Date: 20 Aug 2002 13:37:11 -0600+ From: young_r@encompasserve.org (Rob Young)0 Subject: Re: Simple clustero3 Message-ID: <0ys5NBVHC+p8@eisner.encompasserve.org>t  w In article <OF81D5D9BD.634A99EC-ON07256C1B.0061F8C2@rsc.raytheon.com>, "David D Miller" <ddmiller@raytheon.com> writes:r > Cluster experts: > K > All this talk about updating a system shadow volume got me thinking.  I'moH > trying to imagine the simplest (and cheapest) redundant Alpha cluster. > Will this work?  > M > Two Alphas on Ethernet and each has a disk.  The two disks make up a systemaE > shadow volume.  Each Alpha has a vote.  Is a quorum disk necessary?t >   E 	Depends.  If you want one to "automatically" be able to survive the cC 	other crashing, then the answer is "yes."   Maybe you have an ideahD 	of setting expected_votes to 1 and each node 1 vote?  If so, a lost= 	network connection could very easily cause you to partition r; 	the cluster.  Numerous Google and FAQ warnings about that.g    & > Are there other, better suggestions?  : 	Two nodes?  You mentioned cheapest, maybe add a 3rd cheapC 	quorum watcher node.  If you have that laying around now you don't-B 	need a quorum disk but in some senses you aren't much better off.; 	If that quorum watcher and the node it is on loses networkD< 	connectivity, then you are hung until you adjust quorum/EV.  @ 	A two node "mostly available" cluster requires a quorum disk.  9 	Otherwise, you have to adjust EXPECTED_VOTES on the fly:t  > http://kuhub.cc.ku.edu/www/html/721final/4477/4477pro_022.html   				RobP   ------------------------------  % Date: Tue, 20 Aug 2002 20:46:15 +0200 " From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: Simple cluster 6 Message-ID: <aju2pt$1du8t5$1@ID-143435.news.dfncis.de>  ; "David D Miller" <ddmiller@raytheon.com> schreef in berichte@ news:OF81D5D9BD.634A99EC-ON07256C1B.0061F8C2@rsc.raytheon.com... > Cluster experts: > K > All this talk about updating a system shadow volume got me thinking.  I'miH > trying to imagine the simplest (and cheapest) redundant Alpha cluster. > Will this work?o >tF > Two Alphas on Ethernet and each has a disk.  The two disks make up a systemE > shadow volume.  Each Alpha has a vote.  Is a quorum disk necessary?  > & > Are there other, better suggestions? >. > TIA, dave.   Dave,i  K rule 1 for a quorum disk is that it must be directly connected to the hoststJ that have it defined as their quorum disk. Directly connected includes HSxK disks and RF disks. Rule 2 is that only one quorum disk may be present in ah cluster.K The direct consequence of these rules is that your NI cluster can have only H one disk, attached to the node that you'd like to be up should the otherI node fail. There's no way to guarantee the availability of one node. EvenaJ not on a shared scsi bus, provided it is supported on yoar alpha's becauseL loss of one node will cause a crash (intended) on the other node. The reasonJ is that NI connectivity is lost and thus between the PEdriver that handlesI the cluster traffic across the LAN. The shared disks are still accessibleaE for the  nodes and that would lead to disk inconsistencies ("Multiplyt allocated blocks").   H However, on VAXen it is possible to run in a definitely unsupported modeL with two quorum disks in a two node cluster. Each disk directly connected toJ the VAX. Not sure whether that will also work on alpha, but on the VAX theJ quorum disk votes are only taken into account as soon as one node is lost.L Again, this is nice on a home system but not for a production cluster. Add a+ small third node to cast the decisive vote.a   Hans   ------------------------------  % Date: Tue, 20 Aug 2002 14:45:53 -0400e0 From: "Alan Boyles" <alan.boyles@mindspring.com> Subject: Re: Simple clustera/ Message-ID: <um53ofc8sghbfe@corp.supernews.com>o  J A quorum disk is never "necessary" but it's ALWAYS recommended in a 2-nodeL cluster for a couple of reasons.  One is that in a standard config you wouldJ need 2 votes to keep the cluster up and if the LAN went away 2 votes wouldJ not be available.  Second, is that if you set the cluster quorum to 1  you$ could easily partition this cluster.   Alan9 "David D Miller" <ddmiller@raytheon.com> wrote in message@@ news:OF81D5D9BD.634A99EC-ON07256C1B.0061F8C2@rsc.raytheon.com... > Cluster experts: >nK > All this talk about updating a system shadow volume got me thinking.  I'mhH > trying to imagine the simplest (and cheapest) redundant Alpha cluster. > Will this work?e >eF > Two Alphas on Ethernet and each has a disk.  The two disks make up a systemE > shadow volume.  Each Alpha has a vote.  Is a quorum disk necessary?u >s& > Are there other, better suggestions? >s > TIA, dave. >t >w   ------------------------------  # Date: Tue, 20 Aug 2002 20:29:17 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Simple clusterlA Message-ID: <xEx89.88348$m91.4337350@bin5.nnrp.aus1.giganews.com>d  9 "David D Miller" <ddmiller@raytheon.com> wrote in messageu@ news:OF81D5D9BD.634A99EC-ON07256C1B.0061F8C2@rsc.raytheon.com... > Cluster experts: >rK > All this talk about updating a system shadow volume got me thinking.  I'mdH > trying to imagine the simplest (and cheapest) redundant Alpha cluster. > Will this work?o >,F > Two Alphas on Ethernet and each has a disk.  The two disks make up a systemE > shadow volume.  Each Alpha has a vote.  Is a quorum disk necessary?   L While you have received several good responses, none have asked exactly what you meant by 'redundant'.e  F If all you want is replicated storage in case of a local disaster thatK destroys one site's disks, then you don't need a third vote (quorum disk orWJ additional node):  just assign the primary server two votes and the remoteJ back-up server 1 vote.  If the primary server dies, your data will be safeK at the remote server, and you can manually change the cluster configurationnL at that time to allow it to run if desired.  For that matter, there's reallyI no reason that VMS couldn't allow you to mirror a disk at a second systemsL without forming a cluster at all, but I have no idea whether such facilities exist.  J If you want continuous operation despite the failure of one of your nodes,K you'll need a third vote (or have to do something unsupported):  that's thehJ way a cluster protects itself against partitioning into multiple subgroupsD where more than one keeps running independently and thus consistencyH diverges.  If/when iSCSI arrives and gets supported by VMS, you might beI able to do this with an iSCSI disk attached to your Ethernet; until then,gK sounds as if you'll need a third node, if indeed VMS doesn't allow a sharedtL SCSI disk to function as a quorum disk as was stated (my dim recollection isI that Tru64 may support that option, and/or may support use of target-mode K SCSI communication between the two systems as an alternate path that allowsaI one system to verify that the other actually died rather than, e.g., thathJ the interconnect cable got cut - though that's a tad dangerous if a systemA just becomes too wedged up to respond at all for a while and then 
 recovers...).s   - bill   ------------------------------  % Date: Tue, 20 Aug 2002 15:18:05 -0700n. From: "David D Miller" <ddmiller@raytheon.com> Subject: Re: Simple clustertF Message-ID: <OF92351823.94D62268-ON07256C1B.0078E3AF@rsc.raytheon.com>  
 Cluster-folk.   I Thanks to all that have helped so far.  Gosh, I thought this was going tooH be a simple question (see previous message below).  Discussions I've hadF offline indicate that maybe I should state this "problem" differently.  @ I'd like to set up a cluster with the following characteristics:  D 1. Continue operation if one CPU fails -- eg, memory, device driver,K software, etc.  No one CPU is a preferred boot or file server if that makese things easier./ 2. Continue operation if one system disk fails.sG 3. A single system disk (therefore probably shadowed due to 2 above) tom minimize management tasks.  I The only thing folks agree on so far is I need three CPUs, one vote each.i So how do I hook in the disks?  I As an aside, I find it curious that this system doesn't have a "standard"tG solution.  I'd think this is a commonly requested option.  Am I way offhG axis here?  Perhaps this configuration doesn't improve reliability.  Myb intuition may be way off here.       dave.   H ----- Forwarded by David D Miller/RWS/Raytheon/US on 08/20/2002 03:00 PM -----p   Cluster experts:  I All this talk about updating a system shadow volume got me thinking.  I'm F trying to imagine the simplest (and cheapest) redundant Alpha cluster. Will this work?e  K Two Alphas on Ethernet and each has a disk.  The two disks make up a systemRC shadow volume.  Each Alpha has a vote.  Is a quorum disk necessary?e  $ Are there other, better suggestions?  
 TIA, dave.   ------------------------------    Date: 20 Aug 2002 16:12:30 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)p Subject: Re: Simple cluster = Message-ID: <cf15391e.0208201512.4752294e@posting.google.com>m  ` "Hans Vlems" <hvlems@iae.nl> wrote in message news:<aju2pt$1du8t5$1@ID-143435.news.dfncis.de>...M > rule 1 for a quorum disk is that it must be directly connected to the hostscL > that have it defined as their quorum disk. Directly connected includes HSx > disks and RF disks.t  1 ...plus SCSI disks in a multi-host configuration.a. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------    Date: 20 Aug 2002 16:14:51 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)r Subject: Re: Simple clusterh= Message-ID: <cf15391e.0208201514.5a51b879@posting.google.com>d  ` "Hans Vlems" <hvlems@iae.nl> wrote in message news:<aju2pt$1du8t5$1@ID-143435.news.dfncis.de>...M > rule 1 for a quorum disk is that it must be directly connected to the hostsiL > that have it defined as their quorum disk. Directly connected includes HSxM > disks and RF disks. Rule 2 is that only one quorum disk may be present in a*
 > cluster.M > The direct consequence of these rules is that your NI cluster can have only J > one disk, attached to the node that you'd like to be up should the other > node fail.  F It would be better to simply give a second vote to the node itself, in3 this case, rather than having a quorum disk at all.P. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  % Date: Tue, 20 Aug 2002 15:37:46 -0400s+ From: Michael Corbett <corbett@PROCESS.COM>g Subject: Re: tcpware smtp * Message-ID: <3D629A8A.4070901@PROCESS.COM>   Antony Wardle wrote:   > Hi > < > Is there a configuration switch that I can turn on to stop3 > tcpwares smtp from keeping a copy of sent e-mailso > in a spool directory?t > 8 > Or do I need to write something to clean it up myself? >  >  >  > antony >  >  >   J It should not keep copies of sent files in the spool directory.  Something8 is wrong on your system.  What version of TCPware is it?   regardse Mike     -- 9K +-------------------------------------------------------------------------+>D Michael Corbett                           Email: Corbett@process.comB Process Software                          Phone: 800 722-7770 x369B 959 Concord St.                                  508 879-6994 x369= Framingham MA 01701-4682                  FAX:   508 879-0042    ------------------------------   Date: 21 Aug 2002 04:26:33 GMT From: sethm@loomcom.com ) Subject: Re: total VMS newbie - pointers?a0 Message-ID: <ajv4pp$r1c@dispatch.concentric.net>  & John Forkosh <john@invalid.com> wrote:9 : Dan Barowy <dbarowy@n-o-s-p-a-m__acad.umass.edu> wrote:eK : : With the 4000/60 came an odd monitor cable (D style mini BNC to 3BNC), cH : : and I have yet to get my hands on an adaptor or BNC monitor.  Is it F : : possible to access this machine in via serial/terminal connection?  ; :      If you get, say, a vt420 off ebay, it'll have an mmj,? : connection also.  Now all you need is an mmj cable -- too bad % : those are rarer than chicken teeth.s  E I have had luck in the past simply cutting the small tabs off the topFE of ordinary RJ-11 cable ends, the type used for phones.  The cable isu9 very easy to pull out, but at least you have -something-.e   -Sethg --  C "It looks just like a Telefunken U47!                 Seth Morabito C  You'll love it."  - Frank Zappa                  sethm@loomcom.comd   ------------------------------  % Date: Wed, 21 Aug 2002 01:22:34 -0400 , From: David Michaels <michaedi@email.uc.edu>) Subject: Re: total VMS newbie - pointers? , Message-ID: <3D63239A.71CEC7E3@email.uc.edu>  ? > connection also.  Now all you need is an mmj cable -- too badn8 > those are rarer than chicken teeth.  Maybe someone can > follow up with a source.    0 My Boss has a bag of about 20 mmj connectors....  H He also has a pair of crimpers to go with them. The last time I tried toF find the connectors on google I searched for "mmj crimpers" instead ofE "mmj connectors"...and I seem to be getting pretty close... If anyoneh3 wants the name of the crimper manufacture email me.@     David Michaels dmichaels@acm.org    ------------------------------    Date: 20 Aug 2002 12:27:54 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)n- Subject: Re: V7.3-1 and TIMA for FC Minimergea= Message-ID: <cf15391e.0208201127.483f17d7@posting.google.com>u  a Paul Repacholi <prep@prep.synonet.com> wrote in message news:<877kiq7ia4.fsf@prep.synonet.com>...l3 > brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:,? > > I never tire of discussing anything VMS-related, especiallyeG > > HSG80-based mini-merge.  It makes for great dinner table discussiongH > > with my wife, who while quite intelligent in her own right, wouldn't/ > > know an HSG80 from a star coupler . . . :-)y > D > Wel,, how about sparing your wife, and giving us the details of it1 > all. :) And how it differs from HSCs, Js, Ds...e  A The HSC was an early storage controller with a CI host port, witheB Digital SDI disk and STI tape interfaces (although late in life itE could also connect to SCSI drives).  The HSJ series was much smaller, C faster, had better caching, and was designed to use SCSI disks fromgF the start (by setting aside a portion of the SCSI disk area at the end@ for metadata for functions that SCSI alone didn't provide).  TheD latest in this line is the HSJ80, with two host-side CI ports on theB front end instead of one and Wide UltraSCSI busses on the back end instead of Fast Narrow SCSI.  A The HSD series had a DSSI host-side port.  The last model in this- series was the HSD50.,  ? The HSC, HSD, and HSJ talk Mass Storage Control Protocol (MSCP):D protocol to the host over a System Communications Architecture (SCA,C aka System Communication Services or SCS) protocol transport.  MSCPbD had special extensions added to support host-based Volume Shadowing,F including Disk Copy Data (ability for the controller to copy data fromD one shadow member to another, instead of having to send data throughF the host system) and Volume Shadowing Assists, including Write HistoryF Logging, in which the controller keeps track of host shadow writes and@ can tell a surviving host which areas were being written to by aE departed cluster node, so only those areas need to be fixed up duringcC the subsequent merge operation, instead of checking all the data ont
 the disks.  D The HSZ series has a SCSI host-side port in place of the CI port theD HSJ had, but otherwise is similar.  The HSZ80 is the latest model in this series.  2 The HSG series has a Fibre Channel host-side port.  B Other than the host-side port, the HSJ, HSD, HSZ, and HSG are veryD similar in architecture, hardware implementation, and firmware.  ForF example, the HSZ80, HSG80, and HSJ80 are essentially identical designsD except for the host-side port(s).  The big difference implied by the? different host ports is that the HSZ and HSG use SCSI protocolsi, instead of MSCP to talk to the host systems.  9 > Why does the #%*& thing need so much code added to VMS?   7 Specialized functions which were previously provided by F carefully-engineered solutions available only from one specific vendorD to meet the special needs of their customer base have to be emulated< when using industry-standard solutions, if you need the same functionality.  F We saw a similar situation when Volume Shadowing had to add support ofC using SCSI ReadLong and WriteLong and inverting the ECC so it could6D emulate the (patented) Forced-Error Flag feature which Digital disks
 had provided.m  F Here it's the MSCP Shadowing Assists which have to be replaced by hostC code when using SCSI (or SCSI over FC) instead of MSCP to talk to ae@ controller, so that you can get the benefit of brief mini-mergesB instead of time-consuming full merges.  I wouldn't be surprised ifE eventually even more of this functionality ends up getting moved intokE the host software in the future, so that the controller wouldn't havel4 to know anything about Write History Logging at all.  F It's just like what's happening in the port of VMS to IPF -- functionsB which were in the Alpha SRM console firmware and PALcode are being8 moved into the operating system itself so VMS can run onC industry-standard hardware and still provide the same functionalityi that we know and love today.  A Sometimes we see innovative proprietary solutions being copied byaC industry standards, many years later.  For example, if one looks at 1 InfiniBand, one sees a lot of similarity with CI.   E So, as an alternative to moving everything into the host, it might be F nice to see extensions for write history logging incorporated into theF SCSI standards themselves, as more platforms learn about what's really@ needed for very-high availability in the area of host-level disk
 mirroring.. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  % Date: Tue, 20 Aug 2002 22:28:28 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>e- Subject: Re: V7.3-1 and TIMA for FC Minimerge ' Message-ID: <3D62A66C.2BA6875B@aaa.com>8  7 Well, maybe this impressive and easy-to-read listing oft9 the different HS* controllers could go into the VMS FAQ ?    Jan-Erik Sderholm.n   Keith Parris wrote:a > + [The very fine writing of Keith snapped...]o >t   ------------------------------  % Date: Tue, 20 Aug 2002 16:37:54 -0400y' From: "Main, Kerry" <Kerry.Main@hp.com>v- Subject: RE: V7.3-1 and TIMA for FC MinimergehT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4023D94D1@kaoexc01.americas.cpqcorp.net>   Keith,  ! Good summary - another "keeper"..o   :-)h   Regards,  
 Kerry Main Senior Consultantc Hewlett-Packard Canada! Consulting & Integration Servicesh Voice: 613-592-4660s Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----2 From: Jan-Erik S=F6derholm [mailto:aaa@aaa.com]=20 Sent: August 20, 2002 4:28 PMe To: Info-VAX@Mvb.Saic.Comf- Subject: Re: V7.3-1 and TIMA for FC Minimerget    7 Well, maybe this impressive and easy-to-read listing ofs9 the different HS* controllers could go into the VMS FAQ ?a   Jan-Erik S=F6derholm.    Keith Parris wrote:s >=20+ [The very fine writing of Keith snapped...]n >e   ------------------------------  # Date: Tue, 20 Aug 2002 22:54:45 GMTs' From: nickerson@pundit.ds.boeing.com ()a& Subject: Re: VMS to OpenVMS conversion( Message-ID: <H15zn9.L7r@news.boeing.com>  6 In article <Xns926B5C822E5Ejknoxtrisoftcom@10.0.0.1>, + "James M. Knox" <jknox@trisoft.com> writes:n  G |>Fortunately, the application for which we do not have source - while tG |>huge - is also not used very often.  That means that speed is not an t> |>issue.  If it runs correctly, we don't care how efficiently.  2 (version of VAX VMS the code currently runs on) is   |>    	VMS 5.3   and I recommendedc; 1) form a mixed VAX & Alpha VMScluster running OpenVMS 7.3;e  I |>We've been told by HP that we can't do this.  They say the Alpha won't nK |>cluster with VMS that old.  [And no, again for reasons we don't control, e |>we can't upgrade.]  I right you can't cluster Alpha with that old; but why can't you move your  I software to VAX VMS 7.3 or even 7.2; a used VAXstation 4000-96 might wellt be a sufficient option;   L could you explain - I don't understand; you want to port to Alpha - a ratherI large undertaking, but you can't upgrade a VAX to VMS 7.3 to run the VAX  I version of your software in a currently supported version, to facilitate DK the port, and to allow running in a mixed architecture cluster as the port n4 progresses or as a fallback for your missing source;  = |>We have allocated about a year just for regression testing.h  F as I said - a large undertaking; so I'm puzzled why the VAX VMS 7.3 asG an intermediate step is not an option; is it operational scale or otherv# software or production risk or ???;q   --bn (Bart Nickerson)s   ------------------------------  % Date: Tue, 20 Aug 2002 14:21:11 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>03 Subject: Re: VMS upgrade with shadowed system disk.s, Message-ID: <3D628895.11BCF057@videotron.ca>   Phillip Helbig wrote:3D > > I think I just made a *manual* MOUNT of the second disk into theG > > system shadow set, and after that, VMS has taken care of it at eachc > > reboot.. >  > Right.  G Why does VMS remount all members of a system shadow set "automatically"tE without any specific mount command during startup ? Sounds to me likenN something that is very dangerous, especially after a failure where YOU want to& decide which disk is to become master.  L Also, what happens when other system shadow set members are not available atM boot time and become available minutes later when another node reboots ? DoeseH the shadow set automatically "regroup" its drives ? or does that require manual MOUNT commands ?t   ------------------------------   End of INFO-VAX 2002.459 ************************:  just assign the primary server two votes and the remoteJ back-up server 1 vote.  If the primary server dies, your data will be safeK at the remote server, and you can manually change the cluster configurationnL at that time to allow it to run if desired.  For that ma