1 INFO-VAX	Sun, 30 Jun 2002	Volume 2002 : Issue 356       Contents:& Re: Capellas resigns from Dynegy board& Re: Capellas resigns from Dynegy board% Re: Delay in publication of VMS books $ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications...( Re: Has SMTP RBL list worked for anyone? Re: parsing >255? RE: PL/I apps on IPF (was RE: Fearless IPF Prognostications...)  Re: Segmented keys" Re: Sun benchmarketeering campaign( Re: TELNET service startup file missing? Re: Worldcom MCI and VMS Re: Worldcom MCI and VMS Re: Worldcom MCI and VMS Re: Worldcom MCI and VMS Re: Worldcom MCI and VMS Re: Worldcom MCI and VMS  F ----------------------------------------------------------------------    Date: 30 Jun 2002 02:21:55 +0800, From: Paul Repacholi <prep@prep.synonet.com>/ Subject: Re: Capellas resigns from Dynegy board - Message-ID: <878z4y3pz0.fsf@prep.synonet.com>   / JF Mezei <jfmezei.spamnot@videotron.ca> writes:    > Marty Kuhrt wrote:  C > > When I first read the subject I only saw "Capellas resigns" and A > > rejoiced!  CPQ always stood for "Capellas Please Quit" to me.    F > This guy just doesn't seem to be "board member" material to me. JustA > look at his pictures that seem to be taken from a shopping mall C > picture booth whereas Carly's pictures were definitely taken by a / > professional photograph in a serious session.   6 He is exelent board material. Two of them, with nails.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sat, 29 Jun 2002 19:36:57 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> / Subject: Re: Capellas resigns from Dynegy board > Message-ID: <t%nT8.194137$R61.68132@rwcrnsc52.ops.asp.att.net>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in message ' news:878z4y3pz0.fsf@prep.synonet.com... 1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes:  >  > > Marty Kuhrt wrote: > E > > > When I first read the subject I only saw "Capellas resigns" and C > > > rejoiced!  CPQ always stood for "Capellas Please Quit" to me.  > H > > This guy just doesn't seem to be "board member" material to me. JustC > > look at his pictures that seem to be taken from a shopping mall E > > picture booth whereas Carly's pictures were definitely taken by a 1 > > professional photograph in a serious session.  > 8 > He is exelent board material. Two of them, with nails.  I Without commenting one way or t'other on Mr. Capellas, I think abdicating > the Dynegy board was a prudent move. From Dow Jones we have...  C Dynegy the Latest Energy Trader to Have Debt Rating Hit Junk Status D Updated: Friday, June 28, 2002 05:30 PM ET  Printer-friendly version   Dow Jones Newswires L CHICAGO -- Moody's Investors Service downgraded Dynegy Inc.'s debt rating toH junk status Friday, making the Houston-based energy trader the latest toJ feel the sting of heightened scrutiny by the ratings agency in the wake of the collapse of Enron Corp.    ------------------------------    Date: 29 Jun 2002 18:35:17 -0700( From: bob@instantwhip.com (Bob Ceculski). Subject: Re: Delay in publication of VMS books= Message-ID: <d7791aa1.0206291735.4ea86069@posting.google.com>    winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote in message news:<00A102E0.DA2C1753@SSRL04.SLAC.STANFORD.EDU>...G > In article <3D1DD318.90609@home.nl>, Dirk Munk <munk@home.nl> writes:  > Q > >Many of us were hoping to receive our copies of "OpenVMS with Apache, OSU and  G > >WASD" and of the "OpenVMS System Management Guide" by now, but alas.  >    > > S > >Both books were scheduled for publication on June 15. However the first book is  Q > >scheduled now to be published on August 30, and the second book isn't even on  F > >the web pages of the publisher yet (that is not the new edition !). > >  > M > I can't speak to the "OpenVMS System Management Guide", but as to the other L > one, the delay is all my fault.  That's the first book I've written, and IK > seriously underestimated the time and trouble it would take.  I returned  H > corrected proofs to the relevant freelance Frame person in early June. > O > >I just hope the books will be up to date when they are published (Apache 2.x  > and  VMS 7.3-1). > N > The book will have inevitably fallen somewhat behind.  There won't be a CSWSO > based on Apache 2.x by the publication date, but WASD 8.0 (maybe 8.1) will be P > out and the book is based on 7.2; OSU 3.9 and 3.10alpha are covered, but 3.10aQ > is out.  The book isn't particularly OS-version specific, but my tests were all  > done on VMS 7.2-2. >  > Sorry to disappoint. > 	 > -- Alan  >   8 you already did disappoint ... you left out Purveyor ...   ------------------------------  # Date: Sat, 29 Jun 2002 19:34:52 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> - Subject: Re: Fearless IPF Prognostications... ' Message-ID: <3D1E0FE8.4AF4EEA2@fsi.net>    JF Mezei wrote:  >  > Bill Todd wrote:N > > anyway).  If Itanic sinks, the choice will be whether to let VMS *and* NSK% > > sink with it or just let NSK sink  > M > During the merger pregnancy, remember that Carly had no problems mentioning O > that Tandem would survive, but went through great lengths to avoid mentioning N > VMS at all. Profits or not, it seems to me that Tandem is a sacred cow whileI > VMS is rotten meat that should be disposed of in the long term. So when M > choosing a replacement platform for IA64, I suspect that NSK,s requirements # > would have more weight than VMS'.   , For what little it may be worth (FWLIMBW)...  F I believe its possible that the "key" decision makers among HP and theC former Q see the world as already being 100% Gatesian, and that VMS F folks, Tru64 folks, HP-UX folks, etc. are little more than "cling-ons"C who have yet to shake loose from "spaceship Windows", while Linux's 7 "Tuxans" are, to draw a parallel, the "Rebel Alliance".   E It is only when they see the potential dollar value (to them) of VMS, G etc. that they will embrace "diversity" and seek to exploit for fun and # profit that which they already own.   F How to resolve that problem is the "eternal question" which keeps this noosegroup humming like a hive.   H ...IMHO, YMMV, void where prohibited by law, no purchase necessary, some6 restrictions apply, see store display for details, ...   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Sat, 29 Jun 2002 20:06:23 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com> - Subject: Re: Fearless IPF Prognostications... . Message-ID: <3roT8.198806$nZ3.95308@rwcrnsc53>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3D1E0FE8.4AF4EEA2@fsi.net...    > . > For what little it may be worth (FWLIMBW)... > H > I believe its possible that the "key" decision makers among HP and theE > former Q see the world as already being 100% Gatesian, and that VMS H > folks, Tru64 folks, HP-UX folks, etc. are little more than "cling-ons"E > who have yet to shake loose from "spaceship Windows", while Linux's 9 > "Tuxans" are, to draw a parallel, the "Rebel Alliance".   F Possible, but IMHO unlikely. Now that the merger's done and everyone'sK slithered out of the clean rooms, the VMS folks have established tight ties F with their HP counterparts in HP-UX, HP Labs, firmware engineers. GoodL access to code, project plans, test tools, developer working groups, etc. AtH least from the perspective of the ZKO folks, HP is serious about the VMS effort.   L The VMS Boot Camp/Immersion Course has a cost in terms of resources and $$$.I While the investment is admittedly modest, at least HP is willing to make : it. Was such a course offered in the pre-acquisition days?   > G > It is only when they see the potential dollar value (to them) of VMS, I > etc. that they will embrace "diversity" and seek to exploit for fun and % > profit that which they already own.   I Every new Windows security vulnerability will help the HP Honchos see the F light, especially with the increased emphasis on security and business continuity these days.  H The "Tuxans" apparently have gained some momentum. Note how earlier this< year Compaq started emphasizing Windows AND LINUX in all its  ProLiant-related press releases.   > H > How to resolve that problem is the "eternal question" which keeps this! > noosegroup humming like a hive.   A T'is the never-ending burden of the VMS Marketing Volunteers. ;-}    ------------------------------  % Date: Sat, 29 Jun 2002 22:55:10 +0100  From: nic <junk@127.0.0.1>- Subject: Re: Fearless IPF Prognostications... ) Message-ID: <3D1E2CBE.86E9A872@127.0.0.1>    JF Mezei wrote:  >  > "Terry C. Shannon" wrote: P > > Likelihood that VMS will end up being more portable (to other architectures)! > > as a result of IPF port: 0.99  > N > From a technical pont of view, what will be changed inside of VMS to make it > more portable ?   G In the beginning [for VMS] was the VAX, and a lot was done in hardware. ? (Well OK, the first one as emulated in SPICE on a PDP/11 AFAIK)   D Later on came the Alpha, some was done in hardware, some was done in5 PALcode (firmware), the rest was moved into software.   F Coming is Itanium, and pretty much it's all being moved into software.C i.e. VMS does what it needed the hardware to do in the past, so, as H Terry suggests, porting VMS onto any other 64 bit architecture will be a walk in the park.    H > Or is the additional portability going to be the result of better codeO > management (eg: the effort to make a common source code for alpha/IA64 making ( > it easier to then add new platforms) ?  = Lessons were taken from the Alpha development of VMS, and the A opportunity has been taken to move hardware dependency out of the G operating system. Speaking to one of the guys closely involved with the H port, it is a fallacy to believe that the Alpha was optimized in any wayE for VMS, or the other way round. As far as the differences go between G Itanium and Alpha, it will be swings and roundabouts in the performance  stakes.   = However, performance on any chip is almost irrelevant, as the H portability grants the opportunity to move VMS easily to whatever 64 bit chip is dominant.    --   Regards, Nic Clews (from home), nic at python dot demon dot co dot uk (play) nclews at csc dot com (work)   ------------------------------  % Date: Sat, 29 Jun 2002 23:07:11 +0100  From: nic <junk@127.0.0.1>1 Subject: Re: Has SMTP RBL list worked for anyone? ) Message-ID: <3D1E2F8F.4F696376@127.0.0.1>    Steven Thompson wrote: >  > Hi Nic > J > Do you have a permanent conection with your ISP and thus a permanent IP?  C No, not always on. I do have a permanent IP though. If I went for a E broadband connection, I could not use SMTP, only POP, which is one of C the things holding me back (cost justification* and availability is 
 another :-( )    D * The mains power needed to keep a 4000 series machine powered 24x7!  * > You could try reversing the MX priority.D > Give yourself a smaller number and therefore a higher MX priority.G > Your ISP will still cache your mail but only when your SMTP server is  > unavailable.K > That way the RBL should work. Maybe worth a try, as the disruption to the  > DNS is minimal.   D My ISP is Demon, and they have a habit of believing they know betterH than me. I've argued the toss about RBLs, even though their mail serversE are straining under the spam loading. I'll try changing the priority, @ however as I've said, a fair number (most) of the spammers in my( experience don't use servers in the RBL.   Thanks for the suggestion.   --   Regards, Nic Clews (from home), nic at python dot demon dot co dot uk (play) nclews at csc dot com (work)   ------------------------------  % Date: Sat, 29 Jun 2002 20:25:41 -0400 1 From: Michael Austin <maustin@firstdbasource.com>  Subject: Re: parsing >255 1 Message-ID: <3D1E5005.44D3249@firstdbasource.com>    "David J. Dachtera" wrote: >  > Chuck Aaron wrote: > > 
 > > Group, > > @ > > It appears DCL command procedures cannot parse more than 255H > > characters at one time into a single form_fld buffer. Is there a way9 > > around this or is this still an internal restriction?  > J > I believe that's still a known restriction. In some cases, it can handleC > strings as long as 510 bytes, but 255 seems to be the safest bet.  >  > -- > David J. Dachtera  > dba DJE Systems  > http://www.djesys.com/ > * > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/   > First of all, which Web server ( I assuming OSU because of the form_fld symbols).  @ If you need to process more than 255 bytes there are a couple of ways to do it.  7 I have modified/cut/pasted some very simple C code that > manipulates up to 8KB but, quite frankly doesn't support everyA thing you can do in a web CGI environment, but it works for me...   A Anything else will make it difficult to manipulate that data.  If > I were you, I would convert this particular piece of code into= either PERL or PHP. Both of which will run from a DCL command > procedure and if you are using Apache, can call either Perl or@ PHP directly. I have some code I wrote on a Unix machine I moved9 to the Alpha with either very minor or no changes at all.    --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163 7 Sr. Consultant            http://www.firstdbasource.com                            + http://www.firstdbasource.com/donation.html / 704-947-1089 (Office)     704-236-4377 (Mobile)    ------------------------------    Date: 29 Jun 2002 20:08:08 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) H Subject: RE: PL/I apps on IPF (was RE: Fearless IPF Prognostications...)3 Message-ID: <CAacxueDahC7@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIEEFJFEAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: H > Of course, a binary translator, doesn't need to know what the originalF > source languqage was.  Making the PL/I runtime avaialble on IPF is aH > piece of cake, since it is all C code, and that is the first thing we ' > will provide, both for VMS and Tru64.  > " > I hope that addresses the issue.  > The Translated Image Environment on Alpha has separate runtime4 libraries specifically to support translated images.   ------------------------------    Date: 29 Jun 2002 19:04:56 -0700# From: dooleys@snowy.net.au (dooley)  Subject: Re: Segmented keys = Message-ID: <1ca82fc6.0206291804.43bc9d28@posting.google.com>   a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3D1D6930.DF8CFDE0@videotron.ca>... P > If I need to do a keyed access to a file whose key is segmented, how do I fill > the RAB  key_buffer ?  > . > The grey manuals don't seem to mention this.  3 you should beg, borrow, or steal a documentation cd 7 the "guide to openvms file applications" is a bit more  ' readable thean the rms reference manual    > L > Do I supply a single buffer made up of a concatenated string that containsO > full length key values in the order of the key definition ? (seg0, seg1 etc).    B you supply a single string, but it doesn't have to be full length   B > Suppose I have a segmented key that is CITY[30] and Province[2].   fine, RAB$B_KSZ will be 32   > F > It is possible for me to supply a CITY value that is shorter than 30 > chartacters ?   8 yes, but if you do, you will be using "generic" matching" so the province will be irrelevant   > P > With a non-segmented key, one can supply a key that is shorter than the file'sM > key and you get the first record that matches. But with a segmented key, is  > that functionality lost ?    no  < have a look at how to use RAB$L_ROP for indexed file optionsG you have to choose a combination of RAB$V_EQNXT RAB$V_NXT and RAB$V_REV 6 this gives you a choice of going forwards or backwards  using exact or generic matching  Phil   ------------------------------    Date: 30 Jun 2002 01:28:06 +0800, From: Paul Repacholi <prep@prep.synonet.com>+ Subject: Re: Sun benchmarketeering campaignd- Message-ID: <87hejm3sgp.fsf@prep.synonet.com>e  W Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> writes:n  * > I await your answer with great interest.  D Perhaps you can read the Sun Bumph about their TPC-H results to pass+ the time? 26% better than x86 with a 15K...e   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 29 Jun 2002 18:13:46 -0700# From: dooleys@snowy.net.au (dooley)m1 Subject: Re: TELNET service startup file missing?n= Message-ID: <1ca82fc6.0206291713.34100661@posting.google.com>   \ Alder <PGDEHMKOKIMD@spammotel.com> wrote in message news:<3D1D4D16.5030409@spammotel.com>... > JF Mezei wrote:aR > > It is normal that there is no telnet srartup file in sys$manager. Telnet isn'tH > > a "normal" service, it is closer to a fancy terminal driver I think. > > # > > You can enable/disable it with:  > >  > > ! > > $TCPIP DISABLE SERVICE TELNETt > >  > > or:r
 > > $TCPIP > > TCPIP> HELP ENABLE s > > TCPIP> HELP DISABLEo >  > Thanks JF, > G > I was just going on the TCPIP docs which said the TELNET_STARTUP.COM C > file was "supplied". > 	 > Cheers,  > Alder    It does appear in 5.1    tcpip show ver    ?   Compaq TCP/IP Services for OpenVMS Alpha Version V5.1 - ECO 1 6   on a AlphaServer 2000 4/233 running OpenVMS V7.2-1     $ !a, $ ! File name:      TCPIP$TELNET_STARTUP.COM6 $ ! Product:        Compaq TCP/IP Services for OpenVMS $ ! Version:        V5.1-02e  5 it does some checks, installs images, defines logicalm6 names, and allows a site specific procedure to be run. Phil   ------------------------------  # Date: Sat, 29 Jun 2002 19:39:47 GMTs* From: "Bill Todd" <billtodd@metrocast.net>! Subject: Re: Worldcom MCI and VMSeB Message-ID: <72oT8.449446$Gs.32595498@bin5.nnrp.aus1.giganews.com>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D1DE368.6BDE6F2C@videotron.ca...   ...e  I > And as far as clustering, isn't it possible to have an application on aiH > (primitive) unix cluster that automatically reconnects to another node whenJ > the node you're connected to fail ? I realise it may not be as pretty as the C > VMS solution, but is it possible ? Or is it truly architecturallyo
 impossible	 > to do ?e  I It's certainly possible on Solaris, since its resource sets include theiriL own IP addresses that can fail over to another node.  I'd hate to think thatH it's not on Tru64 (I don't happen to *know* that this particular featureH exists there, but I strongly suspect that it, or something very similar, does).   - bill   ------------------------------  % Date: Sat, 29 Jun 2002 17:23:52 -0600 % From: Dan O'Reilly <dano@process.com>t! Subject: Re: Worldcom MCI and VMSoB Message-ID: <5.1.0.14.2.20020629172245.01b314b0@raptor.psccos.com>  & At 10:42 AM 6/29/2002, JF Mezei wrote: >arturo saavedra wrote:- > > H > > Clustering.   VMS system goes down in our cluster environment, they 
 > only seeL > > a glitch, the user session drops, but reconnects automatically.. almost  > as aK > > network hiccup.   Tru64 folks would need to wait until their system wasn/ > > backup to a. start he application b. login.1 >@O >Ok, someone mentioned non-paged pool. Does this mean that on unix, there is nouO >concept of memory that cannot be paged ?  On Unix, if you have sufficient RAM,nI >wouldn't it be possible to achieve a similar level of performance  sinceG, >pageable memory wouldn't need to be paged ?  H No, think of an incredibly fast database that runs in non-paged pool andH uses system services for access.  No conventional commercial product can9 come close to the requirements this database has upon it.n   ------I +-------------------------------+---------------------------------------+uI | Dan O'Reilly                  |                                       |iI | Principal Engineer            |  "Why should I care about posterity?  |lI | Process Software              |   What's posterity ever done for me?" |eI | http://www.process.com        |                    -- Groucho Marx    |tI +-------------------------------+---------------------------------------+w   ------------------------------  % Date: Sat, 29 Jun 2002 17:25:11 -0600 % From: Dan O'Reilly <dano@process.com>b! Subject: Re: Worldcom MCI and VMS B Message-ID: <5.1.0.14.2.20020629172430.01b3a020@raptor.psccos.com>  ' At 01:39 PM 6/29/2002, Bill Todd wrote:c  ; >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in messageM' >news:3D1DE368.6BDE6F2C@videotron.ca...  >- >... > K > > And as far as clustering, isn't it possible to have an application on a-J > > (primitive) unix cluster that automatically reconnects to another node >when L > > the node you're connected to fail ? I realise it may not be as pretty as >theE > > VMS solution, but is it possible ? Or is it truly architecturallyt >impossibley > > to do ?  >kJ >It's certainly possible on Solaris, since its resource sets include theirM >own IP addresses that can fail over to another node.  I'd hate to think thatrI >it's not on Tru64 (I don't happen to *know* that this particular featuregI >exists there, but I strongly suspect that it, or something very similar,  >does).   F "Clustering" in the UNIX and Windows arena is still more appropriatelyI called "fast failover".  I know of no clustering implementation the works  like VMS's does.   ------I +-------------------------------+---------------------------------------+MI | Dan O'Reilly                  |                                       |dI | Principal Engineer            |  "Why should I care about posterity?  | I | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    |aI +-------------------------------+---------------------------------------+t   ------------------------------  % Date: Sat, 29 Jun 2002 20:50:47 -0400d1 From: Michael Austin <maustin@firstdbasource.com>t! Subject: Re: Worldcom MCI and VMS 2 Message-ID: <3D1E55E7.9883720A@firstdbasource.com>   Dan O'Reilly wrote:o > ) > At 01:39 PM 6/29/2002, Bill Todd wrote:  > = > >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in messagea) > >news:3D1DE368.6BDE6F2C@videotron.ca...  > >  > >... > >tM > > > And as far as clustering, isn't it possible to have an application on a L > > > (primitive) unix cluster that automatically reconnects to another node > >when N > > > the node you're connected to fail ? I realise it may not be as pretty as > >theG > > > VMS solution, but is it possible ? Or is it truly architecturally.
 > >impossible>
 > > > to do ?a > >aL > >It's certainly possible on Solaris, since its resource sets include theirO > >own IP addresses that can fail over to another node.  I'd hate to think thatbK > >it's not on Tru64 (I don't happen to *know* that this particular featureaK > >exists there, but I strongly suspect that it, or something very similar,k	 > >does).  > H > "Clustering" in the UNIX and Windows arena is still more appropriatelyK > called "fast failover".  I know of no clustering implementation the worksc > like VMS's does.  = aside from Tru64 TruCluster (V5.1+). it does and does it verye& well.. from what I have seen at least!   >  > ------K > +-------------------------------+---------------------------------------+eK > | Dan O'Reilly                  |                                       |,K > | Principal Engineer            |  "Why should I care about posterity?  |eK > | Process Software              |   What's posterity ever done for me?" |eK > | http://www.process.com        |                    -- Groucho Marx    |iK > +-------------------------------+---------------------------------------+      -- i Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163l7 Sr. Consultant            http://www.firstdbasource.com                           y+ http://www.firstdbasource.com/donation.htmlh/ 704-947-1089 (Office)     704-236-4377 (Mobile)    ------------------------------  % Date: Sat, 29 Jun 2002 21:09:46 -0400 ' From: Howard S Shubs <howard@shubs.net>e! Subject: Re: Worldcom MCI and VMSz< Message-ID: <howard-C168D4.21094529062002@enews.newsguy.com>  B In article <5.1.0.14.2.20020629172245.01b314b0@raptor.psccos.com>,'  Dan O'Reilly <dano@process.com> wrote:   J > No, think of an incredibly fast database that runs in non-paged pool andJ > uses system services for access.  No conventional commercial product can; > come close to the requirements this database has upon it.o  F If it's the one I heard of, it made the VMS team fix certain problems > with said nonpaged pool.  Back then, it was only 800MB.  Only.   -- d# "Run in circles, scream and shout!"h I hope you have good backups!I) Are there any more networked SJFs around?    ------------------------------  # Date: Sun, 30 Jun 2002 01:45:19 GMT * From: "Bill Todd" <billtodd@metrocast.net>! Subject: Re: Worldcom MCI and VMSWC Message-ID: <PotT8.196415$_j6.10131799@bin3.nnrp.aus1.giganews.com>e  > "Michael Austin" <maustin@firstdbasource.com> wrote in message, news:3D1E55E7.9883720A@firstdbasource.com... > Dan O'Reilly wrote:t > >,+ > > At 01:39 PM 6/29/2002, Bill Todd wrote:f > >.? > > >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message,+ > > >news:3D1DE368.6BDE6F2C@videotron.ca...h > > >i > > >... > > >lJ > > > > And as far as clustering, isn't it possible to have an application on aI > > > > (primitive) unix cluster that automatically reconnects to anothere node	 > > >whenAF > > > > the node you're connected to fail ? I realise it may not be as	 pretty as  > > >theI > > > > VMS solution, but is it possible ? Or is it truly architecturallyd > > >impossible  > > > > to do ?  > > >gH > > >It's certainly possible on Solaris, since its resource sets include theirtL > > >own IP addresses that can fail over to another node.  I'd hate to think thatE > > >it's not on Tru64 (I don't happen to *know* that this particularu featureiD > > >exists there, but I strongly suspect that it, or something very similar, > > >does).  > >tJ > > "Clustering" in the UNIX and Windows arena is still more appropriatelyG > > called "fast failover".  I know of no clustering implementation thee works  > > like VMS's does. >a? > aside from Tru64 TruCluster (V5.1+). it does and does it verya( > well.. from what I have seen at least!  ( The funny thing is, all of us are right.  G VMS clustering does indeed differ noticeably from fail-over clustering,vD principally in how the file system is shared (all aspects, including) metadata, are shared, under DLM control).   I Tru64 clustering does *not* work the same way VMS clustering does in thisbF area:  while some aspects of Tru64's cluster file mechanisms can allowK direct disk access for *user data* by multiple nodes (using DLM facilities, J IIRC), metadata handling for any given portion of the file system is still? the responsibility of a single node, and if that node fails them* responsibility fails over to another node.  L But that works just fine.  Fail-over, as long as a log-protected file system< is used that does not require a lengthy verification scan onL restart/fail-over, can execute very nearly as quickly as the distributed DLMK reorganization that takes place if any cluster node fails:  while fail-overbK configurations sometimes take as long as a minute to recover from a failuregK (as did the VMS DLM in early days:  delays of as much as 5 minutes were not)F unknown), if heartbeat-style polling is done every few seconds then itI doesn't take many additional seconds for the fail-over to complete (i.e.,o4 comparable to current VMS DLM lock-rebuild latency).  I Now, except for Tru64 and AIX (which cloned the VMS DLM close to a decade K ago), most Unix environments don't support a DLM that applications can use.iB But application use of the DLM was not at issue in the point underA discussion above:  it just referred to the ability for clients to J reestablish on-going activity with a resource failed over to another node,G and several Unix environments can handle this in a manner *functionally B equivalent to* (though different in details from) VMS's abilities.   - bill   ------------------------------   End of INFO-VAX 2002.356 ************************but 255 seems to be the safest bet.  >  > -- > @    A    B    C    D    E    F    G    H    I    J    K    L    M    N    O    P    Q    R    S    T    U    V    W    X    Y    Z    [    \    ]    ^    _    `    a    b    c    d    e    f    g    h    i    j    k    l    m    n    o    p    q    r    s    t    u    v    w    x    y    z    {    |    }    ~                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             	    
            
                                                                                 !    "    #    $    %    &    '    (    )    *    +    ,    -    .    /    0    1    2    3    4    5    6    7    8    9    :    ;    <    =    >    ?    @    A    B    C    D    E    F    G    H    I    J    K    L    M    N    O    P    Q    R    S    T    U    V    W    X    Y    Z    [    \    ]    ^    _    `    a    b    c    d    e    f    g    h    i    j    k    l    m    n    o    p    q    r    s    t    u    v    w    x    y    z    {    |    }    ~                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        