1 INFO-VAX	Thu, 26 Aug 2004	Volume 2004 : Issue 472       Contents:> Re: 450  %TCPIP-E-SMTP_NOSUCHUSER, no such user, <domain.name>> Re: 450  %TCPIP-E-SMTP_NOSUCHUSER, no such user, <domain.name>! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ??? ! Re: A whopping 50 percent...  ???  CSWS and jserv problems 3 Re: CSWS v2.0 & CSWS_PHP v1.2 - "php4_module" error 3 Re: CSWS v2.0 & CSWS_PHP v1.2 - "php4_module" error & DCPS, PRINT /HEADER and /PARA=DATA=PCL* Re: DCPS, PRINT /HEADER and /PARA=DATA=PCL Divide instruction in IA64 Re: Divide instruction in IA64 Re: Divide instruction in IA64 Re: Divide instruction in IA64 Re: Divide instruction in IA64 RE: Divide instruction in IA64D Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 usersD RE: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 usersD Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 usersD Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 usersD Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 usersD Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 users GCC for OpenVMS/VAX?, Re: How can I monitor VMS from Windows/Linux, Re: How can I monitor VMS from Windows/Linux, Re: How can I monitor VMS from Windows/Linux Re: HPworld - I Survived Re: HPworld - I Survived Re: HPworld - I Survived Re: HPworld - I Survived Re: HPworld - I Survived# Re: Looking for VMS experts opinion  Re: OpenVMS Wikipedia entry   Preparing for HP Tech Forum 2005 Re: Re, Re : set prompt  Re: Re, Re : set prompt  Re: Re, Re : set prompt % Re: Shadow Merge is Killing Me - help K Re: SKHPC's Latest Take on IPF and Post-Superdome Technology From HP  World K Re: SKHPC's Latest Take on IPF and Post-Superdome Technology From HP  World  Re: Whither RAID?  Re: Whither RAID?  Re: Whither RAID?  Re: Whither RAID?   F ----------------------------------------------------------------------  + Date: Wed, 25 Aug 2004 13:52:36 -0500 (CDT)  From: sms@antinode.orgG Subject: Re: 450  %TCPIP-E-SMTP_NOSUCHUSER, no such user, <domain.name> ) Message-ID: <04082513523432@antinode.org>   4 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)  ^ > In article <4122810A.99D24114@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  =    Hmmm.  Either Info-VAX or I must have missed this posting.   = > >> 450  %TCPIP-E-SMTP_NOSUCHUSER, no such user, domain.name   Q > > This is a very misleading message. What it really means is that it didn't get Q > > a 200 message after a RCPT TO command. But unfortunatly, it doesn not provide H > > you with the error message as reported by the receiving SMTP server.      Apparently.  S > > You need to enable logging and check the smtp logs for each individual message.       Did that.  Saw:  @ recv buf=450 <<lame_user>@<lame.domain.name>>: Recipient address5 rejected: Server is Busy please try again later\0d\0a   D    I gather that code 450 translates (generically) to something likeA "Requested mail action not taken: mailbox unavailable", where the D leading "4" suggests that it is a temporary failure.  I'd've guessedE that this sort of thing should cause the message to be re-queued, but 
 I'm ignorant.   G    I'll just add this to my (ever-growing) list of complaints about the E TCPIP SMTP server, along with the too-small (16) limit on SET SERVICE E xxxx /REJECT hosts and networks, and the lack of any convenient hooks @ for user-supplied junk-e-mail handling.  (If China and Korea hadG contiguous IP address ranges, that would help on the /REJECT limit, but " more than 16 would still be nice.)  3    Thanks for the helpful suggestions, irregardful.   H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode.org     Saint Paul  MN  55105-2547    ------------------------------  % Date: Wed, 25 Aug 2004 16:17:24 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> G Subject: Re: 450  %TCPIP-E-SMTP_NOSUCHUSER, no such user, <domain.name> , Message-ID: <412CF3C4.BCBD14D4@teksavvy.com>   sms@antinode.org wrote: B > recv buf=450 <<lame_user>@<lame.domain.name>>: Recipient address7 > rejected: Server is Busy please try again later\0d\0a  > F >    I gather that code 450 translates (generically) to something like9 > "Requested mail action not taken: mailbox unavailable",     I Many servers are now configured to reject messages coming from an unknown I sender this way. The sending server will then retry within 30 minutes, at M which point the receiving server will accept the message. This avoids much of ; the spam which does not retry delivery after such messages.   N Omce the receiving SMTP server knows you, it will accept messages on first try
 from then on.    ------------------------------    Date: 25 Aug 2004 13:40:48 -05004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)* Subject: Re: A whopping 50 percent...  ???3 Message-ID: <PXpW0XseP6N$@eisner.encompasserve.org>   R In article <f5OdnfGD0pAgB7XcRVn-gw@igs.net>, "John Smith" <a@nonymous.com> writes:F > The problem with Digital/Compaq/HP's approach in suggesting that VMSI > customers move to unix, Windows, or Linux is that none of these options M > provide as high a profit margin to the vendor nor do they necessarily offer L > a better overall value proposition (security, stability, scalability, ease; > of programming, operating costs, etc...) to the customer.   I And once you leave VMS for any flavor of "open" systems, you're one short H hop away from leaving DEC/Q/HP for some other vendor. Until IBM, Sun, orJ DELL start offering VMS servers, HP is better off keeping VMS users on VMSG rather than even giving them the chance to migrate elsewhere, much less  encouraging them to do so.  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf L     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  O  Save Model Rocketry from the HSA!   http://www.space-rockets.com/congress.html    ------------------------------  % Date: Wed, 25 Aug 2004 15:03:15 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> * Subject: Re: A whopping 50 percent...  ???, Message-ID: <412CE268.8F14CEFB@teksavvy.com>   Bob Kaplow wrote: L > DELL start offering VMS servers, HP is better off keeping VMS users on VMSI > rather than even giving them the chance to migrate elsewhere, much less  > encouraging them to do so.  G But you see, HP isn't actively encouraging customers to migrate to Unix & anymore (remember the Stallard memo ?)  ? So from HP's point of view, they are doing nothing to harm VMS.   I The problem is that HP is allowing previous serious injuries inflicted by H Palmer and Curly to take their course. In essence, they are allowing theJ ghosts of previous owners to do the dirty worlk so HP can claim innocence.  K When HP announced it would continue Compaq's policies on VMS, (followed the N next day by Stallard's memo which have some 9 months to be carefully crafted),L it became clear that HP wasn't about to stop the decline of VMS and leverage its full commercial potential.  M Remmeber that prior to the Sept 7 announcement, Carly and Curly had carefully M planned all product merger issues, and they were bragging about it throughout L the merger pregnancy. So they would have known exactly what VMS's fate would. have been at the time Stallard wrote his memo.  M Fact is that if HP had really wanted to fully leverage its investment in VMS, L it would have taken certain token actions to ensure that customers knew thatM the previous management style was changed and that from now on, HP would take ( VMS very seriously. HP did none of that.    L When someone buys a failed hotel or restaurant, one of the first things theyW do is put up a sign "under new management" to indicate that things will change/improve.   K The first thing HP did was posted a sign stating "no changes to management, P we'll continue the same policies that caused the failure of Digital and Compaq".   ------------------------------  % Date: Wed, 25 Aug 2004 21:28:27 +0200   From: "Dr. Dweeb" <dr@dweeb.com>* Subject: Re: A whopping 50 percent...  ???- Message-ID: <cgip8s$2f3f$1@news.cybercity.dk>    Kenneth Farmer wrote: < > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message( > news:412CB28D.30441D27@teksavvy.com... >> David Froble wrote:C >>> Regardless what anyone thinks or says, it's always about money!  >>D >> No. It is about strategy to make money. Carly wants to be seen asC >> taking the right steps to please shareholders. Period. Hence the  >> "image is everything".  >>E >> If Carly tells shareholders that the future is with wintel servers D >> and that proprietary systems such as VMS have no future, then sheF >> will be expected to take steps to move VMS customers over to wintel
 >> customers.  >>D >> The problem with folks like Carly is that power has gone to theirE >> heads and they are using their industry leadership position to try E >> to set trends. This si where there is a huge difference bewteen HP  >> and IBM.  >>G >> IBM doesn't really attenpt to predict a single technological future. > >> They leave doors opened without jeoperdizing their existingD >> business. Their Linux strategy is a good example. HP on the other@ >> hand wants to be seen as the oracle of the IT world, with theG >> ability to predict a single very precise future and it then bets all ( >> its eggs into that prediction basket. >>E >> Sun isn't putting all its eggs into Opteron. It is edging its bets . >> by going to Opteron and staying with Sparc. >>E >> But in the end, it is Carly that makes the most noise about the IT D >> industry's future and she is listened to by the wall stree casinoG >> analysts who are impressed with her leadership skills. Carly's hopes A >> is that if she repeats her predictions often enough, they will  >> actually happen.  >>@ >> Problem is that the wall street analysts have only short termE >> memories. If they went back to the pre-merced promises about IA64, C >> they'd see just how wrong Carly and Curly were and how IA64 will C >> never be an "industry standard" commodity item. If they realised G >> that, they would they take Carly,s newer predictions with a grain of ? >> salt and Carly would lose much credibility and would then be F >> required to make HP perform now instead of living on predictions of >> the future. >  > G > Funny, some of you guys seem to pratice the same repeat-repeat-repeat  > philosophy here. > 3 > "...IA64 will never be an "industry standard"..."  > > > That's a bold statement.  What's the definition of "industry > standard" this week anyway.  >   J "Industry Standard" is not a standard term, however we all know it when weC see it.  Intel rarely uses Industry Standard and Itanic in the same J sentence, and usually avoids calling the Itanic chip Industry Standard.  IG doubt whether Intel believe it will be so any more than the rest of us.   
 Dr. Dweeb.   > Ken 
 > OpenVMS.org  >  > ________________________$ > Kenneth R. Farmer <>< 336-736-7376& > SpyderByte: http://www.SpydeByte.com   ------------------------------  % Date: Wed, 25 Aug 2004 21:56:04 -0400 * From: "Bill Todd" <billtodd@metrocast.net>* Subject: Re: A whopping 50 percent...  ???= Message-ID: <J5idncMBM4F137DcRVn-sw@metrocastcablevision.com>   A "Kenneth Farmer" <kfarmer@NOSPAM.spyderbyte.com> wrote in message 6 news:Cy2Xc.1350$LH6.149796@twister.southeast.rr.com...   ...   G > Funny, some of you guys seem to pratice the same repeat-repeat-repeat  > philosophy here. > 3 > "...IA64 will never be an "industry standard"..."  >  > That's a bold statement.  I Indeed it is.  The future is hard to predict even when you understand the I situation quite well (as we did back when Alpha was killed, for example).   K Whether Intel will be able to make Itanic into an industry standard if it's I willing to forge ahead for the next 3 years with a mediocre product until K the Alpha team has Tukwila ready is hardly predictable by anyone who is not I privy to the details of exactly how the Tukwila work is progressing:  the I Alpha team can probably make this sow's ear into a silk purse *if* anyone 2 can, but there is no proof yet that even they can.  3   What's the definition of "industry standard" this  > week anyway.  J 'Not Itanic', at least for purposes of the current discussion.  As someoneK else noted, Intel does *not* use that term to describe Itanic:  only flacks 0 like Terry do (and HP has a lot of such flacks).   - bill   ------------------------------  % Date: Wed, 25 Aug 2004 21:30:33 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>* Subject: Re: A whopping 50 percent...  ???+ Message-ID: <412D4B49.E728F4AE@comcast.net>    JF Mezei wrote:  >  > Bob Kaplow wrote: N > > DELL start offering VMS servers, HP is better off keeping VMS users on VMSK > > rather than even giving them the chance to migrate elsewhere, much less  > > encouraging them to do so. > I > But you see, HP isn't actively encouraging customers to migrate to Unix ( > anymore (remember the Stallard memo ?) > A > So from HP's point of view, they are doing nothing to harm VMS.   E What they don't realize is they are doing nothing to help it, either. / (Don't start in about IA64 - read on, instead.)   K > The problem is that HP is allowing previous serious injuries inflicted by J > Palmer and Curly to take their course. In essence, they are allowing theL > ghosts of previous owners to do the dirty worlk so HP can claim innocence.  F They'll more likely be accused of negligence, in so far as that can be
 applied here.   M > When HP announced it would continue Compaq's policies on VMS, (followed the P > next day by Stallard's memo which have some 9 months to be carefully crafted),N > it became clear that HP wasn't about to stop the decline of VMS and leverage  > its full commercial potential.  D That just totally dumbfounding - I can think of nothing to say aboutE that, but I know there must be SOMEthing that SHOULD be said, even if E it's only a string expletives long enough to choke even DCL's new 8KB 
 buffer sizes!   O > Remmeber that prior to the Sept 7 announcement, Carly and Curly had carefully O > planned all product merger issues, and they were bragging about it throughout N > the merger pregnancy. So they would have known exactly what VMS's fate would0 > have been at the time Stallard wrote his memo. > O > Fact is that if HP had really wanted to fully leverage its investment in VMS, N > it would have taken certain token actions to ensure that customers knew thatO > the previous management style was changed and that from now on, HP would take * > VMS very seriously. HP did none of that.  B ...which stands to date. Some may argue that IA64 should be a veryH string statement and response. However, a review of the truth about IA64" does not support such a statement.  N > When someone buys a failed hotel or restaurant, one of the first things theyY > do is put up a sign "under new management" to indicate that things will change/improve.  > M > The first thing HP did was posted a sign stating "no changes to management, R > we'll continue the same policies that caused the failure of Digital and Compaq".  G It is often argued that VMS is in a "Sony Beta"-like state because "the $ best technology doesn't always win".  A Rather than applying that to VMS, we should perhaps apply that to B Itanic, go through the grieving period, then swallow our pride andG embrace IA32 (the present as well as the recent past of EDP) and x86-64 D (the future of EDP). We have nothing to lose that we haven't already; lost, and everything (profits, market share, etc.) to gain.    D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 21:34:41 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>* Subject: Re: A whopping 50 percent...  ???+ Message-ID: <412D4C41.383A3F84@comcast.net>    Kenneth Farmer wrote:  > < > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message( > news:412CB28D.30441D27@teksavvy.com... > > David Froble wrote: E > > > Regardless what anyone thinks or says, it's always about money!  > > L > > No. It is about strategy to make money. Carly wants to be seen as taking > the C > > right steps to please shareholders. Period. Hence the "image is  > everything". > > J > > If Carly tells shareholders that the future is with wintel servers and > thatM > > proprietary systems such as VMS have no future, then she will be expected  > to> > > take steps to move VMS customers over to wintel customers. > > K > > The problem with folks like Carly is that power has gone to their heads  > and K > > they are using their industry leadership position to try to set trends.  > This; > > si where there is a huge difference bewteen HP and IBM.  > > N > > IBM doesn't really attenpt to predict a single technological future.  TheyJ > > leave doors opened without jeoperdizing their existing business. Their > Linux L > > strategy is a good example. HP on the other hand wants to be seen as theM > > oracle of the IT world, with the ability to predict a single very precise E > > future and it then bets all its eggs into that prediction basket.  > > I > > Sun isn't putting all its eggs into Opteron. It is edging its bets by 
 > going to# > > Opteron and staying with Sparc.  > > F > > But in the end, it is Carly that makes the most noise about the IT > industry'sK > > future and she is listened to by the wall stree casino analysts who are N > > impressed with her leadership skills. Carly's hopes is that if she repeats > her 8 > > predictions often enough, they will actually happen. > > N > > Problem is that the wall street analysts have only short term memories. IfM > > they went back to the pre-merced promises about IA64, they'd see just how F > > wrong Carly and Curly were and how IA64 will never be an "industry > standard" M > > commodity item. If they realised that, they would they take Carly,s newer N > > predictions with a grain of salt and Carly would lose much credibility andF > > would then be required to make HP perform now instead of living on
 > predictions  > > of the future. > G > Funny, some of you guys seem to pratice the same repeat-repeat-repeat  > philosophy here. > 3 > "...IA64 will never be an "industry standard"..."  > M > That's a bold statement.  What's the definition of "industry standard" this  > week anyway.  D That same as it's always been: a specification negotiated through anE internationally recognized body that is then published so that anyone % can manfacture to that specification.   H Unfortunately, too many people see as "industry standard" that which is,= in fact, de-facto standard (widely used, but not a negotiated G specification; quite often, its actually a M$ dictate, not a "standard"  at all).   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 22:41:17 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> * Subject: Re: A whopping 50 percent...  ???, Message-ID: <412D4DC8.32EA6E34@teksavvy.com>   David J Dachtera wrote: C > Rather than applying that to VMS, we should perhaps apply that to D > Itanic, go through the grieving period, then swallow our pride andI > embrace IA32 (the present as well as the recent past of EDP) and x86-64  > (the future of EDP).    D At this point in time, with Opterons already appearing is mail orderM magazines, it seems to me that the industry standard will very quickly switch N from the 32 bit 8086 to the 64 bit 8086. With this in mind, porting VSM to the4 32 bit 8086 would be a waste of time and resources.   L Porting it to the 64 bit 8086 would be a really wise move , especially sicneK it would allow VMS to be sold and marketed along with Linux and Solaris and M Windows etc. It woudl truly run on commodity and industry standard platforms.    ------------------------------  % Date: Wed, 25 Aug 2004 21:43:21 -0400 ( From: David Froble <davef@tsoft-inc.com>* Subject: Re: A whopping 50 percent...  ???, Message-ID: <412D4039.3020004@tsoft-inc.com>   Kenneth Farmer wrote:   < > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message( > news:412CB28D.30441D27@teksavvy.com... >  >>David Froble wrote:  >>B >>>Regardless what anyone thinks or says, it's always about money! >>> J >>No. It is about strategy to make money. Carly wants to be seen as taking >> > the  > A >>right steps to please shareholders. Period. Hence the "image is  >> > everything". > H >>If Carly tells shareholders that the future is with wintel servers and >> > that > K >>proprietary systems such as VMS have no future, then she will be expected  >> > to > < >>take steps to move VMS customers over to wintel customers. >>I >>The problem with folks like Carly is that power has gone to their heads  >> > and  > I >>they are using their industry leadership position to try to set trends.  >> > This > 9 >>si where there is a huge difference bewteen HP and IBM.  >>L >>IBM doesn't really attenpt to predict a single technological future.  TheyH >>leave doors opened without jeoperdizing their existing business. Their >> > Linux  > J >>strategy is a good example. HP on the other hand wants to be seen as theK >>oracle of the IT world, with the ability to predict a single very precise C >>future and it then bets all its eggs into that prediction basket.  >>G >>Sun isn't putting all its eggs into Opteron. It is edging its bets by  >>
 > going to > ! >>Opteron and staying with Sparc.  >>D >>But in the end, it is Carly that makes the most noise about the IT >> > industry's > I >>future and she is listened to by the wall stree casino analysts who are L >>impressed with her leadership skills. Carly's hopes is that if she repeats >> > her  > 6 >>predictions often enough, they will actually happen. >>L >>Problem is that the wall street analysts have only short term memories. IfK >>they went back to the pre-merced promises about IA64, they'd see just how D >>wrong Carly and Curly were and how IA64 will never be an "industry >> > standard"  > K >>commodity item. If they realised that, they would they take Carly,s newer L >>predictions with a grain of salt and Carly would lose much credibility andD >>would then be required to make HP perform now instead of living on >>
 > predictions  >  >>of the future. >> >  > G > Funny, some of you guys seem to pratice the same repeat-repeat-repeat  > philosophy here.    O At some time claims and firings will not be enough.  If HP doesn't prosper, as  ? in 'make money', everyone will understand that they are losers.     3 > "...IA64 will never be an "industry standard"..."  > M > That's a bold statement.  What's the definition of "industry standard" this  > week anyway.    I Well, what allowed people to call IA-32/x86/whatever you want to call it  L "industry standard"?  It was selling enough that everyone else's sales were L minor to not worth considering.  Intel itself has backed off on IA-64 being G 'everywhere'.  Intel itself has given up on what made x86 an "industry  + standard".  Who are we to argue with Intel?     . What's your definition of "industry standard"?     Dave     --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 25 Aug 2004 20:30:23 -0700& From: jwparker@sfasu.edu (John Parker)  Subject: CSWS and jserv problems= Message-ID: <229a787c.0408251930.3dcf5bd3@posting.google.com>    OpenVMS 7.3  CSWS 1.2 ApacheJserv/1.1   5 I see the following errors in my mod_jserv.log.  I am 6 using the default settings for jserv.  Can anyone tell6 me what's going on here and what I can do to keep this8 from happening?  We are in the middle of a time when the5 use of jserv spikes quite a bit higher than normal.     7 Could this also be a result of some kind of attack?  If 7 so how can I determine where the attack is coming from?     % [25/08/2004 17:30:58:385] (EMERGENCY) , ajp12[1]: cannot scan servlet headers  (500)  ! [25/08/2004 17:30:58:437] (ERROR) 8 an error returned handling request via protocol "ajpv12"  % [25/08/2004 17:30:59:080] (EMERGENCY) - ajp12: can not connect to host 127.0.0.1:8007   % [25/08/2004 17:30:59:126] (EMERGENCY)  ajp12: connection fail     Thanks,    John   ------------------------------   Date: 25 AUG 2004 16:54:35 GMT4 From: karcher@thuria.waisman.wisc.edu (Carl Karcher)< Subject: Re: CSWS v2.0 & CSWS_PHP v1.2 - "php4_module" error6 Message-ID: <25AUG04.16543546@thuria.waisman.wisc.edu>  L In a previous article, Chuck Chopp <ChuckChopp@_removeme_rtfmcsi.com> wrote:L ->I have OpenVMS Alpha v7.3-1 with all of the current patches applied to it E ->for use with JDK v1.4.2, CSWS v2.0, CSWS_PHP v1.2 & CSWS_JAVA v2.1.  ->  + ->When I try to shutdown Apache as follows:  ->   ->@SYS$STARTUP:APACHE$SHUTDOWN ->   ->I get the following error: ->  ; ->Syntax error on line 5 of /apache$root/conf/mod_php.conf: : ->Can't locate API module structure `php4_module' in file N ->/apache$root/000000/modules/mod_php_apache-2_0.exe: function not implemented ->    A Same here. Same config except for CSWS_JAVA (I don't have it). It F doesn't always happen but the longer apache runs the more likely it is9 to happen. After I comment that line out of mod_php.conf, ( @apache@shutdown again it will shutdown.   --G -- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison 9 --                  karcher.nomorespxm@waisman.wisc.edu      ------------------------------  % Date: Wed, 25 Aug 2004 16:36:04 -0400 * From: Chuck Chopp <ChuckChopp@rtfmcsi.com>< Subject: Re: CSWS v2.0 & CSWS_PHP v1.2 - "php4_module" error9 Message-ID: <1K6Xc.24780$0o5.9460@bignews1.bellsouth.net>    Carl Karcher wrote:   C > Same here. Same config except for CSWS_JAVA (I don't have it). It H > doesn't always happen but the longer apache runs the more likely it is; > to happen. After I comment that line out of mod_php.conf, * > @apache@shutdown again it will shutdown.  K Commenting out the line in the configuration file was going to be the next   thing I wanted to ask about.  J What is the significance of commmenting out this line?  Will it result in 0 disabling some portion of the PHP functionality?     --   Chuck Chopp   8 ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com  @ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax Greer, SC  29651  , Do not send me unsolicited commercial email.   ------------------------------  % Date: Wed, 25 Aug 2004 15:47:37 -0400 & From: David M Smith <dsmit115@csc.com>/ Subject: DCPS, PRINT /HEADER and /PARA=DATA=PCL 8 Message-ID: <h0rpi0d90ctg7ms2slueuvlqc9g3cg6gdd@4ax.com>  J One of the system managers in our company has just reported to me that hisO attempt to use /HEADER on a PRINT command to a DCPS print queue, in combination P with /PARAMETER=DATA_TYPE=PCL, results in no errors, but also no heading line. IK am trying to determine if this is a bug or a feature and, if a bug, whether  there is a fix or workaround.   N I did find in the DCPS User's Guide, Appendix B (which lists all PRINT command qualifiers) the statement:  N Several qualifiers apply only to print jobs for ANSI files; if you supply thisJ type of qualifier on a PRINT command line for printing non-ANSI files, the- qualifier is ignored and the file is printed.   N However, the qualifiers are not marked in any way, so I don't know for certainN to which qualifiers this applies and exactly what is mean by "ANSI files" -- IJ assume that means a file submitted with /PARA=DATA=ANSI, but I'm not sure.  9 Anyone here have experience with this or know the answer? I ------------------------------------------------------------------------- I David M. Smith 302.391.8533                       dsmit115 at csc dot com I Computer Sciences Corporation     (Opinions are those of the writer only) I -------------------------------------------------------------------------    ------------------------------  # Date: Wed, 25 Aug 2004 21:34:40 GMT * From: Paul Anderson <paul.anderson@hp.com>3 Subject: Re: DCPS, PRINT /HEADER and /PARA=DATA=PCL 5 Message-ID: <250820041734001208%paul.anderson@hp.com>   F In article <h0rpi0d90ctg7ms2slueuvlqc9g3cg6gdd@4ax.com>, David M Smith <dsmit115@csc.com> wrote:   C > One of the system managers in our company has just reported to me D > that his attempt to use /HEADER on a PRINT command to a DCPS printD > queue, in combination with /PARAMETER=DATA_TYPE=PCL, results in noG > errors, but also no heading line. I am trying to determine if this is = > a bug or a feature and, if a bug, whether there is a fix or 
 > workaround.   F It's intended behavior.  You can decide for yourself if it's a feature	 or a bug.   B > I did find in the DCPS User's Guide, Appendix B (which lists all* > PRINT command qualifiers) the statement: > D > Several qualifiers apply only to print jobs for ANSI files; if youD > supply this type of qualifier on a PRINT command line for printingC > non-ANSI files, the qualifier is ignored and the file is printed.  > D > However, the qualifiers are not marked in any way, so I don't knowG > for certain to which qualifiers this applies and exactly what is mean > > by "ANSI files" -- I assume that means a file submitted with$ > /PARA=DATA=ANSI, but I'm not sure.  A The DCPS ANSI translator looks at the HEADER qualifier and prints 1 headers if requested.  So yes, a job printed with C /PARAMETERS=DATA_TYPE=ANSI or equivalent (queue setting or match by G file type for example) will print with headers if /HEADER is specified.   B When your system manager printed with DATA_TYPE=PCL, he could haveC gotten either the printer's native PCL interpreter or the DCPS PCL4 ? translator.  Neither knows about the OpenVMS /HEADER qualifier.   F I don't know off the top of my head which PRINT qualifiers are ignored5 by DCPS but agree the documentation could be clearer.    Paul   --    Paul Anderson   OpenVMS Engineering    Hewlett-Packard Company    ------------------------------  % Date: Wed, 25 Aug 2004 16:12:14 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Divide instruction in IA64 , Message-ID: <412CF28F.9089FCC7@teksavvy.com>   John Reagan wrote:H > Easy.  The Itanium architecture doesn't have a divide instruction. :-)  B What sort of arguments were used to justify leaving this out of anM architecture ? Can the compilers generate aseembler instructions that will be  just as fast as a real divide ?   G I know how a division by a power of 2 is done (shift right the register M contents). But how will the IA64 compilers generate divide operations for non B base-2 divisors ? (or how do current chips perform the division ?)   ------------------------------  # Date: Wed, 25 Aug 2004 20:52:48 GMT % From: "John Vottero" <John@mvpsi.com> ' Subject: Re: Divide instruction in IA64 ; Message-ID: <A_6Xc.3326$M_.2804@newssvr16.news.prodigy.com>   ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:412CF28F.9089FCC7@teksavvy.com... > John Reagan wrote:I >> Easy.  The Itanium architecture doesn't have a divide instruction. :-)  > D > What sort of arguments were used to justify leaving this out of anM > architecture ? Can the compilers generate aseembler instructions that will   > be! > just as fast as a real divide ?  > I > I know how a division by a power of 2 is done (shift right the register L > contents). But how will the IA64 compilers generate divide operations for  > non D > base-2 divisors ? (or how do current chips perform the division ?)  L Alpha doesn't have integer divide either.  It may have been added somewhere = along the line but the 1992 Alpha Architecture Handbook says:   M Integer division does not exist as a hardware opcode. Division by a constant  
 can always be   M done via UMULH of another appropriate constant, followed by a right shift. A   subroutine can  J do general quadword division by true variables. The subroutine could test  for small divisors  M (less than about 1000 in absolute value) and for those, do a table lookup on   the exact constant  I and shift count for an UMULH/ shift sequence. For the remaining cases, a   table lookup on   K about a 1000-entry table and a multiply can give a linear approximation to % 1/ divisor that is   accurate to 16 bits.    L Using this approximation, a multiply and a back-multiply and a subtract can  generate one  J 16-bit quotient digit plus a 48-bit new partial dividend. Three more such  steps can generate the  K full quotient. Having prior knowledge of the possible sizes of the divisor n and dividend, normal-izing  M away leading bytes of zeros, and performing an early-out test can reduce the   averagev  I number of multiplies to about five (compared to a best case of one and a p worst case of nine).   ------------------------------  + Date: Wed, 25 Aug 2004 21:10:26 +0000 (UTC) % From: Dan Foster <usenet@evilphb.org>i' Subject: Re: Divide instruction in IA64n6 Message-ID: <slrnciq046.uo9.usenet@gaia.roc2.gblx.net>  [ In article <412CF28F.9089FCC7@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:X > John Reagan wrote:I >> Easy.  The Itanium architecture doesn't have a divide instruction. :-)  >uD > What sort of arguments were used to justify leaving this out of anO > architecture ? Can the compilers generate aseembler instructions that will bei! > just as fast as a real divide ?d >uI > I know how a division by a power of 2 is done (shift right the registereO > contents). But how will the IA64 compilers generate divide operations for nonaD > base-2 divisors ? (or how do current chips perform the division ?)  H The 8-bit 6502 didn't have a divide instruction, but Applesoft BASIC was> able to perform integer and floating point division just fine.  E So, yes, there are methods to deal with division through other means.p  D Can split the exponent and mantissa, calculate them separately, then  recombine results, for instance.  H I don't know why Intel left out a divide instruction but I'm sure it wasE an engineering decision -- you have a finite amount of silicon space.I  C So when you're designing chips, you try to make most use of siliconeF possible... and that means stripping out instructions that aren't used as often as others.-  E Very heavy profiling of previous generation CPUs with a wide range of0F applications is often done in order to design a better next generation CPU.  G Or maybe there's a philosophical perspective -- division implemented as . a CPU instruction is often CISC-ish in nature.  G RISC instructions tend to be far simpler and more focused on primitivessG (loads, stores, etc) rather than more complex sequences encapsulated inm a single instruction.   H Lack of a divide instruction in the CPU generally means you need to do aG little more work in software to do the equivalent, but it's not an huge 	 obstacle.e  H Please don't read into this as a defense of the IA-64; I am not speakingH specifically of the IA-64, but of CPU design in general. The IA-64 is anE interesting chip, but I'm not yet sold on its commercial prospects tofF date. It's unfortunate they chose to kill off the Alpha to push IA-64.   -Dan   ------------------------------  # Date: Thu, 26 Aug 2004 00:04:53 GMTr3 From: Robert Klute <robert_klute_removethis@hp.com>n' Subject: Re: Divide instruction in IA64R8 Message-ID: <n3aqi05v1lvdi6b78s81uo4a0ju4is43dr@4ax.com>  , On Wed, 25 Aug 2004 16:12:14 -0400, JF Mezei% <jfmezei.spamnot@teksavvy.com> wrote:    >John Reagan wrote:uI >> Easy.  The Itanium architecture doesn't have a divide instruction. :-)i >oC >What sort of arguments were used to justify leaving this out of anaN >architecture ? Can the compilers generate aseembler instructions that will be  >just as fast as a real divide ? >oH >I know how a division by a power of 2 is done (shift right the registerN >contents). But how will the IA64 compilers generate divide operations for nonC >base-2 divisors ? (or how do current chips perform the division ?)i  G While my memory is too hazy to remember which ones, I do remember using-G some compilers/libraries in the distant past that did implement divides3> as shifts and subtracts for performance reasons - the register0 operations were faster than the hardware divide.   ------------------------------  % Date: Wed, 25 Aug 2004 22:06:45 -0400@* From: "Bill Todd" <billtodd@metrocast.net>' Subject: Re: Divide instruction in IA64e= Message-ID: <X8KdnR23wpT02LDcRVn-uw@metrocastcablevision.com>e  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:412CF28F.9089FCC7@teksavvy.com... > John Reagan wrote:J > > Easy.  The Itanium architecture doesn't have a divide instruction. :-) >eD > What sort of arguments were used to justify leaving this out of anL > architecture ? Can the compilers generate aseembler instructions that will be! > just as fast as a real divide ?  >lI > I know how a division by a power of 2 is done (shift right the registercK > contents). But how will the IA64 compilers generate divide operations fory nonrD > base-2 divisors ? (or how do current chips perform the division ?)  K Some of the novel ways in which compilers can optimize around the lack of a I divide instruction have been mentioned.  But my understanding is that the F other reason there's no (integer) divide instruction is because of theG difficulty of managing it in an otherwise relatively simple instruction-J pipeline (i.e., it's not just silicon area - entire cores will soon becomeJ almost negligible percentages of chip area, though their power consumption will remain an issue).   - bill   ------------------------------  % Date: Wed, 25 Aug 2004 20:08:44 -0700e# From: "Tom Linden" <tom@kednos.com>v' Subject: RE: Divide instruction in IA64a9 Message-ID: <NDEMLKKEBOIFBMJLCECICEFPDLAA.tom@kednos.com>t   < -----Original Message-----. < From: Dan Foster [mailto:usenet@evilphb.org]* < Sent: Wednesday, August 25, 2004 2:10 PM < To: Info-VAX@Mvb.Saic.Comi) < Subject: Re: Divide instruction in IA64v <  < 8 < In article <412CF28F.9089FCC7@teksavvy.com>, JF Mezei ' < <jfmezei.spamnot@teksavvy.com> wrote:e < > John Reagan wrote:K < >> Easy.  The Itanium architecture doesn't have a divide instruction. :-)  < >pF < > What sort of arguments were used to justify leaving this out of an8 < > architecture ? Can the compilers generate aseembler  < instructions that will bee# < > just as fast as a real divide ?  < >tK < > I know how a division by a power of 2 is done (shift right the register-? < > contents). But how will the IA64 compilers generate divide m < operations for nonF < > base-2 divisors ? (or how do current chips perform the division ?) < J < The 8-bit 6502 didn't have a divide instruction, but Applesoft BASIC was@ < able to perform integer and floating point division just fine. < G < So, yes, there are methods to deal with division through other means.r < F < Can split the exponent and mantissa, calculate them separately, then" < recombine results, for instance. < J < I don't know why Intel left out a divide instruction but I'm sure it wasG < an engineering decision -- you have a finite amount of silicon space.i < E < So when you're designing chips, you try to make most use of siliconrH < possible... and that means stripping out instructions that aren't used < as often as others.n < G < Very heavy profiling of previous generation CPUs with a wide range oftH < applications is often done in order to design a better next generation < CPU. < I < Or maybe there's a philosophical perspective -- division implemented asl0 < a CPU instruction is often CISC-ish in nature. < I < RISC instructions tend to be far simpler and more focused on primitivesgI < (loads, stores, etc) rather than more complex sequences encapsulated iny < a single instruction.n < J < Lack of a divide instruction in the CPU generally means you need to do aI < little more work in software to do the equivalent, but it's not an hugeV < obstacle.d < J < Please don't read into this as a defense of the IA-64; I am not speakingJ < specifically of the IA-64, but of CPU design in general. The IA-64 is anG < interesting chip, but I'm not yet sold on its commercial prospects tooH < date. It's unfortunate they chose to kill off the Alpha to push IA-64.  B It is unfortunate that they decided to kill off VAX to push Alpha!   <  < -Dan <  < --- ( < Incoming mail is certified Virus Free.< < Checked by AVG anti-virus system (http://www.grisoft.com).A < Version: 6.0.735 / Virus Database: 489 - Release Date: 8/6/2004, <  ---0& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.735 / Virus Database: 489 - Release Date: 8/6/2004o   ------------------------------    Date: 25 Aug 2004 13:34:13 -05004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)M Subject: Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 users 3 Message-ID: <s6QYKMoSiGbR@eisner.encompasserve.org>w  \ In article <41299082.8D461933@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:P > VMS has already had its substiantial decline. DO you really want IA64 to force > a second wave of decline ?  I Too late. From what I've seen, more Alpha or HPUX customers are moving tooK AIX than to IA64. It may be an inferior solution, but it is ready TODAY andp IA64 is not.  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD"a& 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdffL     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  O  Save Model Rocketry from the HSA!   http://www.space-rockets.com/congress.htmlh   ------------------------------    Date: 25 Aug 2004 13:26:36 -05004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)M Subject: RE: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 usersd3 Message-ID: <VXXhQW$cN8FP@eisner.encompasserve.org>b  | In article <FD827B33AB0D9C4E92EACEEFEE2BA2FB3DFBD5@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <kerry.main@hp.com> writes:I > When the first Alpha's were released (Jensen AXP150 etc), they were notI' > faster than many of the bigger VAX's.n > J > It was only over time when the Alpha performance exceeded all of the VAX
 > systems. > 4 > Take a look at the relative performance levels at:A > http://h18002.www1.hp.com/alphaserver/performance/perf_tps.htmlt  I But the VAXen weren't killed off until not only had Alpha performance hadkL left VAX in the dust, but Alpha **SALES** had left VAX in the dust. It was 5H years from Alpha announce to end-of-life for VAX announce, and another 4I years until last ship of new hardware. That's a 9 year overlap. Very muchr= like we saw for the PDP-11 to VAX migration 15 years earlier.r  J HPQ has already killed the goose(s) before the new ones are even ready forK sale. Please tell me what HP server I can buy TODAY to run my enterprise onmJ for the next decade? Alpha is EOL. VAX is EOL. PArisc is EOL. MIPS is EOL. MPE is past EOL.  G Meanwhile VMS on IA64 is over a year late from the initial announcementnJ roadmap and will be 18 months late by the time it ships in December. Tru64L (now HP-yucks with falsecluster extensions) is over 2 years behind schedule.I That initial roadmap included a 3 year inventment protection on new AlphaiF server purchases. Well, the 3 years are up and IA64 still ain't there.  K BTW, what happens to HP servers and their customers when Intel continues topK miss delivery dates and performance targets with IA64? What happens when we30 get the "FDIV" error IA64 chips in the pipeline?  G Any one wondering why HP business critical server sales are in a slump?   1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD"w& 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdfeL     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  O  Save Model Rocketry from the HSA!   http://www.space-rockets.com/congress.htmlr   ------------------------------    Date: 25 Aug 2004 13:30:04 -05004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)M Subject: Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 users 3 Message-ID: <3H$qRclgGiQH@eisner.encompasserve.org>   W In article <41276934.9070704@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:aQ > The only reason itanic will get faster than Alphas is the lack of newer faster  	 > Alphas.   H Which is why it was critical for HP to get Compaq to kill Alpha. I don'tD understand how either of these ever got past the federal regulators.  K At least HP is a less hostile environment for VMS than Compaq or the Palmer  years.  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD"s& 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdfsL     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  O  Save Model Rocketry from the HSA!   http://www.space-rockets.com/congress.html    ------------------------------  # Date: Wed, 25 Aug 2004 19:00:54 GMT & From: John Reagan <john.reagan@hp.com>M Subject: Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 users72 Message-ID: <Gl5Xc.8748$PM3.3619@news.cpqcorp.net>   Bob Kaplow wrote:E  M > BTW, what happens to HP servers and their customers when Intel continues tohM > miss delivery dates and performance targets with IA64? What happens when wer2 > get the "FDIV" error IA64 chips in the pipeline?  F Easy.  The Itanium architecture doesn't have a divide instruction. :-)         --   John Reaganf/ HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Companyo   ------------------------------   Date: 25 Aug 2004 19:27:50 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)M Subject: Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 users * Message-ID: <2p47hmFgjg50U1@uni-berlin.de>  3 In article <VXXhQW$cN8FP@eisner.encompasserve.org>,n7 	kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) writes:h > K > But the VAXen weren't killed off until not only had Alpha performance hadeN > left VAX in the dust, but Alpha **SALES** had left VAX in the dust. It was 5J > years from Alpha announce to end-of-life for VAX announce, and another 4K > years until last ship of new hardware. That's a 9 year overlap. Very much ? > like we saw for the PDP-11 to VAX migration 15 years earlier.l  G Ummmmm......  PDP-11 isn't EOL yet.  Mentec still sells them.  Not sureeE how much development is still going on, but it did continue after DECp left the picture.    bill   -- CJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   o   ------------------------------  % Date: Wed, 25 Aug 2004 17:09:44 -0700s* From: "Jack Peacock" <peacock@simconv.com>M Subject: Re: Figures on Itanic migration plans by HP-UX, VMS, and Tru64 users 2 Message-ID: <FpadnZmzMbzUt7DcRVn-tw@mpowercom.net>  5 "Bill Gunshannon" <bill@cs.uofs.edu> wrote in messageo$ news:2p47hmFgjg50U1@uni-berlin.de...I > Ummmmm......  PDP-11 isn't EOL yet.  Mentec still sells them.  Not sureIG > how much development is still going on, but it did continue after DEC  > left the picture.  >sL That's actually a good comparison.  Like the PDP-11 there will be no new VAXE or Alpha processors but there will be a few diehards hanging in therenJ decades after the last new chip came out of the foundry.  Maybe Mentec canL take over the VAX and Alpha lines too.  They do have a good track record for1 keeping the PDP-11 alive, albeit on life support.i   Jack Peacock   ------------------------------  # Date: Thu, 26 Aug 2004 02:05:10 GMTh' From: bcwright <bcwright@ix.netcom.com>  Subject: GCC for OpenVMS/VAX?VC Message-ID: <qzbXc.12900$2L3.4650@newsread3.news.atl.earthlink.net>   G Forgive me for asking such a simple question, but I'm trying to find a eF more recent version of GCC for OpenVMS/VAX than what I have, and I've G been having quite a bit of trouble finding anything about where to get rI the latest version.  There are various pointers in the FAQ and elsewhere ,F but these all seem to have become the victim of bit rot - all of them 4 that I've found point to sites that no longer exist.  K What's the latest version of GCC for OpenVMS/VAX?  Does anyone have a copy?J   Thanks,f   Bruce Wright   ------------------------------  # Date: Wed, 25 Aug 2004 22:14:19 GMT 6 From: "Andy Bustamante" <a_c_bustamante@earthlink.net>5 Subject: Re: How can I monitor VMS from Windows/Linuxt< Message-ID: <%a8Xc.8129$QJ3.2492@newssvr21.news.prodigy.com>  D See T4, http://h71000.www7.hp.com/openvms/products/t4/index.html forI establishing an automated monitoring proceedure.  This collects data intof> CSV and the command file can be configured to e-mail the data.   -- a     Andy Bustamante  Remove the ASCII 95s for e-mail     6 "Sebby Lind" <sebbylind@yahoo.com.au> wrote in message7 news:8b171295.0408232329.6ccb6483@posting.google.com...oH > I need to provide some support for a old but critical VMS system (7.1) >r/ > How can I monitor this from Windows or Linux?  >wH > I prefer using free tools/scripts (or not so expensive software) sinceE > we can't spend much more money on these systems since they are soone) > (within a year or so) to be turned off.  >s
 > Regards, > Sebby  > Sydney, Australiay   ------------------------------  % Date: Wed, 25 Aug 2004 21:38:51 -0500e2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: How can I monitor VMS from Windows/Linuxg+ Message-ID: <412D4D3A.14724DB0@comcast.net>u   Sebby Lind wrote:t > h > Roland Barmettler <itsme@127.0.0.1> wrote in message news:<20040824142854.0abaf2e2.itsme@127.0.0.1>...0 > > Phil wrote on Tue, 24 Aug 2004 12:11:03 GMT: > > > I > > > If you have nagios running on linux, vms monitoring can be "made toa > > > work"  > >rE > > I entirely agree. I'm using Nagios on Linux and self-written perlsJ > > scripts (which in turn use SNMP tools) to monitor all our VMS systems.F > > It's quite easy to setup, only SNMP needs to be running on the VMS
 > > machines.  > >h > > Cheers, Roland > G > I've been using Nagios on other systems and will as adviced use it tolH > monitor VMS too. I just wasn't sure how common it was to use Nagios on > VMS. >  > Thank you all for your input.y  G You may receive a call from your local VMS Ambassador. I forwarded yourlC note to Sue and Mark G. under the subject line, "Endangered AccountrF Alert". If he/she calls, make sure he/she gets the part about your VMSF systems being EOL'd rather than being distracted by the other content.   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 21:42:05 -0500t2 From: David J Dachtera <djesys.nospam@comcast.net>5 Subject: Re: How can I monitor VMS from Windows/Linux'+ Message-ID: <412D4DFD.B35E50B2@comcast.net>o   Andy Bustamante wrote: > F > See T4, http://h71000.www7.hp.com/openvms/products/t4/index.html forK > establishing an automated monitoring proceedure.  This collects data into @ > CSV and the command file can be configured to e-mail the data.   A note of caution about T4:i  D The .CSV output can be imported into Excel; however, you may find itH challenging to work with. The recordsize of the .CSV file approaches the 32767 byte RMS limit.f  D Look up the "Timeline Visualizer" tool (TLViz) which is a WhineBlozeF program to produce graphs (Display only) of selected metrics extracted from the source VMS machine.   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 21:13:00 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>! Subject: Re: HPworld - I SurvivedD+ Message-ID: <412D472C.AAF4E924@comcast.net>t   Bob Kaplow wrote:w > [snip] >  The union situation inlJ > Rosemont can't be worse than Chicago, but may not be much better either.  F It's hard for me to say anything against unions because if not for theC UAW, I wouldn't have straight teeth and my Mom couldn't stay in her  house now that Dad is gone.8  H On the other hand, it really does get in the way sometimes. You'd almostG be better off to pay the union guys to go drink coffee and let the reald go-getters do the job NOW.   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 21:16:55 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>! Subject: Re: HPworld - I Survived + Message-ID: <412D4817.1D4D6C85@comcast.net>0   Joe Silagi wrote:  > < > "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in messageP > news:DA4AD590CAF06845B671C398333A89C60415850A@ohms.electric.ci.austin.tx.us...( > > Book a hotel room on an upper floor? > I > no lie!    in 1992 Interex (now HP World) was in New Orleans.... so waseI > hurricane Andrew.  For a place that gets as much rain as they do, I waspN > surprised at how leaky the conference hall was.   The other surprising thing7 > is how fast "I survived ...." t-shirts were produced!r  H Very likely, they had been made up "just in case" and were brought forth when opportunity knocked.   F Yeah - late summer is always bad down in the gulf 'cuz ya dunno what's gonna happen or when.h  G I'll also be researching AmTrak's schedules to see if surface transport>A might be an option should the airlines be grounded by threateningn weather.   D.J.D.   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 22:37:21 -0400y- From: JF Mezei <jfmezei.spamnot@teksavvy.com>r! Subject: Re: HPworld - I Survivedo, Message-ID: <412D4CDD.437A1EAF@teksavvy.com>   David J Dachtera wrote:eI > I'll also be researching AmTrak's schedules to see if surface transporteC > might be an option should the airlines be grounded by threatening 
 > weather.  K A few years ago, when a hurricane was about to hit Florida and with advancenM evacuation notice (remember when they closed the eastbound lanes of a highwaypG so that westbound traffic could use them ?). Guess who was first to cutkJ service: AMTRAK. Airlines stopped flying well after Amtrak cancelled their trains to florida.  L (Goes to show that Amtrak is rather useless in times where massive number ofL people need to be moved, which was one argument to keep a national passenger railway alive).h  J You do not wish to be in the path of a hurricane in an area where buildingJ codes are not up to snuff (such as Florida). In fact, I am not sure if anyM place in the USA has properly enforced building codes. Floridians should maketL a trip to northern australia to see how just one cyclone (Tracy in 1974) was6 enough to force strict building standards on everyone.  N If airlines stop flying into a city the size of New Orleans, it probably means! that you do NOT wnat to go there.   L In a cat 4  cyclone, a piece of plywood over a window will not prevent a 2*4H travelling at 250km/h  from punching through.  The idea is to have *ALL*M buildings secured so that they don't release building materials into the wind % during the cyclone/typhoon/hurricane.n   ------------------------------  % Date: Wed, 25 Aug 2004 22:37:34 -0400d- From: JF Mezei <jfmezei.spamnot@teksavvy.com>t! Subject: Re: HPworld - I Survived", Message-ID: <412D4CEA.DDF2874C@teksavvy.com>   David J Dachtera wrote:hI > I'll also be researching AmTrak's schedules to see if surface transporthC > might be an option should the airlines be grounded by threateningl
 > weather.  K A few years ago, when a hurricane was about to hit Florida and with advancedM evacuation notice (remember when they closed the eastbound lanes of a highwayyG so that westbound traffic could use them ?). Guess who was first to cut J service: AMTRAK. Airlines stopped flying well after Amtrak cancelled their trains to florida.  L (Goes to show that Amtrak is rather useless in times where massive number ofL people need to be moved, which was one argument to keep a national passenger railway alive).   J You do not wish to be in the path of a hurricane in an area where buildingJ codes are not up to snuff (such as Florida). In fact, I am not sure if anyM place in the USA has properly enforced building codes. Floridians should makeIL a trip to northern australia to see how just one cyclone (Tracy in 1974) was6 enough to force strict building standards on everyone.  N If airlines stop flying into a city the size of New Orleans, it probably means! that you do NOT wnat to go there.e  L In a cat 4  cyclone, a piece of plywood over a window will not prevent a 2*4H travelling at 250km/h  from punching through.  The idea is to have *ALL*M buildings secured so that they don't release building materials into the windr% during the cyclone/typhoon/hurricane.    ------------------------------  % Date: Wed, 25 Aug 2004 23:27:22 -0400t# From: "John Smith" <a@nonymous.com> ! Subject: Re: HPworld - I Survivedc, Message-ID: <XLudnZQ6M_k9xbDcRVn-gw@igs.net>   David J Dachtera wrote:  > Joe Silagi wrote:5 >>= >> "Stuart, Ed" <Ed.Stuart@austinenergy.com> wrote in messagej >>L news:DA4AD590CAF06845B671C398333A89C60415850A@ohms.electric.ci.austin.tx.us. ..( >>> Book a hotel room on an upper floor? >>F >> no lie!    in 1992 Interex (now HP World) was in New Orleans.... soD >> was hurricane Andrew.  For a place that gets as much rain as theyB >> do, I was surprised at how leaky the conference hall was.   TheE >> other surprising thing is how fast "I survived ...." t-shirts wereT >> produced! >ND > Very likely, they had been made up "just in case" and were brought! > forth when opportunity knocked.  >aH > Yeah - late summer is always bad down in the gulf 'cuz ya dunno what's > gonna happen or when.e >0? > I'll also be researching AmTrak's schedules to see if surfacecA > transport might be an option should the airlines be grounded by  > threatening weather.      L I can see it now - both the train and all the passengers snorkelling at high( speed through 10' deep flood waters. :-)  K Maybe a 406Mhz GPS PLB (personal locating beacon) should be brought along --I that way the Coast Guard can find you when you've been washed out to sea.-   ------------------------------    Date: 25 Aug 2004 21:02:36 -07001 From: susan_skonetski@hotmail.com (Sue Skonetski)2, Subject: Re: Looking for VMS experts opinion= Message-ID: <857e9e41.0408252002.48b97faf@posting.google.com>K  a JF Mezei <jfmezei.spamnot@teksavvy.com> wrote in message news:<412BB716.C1CBE5E1@teksavvy.com>...a > Keith Parris wrote:rI > > Carly has spoken very positively about OpenVMS on multiple occasions,o > P > Speaking to the troups and/or VMS bigots isn't enough. She must present VMS asI > a viable , core , strategic product whenever she presents her company'stP > product to the public and to the press. And HP has failed just like Compaq did > in that respect. > E > It doesn't cost any advertising budget to include VMS in the publicpO > presentations Carly makes. But the consistant omission of VMS from her public P > appearances sends a very strong message that HP doesn't see VMS as a long term& > strategic product it wishes to grow. > ; > > and you can even find videos on the HP OpenVMS website: 5 > > http://h71000.www7.hp.com/openvms/25th/index.htmlm > L > I don't care about videos or testimonies hidden away in the VMS website. IC > care about HP telling the world it has VMS and wants to grow VMS.   C JF you may not care about videos or testimonials but other folks doeD and they are not hidden away, we spend time money and effort gettingE them done. They are on the VMS web page where they should be.  PeoplelA actually use them.  People that need real testmonials to buy VMS.f  E I must say no one has ever said I have ever done anything covertly, IS> usually get accused of being to obvious about VMS ;') which isD probably true.  And guess what.  I am not going to stop.  I am goingE to do what ever I can however I can, internal or external for as longlE as I can.  And maybe,  just maybe it helps a little.  But one thing I > do know, wishing things were different never changes anything.  @ I have also found that if you are going to purchase some seriousB hardware and software any corporation will usually listen.  If theC last time you purchased something they still had vaccum tubes, youre  argument has lost some strength.   sue     -L > I care about Carly making press releases about VMS wins. The fact that SueN > must find ways to get some VMS stuff out the door almost covertly says a lot" > about HP's intentions about VMS. >  >  > > G > > As one of the bright spots (both growing and profitable) within the-F > > ESS organization (the sole area which fell short in last quarter'sI > > results), and with 3 quarters averaging double-digit growth, I'm sure:$ > > OpenVMS gets noticed at the top. > + > May I ask how you got that information ? @ > O > If that information is true, then how come Carly didn't mention that when shedP > had to announce the bad news about ESS ? She could have said that some productM > lines including VMS were growing and profitable within ESS. That would havep) > sent a very positive message about VMS.E > J > Unless, of course, VMS had dwindled to the size of Tandem where a single: > additional sale can increase sales in a quarter by 100%.   ------------------------------  % Date: Wed, 25 Aug 2004 21:43:35 -0500u2 From: David J Dachtera <djesys.nospam@comcast.net>$ Subject: Re: OpenVMS Wikipedia entry+ Message-ID: <412D4E57.26DFDCC1@comcast.net>o   Paul Sture wrote:  > K > I just stumbled across this today, and thought y'all might appreciate it.y > 4 > http://en.wikipedia.org/wiki/Virtual_Memory_System  G I made a note to myself to include that link in the next incarnation ofp my OpenVMS Support page.   Thanx!   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 21:05:05 -0500s2 From: David J Dachtera <djesys.nospam@comcast.net>) Subject: Preparing for HP Tech Forum 2005i+ Message-ID: <412D4550.F683777C@comcast.net>h  D O.k. I've started collecting data on the Morial Convention Center in  "Nawlins" (New Orleans, LA USA).   Looking for hotels:=  ? Go to http://www.neworleanscvb.com/ (New Orleans Convention and ? Visitor's Bureau). Under "Book a room", Pull down the "Select a ? landmark" list, and select Morial Convention Center, then clickeF "Search". This should open a sub-frame to TravelNow.com listing hotels& by proximity to the convention center.  F I did not test this with either Mozilla or the older Netscape V3.x forC VMS. It wokrs in Interhose Exploder V5.5 and later, and in Netscapee V4.77.   D.J.D.   ------------------------------  % Date: Wed, 25 Aug 2004 20:24:08 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>  Subject: Re: Re, Re : set prompt+ Message-ID: <412D3BB8.D3EDD17F@comcast.net>c   "Alan E. Feldman" wrote: > g > David J Dachtera <djesys.nospam@comcast.net> wrote in message news:<412AA189.2C33B015@comcast.net>...s > > "Alan E. Feldman" wrote: > > > [snip]L > > > I want DCL to offer an option to add the time to the DCL prompt -- theJ > > > time that the prompt appeared. This is how it works in MS-DOS and onG > > > Stratus's VOS. That's what I am asking for. I am not asking for aiF > > > clock. I have a clock already. I want to be able to go back to aF > > > session, either still in the SmarTerm history buffer or copy andJ > > > pasted to a file on the VAX, and have the times in the prompts. ThisL > > > gives clues as to what happened when. It is not a comprehensive set ofL > > > time stamps, but it is better than no time stamps. It might be nice toI > > > also have at least the day as an added option as sometimes the time F > > > alone is not enough (for example if you come back to a session a2 > > > couple of days later and run more commands). > >iJ > > Some old advice (from Hoff?) was to write a short DCL "shell" proc. to5 > > write out the time before accepting input, as in:e > > 
 > > $loop: > > $ write sys$output f$time()t > > $ read sys$command line  > > $ 'line' > > $ goto loopo > C > The problem with this is that it dies with a ^Y and loses command4	 > recall.g  / Does INQUIRE work better than READ SYS$COMMAND?v  = > I don't want to lose command recall in favor of timestamps.   ) Here's kind of an off-the-wall thought...a  H Is there any way to hook the return from an executed image or cliroutineE and add a user-specific routine at that point? If so, you could add ai@ brief routine to display the time before the DCL prompt returns.  G ...or even further off-the-wall, are there any games that can be playedoE with audits to issue an OPCOM message (to a specific operator class?) A upon image activation *AND* image run down (would give start/stopdC times)? You'd have to mine that data from the OPCOM log or whatevero logging sink, but ...    D.J.D.   ------------------------------    Date: 25 Aug 2004 19:02:10 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)  Subject: Re: Re, Re : set prompt< Message-ID: <b096a4ee.0408251802.1edd910@posting.google.com>   winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote in message news:<00A36D8C.116E5846@SSRL.SLAC.STANFORD.EDU>...U > In article <00A36D2D.6955CB50@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:sq > >In article <b096a4ee.0408231614.66e6ebed@posting.google.com>, spamsink2001@yahoo.com (Alan E. Feldman) writes:  > >>Mr. Shake and Baker wrote: > >>	 > >>[...]oL > >>> >I will write to Hunter Goatley and ask for a copy of his program (see  > >>> >his post in this thread). > >>> / > >>> ...but you still need a terminal...  doh!i > >>- > >>Hmmm. I have a terminal. I even said so.   > >> > >>> plonk! > >>L > >>Well goodbye to Mr. Shake and Baker and his inane questions and remarks! > >e > >What a childish twit.     > >oK > >Do you speak for yourself or for everone here?  If for yourself, go fuck K > >off.  If for the entire newsgroup, I'll gladly step out.  I am sure thateK > >my contributions to comp.os.vms in terms of VMS will not be missed when,nK > >in its place, there will be your faineant prattle to fill that technicalw > >void. > >a' > >I'll give the group a day to decide.s > J > Oh, for heaven's sake.  Of course Alan E. Feldman doesn't speak for the M > entire group - but he doesn't seem to be saying what you think he's saying, 
 > either.   A It appears that Mr. VAXMAN tends to overgeneralize so as to blame $ entire groups for the sins of a few.  oE > You plonked him. "plonk", usenet-wise, was the sound somebody makeshK > as they go in your killfile; he therefore understood that you wouldn't beeK > talking to him anymore because you'd killfiled him.  (This was apparently K > not what you meant by it.)  This makes his "goodbye" something other than K > a request for you to go away, especially since he thought you wouldn't be M > reading it, having him killfiled.  (That said, making fun of people's namesiP > _is_ pretty childish.  But up 'til then, I don't see him as being particularlyN > in the wrong - you referred to XPDNT updating a DECterm status line; he said@ > he didn't have a DECterm, and you guys were off to the races.)  E Well, his attacks on me were unprovoked, undeserved, and unjustified.SE And using "doh" doesn't strike me as being particularly mature. It isoB funny, but so was my remark, unlike some others we've seen in this group.   I have done nothing wrong. s  E All this fuss over a minor miscommunication. It's not like I made him  dig a moat!   N > Your technical contributions are extremely valuable to the VMS community andF > to comp.os.vms in particular, so I very much hope you won't go away.  F I just wish Mr. VAXMAN would stop his attacks and that either he would> ignore my posts altogether or at least read them a little moreD carefully. I very clearly said that I have a terminal in the form ofE SmarTerm and as a reply to that very post he said I have no terminal.,= Then how does he think I communicate with my VAX systems? Viam
 telepathy?  B OK, I shouldn't have said I don't have DECwindows, but I did say IE want the time in the prompt and that I do not want the default in the0, prompt. Still, the attacks were unjustified.   ------------------------------    Date: 25 Aug 2004 22:16:54 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)  Subject: Re: Re, Re : set prompt= Message-ID: <b096a4ee.0408252116.571b819e@posting.google.com>e   winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote in message news:<00A36D8C.116E5846@SSRL.SLAC.STANFORD.EDU>...U > In article <00A36D2D.6955CB50@SendSpamHere.ORG>, VAXman-  @SendSpamHere.ORG writes:rq > >In article <b096a4ee.0408231614.66e6ebed@posting.google.com>, spamsink2001@yahoo.com (Alan E. Feldman) writes:e > >>Mr. Shake and Baker wrote: > >>	 > >>[...]sL > >>> >I will write to Hunter Goatley and ask for a copy of his program (see  > >>> >his post in this thread). > >>> / > >>> ...but you still need a terminal...  doh!d > >>- > >>Hmmm. I have a terminal. I even said so.   > >> > >>> plonk! > >>L > >>Well goodbye to Mr. Shake and Baker and his inane questions and remarks! > >e > >What a childish twit.     > >uK > >Do you speak for yourself or for everone here?  If for yourself, go fucktK > >off.  If for the entire newsgroup, I'll gladly step out.  I am sure that K > >my contributions to comp.os.vms in terms of VMS will not be missed when, K > >in its place, there will be your faineant prattle to fill that technicalt > >void. > >e' > >I'll give the group a day to decide.s > J > Oh, for heaven's sake.  Of course Alan E. Feldman doesn't speak for the M > entire group - but he doesn't seem to be saying what you think he's saying,h
 > either.  > E > You plonked him. "plonk", usenet-wise, was the sound somebody makescK > as they go in your killfile; he therefore understood that you wouldn't belK > talking to him anymore because you'd killfiled him.  (This was apparentlydK > not what you meant by it.)  This makes his "goodbye" something other thaneK > a request for you to go away, especially since he thought you wouldn't beaM > reading it, having him killfiled.  (That said, making fun of people's names P > _is_ pretty childish.  But up 'til then, I don't see him as being particularlyN > in the wrong - you referred to XPDNT updating a DECterm status line; he said@ > he didn't have a DECterm, and you guys were off to the races.) > N > Your technical contributions are extremely valuable to the VMS community andF > to comp.os.vms in particular, so I very much hope you won't go away. > 	 > -- Alanr  D While not admitting any wrongdoing, I am sorry if any of my posts inC this thread caused anyone any trouble, including Mr. VAXMAN. AnyoneIF who really cares about this issue is free to use Google groups to read% this thread and judge for themselves.e   ------------------------------  # Date: Wed, 25 Aug 2004 18:48:59 GMTv1 From: Keith Parris <keithparris_NOSPAM@yahoo.com>f. Subject: Re: Shadow Merge is Killing Me - help2 Message-ID: <va5Xc.8745$YL3.7203@news.cpqcorp.net>   Dave Baxter wrote:G >      I had one of my ES40 systems crash at 09:10 Monday 23rd, no diskn > merges resulted from this.  H I'm surprised. Perhaps the system had no shadowsets mounted at the time?   > I amH > now in the position of trying to deal with the effect of the "merges". > C >    RIGHT NOW, PERFORMANCE IS SO POOR, MY USERS ARE TREATING US ASa > "DOWN"  & You have my sympathy. And we can help.  F >      First of all, can anyone explain why I ended up merging at all,F > since two nodes were up and had the volumes mounted throughout theseH > events.   (this was not an issue with CI clusters, so long as one node( > remained up with the volumes mounted).  H In a CI cluster, storage is typically on HSJ controllers, which support F the MSCP protocol and its various Volume Shadowing Assists, including H Write-History Logging, which allow a brief Mini-Merge instead of a Full F Merge. SCSI and Fibre Channel controllers don't speak MSCP, and don't  have such assists.  I There is a host-based Mini-Merge capability in field test right now, and tI slated to be available at the same time as 8.2 ships (but also available  (   in an ECO kit for 7.3-2), as I recall.  D >      I have to get my disks re-synched, either merged or copied.  G > Logic tells me that it should be less disruptive to merge, however itdD > would probably be quicker to copy, is this a reasonable statement?  H In my measurements, the biggest impact to applications during merges is I due to the need for repeated merging of hot areas on each read operation mG until the merge fence passes over the hot area. So in actual practice, cF it often has significantly less impact to applications to have a Full C Copy going on than a Full Merge, so if you can stand the temporary aH reduction in data protection, you can dismount all but one disk in each I shadowset and stop the merges that way (and then presumably start a Full h@ Copy in its place on each shadowset to restore your redundancy).  H >      Are there methods to "tune", or administer the merge/copy processC > so that I can get my volumes re-synched with a minimum of impact?c  A The OpenVMS Volume Shadowing manual describes some logical names 0I SHAD$MERGE* which you can set to help speed merges, particularly on your i most-critical disks. See oC http://h71000.www7.hp.com/doc/732FINAL/aa-pvxmj-te/aa-pvxmj-te.HTML2  : > One last comment, I have a 20 x 35GB Volumes Oracle DB    I It can often be lower in impact to have more volumes but each of smaller RD size (perhaps by partitioning), to get more parallelism in the Full I Merge work and get the pain over and done with faster. This is also true 2 for Full Copies.  A There is much more detail in my user-group presentation entitled e7 "OpenVMS Volume Shadowing Merge & Copy Performance" at    http://www2.openvms.org/kparris/   ------------------------------  % Date: Wed, 25 Aug 2004 17:33:50 -0700i* From: "Jack Peacock" <peacock@simconv.com>T Subject: Re: SKHPC's Latest Take on IPF and Post-Superdome Technology From HP  World2 Message-ID: <wd6dnexnVsNysrDcRVn-jg@mpowercom.net>  + "Dr. Dweeb" <dr@dweeb.com> wrote in messager' news:cgi923$1sl4$1@news.cybercity.dk... I > Well, that is a good question Bill.  It seems that the argument bandiedgE > arround for the Itanic is that it *is* in some way more capable foro top-endmF > machines than the X86 chips which must be by definition lacking some  > important chip-level features. >AI It's partly a matter of semantics but from a strictly Intel point of viewVI there is some truth that an Itanium has something extra.  The EMT64 Xeons L only have a 36 bit physical address, 64GB max memory, and Xeons use a sharedG bus which tends to limit scaling.  The Itanium (as I understand it) hassK additional hardware to take care of those limitations.  Rumors are that the L EMT64 chips have 64-bit performance problems too, but there don't seem to be, enough of them around to confirm or deny it.  I Of course if you include AMD (Intel would rather you paid no attention torF that CPU behind the curtain) the "lacking" argument is reduced to highL performance floating point clustered arrays rendering 3D movie effects whereH the entire app fits in the 9MB CPU cache.  I haven't seen a single claim@ that AMD would outrun an Itanium in that particular environment.   Jack Peacock   ------------------------------  % Date: Wed, 25 Aug 2004 21:48:10 -0400 * From: "Bill Todd" <billtodd@metrocast.net>T Subject: Re: SKHPC's Latest Take on IPF and Post-Superdome Technology From HP  World= Message-ID: <HdidnXGQnNGT3LDcRVn-ow@metrocastcablevision.com>d  + "Dr. Dweeb" <dr@dweeb.com> wrote in messageS' news:cgi923$1sl4$1@news.cybercity.dk...M > Bill Todd wrote:9 > > "Bob Ceculski" <bob@instantwhip.com> wrote in messageb: > > news:d7791aa1.0408241513.f69239a@posting.google.com... > >- > > ...h > >e
 > ... clip: > >   It certainly can't run a high end system like alpha. > >c< > > Really?  Care to provide very specific evidence why not? > >s
 > > - bill >eI > Well, that is a good question Bill.  It seems that the argument bandiednE > arround for the Itanic is that it *is* in some way more capable forf top-endaF > machines than the X86 chips which must be by definition lacking some  > important chip-level features. > G > I have no clue why this should be the case, though I seem to see this  notion4 > expressed at regular intervals by Itanic boosters. >AJ > Is the Itanic intrinsically "better" for Superdome class machines, or is5 > this just all hot air from the Itanic boiler room ?.  K Completely hot air?  Possibly not.  While Opteron has some very respectable/H on-chip RAS features, Itanic *may* have a couple more - and I'd honestlyL appreciate a real head-to-head comparison in this area (though hardly expect to get one from Bob).F  G And at least currently the only way to use Opteron in a Superdome-classDK machine would seem to be to throw away its on-chip support for both routingoC and memory and use it just like Xeon or Itanic, with external chipsrE providing memory and routing support.  Since that would eliminate two L significant advantages that the glueless configurations currently enjoy overK the competition, Opteron might not look as good by comparison as it does in.0 the glueless configurations it was designed for.  J That is reportedly about to change, however.  The obvious (at least to me,H though my understanding of the details is too superficial for this to beD more than a wild-assed guess) solution is to keep the on-chip memoryJ support, and quite possibly the on-chip routing (to allow small groups of,A say, 2 or 4 processors with their associated RAM), and then use asI hypertransport switch to connect those small groups together.  This would D look rather like the POWER architecture (save that POWER requires noG external HT switch - inter-group routing also occurs on-chip) or even acJ *little* like Superdome (save that Superdome - whether Itanic or PA-RISC -I lacks on-chip memory support and on-chip routing within the small group).r  F The one gotcha in the above is that the HT switch must have additionalH intelligence in it to support (probably directory-based) cache coherenceK *between* the small groups, because the on-chip coherence mechanism doesn'tsI scale beyond 8 processors (and 8 may in fact stretch it a bit - we should-K know soon, as 8-processor Opteron systems are starting to appear).  If thato@ is feasible, then a larger Opteron system should exhibit scalingK characteristics closer to EV7 and POWER than to Superdome.  One should notenI that SGI has, in fact, managed to build very respectable scalable systemsoF using Itanic for HPTC applications, but they've been shy about runningH commercial benchmarks on them so we don't know how they'd scale on, say,I TPC-C.  If they scale well there that might help Itanic a bit in general,p( but of course it doesn't help Superdome.  B EV7 and POWER seem to have demonstrated that if you have a stellarD interconnect in a large system, superior scalability doesn't requireG humongous on-chip caches (EV7's being 1.75 MB, POWER4/4+'s being 1.5 MB E shared by two cores, and POWER5's 2 MB shared by two cores, while thedH top-of-the-line Itanic's has been 6 MB for the past year and is about toI increase to 9 MB, with 24 MB on the dual-core Montecito about a year fromtL now).  This is good news for Opteron, because its on-chip cache is only 1 MBJ (though 2 MB may be in the cards soon).  On the one hand, the fact that itK can trounce Itanic in small system configurations with only 1/6 as large anmH on-chip cache is impressive in its own right, but scaling it up to largeH systems will require either superb interconnects (possibly of the form IH described above) or a larger cache to cut down on inter-group referencesC (while EV7 gets by on pure interconnect speed, POWER does use largeiD auxiliary off-chip caches to help here, and the hypothetical Opteron@ inter-group switch could provide them for Opteron if necessary).  K I'm looking forward to seeing exactly what large Opteron architectures lookbH like.  Their superiority is not a foregone conclusion, but the amount ofI time they're taking to appear suggests (I hope) that the designers may be ! taking the time to do them right.l   - bill   ------------------------------    Date: 25 Aug 2004 13:54:55 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)- Subject: Re: Whither RAID?3 Message-ID: <qZUOXHhAnh$u@eisner.encompasserve.org>t  P In article <cgiau4$1ump$1@news.cybercity.dk>, "Dr. Dweeb" <dr@dweeb.com> writes:  F > It is a common mistake to think that RAID-X is some kind of panacea.  D How is that common ?  I don't know of any VMS experts who think thatC redundancy can save one from software errors.  If I write the wrongiD data, proper redundancy will replicate the wrong data everywhere !!!   ------------------------------  % Date: Wed, 25 Aug 2004 21:21:23 +0200m  From: "Dr. Dweeb" <dr@dweeb.com> Subject: Re: Whither RAID?- Message-ID: <cgiorj$2ejh$1@news.cybercity.dk>    Larry Kilgallen wrote:; > In article <cgiau4$1ump$1@news.cybercity.dk>, "Dr. Dweeb"f > <dr@dweeb.com> writes: >-G >> It is a common mistake to think that RAID-X is some kind of panacea.  >tF > How is that common ?  I don't know of any VMS experts who think thatE > redundancy can save one from software errors.  If I write the wrong.F > data, proper redundancy will replicate the wrong data everywhere !!!  K You have answered your own question.  "VMS experts" constitute a very smallaJ part of the population of IT professionals, and most e-mail systems do notI run on VMS.  Just because you and I know better, does not mean others do.nI And yes, I have met many people who think RAID-X is a solution when it is6 not.   Dweebg   ------------------------------  % Date: Wed, 25 Aug 2004 17:24:07 -0700t* From: "Jack Peacock" <peacock@simconv.com> Subject: Re: Whither RAID?2 Message-ID: <3YqdnVsNLcs1sLDcRVn-pg@mpowercom.net>  + "Dr. Dweeb" <dr@dweeb.com> wrote in messagen' news:cgiau4$1ump$1@news.cybercity.dk... L > It is a common mistake to think that RAID-X is some kind of panacea.  Only auK > correct and regular backup strategy can save you from the sort of failure  I0G > experienced.  Indeed, it may be exactly this type of failure that thec > article referred to. >wG As I tell customers who think RAID equates to no tape drive needed, anyeH newbie with the admin password can go and delete system files.  The RAIDK system will faithfully delete the files across all the mirrors, so that all:) disks in the array are equally corrupted.s  I The problem sounds like a restore to the last good backup, which may have K been a few days back before the file corruptions started.  Even a backup is F no guarantee if the problem isn't caught until days later.  I had that@ problem on an Alpha 2100 a few years back.  An pattern sensitiveF intermittent failure developed in the data bus to the SCSI controller.J Every few hours a disk or tape write would be corrupted, but in such a wayL that it veriefied on the backup.  Since the apps were 99% read, 1% write theG problem didn't reach crash proportions until more than 4 weeks after itrK began.  At that point the entire monthly cycle (31 tapes) had some level ofoL corruption.  I had to restore data files as best I could, patch the sectionsJ back together, and in some cases data had to be reconstructed.  The savingK grace was that they didn't work on weekends, so some of the tapes were more0L than 31 days old.  A nasty hardware failure as it didn't log as a error with: the motherboard SCSI controller.  It was a very long week.   Jack Peacock   ------------------------------  % Date: Wed, 25 Aug 2004 20:16:26 -0400m* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Whither RAID?= Message-ID: <we-dnSaBRtwTtrDcRVn-gQ@metrocastcablevision.com>c  + "Dr. Dweeb" <dr@dweeb.com> wrote in messageo' news:cgiau4$1ump$1@news.cybercity.dk...a   ...p  L > It is a common mistake to think that RAID-X is some kind of panacea.  Only aeK > correct and regular backup strategy can save you from the sort of failurel I  > experienced.  A Actually, there *is* another way to protect against it other thanlF conventional backup, at least as long as the file system itself can beK trusted (e.g., either it lives on a separate NAS box or you trust your host K not to corrupt the local file system):  use RAID plus some form of snapshotSJ mechanism (or full-fledged log-structured storage) to protect against lossK of old versions (VMS's versioning mechanism, if used pervasively and in theoJ appropriate manner, could also do this, but only if all files were updatedD by creating a new version rather than in place, so it's not quite as. feasible as snapshots or log-structuring are).  J Given the size of today's disks, creating a file system which either neverJ gets rid of *anything* or at least automatically keeps a reasonable recentL history plus some older versions (the 'Elephant File System' is worth takingL a look at in this regard) is starting to become feasible:  old data tends to@ be cold data, so is an ideal candidate for placing on humongous,G very-low-cost-per-GB disks that might otherwise be too large to be usedr" effectively for normal processing.  K In such a file system, you can trash your file secure in the knowledge that.F a very recent untrashed copy can still be accesssed.  Couple this withF sufficient underlying storage redundancy (including geographic replicaK separation to substitute for off-site backup tapes), and you've potentiallyu> got an inexpensive and very convenient replacement for backup.  D But you really, really do have to trust the underlying file system'sF integrity in this case.  This means ECC memory, RAID-10 storage as theJ absolute minumum, but preferably storage that actually performs end-to-endJ checksums on all data (this catches bus errors as long as the full path toI each data copy is replicated such that at least one copy should be valid,lL plus of course any undetected disk errors) and scrubs it regularly to detectJ single-sector failures before a disk failure somewhere else needs the data< in them.  And, of course, no bugs in the file system itself.  I Sun makes some relevant claims for its new ZFS file system in such areas,hG but not yet (at least to my knowledge) in sufficient detail to evaluatef their credibility.   - bill   ------------------------------   End of INFO-VAX 2004.472 ************************