1 INFO-VAX	Wed, 23 Aug 2006	Volume 2006 : Issue 469       Contents: Re: Alpha remembrance day % Re: ANN: DynDNS update client for VMS  Re: Datatrieve/CDD protection  Heresy!! Free Sun Stuff!!  KZPBA-CB and PWS 433au problems # Re: KZPBA-CB and PWS 433au problems # Re: KZPBA-CB and PWS 433au problems # Re: KZPBA-CB and PWS 433au problems # Re: KZPBA-CB and PWS 433au problems # Re: KZPBA-CB and PWS 433au problems + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS + Re: No more Oracle Standard Edition for VMS  Re: On-chip, 7-way associative Re: On-chip, 7-way associativeA Re: openvms - java - timezone - daylight savings - what the heck! 2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node2 Re: SEPPUCLU bugcheck introducing new cluster node  F ----------------------------------------------------------------------    Date: 23 Aug 2006 08:09:49 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1156345789.577946.309020@i42g2000cwa.googlegroups.com>    Bill Todd wrote: > Michael Kraemer wrote:9 > > In article <44E6087E.FA9BDDEC@teksavvy.com>, JF Mezei * > > <jfmezei.spamnot@teksavvy.com> writes: > > K > >> Well, considering it was the first "mainstream" 64 bit architecture, I M > >> wouldn't say that Alpha was late. If at all, it was early to the market.  > > F > > even if it were true (Andrew corrected you on that one), so what ?M > > It is just now, more than a decade later that people start really looking  > > at 64 bit stuff. > J > Ah, you must be a PC weenie:  that could explain a lot.  Of course, evenF > PC weenies might have recognized what benefits a 64-bit architectureH > could confer on systems configured with 4 GB or less of RAM (let aloneH > the 64 GB that IA32 servers have supported since 1996 - hmmm, I wonderD > why Intel bothered with that?) if he were familiar with NT/2K/XP'sJ > 32-bit approach to its file system cache and how much *virtual* space it > can waste. >   C It would be nice if the benefits of 64bit are as clear as you think G they are it would also be nice if your Windows filesystem cache example 2 was really a 32bit issue and not just an MS issue.  ( However as is usual neither is the case.  D Most vendors who support dual 64/32 bit architectures such as SPARC,F POWER and x86-64 try to ensure that people only port applications thatG will benefit from being 64bit to being a native 64bit application. This @ is not just because the effort involved would be wasted but alsoE because in some cases the 64bit ports will be slower than their 32bit D counterparts. OSnews and other online publications are peppered withG tests illustrating the negative impact of native 64bit applications for E some commonly used tools and applications. Performance hits can be up C to 20% with other issues such as larger executables on disk, bigger @ memory footprint and higher cache useage.  Most vendors identifyF applications that can use more than 4GB of memory, with other benefits$ after that which have lower returns.  B Your point about 32bit filesystem caching may be valid for WindowsG however other 32bit OS's such as Solaris did not have this problem, the D Solaris 2.x UFS buffer cache could be larger than 4GB despite the OSC only being 32bit. Sun even had a marketing name of SuperCaching for  this.   D So much for your claims for the universal understanding of the 64bit benefit.  B The reality is that 64bit VLM support in Tru64 was of very limitedD benefit because the AlphaServer platform was not configurable with aD usefull amount of memory, CPU's and I/O. Having to trade I/O/CPU and< memory slots in configurations ment that having a decent I/OE infrastructure of decent number of CPU's severely limitted the number  of slots available for CPU's.   D The hype arround VLM created by Digital caused some customers to buyE TurboLasers to host 64bit versions of Oracle, it quickly became clear G to most of them that the other limitations of the platform limitted the " benefits they might have acheived.  C The TurboLaser held the TPC OLTP performance crown between 1995 and E 1996 but was overtaken by HP, Sun and IBM. Alpha boxes never featured A in the TPC OLTP stakes again except by using multi-node clusters.   C The issues configuring the TurboLaser to make best use of its large A memory support is well illustrated by the TPC-C results posted by C Digital. Despite supporting 14 CPU's no 8400 results exist for more D than 10 CPU's and most are for 8, this is mainly because in order toE get enough memory to support the benchmark and enough I/O Digital had  to drop CPU's from the config.      J > The more serious part of the industry has of course been 'really looking? > at 64 bit stuff' for considerably longer - it having been one I > significant reason, for example, why Tru64 enjoyed the level of success G > it did despite its owner's earlier Unix missteps, and why the rest of G > the RISC brigade tried to catch up with Alpha and MIPS in that regard  > sooner rather than later.  >   E Again you are mistaken, Sun spent a great deal of time worrying about D losing business to Alpha because of its 64bit support. However afterB the initial flurry of purchases many customers discovered that youF couldn't really benefit from having a 64bit platform at least not with" Alpha and so Sun stopped worrying.   Regards  Andrew Harrison    ------------------------------  % Date: Wed, 23 Aug 2006 13:17:58 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> . Subject: Re: ANN: DynDNS update client for VMSJ Message-ID: <paul.sture.nospam-8B2F0E.13175823082006@mac.sture.homeip.net>  0 In article <12elgg73f5gn3a6@corp.supernews.com>,,  Mark Daniel <mark.daniel@vsm.com.au> wrote:   > % > There's a bit more to it of course.  > D > DynDNS' specifications have a number of policies regarding client E > behaviour.  These, amongst other requirements, limit the number of  J > accesses to their web-based client IP identification service in a given H > period, and require that the update service only be accessed when the G > client's IP address has actually changed.  Poor client behaviour can  E > result in being blocked by DynDNS (someone has reported to me this  G > happened to them when a local modification to their VMS-based client  I > made it a little too eager to keep DynDNS informed :-)  Various DynDNS  C > update service responses should be parsed and behaviour modified   > appropriately.  And so forth.  >    Thanks very much for this Mark.   H I was previously using the DynDNSUpdater for OS X that I picked up from G the dyndns website. Yuk, it was doing a query every minute. Given that  ; my IP address doesn't change very often, that was overkill.    --  
 Paul Sture   ------------------------------  % Date: Wed, 23 Aug 2006 09:48:40 -0600 4 From: Norman Lastovica <norman.lastovica@oracle.com>& Subject: Re: Datatrieve/CDD protection* Message-ID: <44EC78D8.7DB2CCCC@oracle.com>  F agreed.  you'll probably want give the oracle CDD support team a call.  + Barry.Treahy@EmersonNetworkPower.com wrote:  > 
 > Hi Rich, > A > Knowing which versions might help but if memory serves, CDD was F > dependent on Rdb and this sounds like you have Rdb permission issuesF > with the database, not necessarily external RMS file permissions but4 > perhaps internally with the ACL's on the tables... >  > Barry Treahy, Jr > Vice President/CIO > Midwest Microwave, Inc. . > Emerson Network Power Connectivity Solutions. > E-mail: Barry.Treahy@EmersonNetworkPower.com > Phone: 480/314-1320  > Cell:     480/216-9568 > Fax:     480/661-7028  > 1 >                        ... but it's a DRY HEAT!  > -----Original Message-----/ > From: Rich Jordan [mailto:jordan@ccs4vms.com] ( > Sent: Tuesday, August 22, 2006 4:21 PM > To: Info-VAX@Mvb.Saic.Com $ > Subject: Datatrieve/CDD protection > I > We've never worked with datatrieve, and only very peripherally with CDD G > (at MANMAN sites where CDD was dropped when MANMAN no longer required 2 > it, so our exposure was mostly deinstalling it). > I > Got a site now with issues after a VAX-Alpha move.  Datatrieve runs for C > privileged users, but not for non-priv;d.  The problem is not any = > manner of file level access (tested severely, also full SET H > WATCH/CLASS=ALL runs to verify).  If a non-priv'd user is given BYPASSG > or SYSPRV, Datatrieve starts working for them.  The error seems to be ( > that Datatrieve can't find its schemasI > ("CDD$DEFAULT.MAND.MANDB.DBM$SUBSCHEMAS.DTRMA" not found in dictionary) G > due to a protection issue, I assume within the CDD protection scheme.  > I > We;re using the CDD and DTR dictionaries imported from the VAX.  MANMAN F > schemas in the CDD were built by a MANMAN installation on the Alpha. > G > What seems funny to me (as a non DTR user) is if I run MCR DMU with a E > priv'd account I can SET DEF MM$CDDSCHEMA, list the contents, check @ > protection, etc.  If I do it with a non-priv'd account it saysC > MM$CDDSCHEMA it says directory or object not found.  MM$CDDSCHEMA A > points to MM$DISK:[MANMAN.CDD.SCHEMA], all of which directories F > (currently for testing) have full W:RWE access, all the files in the@ > directory have W:RWE as well as the complex CDD ACLs in place. > G > If I log on as SYSTEM, show protections on MM$CDDSCHEMA (which works) C > then try to set protections for the non-priv'd users UIC, it says E > directory or object not found (tried using both teh logical and the I > pathname); says the same if I try to set protection on one of the items E > that shows up when I issue a list command at that point; I can list ( > them but can't set protection on them. > G > Tomorrow I'm digging old CDs out to see if I can find a DMU reference D > manual.  Found user and install guides for CDD online but not DMU. > I > If anyone has a pointer to troubleshooting info on DTR with CDD, or has 1 > some thoughts or helpful hints I'd be grateful.  >  > Rich > CCS    --  	 - - - - - 0  opinions expressed here are mine and mine alone.  and certainly are not intended in any way to 0  express or represent any opinions or commitment  of oracle corporation.   *  norman lastovica / oracle rdb engineering   ------------------------------   Date: 23 Aug 2006 16:34:30 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)" Subject: Heresy!! Free Sun Stuff!!* Message-ID: <4l3eclF2ukjU3@individual.net>  B I realize that this is major heresy, but I would be willing to betB there is at least one person here who works at a site that has Sun as well as VMS stuff, so......  A Is there anyone here still running a SparcPrinter?  I have, brand B new, still sealed in their boxes, a toner cartridge and a drum forA said printer.  Be nice to keep them out of the landfill till they  have seen some use.      bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 23 Aug 2006 08:24:57 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) ( Subject: KZPBA-CB and PWS 433au problems3 Message-ID: <l1746l69$6Ov@eisner.encompasserve.org>   C Attempting to install a KZPBA-CB in a PWS 433-AU, the console (6.8) A tells me it got an "unexpected interrupt through vector 00000066" ? if I install the board in the second slot from the bottom (with , something similar for the very bottom slot).  B If I install into one of the top three slots, the console is happyC but I get lots of mount verification errors running VMS, presumably 5 due to being on the wrong side of the PCI-PCI bridge.   # Does anybody have any suggestions ?    ------------------------------  % Date: Wed, 23 Aug 2006 09:28:44 -0400 C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com> , Subject: Re: KZPBA-CB and PWS 433au problems6 Message-ID: <nJYGg.3166$T8.862@bignews3.bellsouth.net>   What is it hooked up to?     --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@islandco.com Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:l1746l69$6Ov@eisner.encompasserve.org... E > Attempting to install a KZPBA-CB in a PWS 433-AU, the console (6.8) C > tells me it got an "unexpected interrupt through vector 00000066" A > if I install the board in the second slot from the bottom (with . > something similar for the very bottom slot). > D > If I install into one of the top three slots, the console is happyE > but I get lots of mount verification errors running VMS, presumably 7 > due to being on the wrong side of the PCI-PCI bridge.  > % > Does anybody have any suggestions ?    ------------------------------    Date: 23 Aug 2006 08:44:46 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) , Subject: Re: KZPBA-CB and PWS 433au problems3 Message-ID: <pq0+OPajrqj7@eisner.encompasserve.org>   | In article <nJYGg.3166$T8.862@bignews3.bellsouth.net>, "David Turner, Island Computers US Corp" <dbturner@icusc.com> writes:   > What is it hooked up to?  @ Sometimes a string of Storageworks disks that work with an older? PCI differential adapter as well as a KZTSA (on a non-PCI box).   ? But I got the interrupt message from the console when connected C to nothing - and also, as I recall, when connected to a terminator. B The termination resistors have been removed from the KZPBA itself.  < > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message/ > news:l1746l69$6Ov@eisner.encompasserve.org... F >> Attempting to install a KZPBA-CB in a PWS 433-AU, the console (6.8)D >> tells me it got an "unexpected interrupt through vector 00000066"B >> if I install the board in the second slot from the bottom (with/ >> something similar for the very bottom slot).  >>E >> If I install into one of the top three slots, the console is happy F >> but I get lots of mount verification errors running VMS, presumably8 >> due to being on the wrong side of the PCI-PCI bridge. >>& >> Does anybody have any suggestions ?   ------------------------------  % Date: Wed, 23 Aug 2006 11:01:01 -0400   From: "DBT" <dbturner@icusc.com>, Subject: Re: KZPBA-CB and PWS 433au problems/ Message-ID: <12eorc4ff19v85@news.supernews.com>   E Try updating to Version 7.21 firmware (not F/W disk 7.21) for the PWS 8 It is available  online at the HP firmware download site  K Also - there is a configuration utility on the Firmware CD for the KZPBA-Cx L named  EEROMCFG - you may need to use this and reset it to default settings.  J Apart from that you could have a "buggared" card... does happen especially at this age    DT       --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X251  Fax: 912 201 0402  Email: dbturner@islandco.com Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:pq0+OPajrqj7@eisner.encompasserve.org... G > In article <nJYGg.3166$T8.862@bignews3.bellsouth.net>, "David Turner, 6 Island Computers US Corp" <dbturner@icusc.com> writes: >  > > What is it hooked up to? > B > Sometimes a string of Storageworks disks that work with an olderA > PCI differential adapter as well as a KZTSA (on a non-PCI box).  > A > But I got the interrupt message from the console when connected E > to nothing - and also, as I recall, when connected to a terminator. D > The termination resistors have been removed from the KZPBA itself. > > > > "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message1 > > news:l1746l69$6Ov@eisner.encompasserve.org... H > >> Attempting to install a KZPBA-CB in a PWS 433-AU, the console (6.8)F > >> tells me it got an "unexpected interrupt through vector 00000066"D > >> if I install the board in the second slot from the bottom (with1 > >> something similar for the very bottom slot).  > >>G > >> If I install into one of the top three slots, the console is happy H > >> but I get lots of mount verification errors running VMS, presumably: > >> due to being on the wrong side of the PCI-PCI bridge. > >>( > >> Does anybody have any suggestions ?   ------------------------------    Date: 23 Aug 2006 11:38:33 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) , Subject: Re: KZPBA-CB and PWS 433au problems3 Message-ID: <DUIM9enoUv9E@eisner.encompasserve.org>   R In article <12eorc4ff19v85@news.supernews.com>, "DBT" <dbturner@icusc.com> writes:G > Try updating to Version 7.21 firmware (not F/W disk 7.21) for the PWS : > It is available  online at the HP firmware download site  G I have done that since I wrote the earlier message and it did not help.   M > Also - there is a configuration utility on the Firmware CD for the KZPBA-Cx N > named  EEROMCFG - you may need to use this and reset it to default settings.   Thanks, I did not know that.  L > Apart from that you could have a "buggared" card... does happen especially
 > at this age     How do you know how old I am :-)   ------------------------------  % Date: Wed, 23 Aug 2006 13:44:31 -0400 / From: "William Webb" <william.w.webb@gmail.com> , Subject: Re: KZPBA-CB and PWS 433au problemsI Message-ID: <8660a3a10608231044k4ac11a0at529b91a46c54ec74@mail.gmail.com>   + On 8/23/06, DBT <dbturner@icusc.com> wrote: G > Try updating to Version 7.21 firmware (not F/W disk 7.21) for the PWS : > It is available  online at the HP firmware download site > M > Also - there is a configuration utility on the Firmware CD for the KZPBA-Cx N > named  EEROMCFG - you may need to use this and reset it to default settings. > L > Apart from that you could have a "buggared" card... does happen especially
 > at this age  >  > DT >  >  >  > -- >  > David B Turner > Island Computers US Corp > 2700 Gregory St, Suite 180 > Savannah GA 31404  > Tel: 912 447 6622 X201 > Cell: 912 447 6622 X251  > Fax: 912 201 0402  > Email: dbturner@islandco.com > Web: http://www.islandco.com' > ===================================== > > All orders are subject to the following terms and conditions0 > of sale. These should be read before ordering.' > http://www.islandco.com/warranty.html  >    David-   Is that the diskette with    ISP 1020/1040 NT DD %QB5T8AA AK-R5XUC-CA    on it?  E I think you slap the card in an Intel-based PC and use that diskette.    Cheers,    WWWebb   ------------------------------    Date: 22 Aug 2006 23:39:32 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 4 Subject: Re: No more Oracle Standard Edition for VMS, Message-ID: <fZtCWarbefTd@malvm3.mala.bc.ca>  7 In article <1156309756.359226@bubbleator.drizzle.com>,  1            DA Morgan <damorgan@psoug.org> writes:  > A > I would argue that Standard Edition is not mission critical for ? > you as you can always substitute Enterprise Edition. What may ? > matter is the cost of the license. And here is where you need A > to invite back that lovely sales rep and ask them how hard they @ > can work, between now and license renewal time, to get that EE. > license to match the cost of the SE license.  7     I'm investigating that angle. Perhaps something can ? be worked out but there'd still be the ongoing software support ; costs to be considered, ie what will the cost delta be over  the next 5 or 10 years?   C     The other option is to get a linux box and move the SE licenses D to it. Of course neither of these solutions is as good as convincing" Oracle to keep offering SE on VMS.   ------------------------------    Date: 23 Aug 2006 05:35:56 -0700 From: bob@instantwhip.com 4 Subject: Re: No more Oracle Standard Edition for VMS@ Message-ID: <1156336555.952861.3580@74g2000cwt.googlegroups.com>   Sybrand Bakker wrote:  > A > I wouldn't be surprised is OpenVMS is going to be a desupported ? > platform soon. If you realize how many options are simply not > > available for OpenVMS, and how kludgy Oracle implemented andF > documented OFA, you realize you would better change O/S, if you want > to continue Oracle. B > The number of customers on the planet might number less than 10. >  > --# > Sybrand Bakker, Senior Oracle DBA   D what a lie!  OpenVMS will be around for a LONG LONG time ... that is= straight from the high ups at HP ... better yet, DUMP ORACLE!   E Either they want sales, or they do not ... move to RDB!  It is a much  better DB anyway ...   ------------------------------  % Date: Wed, 23 Aug 2006 09:43:33 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 4 Subject: Re: No more Oracle Standard Edition for VMS9 Message-ID: <orSdnf5iQoNAxHHZnZ2dnUVZ_rydnZ2d@libcom.com>    Malcolm Dunnett wrote:9 > In article <1156309756.359226@bubbleator.drizzle.com>,  3 >            DA Morgan <damorgan@psoug.org> writes: B >> I would argue that Standard Edition is not mission critical for@ >> you as you can always substitute Enterprise Edition. What may@ >> matter is the cost of the license. And here is where you needB >> to invite back that lovely sales rep and ask them how hard theyA >> can work, between now and license renewal time, to get that EE / >> license to match the cost of the SE license.  > 9 >     I'm investigating that angle. Perhaps something can A > be worked out but there'd still be the ongoing software support = > costs to be considered, ie what will the cost delta be over  > the next 5 or 10 years?  > E >     The other option is to get a linux box and move the SE licenses F > to it. Of course neither of these solutions is as good as convincing$ > Oracle to keep offering SE on VMS. >   E Your problem is that you consider yourself locked into using Oracle.  F They know that you can run on Linux, probably cheaper than running on G VMS, and that this will continue to appeal to you and they'll keep you  H as a customer.  They don't give a damn about your desire to continue to G run VMS.  You need a non-Oracle option to possibly get their attention.    --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 23 Aug 2006 09:45:17 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 4 Subject: Re: No more Oracle Standard Edition for VMS9 Message-ID: <orSdnfliQoPZx3HZnZ2dnUVZ_rydnZ2d@libcom.com>    bob@instantwhip.com wrote: > Sybrand Bakker wrote: B >> I wouldn't be surprised is OpenVMS is going to be a desupported@ >> platform soon. If you realize how many options are simply not? >> available for OpenVMS, and how kludgy Oracle implemented and G >> documented OFA, you realize you would better change O/S, if you want  >> to continue Oracle.C >> The number of customers on the planet might number less than 10.  >> >> -- $ >> Sybrand Bakker, Senior Oracle DBA > F > what a lie!  OpenVMS will be around for a LONG LONG time ... that is? > straight from the high ups at HP ... better yet, DUMP ORACLE!  > G > Either they want sales, or they do not ... move to RDB!  It is a much  > better DB anyway ... >   E In what manner is this suggestion 'dumping Oracle'?  The money still   goes into Larry's jet.   --  4 David Froble                       Tel: 724-529-0450> Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc.  170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Wed, 23 Aug 2006 10:30:22 -0700 $ From: DA Morgan <damorgan@psoug.org>4 Subject: Re: No more Oracle Standard Edition for VMS6 Message-ID: <1156354221.669188@bubbleator.drizzle.com>   Malcolm Dunnett wrote:9 > In article <1156309756.359226@bubbleator.drizzle.com>,  3 >            DA Morgan <damorgan@psoug.org> writes: B >> I would argue that Standard Edition is not mission critical for@ >> you as you can always substitute Enterprise Edition. What may@ >> matter is the cost of the license. And here is where you needB >> to invite back that lovely sales rep and ask them how hard theyA >> can work, between now and license renewal time, to get that EE / >> license to match the cost of the SE license.  > 9 >     I'm investigating that angle. Perhaps something can A > be worked out but there'd still be the ongoing software support = > costs to be considered, ie what will the cost delta be over  > the next 5 or 10 years?   B A lot less than changing vendors and, once again, very negotiable.? Invite the sales rep. to save his client from going to the dark  side.   E >     The other option is to get a linux box and move the SE licenses F > to it. Of course neither of these solutions is as good as convincing$ > Oracle to keep offering SE on VMS.  = Personally I'd move to Linux as fast as I could. Consider the < tremendous financial savings for support as well as the fact% that patches will show up far faster.  --   Daniel A. Morgan University of Washington damorgan@x.washington.edu  (replace x with u to respond)  Puget Sound Oracle Users Group
 www.psoug.org    ------------------------------  % Date: Wed, 23 Aug 2006 13:35:14 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 4 Subject: Re: No more Oracle Standard Edition for VMS, Message-ID: <44EC91D1.41927978@teksavvy.com>   DA Morgan wrote:? > Personally I'd move to Linux as fast as I could. Consider the > > tremendous financial savings for support as well as the fact' > that patches will show up far faster.     G If VMS management do not do something to keep Oracle on VMS and in fact G grow its presence on VMS, I think it may in fact signal the true end of " VMS. It will send a strong signal.  G Remember that there is that suppposed 10 billion buck fund to help port F software. If HP isn't going to use any of it to help VMS, then it alsoF sends quite a strong signal about HP's intentions with reagrds to VMS.H With that 10 billion fund, you'd think tyhey would have already givenm a8 big grant to Tom Linden to port PL1 to VMS-IA64 already.   ------------------------------    Date: 23 Aug 2006 10:53:34 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) 4 Subject: Re: No more Oracle Standard Edition for VMS, Message-ID: <EK9QcPFAITef@malvm9.mala.bc.ca>  , In article <44EC91D1.41927978@teksavvy.com>,2    JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   > I > If VMS management do not do something to keep Oracle on VMS and in fact I > grow its presence on VMS, I think it may in fact signal the true end of $ > VMS. It will send a strong signal. >   G    Well Oracle will be keeping Enterprise Edition on VMS ( at least for B the time being ), although as usual the port lags far behind other
 platforms.  I > Remember that there is that suppposed 10 billion buck fund to help port H > software. If HP isn't going to use any of it to help VMS, then it alsoH > sends quite a strong signal about HP's intentions with reagrds to VMS.  B    The fascinating thing is that there is an Oracle 10gR2 StandardC Edition for Tru64 Unix. So an O/S that HP has declared as dead gets 7 a port but an O/S HP says has a future doesn't. Hmmm...    ------------------------------  # Date: Wed, 23 Aug 2006 11:44:16 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) ' Subject: Re: On-chip, 7-way associative [ Message-ID: <rdeininger-2308060744250001@dialup-4.233.173.137.dial1.manchester1.level3.net>   G In article <VYadnSfvDpVOfnbZnZ2dnUVZ_rudnZ2d@metrocastcablevision.com>, ) Bill Todd <billtodd@metrocast.net> wrote:    >Robert Deininger wrote: >  >... > N >>>> We've certainly seen workloads where ES45 beats ES47, and vice versa.  ItK >>>> turns out a lot of real-world work fits in the ES45 cache, but not the  >>>> ES47 cache.C >>> The Wiki post that Dan Foster cited shows a marked drop-off in  L >>> increasing cache effectiveness for SPECint at sizes exceeding 1 MB, and K >>> the same is true for analyzes of TPC-C-style workloads that I've seen.  J >>> So while I don't doubt that *some* real-world applications may be far L >>> better-suited to 16 MB (or better yet 64 MB) of slower, non-associative A >>> off-chip cache, I doubt that this is anything like *typical*.  >>  H >> One obvious case that can enjoy lots of cache is a random mishmash of >> unrelated workloads.  > F >More cache *of the same quality* is always better.  But the question H >here is whether more cache of far less associativity and significantly E >greater latency is better - even for the kind of workload which you  G >specify above, and especially when the smaller-cache product has half   >the RAM latency.  > H >Sometimes, it may be, but on average I suspect not much if at all.  In H >fact, for the 'random mishmash of unrelated workloads' I think I'd opt J >for the far faster RAM and faster, smarter (though smaller) cache almost  >every time. >  >... > K >> I don't know how much the high EV7 associativity contributed to the cost > >> or development time of the CPU.  I doubt it was negligible. > J >Ah, but that doesn't matter at all:  that cost was already incurred (and * >necessary) to support larger EV7 systems.  H I was actually thinking of the per-chip cost, as well as the developmentA cost which you rightly note has already been sunk.  Of course the E development cost of the whole EV68 platform had already been spent as  well.   E Time to market for the various options mattered back when the choices A where made.  EV7 broke enough new ground that it was difficult to E implement and late to market.  At least part of the justification for D doing the ES45/DS25/DS15 family was to have something to offer whileF EV7/Marvel matured.  And to have a second solution just in case Marvel didn't turn out well.     = >The costs one must compare (except for the single-processor  H >configuration which you rightly note below would have required special H >components to support EV7) to determine whether EV7 ES and dual-socket J >DS series systems would have been more cost effective are the *marginal* H >production costs.  True, the EV68 development costs were already sunk, H >but so were the EV7 costs (for the larger configurations that it *had* K >to support), so only the actual production (not development) costs matter.  >  >>   >>  G >>> And fast off-chip SRAM and separate memory-controllers aren't that  J >>> cheap, either.  I question (again) whether overall small-system board M >>> costs would have been any lower using EV68 than EV7:  in fact, I suspect  M >>> the opposite - if the components were priced reflecting HP's cost rather  : >>> than reflecting what HP thought it could get for them. >>  P >> I'm not at liberty to share what I know about the costs in public, obviously. >>  I >> Don't confuse prices, which HP can control, with costs, which HP can't D >> control.  HP (and others) can and has fiddled with prices to pushK >> customers toward the fad of the quarter.  Costs are much less flexible.  H >> Costs of single-source CPU chips, with a custom-designed process, are >> hardly flexible at all. > E >If you're talking actual marginal production costs here rather than  E >including development costs which Alpha had to incur anyway for its  + >large-system support, I'll agree with you.   + Yes, I'm talking marginal production costs.    ...     A >>>   And the cables and connectors that link together EV7 system 8 >>>> boxes are FAR more expensive than the ES45 chipset.L >>> Except that when we're talking about a small-system configuration (as I 6 >>> believe we are here) we don't *need* any of those. >>  K >> Sort of.  At 4 CPUs and above, the interconnects are a significant issue = >> for EV7 systems.  At the 2 CPU level, you mostly avoid it.  > C >My lack of detailed acquaintance with EV7 systems is showing, I'm  F >afraid:  I do now seem to remember that they're composed of multiple I >dual-processor boards, so if you were really referring to board (rather  H >than box) connections above then even the quad-processor configuration 5 >may be affected (but significantly, I have to ask?).   I The Marvel CPU building block is a 2-processor package - a "duo" - with 2 I EV7 chips, power and cooling for them, and the EV7 interconnect path that I lets the 2 CPUs talk to each other.  The stuff that's brought off the duo H includes the memory path for each CPU, the IO path, and a total of 6 EV7 interprocessor links.   F The EV7 links are often labeled North, South, East, and West.  The duoE connects one processor's North to the other processor's South.  East, H South, and West are brought off the duo for one CPU, as are East, North,I and West for the other.  (I'm making up the names for the purpose of this D discussion.  I don't remember which ones are connected and which are brought off the duo.)   F There are two different Marvel system building blocks.  Both use "duo" modules as described above.   H The 2-CPU building block is used for EV47 and ES80, from the 2-CPU towerG to the 8-CPU rack-mount.  Some of the EV7 links are brought outside the G box with big, multi-conductor connectors, and some links are terminated J inside the box.  If my mental snapshot is accurate, 2 links leave the box, but it might be 4.  J The EV47T doesn't use the links, but has to terminate them.  The ES47 rackE system has 2 system boxes and 2 (IIRC) cables for the EV7 links.  The F cables are over an inch thick, with lots of sheilded conductors and an2 outer sheath for strength.  The cables are costly.  I ES80 uses up to 4 system boxes, with more EV7 link cables and terminators  on unused link connectors.  J The 8-CPU building block is used for all flavors of GS1280.  The EV7 linksJ appear on big connectors as before, and are either terminated or connectedJ via cables.  On small configurations, cables are used to implement some ofH the intra-box links.  If the same box is used in a larger configuration,F those same link connection are made between boxes with longer cables. J This architecture is sold up to 64 CPUs (8 system boxes), but was designedH to go up to 128 CPUs (16 system boxes).  Prototypes were assembled up to! at least 80 CPUs that I heard of.     E >> For a 1 CPU EV7 system, you have to implement single-CPU power and G >> packaging to replace the 2-CPU duo used on all existing EV7 systems.  > H >As I noted above, that's a significant point I had overlooked - and an > >excellent argument for having carried over EV68 at least for  >single-socket systems.  >  >... > 0 >   The RAMBUS memory that never quite caught on >> would be expensive. > I >Indeed, which might in itself have been sufficient reason to carry over  C >dual-socket EV68 systems as well (given that the single-socket DS   >systems were already needed). > E >Which leaves only the question of whether carrying over the ES EV68  H >series made sense, I guess - and if stocking both it and the EV7-based H >ES boxes wasn't an unreasonable expense, why not?  But I still suspect J >that the marginal cost to HP of an ES80 may at worst be no more than the F >marginal cost of an ES45 (if I got the numbers right - I'm trying to H >compare the two quad-socket systems), unless the RAMBUS components are F >sufficient to tip the balance or the EV7 process has significant and ( >continuing marginal cost disadvantages.  G EV7 has significant and continuing marginal cost disadvantages for HP.   Especially the top-bin parts.    ------------------------------  # Date: Wed, 23 Aug 2006 11:59:26 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) ' Subject: Re: On-chip, 7-way associative [ Message-ID: <rdeininger-2308060759380001@dialup-4.233.173.137.dial1.manchester1.level3.net>   
 In articleO <rdeininger-2308060029260001@dialup-4.233.128.75.dial1.manchester1.level3.net>, 6 rdeininger@mindspringdot.com (Robert Deininger) wrote:  H >In article <ttKdnbWN5ppb13bZnZ2dnUVZ_oadnZ2d@metrocastcablevision.com>,* >Bill Todd <billtodd@metrocast.net> wrote: >  ...   L >>> GS320-class systems don't use the ES45 chipset, and they have much worse, >>> memory performance at every system size. >>> H >>> GS320-class systems don't use EV68 CPUs, BTW.  They use EV6 or EV67. >> >>Mea culpa.  I Another memory lapse on my part here.  Late-model GS320 systems do indeed I use EV68 as you said.  They are an earlier revision of CPUs than the ones H in ES45.  I remember waiting for ES45 CPUs to be ready, long after GS320H was shipping. The names get confusing suffixes (EV68CB and such) and are< too often "simplified" with corresponding lack of precision.  E Early GS320-class systems either started with even older revisions of H EV68, or EV67.  I don't remember which; a trip to the secret decode ring. would be necessary, and I don't have it handy.   Apologies for the error.  D If I believe the web page, HP is STILL selling GS320-class systems.  That's a surprise.   ...    ------------------------------  % Date: Wed, 23 Aug 2006 04:40:16 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> J Subject: Re: openvms - java - timezone - daylight savings - what the heck!< Message-ID: <44ec1323$0$24194$9a6e19ea@news.newshosting.com>  # <troy@makaro.com> wrote in message  : news:1156305642.810758.8300@i3g2000cwc.googlegroups.com...G > This is really weird, I used your configuration and it worked. Except / > that instead of saying EDT it said GMT-04:00.  > G > I then went and switched back to my time zone and I am off by an hour B > again. My date says GMT-08:00 when it should say PDT or at least > GMT-07:00. > B > About AUTO_DLIGHT_SAV, I had it set to zero before with the same
 > results. >  > Troy > D It seems that the only difference between us is the OS (I'm running H OpenVMS-7.3-2 while you are running OpenVMS-8.2). Can someone out there / running OpenVMS-8.2 try Troy's JAVA experiment?   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  % Date: Wed, 23 Aug 2006 13:40:41 +0100 ) From: Tom Wade <nospam@picard.eurokom.ie> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node 0 Message-ID: <44EC4CC9.1010802@picard.eurokom.ie>  F > Did you notice, that formatting the LKMSG had worked in the previousG > example ? You had issued the SDA> CLUE REGISTER command before and it 7 > had read in all important symbol table files for you.   + I hadn't of course.  A very useful feature.    SDA> exa @r5+cdrp$l_val26 FFFFFFFF.81BBDBD8:  FFFFFFFF.81D2ABA0   ".=AB=D2....."* SDA> format FFFFFFFF.81D2ABA0/type=3Dlkmsg< FFFFFFFF.81D2ABA0   LKMSG$B_FILL_1                        06#                     LKMSG$B_FILL_11 %                     LKMSG$R_DLCK_MSGS '                     LKMSG$R_EXTENSION_2 %                     LKMSG$R_LOCK_MSGS : FFFFFFFF.81D2ABA1                                   0ADF0A< FFFFFFFF.81D2ABA4                                   00000000< FFFFFFFF.81D2ABA8                                   00000402< FFFFFFFF.81D2ABAC   LKMSG$W_RSEQNUM                     00018 FFFFFFFF.81D2ABAE   LKMSG$W_DIRSEQNUM               0184%                     LKMSG$W_PARSEQNUM < FFFFFFFF.81D2ABB0   LKMSG$W_ACTIVITY                    A47B8 FFFFFFFF.81D2ABB2   LKMSG$B_TSLT                      02'                     LKMSG$W_P25_HASHVAL $                     LKMSG$W_PRIORITY6 FFFFFFFF.81D2ABB3                                   4F< FFFFFFFF.81D2ABB4   LKMSG$L_EPIDNEW                 00000000#                     LKMSG$L_MSTLKID $                     LKMSG$L_ORIGEPID< FFFFFFFF.81D2ABB8   LKMSG$L_ORIGLKID                00000000#                     LKMSG$L_PRCLKID < FFFFFFFF.81D2ABBC   LKMSG$L_CSID                    00000000%                     LKMSG$L_NEWMASTER $                     LKMSG$L_ORIGCSID                     LKMSG$R_DEQ %                     LKMSG$R_EXTENSION #                     LKMSG$R_LOCKQED #                     LKMSG$R_NEWLOCK "                     LKMSG$R_RESEND(                     LKMSG$R_RM_RBLD_DONE'                     LKMSG$R_RM_SHUTDOWN $                     LKMSG$W_EXP_DONE!                     LKMSG$W_FLAGS %                     LKMSG$W_LKBSTATUS "                     LKMSG$B_RQMODE%                     LKMSG$W_RSBSTATUS "                     LKMSG$B_GRMODE< FFFFFFFF.81D2ABC0   LKMSG$L_BLKASTFLG               00010002%                     LKMSG$L_REMTSKPID %                     LKMSG$L_VALBLKFLG &                     LKMSG$Q_BITMAP_EXP(                     LKMSG$W_ORIG_RSEQNUM"                     LKMSG$W_STATUS!                     LKMSG$B_STATE *                     LKMSG$W_ORIG_PARSEQNUM'                     LKMSG$W_RSP_RSEQNUM < FFFFFFFF.81D2ABC4   LKMSG$L_PARPRCLKID              00000001"                     LKMSG$Q_VALBLK)                     LKMSG$W_RSP_PARSEQNUM < FFFFFFFF.81D2ABC8   LKMSG$L_PARMSTLKID              00080020#                     LKMSG$L_VCTMPRI < FFFFFFFF.81D2ABCC   LKMSG$L_VCTMLKID                16000000!                     LKMSG$W_GROUP                       LKMSG$B_RMOD"                     LKMSG$B_RSNLEN< FFFFFFFF.81D2ABD0   LKMSG$L_VCTMCSID                42313146"                     LKMSG$T_RESNAM< FFFFFFFF.81D2ABD4   LKMSG$L_EPIDCVT                 59536124$                     LKMSG$L_NEXTLKID%                     LKMSG$L_VALSEQNUM #                     LKMSG$W_RQSEQNM < FFFFFFFF.81D2ABD8   LKMSG$L_DLCKPRI_CVT             53494453%                     LKMSG$L_ORGTSKPID < FFFFFFFF.81D2ABDC                                   2020314B< FFFFFFFF.81D2ABE0                                   56212020< FFFFFFFF.81D2ABE4                                   00000000< FFFFFFFF.81D2ABE8                                   00000000< FFFFFFFF.81D2ABEC                                   00000000< FFFFFFFF.81D2ABF0   LKMSG$L_DLCKPRI_NEW             00000000< FFFFFFFF.81D2ABF4   LKMSG$W_RQSEQALT                    00008 FFFFFFFF.81D2ABF6   LKMSG$W_LSTAT2                  0000< FFFFFFFF.81D2ABF8   LKMSG$Q_VALBLKALT               08014500< FFFFFFFF.81D2ABFC                                   287EFF00< FFFFFFFF.81D2AC00                                   000055DC< FFFFFFFF.81D2AC04                                   000100C9< FFFFFFFF.81D2AC08   LKMSG$L_VALSEQALT               00000000< FFFFFFFF.81D2AC0C   LKMSG$B_LSTATUS                       00: FFFFFFFF.81D2AC0D   LKMSG$B_RSTATUS                     008 FFFFFFFF.81D2AC0E   LKMSG$B_LCKSTATE                  036 FFFFFFFF.81D2AC0F   LKMSG$B_RBLD_STATUS             00< FFFFFFFF.81D2AC10   LKMSG$L_GRNTSRNG                01200022< FFFFFFFF.81D2AC14   LKMSG$L_GRNTERNG                00000000< FFFFFFFF.81D2AC18   LKMSG$L_RQSTSRNG                00000000< FFFFFFFF.81D2AC1C   LKMSG$L_RQSTERNG                00000000< FFFFFFFF.81D2AC20   LKMSG$L_HASHVAL                 4F02A47B(                     LKMSG$W_P25_PRIORITY#                     LKMSG$W_DIRHASH  SDA>   Thanks yet again.   9 --------------------------------------------------------- @ Tom Wade                 | EMail: tee dot wade at eurokom dot ie3 EuroKom                  | Tel:   +353 (1) 296-9696 3 A2, Nutgrove Office Park | Fax:   +353 (1) 296-9697 J Rathfarnham              | Disclaimer:  This is not a disclaimer         =   =20 G Dublin 14                | Tip:   "Friends don't let friends do Unix !"  Ireland    ------------------------------    Date: 23 Aug 2006 07:16:21 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node C Message-ID: <1156342581.843962.275510@i42g2000cwa.googlegroups.com>    Tom,  > > FFFFFFFF.81D2ABA8                                   00000402  G this LKMSG is a LKMSG$K_RMVDIR message. It is supposed to remove a root ? resource directory entry on the local system. There are about 7 E different checks when processing this message, which would cause this C node to crash after sending a fatal lock message to the other node.   G The CDRP for the fatal lock message to be returned to the other node is G pointed to by R5. The field CDRP$L_VAL13 should contain the reason code  for the crash:   SDA> EXA @R5+CDRP$L_VAL13    SDA> FORMAT @R5   E Crashdump analysis via a newsgroup is a lengthy step-by-step process,  but it works...    Volker.    ------------------------------  % Date: Wed, 23 Aug 2006 16:15:13 +0100 ) From: Tom Wade <nospam@picard.eurokom.ie> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node 0 Message-ID: <44EC7101.1060507@picard.eurokom.ie>  I > The CDRP for the fatal lock message to be returned to the other node is I > pointed to by R5. The field CDRP$L_VAL13 should contain the reason code  > for the crash: >  > SDA> EXA @R5+CDRP$L_VAL13    SDA> exa @r5+cdrp$l_val13 2 FFFFFFFF.81BBDC20:  00000000.00000001   "........" SDA>  " Looks suspiciously like SS$_Normal    > SDA> FORMAT @R5  (below)    G > Crashdump analysis via a newsgroup is a lengthy step-by-step process,  > but it works...    And is most impressive !   DA> format @r5< FFFFFFFF.81BBDA50   CDRP$L_IOQFL                    00000000< FFFFFFFF.81BBDA54   CDRP$L_IOQBL                    45546124< FFFFFFFF.81BBDA58   CDRP$W_IRP_SIZE                     00008 FFFFFFFF.81BBDA5A   CDRP$B_IRP_TYPE                   006 FFFFFFFF.81BBDA5B   CDRP$B_RMOD                     00< FFFFFFFF.81BBDA5C   CDRP$L_PID                      00000000< FFFFFFFF.81BBDA60   CDRP$L_ACB64X_OFFSET            00000003< FFFFFFFF.81BBDA64                                   00000000< FFFFFFFF.81BBDA68   CDRP$L_ACB_FLAGS                81859AA0< FFFFFFFF.81BBDA6C   CDRP$L_THREAD_PID               FFFFFFFF< FFFFFFFF.81BBDA70   CDRP$L_KAST                     00000612                     CDRP$L_MIRP                      CDRP$L_WIND < FFFFFFFF.81BBDA74   CDRP$L_UCB                      00000000< FFFFFFFF.81BBDA78   CDRP$L_IIRP_P0                  3EA2DBBC#                     CDRP$L_SHD_IOFL %                     CDRP$PQ_ACB64_AST < FFFFFFFF.81BBDA7C                                   FFFFFFFF< FFFFFFFF.81BBDA80   CDRP$L_HRB                      00000000"                     CDRP$L_IIRP_P1!                     CDRP$L_MV_TMO                      CDRP$L_SHAD '                     CDRP$Q_ACB64_ASTPRM < FFFFFFFF.81BBDA84                                   00000000O FFFFFFFF.81BBDA88   CDRP$Q_USER_THREAD_ID           81159520    XFCLRUDEPOSEVOL  U  ME+000A0< FFFFFFFF.81BBDA8C                                   FFFFFFFF< FFFFFFFF.81BBDA90   CDRP$B_EFN                            C0: FFFFFFFF.81BBDA91   CDRP$B_PRI                          DA8 FFFFFFFF.81BBDA92   CDRP$B_CLN_INDX                   A26 FFFFFFFF.81BBDA93   CDRP$B_WLG_FLAGS                3E< FFFFFFFF.81BBDA94   CDRP$L_CHAN                     FFFFFFFF< FFFFFFFF.81BBDA98   CDRP$L_CLN_WLE                  81859490"                     CDRP$L_IIRP_P2                      CDRP$PQ_IOSB< FFFFFFFF.81BBDA9C                                   FFFFFFFF< FFFFFFFF.81BBDAA0   CDRP$L_STS                      00000000!                     CDRP$Q_STATUS < FFFFFFFF.81BBDAA4   CDRP$L_STS2                     00000000O FFFFFFFF.81BBDAA8   CDRP$PQ_VA_PTE                  81159208    XFCLOCKACQUIREF  A  L+00058 < FFFFFFFF.81BBDAAC                                   FFFFFFFF< FFFFFFFF.81BBDAB0   CDRP$L_SVAPTE                   00000000%                     CDRP$PS_BUFIO_PKT < FFFFFFFF.81BBDAB4   CDRP$L_BCNT                     00000000< FFFFFFFF.81BBDAB8   CDRP$L_BOFF                     00000000< FFFFFFFF.81BBDABC   CDRP$L_OBOFF                    00000000O FFFFFFFF.81BBDAC0   CDRP$L_EXTEND                   811594F8    XFCLRUDEPOSEVOL  U  ME+00078%                     CDRP$L_EXTEND_IRP < FFFFFFFF.81BBDAC4   CDRP$PS_FDT_CONTEXT             FFFFFFFF< FFFFFFFF.81BBDAC8   CDRP$R_DIOBM                    01100000< FFFFFFFF.81BBDACC                                   00000000< FFFFFFFF.81BBDAD0                                   00000000< FFFFFFFF.81BBDAD4                                   00000000< FFFFFFFF.81BBDAD8                                   45450000< FFFFFFFF.81BBDADC                                   00000045< FFFFFFFF.81BBDAE0                                   45450000< FFFFFFFF.81BBDAE4                                   02020445< FFFFFFFF.81BBDAE8                                   0000001C< FFFFFFFF.81BBDAEC                                   00000041< FFFFFFFF.81BBDAF0                                   001E0001< FFFFFFFF.81BBDAF4                                   00000000< FFFFFFFF.81BBDAF8                                   00000000< FFFFFFFF.81BBDAFC                                   00000000< FFFFFFFF.81BBDB00                                   81BA1880O FFFFFFFF.81BBDB04                                   8112E530    XFC$VABANCHOR+0  0  120 < FFFFFFFF.81BBDB08                                   3E080020< FFFFFFFF.81BBDB0C                                   00000000< FFFFFFFF.81BBDB10                                   00000000< FFFFFFFF.81BBDB14                                   00000000< FFFFFFFF.81BBDB18                                   3E03B660< FFFFFFFF.81BBDB1C                                   FFFFFFFF< FFFFFFFF.81BBDB20   CDRP$L_IOST1                    81BB11E0                      CDRP$L_MEDIA#                     CDRP$PS_ABTD_FL < FFFFFFFF.81BBDB24   CDRP$B_CARCON                         28                      CDRP$L_IOST2"                     CDRP$L_TT_TERM#                     CDRP$PS_ABTD_BL : FFFFFFFF.81BBDB25                                   8143C0< FFFFFFFF.81BBDB28   CDRP$L_ABCNT                    3E080020&                     CDRP$PS_SENDABT_FL$                     CDRP$Q_NT_PRVMSK"                     CDRP$Q_STATION#                     CDRP$Q_TT_STATE %                     CDRP$R_SENDABT_LH < FFFFFFFF.81BBDB2C   CDRP$L_OBCNT                    00000000&                     CDRP$PS_SENDABT_BL< FFFFFFFF.81BBDB30   CDRP$L_FUNC                     81BBDB00< FFFFFFFF.81BBDB34   CDRP$L_SEGVBN                   FFFFFFFF< FFFFFFFF.81BBDB38   CDRP$L_DIAGBUF                  00000000< FFFFFFFF.81BBDB3C   CDRP$L_DCD_SRC_UCB              00000000!                     CDRP$L_SEQNUM < FFFFFFFF.81BBDB40   CDRP$L_ARB                      81B7E940< FFFFFFFF.81BBDB44   CDRP$B_CPY_MODE                       30"                     CDRP$L_KEYDESC"                     CDRP$L_WLE_PTR: FFFFFFFF.81BBDB45                                   8112E5< FFFFFFFF.81BBDB48   CDRP$PS_KPB                     3E080020< FFFFFFFF.81BBDB4C   CDRP$PS_CCB                     00000000< FFFFFFFF.81BBDB50   CDRP$L_QIO_P1                   00000000!                     CDRP$Q_QIO_P1 < FFFFFFFF.81BBDB54                                   00000000< FFFFFFFF.81BBDB58   CDRP$L_QIO_P2                   3E5BADA0!                     CDRP$Q_QIO_P2 < FFFFFFFF.81BBDB5C                                   FFFFFFFF< FFFFFFFF.81BBDB60   CDRP$L_QIO_P3                   81BA5820!                     CDRP$Q_QIO_P3 K FFFFFFFF.81BBDB64                                   8143C028    CPUDB+00028 < FFFFFFFF.81BBDB68   CDRP$L_QIO_P4                   3E080020!                     CDRP$Q_QIO_P4 < FFFFFFFF.81BBDB6C                                   00000000< FFFFFFFF.81BBDB70   CDRP$L_QIO_P5                   81BBDB40!                     CDRP$Q_QIO_P5 < FFFFFFFF.81BBDB74                                   FFFFFFFF< FFFFFFFF.81BBDB78   CDRP$L_QIO_P6                   00000000!                     CDRP$Q_QIO_P6 < FFFFFFFF.81BBDB7C                                   00000000< FFFFFFFF.81BBDB80   CDRP$L_FQFL                     00000000< FFFFFFFF.81BBDB84   CDRP$L_FQBL                     81654B20< FFFFFFFF.81BBDB88   CDRP$W_CDRPSIZE                     00B08 FFFFFFFF.81BBDB8A   CDRP$B_CD_TYPE                    396 FFFFFFFF.81BBDB8B   CDRP$B_FLCK                     3AO FFFFFFFF.81BBDB8C   CDRP$L_FPC                      8116A2A0    SEND_FATAL_MSG+  0  0020< FFFFFFFF.81BBDB90   CDRP$Q_FR3                      817F0380< FFFFFFFF.81BBDB94                                   FFFFFFFF< FFFFFFFF.81BBDB98   CDRP$Q_FR4                      81596830< FFFFFFFF.81BBDB9C                                   FFFFFFFF< FFFFFFFF.81BBDBA0   CDRP$L_SAVD_RTN                 00000000< FFFFFFFF.81BBDBA4   CDRP$L_MSG_BUF                  00000000< FFFFFFFF.81BBDBA8   CDRP$L_RSPID                    00000000< FFFFFFFF.81BBDBAC   CDRP$L_CDT                      815A9880< FFFFFFFF.81BBDBB0   CDRP$L_WAIT_STATE               00000000)                     CDRP$Q_RES_WAIT_STATE < FFFFFFFF.81BBDBB4   CDRP$L_SCS_STATE                00000000< FFFFFFFF.81BBDBB8   CDRP$L_SCS_STALL_DATA           00000000< FFFFFFFF.81BBDBBC   CDRP$L_RWCPTR                   00000000< FFFFFFFF.81BBDBC0   CDRP$L_BD_ADDR                  00000000< FFFFFFFF.81BBDBC4   CDRP$L_RBUN                     00000000< FFFFFFFF.81BBDBC8   CDRP$L_LBUFH_AD                 00000000< FFFFFFFF.81BBDBCC                                   00000000!                     CDRP$C_LENGTH   < FFFFFFFF.81BBDBD0   CDRP$L_FILL_VAL                 DEADC0DE                      CDRP$L_LBOFF%                     CDRP$L_SCATP_VAL1                      CDRP$L_VAL1                      CDRP$Q_VAL1 #                     CDRP$T_LBUFHNDL '                     CDRP$T_QSRV_BUFHNDL < FFFFFFFF.81BBDBD4   CDRP$L_RBUFH_AD                 00000000%                     CDRP$L_SCATP_VAL2 < FFFFFFFF.81BBDBD8   CDRP$L_RBOFF                    81D2ABA0%                     CDRP$L_SCATP_VAL3                      CDRP$L_VAL2                      CDRP$Q_VAL2 < FFFFFFFF.81BBDBDC   CDRP$L_QSRV_TYPE                FFFFFFFF%                     CDRP$L_SCATP_VAL4 #                     CDRP$L_UBARSRCE "                     CDRP$L_XCT_LEN< FFFFFFFF.81BBDBE0   CDRP$L_DUTUFLAGS                0ADF0A06#                     CDRP$L_MYSVAPTE %                     CDRP$L_QSRV_FLAGS %                     CDRP$L_SCATP_VAL5                      CDRP$L_VAL3 < FFFFFFFF.81BBDBE4   CDRP$L_MYBCNT                   00000000%                     CDRP$L_QSRV_STATE %                     CDRP$L_SCATP_VAL6                      CDRP$L_VAL4 %                     CDRP$L_VCNXSVAPTE #                     CDRP$W_DUTUCNTR $                     CDRP$W_ENDMSGSIZ< FFFFFFFF.81BBDBE8   CDRP$L_MYBOFF                   00000402                     CDRP$L_PDT%                     CDRP$L_SCATP_VAL7                      CDRP$L_VAL5 #                     CDRP$L_VCNXBCNT (                     CDRP$Q_QSRV_TIMESENT< FFFFFFFF.81BBDBEC   CDRP$L_CNXSVAPTE                01840001%                     CDRP$L_SCATP_VAL8                      CDRP$L_VAL6 $                     CDRP$L_WALK_CDDB7                     CDRP$T_MYBUFHDL                 "." #                     CDRP$W_VCNXBOFF #                     CDRP$B_VCNXRMOD '                     CDRP$B_SCATP_CLTSTS < FFFFFFFF.81BBDBF0   CDRP$L_CNXBCNT                  4F02A47B'                     CDRP$L_SCATP_MSGBLD                      CDRP$L_VAL7 %                     CDRP$L_WALK_ALCLS &                     CDRP$Q_QSRV_SCCOUT< FFFFFFFF.81BBDBF4   CDRP$L_SCATP_SAVEPC             00000000                     CDRP$L_VAL8 $                     CDRP$L_WALK_SVPC"                     CDRP$W_CNXBOFF"                     CDRP$B_CNXRMOD!                     CDRP$B_CLTSTS < FFFFFFFF.81BBDBF8   CDRP$L_LB_CDDB                  00000000'                     CDRP$L_SAVD_MSG_BUF                      CDRP$L_VAL9 %                     CDRP$Q_QSRV_SCCIN *                     CDRP$W_SCATP_SENDSEQNM$                     CDRP$B_VCNXSTATE&                     CDRP$B_SCATP_FLAGS< FFFFFFFF.81BBDBFC   CDRP$L_SAVD_MSG_SIZ             00000000)                     CDRP$L_SCATP_RETRSPID                       CDRP$L_VAL10< FFFFFFFF.81BBDC00   CDRP$L_CDRP_PARTNER             01840001%                     CDRP$L_DUTU_RSVD1                       CDRP$L_VAL11%                     CDRP$PQ_VIRT_ADDR &                     CDRP$PS_QSRV_QSCUB< FFFFFFFF.81BBDC04   CDRP$L_DUTU_RSVD2               00000000                      CDRP$L_VAL12                     CDRP$L_VCRP &                     CDRP$PS_QSRV_QSCSBO FFFFFFFF.81BBDC08   CDRP$L_DUTU_RSVD3               8116A2B0    SEND_FATAL_MSG+  0  0030!                     CDRP$L_MSGBLD #                     CDRP$L_SDA_BCNT                      CDRP$L_TLCB &                     CDRP$PS_QSRV_QSCPBO FFFFFFFF.81BBDC0C   CDRP$L_DUTU_RSVD4               8116A2A0    SEND_FATAL_MSG+  0  0020!                     CDRP$L_RCVREQ !                     CDRP$L_SAVEPC "                     CDRP$L_SDA_PID-                     CDRP$PS_QSRV_COMPLEX_HEAD < FFFFFFFF.81BBDC10   CDRP$L_SAVE_RET                 000000001                     CDRP$PS_QSRV_COMPLEX_NEXT2MAP                      CDRP$Q_PTE$                     CDRP$W_SENDSEQNM#                     CDRP$B_CNXSTATE '                     CDRP$B_CNX_FUNCTION < FFFFFFFF.81BBDC14   CDRP$L_RETRSPID                 00000000#                     CDRP$L_TLCBFQFL &                     CDRP$PS_QSRV_IORTN< FFFFFFFF.81BBDC18   CDRP$L_CPU                      00000000'                     CDRP$L_LCKMGR_FLAGS #                     CDRP$L_TLCBFQBL < FFFFFFFF.81BBDC1C   CDRP$L_DISC_REASON              00000000                      CDRP$W_STATE%                     CDRP$W_BLK_STATUS < FFFFFFFF.81BBDC20   CDRP$L_SAVED_STATUS             00000001                      CDRP$L_VAL13                      CDRP$Q_VAL13< FFFFFFFF.81BBDC24   CDRP$B_VCNX_FUNCTION                  00: FFFFFFFF.81BBDC25                                   000000< FFFFFFFF.81BBDC28   CDRP$L_VAL14                    00000000                      CDRP$Q_VAL14 SDA>  9 --------------------------------------------------------- @ Tom Wade                 | EMail: tee dot wade at eurokom dot ie3 EuroKom                  | Tel:   +353 (1) 296-9696 3 A2, Nutgrove Office Park | Fax:   +353 (1) 296-9697 L Rathfarnham              | Disclaimer:  This is not a disclaimer            G Dublin 14                | Tip:   "Friends don't let friends do Unix !"  Ireland    ------------------------------    Date: 23 Aug 2006 10:39:23 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> ; Subject: Re: SEPPUCLU bugcheck introducing new cluster node B Message-ID: <1156354763.364504.254470@75g2000cwc.googlegroups.com>   Tom,   > SDA> exa @r5+cdrp$l_val13 4 > FFFFFFFF.81BBDC20:  00000000.00000001   "........" > SDA> > $ > Looks suspiciously like SS$_Normal  E No, it's not a system service code, but a sequential error number for 7 the identification of these LOCKMGRERR/SEPPUCLU errors.   E 1 indicates, that the hash did not match. The remote system is trying ? to remove an existing root resource. That resource should exist C locally, but when trying to look up the resource using the resource C name in the received LKMSG$K_RMVDIR lock message and the hash value @ from that message, this resource could not be found in the local resource database.  6 Here are the relevant fields from the received LCKMSG:  E FFFFFFFF.81D2ABCC   LKMSG$B_RSNLEN          16000000  len of resnam =  22. ; FFFFFFFF.81D2ABD0    LKMSG$T_RESNAM         42313146   F11B ; FFFFFFFF.81D2ABD4   LKMSG$L_EPIDCVT          59536124  $aSY 7 FFFFFFFF.81D2ABD8   LKMSG$L_DLCKPRI_CVT  53494453  SDIS D FFFFFFFF.81D2ABDC                                           2020314B K1D FFFFFFFF.81D2ABE0                                           56212020
 FID: 22049D FFFFFFFF.81D2ABE4                                           00000000 ... 5 FFFFFFFF.81D2AC20   LKMSG$L_HASHVAL          4F02A47B   ? Ideally, you would try to find that message in the other node's E SEPPUCLU crash to find out, if the complete message has been received D correctly from the remote node. As you cannot analyze that crash, we have to speculate...  ? Note that the LKMSG$L_HASHVAL field is the LAST longword in the F received message ! If you could find that resource in the local node'sF resource database, but the hash lookup did NOT find it, the hash valueD in the received lock message could have been clobbered while passing through the network.   SDA> SET OUTPUT file SDA> SHOW RESOURCE/BRIEF	 SDA> EXIT  $ SEA file F11B$aSYSDISK1   3 If you find resources with that name, use SDA> SHOW F RES/ADDR=<rsb-address-in-column-1> to find the correct resource - lookE for the '5621' in the File ID field. If you can find that resource in E the local resource db in memory and the hash lookup routine could NOT D find that resource, then the probability is very high, that the last- bytes of the message got clobbered somewhere.   ? Believe it or not, I just had a call from another customer this A afternoon, who had crashed 2 nodes in a cluster by booting a test 9 system system into the cluster after changing the network G infrastructure (adding GBit netword cards and GBit switches). They were : also experiencing LOCKMGRERR/SEPPUCLU pairs of crashes ;-)  5 So yes, it's true: "we engineers will have our fun"       Volker.    ------------------------------   End of INFO-VAX 2006.469 ************************                                                                                                                                                                                                                                  FyH"ޅTJ\sscAAdWt.l
($	.̈2=q0B *KoLUTGhS3	9l:JH\+uFG>>˕3J\OyUQ_1L?zjjH?8XbNjW
Gc՛HF5vYt絺e'`xΫg	X89YĔ͸8걲q
t>lQwb	9aO2
rXh-[\comF'* ./v5	|mlA_vG+& ~@%=Rg
'v6waNUswoPqu?w0A?() 	.$x'lir(̝0RG9r9劣 h7ՍC}yYpd
nRFJDND[Jum@抺CaYC),'gPոp0ALzxUf[q*)_ùzTM&@C2nߒȃlusf[AIL>|uqC*׹fro<L;,ݪ4ZmDVY
9#G is0A袧]Je#7u5طx<L^s{?|+~aSCx|{͖J-G
q-'G:Ϣ'ޖɐ4!@F,,]JK1\
v		R5
Fc]pNaUEJRv]j lGcIHYʥzQogqVc5`МX.1Ec;A9UyŃMXD?co.*Ֆ64 3X@GU~!3Gnǜ)8>ﬢ	REF9)3ԫ3n##Ο0sPe"kqʀJװ];JQcx%f	 aO Ǌe{|_1J"fl(GLG?̱ddM}٠e*	מWtbffd9{_?f>
o)7Dj
ro8ʌ\t9:#mtS5}ȅDnv]Qz6?yQuWp Bx䰒Sc앇ŰB|V2y[t#!0
baN>,ͨ\7W",I,`FMNaMo an{W5lD>ek{e
l}hT?~
9bVl]}/0%R 5$S^-iUoXm6DL-VJirul޿`tҝ\KT¬DD`vKY9O	ph$"~GST o	44}Tn3ʒttՂ N8hm]њ#矩6<˦	/㘑#5eYzZ_Jg1L62NŞg,{kDʆ\\M<mc$oiPP&IvPoádbgHl8"-߂-Zԭ$ь)0PY"%Q2Sʪ7C8)j.HKo08~rvS{.-܀DW?ȉӉH>r3n
c5pIL	<M6Axw%(ix/醹n.YTVL^<8|CjDGC25p3 z־PK%kzn=i%V-*fCO8g1&?\@O0P׶nxN-*Z.flZMƐ"sh\\O'^AcȘexRm%	9	b
R6
uжlQVooD|-R+I24-<kPĽ]pYOcbTOFHp6| )64xǛ/`׫XLC`5vg:@:_Y_R+OZWOy6ƎCڶďOgB-dyQc
HE@h"H+(S|Vb,ክVӓ慫vGG1丼Ռ?3NdY9}&afE1)SZUӳ3Ȅ;'0۳VlƔJ'	uV2\:Z3^PYhVQiJt-v68F~Xt(x?Yzd(-QY=/EA\J?EڞKُ&2t{<hM6p
}}XҵO{-V0B (.)~+٩U4#1;|QJŢk$WטoyWڣ_nΤ҂("K9N<I3Ÿ,˓}JO
==>r{=j]ȷM~~dQ U6 9*lkq2B?i`3LvS"] LSh2-5,ֲ?УtwUc~r'0uj4[.	"ȨG !#06+m/Z
Mth?am31"DN;:a'ډڑO͝6\"+k%p;&$uc=A=M7!j{j=+V(;/}y*s믧Ysy
9gТ	r+ۛ(|S㓌'lj-9R͖wXD)Nڴ_ՖܒB<Q3Џ=|&tFĖa
ݙUTJ{1Nj7YWSvz {6:ÓHz,+tHȚlU3j#_4FUy[Ʌ^h׬\ض˞a9߭VmPɪ3\]F6Ij[T
ƃn?{aBȳOk,JGKX0:ƾ[520S" 㖃%δ)kL	N:=,ټ+c
3A$Fιي{)f4
]T]|H.$*
/f7^vߞaW_EV"TK, E26 ?	[ъ`1}DƇ\š@%{j?cQ[ҧbluTu8~
5|WeU23&9s;F.:XTd~EL%/L