1 INFO-VAX	Sat, 15 May 2004	Volume 2004 : Issue 268       Contents:> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info?????> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info?????> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? Re: DFO and SET FILE/NOMOVE P Re: Future of Availability Manager on IA64 (was Re: Tomcat / Java /  process quoP Re: Future of Availability Manager on IA64 (was Re: Tomcat / Java / process quot Re: Getting Hammered Re: installation boot failure  Re: installation boot failure D Re: Loading/unloading different versions of the same sharable image.@ Loading/unloading different versions of the same sharable image.D Re: Loading/unloading different versions of the same sharable image.D Re: Loading/unloading different versions of the same sharable image.D Re: Loading/unloading different versions of the same sharable image.+ Re: LOGINOUT callouts and network processes  Re: longest uptime Re: longest uptime Re: longest uptime Lotus notes and VMS mail Re: Lotus notes and VMS mail Re: Lotus notes and VMS mail' Re: Parity errors when HSG80 restarted? ) Re: RZ2DD-LS performance specifications ? 
 Re: SPAM, etc 
 Re: SPAM, etc / Re: TCPIP Services V5.4 on OpenVMS/Alpha V7.2-2 < Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"< Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"< Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"( Re: Timestamp format stored in RMS file?( Re: Timestamp format stored in RMS file?8 Re: [General]: Understanding 'Mean Time Between Failure'8 Re: [General]: Understanding 'Mean Time Between Failure'8 Re: [General]: Understanding 'Mean Time Between Failure'8 Re: [General]: Understanding 'Mean Time Between Failure'  F ----------------------------------------------------------------------    Date: 14 May 2004 15:24:01 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? 3 Message-ID: <mGSUaTw$Nu4$@eisner.encompasserve.org>   f In article <c836nu$ckd$1@reader11.wxs.nl>, "Jan van Mastbergen" <jan.van.mastbergen@planet.nl> writes:8 >> Still the 'IBM Tru64' thing is definetly not right...L > Mmm, maybe. Do I remember correctly that Tru64 originated as the love babyM > of a consortium including a.o. DEC and IBM that wanted to produce a unified J > new Unix based on the Mach kernel. It was originally known as OSF-1. Not+ > sure if the rename to Tru64 was DEC only.   .    The rename to Tru64 UNIX was a Compaq move.   ------------------------------  % Date: Fri, 14 May 2004 21:22:51 +0200 9 From: "Jan van Mastbergen" <jan.van.mastbergen@planet.nl> G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? * Message-ID: <c836nu$ckd$1@reader11.wxs.nl>  7 > Still the 'IBM Tru64' thing is definetly not right... J Mmm, maybe. Do I remember correctly that Tru64 originated as the love babyK of a consortium including a.o. DEC and IBM that wanted to produce a unified H new Unix based on the Mach kernel. It was originally known as OSF-1. Not) sure if the rename to Tru64 was DEC only.    Jan  --   jan a.m. van mastbergen   ; "Alex Daniels" <alexdaniels@themail.co.uk> wrote in message 7 news:9f7f13a8.0405140733.30055fcd@posting.google.com... 2 > "Mike Naime" <mnaime@kc.rr.com> wrote in message0 news:<f11pc.407$zn.258@twister.rdc-kc.rr.com>...J > > It's an Emulex rebranded HBA that you purchase from either vendor.  So did I > > they "steal it " from Emulex the original manufacturer?  :-)   What I  reallyI > > get a kick out of is the 1GB GBICS in our old (Brocade rebranded) SAN J > > switches are an IBM product that was repackaged and sold by Compaq.  I bet 5 > > that the tech doc for that would be the same too!  > > : > > Rob Young <young_r@encompasserve.org> wrote in message1 > > news:mUSy5GhVjQuD@eisner.encompasserve.org... ? > > > In article <c81bn5$1o2k$1@news.wplus.net>, "Alex Daniels" 4 > >  <AlexNOSPAMTHANKSDaniels@themail.co.uk> writes:K > > > > Take a look at these two pages, one on digital.com and one ibm.com,  to > >  me  > > > > they look identical!!  > > > > G > > > > Are ibm taking DEC/Compaq/hp documents, and palming them off as  their 
 > >  own?? > > > >  > > > >  > > L http://ftp.digital.com/pub/DEC/Alpha/firmware/readmes/archive/utility/identi
 > > fy.txt > > > >  > > > >  > > L http://www-1.ibm.com/servers/storage/support/disk/64bitpcifibre/fc-hba_paid. > > html > > > >  > > > >  > > > ; > > > No.  IBM was at one time selling compaq storage under D > > > a joint venture/agreement.  The MSS became the rebranded 2106.J > > > What you are pointing to there is technical support docs.  SomethingA > > > that shouldn't disappear just because it is no longer being  > > > sold.  > > > 	 > > > Rob  > > >  > E > I know that the HBA's are rebranded Emulex, just think its slightly B > odd they have the same tech doc's, although maybe your right and* > Emulex just gave them to both companies. > 7 > Still the 'IBM Tru64' thing is definetly not right...  >  > Alex   ------------------------------    Date: 14 May 2004 20:48:57 -0700. From: alexdaniels@themail.co.uk (Alex Daniels)G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? < Message-ID: <9f7f13a8.0405141948.29dbe38@posting.google.com>  v koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote in message news:<mGSUaTw$Nu4$@eisner.encompasserve.org>...h > In article <c836nu$ckd$1@reader11.wxs.nl>, "Jan van Mastbergen" <jan.van.mastbergen@planet.nl> writes:: > >> Still the 'IBM Tru64' thing is definetly not right...N > > Mmm, maybe. Do I remember correctly that Tru64 originated as the love babyO > > of a consortium including a.o. DEC and IBM that wanted to produce a unified L > > new Unix based on the Mach kernel. It was originally known as OSF-1. Not- > > sure if the rename to Tru64 was DEC only.  > 0 >    The rename to Tru64 UNIX was a Compaq move.  A Wasn't its time as 'Digital UNIX' also in between being OSF/1 and B Tru64 ? So really don't know where the 'IBM Tru64' is coming from.   Alex   ------------------------------  # Date: Fri, 14 May 2004 20:29:48 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) $ Subject: Re: DFO and SET FILE/NOMOVE2 Message-ID: <0%9pc.1536$Yr4.1118@news.cpqcorp.net>  B In an earliar posting I said that SETFILENOMOVE.COM is used to put= the appropriate files in the OpenVMS Alpha and I64 kits into  # "SCOPE BOOSTRAP".  This is correct.   J However, I also said or implied that SETFILENOMOVE.COM is NOT run durring E installation or uprgrade.  That is not correct.  SETFILENOMOVE.COM is F run from the execute install procedure AXPVMS$PCSI_EX_INS_PRODUCT.COM.E This works becasue it is run agains the TARGET disk, not the current   system disk (the kit).  C The essence of my point remains correct; it should not normally be  & necessary to re-run SETFILENOMOVE.COM. --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 14 May 2004 18:19:40 -0700/ From: prosullivan@aol.com (prosullivan@aol.com) Y Subject: Re: Future of Availability Manager on IA64 (was Re: Tomcat / Java /  process quo = Message-ID: <a14b767a.0405141719.33afd5ef@posting.google.com>     > >   Performance Data Collector > Where's the analyzer?   > ECP and TDC seperate products. ECP data collector is the 'old'D ECP_POLL collector, TDC ('The data collector') seems to be somethingD similar, yet different. Hmm, totally off the subject, a) has any oneE bought a copy of TDC, and has anyone read the data into PSPA Analyzer D for analysis? Whch may or may not work. Not that I could say one way or the other...    ------------------------------  % Date: Fri, 14 May 2004 21:56:06 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>Y Subject: Re: Future of Availability Manager on IA64 (was Re: Tomcat / Java / process quot 6 Message-ID: <40A586C6.AEBCC779@NeOaSrPtAhMlNiOnWk.net>   Barry Kierstein wrote: > N > Just a note:  I believe the Performance Data Collector is also known as TDC.M > It is the user-mode data collection utility to collect all sorts of things. > > The analyzer is intended to either be 3rd party or your own.   Attn: Mike Austin - biz opp    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 14 May 2004 21:39:53 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: Getting Hammered * Message-ID: <2gklk9F3vhnhU1@uni-berlin.de>   Michael Austin wrote: L > hmm. I just downloaded the FULL PDF presentation in < 30 seconds.. I am on9 > ADSL 256up/1.5down with a router and a WAP in between..  > + Yep, I'm told that it's working fast again.    ------------------------------  % Date: Fri, 14 May 2004 20:07:17 +0200 , From: "Hans Vlems" <hvlems.dotweg@zonnet.nl>& Subject: Re: installation boot failure* Message-ID: <2gkgavF3vc5nU1@uni-berlin.de>  ) "o-o-o" <bkt@null.net> schreef in bericht 6 news:DJzoc.8222$Fu7.6643@newssvr24.news.prodigy.com...F > I have a Digital Server 5000 (same as AlphaServer 1200) on which I'm trying! > to install VMS. I checked here: 5 > http://h71000.www7.hp.com/openvms/supportchart.html J > to see what version of VMS the system will run, and concluded that 7.3-1B > should work. I checked my firmware, and I believe it is current: >  > I > I am at a loss for what else to check. Any ideas of where to look next?  >  > " check http://home.zonnet.nl/hvlems  G Please note that I fully agree with Hoff's formal statement. A whitebox  alpha was designed and0 built for WindowsNT. There's no support for VMS.I Now that's out of the way: this is exactly why Alpha based Digital Server  3000, 5000 and 7000 H systems are cheap. With little ease these systems will run VMS without a problem.   Hans  3 (happily running Alpha/VMS on a 5305 and a 3300 :-)    ------------------------------  % Date: Fri, 14 May 2004 22:05:45 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>& Subject: Re: installation boot failure6 Message-ID: <40A58909.C387C57E@NeOaSrPtAhMlNiOnWk.net>   o-o-o wrote: > K > Thanks for the help. This box was indeed running NT4.0 SP6 when I got it. M > But I blew it away, switched the console to serial, switched the os type to $ > VMS, and thought I'd give it a go.N > the next question is, does anyone want an alpha that can't run VMS? I don't.2 > It has some nice parts that could be salvaged...  & Other posters have some ideas for VMS.    Have you considered Alpha Linux?   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 14 May 2004 15:22:58 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) M Subject: Re: Loading/unloading different versions of the same sharable image. 3 Message-ID: <hryDikZlIDiy@eisner.encompasserve.org>   c In article <7df8ebf7.0405141035.477472c2@posting.google.com>, int_80h@hotmail.com (int_80h) writes:  > Hello,A > I would like to be able to load a sharable image, implicitly or E > explicitly, and be able to load the same sharable image but a newer  > version during runtime.  > 
 > Main image: 
 > main.exe >  > Sharable images:
 > image.exe;1 
 > image.exe;2  >  > 1) Main loads image.exe;1.@ > 2) Somehow main.exe knows there is a new version of image.exe. > 3) It loads image.exe;2  > E > All of the docs/postings that I have found on this subject say that H > there is no way to "unload" a shared image except to restart main.exe.	 >  But...  > F > 1) Is there a way to load image.exe;2 without unloading image.exe;1?? > 2) Is there a VMS utility that would allow me to "signal" the < > application to load a newer version?  Maybe something like% > LIBRARY/REPLACE/SHARED image.exe;2. B > 3) Is there an undocumented way to manipulate the shared libraryD > database in memory that would allow me to replace image.exe;1 with > image.exe;2? > 5 > Thank you for taking the time to read this posting.  > int   H    You may be able to get what you want by using lib$lookup_image_symbol8    instead of linking to the shareable image explicitly.  A    Alternately, it is possible to link an image /system (no image E    header), map that with $crmpsc when you need it, and jump into it, 7    then unmap it when it returns.  This is non-trivial.    ------------------------------    Date: 14 May 2004 11:35:52 -0700# From: int_80h@hotmail.com (int_80h) I Subject: Loading/unloading different versions of the same sharable image. = Message-ID: <7df8ebf7.0405141035.477472c2@posting.google.com>    Hello,? I would like to be able to load a sharable image, implicitly or C explicitly, and be able to load the same sharable image but a newer  version during runtime.    Main image:  main.exe   Sharable images: image.exe;1  image.exe;2    1) Main loads image.exe;1.> 2) Somehow main.exe knows there is a new version of image.exe. 3) It loads image.exe;2   C All of the docs/postings that I have found on this subject say that F there is no way to "unload" a shared image except to restart main.exe.  But...   D 1) Is there a way to load image.exe;2 without unloading image.exe;1?= 2) Is there a VMS utility that would allow me to "signal" the : application to load a newer version?  Maybe something like# LIBRARY/REPLACE/SHARED image.exe;2. @ 3) Is there an undocumented way to manipulate the shared libraryB database in memory that would allow me to replace image.exe;1 with image.exe;2?  3 Thank you for taking the time to read this posting.  int    ------------------------------  # Date: Fri, 14 May 2004 19:15:55 GMT # From: hoff@hp.nospam (Hoff Hoffman) M Subject: Re: Loading/unloading different versions of the same sharable image. 1 Message-ID: <LV8pc.1529$Ym4.181@news.cpqcorp.net>   c In article <7df8ebf7.0405141035.477472c2@posting.google.com>, int_80h@hotmail.com (int_80h) writes:   @ :I would like to be able to load a sharable image, implicitly orD :explicitly, and be able to load the same sharable image but a newer :version during runtime.  6   lib$find_image_symbol would be the obvious approach.  :   Recent versions of OpenVMS have the C dlopen stuff, too.  F   For full code examples, see Ask The Wizard (ATW) topics (2486), etc.  E   For the shareable image cookbook, please see the left navigation at F   the ATW web page.  The cookbook has a discussion of shareable images/   and related topics, including modular design.   D :All of the docs/postings that I have found on this subject say thatG :there is no way to "unload" a shared image except to restart main.exe.   
   Correct.  E :1) Is there a way to load image.exe;2 without unloading image.exe;1?   E   Yep.  The "fun" here involves the increasing use of virtual memory. C   By repeatedly activating new images, you'll have implemented what %   is effectively virtual memory leak.   E   You could also connect to a server process that is either activated D   dynamically (or maintain a pool of same, restarting the servers asE   a new shareable image is released), and this can obviously load the F   new shareable image.  This is the closest to what you want, and also@   provides the ability to load balance across a cluster, rollingE   upgrades, graceful (and transparent) response to hardware failures, A   and (if coded right) transparent roll-in-a-box system upgrades.   C   A web server CGI process is logically a variation of this scheme.   > :2) Is there a VMS utility that would allow me to "signal" the; :application to load a newer version?  Maybe something like $ :LIBRARY/REPLACE/SHARED image.exe;2.  D   Standard inter-process communications.  Mailboxes, lock managementF   doorbells, DMR synch links, IP sockets, raw Ethernet datagrams, etc.  A :3) Is there an undocumented way to manipulate the shared library C :database in memory that would allow me to replace image.exe;1 with 
 :image.exe;2?   D   The shared library is a link-time construct, BTW.  It is not used,C   referenced or even particularly relevent to image activation nor     to run-time activities.   ,   As for the question: {Snicker} have fun.  G   But seriously, if it were easy and supportable, we'd already have it.     N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  % Date: Fri, 14 May 2004 22:33:09 +0200 3 From: Michael Unger <spam.to.unger@spamgourmet.com> M Subject: Re: Loading/unloading different versions of the same sharable image. * Message-ID: <2gkoufF41vouU1@uni-berlin.de>  * On 2004-05-14 21:15, "Hoff Hoffman" wrote:   > [...]  > . >   As for the question: {Snicker} have fun.  I >   But seriously, if it were easy and supportable, we'd already have it.   @ Quoting from the Microware OS-9 for 68K Product Specification atJ <http://www.radisys.com/oem_products/ds-page.cfm?productdatasheetsid=1124>   | PRODUCT FEATURES | 
 | OS-9 Kernel  | A | The OS-9 kernel provides a secure, process-based, multi-tasking I | environment for embedded systems. OS-9’s use of position-independent, J | reentrant code modules allows the kernel to dynamically load application>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^C | and/or system modules at run-time. This capability enables system #                         ^^^^^^^^^^^ G | designers to add or update software modules across the network during  | development or in the field.  5 Of course I don't know *how* this is accomplished ...    Michael    --  ; Real names enhance the probability of getting real answers. 5 My e-mail account at DECUS Munich is no longer valid.    ------------------------------    Date: 14 May 2004 18:12:53 -0700# From: int_80h@hotmail.com (int_80h) M Subject: Re: Loading/unloading different versions of the same sharable image. = Message-ID: <7df8ebf7.0405141712.21871b01@posting.google.com>   \ hoff@hp.nospam (Hoff Hoffman) wrote in message news:<LV8pc.1529$Ym4.181@news.cpqcorp.net>...e > In article <7df8ebf7.0405141035.477472c2@posting.google.com>, int_80h@hotmail.com (int_80h) writes:  > B > :I would like to be able to load a sharable image, implicitly orF > :explicitly, and be able to load the same sharable image but a newer > :version during runtime. > 8 >   lib$find_image_symbol would be the obvious approach. > < >   Recent versions of OpenVMS have the C dlopen stuff, too. > H >   For full code examples, see Ask The Wizard (ATW) topics (2486), etc. > G >   For the shareable image cookbook, please see the left navigation at H >   the ATW web page.  The cookbook has a discussion of shareable images1 >   and related topics, including modular design.   E I have some sample code running now using the techniques mentioned in < the above reference, and some of the postings to this group.  F > :All of the docs/postings that I have found on this subject say thatI > :there is no way to "unload" a shared image except to restart main.exe.  >  >   Correct. > G > :1) Is there a way to load image.exe;2 without unloading image.exe;1?  > G >   Yep.  The "fun" here involves the increasing use of virtual memory. E >   By repeatedly activating new images, you'll have implemented what ' >   is effectively virtual memory leak.  > G >   You could also connect to a server process that is either activated F >   dynamically (or maintain a pool of same, restarting the servers asG >   a new shareable image is released), and this can obviously load the H >   new shareable image.  This is the closest to what you want, and alsoB >   provides the ability to load balance across a cluster, rollingG >   upgrades, graceful (and transparent) response to hardware failures, C >   and (if coded right) transparent roll-in-a-box system upgrades.  > E >   A web server CGI process is logically a variation of this scheme.   F I thought that I should be able to, but I cannot get it to work in theC code.  I must be doing something wrong. I don't have the code right ' here in front of me but I'll psuedo it.   
 In MY_EXE:% MYPRINT.EXE;1 // prints "1.0 version" % MYPRINT.EXE;2 // prints "2.0 version"    descriptor(name, "MYPRINT"); descriptor(path, "MY_EXE:.EXE")  void (*pf)(char*);( lib$find_image_symbol(&name, &path, pf); (*pf)("Hello from so!");1 <repeat once more for other shared image version>   C This only prints the latest version of the image.  I tried changing C the "path" to MY_EXE:.EXE;0 and MY_EXE:.EXE;-1 but it seems like it C trys to match the "name" only, in this case "MYPRINT", and does not > look at the "path" to see if it is a different sharable image.  @ > :2) Is there a VMS utility that would allow me to "signal" the= > :application to load a newer version?  Maybe something like & > :LIBRARY/REPLACE/SHARED image.exe;2. > F >   Standard inter-process communications.  Mailboxes, lock managementH >   doorbells, DMR synch links, IP sockets, raw Ethernet datagrams, etc.  F Here, I meant an OS utility that would essentially do what I am trying" to do...only without the headache.  C > :3) Is there an undocumented way to manipulate the shared library E > :database in memory that would allow me to replace image.exe;1 with  > :image.exe;2?  > F >   The shared library is a link-time construct, BTW.  It is not used,E >   referenced or even particularly relevent to image activation nor   >   to run-time activities.  > . >   As for the question: {Snicker} have fun.  I >   But seriously, if it were easy and supportable, we'd already have it.   C True. I thought I might be overlooking it.  Sometimes it is hard to A know what to ask for when you don't know what you're looking for.     > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq P >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------    Date: 14 May 2004 13:14:54 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 4 Subject: Re: LOGINOUT callouts and network processes3 Message-ID: <wxnZ4O0L3$1n@eisner.encompasserve.org>   ] In article <k35pc.111803$WA4.35728@twister.nyc.rr.com>, Jonas Lindholm <jlhm@usa.net> writes:   	 > Thanks!  > ? > but the callout for authentication is always invoked even if  B > NET_CALLOUTS is 0 making it possible for the callout routine to J > terminate the login. It would be great if the password always was passedI > to the LOGINOUT image. Any reason why NET$ACP remove the password from  ? > the access control string when invoking the LOGINOUT.EXE and   > NET_CALLOUTS is zero ?  E LGI callouts are an extension of LOGINOUT, and LOGINOUT does not need 9 the password in cases where DECnet has pre-authenticated.   E Shortcomings in the LGI-callout capabilities are supposed to be fixed A on Alpha with the ACME capabilities now available for VMS V7.3-2.    ------------------------------  % Date: Fri, 14 May 2004 21:59:22 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: longest uptime 6 Message-ID: <40A5878A.28D91C92@NeOaSrPtAhMlNiOnWk.net>   Bob Koehler wrote: > d > In article <c802s8$4a3$1@pcls4.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes: > > 1 > > How do you keep Windows up for a whole month?  > ! >    Put a nail through the sash.    ...or cut ya a hunk o' 2-by-4.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Fri, 14 May 2004 22:02:43 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> Subject: Re: longest uptime 6 Message-ID: <40A58852.A43E9B08@NeOaSrPtAhMlNiOnWk.net>   david20@alpha2.mdx.ac.uk wrote:  > { > In article <40A420FA.B799A859@NeOaSrPtAhMlNiOnWk.net>, "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> writes:  > >Syltrem wrote:  > >>L > >> > Well, I have a cluster that was established well over a year ago, butO > >> > the longest uptime for any member is currently just over 30 days, due to ) > >> > monthly reboots, patches and such.  > >> >	 > >> > --  > >> > David J. Dachtera > >> > dba DJE Systems > >> > http://www.djesys.com/  > >> > >> What is a monthly reboot?( > >> This is a VMS forum, not windows... > >> ;-) > > D > >Yeah, well, even in the VMS world, pesky app.'s can have resource > >leaks...  > > 	 > >*SIGH*  > K > Usually when I've come across this monthly reboot phenonemon on VMS it is P > because it has been recommnded by the Vendor and the Vendor has recommended itP > because at some point they had a memory leak problem with the application on aN > Unix platform. The leak on the Unix platform may itself have been fixed agesL > ago but the advice to reboot has become set in stone and is applied to all" > systems the application runs on.  D In our case, unfortunately, it's known problem, and we can predict -9 within about 36 hours - roughly when we'll be in trouble.   A Stopping and restaring the suspect processes delays, but does not  prevent the problem.   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 15 May 2004 03:02:31 GMT From: healyzh@aracnet.com  Subject: Re: longest uptime , Message-ID: <c84187224j5@enews3.newsguy.com>  ? David J. Dachtera <djesys.nospam@neoasrptahmlnionwk.net> wrote: 3 > > > How do you keep Windows up for a whole month?  > > # > >    Put a nail through the sash.     > ...or cut ya a hunk o' 2-by-4.  K Doesn't having access to a hunk of 2-by-4 typically result in Windows being  down?    	Zane    ------------------------------  % Date: Fri, 14 May 2004 21:15:33 +0100 ' From: Tony <tony.wrightwrong@zen.co.uk> ! Subject: Lotus notes and VMS mail 5 Message-ID: <40a528e5$0$4591$db0fefd9@news.zen.co.uk>   G I have a FORTRAN utility which mails system status. The spec says that  H the FROM field should indicate which machine the mail is from, so I use I SEND_ADD_ATTRIBUTE with the SEND_FROM_LINE input code to set the machine  H name. This works as expected when read on a VMS machine, however when I H send the mail to Lotus notes via SMTP it shows  FROM as the account the  mail originated from.   J Is this a Lotus Notes problem, VMS mail problem or me not doing something?   --     Tony Wright    ------------------------------  # Date: Fri, 14 May 2004 22:03:08 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")% Subject: Re: Lotus notes and VMS mail 6 Message-ID: <00A31D4D.0798F5C4@SSRL.SLAC.STANFORD.EDU>  _ In article <40a528e5$0$4591$db0fefd9@news.zen.co.uk>, Tony <tony.wrightwrong@zen.co.uk> writes: H >I have a FORTRAN utility which mails system status. The spec says that I >the FROM field should indicate which machine the mail is from, so I use  J >SEND_ADD_ATTRIBUTE with the SEND_FROM_LINE input code to set the machine I >name. This works as expected when read on a VMS machine, however when I  I >send the mail to Lotus notes via SMTP it shows  FROM as the account the   >mail originated from. > K >Is this a Lotus Notes problem, VMS mail problem or me not doing something?    Yes, yes, and yes.  J I don't use Lotus Notes and I don't know what header it chooses to displayI as "From."  But different mail clients will gratuitously choose different B things; some use From:, some use Reply-To:, some may use X-Sender.  L Lotus Notes isn't using whatever header gets set to show from (and probably ) won't if all that gets set is X-VMS-From:   K It's a VMS mail problem in that VMS mail proper doesn't know anything about H SMTP mail, relying on mail transports to do all that stuff.  So callableK mail doesn't let you tweak the appropriate header.  (Incidentally, it would L be helpful here to know what TCP/IP package and mail transport you're using;H they may use different rules to translate VMS "From:" into SMTP headers.    J It's something you're not doing in that you're not setting whatever headerG it is that Notes wants to use.  Whether you _can_ set it using callable F mail is another question; you may need to use some other means to send mail for SMTP clients.   -- Alan    --  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------    Date: 14 May 2004 20:41:50 -0700. From: alexdaniels@themail.co.uk (Alex Daniels)% Subject: Re: Lotus notes and VMS mail = Message-ID: <9f7f13a8.0405141941.3d12a36c@posting.google.com>    winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote in message news:<00A31D4D.0798F5C4@SSRL.SLAC.STANFORD.EDU>...a > In article <40a528e5$0$4591$db0fefd9@news.zen.co.uk>, Tony <tony.wrightwrong@zen.co.uk> writes: J > >I have a FORTRAN utility which mails system status. The spec says that K > >the FROM field should indicate which machine the mail is from, so I use  L > >SEND_ADD_ATTRIBUTE with the SEND_FROM_LINE input code to set the machine K > >name. This works as expected when read on a VMS machine, however when I  K > >send the mail to Lotus notes via SMTP it shows  FROM as the account the   > >mail originated from. > > M > >Is this a Lotus Notes problem, VMS mail problem or me not doing something?  >  > Yes, yes, and yes. > L > I don't use Lotus Notes and I don't know what header it chooses to displayK > as "From."  But different mail clients will gratuitously choose different D > things; some use From:, some use Reply-To:, some may use X-Sender. > N > Lotus Notes isn't using whatever header gets set to show from (and probably + > won't if all that gets set is X-VMS-From:  > M > It's a VMS mail problem in that VMS mail proper doesn't know anything about J > SMTP mail, relying on mail transports to do all that stuff.  So callableM > mail doesn't let you tweak the appropriate header.  (Incidentally, it would N > be helpful here to know what TCP/IP package and mail transport you're using;J > they may use different rules to translate VMS "From:" into SMTP headers. >  > L > It's something you're not doing in that you're not setting whatever headerI > it is that Notes wants to use.  Whether you _can_ set it using callable H > mail is another question; you may need to use some other means to send > mail for SMTP clients. > 	 > -- Alan    (LNM$PROCESS_TABLE)   ;   "TCPIP$SMTP_FROM" = "AlexNopeToSpamDaniels@themail.co.uk"   D If your using TCP/IP Services, the above may be worth a try, you can/ obviously set the logical to whatever you like.   - Works for me anyway when sending to exchange.      Alex   ------------------------------  # Date: Fri, 14 May 2004 20:03:12 GMT < From: "John E. Malmberg" <Malmberg@dskwld.zko.dec.compaq.hp>0 Subject: Re: Parity errors when HSG80 restarted?2 Message-ID: <4C9pc.1533$Hq4.1400@news.cpqcorp.net>   Malcolm Dunnett wrote: > O >    Actually the mirrorsets seem fine. I can still access the disks and Oracle N > restarted with no complaints ( Oracle dies a horrible death if it can't readH > a controlfile ), so this appears to be a transient problem. I have theM > VMS 7.3-2 FIBRE_SCSI V2.0 patch installed, which I believe may be a problem K > (it's the 7.3-2 analogue of the 7.3-1 FIBRE_SCSI V5.0 patch referenced in  > an earlier post )    Sorry for the inconvenience.  G The parity error problem has been traced to the VMS 7.3-2 Fibre_SCSI V  * 1.0 kit which is included in the V2.0 kit.  F The driver was incorrectly translating some retry conditions in to be G reported as parity errors for Fibre Channel disks.  Typically it would  + take a heavy load to trigger the condition.   C The fix is in the V3.0 kit which should have just come off of hold.   I Falling back to the VMS 7.3-2 SYS$DKDRIVER.EXE image should also work to    remove the parity error problem.   -John2! malmberg@dskwld.zko.dec.compaq.hpC Personal Opinion Only-   ------------------------------  % Date: Fri, 14 May 2004 20:21:37 +0200 , From: "Hans Vlems" <hvlems.dotweg@zonnet.nl>2 Subject: Re: RZ2DD-LS performance specifications ?* Message-ID: <2gkh5rF3r3raU1@uni-berlin.de>  I "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> schreef inu5 bericht news:k2W$ecBUu36s@eisner.encompasserve.org...J9 > In article <2gfa58F28o87U1@uni-berlin.de>, "Hans Vlems"b! <hvlems.dotweg@zonnet.nl> writes:  > >r7 > > Apparently the DEC RZ2DD-LS is a Seagate ST39102LC.sG > > Ref.: http://www.seagate.com/support/disc/specs/scsi/st39102lc.html  > >. >e> > Thank you. I didn't realise that it was a re-badged Seagate. >  > Simon. >nL All the disks in the bricks are third party drives. I've got 15 of these and most of them areI Seagate drives, three IBMs and two Quantum drives. Then again 15 disks is  not ag" representative subset of course...   ------------------------------  # Date: Sat, 15 May 2004 00:47:43 GMTe4 From: "Roert G. Schaffrath" <rschaffrath@yahoo.com> Subject: Re: SPAM, etc% Message-ID: <40A568BF.6621@yahoo.com>    Andrew Robert wrote: > G > If you need a nice application to get rid of spam, I highly recommend:@ > the Spambayes open source Outlook plugin found on Sourceforge. > = > The Sourceforge link is http://spambayes.sourceforge.net/ .s > E > I've been using it for some time with extremely impressive results.i >  > Chuck Chopp wrote: > > Tom Linden wrote:: > >r= > >> In my never ending efforts to get rid of spam and virii,i? > >> I come across a lot I don't follow.  I am running MX5.3 onn< > >> 7.3-1 and I use Outlook as a pop client.  What shows up. > >> on the subject line appears intelligible, > >>@ > >> Stuart, You can delegate authority, but not responsibility. > >>= > >> Now, I am not stupid enough to open this type of mail in : > >> other than VMS mail, and looking at the 822 header it@ > >> appears as gibbersih.  Is this perhaps a character encoding > >> that Outlook understandsr > >>L > >> Here is the header and then there is a .gif attachment, likely a virus.B > >> are =?  ?= delimiters that can be used to effectively filter? > >>< > >> From:   SMTP%"dugzzfeabrrzwy@attbi.com"  "Clint Jepson"" > >> To:     SMTP%"tom@kednos.com" > >> CC:
 > >> Subj:M > >> =?utf-8?B?U3R1YXJ0LCBZb3UgY2FuIGRlbGVnYXRlIGF1dGhvcml0eSwgYnV0IG5vdCByZX  > >> Nwb25zaWJpbGl0eS4=?=e > >t > >6L > > It tells you what you need to know, I think, when you see the "utf-8" atK > > the start of the subject.  I'm not 100% certain about the "=?" and "?="vI > > as delimiters, although they appear to function as such.  I'd have togK > > review teh SMTP related RFCs to know for certain.  However, the "utf-8"rF > > reference indicates that the subject line text is encoded in UTF-8; > > characters rather than plain old ANSI/ASCII characters.t > >v > >y  A If you run a server and can run procmail, SpamProbe which is also E Bayesian based is available at http://spamprobe.sourceforge.net/ .  I E use it on the server and with a little training, it does an excellenta job.   ------------------------------  % Date: Sat, 15 May 2004 12:40:34 +1000s  From: HUMBUG <humbug@bit.bucket> Subject: Re: SPAM, etc, Message-ID: <2icgn1-5pd.ln1@deep.bit.bucket>  O On Fri, 14 May 2004 10:31:47 -0400, Andrew Robert <arobert@townisp.com> Wrote :bH > If you need a nice application to get rid of spam, I highly recommend @ > the Spambayes open source Outlook plugin found on Sourceforge. > = > The Sourceforge link is http://spambayes.sourceforge.net/ .a > E > I've been using it for some time with extremely impressive results.   C I hate "me too" posts but this is one. SpamBayes is by far and away > the best spam filter that I've tried and I've tried _heaps_ of spam filtering packages.     -- c   Humbug   ------------------------------  # Date: Fri, 14 May 2004 17:56:34 GMT 1 From: Michael Austin <maustin@firstdbasource.com>e8 Subject: Re: TCPIP Services V5.4 on OpenVMS/Alpha V7.2-22 Message-ID: <40A508BD.F07AE540@firstdbasource.com>  I there are a lot of performance enhancements when used in conjunction withnO 7.3-2.  Some of the new functionality is there (see release notes for details),d@ but most of the performance enhancements only work with 7.3-2...   Michael Austin   Mark Iline wrote:t  9 > From: Jonathan Boswell [mailto:jsb.NOSP@M.cdrh.fda.gov]/ >hN > > Has anybody tried this unsupported configuration?  I am trying to cut down > on spam (again). >n' > 'Fraid  can't answer your question...h >SK > However, as I'm running v5.3 on that version of VMS I'm interested in theaI > answer. I'm also curious what particular advantages 5.4 gives over 5.3.i >o > Mark >n > Mark Iline, UCL Mech ENg   ------------------------------  % Date: Fri, 14 May 2004 20:19:10 +0200i, From: "Hans Vlems" <hvlems.dotweg@zonnet.nl>E Subject: Re: Terry Shannon's "HP: Two Years Post-Merger Presentation" * Message-ID: <2gkh18F3qf7rU1@uni-berlin.de>  9 "Paul Sture" <nospam@sture.homeip.net> schreef in bericht-$ news:2gic3qF3aefqU1@uni-berlin.de... > Paul Sture wrote:xL > > As reported by The Inquirer at http://www.theinquirer.net/?article=15879: > > Terry Shannon's has a presentation up in PDF format at > >8E > > http://www.shannonknowshpc.com/stories.php?story=04/05/12/7726404  > >KK > > Terry claims "It took me 150 hours out of a 168-hour week to render thenK > > slideware reasonably consistent with HP standards; you can download therI > > results in just a few minutes.", but I must assume that his server isiJ > > either getting hammered or is somewhat sick, as it felt like 150 hours > > to download it.c > >tI > > The PDF pages containing graphics took ages to render too, so to savenB > > others the frustration I've knocked up some quick web pages at > >u2 > > http://www.sture.homeip.net/itanium/index.html > >n > J > Well, aargh here. I have inspected my web logs, and I see that many haveG > looked at the thumbnails, but not the full-screen shots. Apologies ifr  > anyone was disappointed there. >-. > Sorry to all I didn't explain how it worked. >2I > Click on the first thumbnail and you get a full screenshot of the first:I > slide, click the Next link for the rest until it gets to slide 30, then.! > UP, Page 2 and follow the rest.d >a- > Simple, but then I assumed... Blegh...Sigh.i > ...eI > However, I can report that Apache on Alpha VMS 7.3-1 has just deliveredeF > a load of pages to the outside world, and continues to do so at thisH > moment; less than 5% CPU usage over several hours, even when I've been > hammering it on other things.s >l  L The way to use the slideshow was pretty obvious. No problems with that Paul.7 Speed was fine (we're behind a 768/128 kbps ADSL link).. Thanks for the service.n   Hans   ------------------------------  % Date: Fri, 14 May 2004 21:48:31 +0200O* From: Paul Sture <nospam@sture.homeip.net>E Subject: Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"s* Message-ID: <2gkm4hF3ukadU1@uni-berlin.de>   Hans Vlems wrote:e >d > N > The way to use the slideshow was pretty obvious. No problems with that Paul.9 > Speed was fine (we're behind a 768/128 kbps ADSL link).   F Thanks for the feedback. It appeared obvious to me at the time how it 4 worked,but the weblogs also taught not to assume :-)   > Thanks for the service.@ >   ) Thanks too for letting me know it worked.l   ------------------------------  % Date: Fri, 14 May 2004 21:54:53 +0200 * From: Paul Sture <nospam@sture.homeip.net>E Subject: Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"t* Message-ID: <2gkmgfF3v57dU1@uni-berlin.de>   Bob Ceculski wrote:C^ > Paul Sture <nospam@sture.homeip.net> wrote in message news:<2gh8c7F2ppi0U1@uni-berlin.de>... > = > sounds like damage control to me ... and I wouldn't believe-= > half that, as EV8 would have been cheap to make compared tod: > itanium ... itanium only holds a lead over alpha because7 > alpha has been held back for years now to allow it tom8 > catch up ... I think you can find the real reason that9 > alpha was canned in their, because intel told compaq tou( > get rid of it or no more cheap pcs ...  C Don't shoot the messenger Bob. I have no comment to make about the  H article, even though I did my best to make it available to the denizens  of comp.os.vms.   E Simply a service I provided, since I knew people would be interested.    ------------------------------  # Date: Fri, 14 May 2004 21:29:24 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")1 Subject: Re: Timestamp format stored in RMS file?a6 Message-ID: <00A31D48.513F3305@SSRL.SLAC.STANFORD.EDU>  ] In article <opr7zkyxygxckwek@diablo.uninet.ee>, Jaan Kronberg <jaan.kronberg@mail.ee> writes:o >o >d >eH >On Thu, 13 May 2004 16:45:42 +0100, Richard Brodie <R.Brodie@rl.ac.uk>  >wrote:r >d >>< >> "Jaan Kronberg" <jaan.kronberg@mail.ee> wrote in message , >> news:opr7x0i8q6xckwek@diablo.uninet.ee... >> >>> 8 bytes: >>> 0000 36BD 04FB A200H >>>lF >>> Could anybody "translate" it to "readable" date without using any  >>> built-in >>> OpenVMS function?n >>G >> Yes. Time in 100 nanosecond intervals since November 17th 1858, as an >> 64-bit word.d >> >> Some Python:a >>" >>>>> base = '1-jan-1970 00:00:00'! >>>>> vms.starlet.bintim(base)[1]i >> 35067168003000000Le@ >>>>> seconds = ( 0xA2FB04BDBDCDA0L - 35067168002100000L ) / 1E7( >>>>> time.asctime(time.gmtime(seconds)) >> 'Thu Apr  1 00:00:00 2004'  >> >> Close enough:. >>>>> vms.starlet.asctim(0xA2FB04BDBDCDA0L)[1] >> ' 1-APR-2004 00:00:00.89' >> >> >> >A >i >s& >Thank you all, folks, esp. Richard :) >pL >He answered what I actually needed - platform-independent code (algorythm) 1 >for translating vms time from quadword to ascii.l  J I suspect you won't find vms.starlet.bintim working properly on any PythonI platform but VMS. This is just the Python interface into the VMS runtime r library.   -- Alane -- hO ===============================================================================S0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================n   ------------------------------    Date: 14 May 2004 16:02:48 -0700 From: ohm62@hotmail.com (OHM)d1 Subject: Re: Timestamp format stored in RMS file? = Message-ID: <9d337b47.0405141502.5d7bcc16@posting.google.com>s   #include <string.h>h #include <stdio.h> #include <time.h>m #include <timers.h>l   #include <ssdef.h> #include <descrip.h> #include <starlet.h>    % typedef unsigned long long TDateTime; " typedef struct timespec TTimeSpec;    D /* UNIX EPOCH time reference, expressed in OpenVMS date time type */7 const TDateTime JANUARY_1RST_1970 = 0x007c95674beb4000;     1 /* OpenVMS date-time quadword conversion to UNIX r3  * timespec value (seconds,nanoseconds from EPOCH).:  */i  = extern void VmsToUnixTime( TDateTime vmsTime, TTimeSpec *ts )s {-     struct tm tmv;     time_t t = 0;o    ;     vmsTime -= JANUARY_1RST_1970;  /* Translate to EPOCH */o     F     localtime_r( &t, &tmv );  /* OpenVMS time is local, UNIX is GMT */  F     /* OpenVMS times in ticks of 100 nanoseconds: factor 10,000,000 */5     ts->tv_sec  = vmsTime / 10000000 - tmv.tm_gmtoff;i+     ts->tv_nsec = vmsTime % 10000000 * 100;  }     
 #ifdef __TEST    /*  * Test case:   *  *  $ show cpu  *  $ cc /version;-  *  Compaq C V6.5-001 on OpenVMS Alpha V7.3-1v   *  $ cc timcnv.c /define=__TEST  *  $ link timcnv $  *  $ timcnv := $mydev:[mydir]timcnv&  *  $ timcnv "14-MAY-2004 12:31:00.10"F  *  UNIX representation: Fri May 14 13:31:00 and 100000000 nanoseconds  */   " void main( int argc, char **argv ) {x     int sts = 0;L     struct dsc$descriptor_s dsc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, NULL };     TDateTime dt;      TTimeSpec ts;s         if ( argc <= 1 ) {Q 	printf( "Usage: testime :== $testime\n\ttestime ""DD:MM:YYYY HH:MM:SS.CC""\n" );l 	sys$exit( SS$_INVARG );     }e  *     dsc.dsc$w_length  = strlen( argv[1] );      dsc.dsc$a_pointer = argv[1];  @     /* Convert date time string passed as parameter to binary */"     sts = sys$bintim( &dsc, &dt );  ;     /* Test the conversion to UNIX binary representation */e     VmsToUnixTime( dt, &ts );   >     printf( "UNIX representation: %.19s and %d nanoseconds\n",-        ctime( &ts.tv_sec ), ts.tv_nsec );    e }t   #endif   ------------------------------  % Date: Fri, 14 May 2004 11:32:27 -0700-+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>0A Subject: Re: [General]: Understanding 'Mean Time Between Failure'a' Message-ID: <40A510BB.6000207@MMaz.com>s  A Very interesting read, thanks for taking the time to write it... n  I I never took much in the way of statistics in school, but I would assume mG others on this list have, and I would really be interested in what you  G wrote with practical statistical application (probably not the correct iB verbiage).  What do I mean?  What if you take all of the discrete H components that make up an entire system, can you develop more accurate F MTBF's of 'systems' based on the manufacturers individual component's B MTBF average?  Knowing that based on history, the more components H involved, that the MTBF of each individual component is reduced by an X * factor?  Perhaps in an Excel spreadsheet?   I For example, we had a RAID array that just ground through Seagate drives sF for about two years.  The array stayed up, but as you pointed out, we H had SCSI U320 drives that we dying about every 11 to 17 months which is G far lower than the factory MTBF.  In this case, neither the system nor nC the RAID's MTBF was directly impacted, but what if in a worse case -I scenario, multiple drives failed concurrently while a RAID 5 rebuild was oG occurring (after a new drive was automatically pulled from the 'spares fH pool'), then both our 'systems'  and 'RAID" MTBF would have gone in the G toilet which I believe is the precise point your article is attempting _ to make.  H After over two decades in IT, you have gut feeling for products to stay H away from, but even your more reliable sources like Seagate and Fujistu H are having such consistent MTBF problems (at least in our case) that it G appears the MTBF numbers are fiction.  Having a tool that could better s? extrapolate the potential 'real life' MTBF based on individual tA components and their propensities for combined failures would be eE helpful...  One could more accurately count the cost of downtime vs. s/ more redundancy vs. on the shelf spare parts...n   Just a thought.i  
 Best regards,h   Barry Treah        John Smith wrote:   = >http://itmanagement.earthweb.com/columns/article.php/3354191e >t* >Understanding 'Mean Time Between Failure' >By George Spaffordi
 >May 14, 2004o >uM >Mean Time Between Failure (MTBF) is a much-used management metric in IT both 4 >for discrete components as well as overall systems. >yM >For simplicity, let's define MTBF as the average time between failures. It'soI >either based on historical data or estimated by vendors and is used as alM >benchmark for reliability. Organizations trending MTBF over time can readilygH >see devices that are failing above average and take appropriate action. >sJ >Where MTBF breaks down is when management puts too much faith in unprovenH >MTBF estimates and uses them to justify inordinately massive amounts ofL >capital investment on complex systems. This may seem to be a bold statement) >and therefore requires some explanation.p >eJ >If we assume that there are 8,760 hours per year (365 days x 24 hours perJ >day) then we can divide MTBF claims from vendors and look at how long theM >system will run in years. If we buy a system, or component, with a rating ofpM >30,000 MTBF, then we might assume that on average, the system would run 3.42sJ >years without a failure. Granted, there are always statistical variationsE >around the average, but 3.42 years doesn't seem bad at all, does it?l >mK >There's a problem with this rationale, however, especially when applied toiL >complex systems. First, as previously mentioned, it is both an estimate andG >an average. You run the risk of being one of the seemingly statisticaltK >anomalies with a far higher frequency of failure that gets smoothed out byoE >the averaging! The reason could simply be that the MTBF estimate wasuE >subjected to different environmental factors such as heat and power.s >tK >Second, fault-tolerance costs accelerate very rapidly as higher and higherrM >MTBF levels are sought. Third and perhaps the most important, fault-tolerant L >systems (hardware, software, documentation and processes) in general become@ >increasingly complex as the level of fault tolerance increases.J >Fault-tolerant systems typically are more complex than non-fault-tolerantG >systems. This increased level of complexity, in and of itself, creates  >fertile ground for disasters. >n >r* >Coupling, Complexity and Normal Accidents >{G >In 1984, Charles Perrow wrote an amazing book titled Normal Accidents: L >Living with High Risk Technologies. In it he observed that system accidentsG >can be the result of one big failure, but most often are caused by theaA >unexpected interactions between failures of multiple components.  >9H >In other words, complex systems whose components are tightly integratedJ >typically fail through the culmination of multiple components failing andM >interacting in unexpected ways. For example, it's very rare that a plane has H >a wing fall off mid-flight. It's far more likely that several componentE >failures interact in unpredictable ways that, when combined, cause a^? >catastrophe. Let's investigate this line of reasoning further.t >kL >First, errors can be readily visible or latent. The former we can deal withK >when we detect them. The latter are far more insidious because they can beo> >in a system and undetected, "waiting to spring," if you will. >oM >Second, complex systems made up of hundreds, if not thousands of components,7K >that interact tightly are considered to be tightly "coupled." The possiblyeK >pathways of interaction are not necessarily predictable. Perrow points out2L >that during an accident, the interaction of failed components can initially >be incomprehensible.8 >eI >Let's take a highly fault-tolerant database server with its own externallM >RAID and then use clustering software to join it with another server locatedt >in another data center. >iI >At this point, we have a pretty complex system comprised of thousands ofnL >components that are all tightly coupled. The IT operations staff is capable* >and diligent, performing nightly backups. >eM >Now, imagine that there is a programming error on the RAID controller caused L >by an unexpected combination of data throughput and multi-threaded on-boardI >processor activity that causes a periodic buffer overflow and subsequent M >data corruption that is then written to the drives. It doesn't happen often,nL >but it does happen. As the systems are exact duplicates of one another, the, >issue happens on both nodes of the cluster. >tL >At an observable level, everything would seem to be OK because the error isH >latent. It isn't readily apparent until one or more database structuresJ >become sufficiently corrupt to raise awareness of the issue. Once it doesK >happen, the network and database people scramble to find out what is wrongaM >and go tracking through the logs looking for clues and checking for securityaC >breaches because "it was running fine." The point is that multiple F >components can interact in unforeseen ways to bring down a relatively >fault-tolerant system.a >aK >One must also readily conclude that if the chance of errors increases witheL >the level of complexity, then so to must the probability of errors that canG >cause security breaches. Thus, not only is failure inevitable, but theeM >likelihood that at least one exploitable security hole exists is inevitable.o >r >r >Mean Time to Repair (MTTR)e >iK >Let's face it, accidents can and will happen. Fault tolerance can create ao@ >false sense of security. From our 30,000-hour example, we couldJ >unrealistically expect 3.42 years of uninterrupted bliss, but reality and$ >Mr. Murphy don't like this concept. > L >Yes, fault tolerance reduces the chance of some errors, but as the system'sI >inherent complexity and level of interaction increases, the chance of antJ >accident increases. How often is a fault-tolerant system simple? How manyJ >people in your organization fully understand your fault-tolerant systems?K >There are many questions that can be asked, but here is the most importantsK >question: "When the system fails, and it will fail, how easy will it be to.
 >recover?" >eL >Not too surprisingly, there often is a dichotomy with highly fault-tolerantJ >systems. On one hand, their likelihood of failure is less than a standardL >system lacking redundancy, but on the other, when they do fail, they can be- >a bear to troubleshoot and get back on line.  >LE >Instead of spending tens, if not hundreds of thousands of dollars onuD >fault-tolerant hardware, what if IT balanced the costs of the faultH >tolerance with an eye toward unrelentingly driving down the MTTR of theE >systems? True systemic fault tolerance is a combination of hardware,aM >software, processes, training, and effective documentation. Sometimes, teams F >focus on the hardware involved first, the software requirements are aI >distant second and then they totally overlook the process, training, and  >documentation needs.e >eH >Always remember that availability can be addressed by trying to preventG >downtime through fault tolerance as well as by reducing the time spent C >recovering when an actual outage does occur. Therefore, activities H >surrounding the rapid restoration of service and problem resolution areI >essential. The ITIL Service Support book provides great guidance on both H >initially restoring services through Incident Management and ultimatelyA >addressing the root causes of the outage via Problem Management.c >gI >The Berkeley/Stanford Recovery-Oriented Computing (ROC) research team, a-H >joint project at Berkeley and Stanford, also provides great information! >about ROC. You can find it here.- >- >- >Summary > J >Of course MTBF matters -- it is an important metric to track in regard toM >system reliability. The main point is that even fault-tolerant servers fail.0K >As the level of complexity and coupling increases, systemic failure due torL >the accumulation of component failures interacting in previously unexpectedM >ways is inevitable. IT should look at availability holistically and consider M >addressing both initial system design fault tolerance and the speed in which " >a failed system can be recovered. >sD >In some cases, it may make far more sense to invest less in capitalI >intensive hardware and more on the training, documentation and processes 5 >necessary to both prevent and recover from failures.o >f >--------------------------- >nH >A thought-provoking article on a series of issues that many managements4 >never consider, and most IT departments gloss over. > M >Overall, assuming that one was going to employ properly trained staff in the-J >first place, I'd consider this article to be making an effective case forJ >VMS clusters. Some might say that NSK would be a better bet, and for someH >apps that may well be the case. But for the vast majority of companies,, >OpenVMS style clusters fit the bill better. >1 >l >s >c >  m >n   -- d  > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                        m   ------------------------------  % Date: Fri, 14 May 2004 14:49:52 -0400p# From: "John Smith" <a@nonymous.com>-A Subject: Re: [General]: Understanding 'Mean Time Between Failure' , Message-ID: <bqydnUKWKNVIiTjdRVn-sQ@igs.net>  6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! news:40A510BB.6000207@MMaz.com...NB > Very interesting read, thanks for taking the time to write it...     Barry,  J I didn't write it.  I just posted it because I thought it might be thoughtH provoking for those of us here in c.o.v., and a possible tool for use inJ considering whether it was wise to leave OpenVMS for the murky pastures of Window, linux, or unix.l  $  The author deserves all the credit.   John   ------------------------------  % Date: Fri, 14 May 2004 13:01:19 -0700>* From: "Jack Peacock" <peacock@simconv.com>A Subject: Re: [General]: Understanding 'Mean Time Between Failure'r2 Message-ID: <CoWdnQuuJNkLuDjd4p2dnA@mpowercom.net>  6 "Barry Treahy, Jr." <Treahy@MMaz.com> wrote in message! news:40A510BB.6000207@MMaz.com...sI > After over two decades in IT, you have gut feeling for products to stay I > away from, but even your more reliable sources like Seagate and Fujistu I > are having such consistent MTBF problems (at least in our case) that itt' > appears the MTBF numbers are fiction.e >iJ As I understand the procedure vendors determine the MTBF by testing drivesI under accelerated conditions (higher temp, etc.) and extrapolate what thesL MTBF would be under normal conditions.  It isn't practical to actually run aI batch for 50,000 hours before putting the drives on the market so I don'trL disagree with the procedure...but I don't put much faith in MTBF figures (orL MTTR either, if you don't have a spare the MTTR is days regardless of vendor claims).  J Accelerated testing doesn't account for the nasty surprises that come fromD catastrophic failures rather than normal wear and tear.  Not being aC mechanical engineer I don't know of any specific cases, tho the IBMeK Deathstar fiasco might be an example ("our MTBF is based on using the drive  no more than 8 hours a day").   L (VMS content) I have learned that MTBF for modern drives has more to do withB the cooling in the chassis than the drive itself.  Even supposedlyH well-designed boxes like the DEC Alphastation 500 tended to burn up SCSIH drives once a year (and yes they were the drives DEC recommended for theG box).  Before we replaced our 500 we went thru 3 drives in the two year4L warranty period (300% failure rate, MTBF in our case of about 6500 hours forK 4GB RZ29s).  Fortunately we had implemented a policy of all server disks tom' be mirrored starting with that machine.A  D We also encountered a problem with a pair of DS10s where the factoryK installed CD-ROM drives lasted about 30 days.  MTBF doesn't account for badtK batches slipping thru Q/C.  (BTW the CD replacements were the last time theiJ machines were manually rebooted, the one on a UPS is now at about 700 days uptime.)   Jack Peacock   ------------------------------  % Date: Fri, 14 May 2004 15:34:09 -0500:/ From: Chris Scheers <chris@applied-synergy.com>(A Subject: Re: [General]: Understanding 'Mean Time Between Failure'd3 Message-ID: <40A52D41.4E2B7D16@applied-synergy.com>S   "Barry Treahy, Jr." wrote: > B > Very interesting read, thanks for taking the time to write it... > J > I never took much in the way of statistics in school, but I would assumeH > others on this list have, and I would really be interested in what youH > wrote with practical statistical application (probably not the correctC > verbiage).  What do I mean?  What if you take all of the discreteoI > components that make up an entire system, can you develop more accurateeG > MTBF's of 'systems' based on the manufacturers individual component'smC > MTBF average?  Knowing that based on history, the more components I > involved, that the MTBF of each individual component is reduced by an Xy+ > factor?  Perhaps in an Excel spreadsheet?   C The problem with calculating a system is determining how things areT
 interrelated.e  F If you assume that all components are independent, you figure the oddsA that each component will NOT fail in a given period of time, thensD multiply them all together, to get the odds that the system will NOT! fail in that same period of time.s  G For a trivial example: Assume you figure that you have a 1% change thatp? any given component will fail in the next year, and you have 20o components in your system.  G The odds that any single component will NOT fail are 99% (or .99).  TheF> odds that the system will NOT fail are .99^20 ~= .82 or (82%).  D This can be summarized as the odds that your system will fail in the next year are:   	1 - (.99^20) ~= 18%   If your failure rate is 2%:o   	1 - (.98^20) ~= 33%   If your failure rate is 5%:T   	1 - (.95^20) ~= 64%  H Increasing the number of components results in a similar increase in the
 failure rate.A  F Unfortunately, things are usually not independent.  For example, a fanH failure is likely to result later in a higher failure rate for the items which were cooled by that fan.  G -----------------------------------------------------------------------=$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com     Fax: 817-237-3074o   ------------------------------   End of INFO-VAX 2004.268 ************************41.3d12a36c@posting.google.com>    winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote in message news:<00A31D4D.0798F5C4@SSRL.SLAC.STANFORD.EDU>...a > In article <40a528e5$0$4591$db0fefd9@news.zen.co.uk>, 
> Tajuan ett absoluuttista vastausta ei voi antaa (siksi "paras"
> sulkumerkeiss), mutta lukisin mielellni mielipiteit. Oletan ett ryhmn
> kirjeenvaihtoa seuraa muitakin jotka miettivt samaa asiaa, joten, te
joilla
> on kokemuksia, ystvllisesti jakakaa ne muillekin. Kiitos etukteen!
>
> Ernst Nyberg
>
>


^~00001784:0000013756:035017:From: "KeesR" <KeesR@wanadoo.nl>
Newsgroups: nl.uitkeringen
Subject: Re: Wat krijg je allemaal als je een bijstandsuitkering hebt?
Date: Thu, 30 Jan 2003 20:18:16 +0100
Sender: kees_reijman
Organization: Behoorlijk.
Reply-To: "KeesR" <KeesR@wanadoo.nl>
Message-ID: <shui3v4r2hl4l2bdn2m3lfvj994to9a3ud@4ax.com>
References: <nk5e3vk1oc86lgkslkirq5qdc2lcav5899@4ax.com> <3e37ce83$0$49110$e4fe514c@news.xs4all.nl> <fccg3v8fndngu5toebo3qmhj76rtj1ch7h@4ax.com> <3e385134$0$49109$e4fe514c@news.xs4all.nl> <d9nh3vobvi7ig7dnjdff504to5stuc3b10@4ax.com> <b1ascv$fjn$1@reader08.wxs.nl> <3e3903a4$0$49112$e4fe514c@news.xs4all.nl> <b1b5fb$4k3$1@reader10.wxs.nl> <3e393d15$0$49100$e4fe514c@news.xs4all.nl>
X-Newsreader: Forte Agent 1.91/32.564
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 12
NNTP-Posting-Date: 30 Jan 2003 20:18:15 CET
NNTP-Posting-Host: 62.234.123.64
X-Trace: 1043954295 news.xs4all.nl 49106 greijman/62.234.123.64:1024
X-Complaints-To: abuse@xs4all.nl
Path: mvb.saic.com!news-out.cwix.com!newsfeed.cwix.com!iad-peer.news.verio.net!news.verio.net!news.maxwell.syr.edu!transit.news.xs4all.nl!not-for-mail
Xref: mvb.saic.com nl.uitkeringen:13756

Op Thu, 30 Jan 2003 15:56:22 +0100 schreef "francina"
<fralie@xs4all.nl> Met Microsoft Outlook Express 6.00.2800.1106 over
Re: Wat krijg je allemaal als je een bijstandsuitkering hebt? in
nl.uitkeringen

<|> Dus zal er meer controle moeten komen bij bedrijven, die werk aanbieden en
<|> dit zal gericht moeten zijn op risico-bedrijven.
<|Helemaal gelijk, maar denk je dat dat gaat gebeuren?
<|Natuurlijk niet

Nee. Uiteraard niet. Weet je waarom? Omdat de lieden die het zouden
moeten aanpakken allemaal zelf boter op het hoofd hebben volgens mij.
^~00003528:0000003947:045410:From: "Samuel L Matzen" <smatzen@slm.com>
Newsgroups: infragistics.ultragrid
References: <3e3348e1@news.shersoft.com> <3e337c09@news.shersoft.com> <3e395c89$1@news.shersoft.com>
Subject: Re: Unbound Grids
Date: Thu, 30 Jan 2003 12:51:00 -0600
Lines: 80
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
NNTP-Posting-Host: adsl-65-66-88-89.dsl.wchtks.swbell.net
Message-ID: <3e3972f4$1@news.shersoft.com>
X-Trace: 30 Jan 2003 13:46:12 -0500, adsl-65-66-88-89.dsl.wchtks.swbell.net
Organization: Infragistics, Inc.
Path: mvb.saic.com!news.shersoft.com!adsl-65-66-88-89.dsl.wchtks.swbell.net
Xref: mvb.saic.com infragistics.ultragrid:3947

Scott,

I am not quite sure what you are asking here, but I will expound anyway:

1.  I think what they are referring to regarding meta data 