1 INFO-VAX	Sat, 15 May 2004	Volume 2004 : Issue 269       Contents:! $SHOW NET w/TCPIP, odd behaviour? 1 Re: Anyone here using products from this company? > Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info?????> Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? Re: Help required with CLD file  Re: installation boot failure  Re: longest uptime Re: longest uptime Re: Lotus notes and VMS mail Re: Lotus notes and VMS mail> Re: Poor VMS file create performance compared to Linux/FreeBSD Reboot forces Shadowset Merge < Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"< Re: Terry Shannon's "HP: Two Years Post-Merger Presentation"2 Re: VMS Linker Question - multiple defined symbols8 Re: [General]: Understanding 'Mean Time Between Failure'8 RE: [General]: Understanding 'Mean Time Between Failure'  F ----------------------------------------------------------------------  % Date: Sat, 15 May 2004 15:31:14 +0200 + From: Wilm Boerhout <w2.boerhout@planet.nl> * Subject: $SHOW NET w/TCPIP, odd behaviour?6 Message-ID: <40a61b4f$0$32173$ba620dc5@nova.planet.nl>  B I have a production VAX and an exact copy (hardware, peripherals, I software setup) that I want to connect to the TCP/IP LAN. They *used* to  G have DECnet, but that is no longer started. Just TCP/IP Services. (VMS  5 7.1, TCPIP Services for VMS V4.1, patches up to date)   I The DECnet and SCSNODE names are PRDVAX and TSTVAX. Periodically, I want  G do make an image backup of PRDVAX single disk (system and application)  G and reload it to TSTVAX. Obviously, I need to reconfigure at least the  I TCP/IP address on TSTVAX's Ethernet interface to be able to connect them  E both to the LAN. For good measure I also change the unqualified host  ? name on that interface to TSTVAX. I deliberately do not change  D SCSNODENAME on TSTVAX after the reload, so VMS on the TSTVAX system  still thinks it's called PRDVAX   D After I reconfigure the interface on TSTVAX, reboot and start TCPIP H Services, the $SHOW NET command on TSTVAX lists PRDVAX *and PRDVAX's IP I number* in its information line. However, on the actual interface the IP  F number assigned to TSTVAX is active, as demonstrated by both outgoing G and incoming connection data (connecting to TSTVAX's IP number from an  H arbitrary system makes it connect to the correct system, TELNETting out 5 list the correct sender address on the remote system)   A Is this expected behaviour of $SHOW NET, does it always list the  E information starting with the SCSNODE entry in the UCX host database?    Thanks,  Wilm   ------------------------------  % Date: Sat, 15 May 2004 04:11:47 -0400 * From: "Bill Todd" <billtodd@metrocast.net>: Subject: Re: Anyone here using products from this company?2 Message-ID: <YrCdnUBgmNg9TTjdRVn-ug@metrocast.net>  . "John Smith" <a@nonymous.com> wrote in message& news:qKqdnfKrm9j0CD7dRVn-vA@igs.net... > http://www.netapp.com  >  > Opinions?   B Network Appliance revolutionized the business of high-performance,I high-integrity file serving over a decade ago, with the introduction of a C novel 'write-anywhere file layout' - WAFL - file system (not really J log-structured, but with some similarities) with integrated stable RAM forF write performance.  Since then, they have been a consistent leader andI developed a very good reputation, to the point where their prices reflect L this.  They offer a pretty complete lineup, including remote replication for. disaster tolerance (may be asynchronous only).  L Neat technology, plus some *very* good technical people (including early SunK and Tandem folks).  If you need industry-standard file service (CIFS and/or J NFS) it would be hard to do better, save perhaps on price (and at least to0 some extent you get what you pay for at NetApp).   - bill   ------------------------------  # Date: Sat, 15 May 2004 06:06:46 GMT + From: "Dan Notov" <danno@large.INVALID.com> G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? / Message-ID: <Wripc.51198$536.8859046@attbi_s03>   ; "Alex Daniels" <alexdaniels@themail.co.uk> wrote in message 6 news:9f7f13a8.0405141948.29dbe38@posting.google.com...H > koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote in message/ news:<mGSUaTw$Nu4$@eisner.encompasserve.org>... C > > 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...K > > > Mmm, maybe. Do I remember correctly that Tru64 originated as the love  babyI > > > 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.  > > 2 > >    The rename to Tru64 UNIX was a Compaq move. > C > Wasn't its time as 'Digital UNIX' also in between being OSF/1 and D > Tru64 ? So really don't know where the 'IBM Tru64' is coming from.  0 The brand name lineage goes something like this: DEC OSF/1 at inception  DIGITAL UNIX at the death of OSF2 Compaq's DIGITAL UNIX immediately after the merger2 Tru64 UNIX. when it was planned to move to Itanium  = IBM Tru64 sounds like a search/replace without proof-reading.    ------------------------------  % Date: Sat, 15 May 2004 07:50:22 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>G Subject: Re: Big Blue - Caught Red Handed, stealing KGPSA HBA info????? * Message-ID: <c84eh6$1hvf$1@news.wplus.net>  6 "Dan Notov" <danno@large.INVALID.com> wrote in message) news:Wripc.51198$536.8859046@attbi_s03... E > > Wasn't its time as 'Digital UNIX' also in between being OSF/1 and F > > Tru64 ? So really don't know where the 'IBM Tru64' is coming from. > 2 > The brand name lineage goes something like this: > DEC OSF/1 at inception" > DIGITAL UNIX at the death of OSF4 > Compaq's DIGITAL UNIX immediately after the merger4 > Tru64 UNIX. when it was planned to move to Itanium > ? > IBM Tru64 sounds like a search/replace without proof-reading.   F If it was a search/replace as you suggest, does that then indicate IBM) acquired the original from DEC/Compaq/HP?   G If it had come from Emulex there would be no need to search and replace D anything as any references to OS manufacturers would remain correct.   Alex   ------------------------------   Date: 15 May 2004 07:42:51 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>( Subject: Re: Help required with CLD file? Message-ID: <DTiotGxQ0bj6-pn2-W1Kqxz8dXSgU@dave2_os2.home.ours>   D On Wed, 12 May 2004 16:07:13 UTC, oj_287@yahoo.co.uk (Ron Atkinson)  wrote:  > > I want to be able to enter a command in the following format >  > 	> APP CMD /QUAL=<txt>   This implies  either :-   / a. The CLD file you mention below is used with    # 	SET COMMAND MY_APP_CMD_TABLE.CLD       to modify your process DCLTABLES  5 b. you have defined symbol APP :== $ MY_APP and used    ( 	SET COMMAND    /OBJ    MY_APP_CMD_TABLE  - and linked  MY_APP_CMD_TABLE into MY_APP.EXE.   D I would only expect you to be using SYNTAX to run a second image if  you are using option (a).   C If you're using option (b) there are a few more possibilities. You   won't need a second image.  H > where the first two characters of the <txt> value are fixed (i.e. AB). > E > In my CLD file the value of QUAL is set to $quoted_string type i.e.  >  > DEFINE SYNTAX 	QUAL_SYN  > IMAGE 		"QUAL.EXE", > QUALIFIER	QUAL VALUE (TYPE=$QUOTED_STRING) > F > I guess I want to be able to define a user-defined keyword where theF > first two characters are set to AB and the rest of the string can be > free text. > H > I cannot create a new QUAL.EXE file. So is this possible under VMS 6.2% > purely within the CLD file itself ?   F Using option (b) you can use the SYNTAX statement to call a different D routine or to apply different parsing rules. It's very powerful and @ perhaps a little overwhelming. I have to think every time I add $ something but that's no bad thing...  F Nic's suggestion to check out the Command Definition Utility manual isE the first one to take up. Follow that up by reading the CLI routines  D section of the Utilities Manual from the programmers section of the D docs. That teaches you how to process the parameters and qualifiers  within your programs.   E I have used both options over the years from VMS 3.7 and up. I don't  F remember a great deal of variation bewtween 5.5, 6.2 and 7.1 (the most$ recent version I can develope under)   --     Cheers - Dave.   ------------------------------  # Date: Sat, 15 May 2004 12:52:11 GMT  From: "o-o-o" <bkt@null.net>& Subject: Re: installation boot failure: Message-ID: <%nopc.351$Bk1.291@newssvr23.news.prodigy.com>  L Thanks for the tip, that works, and I can boot the CD. However on boot I get checksum errors:" Installing required known files...   Configuring devices...  A %PKB0, Copyright (c) 1998 IntraServer Technology Inc. PKW V2.1.21   > %PKB0, SCSI Chip is SYM53C875, Operating mode is SE Ultra SCSI  ( %PKB0, OFFLINE. ROM Checksum read error.  A %PKC0, Copyright (c) 1998 IntraServer Technology Inc. PKW V2.1.21   > %PKC0, SCSI Chip is SYM53C875, Operating mode is SE Ultra SCSI  ( %PKC0, OFFLINE. ROM Checksum read error.  ! %EWA0, FastFD mode set by console   K and once I'm in the install utility, I can't see my SCSI hard drives. All I 0 see are the CDROM, floppy drive, and tape drive:4 Enter device name for target disk: (? for choices) ?  ) Device Device Error Volume Free Trans Mnt   ( Name Status Count Label Blocks Count Cnt   DAD0: Online 0  , DKA500: Mounted wrtlck 0 ALPHA0731 7785 87 1   DVA0: Online 0      2 Enter device name for target disk: (? for choices)  
 any ideas?    6 "Roland Barmettler" <itsme@127.0.0.1> wrote in message/ news:20040514164358.5f919920.itsme@127.0.0.1... 7 > Colin Butcher wrote on Fri, 14 May 2004 10:49:39 GMT:  > J > > You might find that you could change the CPU, but keep the bulk of theH > > box. I did that with a Digital Server 7000 and turned it into a 4100E > > by simply swapping the CPU boards for some old 300MHz VMS capable G > > Alphas. The rest of the box is pretty much the same - seems to work  > > just fine. > G > You don't even need to change CPUs, I have a Digital Server 7310 with ) > "NT only" CPUs that runs VMS just fine. B > What you need to do is to create a small NVRAM script in the SRMI > console that creates and sets an environment variable srm_boot to "ON".  >  > So:  >  > >>>edit nvram  > >>>10 set srm_boot ON 	 > >>>exit  >  > I also set boot_reset to "ON"  >  > Hope it helps... >  > Cheers, Roland >  > -- > 3rd Law of Computing: ! >         Anything that can go wr " > Segmentation fault (core dumped)   ------------------------------   Date: 15 May 2004 07:42:56 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow> Subject: Re: longest uptime ? Message-ID: <DTiotGxQ0bj6-pn2-q3mpCVElFIXn@dave2_os2.home.ours>   6 On Fri, 14 May 2004 01:29:30 UTC, "David J. Dachtera" - <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote:    > Syltrem wrote: > > K > > > Well, I have a cluster that was established well over a year ago, but N > > > 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...  > > ;-)  > C > Yeah, well, even in the VMS world, pesky app.'s can have resource 
 > leaks... >  > *SIGH*  F True, we rebooted a colleague's Workstation yesterday as it had slowedF to a crawl after 'loosing' free memory. I hate to admit it but it the F culprit was either my DecThreaded app or the debugger. Probably me and circumstance :-)   --   Cheers - Dave.   ------------------------------  % Date: Sat, 15 May 2004 11:02:51 +0200 * From: Paul Sture <nospam@sture.homeip.net> Subject: Re: longest uptime * Message-ID: <2gm4ltF4d6ijU1@uni-berlin.de>   Nic Clews wrote:! > david20@alpha2.mdx.ac.uk wrote:  >  >> >>>>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. >  > F > A system that has a weekly reboot (for standalone image backups) theG > operator commands are described as "IPLing" the system (not booting).  > F > No prizes for guessing the "partner in crime" system to this one ;-) > 0 > (Uh, oh, OK, Initial Program Load for the IBM) > B > Yes I said weekly. Very stable otherwise. Any advance on weekly?  G Yep, I've done weekly reboots too, but that was 8 years ago, where the  H disks were small enough that fragmentation was a potential show stopper.  G We did standalone backups of the system disks (VAX and Alpha) and full  F backups of the rest, using backup/image to go to tape and then to the G second shadow set member of each disk, mounting the newly defragmented  8 disk for use then having shadowing copy to the original.  H And it was performed by the IBM operators, so we had to keep it as easy  as possible for them.   C One thing nobody else has mentioned, which is important, is that a  H reboot proves out changes to startup files. This was a mission critical G site with active development of new applications, so the startup files    got modified on a regular basis.  E In the event of a startup failure, we wanted it to happen during our  I Friday night downtime slot rather than have the panic of discovering and  ; fixing it after a hardware failure during production hours.   F Weekly reboots also tested out any startup modifications on a regular E basis. Far easier to remember what you chanegd in the last week than  F many moths ago, and it reduced the potential for more than one or two $ problems to be introduced.at a time.  F Fortunately we never had a system crash in production hours during my F time there, but we were confident our startups would be no problem if 
 we'd had one.    ------------------------------  % Date: Sat, 15 May 2004 11:27:28 +0200 * From: Paul Sture <nospam@sture.homeip.net>% Subject: Re: Lotus notes and VMS mail * Message-ID: <2gm642F4egc4U1@uni-berlin.de>   Alex Daniels wrote:  > 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"  > F > If your using TCP/IP Services, the above may be worth a try, you can1 > obviously set the logical to whatever you like.  > / > Works for me anyway when sending to exchange.  >   0 I too have used that successfully with exchange.  I I never tried it with Notes, but found with that, that mails sent from a  F VMS account containing an underscore would arrive with the underscore B replaced by a period, so replies without editing the address were  impossible.    ------------------------------    Date: 15 May 2004 06:31:17 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) % Subject: Re: Lotus notes and VMS mail 3 Message-ID: <4EJNE0Z1wHxE@eisner.encompasserve.org>   n In article <9f7f13a8.0405141941.3d12a36c@posting.google.com>, alexdaniels@themail.co.uk (Alex Daniels) writes: > winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote in message news:<00A31D4D.0798F5C4@SSRL.SLAC.STANFORD.EDU>...  M >> It's something you're not doing in that you're not setting whatever header J >> it is that Notes wants to use.  Whether you _can_ set it using callableI >> 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"   % $ show logical MULTINET_SMTP_REPLY_TO I    "MULTINET_SMTP_REPLY_TO" = "Kilgallen@spamcop.net" (LNM$PROCESS_TABLE)    ------------------------------  % Date: Sat, 15 May 2004 04:49:27 -0400 * From: "Bill Todd" <billtodd@metrocast.net>G Subject: Re: Poor VMS file create performance compared to Linux/FreeBSD 2 Message-ID: <9NudnaqZNarpRDjdRVn-hw@metrocast.net>  G "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 5 message news:ACNLDAui2WbG@eisner.encompasserve.org... J > I am seeing very poor VMS I/O performance compared to Linux/FreeBSD whenJ > trying to perform the same task - unpacking a GCC tar archive - on these1 > operating systems. A table of results is below.  > D > I've gone into a lot of detail about my test environments, so that	 hopefully F > if I've missed something it will be noticed. I am also interested in seeing: > the results on other platforms if anyone is so inclined. > J > The tar archive in question is GCC 3.4.0 which contains 22735 files/dirs and D > is 191,467,520 bytes long uncompressed; as VMSTAR does not support
 compressed0 > archives I uncompressed all archives first[1].  I This in itself should be a rather glaring clue:  according to the numbers I you provided later, on the Red Hat systems you seem to be creating output K files at a rate of close to 90 per second with 'deferred writing' disabled, * and close to twice that when it's enabled.  K You'd have difficulty doing that with truly synchronous disk access even if J each file creation/population took only a single disk access:  clearly, -oE sync is not doing what you think it's doing - quite likely, it may be K controlling deferring of writes to the files, but isn't affecting deferrals * of creation (directory) operations at all.  I 20 years ago (about the most recently I've used VMS), there was no way to J defer directory operations at all - and for a file creation, you've got atI least a single write to enter the name, plus file header allocation, plus L the header update for the creation, plus the header update after the data isC written, plus the data write itself (and that's if there's no other G bookkeeping such as the high-water-mark maintenance already mentioned). K Only the last of these is likely affected by specifying -o sync to Red Hat: H everything else is likely asynchronous, and if you're dumping many filesI into the same directories a lot of those asynchronous writes will also be 
 coalesced.  I David Mathog's tests point out differences like this, and others as well. F VMS started out with a significantly different attitude toward on-diskK consistency than Unix did, and clustering only intensified it (because with E Unix, you can try to fix up a potentially inconsistent file system on L restart, at the cost of a potentially lengthy analysis, whereas with VMS theH file system must be left in an internally consistent state all the time,J since other nodes may continue processing it even if one node fails in the middle of an operation).  B It's possible that VMS has changed enough lately to make the above= observations inaccurate, so take them for what they're worth.    - bill   ------------------------------  % Date: Sat, 15 May 2004 07:58:34 -0700 # From: "Tom Linden" <tom@kednos.com> & Subject: Reboot forces Shadowset Merge9 Message-ID: <NDEMLKKEBOIFBMJLCECIMEBKDEAA.tom@kednos.com>   9 I have three shadow sets on a BA356 attached to two nodes < (7.3 and 7.3-1 alphas) If I shutdown and reboot another node8 in the cluster it causes a merge operation on the shadowA sets, which takes 24 hours!  (74GB disks and bandwidth on BA3565)   " the shutdown command I ma using isE   SHUTDOWN == "@SYS$SYSTEM:SHUTDOWN 0 SHUTDOWN YES YES LATER NO NONE"   = Now if I manually dismount the shadow sets from the node I am A shutting down, then this doesn't happen, but in order to do that, , I have to stop the queue manager (open file)   Any suggestions? --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004   ------------------------------  % Date: Sat, 15 May 2004 03:59:06 -0400 * From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: Terry Shannon's "HP: Two Years Post-Merger Presentation" 2 Message-ID: <AL6dnckdK7I1UDjdRVn-ug@metrocast.net>  7 "Paul Sture" <nospam@sture.homeip.net> wrote in message $ news:2gh8c7F2ppi0U1@uni-berlin.de...J > As reported by The Inquirer at http://www.theinquirer.net/?article=158798 > Terry Shannon's has a presentation up in PDF format at > C > http://www.shannonknowshpc.com/stories.php?story=04/05/12/7726404   I Well, Terry's bullshit doesn't improve with age - nor even seem to change L much (which makes it tiring as well as disgusting).  But the passage of timeH does change one aspect, since it's now full of provable lies rather than4 simply unsupportable and highly dubious projections.  E I mean, aside from the old falsehoods regarding Alpha's potential vs. A Itanic's, on page 16 we see current Itanic performance graphed as J dramatically higher than x86 performance, whereas in fact x86 out-performsJ today's best Itanics by significant margins save in cases where no one hasK bothered to create a competitive x86 *system* architecture and hence Itanic I forges ahead in some MP environments.  And the first bullet on page 28 is L simply a lie:  in fact, Opteron matches or exceeds Itanic's best performanceC today in most apples-to-apples match-ups - often without even using I Opteron's 64-bit capabilities (which add noticeably to its performance in  most cases).  J And then there's the 'OLTP performance' graph on page 35 - marketecture atL its finest, without a hint of underlying reality.  The near-doubling of OLTPL performance this year presumably assumes that doubling Superdome's CPU countE will nearly double performance - a most dubious projection given that : Superdome's performance limits seem to be at least as muchG system-architecture-related as processor-count-related.  The additional H more-than-doubling projected by mid-2005 must be what Terry expects fromK Montecito, despite Intel's current experience that moving Pentium to 90 nm. H has allowed neither any increase in clock rate nor any decrease in powerH consumption, circumstances which would keep Montecito from providing any performance increase *at all*.  L It's simply not worth picking apart this garbage in finer detail, especiallyK since I've done so before in its previous incarnations.  But it remains, of J course, entirely consistent with the past decade-plus:  Itanic enthusiastsJ have always been forced to sell future projections rather than present-dayH achievements.  And, true to form, at the end of the presentation Terry'sH selling a new HP server architecture for 2007 which may finally catch upG with what EV7 (and in smaller form Opteron) offered over a year ago and J POWER4 offered in late 2001.  Even if such a system does achieve 5 millionL tpmC in 2007, this won't be particularly impressive:  POWER5 is on course toH exceed 2 million tpmC *this* year, as soon as clock rates match those ofK POWER4+ and the 64-processor system is released, and by the time 2007 rolls H around HP will be competing with POWER6 and its new system architecture.  G The Big Lie is clearly still alive and well at HP, and Terry spreads it F around as blatantly as ever.  His predictions for Itanic's rosy futureH remind me very much of the current administration's projections for IraqL (until very recently, anyway), and likely will be accepted by the same kindsC of people inclined to accept Bush's flagrant abuses of the truth so K uncritically.  Terry and HP would very much like people to pay no attention L to the man behind the curtain - the increasing skepticism in the trade pressJ that Itanic can ever be more than a high-priced, low-volume niche product,A especially given the recent adoption by Intel of AMD's 64-bit x86 L architecture (and an architecture it truly is:  attempting to pass it off asJ mere 'extensions' that somehow don't *really* make it a 64-bit platform isK just more bluster on the part of those who have nothing more substantial to  offer).   J Given how badly HP (and Compaq before it) have screwed up their enterpriseD system business, it's at least as likely that it will be approachingI decrepitude by 2007 as that it will enjoy the leadership position that HP J and their lapdogs keep trying to sell to the world.  Time will, of course,H eventually tell, just as it has so far largely validated the projectionsL that some of us laid out 3 years ago when Alpha was axed so unceremoniously,? and that flacks like Terry would so much like people to forget.   J "HP has delivered on its promises" - right, just like Bush has:  they bothJ just change them as frequently as necessary to match unfolding events, andL hope that no one is paying sufficient attention to notice.  And indeed, some: people aren't - and thus completely deserve what they get.   - bill   ------------------------------  % Date: Sat, 15 May 2004 13:42:48 +0200 * From: "Karsten Nyblad" <nospam@nospam.com>E Subject: Re: Terry Shannon's "HP: Two Years Post-Merger Presentation" - Message-ID: <c84vo0$17qh$1@news.cybercity.dk>   5 "Bill Todd" <billtodd@metrocast.net> wrote in message , news:AL6dnckdK7I1UDjdRVn-ug@metrocast.net... >  [...]    Bill,   I I agree with you except for one detail.  The Inquirer had an article that I they had talked to a guy testing Nocona said that its performance sucked. J If this is true, the it could influence which architecture succeeds in theL Windows and Linux market.  There are many that will not buy AMD, and if theyI want a 64-bit machine then might buy an Itanic even if they get more bang  for the buck by AMD.   Karsten Nyblad ibpit1202 at sneakemail dot com    ------------------------------   Date: 15 May 2004 07:42:54 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>; Subject: Re: VMS Linker Question - multiple defined symbols ? Message-ID: <DTiotGxQ0bj6-pn2-ICwSmprMd3Xq@dave2_os2.home.ours>   B On Wed, 12 May 2004 17:22:44 UTC, "Jakob Erber" <erberj@yahoo.de>  wrote:   > Hello, > 3 > could somebody please help me with this question:  > K > I need to link a process which is using DCE and SSL at the same time. The M > problem is, that the shareables of both products define the function CRYPT, < > which results in a multiple defined symbol linker warning. > H > Knowing, that we need no DCE SSL features, this would not be much of aM > problem, an interactive program works fine despite of this warning (we link F > so that the Symbol CRYPT is first found in the SSL shared lib by the
 > linker). > G > But if we want to build our program in a shareable itself and load it N > dynamicly to another programm, it results in a dynamic load problem (key not > found in tree).  > L > So we strongly suspect, that we have to get rid of the linker warning. HowL > can we direkt the linker to use the symbol in the SSL library and not warn, > about the CRYPT symbol in the DCE library? > ( > I hope one can understand what I mean. >  > best regards >  > Jakob    Jakob ?               do you just link against libraries with /LIB and  @ allow/require the linker to search for modules that resolve its > symbols or do you grab the required modules the with /INCLUDE F qualifier. The latter allows you to pick and choose which modules come3 from which libraries (but you probably knew that).    B However, that will only resolve the problem as long as the global F symbol CRYPT is defined in a single module in each library. What that F means is : if each library has an object module CRYPT containing only B the symbol CRYPT, you can direct the linker to choose the desired A module from the relevant library. The symbol is resolved for the  E linker and it should have no reason to go looking/finding the module  E in the other library and getting confused.  On the other hand If the  D symbol CRYPT is defined within object modules in both libraries and F both _modules_ are rquired to satisfy the linker, then, I believe, the warning is unavoidable. e.g.   Case 1    B A_LIB and B_LIB contain Object module CRYPT with only that global  symbol then     	link my_obj+a_lib /inc=CRYPT or 	link my_obj+b_lib /inc=CRYPT   ' I wouldn't expect  any warning message.    Case 2  E However, if A_LIB ontains a module C_OBJ containg ROUT_A, ROUT_B and  F CRYPT and B_LIB contains a module D_OBJ containing ROUT_C, ROUT_D and E CRYPT then if you need ROUT_A and ROUT_C, the warning is unavoidable  D because the linker, understandably, will be confused. It needs both D C_OBJ and D_OBJ, to resolve ROUT_A and ROUT_C, but each one defines  the symbol CRYPT.    Hope this helps a little.    --   Cheers - Dave.   ------------------------------  % Date: Sat, 15 May 2004 05:10:31 -0400 * From: "Bill Todd" <billtodd@metrocast.net>A Subject: Re: [General]: Understanding 'Mean Time Between Failure' 2 Message-ID: <97idnWacZrz5QzjdRVn-jA@metrocast.net>  . "John Smith" <a@nonymous.com> wrote in message& news:oaudnS7z1f68YjndRVn-vw@igs.net...> > http://itmanagement.earthweb.com/columns/article.php/3354191 > + > Understanding 'Mean Time Between Failure'  > By George Spafford > May 14, 2004 > I > Mean Time Between Failure (MTBF) is a much-used management metric in IT  both5 > for discrete components as well as overall systems.  > I > For simplicity, let's define MTBF as the average time between failures.   G Oh, well - about the level of technical accuracy you can expect from an K industry rag:  higher-management-level at best, just plain wrong at worst..   H MTBF does not predict how long an average component will last:  'serviceH life' is what you go by for that.  MTBF predicts how likely a failure is% *within* that specified service life.   J For example, if a modern disk has a 1,000,000 hour MTBF (somewhat over 100E years), but a 5-year service life, then if you use 100 of these disks H (replacing each before the end of its service life) you should get a bit9 less than one disk failure per year for the entire batch.   E Under the environmental conditions specified by the manufacturer.  As H someone else noted, go outside those conditions (e.g., in temperature orK vibration), and failure rates may rise dramatically.  Or if you encounter a H bug in the disk's firmware, well, the manufacturer didn't test for that.> MTBF is real, but only within the limits used to determine it.  G The author managed to blur the distinctions between fault-tolerance and J availability as well.  The former describes a system that will continue toH function *correctly* after experiencing a fault, while the latter simplyK describes the likelihood that the system will continue to run (but actually E says nothing about the likelihood of correctness - that's a different,K metric).  So true fault-tolerance (which no VMS system has had since VAXft, C but Tandem of course *does* provide) can increase availability, but-@ clustering can't provide fault-tolerance (though it does provideK availability) because it doesn't detect stealthy faults that leave the nodeg running (albeit incorrectly).    - bill   ------------------------------  % Date: Sat, 15 May 2004 05:57:22 -0700 # From: "Tom Linden" <tom@kednos.com>wA Subject: RE: [General]: Understanding 'Mean Time Between Failure't9 Message-ID: <NDEMLKKEBOIFBMJLCECIIEBIDEAA.tom@kednos.com>t     -----Original Message-----1   From: Bill Todd [mailto:billtodd@metrocast.net]n&   Sent: Saturday, May 15, 2004 2:11 AM   To: Info-VAX@Mvb.Saic.ComTC   Subject: Re: [General]: Understanding 'Mean Time Between Failure'-      0   "John Smith" <a@nonymous.com> wrote in message(   news:oaudnS7z1f68YjndRVn-vw@igs.net...@   > http://itmanagement.earthweb.com/columns/article.php/3354191   > -   > Understanding 'Mean Time Between Failure'    > By George Spafford   > May 14, 2004   >rK   > Mean Time Between Failure (MTBF) is a much-used management metric in ITh   both7   > for discrete components as well as overall systems.T   > K   > For simplicity, let's define MTBF as the average time between failures.h  I   Oh, well - about the level of technical accuracy you can expect from anmB   industry rag:  higher-management-level at best, just plain wrong   at worst..  J   MTBF does not predict how long an average component will last:  'serviceJ   life' is what you go by for that.  MTBF predicts how likely a failure is'   *within* that specified service life.l  L   For example, if a modern disk has a 1,000,000 hour MTBF (somewhat over 100G   years), but a 5-year service life, then if you use 100 of these diskslJ   (replacing each before the end of its service life) you should get a bit;   less than one disk failure per year for the entire batch.T  G   Under the environmental conditions specified by the manufacturer.  AsvJ   someone else noted, go outside those conditions (e.g., in temperature orA   vibration), and failure rates may rise dramatically.  Or if youn
   encounter aXJ   bug in the disk's firmware, well, the manufacturer didn't test for that.@   MTBF is real, but only within the limits used to determine it.  I   The author managed to blur the distinctions between fault-tolerance andeL   availability as well.  The former describes a system that will continue toJ   function *correctly* after experiencing a fault, while the latter simply?   describes the likelihood that the system will continue to runc   (but actuallyeG   says nothing about the likelihood of correctness - that's a differente@   metric).  So true fault-tolerance (which no VMS system has had   since VAXft,E   but Tandem of course *does* provide) can increase availability, butwB   clustering can't provide fault-tolerance (though it does provide>   availability) because it doesn't detect stealthy faults that   leave the node   running (albeit incorrectly).   # Availability = MTBF / (MTBF + MTTR)d MTTR := Mean Time To Repair.     - bill         ---M(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004   ---y& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.667 / Virus Database: 429 - Release Date: 4/23/2004   ------------------------------   End of INFO-VAX 2004.269 ************************