1 INFO-VAX	Fri, 05 Dec 2003	Volume 2003 : Issue 673       Contents:/ Re: "Compaction disabled" ... how to enable it?  Re: DS700 RAS configuration  Re: Hairdoo Economics  Re: Hairdoo Economics  Re: Hairdoo Economics  Re: Hairdoo Economics : Re: I wonder if this HP director will resign from HP's BOD8 Re: Linux kernel security bug ... VMS kernel rock solid! New patchkits available  Re: New patchkits available   Re: NTP build procedure for VMS?! Re: OpenVMS Freeware V6.0 On-Line  OpenVMS org 5 Re: OT Very scary: Cars running on Microsoft software $ OT: Bell Canada's DNS compromised... Re: OT: What's next for HP? & Re: Pictures from the OpenVMS bootcamp& Re: Pictures from the OpenVMS bootcamp& Re: Pictures from the OpenVMS bootcamp Re: Problems starting TCPIP$NTP $ RE: Routable Protocol for Clustering$ RE: Routable Protocol for Clustering$ RE: Routable Protocol for Clustering$ RE: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ RE: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ RE: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering$ Re: Routable Protocol for Clustering RTL/2 AnyoneA Re: Strange FTP behavior (and a followup to my bugcheck message). 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday = Re: VMS clusters prove they are the best - Sun comes in last! = RE: VMS clusters prove they are the best - Sun comes in last! = Re: VMS clusters prove they are the best - Sun comes in last! , Will VMS contribute to Microsoft's profits ?0 Re: Will VMS contribute to Microsoft's profits ?0 Will VMS have to pay royalties Microsoft ? (FAT)4 Re: Will VMS have to pay royalties Microsoft ? (FAT)  F ----------------------------------------------------------------------  % Date: Fri, 05 Dec 2003 07:50:26 +0000 * From: Nic Clews <sendspamhere@[127.0.0.1]>8 Subject: Re: "Compaction disabled" ... how to enable it?' Message-ID: <bqpdb4$5lc$1@lore.csc.com>    Z wrote: >  > $ SHOW DEVICE MKE600/FULL  > G > Magtape NODE03$MKE600:, device type SDLT1, is online, record-oriented M > device, file-oriented device, error logging is enabled, controller supports $ > compaction (compaction  disabled). > ...  > 0 >  "Compaction disabled" ... how do I enable it? > J > Will it be enabled when I do INIT/MEDIA=COMPACTION or is there something, > I need to do with SET DEVICE to enable it?  E You've not identified the operating system, and patch levels may have F something to do with this as well, but I'll assume a recent version asH you appear to be using something that describes itself as an SDLT. Also,B typically, if no media is present, you see the "disabled" wording.   Best advice is to:   $ INIT/MEDIA=COMPACT ... $ MOUNT ... /MEDIA=COMPACT $ BACKUP ... /MEDIA=COMPACT   @ Some [early] drives in combination with certain operating systemF software would only work if you followed these rules. Also think aboutF the /CACHE qualifier with MOUNT for applicable devices. If you want to be sure, specify.   G If it still doesn't work and you're sure that your operating system and H patch level in combination with that device is supported, log a software call.  --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------   Date: 5 Dec 2003 07:38:02 -0800 & From: jordan@ccs4vms.com (Rich Jordan)$ Subject: Re: DS700 RAS configuration= Message-ID: <cc5619f2.0312050738.33388757@posting.google.com>   t gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann) wrote in message news:<bqlo4t$j1d$1@n.ruf.uni-freiburg.de>...h > In article <cc5619f2.0312030839.14696b21@posting.google.com>, jordan@ccs4vms.com (Rich Jordan) writes: ... H > >So... any sample configs running a RAS dialup at 57600 or 115200, andH > >modem recommendations to go with it?  Also, is NAS 2.2 up to the taskI > >or do we need to get the one server upgraded to current (2.6 I think)?  > P > This is the port setup for one Modem on our DS700-08 with NAS 2.2. It works inD > conjunction with DRAS 2.3. It works with both, dialup and dialout. > 7 > Port  1: MODEM1                        Server: SERV16  > H > Character Size:            8           Input Speed:              57600H > Flow Control:            CTS           Output Speed:             57600H > Parity:                 None           Modem Control:          Enabled9 > Stop Bits:                 1                             > H > Access:              Dynamic           Local Switch:              NoneH > Backwards Switch:       None           Name:                  SERV16_1H > Break:              Disabled           Session Limit:                1H > Forwards Switch:        None           Type:                      AnsiH > Default Protocol:   Autolink           Default Menu:        MPIIB-MENUH > Autolink Timer One:10 Two:10           Dialer Script:        ELSAMODEM > # > Preferred Service: CALLBACK_MODEM  > Authorized Groups:   0 > (Current)  Groups:   0 >  > Enabled Characteristics:J > Autoconnect,  Autolink Authentication,  Autoprompt,  Dialup,  DSRlogout,8 > Inactivity Logout,  Input Flow Control,  Limited View,& > Output Flow Control,  PPP,  Security >  > 
 > Regards, >    Christoph Gartmann     
 Christoph,D      thanks for the info.  I presume that it actually stays at 57600F baud on connect since you don't have autobaud set.  What modem are you? using?  I've only ever seen one Elsa modem here ("Microlink 56K D Internet", apparently a simplified PC external modem) which I've not' had the opportunity to try as a dialin.   F      In our one previous test, where we could not get better than 9600F baud connects, we used local authentication.  I'll have to find out if5 we can use DRAS or have to stick with server local...   A      We may be able to borrow a Courier 56K Business modem, which C seems to be the 'high standard' since Hayes died.  If it works then E thats what we'll likely recommend, though it will drive the prices up  a lot on the configuration.    Rich Jordan    ------------------------------  % Date: Fri, 05 Dec 2003 01:51:48 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com> Subject: Re: Hairdoo Economics) Message-ID: <3FD02AD9.2050EB4C@istop.com>    John Smith wrote: : > a) the firm is making significant investments in OpenVMS  N They are not making significant investments in VMS. They are spending money to' help support their decision to go IA64.   I The port to IA64 is a big distraction from the real needs of VMS, such as L improving the TCPIP stack, improving VMSmail, spending money to get SAP back on VMS etc etc.   K Can anyone confirm if total staffing level for VMS and its layered products N has increased since HP has taken Compaq ? I only know of people leaving. And IK only know that Carly is proud to announce layoff since this is seen by Wall   Street as a sign she has gonads.   ------------------------------  # Date: Fri, 05 Dec 2003 12:04:43 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger)  Subject: Re: Hairdoo EconomicsL Message-ID: <rdeininger-0512030706290001@user-uinj43q.dialup.mindspring.com>  2 In article <3FD02AD9.2050EB4C@istop.com>, JF Mezei" <jfmezei.spamnot@istop.com> wrote:   >John Smith wrote:; >> a) the firm is making significant investments in OpenVMS  > O >They are not making significant investments in VMS. They are spending money to ( >help support their decision to go IA64.  = I guess everyone has a different definition for "significant"     J >The port to IA64 is a big distraction from the real needs of VMS, such asM >improving the TCPIP stack, improving VMSmail, spending money to get SAP back  >on VMS etc etc.  F I guess everyone has a different opinion about the real needs of VMS. I It's pretty obvious that TCPIP is getting a lot of attention, and VMSmail  isn't.   ------------------------------   Date: 5 Dec 2003 09:33:18 -0800 ( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Hairdoo Economics= Message-ID: <d7791aa1.0312050933.21657a43@posting.google.com>   [ JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<3FD02AD9.2050EB4C@istop.com>...  > John Smith wrote: < > > a) the firm is making significant investments in OpenVMS > P > They are not making significant investments in VMS. They are spending money to) > help support their decision to go IA64.  > K > The port to IA64 is a big distraction from the real needs of VMS, such as N > improving the TCPIP stack, improving VMSmail, spending money to get SAP back > on VMS etc etc.   : it would save them money actually to just buy TCPware from: Process ... it is the best IP stack for VMS hands down and9 would save a tremendous amount of time and resources from  trying to develop UCX ...    ------------------------------  % Date: Fri, 05 Dec 2003 12:22:40 -0600 ( From: David Harrold <DHarrold@wi.rr.com> Subject: Re: Hairdoo Economics8 Message-ID: <pri1tv0j8fvvkdk8d1ubdr0qg1vrm5rgv4@4ax.com>  H On Fri, 05 Dec 2003 01:51:48 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:   >John Smith wrote:; >> a) the firm is making significant investments in OpenVMS  > O >They are not making significant investments in VMS. They are spending money to ( >help support their decision to go IA64. >   M Porting an operating system from one hardware architecture to another isn't a N significant investment?  I know you have a grudge against HP and the decisionsN it has made for its business, but that sounds like a significant investment to me.     J >The port to IA64 is a big distraction from the real needs of VMS, such asM >improving the TCPIP stack, improving VMSmail, spending money to get SAP back  >on VMS etc etc.  N And seeing as the only future platform for VMS is IA64, how is porting to thatJ platform a distraction?  Seems to me that should be the place to spend the  most money to ensure the future.  N But, I keep forgetting that you are mad about the Alpha decision.  So anything( that helps the IA64 plan is a bad thing.  M And I also know that TCPIP is seeing enhancements as well as porting to IA64.   K It might help if you had something useful to say rather than beating a dead N horse.  VMS is going to IA64, deal with.  Move on.  HP isn't going to suddenlyI decide to revive the Alpha and port HP-UX, Windows, MPE and Tandem to it.    Dave Harrold  N ..............................................................................N David Harrold                              E-Mail: David_Harrold at aurora.orgI Sr. Software Systems Engineer              Phone:          (414) 647-6204 I                                            Pager:          (414) 941-4634 G Aurora Health Care                         Fax:          (414) 647-4999  3031 W. Montana Street Milwaukee, WI 53215    ------------------------------  # Date: Fri, 05 Dec 2003 12:47:42 GMT ! From: Nigel Barker <nigel@hp.com> C Subject: Re: I wonder if this HP director will resign from HP's BOD 8 Message-ID: <mfv0tvc2mbe4kmqrio96i4m4ukd8aore2l@4ax.com>  O On Thu, 04 Dec 2003 17:04:09 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:   O >Qantas, which used to pride itself with being an "all Boeing" airline has just E >ordered 23 Airbus A320, as well as some A380s and 330s a while back. P Easyjet in the UK have just purchased 120 A319s with an option on another 120 at the same price.    -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  % Date: Fri, 05 Dec 2003 10:46:31 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> A Subject: Re: Linux kernel security bug ... VMS kernel rock solid! 0 Message-ID: <bqpnm8$1qp$1@new-usenet.uk.sun.com>   Bob Ceculski wrote: r > "Jeff Goodwin" <jgoodwin@maine.rrr-r.com> wrote in message news:<Qs3zb.161022$ji3.47459@twister.nyroc.rr.com>... > M >>Rock solid may not be an appropriate description.  Perhaps you should check < >>out the latest Alpha SYS ECOs for V7.2-2, V7.3 and V7.3-1. >>7 >>"Bob Ceculski" <bob@instantwhip.com> wrote in message 9 >>news:d7791aa1.0312020824.294ed988@posting.google.com...  >>1 >>>the linux/slowaris/unix cert counters continue " >>>to increase at a rapid pace ... >>> , >>>http://www.theinquirer.net/?article=12970 >  > ; > well our alphaservers on 7.1 have been up for 4 years now 7 > without ANY problems at all ... go check out the cert : > counts and compare vms to all others then come back here > and talk about bugs ...     ; Bob this is total and utter BS, OpenVMS security violations = do not get reported to CERT so its a pointless place to start & looking for OpenVMS security exploits.  6 Take the latest ECO it contains a patch for a "Serious3 Security Issue" on OpenVMS no other description and 2 there is no mention of this or the ECO in any CERT advisories.   7 The fact that you continue to peddle this dangerous and 4 missleading BS in the light of overwhelming evidence" that its completely untrue is sad.  7 All you are doing is further erroding your standing and  credibility in this group.  5 I have repeatedly challenged you to substantiate your 3 claims you have never suceeded or even tried so cut  the BS out its laughable.    regards  Andrew Harrison    ------------------------------  % Date: Fri, 05 Dec 2003 09:32:17 +0100 : From: Karl Rohwedder <extern.karl.rohwedder@volkswagen.de>  Subject: New patchkits available/ Message-ID: <bqpfpd$ep59@doiweb4.volkswagen.de>   G On ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-1/ you can find the J new SYS V5.0 patchkit, which resolves the memory leak introduced with V4.0O and a new UPDATE V2.0 kit together with a ALPHA_V731_MASTER_ECO_LIST.TXT, which ' lists all available patches for V7.3-1.  --    + mit freundlichen Gren | with best regards   3 Karl Rohwedder          | it-ingteam(at)t-online.de A                          | extern.karl.rohwedder(at)volkswagen.de    ------------------------------  $ Date: Fri, 5 Dec 2003 11:14:10 -0500 From: norm.raphael@metso.com$ Subject: Re: New patchkits availableQ Message-ID: <OF35E1EF93.F01F687B-ON05256DF3.00581210-85256DF3.00597DFB@metso.com>   H Karl Rohwedder <extern.karl.rohwedder@volkswagen.de> wrote on 12/05/200= 3  03:32:17 AM:  H > On ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-1/ you can find t= heH > new SYS V5.0 patchkit, which resolves the memory leak introduced with=   V4.0+ > and a new UPDATE V2.0 kit together with a ' > ALPHA_V731_MASTER_ECO_LIST.TXT, which ) > lists all available patches for V7.3-1.  > --  = I just looked at the ALPHA_V731_MASTER_ECO_LIST.TXT file, and ? it says that there are included in the UPDATE V2.0 ECO kit some   ECO's that are Rated 2 and/or 3.  A As usual, I have installed most of the ECO's in this kit, but not A all of them.  I was about to install another group Rated 1.  Now, D should I do that, or just install the UPDATE V2.0 kit, getting thoseH I was about to install, new ones, a group I have already installed, and=  @ those Rated 2 and 3 that I don't really need, but will not hurt.  H Will UPDATE V2.0 now be a required ECO for follow-on ECO's as is UPDATE=   V1.0B now, so that the question of whether or not to install it is moot?  H Oh, and what about recovery-sets?  I would expect to want to accept the=   ECO's H that I now have installed, and then produce a recovery-set for only UPD= ATE  V2.0H and then recovery-sets for subsequent ECO installations.  How do I clea= r  the H existing recovery-sets before taking my phase-0 backup of my system dis= k?  D On, and given these bundled UPDATE ECO's, how does one readily check	 whether a  specific ECO has been applied?   -Norm   1 > mit freundlichen Gr=FC=DFen | with best regards   5 > Karl Rohwedder          | it-ingteam(at)t-online.de * > | extern.karl.rohwedder(at)volkswagen.de =    ------------------------------  % Date: Fri, 05 Dec 2003 09:26:25 +0100  From: Dirk Munk <munk@home.nl>) Subject: Re: NTP build procedure for VMS? & Message-ID: <3FD04131.9020906@home.nl>  2 That's good, at least NTP is getting the time now.K Did you also check that DTSS is not running? It should be disabled (or not   started at all).       Richard B. Gilbert wrote: H > One mystery solved!  If I specify the server/peer addresses in dotted J > decimal form,  NTP is able to locate the servers.  This was reported as K > a bug in UCX 4.1 ECO 6 and engineering said it was supposed to work that  J > way!!  TCPIP services V5.0 fixed it but only, I believe, because it was H > a port of the True-64 Unix code which did it right in the first place! > I > I still would like to get NTP V4.2 compiled, linked and running.  V4.2  F > offers, in addition to amenities like NTPDATE, improvments in clock ( > selection that reduce "clock hopping". >  > Dirk Munk wrote: >  >> Richard B. Gilbert wrote: >>C >>> It's fairly obvious that NTP is not setting the clock.  It not  - >>> obvious that it is doing anything at all.  >>> H >>> The Wizard (and HPAQ tech support) say to upgrade to TCPIP Services H >>> V5.1 which I can't do.  TCPIP V5.1 works very well BTW, I'm running E >>> it on the four Alphas that I *can* run it on; they are generally  H >>> within a couple of milliseconds of the server they are synchronized - >>> with and that's well within my tolerance.  >>> G >>> The NTP.TEMPLATE file is not much help!  The only basic difference  I >>> between what I was doing, and the template file is that I was  using  G >>> the "server" keyword instead of "peer" because I didn't want these  D >>> systems to have any peers in the NTP sense of the word.  When I J >>> changed "server" to "peer" and restarted NTP, the log file did report H >>> that it had found a peer and was now at stratum 2.  I also have the E >>> "correct-any" keyword which is supposed to allow NTP to jump the  G >>> clock if necessary; it's clearly necessary but it's not doing that  H >>> either.  Thirty minutes later, it's still at an offset of -2.334959 F >>> seconds from it's new "peer" and it's still drifting in the wrong / >>> direction at about 8 milliseconds per hour.  >>> ( >>> Do you actually have this working??? >>> ? >> I will have to look at some systems at my work how they are  I >> configurered. We do have some older system running VMS 6 and UCX 4.2,  J >> but I hardly ever look at them. However I'm quite sure they do use NTP I >> for their time source. I hope to come back to you soon with an answer.  >> >    ------------------------------  % Date: Fri, 05 Dec 2003 07:48:44 +0100 : From: Karl Rohwedder <extern.karl.rohwedder@volkswagen.de>* Subject: Re: OpenVMS Freeware V6.0 On-Line/ Message-ID: <bqp9n8$ep58@doiweb4.volkswagen.de>    David J. Dachtera wrote: > Karl Rohwedder wrote:  >  >>A little errata with DFU:  >>W >>        the image is linked /TRACEBACK, so DFU$STARTUP fails to install it with privs  >  > F > Given what DFU can do, installing it with priv.'s seems inadvisable, > IMO. > \ I agree with that, may be the /traceback was ment to prevent from installing with privs? :-]   --    + mit freundlichen Gren | with best regards   3 Karl Rohwedder          | it-ingteam(at)t-online.de A                          | extern.karl.rohwedder(at)volkswagen.de    ------------------------------   Date: 5 Dec 2003 04:07:11 -0800 . From: mistdragon@zdnetonebox.com (mist dragon) Subject: OpenVMS org= Message-ID: <7500353b.0312050407.195a04ac@posting.google.com>   F Just imagine: What would happen if HP decided that Itanium would never9 make it to mainstream and spin OpenVMS off OpenVMS corp ?   E How many would there be left ? What would be the future of it ? Would A it bring Alpha back ? Would charon-vax nail it ? Who would be the 
 competitors ?    M    ------------------------------   Date: 5 Dec 2003 09:42:34 -0800 . From: al5vf03p02@sneakemail.com (William Webb)> Subject: Re: OT Very scary: Cars running on Microsoft software= Message-ID: <d5ce4b06.0312050942.6d5abd35@posting.google.com>   U Dean Woodward <deanw@rdrop.com> wrote in message news:<3FCE2243.5050705@rdrop.com>...  > JF Mezei wrote:  > 3 > > Unfortunatly, this is NOT an April Fool's joke.  > > G > > http://wired.com/news/autotech/0,2554,61412,00.html?tw=wn_tophead_6  > H > Yesterday, a friend from the Seattle area reported seeing a Hummer H2 K > with www.microsoft.com/automotive emblazoned all over it. Shortly after,  B > he saw it again- pulled over for abusing the HOV (carpool) lane. > J > I'm not sure what's scarier- that brake "software" (ABS?) would be able G > to upgrade itself (buggy patch? virus? system crash mid-upgrade?) or  J > that it would _need_ an upgrade in the first place. Which is the lesser  > of evils? Eek...  B All these posts and nobody came up with "Blue Dashboard of Death?"   I'm disappointed.    ========================! William W. Webb- EMS Operations,   OpenVMS Systems Support % USPS DSSC Annex - 4730 Hargrove Road  ( Raleigh, NC 27616-2874 919.325.7500x4186I * * * -      email is first initial last name at email stop usps stop gov    ------------------------------  % Date: Fri, 05 Dec 2003 01:43:40 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>- Subject: OT: Bell Canada's DNS compromised... ) Message-ID: <3FD028F2.65DBDDC5@istop.com>   L Overnight (probably will have been fixed by the time you read this), someoneH hacked into the reverse IP root server to point a certain number of Bell- Canada IP ranges to a different DNS server...    $ nslookup 206.108.99.129   L Name:    bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net Address:  206.108.99.129  J This came up when some folks on another newsgroup started to complain thatH traceroutes gave out really weird results :-) (same domain name for many< different addresses along the Bell/Sympatico/Nexxia network.  F The IP ranges are still listed as belonging to Bell (or its subsidiaryF NEXXIA), but the dns server points to pluto.bell-nexxia.net instead of bellnexxia.net ....   K bell-nexxia is owned by someone in Vancouver ("MrHost") and has existed for * some time (probably some cyber squatter).   % Forward translations seem unaffected.    ------------------------------  % Date: Fri, 05 Dec 2003 22:41:15 +0800 , From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: OT: What's next for HP?- Message-ID: <87vfovl438.fsf@prep.synonet.com>   4 "Ken Farmer" <KFarmer@NOSPAM.SpyderByte.com> writes:  A > You think of HP as a big player, but they don't have that brand  > cachet to be cool."   $ It's OK Ken, they are fixing that :)   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Fri, 05 Dec 2003 02:04:05 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>/ Subject: Re: Pictures from the OpenVMS bootcamp ) Message-ID: <3FD02DB9.60B3C603@istop.com>    "Martin P.J. Zinser" wrote: I > complaints about privacy violations. I obviously grossly misjudged this  > issue.  D I think you misjudged the reaction.  i don't think that the "lawyer"M threathened to sue you for those pictures, but more just wanted to let you be M aware of the issue. Since none of the pictures you had posted were degrading, L since none involved showings omeone with a mistress, I really doubt you'd be getting any negative reactions.   L Furthermore, if anyone objected to having their photo there, they would have told you by now.  I What you could have done is call them all "John Smith" and ask people who N agree to have their name attached to their picture to contact you. Then, after? a while, you'd remove any images that are still not identified.   N I understand your reaction of pulling the images. But I deplore it since it isN an attack to basic freedom of expression. This was for good clean fun, without1 any pretense of you profiting from such pictures.    ------------------------------  # Date: Fri, 05 Dec 2003 12:01:38 GMT " From:   VAXman-  @SendSpamHere.ORG/ Subject: Re: Pictures from the OpenVMS bootcamp 0 Message-ID: <00A29E86.1F2668F9@SendSpamHere.ORG>  r In article <bqovm3$23j7r3$1@ID-209632.news.uni-berlin.de>, "Martin P.J. Zinser" <zinser@zinser.no-ip.info> writes:
 >Hello again,  >  >PEACE PLEASE!!!!  >  >Short version:  > J >All I wanted (and still) want to do is to share the good memories of the H >bootcamp with the other attendees and the community at large. I do not I >want to harm/cause discomfort/rip off anybody at all. As Barts reaction  I >clearly shows there are people with serious misgivings about what I did  E >with their pictures and who think I stepped way out of bounds. I do  G >sincerely apologize to everybody who feels this way. >>All<< pictures  H >from the bootcamp showing any person at all have been removed from the  >server as of now!!!  G ...and once again the world can rest safely, safe in the knowledge that G the threats of sleazy law(lie)yers and or those that would employ their E sleasy services have been able to erode the basic freedoms of others.   F What is the difference between Al Qaeda and the Trial Law(lie)yers As-E sociation?  Nothing!  They both have the same effects of having good, F honest, hardworking citizenry of the "free-world" (an oxymoron if everF I've heard one) cowering at the prospects of this group of terroristicF progressive hypocrites enacting some future tort and torture (What theF fuck's the difference?  Ever notice that the root of torture IS tort?) campaign against them.  E This group is eroding into a bunch of weedy New Yorkers (or a stone's F throw to if you know what I mean) slinging their "you've done me me meF wrong" pretentiousness and then doing others wrong by throwing volleys of law(lie)yers at them.  ) Hey Martin, go ahead and post my picture.    --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM             5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  # Date: Fri, 05 Dec 2003 17:50:14 GMT " From:   VAXman-  @SendSpamHere.ORG/ Subject: Re: Pictures from the OpenVMS bootcamp 0 Message-ID: <00A29EB6.D1FF0240@SendSpamHere.ORG>  W In article <vt1ga51v35r37e@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes: K >> All I wanted (and still) want to do is to share the good memories of the I >> bootcamp with the other attendees and the community at large. I do not J >> want to harm/cause discomfort/rip off anybody at all. As Barts reactionJ >> clearly shows there are people with serious misgivings about what I didF >> with their pictures and who think I stepped way out of bounds. I doH >> sincerely apologize to everybody who feels this way. >>All<< picturesI >> from the bootcamp showing any person at all have been removed from the  >> server as of now!!! > K >It's a shame that such a sincere effort or share the OpenVMS Bootcamp with L >the rest of the OpenVMS community has been squashed by a single misinformed3 >(although well intentioned) piece of legal advice.  > L >Barbra Streisand (who many of you have heard of) sued Ken Adelman (who manyM >of you know) because he flew over her house in a helicopter taking pictures. I >A judge just ruled in Ken's favor (hooray!!!) and even went so far as to # >tell Babs to pay Ken's legal fees.  >  >Details are available here: > # >http://www.californiacoastline.org  > D >http://www.bayarea.com/mld/montereyherald/news/politics/7407582.htm > I >Any lawsuit over Martin's pictures and postings would be (and should be)  >thrown out of court.  > 
 >John Vottero   C Hooray for Ken!  ...and a pox on that elitist progressive hypocrit  B Hollywood mouthpiece.  Of course, as is in most torture cases, theB only ones coming out ahead are the scourge of the human condition B -- law(lie)yers.  (Disclaimer:  I dislike Hollywood types only the& slightest bit less than law(lie)yers.)   --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM             5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Fri, 05 Dec 2003 12:02:52 -0600 ( From: David Harrold <DHarrold@wi.rr.com>( Subject: Re: Problems starting TCPIP$NTP8 Message-ID: <vvh1tv4cn3c8ih01179uhc0gi0tokevm4m@4ax.com>  H On Fri, 05 Dec 2003 02:30:29 GMT, "Mike Naime" <mnaime@kc.rr.com> wrote:  J >What hardware is this on?  If it's a Marvel box (ES47, ES80, GS1280) thenM >you need a different TCPIP$NTP.EXE file.  According to my TAM, It's supposed 4 >to be in the next SYS patch or something like that. >   L According to the release notes for the marvels, this has been resolved as of TCPIP V5.3 ECO2.  = See: http://h71000.www7.hp.com/doc/731FINAL/6665/6665PRO.HTML       . >James T Horn <horn@shsu.edu> wrote in message8 >news:843706dc.0312030822.43c61fc3@posting.google.com...C >> While trying to start TCPIP$NTP on 7.3-1, I'm getting the error:  >>= >> VMS timekeeping is not working as expected - can't proceed  >>F >> I've seen the post about the patch, have applied the patch, but I'm4 >> still getting this same message. Any suggestions? >    Dave Harrold  N ..............................................................................N David Harrold                              E-Mail: David_Harrold at aurora.orgI Sr. Software Systems Engineer              Phone:          (414) 647-6204 I                                            Pager:          (414) 941-4634 G Aurora Health Care                         Fax:          (414) 647-4999  3031 W. Montana Street Milwaukee, WI 53215    ------------------------------  $ Date: Fri, 5 Dec 2003 08:12:13 -0600/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> - Subject: RE: Routable Protocol for Clustering T Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC110534FC@ohms.electric.ci.austin.tx.us>  I Good question, but remember, these are networking folks.  They never even  saw a star coupler.    EdE **Please apply a generous amount of all the usual disclaimers here.**      -----Original Message-----; From: Kilgallen@SpamCop.net [mailto:Kilgallen@SpamCop.net]  ) Sent: Thursday, December 04, 2003 6:17 PM  To: Info-VAX@Mvb.Saic.Com - Subject: RE: Routable Protocol for Clustering     
 In articleI <92EFB80E551BD511B39500D0B7B0CDCC110534E6@ohms.electric.ci.austin.tx.us>, 1 "Stuart, Ed" <Ed.Stuart@austinenergy.com> writes: 9 > Here's some specific info from our network engineers...  > G > The only limitations to the Proprietary VMS cluster are self imposed  F > by HP due to the fact that they will not support IP clustering. All F > other major OSs support IP clustering.  There were good reasons for H > the other OSs vendors to do this. A good reason for us is the fact we H > do not have the fiber resources to dedicate paths for Proprietary VMS I > use exclusively.  This fact was made apparent 3 years ago when we made  > > the decision to go IP only on the network, and the resource 9 > limitations were a major consideration in the decision.   K Let's see, their proposal is to make VMS clustering depend on the integrity H of some router software ?   I realize things have changed, but have theyK even considered the design considerations that went into the star coupler ?    ------------------------------  $ Date: Fri, 5 Dec 2003 08:23:07 -0600/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> - Subject: RE: Routable Protocol for Clustering T Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC11053500@ohms.electric.ci.austin.tx.us>  J Thanks for your assistance Mike.  These type of questions and opinions are; just what I was looking for.  I've got some feedback below.   7 > > A good reason for us is the fact we do not have the = > >fiber resources to dedicate paths for Proprietary VMS use   > exclusively. > < > Why not run the direct paths for VMS and also run IP over < > them?  No reason to dedicate paths to VMS clustering only. > L Our network is broken down into various subnets and VLANs and from what I amI told there is a good amount of extra configuration to do to make a single K VLAN be extended and therefore not routed throughout the whole network.  We K are an electric utility and our network is extended over 360 miles of fiber K connecting substations, power plants, office buildings and control centers.    >   This@ > >fact was made apparent 3 years ago when we made the decision  > to go IP eB > >only on the network, and the resource limitations were a major ! > >consideration in the decision.f > A > Again, why not direct LAN links with IP also running over them?  Answered above.a > 1 > What other reasons are there for IP only links? G Standardize on one protocol.  We have already removed IPX, DECnet, LAT,o( Appletalk, and NetBeui from the network. > ; > > Other considerations include the fact that MOST modern   > systems require ? > >fast failovers of <2 seconds.  To run the ancient  flat lan f< > >architecture which  Proprietary VMS requires, means fail  > over times up  > >to 45 seconds.p > 8 > Huh?  The default failover time (RECNXINTERVAL) is 20 ? > seconds, and can usually be shortened by quite a bit.  There  ? > is no "45 second" timer for LANs unless you have those funny  ( > self-configuring lan bridges in there. Yep.   EdE **Please apply a generous amount of all the usual disclaimers here.**    ------------------------------  $ Date: Fri, 5 Dec 2003 08:54:32 -0600/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com>b- Subject: RE: Routable Protocol for ClusteringoT Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC1105350B@ohms.electric.ci.austin.tx.us>  - > > Are there any plans to make LAVC routable/ > > or tunnel LAVC in IP?e > @ > Any entrepreneurial hobbyists out there interested in blazing > > this trail? Maybe a piece of software on a LINUX or (*GASP* > > *CHOKE* *PUKE*) WhineBloze box that "listens" to SCS (LAVc) 0 > and encapsulates it in the appropriate tunnel? >  >nJ Or even better, experiment with multi-site clusters that use fibre channelJ and connect the sites using fibre channel to IP bridges like the ones fromL CNT.  The multi-island SAN that we just bought from HP will be communicatingJ this way.  The only way we were able to get it in here was that it used IPK to go between the sites.  The question that begs answering here is that areSL the SAN islands in the same VLAN and if so why can't we just run our cluster4 in this VLAN since it must be extended to all sites?   EdE **Please apply a generous amount of all the usual disclaimers here.**:   ------------------------------  $ Date: Fri, 5 Dec 2003 08:44:44 -0600/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> - Subject: RE: Routable Protocol for ClusteringiT Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC11053509@ohms.electric.ci.austin.tx.us>  K Thanks for your feedback.  I'm using it to help build my case.  Here's some. answers to your questions.   > ; > > Here's some specific info from our network engineers...I > > < > > The only limitations to the Proprietary VMS cluster are  > self imposed ?C > > by HP due to the fact that they will not support IP clustering.h > ? >     I think that was already covered by Hoff. VMS clustering s= > is much more tightly integrated with the kernel than those a? > other clustering solutions and must be available long before " > the IP stack is running.L Right, but other operating systems are supposedly doing it.  The issue comesC down to which one of the existing clustering technologies support aiL multi-site cluster.  I know how OpenVMS handles it and am trying to researchK how other operating systems handle it.  Supposedly, Windows Advanced ServerwL will multi-site cluster using a "stretch cluster" based on a SAN.  I believeD Linux, Tru64, HP-UX, AIX, Solaris... (see the problem here) will allJ multi-site cluster if they sit on a SAN. You could argue that the downsideK to these clusters might be that they do not have a distributed lock manager-J and the cluster members cannot access the same files at the same time, butK if the Oracle Cluster File System is added to the Windows or Linux servers,2I (part of a 9i RAC implementation), or the HP-UX Service Guard, or Tru64'sCI Cluster File System are added these systems are geographically dispersed,e= have common access to files, and communicate via routable IP.. >  > > All other major(@ > > OSs support IP clustering.  There were good reasons for the  > other OSs H > > vendors to do this. A good reason for us is the fact we do not have B > > the fiber resources to dedicate paths for Proprietary VMS use  > > exclusively. > > >    If you control the fibre ( either owned or leased "dark" ; > fibre ) then why can't you implement a VLAN architecture  > > between the sites and run your VMS cluster on it? You could H > still route the IP traffic to keep different subnets in each location. > > >    I do this with a cluster I have. Two of the nodes are in > > the same room, a third node is in a building about 1/2 mile < > away ( as the fibre runs), across a path spanning 4 Cisco 9 > switches/routers. The two buildings are routed for the  @ > purposes of IP traffic (each a different subnet). The cluster @ > has it's own IP subnet which spans the buildings. It all runs  > over the same pair of fibres. J Our configuration uses the same technology, except our network is over 360H miles of fibre (we are an electric utility), and it connects our controlL centers, substations, administrative offices, and power plants and keeping aJ single VLAN enables throughout the network is time-consuming and difficult (from what I am told). > 8 > > fact was made apparent 3 years ago when we made the  > decision to go IP C > > only on the network, and the resource limitations were a major n" > > consideration in the decision. > @ >     Could a poor choice of routers have limited their ability - > to simultaneously bridge and route traffic?, > ; > > Other considerations include the fact that MOST modern 5 > systems require @ > > fast failovers of <2 seconds.  To run the ancient  flat lan = > > architecture which  Proprietary VMS requires, means fail n > over times up  > > to 45 seconds. > ? >    I have no idea what this statement is supposed to mean. I  D > suspect it means your network folks don't understand VMS clusters.: I agree, that's why I'm trying to get help from the group. > 8 > > for most customers.  We are being asked to change a  > business process  @ > > to match a vendors product, instead of the vendor producing  > a product $ > > to enhance our business process. > 9 >    I get confused here, aren't you already using a VMS  @ > cluster? Does it not have value for your business ( either in  > features it provides or = > simply in the fact that the existing application meet your e> > business needs and would have a real cost to replace? ). If < > so, then aren't the network people asking you to change a < > business process in order to meet their view of what your 4 > network should look like ( tail wagging the dog? )F Yes we have an OpenVMS cluster than spans multiple sites that runs ourJ database servers (Oracle).  We have two main sites and a third site with aJ "quorum watcher."  However, there is a movement within the organization toJ replace these OpenVMS clusters with Red Hat Linux Advanced Server Clusters; using Oracle 9i RAC product.  I'm able to argue the TCO and C high-availability advantages of OpenVMS, but loose when it comes toaL clustering over IP.  It comes down to standards and if IP is going to be theE "standard" protocol on our network, then OpenVMS clusters do not fit.  > 0 > > I'm not saying HP/VMS is not a good OS, just1 > > not a good OS for us under the circumstances.e > @ >   "I'm not saying your network design is not a good one, just 4 > not a good one for us under the circumstances" :-) >  Touche'p   EdE **Please apply a generous amount of all the usual disclaimers here.**s   ------------------------------  * Date: Fri, 5 Dec 2003 17:31:42 +0000 (UTC)7 From: moroney@world.std.spaamtrap.com (Michael Moroney) - Subject: Re: Routable Protocol for Clusteringf( Message-ID: <bqqfdu$nlm$1@pcls4.std.com>  1 "Stuart, Ed" <Ed.Stuart@austinenergy.com> writes:M  K >Thanks for your assistance Mike.  These type of questions and opinions aret< >just what I was looking for.  I've got some feedback below.  = >> Why not run the direct paths for VMS and also run IP over t= >> them?  No reason to dedicate paths to VMS clustering only.- >> -M >Our network is broken down into various subnets and VLANs and from what I amiJ >told there is a good amount of extra configuration to do to make a singleL >VLAN be extended and therefore not routed throughout the whole network.  WeL >are an electric utility and our network is extended over 360 miles of fiberL >connecting substations, power plants, office buildings and control centers.  F In another post you state the VMS cluster is spread over 3 sites.  YouH only need to worry about the links between those 3 sites.  Just run darkH fibre between those 3 sites (3 links) and you can also run IP over them.) All other links can be anything you want.   I Do you have fibrechannel between those sites?  (I think VMS 7.3-2 has SCS  over fibrechannel)  2 >> What other reasons are there for IP only links?H >Standardize on one protocol.  We have already removed IPX, DECnet, LAT,) >Appletalk, and NetBeui from the network.-  J OK, sounds like other protocols were mostly removed for political reasons, not technical ones.:  < >> > Other considerations include the fact that MOST modern  >> systems require n@ >> >fast failovers of <2 seconds.  To run the ancient  flat lan = >> >architecture which  Proprietary VMS requires, means fail g >> over times up s >> >to 45 seconds. >> r9 >> Huh?  The default failover time (RECNXINTERVAL) is 20 i@ >> seconds, and can usually be shortened by quite a bit.  There @ >> is no "45 second" timer for LANs unless you have those funny ) >> self-configuring lan bridges in there.o >Yep.a  D Well, those bridges will give you 45 second failover times no matterG what protocol you run on the LANs (IP, SCS or whatever).  If you really @ need those short failover times, you'll have to get rid of them.I (ps. don't tell anyone, but they use their own non-IP protocol to talk to  each other!)  C Now what does your utility really need?  Maybe VMS standalone nodesgC talking to each other over IP is all that's necessary.  As to othercG "clusters" none is as robust as those on VMS.  Microsoft "clusters" aregJ simply hot failover.  Unix clusters are better, but not quite "there" yet.H Maybe that's OK for your application, maybe not.  You'll have to explainD some features of VMS clustering will no longer be available once you+ switch to something else.  Maybe that's OK.s  C As to VMS clustering over IP, for that to happen the following mustnF happen:  The current SCS layer deep in the bowels of VMS (PEDRIVER andH friends) will have to be trashed and replaced with a low layer IP driverI of some sort.  It has to be up and running very early in the boot, beforeEG (obviously) clustering, disk drivers etc. are up and running.  Now they E will have to trash much/most/all of the TCP/IP layered product to use I this new low-level code rather than what's already there.  And the TCP/IP . protocol isn't very robust in the first place. -- n -Miket   ------------------------------   Date: 5 Dec 2003 06:42:10 -0600,- From: Kilgallen@SpamCop.net (Larry Kilgallen)<- Subject: RE: Routable Protocol for ClusteringP3 Message-ID: <eXRjB4jMOJ8b@eisner.encompasserve.org>v  g In article <DwQzb.305607$ao4.1046935@attbi_s51>, brad@.gateway.2wire.net (Bradford J. Hamilton) writes:se > In article <fOx8v4Dx7Yxx@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:o  N > !Let's see, their proposal is to make VMS clustering depend on the integrityK > !of some router software ?   I realize things have changed, but have theyeN > !even considered the design considerations that went into the star coupler ? > P > This is becoming the "norm" in some IT shops - at my last job, the connectionsQ > to our clusters were going to be arbitrated by a piece of software running on aeQ > Cisco box.  The name of the software company escapes me at present, but I think.5 > the number "5" was part of the name of the company.n > I > Said software was going to "poll" the members of the cluster, and routerF > incoming connections to the least-busy or fastest-responding member.  @ Well that sounds like IP connections, which might be reasonable,= but subjecting the core SCS communications to the vagaries ofe7 external software would be hazardous to cluster uptime..   ------------------------------  % Date: Fri, 05 Dec 2003 11:49:14 -0500t( From: David Froble <davef@tsoft-inc.com>- Subject: Re: Routable Protocol for Clustering * Message-ID: <3FD0B70A.80309@tsoft-inc.com>   Stuart, Ed wrote:   , >>>Are there any plans to make LAVC routable >>>or tunnel LAVC in IP? >>>s@ >>Any entrepreneurial hobbyists out there interested in blazing > >>this trail? Maybe a piece of software on a LINUX or (*GASP* > >>*CHOKE* *PUKE*) WhineBloze box that "listens" to SCS (LAVc) 0 >>and encapsulates it in the appropriate tunnel? >> >> >>L > Or even better, experiment with multi-site clusters that use fibre channelL > and connect the sites using fibre channel to IP bridges like the ones fromN > CNT.  The multi-island SAN that we just bought from HP will be communicatingL > this way.  The only way we were able to get it in here was that it used IPM > to go between the sites.  The question that begs answering here is that are N > the SAN islands in the same VLAN and if so why can't we just run our cluster6 > in this VLAN since it must be extended to all sites? >  > EdG > **Please apply a generous amount of all the usual disclaimers here.**  >   L I'm thinking that your networking people may need to go back to school.  My  understanding is that:  O 1) The network is a physical link, which can support any protocol.  If routers pO are involved, then it should support any routable protocol.  If a network link hQ is robust enough, there is no reason to restrict the protocols.  A seperate link wE for TCP/IP is not a requirement.  Note that capacity can be an issue.e  Q 2) A protocol is a format for data being transmitted over the physical link, the rK network.  You can criple a network to prevent it from doing some things it lK normally can do.  Seem a favorite 'criple' is to only route TCP/IP.  Don't 5L really know why anyone would want to criple a network.  Possibly they don't 4 really know their job, or want to dictate their job.  P I'm still trying to understand, if you are running VMS cluster(s), and it's the M job of the networking people to support your communication requirements, why pM they aren't doing their jobs and implementing a network that satifys all the ,> requirements.  It's the networking people who are screwing up.  P As for the comment about other cluster products running over TCP/IP that I read M earlier, there is a real problem with that comment.  If anyone wants to talk 3Q about any of the other so-called clusters in the same sentence with VMS clusters 0O and IBM Sysplex, then that person just plain doesn't know what they're talking sD about.  A much wider gulf than that between a RollsRoyce and a Yugo.   Dave   -- o4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin RoadI Vanderbilt, PA  15486    ------------------------------  % Date: Fri, 05 Dec 2003 12:45:20 -0500s* From: JF Mezei <jfmezei.spamnot@istop.com>- Subject: Re: Routable Protocol for Clustering ) Message-ID: <3FD0C41D.4536E458@istop.com>d   Michael Moroney wrote:E > As to VMS clustering over IP, for that to happen the following mustsH > happen:  The current SCS layer deep in the bowels of VMS (PEDRIVER andJ > friends) will have to be trashed and replaced with a low layer IP driverD > of some sort.  It has to be up and running very early in the boot,  J Actually, there might be a way to do this without dramatic changes to VMS.L Create what looks like an ethernet card VMS and the machine, but in fact has* its own IP stack and SCS-over-IP software.  M Remember that IP stacks are now commonly embedded into firmware of modems. So-M it shouldn't be impossible to embed it into a specialised PCI card that looksn% exactly like an ethernet card to VMS.r  K However, such card would require knowledge of how to reach another ETHERNETgI address since this is what VMS knows another cluster node as.  Right now,dL about the only way would be ARP but that requires that all other hosts be inF the same subnet. And if they are all in the same subnet, they can't beM separated by a router, which means that you effectively need a bridge. And if M you have a bridge between sites, then your network folks won't care what sort! of ethernet traffic flows.  N Out of curiosity, I have only worked with LAVC clusters. How do nodes identify; each other when you have a different type of interconnect ?    ------------------------------  % Date: Fri, 05 Dec 2003 09:35:45 -0500o* From: JF Mezei <jfmezei.spamnot@istop.com>- Subject: Re: Routable Protocol for Clustering ) Message-ID: <3FD097BB.4B78DDC2@istop.com>b   "Stuart, Ed" wrote:s > K > Good question, but remember, these are networking folks.  They never even  > saw a star coupler.l  K And you could simply argue that the connection between VMS cluster nodes iseP not a "network" connection but a more comprehensive connection between machines.  H Talk to your users and tell them that if they migrate to a Unix "cluster: wannabe", they will be losing such and such functionality.  N Generally users balk at a move which will be a downgrade in functionality. TheP user will then go to the network folks and tell them to continue to support VMS.  J And if you think about having "boxes" encapsulate SCS into IP, you need to consider many items:N -a 1500 byte ethernet SCS packet won't fit into a 1500 byte IP packet. So someN box doing encapsulation would have to also provide for packet segmentation and  reconstitution at the other end.  G -Since cluster nodes identify themselves with their ethernet address, acH request from node A to join a cluster might be received by Node B from aM different ethernet address than A's own ethernet address if there are routers'M or other boxes in the middle. As a matter of fact, if B and C are on one sidetI and try to talk to A on the other side, both B and C's packets to A would S appear, from A's point of view, to come from the same ethernet device (the router).e   ------------------------------   Date: 5 Dec 2003 08:54:15 -0600o- From: Kilgallen@SpamCop.net (Larry Kilgallen)t- Subject: RE: Routable Protocol for Clusterings3 Message-ID: <IaAKRJbvXxti@eisner.encompasserve.org>e   In article <92EFB80E551BD511B39500D0B7B0CDCC110534FC@ohms.electric.ci.austin.tx.us>, "Stuart, Ed" <Ed.Stuart@austinenergy.com> writes:K > Good question, but remember, these are networking folks.  They never evenr > saw a star coupler.-  B Well I have never seen a Cisco router, but I do believe they exist2 and have a purpose (even if it is not my purpose).   ------------------------------  % Date: Fri, 05 Dec 2003 09:41:59 -0500t* From: JF Mezei <jfmezei.spamnot@istop.com>- Subject: Re: Routable Protocol for Clustering ) Message-ID: <3FD09931.79F099B6@istop.com>,   "Stuart, Ed" wrote:wI > Standardize on one protocol.  We have already removed IPX, DECnet, LAT,h* > Appletalk, and NetBeui from the network.  H For the nodes that are "remote", what functionality of clustering do you absolutely require ?  M COuld you achieve the same results with simpler DECNET links between machines M ? Or do you make heavy use of distributed lock manager, shadowed drives etc ?-  F You can route DECNET over IP networks (either with th ereal decnet and@ Multinet, or with DECnet-5 which can appear to be IP to routers)   ------------------------------  % Date: Fri, 05 Dec 2003 22:04:49 +0800 , From: Paul Repacholi <prep@prep.synonet.com>- Subject: Re: Routable Protocol for Clusteringt- Message-ID: <874qwfmkce.fsf@prep.synonet.com>-  1 "Stuart, Ed" <Ed.Stuart@austinenergy.com> writes:2  9 > Here's some specific info from our network engineers...u  F > The only limitations to the Proprietary VMS cluster are self imposedA > by HP due to the fact that they will not support IP clustering.   F The factors behind the design of SCA where determined by lots of studyD and testing, DEC did not just pull them out of thin air. The key btwA is latency, perhaps your nutwork thingies have heard of it. TheirmD statment about `self imposed' are a total load of bullshit. Probably ignorant bullshit at that.  E > All other major OSs support IP clustering.  There were good reasons,' > for the other OSs vendors to do this.u  F The good reason is money. The money they now have you you don't. OtherA than that, what is your point? Anything can be labeled `Cluster',h* that tells you nothing about what it does.  E > A good reason for us is the fact we do not have the fiber resources 8 > to dedicate paths for Proprietary VMS use exclusively.  6 OK, so you are conection limited. That is not unusual.  F > This fact was made apparent 3 years ago when we made the decision toF > go IP only on the network, and the resource limitations were a majorF > consideration in the decision. Other considerations include the factD > that MOST modern systems require fast failovers of <2 seconds.  To= > run the ancient flat lan architecture which Proprietary VMS@< > requires, means fail over times up to 45 seconds.  This isD > unacceptable for all of the critical service systems, which by the@ > way are high availability, which have to share the same pipes.  D This make almost no sense at all. And is `not even wrong' in detail.E Show me a system that requires and does fail over in less than 2 sec.e= And clusters can be set to take a varing time to do a clustere* transition acording to what you needs are.  F > I don't see why we are even wasting time on this discussion, becauseC > it was known well in advance that the network was to be all IP by  > the end of this year.   E We are wasting time, because you asked. If you don't like the answerseA that is your problem. It will sson be your companies problem, butn hey, it's standard....  @ > My understanding was that we were speaking with HP to see whatB > solutions were available as far as IP clustering from them. If aF > solution couldn't be provided by HP, then Proprietary Clustering VMS* > wasn't going to be the system of choice.  D Did you ask for them to give you an upgrade to the speed of light as well?   C > The SANs, and all other recent purchases have revolved around thet= > fact they were IP capable to meet our goals for the network C > backbone.  You are asking us to take a step backward because HP's F > VMS team doesn't want to deal with the realities of WANs and budgetsD > today for most customers.  We are being asked to change a businessE > process to match a vendors product, instead of the vendor producing F > a product to enhance our business process.  I'm not saying HP/VMS isC > not a good OS, just not a good OS for us under the circumstances.   E Fine, enjoy basking in the brilliance of your network engineers. Just-F as a matter of detail, how much in total will have been pissed away be/ these modern wonders by the time this finishes?R   -- u< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Fri, 05 Dec 2003 18:27:23 GMT / From: brooks@cuebid.zko.dec.nospam (Rob Brooks)r- Subject: Re: Routable Protocol for Clusteringi- Message-ID: <fXMamr$rgyxs@cuebid.zko.dec.com>e  9 moroney@world.std.spaamtrap.com (Michael Moroney) writes:oH > In another post you state the VMS cluster is spread over 3 sites.  YouJ > only need to worry about the links between those 3 sites.  Just run darkJ > fibre between those 3 sites (3 links) and you can also run IP over them.+ > All other links can be anything you want.  > K > Do you have fibrechannel between those sites?  (I think VMS 7.3-2 has SCSh > over fibrechannel)   No, it is not in V7.3-2.   -- r  M Rob Brooks    VMS Engineering -- I/O Exec Group     brooks!cuebid.zko.dec.come   ------------------------------  $ Date: Sat, 6 Dec 2003 00:28:10 +0800( From: "Norbert Liew" <nliew@delinux.biz> Subject: RTL/2 AnyoneS) Message-ID: <3fd0b211$1_2@news.tm.net.my>r   Hi,2  L First of all I know this is really obsolete but anyone knows where can I getG a reasonable documentation to learn RTL/2 from scratch ?  Can never getl anything from the net.   Thanks.    Bert.t   ------------------------------  # Date: Fri, 05 Dec 2003 12:01:49 GMTu5 From: rdeininger@mindspringdot.com (Robert Deininger)tJ Subject: Re: Strange FTP behavior (and a followup to my bugcheck message).L Message-ID: <rdeininger-0512030703340001@user-uinj43q.dialup.mindspring.com>  : In article <20031204194804.26022.00000170@mb-m06.aol.com>,& ejheller@aol.com.com (EJHeller) wrote:  " >... Using the Ethereal sniffer, IH >noticed that on the good transfers, the Alpha1000 does not send the 226N >Transfer complete message until after the last data is transferred and on theL >bad transfers the AlphaDS10 sends the 226 message after the transfer of theM >first 2 of 9 data packets. Apparently VxWorks sees the 226 and issues a QUITr( >command, messing up the data transfer.   H I don't know the details of the ftp protocol, but that sounds like a bugB in the ftp server. "Transfer complete" ought to mean what it says.    D Since you have the latest patches, you might want to place a call to software support.v   ------------------------------  % Date: Fri, 05 Dec 2003 10:32:01 +0000fO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> B Subject: Re: Sun to use AMD Opteron - announcement expected Monday0 Message-ID: <bqpmr2$1j9$1@new-usenet.uk.sun.com>   jlsue wrote:J > On Wed, 03 Dec 2003 20:12:51 -0500, JF Mezei <jfmezei.spamnot@istop.com> > wrote: >  >  >>"Main, Kerry" wrote: >>H >>>Even the current SPARC III based servers did not start shipping untilI >>>something like 2000/2001 - approx 4 years after the announcement shown  >>>in this url.a >>>k  >>>Delivery against commitments? >>N >>Sun has no motivation to cripple its own products. It is the sale to neither >>Microsoft nor Intel. >  > L > Which actually only means that Sun has no other alternative at this point. >   ! But you also know that is untrue..  8 Heard of SPARC64 heard of Opteron heard of CMT these are all options.  2 You really arn't doing well on this thread are you  G > HP is in a completely different business position because it has many>I > products in many areas (several server & OS platforms, peripherals, and> > great SAN technology)p >   @ No HP has a great printing business all the rest is just baggage2 and HPS SEC filings only serve to illustrate this. > P >>HP has every motivation to cripple Alpha because they want a cosy relationship! >>with both Intel and Microsoft.   >  > H > And, perhaps, they also realize that having multiple server design andK > manufacturing groups is a waste of resources (there's LOTS of overhead touK > manage the separate businesses).  Bringing all OS platforms to one serverpL > line will allow the company to invest resources in a more focused fashion,# > and all OS platforms can benefit.n >   ' So how similar is a DL580 to a rx5600 ?t   Same OS's no *% Same CPU architecture no IA32 vs IA64(, Same Chipsets no the DL uses the Serverworks' chipset the rx5600 uses HP zx1 chipset.i  ; So how are you going to "focus" engineers onto two entirely 5 different platforms with very very little shared IP ?o  = All you end up with is the commodity disk and DRAM componentso= and all HP needs to get access to economies of scale for themJ= is a central buying organisation which you must of had beforer the merger.o  7 Now how does this compare with HP pre Itanium, well itst3 exactly the same, so sorry but all you have done iso added another platform.o  H > It always bugged me in CPQ that we had the Intel servers and the AlphaM > server businesses, there was virtually zero cross-utilization of investmentlL > - even to the point of the Intel camp investing in another crossbar-switchI > architecture (when we already had an exceptional amount invested in our  > own).e >  > ' >>The current "plan of record" has lessrM >>credibility than their pre-June-25 commitments. Their abandonnement of EV79nL >>further re-enforces the distrust of HP commitments with regards to VMS andM >>Alpha. HP has shown no *real* intentions to fully leverage the potential ofl >>VMS. 7 >  > H > The Alpha line is sold and supported for customers.  Period.  EveryoneF > knows that it's days are numbered, but HP is delivering products andH > services for those that continue to need them.  We actually have *new*H > customers buying Alpha today.  Some even running OpenVMS (and, perhaps) > surprisingly, some running Tru64 UNIX).h >   D This is just spin and you know it. The plan of record for COMPAQ wasA a full Alpha Roadmap including EV8 and beyond and as late as 2002iH Compaq engineers were actually publishing papers about followons to EV8.  h http://portal.acm.org/ft_gateway.cfm?id=545247&type=pdf&coll=GUIDE&dl=ACM&CFID=14731370&CFTOKEN=32180537 Read it and weep.u  B HP's plan of record for Alpha after the merger was to drop EV8 but continue to develop EV79..  @ The fact that you may or may not have new customers buying Alpha> boxes is irrelevant, if they really are new then they were not> the ones who were let down by Compaq/HP's non delivery against; commitments. The people really impacted were the people whoa> built a platform strategy based on commitments from Compaq and? HP which havn't been honoured they are your existing customers.-  = You are well on the way to joining Rob as the person with ther3 highest spin quotient on this newsgroup keep it up.u   Regardsc Andrew Harrison    ------------------------------  % Date: Fri, 05 Dec 2003 08:46:53 -0800s/ From: Greg Cagle <news@removethisgregcagle.com>aB Subject: Re: Sun to use AMD Opteron - announcement expected Monday/ Message-ID: <vt1djthrv52u5b@corp.supernews.com>    Andrew Harrison wrote:  ? > There are 3 separate SPARC processor families all with fundedg4 > teams developing a number of different processors.   So you say.   > > We currently have UltraSPARC IV and V and V's followon under  > development for large servers.   So you say.B  D > In the mid range we have the Ultra IIIi family and followons under
 > developmentm   So you say.e  A > At the Blade level we have the CMT SPARC processors (Gemini andy > Niagara under development.   So you say.r  C > Sun currently has the second largest processor design team behind A > Intel hardly a good example of a vendor that isn't investing ine > its core platform.   So you say.    Can you prove ANY of this?   --  
 Greg Cagle gregc at gregcagle dot com   ------------------------------  # Date: Fri, 05 Dec 2003 14:14:45 GMT # From: "John Smith" <a@nonymous.com>gB Subject: Re: Sun to use AMD Opteron - announcement expected MondayM Message-ID: <pp0Ab.171371$Fv8.131094@twister01.bloor.is.net.cable.rogers.com>'   jlsue wrote:G > On Wed, 03 Dec 2003 14:29:40 +0000, Andrew Harrison SUNUK Consultancys0 > <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >h >> jlsue wrote:e= >>> On Tue, 02 Dec 2003 17:42:14 +0000, Andrew Harrison SUNUK > >>> Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >-H >>>> 2 SPARC is the market leader in the 64bit general purpose processorH >>>> space, by units, by revenues by ISV support so whatever your pointsB >>>> are about non delivery the market doesn't agree with you. The7 >>>> market never agreed with your assessment of Alpha.w >>>  >>>oD >>> What assessment of Alpha are you referring to?  And why bring inA >>> market presence - yet again - when that's not the point beingtD >>> discussed?  It's about business commitment to the platform - and> >>> unless it actually delivers a system based on the researchF >>> investments, it's tough to tell how strong the real commitment is. >>E >> Why bring the market in ?? Well because in an unconstrained marketnA >> with competing products the leaders are normally the ones thata! >> deliver what the market wants.t >w? > But we weren't talking about market.  We were talking about atB > specific, narrow, instance of business decisions and investment. >fE > I will grant you, and everyone else in here, that OpenVMS marketingrE > fell very short of what DEC/CPQ needed if they wanted it to competee > in the market. >oC > But we're talking about chip investment, and whether/how-much the 1 > business managers (BOD) have decided to invest.n >g >>E >> And in the datacenter server market one of the key things that then@ >> market wants is delivery against commitments, consistency and >> investment preservation., >dC > And, again, there appear to be many (at least, in here) who don'tfE > believe that Sun delivered much in quite awhile to keep performanceo@ > leadership. It's been called everything from abysmal, to "good/ > enough"; none of which is a resounding "yay".  > F > I'm not knocking Sun's investment strategy - it seems to have worked# > for them for quite awhile so far.  >r >> >>= >>> Within the context of the discussion, the parallel from asG >>> customer's view of systems actually delivered, could certainly lead G >>> one to feel that the business commitment to SPARC wasn't really all*H >>> that great.  The future sure looks great, but it almost always does. >>>r >>E >> Sorry but the market/customers don't agree with you and never havecA >> why did all those people who didn't buy Alphas in their droves0@ >> buy SPARC based systems instead. Why did Gartner always score2 >> SPARC higher than Alpha in terms of longevity ? > E > Except where customers need higher performance.  And then they wentt > elsewhere.    I But for the bulk of customers, 'good enough' was sufficient because there J was a company behind the 'good enough' product (Sun) that didn't flip-flopL on them with respect to commitments. And that my friends is the sad story ofI Digital/Compaq/ChumHPaq and Alpha/VMS, and soon to be IA64/VMS, technical  marvels though they may be.S  J I swear that if we had hooked up all Digital/Compaq/ChumHPaq exec's to oneC of those nifty HP/Agilent EEG machines, all we'd see is a flat line 	 response.    ------------------------------  % Date: Fri, 05 Dec 2003 09:38:21 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday) Message-ID: <3FD09858.80895177@istop.com>s   John Smith wrote:*L > I swear that if we had hooked up all Digital/Compaq/ChumHPaq exec's to oneE > of those nifty HP/Agilent EEG machines, all we'd see is a flat line  > response.C  M But you'd see instant excitement and healthy heartbeats the minute you said aiM magic phrase such as "Windows will Eviscerate ...." or just mentions "Windows.  Enterprise Edition", or "Intel".  K The Digital/Compaq/HP folsk are ashamed of their own products and prefer to N peddle other people's products. Sun folks are proud of their products and wantA to convince everyone that they products offer the best solutions.i   ------------------------------  % Date: Fri, 05 Dec 2003 10:49:59 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>gF Subject: Re: VMS clusters prove they are the best - Sun comes in last!0 Message-ID: <bqpnsn$1sb$1@new-usenet.uk.sun.com>   Nic Clews wrote:* > Andrew Harrison SUNUK Consultancy wrote: >  >>Bob Ceculski wrote:u >>, >>>http://www.theinquirer.net/?article=13002 >> >>More old BS Bob. >  > . > Did you *bother* to read the actual article? >   3 Yes I was refering to the attempt to link the Dutch 6 example to the MarketingFoolish TCO study for OpenVMS.  3 The MarketingFoolish TCO study is such tosh that ite1 places the whole Register article in the suitable. for chip paper category.   regardso Andrew Harrisoni   ------------------------------  $ Date: Fri, 5 Dec 2003 10:27:23 -0600/ From: "Stuart, Ed" <Ed.Stuart@austinenergy.com>tF Subject: RE: VMS clusters prove they are the best - Sun comes in last!T Message-ID: <92EFB80E551BD511B39500D0B7B0CDCC11053515@ohms.electric.ci.austin.tx.us>  ) Agreed...the study is almost 2 years old.t   EdE **Please apply a generous amount of all the usual disclaimers here.**a     > -----Original Message-----* > From: Andrew Harrison SUNUK Consultancy 1 > [mailto:Andrew_No.Harrison_No@nospamn.sun.com]  ) > Sent: Friday, December 05, 2003 4:50 AMi > To: Info-VAX@Mvb.Saic.Com H > Subject: Re: VMS clusters prove they are the best - Sun comes in last! >  >  > Nic Clews wrote:, > > Andrew Harrison SUNUK Consultancy wrote: > >  > >>Bob Ceculski wrote:u > >>. > >>>http://www.theinquirer.net/?article=13002 > >> > >>More old BS Bob. > >  > > 0 > > Did you *bother* to read the actual article? > >  > 5 > Yes I was refering to the attempt to link the Dutcha8 > example to the MarketingFoolish TCO study for OpenVMS. > 5 > The MarketingFoolish TCO study is such tosh that itu3 > places the whole Register article in the suitablee > for chip paper category. > 	 > regards  > Andrew Harrisona >    ------------------------------  % Date: Fri, 05 Dec 2003 22:34:43 +0800a, From: Paul Repacholi <prep@prep.synonet.com>F Subject: Re: VMS clusters prove they are the best - Sun comes in last!- Message-ID: <87zne7l4e4.fsf@prep.synonet.com>a  , JF Mezei <jfmezei.spamnot@istop.com> writes:  B > does "the enquirer.com" have a wide readership, or is its just aD > covert publication done by a couple of guys who are loyal to VMS ?  F The inq has a very wide readership. Not as big as /. perhaps. Mike wasF one of the founders of The Register, and left it a few years ago to go@ his own way. It was the inq that scooped the alphacide remember.   -- d< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.a@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Fri, 05 Dec 2003 03:55:12 -0500   From: nobody <nobody@nobody.com>5 Subject: Will VMS contribute to Microsoft's profits ?t* Message-ID: <3FD047BA.D55E094E@nobody.com>  / http://www.microsoft.com/mscorp/ip/tech/fat.aspW  K Essentially, Microsoft wants $0.25 for every device built that uses the FAToN file storage design which Microsoft claims to have copyrighted in 1976 (didn't" know Microsoft existed back then).  % (There is a cap of $250,000 dollars).   K Does this mean that ever IA64 based VMS system will have to pay the royaltyrM twice ? Once for the IA64 hardware which understands FAT, and one for the VMSuK system which will store the boot media into a FAT partition enclosed into a 
 VMS file ?   ------------------------------   Date: 5 Dec 2003 11:37:33 -0600h4 From: kuhrt@nospammy.encompasserve.org (Marty Kuhrt)9 Subject: Re: Will VMS contribute to Microsoft's profits ? 3 Message-ID: <lI7sPtQwY$$2@eisner.encompasserve.org>(  M In article <3FD047BA.D55E094E@nobody.com>, nobody <nobody@nobody.com> writes:v1 > http://www.microsoft.com/mscorp/ip/tech/fat.asp  > M > Essentially, Microsoft wants $0.25 for every device built that uses the FATrP > file storage design which Microsoft claims to have copyrighted in 1976 (didn't$ > know Microsoft existed back then). > ' > (There is a cap of $250,000 dollars).n > M > Does this mean that ever IA64 based VMS system will have to pay the royaltySO > twice ? Once for the IA64 hardware which understands FAT, and one for the VMS M > system which will store the boot media into a FAT partition enclosed into at > VMS file ?  D Or do like Micro$quish does.  Modify FAT slightly, call it somethingH slightly different, like RAT.  Get sued, lose, and then refuse to pay.    H Plus, I doubt M$ developed FAT in the first place.  Back then all Billy = did was steal code from dumpsters and remarket it as his own.o   ------------------------------  % Date: Fri, 05 Dec 2003 03:57:06 -0500g* From: JF Mezei <jfmezei.spamnot@istop.com>9 Subject: Will VMS have to pay royalties Microsoft ? (FAT) ) Message-ID: <3FD0482C.B5F79EE6@istop.com>o  / http://www.microsoft.com/mscorp/ip/tech/fat.asp   K Essentially, Microsoft wants $0.25 for every device built that uses the FATlN file storage design which Microsoft claims to have copyrighted in 1976 (didn't" know Microsoft existed back then).  % (There is a cap of $250,000 dollars).h  K Does this mean that ever IA64 based VMS system will have to pay the royaltyiM twice ? Once for the IA64 hardware which understands FAT, and one for the VMS K system which will store the boot media into a FAT partition enclosed into ab
 VMS file ?   ------------------------------  $ Date: Fri, 5 Dec 2003 07:54:11 -07008 From: "Michael D. Ober" <obermd-.@.-alum-mit-edu-nospam>= Subject: Re: Will VMS have to pay royalties Microsoft ? (FAT)s0 Message-ID: <q_0Ab.595$o_.17091@news.uswest.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messagek# news:3FD0482C.B5F79EE6@istop.com...u1 > http://www.microsoft.com/mscorp/ip/tech/fat.aspM >.I > Essentially, Microsoft wants $0.25 for every device built that uses theo FATiH > file storage design which Microsoft claims to have copyrighted in 1976 (didn'tp$ > know Microsoft existed back then). > ' > (There is a cap of $250,000 dollars).l >eE > Does this mean that ever IA64 based VMS system will have to pay thee royaltynK > twice ? Once for the IA64 hardware which understands FAT, and one for the  VMScK > system which will store the boot media into a FAT partition enclosed into  au > VMS file ?  I Microsoft got its start by writing BASIC for the M.I.T.S. Altair personaloK computer.  Bill Gates and Paul Allen demo'd BASIC for this machine in early L 1975.  The biggest impact of Altair-BASIC was the file system, which used anJ allocation table to bring the concept of scattered (cluster based) storageK to the files.  This was the first FAT file system and it was the first timeuJ .  Prior to this, microcomputer (and many mini-computer) files were always& stored as a single, contiguous, block.  G As for the royalty issue, I'm not sure how enforceable this is since MStL didn't attempt to get any royalties.  Even if the royalties are enforceable,D it appears that the max HP would have to pay is 250,000 for (DigitalG Equipment Corporation), since HP and Compaq got the FAT file system vias MS-DOS OEM licenses.   Mike..   ------------------------------   End of INFO-VAX 2003.673 ************************