1 INFO-VAX	Fri, 10 Oct 2003	Volume 2003 : Issue 561       Contents: Re: Advertising in HP  Re: Advertising in HP  Re: affordable VMS2 Re: EVA question: How many vdisks should I create?2 Re: EVA question: How many vdisks should I create?2 Re: EVA question: How many vdisks should I create?/ Re: HGFTP - how to troubleshoot data connection 
 Info about HP  Re: Info about HP  Re: Info about HP  Re: Info about HP % Re: ITRC Download site - some answers P Re: Problem with CLUSTER_CONFIG? (was: Re: DIFVOLMNT (%X0072832C), then bugcheck  Re: Problem with SWCC_CONFIG.com Sickening, isn't it?' Re: SKHPC's view on the port to Itanium $ SKHPC: Howard Elias Emigrates to EMC Re: SMTP receiver logs& Soap Toolkit and alternate web servers Re: Sun takes a hit  Re: Sun takes a hit  Re: Sun takes a hit  Re: Sun takes a hit  Re: TSM on Alpha Re: TSM on Alpha) Re: Vax / VMS V5.5-2 External Drive Issue % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ? % Re: What is the performance of iVMS ?   F ----------------------------------------------------------------------   Date: 9 Oct 2003 12:05:51 -0700 / From: kenneth.randell@verizon.net (Ken Randell)  Subject: Re: Advertising in HP= Message-ID: <79de9693.0310091105.432b31b2@posting.google.com>   ] "Island" <dbturner@islandco.com> wrote in message news:<voammsea80vs4d@news.supernews.com>... J > In "People" Ragazine yesterday (I don't read it honestly) there is a  20& > page Ad for HP Printers and Cameras. > ) > I repeat 20 page Ad, yes, a 20 page Ad.  >   C Last Thursday (10/02/2003) in USA Today (in the SF Bay area anyway) E there was a 24-page -- full newspaper-size pages -- full-color ad for  HP color printers/cameras/etc.  / Somewhere in HP there is money for advertising.    ------------------------------  $ Date: Thu, 9 Oct 2003 19:55:19 -0500, From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> Subject: Re: Advertising in HP/ Message-ID: <voc0ro3npe8232@corp.supernews.com>   G 20 pages in People !!  Wonder where else these pages will show up.  How # about Mad magazine?  What the heck.   K During the Cubs/Marlins baseball games, hp is trying to get people thinking J about their digital cameras, printers and other personal technology.  That! probably cost a pretty penny too.     1 "Island" <dbturner@islandco.com> wrote in message ) news:voammsea80vs4d@news.supernews.com... J > In "People" Ragazine yesterday (I don't read it honestly) there is a  20& > page Ad for HP Printers and Cameras. > ) > I repeat 20 page Ad, yes, a 20 page Ad.  > : > Yep... shows where HP's concentrating don't you think??? > 0 > It must have cost tens of millions of dollars.G > I think HP is more worried about losing printer business to DELL than  > pushing their REAL systems.  >  >  > DT >  > --   > David B Turner! > Island Computers US Corporation  > 2700 Gregory St., Suite 180  > Savannah GA 31404  > Tel: 912 447 6622  > Fax: 912 201 0402  > Email: dbturner@hpaq.net > http://www.hpaq.net  >  >    ------------------------------  $ Date: Thu, 9 Oct 2003 20:25:47 -0400* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: affordable VMS 2 Message-ID: <vkOdnc9KgNkVYRiiU-KYiA@metrocast.net>  ; "Mike Bartman" <omni@foolie.omniphile.com> wrote in message 2 news:2m57ovom919tfbehmp8b7t13dk8aagq17s@4ax.com...   ...   D > Yes, it's sad.  The real problem is managers who aren't fit to runE > their companies.  If they knew anything about what they were doing, ? > they'd know about Bidder 3, get curious about the low-problem H > airports, or start asking questions of those who did when they see allC > the problems they are having with theirs...and then LISTEN to the 
 > answers. > F > Instead, they read BOTASMs[1], and do what everyone else seems to beG > doing (according to the BOTASMs), and make lots of "penny wise, pound F > foolish" decisions, over the objections of the technical specialistsF > who DO know better (or once did) and hire more managers who are justH > as clueless as themselves to try to fix it all, while firing those who > they wouldn't listen to   J Unfortunately, the above is just as accurate a description of vendors such* as HP as it is of some of their customers.   - bill   ------------------------------  $ Date: Thu, 9 Oct 2003 21:02:01 -0400* From: "Bill Todd" <billtodd@metrocast.net>; Subject: Re: EVA question: How many vdisks should I create? 2 Message-ID: <jhmdnYCA-e2XmBuiU-KYiQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:p91EPr7gxnKJ@eisner.encompasserve.org...    ...   I > > So if you have one LUN on an EVA (still taking Windows here), you can J > > have (1 x 32) pending IO requests.  If you create ten LUNs on the sameH > > EVA and present them to the same Windows box, now you can have (10 x+ > > 32) pending IO requests on that system.  > >  > < > But how many IOs is the system working on while waiting on > IO?   G I think his point was that if the OS itself limits the number of active I requests queued to a single LUN, then if your workload could benefit from K more concurrent I/O and the EVA has enough disks to support more concurrent J I/O (or even just can optimize request orders and thus improve throughput)H it makes sense to spread the I/O across multiple LUNs to work around the OS-imposed constraint.   > J > > *This* is why I originally asked the question about having one LUN vs. > > many LUNs. > > H > > On a Windows system or Tru64 system, you want *more* LUNs so you can > > throw more IOs at an EVA.  > >  > 5 > Smart (most) RDBMS systems run with queue length of 6 > 1.  You want 1 (not 30) pending IOs so you are using2 > the IO system to its fullest but NOT killing it.  J If you have, say, 60 disks hiding in the EVA, I don't see why you wouldn'tK want at *least* 60 concurrent requests outstanding (if that many were ready I to be submitted, of course).  Even more, if they're ready to be submitted K and the EVA can use them to queue-optimize at the individual disk level and  improve throughput further.      VMS backup@ > is a beast, it throws as many IOs at the IO system as you have= > the account tuned for.  I think you know that.  Point is... ? > you are mixing up outstanding IO requests with IO throughput.   J When queue-optimization can be applied, outstanding I/O requests (from theJ viewpoint of the EVA, anyway) become intimately related to throughput (and5 to some degree with *average* response time as well).    > H > > On VMS, it doesn't matter.  The OS doesn't throttle IO requests likeG > > that (which is why I can bury my HSG80s with VMS 7.3-1 and make the  > > HSG80s go tits-up).  >  > ; > OSes don't do much of anything.  Applications do, whether A > RDBMSes or others like VMS backup.  You buried your HSG80s with 
 > VMS backup.   I Only because the VMS driver handling the LUN allowed you to.  As has been L noted, other OSs may be more conservative (I suspect perhaps because they'reL avoiding situations where a disk will reject a request rather than queue it:K IIRC any disk that supports command-tagged queuing should be able to handle L *at least* 32 concurrent requests, but not necessarily the full 255 requestsJ that the interface allows - and until virtual devices became popular thereJ was very little reason to want to be able to queue more than 32 concurrent requests to a single disk).    ...   < > It makes little sense to send from the OS more IO requests- > if the LUN you are talking to is saturated.   D What do you mean by 'saturated'?  It certainly makes sense to submitJ additional requests even if they can't be satisfied immediately (i.e., allI disks are busy at the time the next request arrives):  that's what allows C individual disks (or higher-level intelligence in the EVA) to start F optimizing request orders (taking into account the head and rotationalK position of the individual disks) to improve overall throughput and average  response time.     Other OSes tryC > to protect you, VMS doesn't and by design.  VMS with a process IO 7 > model doesn't have an IO traffic cop like other OSes.   I It should at the driver level, even if that cop doesn't choose to hold up K his hand:  it should have nothing to do with use of VMS's process-based I/O J model (at least I'd expect that *some* form of software arbitration existsL to coordinate access to the local node's SCSI or FC hardware, and that's theG point - if no higher one exists - at which a local shared request queue  would be maintained).   K Now, in a *cluster* there may not be any *distributed* cop to ensure that a E bunch of nodes don't concurrently submit arbitrarily large numbers of J requests to a single shared device, and it's possible that this is why VMSD doesn't provide throttling similar to other OSs (because it's alwaysE possible that the device may reject a request due to such distributed E overload, hence the OS must be able to handle that situation anyway).    - bill   ------------------------------   Date: 9 Oct 2003 23:09:39 -0500 + From: young_r@encompasserve.org (Rob Young) ; Subject: Re: EVA question: How many vdisks should I create? 3 Message-ID: <O7zYMXbqiWx3@eisner.encompasserve.org>   _ In article <jhmdnYCA-e2XmBuiU-KYiQ@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:  > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:p91EPr7gxnKJ@eisner.encompasserve.org...  >  > ...  > J >> > So if you have one LUN on an EVA (still taking Windows here), you canK >> > have (1 x 32) pending IO requests.  If you create ten LUNs on the same I >> > EVA and present them to the same Windows box, now you can have (10 x , >> > 32) pending IO requests on that system. >> > >>= >> But how many IOs is the system working on while waiting on  >> IO? > I > I think his point was that if the OS itself limits the number of active K > requests queued to a single LUN, then if your workload could benefit from M > more concurrent I/O and the EVA has enough disks to support more concurrent L > I/O (or even just can optimize request orders and thus improve throughput)J > it makes sense to spread the I/O across multiple LUNs to work around the > OS-imposed constraint. >    	Okay.   >>K >> > *This* is why I originally asked the question about having one LUN vs.  >> > many LUNs.  >> >I >> > On a Windows system or Tru64 system, you want *more* LUNs so you can  >> > throw more IOs at an EVA. >> > >>6 >> Smart (most) RDBMS systems run with queue length of7 >> 1.  You want 1 (not 30) pending IOs so you are using 3 >> the IO system to its fullest but NOT killing it.  > L > If you have, say, 60 disks hiding in the EVA, I don't see why you wouldn'tM > want at *least* 60 concurrent requests outstanding (if that many were ready K > to be submitted, of course).  Even more, if they're ready to be submitted M > and the EVA can use them to queue-optimize at the individual disk level and  > improve throughput further.  >   ? 	I know most of the time you are right, so I had to go back and ? 	look at some stats.  You would of course want as many requests @ 	outstanding as you say.  Which makes what Scott say make sense,B 	regarding Unix and Windows.  I am not seeing 300 IOs with a queue: 	depth of 1, I'm wrong there, should not have winged that.  @ 	If Unix and Windows are throttling, Unix can make up for it by < 	striping a filesystem across multiple LUNs.  But if you had@ 	60 disks and a Windows LUN is bound at 32 outstanding requests,A 	it seems Windows can't take advantage of the other 28 drives (or ; 	leaving a lot of IO on the table), or can it?  If so, how?   > 	Additionally, we probably have to start thinking differently.@ 	Queue Depth shouldn't be a bad thing on EVA and confirming thatA 	would be that average IO response time stays low even when queue  	length increases.   >>I >> > On VMS, it doesn't matter.  The OS doesn't throttle IO requests like H >> > that (which is why I can bury my HSG80s with VMS 7.3-1 and make the >> > HSG80s go tits-up). >> >>< >> OSes don't do much of anything.  Applications do, whetherB >> RDBMSes or others like VMS backup.  You buried your HSG80s with >> VMS backup. > K > Only because the VMS driver handling the LUN allowed you to.  As has been N > noted, other OSs may be more conservative (I suspect perhaps because they'reN > avoiding situations where a disk will reject a request rather than queue it:M > IIRC any disk that supports command-tagged queuing should be able to handle N > *at least* 32 concurrent requests, but not necessarily the full 255 requestsL > that the interface allows - and until virtual devices became popular thereL > was very little reason to want to be able to queue more than 32 concurrent > requests to a single disk).  >   
 	Interesting.    > ...  > = >> It makes little sense to send from the OS more IO requests . >> if the LUN you are talking to is saturated. > F > What do you mean by 'saturated'?  It certainly makes sense to submitL > additional requests even if they can't be satisfied immediately (i.e., allK > disks are busy at the time the next request arrives):  that's what allows E > individual disks (or higher-level intelligence in the EVA) to start H > optimizing request orders (taking into account the head and rotationalM > position of the individual disks) to improve overall throughput and average  > response time.  < 	Saturated is weak and vacuous.  Saturated to the point that6 	average IO response is trailing off dramatically with@ 	little throughput gained.  Actual data on the same non-EVA LUN:  - 	Queue Depth  IO size		IOPS		Average Response  	16		2 KB		400		35 ms  	29		2 KB		415		65 ms  	32		2 KB		419		71 ms   C 	Going from Queue Depth 16 to 32 gains little more than 19 IOPS and 8 	yet doubles response time.  EVA should break that mold.   	  >   Other OSes tryD >> to protect you, VMS doesn't and by design.  VMS with a process IO8 >> model doesn't have an IO traffic cop like other OSes. > K > It should at the driver level, even if that cop doesn't choose to hold up M > his hand:  it should have nothing to do with use of VMS's process-based I/O L > model (at least I'd expect that *some* form of software arbitration existsN > to coordinate access to the local node's SCSI or FC hardware, and that's theI > point - if no higher one exists - at which a local shared request queue  > would be maintained).  > M > Now, in a *cluster* there may not be any *distributed* cop to ensure that a G > bunch of nodes don't concurrently submit arbitrarily large numbers of L > requests to a single shared device, and it's possible that this is why VMSF > doesn't provide throttling similar to other OSs (because it's alwaysG > possible that the device may reject a request due to such distributed G > overload, hence the OS must be able to handle that situation anyway).  >   > 	Thanks for the overview.  I realize in hindsight I did not do/ 	good on a couple key points in that last post.   ; 	In a related matter that has me somewhat touchy about this @ 	subject (LUNs, pending IO) I have a vendor that *insists* queue? 	depth greater than 1 is BAD and a sign of a slow IO subsystem. = 	SQL running on Windows as an RDBMS.  The worst part about it D 	is convincing folks that pending IO will happen across OS platforms? 	and is natural during backups (across OSes).  Queue depth of 4 > 	and they get loopy and yet they are doubling their throughput@ 	and average random IO response time is still less than 10 ms.   	Go figure.    				Rob    ------------------------------   Date: 9 Oct 2003 23:23:29 -0500 + From: young_r@encompasserve.org (Rob Young) ; Subject: Re: EVA question: How many vdisks should I create? 3 Message-ID: <$onYksGOl9WN@eisner.encompasserve.org>   a In article <p91EPr7gxnKJ@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:    > 6 > 	Smart (most) RDBMS systems run with queue length of7 > 	1.  You want 1 (not 30) pending IOs so you are using 3 > 	the IO system to its fullest but NOT killing it.   8 	This is wrong.  I had to go back and check notes.  5 to; 	10 for a queue length is more like it and I don't know how ; 	many RDBMS's (in general) that applies to.  Just anecdotal  	on my part.   				Rob    ------------------------------  $ Date: Thu, 9 Oct 2003 15:58:52 -0700* From: "Alder" <MUNDDGNTDYTV@spammotel.com>8 Subject: Re: HGFTP - how to troubleshoot data connection+ Message-ID: <3f85e82c$1@obsidian.gov.bc.ca>   
 Thanks, Andy.   F I appreciate the advantage of non-Windows software and running a LinuxE gateway, but it's just physically impossible under the circumstances.   ( I'll go pester the Window networking ng.   Cheers,    Alder   A "Andy Bustamante" <a_c_bustamante@earthlink.net> wrote in message 6 news:18ghb.9019$o_5.5257@newssvr29.news.prodigy.com...L > I would venture that NAT on the outgoing data connection is not preservingI > port 20. If this is for a home network I'd recommend on of the internet G > gateways (SMC, Netgear, Linksys, 3Comm . . .).  Or you can download a  patch J > for your system from www.redhat.com.  I run Linux on an older AMD for my DSL 
 > gateway. >  >  > -- > Andy Bustamante  > remove the ASCII 95s to reply  >  > 7 > "Alder" <PGDEHMKOKIMD@spammotel.com> wrote in message & > news:q4Kgb.6619$Sg4.4524@edtnps84... > > [Hobbyist alert!]  > > " > > This should be simple, but ... > > J > > Since reinstalling Win2K on my internet gateway system I can't seem toG > > get a data connection to the FTP server from outside my LAN.  I can I > > connect and login just fine, get STAT and SYST results, but directory  > > listings > > L > > To eliminate other possible causes I shut down the ZoneAlarm firewall onE > > the gateway system, but the results were the same.  It also seems L > > unlikely that it's the fact I'm using Internet Connection Sharing on theJ > > W2K box, since connections to my other VMS servers like HTTP and HTTPS > > are working just fine. > > K > > The HGFTP log files aren't too revealing (to me).  Here's an example of H > > me connecting (telnet to remote VMS host, then FTP back from there),J > > running the STAT and SYST commands, then trying a GET of a known file.7 > > The client merely "locks" and eventually times out:  > > D > >   7-OCT-2003 18:40:20.49 Connection accepted for server 00000009I > >   7-OCT-2003 18:40:21.13 Server 00000009 (142.32.2.124) [FTP: Session - > > begins. User=<USERID>, Host=<RemoteHost>] H > >   7-OCT-2003 18:40:42.77 Server 00000009 (142.32.2.124) [FTP: STAT ]H > >   7-OCT-2003 18:40:53.30 Server 00000009 (142.32.2.124) [FTP: SYST ]B > >   7-OCT-2003 18:43:18.77 Connection closed for server 00000009D > >   7-OCT-2003 18:43:18.85 Connection accepted for server 0000000AI > >   7-OCT-2003 18:43:19.39 Server 0000000A (142.32.2.124) [FTP: Session - > > begins. User=<USERID>, Host=<RemoteHost>]  > > C > > Any suggestions on troubleshooting this would be appreciated...  > >  > > GREATLY! > >  > > Thanks for reading,  > > 	 > > Alder  > >  >  >    ------------------------------  % Date: Thu, 09 Oct 2003 20:10:38 -0400 - From: David Turner <davidnospam@hpaq_dot_net>  Subject: Info about HP. Message-ID: <vobu82naa9sb9@news.supernews.com>  ! So far I have seen the following:   G 1) Dec parts source - a place where you could buy Digital/Compaq Alpha  F spares no longer accept calls outside of their contractual obligation.  A 2) HP Field Service can no longer accept ANY purchase orders for  = product, even when it's not on the standard Compaq price file   H 3) A drove of Authorised Resellers are now losing their "right" to sell 
 Alpha systems   C 4) Compaq is now plaming off their non service contract stuff to a  E rather unknown parts reseller (some kind of search company that goes  * into the market and tacks on a percentage)  ' As far as we are concerned, it's great. F Our sales are up over 400% over last year (yes, that includes systems)E We were looking at the reasons and started asking customers how they  ; found us and why they wanted to deal with us over HP/Compaq   I The frightening answer was: We don't have any contacts at HP anymore and  9 can't find anyone who knows anything but PC related info.   H Now I don't want to shoot myself in the foot by offering HP information 4 that will cause us to lose business, but Come On !!!E HP - You need to answer to the customers of DEC/Compaq/HP that spend  8 Hundreds of Thousands of Bucks a year on your equipment.  H A perfect sign of their attempts at dissuading people from buying their < newer Alpha equipment is their drop of 3 to 1 year warranty.5 Hell, we give a 1 year warranty on Refurbished stuff. E Is their product so questionnable in quality now that they only feel  ( safe offering the 12 months of liability    E Yes - I am groaning again but I am watching a whale beach itself and    can't do anything to help it !!!   David (frustrated but thankful)    ------------------------------  % Date: Thu, 09 Oct 2003 20:10:42 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: Info about HP' Message-ID: <3F860712.95B9D5BD@fsi.net>    David Turner wrote:  > # > So far I have seen the following:  > H > 1) Dec parts source - a place where you could buy Digital/Compaq AlphaH > spares no longer accept calls outside of their contractual obligation. > B > 2) HP Field Service can no longer accept ANY purchase orders for? > product, even when it's not on the standard Compaq price file  > I > 3) A drove of Authorised Resellers are now losing their "right" to sell  > Alpha systems  > D > 4) Compaq is now plaming off their non service contract stuff to aF > rather unknown parts reseller (some kind of search company that goes, > into the market and tacks on a percentage) > ) > As far as we are concerned, it's great. H > Our sales are up over 400% over last year (yes, that includes systems)F > We were looking at the reasons and started asking customers how they= > found us and why they wanted to deal with us over HP/Compaq  > J > The frightening answer was: We don't have any contacts at HP anymore and; > can't find anyone who knows anything but PC related info.  > I > Now I don't want to shoot myself in the foot by offering HP information 6 > that will cause us to lose business, but Come On !!!F > HP - You need to answer to the customers of DEC/Compaq/HP that spend: > Hundreds of Thousands of Bucks a year on your equipment. > I > A perfect sign of their attempts at dissuading people from buying their > > newer Alpha equipment is their drop of 3 to 1 year warranty.7 > Hell, we give a 1 year warranty on Refurbished stuff. F > Is their product so questionnable in quality now that they only feel* > safe offering the 12 months of liability > F > Yes - I am groaning again but I am watching a whale beach itself and" > can't do anything to help it !!! > ! > David (frustrated but thankful)   3 You're now sharing in the pain the rest of us feel.   
 Hello, Carly?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  $ Date: Thu, 9 Oct 2003 20:11:53 -0500, From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net> Subject: Re: Info about HP. Message-ID: <voc1qrahpkc57@corp.supernews.com>  K Sounds like they doing all they can to please Wall Street while at the same I time not pleasing an important part of their customer base..  Also sounds E like their long range planning = about 3 months.  Welcome to the 21st  century?  A Perhaps its no surprise their fiscal year ends on Halloween.  ;-)     : "David Turner" <davidnospam@hpaq_dot_net> wrote in message( news:vobu82naa9sb9@news.supernews.com...# > So far I have seen the following:  > H > 1) Dec parts source - a place where you could buy Digital/Compaq AlphaH > spares no longer accept calls outside of their contractual obligation. > B > 2) HP Field Service can no longer accept ANY purchase orders for? > product, even when it's not on the standard Compaq price file  > I > 3) A drove of Authorised Resellers are now losing their "right" to sell  > Alpha systems  > D > 4) Compaq is now plaming off their non service contract stuff to aF > rather unknown parts reseller (some kind of search company that goes, > into the market and tacks on a percentage) > ) > As far as we are concerned, it's great. H > Our sales are up over 400% over last year (yes, that includes systems)F > We were looking at the reasons and started asking customers how they= > found us and why they wanted to deal with us over HP/Compaq  > J > The frightening answer was: We don't have any contacts at HP anymore and; > can't find anyone who knows anything but PC related info.  > I > Now I don't want to shoot myself in the foot by offering HP information 6 > that will cause us to lose business, but Come On !!!F > HP - You need to answer to the customers of DEC/Compaq/HP that spend: > Hundreds of Thousands of Bucks a year on your equipment. > I > A perfect sign of their attempts at dissuading people from buying their > > newer Alpha equipment is their drop of 3 to 1 year warranty.7 > Hell, we give a 1 year warranty on Refurbished stuff. F > Is their product so questionnable in quality now that they only feel* > safe offering the 12 months of liability >  > F > Yes - I am groaning again but I am watching a whale beach itself and" > can't do anything to help it !!! > ! > David (frustrated but thankful)  >    ------------------------------   Date: 10 Oct 2003 04:57:55 GMT From: healyzh@aracnet.com  Subject: Re: Info about HP, Message-ID: <bm5e8j01glo@enews2.newsguy.com>  . David Turner <davidnospam@hpaq_dot_net> wrote:# > So far I have seen the following:   I > 1) Dec parts source - a place where you could buy Digital/Compaq Alpha  H > spares no longer accept calls outside of their contractual obligation.  C > 2) HP Field Service can no longer accept ANY purchase orders for  ? > product, even when it's not on the standard Compaq price file   J > 3) A drove of Authorised Resellers are now losing their "right" to sell  > Alpha systems   E > 4) Compaq is now plaming off their non service contract stuff to a  G > rather unknown parts reseller (some kind of search company that goes  , > into the market and tacks on a percentage)  K You know, this is really depressing.  You make me wonder if I don't want to K Migrate to something better supported such as OpenBSD or Mac OS X, and I'm  M a Hobbyist!  (Though I have purchased hardware and software from DEC/Compaq).    			Zane    ------------------------------  # Date: Thu, 09 Oct 2003 20:13:59 GMT 2 From: "George Pagliarulo" <georgepag@adelphia.net>. Subject: Re: ITRC Download site - some answers2 Message-ID: <bkjhb.6731$he4.6000@news.cpqcorp.net>  , This is a multi-part message in MIME format.  + ------=_NextPart_000_0013_01C38E80.32F80920  Content-Type: text/plain;  	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printable    Ken,/ I think this does what you want.  From the FAQ:   6 3.2 How do I know what the dependencies are for a kit?  6     OpenVMS patches have two types of dependencies,=208     required dependencies which are kits that must be=20;     stalled first, before the target kit gets installed,=20 ?     and optional dependencies, kits that should be installed=20 A     with the target kit but are at the discretion of the user.=20 D     For new OpenVMS kits being issued, both types of dependencies=20>     will be listed at the top of the kit document, in a kit=20D     information header, as well as the usual spots in the body of=20B     the document. When you select a kit for download, if it has=20>     required dependencies, those kits will also be added to=20C     your "shopping cart". The user has the option to remove them=20 B     from the cart (e.g. if the dependent kits have already been=20C     downloaded). Optional dependencies will not automatically be=20 B     added to the shopping cart. The user will have to select them.   George Pagliarulo  george.pagliarulo@hp.com    ; "Ken Fairfield" <My.Full.Name@intel.com> wrote in message = # news:3F8471AD.149C102B@intel.com... & > Jumping into the fray a week late... >=20 > Michael Unger wrote: > =20  > [...]  >=20C > > What about "cross dependencies" of patches? Example, taken from  > > a recent notification: >=20 > <SNIP> >=20@ > > When requesting the VMS731_LAN-V0700 patch there should be aB > > question "Do you want to get the VMS731_PCSI-V0100 patch whichB > > is a prerequisite too?" If the response is "yes" then the PCSI< > > patch will also be downloaded. If there is another patchC > > depending on the very same (i.e., PCSI) patch as a prerequisite 4 > > the question shouldn't be asked again of course. >=20@ > I just wanted to comment that I don't believe that feature hasA > been present in any other patch notification or download system ? > in the past.  If it has, could we have a pointer?  OTOH, this   > would be a nice enhancement... >=20 > -Ken > --8 > I don't speak for Intel, Intel doesn't speak for me... >=20 > Ken Fairfield & > D1C Automation VMS System Support=20$ > who:   kenneth dot h dot fairfield > where: intel dot com+ ------=_NextPart_000_0013_01C38E80.32F80920  Content-Type: text/html; 	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printable   > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =  charset=3Diso-8859-1">9 <META content=3D"MSHTML 5.50.4930.1700" name=3DGENERATOR>  <STYLE></STYLE>  </HEAD>  <BODY> <DIV>Ken,</DIV> ? <DIV>I think this does what you want. &nbsp;From the FAQ:</DIV>  <DIV>&nbsp;</DIV> A <DIV>3.2 How do I know what the dependencies are for a kit?</DIV>  <DIV>&nbsp;</DIV> @ <DIV>&nbsp;&nbsp;&nbsp;&nbsp;OpenVMS patches have two types of = dependencies,=20 </DIV>H <DIV>&nbsp;&nbsp;&nbsp; required dependencies which are kits that must =	 be </DIV> C <DIV>&nbsp;&nbsp;&nbsp; stalled first, before the target kit gets = 
 installed,=20  </DIV>H <DIV>&nbsp;&nbsp;&nbsp; and optional dependencies, kits that should be = installed=20 </DIV>J <DIV>&nbsp;&nbsp;&nbsp; with the target kit but are at the discretion of = the=20 user. </DIV>J <DIV>&nbsp;&nbsp;&nbsp; For new OpenVMS kits being issued, both types of =   dependencies </DIV> H <DIV>&nbsp;&nbsp;&nbsp; will be listed at the top of the kit document, = in a kit=20  </DIV>H <DIV>&nbsp;&nbsp;&nbsp; information header, as well as the usual spots =	 in the=20  body of </DIV>A <DIV>&nbsp;&nbsp;&nbsp; the document. When you select a kit for =  download, if it=20
 has </DIV>H <DIV>&nbsp;&nbsp;&nbsp; required dependencies, those kits will also be = added to=20  </DIV>J <DIV>&nbsp;&nbsp;&nbsp; your "shopping cart". The user has the option to =	 remove=20  them </DIV> H <DIV>&nbsp;&nbsp;&nbsp; from the cart (e.g. if the dependent kits have =
 already=20 been </DIV> F <DIV>&nbsp;&nbsp;&nbsp; downloaded). Optional dependencies will not=20 automatically be </DIV> H <DIV>&nbsp;&nbsp;&nbsp; added to the shopping cart. The user will have = to select=20 them.</DIV>  <DIV>&nbsp;</DIV>  <DIV>George Pagliarulo</DIV>
 <DIV><A=20J href=3D"mailto:george.pagliarulo@hp.com">george.pagliarulo@hp.com</A></DI= V>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>A <DIV><FONT face=3DArial size=3D2>"Ken Fairfield" &lt;</FONT><A=20 < href=3D"mailto:My.Full.Name@intel.com"><FONT face=3DArial=20> size=3D2>My.Full.Name@intel.com</FONT></A><FONT face=3DArial = size=3D2>&gt; wrote in=20 C message </FONT><A href=3D"news:3F8471AD.149C102B@intel.com"><FONT =  face=3DArial=20 I size=3D2>news:3F8471AD.149C102B@intel.com</FONT></A><FONT face=3DArial=20 H size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>&gt; Jumping into = the fray a week=20G late...<BR>&gt; <BR>&gt; Michael Unger wrote:<BR>&gt; &nbsp;<BR>&gt;=20 I [...]<BR>&gt; <BR>&gt; &gt; What about "cross dependencies" of patches? =  Example,=20 B taken from<BR>&gt; &gt; a recent notification:<BR>&gt; <BR>&gt;=20I &lt;SNIP&gt;<BR>&gt; <BR>&gt; &gt; When requesting the VMS731_LAN-V0700 =  patch=20B there should be a<BR>&gt; &gt; question "Do you want to get the=20G VMS731_PCSI-V0100 patch which<BR>&gt; &gt; is a prerequisite too?" If =  the=20A response is "yes" then the PCSI<BR>&gt; &gt; patch will also be =  downloaded. If=20 G there is another patch<BR>&gt; &gt; depending on the very same (i.e., =2 PCSI)=20F patch as a prerequisite<BR>&gt; &gt; the question shouldn't be asked = again of=20eH course.<BR>&gt; <BR>&gt; I just wanted to comment that I don't believe = that=20iE feature has<BR>&gt; been present in any other patch notification or =  download=20t> system<BR>&gt; in the past.&nbsp; If it has, could we have a = pointer?&nbsp;=20tD OTOH, this<BR>&gt; would be a nice enhancement...<BR>&gt; <BR>&gt; = -Ken<BR>&gt;=20e= --<BR>&gt; I don't speak for Intel, Intel doesn't speak for =, me...<BR>&gt;=20B <BR>&gt; Ken Fairfield<BR>&gt; D1C Automation VMS System Support = <BR>&gt;=20tH who:&nbsp;&nbsp; kenneth dot h dot fairfield<BR>&gt; where: intel dot=20 com</FONT></BODY></HTML>  - ------=_NextPart_000_0013_01C38E80.32F80920--e   ------------------------------   Date: 9 Oct 2003 11:01:54 -0700a$ From: gspamtackett@yahoo.com (Galen)Y Subject: Re: Problem with CLUSTER_CONFIG? (was: Re: DIFVOLMNT (%X0072832C), then bugcheckc= Message-ID: <bdc65a53.0310091001.2d9fd727@posting.google.com>i  B HP Support is elevating this issue for us. They say it's generatedC quite a bit of discussion among the maintainers and support people,f? and a lot of suggestions have turned up--each with its own weak- points, of course.   ------------------------------  $ Date: Thu, 9 Oct 2003 20:00:47 -0500, From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>) Subject: Re: Problem with SWCC_CONFIG.com-/ Message-ID: <voc166m2f61ea0@corp.supernews.com>c  J Had the same problem.  Saw this thread and got my hands on v2.5 of the VMSE agent.  2.5-106 to be exact.  Installed it on a DS20E/VMS 7.3-1/HSZ80d? system.  Didn't help.  SWCC_CONFIG still complained about >255.a  B Thinking I must have done something wrong, I removed the agent and  reinstalled v2.5.  Same results.  K I sent a note to a local hp storage guy.  We'll see what he has to say in al
 day or three.         6 "Oliver" <oliver.steeples@compaq.com> wrote in message7 news:e5029990.0310090228.16726c79@posting.google.com...a > This is a known issue. >-@ > The SWCC polling of the storage comes back with a string > 255$ > characters which vms can't handle. >8D > Contact your local HP office and they should be able to supply the$ > latest 2.5 agent which fixes this. > 
 > Regards, >    Oliver  > 6 > PS: SWCC should only be run on 1 node in the cluster >  >p2 > "Mike Naime" <mnaime@kc.rr.com> wrote in message4 news:<005hb.27370$832.8932@twister.rdc-kc.rr.com>...? > > Dave Baxter <dave.baxter@bannerhealth.com> wrote in message ; > > news:a3c44af1.0310080938.787d284f@posting.google.com...eE > > > Can anyone help me here.    I have a two node cluster of ES40'saK > > > running OVMS 7.3-1, connected via a SAN setup to two pairs of HSG80's K > > > with 42 drives attached to each controller pair.   Each of the ES40'stF > > > has two HBA's, and is dualpathed to the storage via two separate? > > > fabrics, i.e. Each Host (ES40) has 4 paths to each drive.EJ > > >      The CC Lun's on the two pairs of HSG's are set to 9000 and 9001J > > > and they appear on the hosts as devices $1$gga9000: and $1$gga9001:. > > >4K > > > When I try to run SWCC_CONFIG and add a sub-system (option 8), I give.	 > > > it;  > > >- > > > Subsystem Name: HSG9000a! > > > Device Name:    $1$gga9000: ! > > > Monitoring interval: 5 secss > > >  > > > I then get;a > > > G > > > Adding subsystem: hsg9000, access device: $1$GGA9000:, monitoringm > > > interval: 5.L > > > %DCL-W-BUFOVF, command buffer overflow - shorten expression or command
 > > > line > > > $a > > > ; > > > If I "set verify" and run it again this is what I getn > > >f > > > $write cfile > > L "hsg9000|$1$GGA9000:|5|18|81D11B00PATHBIAS:0017PATH:PGA0.5000-1FE1-0012-1992 > >bL PRIMARY,CURRENT|81D17AC0PATHBIAS:0016PATH:PGB0.5000-1FE1-0012-1991|81D123C0| > >hL 81D123C0PATHBIAS:0002PATH:PGA0.5000-1FE1-0012-1994|81D182C0PATHBIAS:0006PATH > > L :PGB0.5000-1FE1-0012-1993|81D11B00PATHBIAS:0017PATH:PGA0.5000-1FE1-0012-1992 > >rL PRIMARY,CURRENT|81D17AC0PATHBIAS:0016PATH:PGB0.5000-1FE1-0012-1991|81D182C0| > > 81D123Co > > >n > >tL PATHBIAS:0002PATH:PGA0.5000-1FE1-0012-1994|81D182C0PATHBIAS:0006PATH:PGB0.50 > > L 00-1FE1-0012-1993|81D172C0PATHBIAS:0005PATH:PGB0.5000-1FE1-0012-1C13|81D1130 > >wL 0|81D11300PATHBIAS:0005PATH:PGA0.5000-1FE1-0012-1C14|81D18AC0PATHBIAS:0015PA > >sL TH:PGB0.5000-1FE1-0012-1C11|81D172C0PATHBIAS:0005PATH:PGB0.5000-1FE1-0012-1C > >-L 13|81D18AC0|81D11300PATHBIAS:0005PATH:PGA0.5000-1FE1-0012-1C14|81D18AC0PATHB > > IAS:0015PATH:PGB0.50 > > > 0-1FE1-0012-1C11|"L > > > %DCL-W-BUFOVF, command buffer overflow - shorten expression or command
 > > > line > > > $exit: > > > & > > > Does anyone have any suggestions > > > > > Yes, scrap the SWCC GUI stuff and use the CLI interface to monitor/programLJ > > your HSG's.  You can connect the console ports of the Alphaservers and HSG'sqJ > > to a Decserver700, or some such similar device, and access it remotelyL > > through the Telnet Listener service.  Something like ConsoleWorks allows youmI > > to have remote access, share the access, as well as scanning/alerting  for : > > problems/errors on the systems.  Ours runs on a DS10L. > >  > >t > > > Thanks > > >  > > > Dave Baxtere   ------------------------------  # Date: Fri, 10 Oct 2003 02:24:37 GMTa# From: "John Smith" <a@nonymous.com>r Subject: Sickening, isn't it?iK Message-ID: <FLohb.269357$Lnr1.175241@news01.bloor.is.net.cable.rogers.com>e  J It reads almost exactly like a Microsoft press release, but that's not the> most sickening thing about the following Reuters 'news' story.  D The most sickening thing is that the lame excuse for a VMS MarketingJ Department does zero, zilch, nichts, nada, zip, gornischt, and squat aboutK marketing VMS even when Reuters seems so desperate for material to send out  over the newswires.u   The mind boggles......    L http://story.news.yahoo.com/news?tmpl=story&cid=569&ncid=738&e=1&u=/nm/20031$ 009/tc_nm/tech_microsoft_smallbiz_dc    0 Microsoft Unveils Small Business Server Software Thu Oct 9, 2:45 PM ETb   By Reed Stevensone  D SEATTLE (Reuters) - Microsoft Corp. (Nasdaq:MSFT - news) on ThursdayL unveiled new server software that it said gives smaller firms the ability to= run big-business computer systems for a fraction of the cost.t  L The introduction is part of a push by Microsoft to sell up to $10 billion in4 software to small business by the end of the decade.  L Microsoft said at an annual conference in New Orleans that gathers the 5,500I resellers, dealers and consultants who sell its software that the Windows J Small Business Server offering was designed to allow smaller businesses toA implement cheap and effective corporate computer systems quickly.q   ....G While Linux is free, it requires constant upkeep and maintenance, AyalahJ said. By contrast, the Small Business Server software, for example, can be! set up in 15 minutes, Ayala said.r     ...more....b    H Instead of dedicating different computers to different server tasks, theG Small Business Server software is designed to be loaded onto one serveryI computer with networking, e-mail, secure Internet tools, file and printern@ sharing, as well as backup capabilities straight out of the box.   ------------------------------  # Date: Thu, 09 Oct 2003 21:44:28 GMTa# From: "John Smith" <a@nonymous.com>n0 Subject: Re: SKHPC's view on the port to ItaniumG Message-ID: <0Fkhb.158975$3r1.790@news02.bloor.is.net.cable.rogers.com>l   Didier Morandi wrote:e > From:qH > http://www.hp-interex.org/site/cms/contentviewarticle.asp?article=1852 >k > ---[start]---o > Any Port(s) in a Storm >uF > "For those interested in VAX/Alpha/IPF mixed-mode clusters, or thoseE > concerned that their ancient VAX code wont run on Itanium systems,tG > theres good news: it seems that it will be possible to most VAX codeaG > directly to Integrity (the new name for IPF-based systems.). Also, itsH > will it be possible to translate native VAX code to IPF either with orF > without an intermediate step through SRIs CHARON-VAX. As of currentG > plans, customers can translate their aging VAX apps and code from VAX.A > to Alpha using the old VEST/ DECmigrate tool, and they can then G > translate their translated code to Itanium using the Alpha to Itanium ? > translator which SRI has developed for us. SRI has considered G > developing a direct VAX to Itanium translator tool, but that would beME > under their own funding. So under current plans, HP will have toolssG > that allow customers to translate code from VAX to Itanium. This will G > be a two-step process, but HP opted for this technique to ensure thathE > translated code on Alpha today could then be translated to Itanium,uE > thus reassuring the VAX community that they have not been forgottenf. > or cast aside by HP or OpenVMS Engineering". >n > Terry Shannon, SKHPC
 > ---[end]---  >i6 > Terry, I love the "by HP or OpenVMS Engineering" :-)    % Wild Rumor and Innuendo Mongor Dept.:eI Since HP and OpenVMS Engineering are mentioned separately and distinctly,tH and that a writer's words are carefully chosen, can this mean that HP is* thinking of spinning off OpenVMS?  YES!!!!   ------------------------------  # Date: Fri, 10 Oct 2003 03:48:37 GMTr2 From: "Ken Farmer" <KFarmer@NOSPAM.SpyderByte.com>- Subject: SKHPC: Howard Elias Emigrates to EMCi< Message-ID: <p_phb.41703$xB4.15021@twister.southeast.rr.com>  9 http://www.openvms.org/stories.php?story=03/10/09/6710787r   -- Kenneth Farmer  <><y 336-736-7376B SpyderByte Network of Technical Portals, http://www.SpyderByte.com    EnterpriseUnix.org  |  Tru64.org OpenVMS.org  |  dcl.OpenVMS.orgi$ EnterpriseLinux.org  |  LinuxHPC.org ShannonKnowHPC.org   ------------------------------  % Date: Thu, 09 Oct 2003 20:20:01 -0400t+ From: John Johnstone <jj_usenet2@yahoo.com>  Subject: Re: SMTP receiver logss) Message-ID: <3F85C2F1.7074E4AD@yahoo.com>n   sms@antinode.org wrote:  > - > From: John Johnstone <jj_usenet2@yahoo.com>n > L > > > > Having multiple (possibly unlimited?) occurrences of the field names- > > > > works around the 500 character limit:f > > > N > > >    Hmmm.  Seems to work.  Thanks for the useful info.  Was this clear in > > > the documentation? > >r? > > It's in there at 17.6.1 but I did miss it initially though.p > % >    If you say so, but all I see is:r > G >       Or specify each value as a separate instance of same field. Foro >       example: > 1 >       Field1: Item1 Field1: Item2 Field1: Item3  > ! >       An alternative format is:  > # >       Field1: Item1, Item2, Item3  > H > and neither of those suggests multiple lines of "Feild1" values to me. > (I'm looking at M > "http://h71000.www7.hp.com/doc/73final/6526/6526pro_031.html#index_x_716".)t  G Looking at the HTML formatted version, I see that there is a differencetD between what is shown there and the printed hardcopy that I have.  IG printed either the PDF or PS version and it shows the "Field1" items asrF three lines rather than all on one line that the HTML shows.  It looksD like either there was a bug in the way that the HTML got rendered or0 there was a revision made in the PDF/PS version.   > G > > >    And speaking of the documentation, does anyone actually have acI > > > "SMTP_CONFIG.TEMPLATE" file, as advertised therein?  I seem not to.o > >yK > > Running tcpip$config to enable the SMTP service should extract the filee6 > > from sys$library:tcpip$templates.tlb and put it in > > sys$specific:[tcpip$smtp]. > I >    Ah.  As I upgraded from TCPIP V5.1, and the SMTP service was alreadypD > "Enabled  Started", I saw no reason to run TCPIP$CONFIG.COM again. > . > >   You could do that manually.  The file in > > the TLB is smtp_config.e > " >    Right you are.  Thanks again. > @ >    And one more complaint, while I'm in the mood.  Starting atJ > "http://h71000.www7.hp.com/doc/index.html", I'd've thought that a searchE > through "hp OpenVMS systems" for "smtp.config" would've done betterw > than:  > $ >                     search results > 0 >                     from openvms systems sites > < >                     No results were found for your search. > A > I can't remember the last time I did a search there which found  > anything.  > J > ------------------------------------------------------------------------ > 6 >    Steven M. Schweda               (+1) 651-699-98185 >    382 South Warwick Street        sms@antinode,orgo >    Saint Paul  MN  55105-2547v   ------------------------------  # Date: Thu, 09 Oct 2003 23:24:42 GMTi6 From: "Andy Bustamante" <a_c_bustamante@earthlink.net>/ Subject: Soap Toolkit and alternate web serversl< Message-ID: <_6mhb.13347$FW.3746@newssvr25.news.prodigy.com>  I Has any successfully used the OpenVMS Soap toolkit with either the OSU ori WASD web servers?e   -- Andy Bustamantea remove the ASCII 95s to reply    ------------------------------  # Date: Thu, 09 Oct 2003 21:53:49 GMT # From: "John Smith" <a@nonymous.com>> Subject: Re: Sun takes a hitJ Message-ID: <NNkhb.158977$3r1.129754@news02.bloor.is.net.cable.rogers.com>   Tim Shoppa wrote: # > Andrew Harrison SUNUK Consultancyk: > <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message. > news:<bm3a9j$kbb$1@new-usenet.uk.sun.com>...E >> In the circumstances Oracles possition is entirely understandable.n >iG > Not really.  They're losing lots of sales because they want the worldiF > to adapt to them.  Sure, there are customers who are clueless enoughA > to just bend to Oracle's whims and build their whole enterpriseg+ > computing system around what Oracle says.d >cH > But the rest of us realize there are alternatives which do not involve' > strapping ourselves to Oracle's mast.e    # Perhaps just Microsoft's mast then.    ------------------------------  $ Date: Thu, 9 Oct 2003 19:48:48 -0400* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Sun takes a hit2 Message-ID: <pMednfa_pp9AbhiiU-KYgg@metrocast.net>  . "John Smith" <a@nonymous.com> wrote in messageE news:jvBgb.249704$Lnr1.121845@news01.bloor.is.net.cable.rogers.com...n   ...w  I > Given the state of the computing market at the time the Compaq deal was E > thought about, consumated, and still remains, HP would have, in alloJ > likelihood, been  as profitable or unprofitable today (depending on your= > perspective) as it would have been without the Compaq deal.f  K Nope - it would not only have been more profitable without the Compaq deal, 8 but its future prospects would have been better as well.  E The merger/acquisition made customers nervous about *both* companies' I product lines and lost sales (and not a few long-standing customers) as a  result.c  H The product lines that actually *were* declared dying as a result of theL merger (or immediately before it, as happened with Alpha) took an additionalF major revenue hit but without much immediate compensating cost savings* (Tru64 expenses are *still* winding down).  G The brouhaha of the merger prevented Carly from getting fired (which issH still the only thing that can possibly save HP, if it happens before sheI completes flushing all its intrinsic worth down the toilet, and of courseeL was almost certainly a powerful incentive for both her and Curly - who wouldK also almost certainly have otherwise been fired, letting HP make hay out ofsI Compaq's customers while Compaq got its own act back together - to pursues the merger in the first place).f   - bill   ------------------------------  $ Date: Thu, 9 Oct 2003 20:09:04 -0400* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Sun takes a hit2 Message-ID: <A42dnbbj5soAZRiiU-KYvg@metrocast.net>  8 "Tim Shoppa" <shoppa@trailing-edge.com> wrote in message7 news:bec993c8.0310070803.4e75038c@posting.google.com...3K > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>E= wrote in message news:<blu5jl$osa$1@new-usenet.uk.sun.com>...nE > > Exentually you realise that Free Linux is in fact Expensive Linux.D > > unless you think that paying 7.5K over 3 years for SW support on' > > a box that costs 6K is a good deal.h >eK > 7.5K and 6K are both in the noise... unless you're talking about hundredseL > or thousands or tens of thousands of boxes.  If you've got that many boxesL > then you *do* go with the open-source alternative and self-support becauseH > you have all the sources and you built from them.  (Or at least that's > what I hope happens!)   D While I don't really care to enter any portion of my anatomy in thisI particular pissing contest, I've just got to ask:  how did the supposedly I direct quote from Andrew above get its 7500K figure (at least that's what K his post contains in the copy on *my* news server) get magically changed tonI 7.5K - and why didn't Andrew complain about it in his later response (hissL point presumably having been that supporting even a single inexpensive LinuxG box can cost a hell of a lot of money in certain circumstances, a point1L which your response completely ignores by virtue of having changed the value	 to 7.5K)?i   - bill   ------------------------------  $ Date: Thu, 9 Oct 2003 22:18:29 -0400* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Sun takes a hit2 Message-ID: <7ZKcnWSFS6BvixuiU-KYiQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:5DbD7SvsqgCc@eisner.encompasserve.org...a   ...   D > Sun is dying.  Itanium is getting started.  Compare the two a yearD > from now, and two years from now.  You can be assured that ItaniumG > will be growing far faster than Sun and Sun will *still* be shrinkingi/ > (if it exists at all, i.e. isn't taken over).t  L Still vigorously selling futures, eh, Rob?  For a good laugh, you might wantI to re-read Gordon Haff's (of course laudatory) Illuminata article on HP'su- zx1 Itanic chipset written in February, 2002:a  C "2002 is the year that McKinley will come to market.  The first IPF C processor [Merced] is deployed primarily as a development and pilotnK platform.  Look for McKinley to be the CPU that starts the ball rolling for2I IPF processors in serious production roles.  As the McKinley action heatsr% up, so will the IPF world as a whole.T  J "But to say that McKinley will help break IPF-based systems out of a 'kickG the tires' mode begs a question:  Where will the breakouts take place?"     J Where indeed, Rob?  The answer, of course, was "Nowhere" - and that answerL doesn't seem to have changed much even with the introduction of Madison thisJ year (which is hardly all that surprising, given that Madison was requiredK just to maintain the competitive position that McKinley achieved:  the restt+ of the world wasn't standing still either).   L So the "McKinley action" (or more accurately the lack of it) certainly neverH 'heated up', and neither did "the IPF world as a whole" - it's been moreC like a *black* hole, consuming all the hardware engineers, compilereK engineers, and funding that got thrown at it without even an audible belch.2  L But facts are just *so* annoying if you can still find people willing to buy futures, aren't they?o   - bill   ------------------------------   Date: 9 Oct 2003 11:54:56 -0700s' From: n.rieck@sympatico.ca (Neil Rieck)  Subject: Re: TSM on Alpha-= Message-ID: <a5396d5d.0310091054.642b38db@posting.google.com>i  Z huber@mppmu.mpg.de (Joseph Huber) wrote in message news:<ENYQRtgSaATt@vms.mppmu.mpg.de>... [ snip ] > P > Maybe the TSM source has to be updated to accept newer interfaces, I think the# > freeware one is with sources (?).r; > Worst case You have to change from decnet-IV to decnet-V:t > On my alphas, it looks like: >  > Terminal Server Manager V2.1G > Copyright  Digital Equipment Corporation. 1994. All Rights Reserved.  > Usage is DIRECTORY > TSM> show server tskele > > Server:         TSKELE             Circuit(s):      CSMACD-0 >  > A > And it always works, because the circuits are always  CSMACD-n,e% > independent of hardware interfaces.s  E Unfortunately, TSM is no longer supported. It would be cool of HP didnC release the source code, otherwise they should make one more changetE which would allow new interfaces to be added just like they currentlyuD allow new terminal server types. (or don't do any validation at all)  
 Neil Rieck! http://www3.sympatico.ca/n.rieck/t   ------------------------------   Date: 9 Oct 2003 12:04:57 -0700n. From: dieter.rossbach@gmx.de (Dieter  Ro?bach) Subject: Re: TSM on Alphat= Message-ID: <e1d40caf.0310091104.429f8524@posting.google.com>s  B TSM is to old and out of support, newer interfaces are unknown andE nobody will add them in the future. There is only one solution if youi want to stay with decnet IV:    ! $ set def sys$sysroot:[decserver]b  $ analyse/rms/fdl tsm$config.dat $ edit tsm$config.dat 9 --- Replace the interface definition to the right one ...i: $ convert/fdl0tsm$config.fdl tsm$config.dat tsm$config.dat  ; Now TSM can connect to your terminalserver and maintain in i   Dieter   ------------------------------  % Date: Thu,  9 Oct 2003 22:56:27 +0200 5 From: "GWDVMS::MOELLER" <moeller@gwdvms.dnet.gwdg.de>n2 Subject: Re: Vax / VMS V5.5-2 External Drive Issue. Message-ID: <E1A7hpj-0006hl-CT@mailer.gwdg.de>  / From: Chris Scheers <chris@APPLIED-SYNERGY.COM>f > sms@antinode.org wrote:83 > > From: Chris Scheers <chris@applied-synergy.com> L > > > There is also a problem if the INQUIRY string returned by the drive isI > > > too long.  I forget what the limit is, but I have seen it with somed< > > > Seagate drives.  I don't know of an easy fix for this. > >oK > >    That's a console problem, not a VMS problem.  On a VAXsta 3100 modelsA > > 30/40/38/48 (and the 2000?), "TEST 50" showed an error statussI > > ("000000D4") for such drives, which is enough to inhibit an automaticsG > > boot, though the drive may work just fine when the system is bootedp
 > > manually.s > >iK > >    The closest thing to a fix is a revised set of firmware EPROMs, data I > > for which exist, but you need an EPROM programmer (and EPROMs, unless%" > > you want to live dangerously). > >m< > >    Again, it's probably not a problem on a later system. >[...]M > I have EPROMs and a burner.  Where can I get this update? (For a VS3100-38)   D Seems I never "published" the patch, due to underwhelming demand ...  I On the Vs3100 /3x and /4x, the SCSI self-test resides in the "option ROM" I on the SCSI option board; on the /76 it's contained within the boot ROMs.a& ROM version is displayed with "T 50".   3 I do have the patch for option ROMs saying "V1.30" p8 (both the floppy/SCSI-A and the SCSI-A/SCSI-B variant), . and for the Vs3100/76 where T 50 says "V1.60".  5 I also know of a SCSI-A/SCSI-B option ROM "V1.58" bute: so far(!) had no incentive to disassemble & patch that one9 (no big surprises expected, but it's been some time ...).s   What version do you have?    ***a  2 Trouble with the ROM patches (these plus those to 3 allow for boot disks > 1 GB) is, that there are so u1 many ROM versions around ... it'd be much simplero0 to just distribute some known working ROM image.  0 In the past, I refrained from "publishing" ROMs % due to DEC's copyright. Any opinions?    ***a  6 BTW, my V5.5-2 DKDRIVER patch (as published years ago,5 and now quoted by Robert Byer) still can be found in w  " 	ftp://ftp.gwdg.de/pub/vms/dk-552/  B Vs3100 ROM patch "teaser" kit (do contact me in case of interest -2 I have it in constant use with 2G and 4G disks) in  " 	ftp://ftp.gwdg.de/pub/vms/dk-552/   Vs2000 SCSI disk stuff ins    	ftp://ftp.gwdg.de/pub/vms/pk2k/  H (and no, the Vs2000 SCSI self tests don't go up to "D4", so won't fail).   Regards,M Wolfgang J. Moeller, Tel. +49 551 201-1516/-1510, moeller@gwdvms.dnet.gwdg.demM GWDG, D-37077 Goettingen, F.R.Germany     |    Disclaimer: No claim intended!aM http://www.gwdg.de/~moeller/ ---- <moeller@gwdg.de> ---- <w.moeller@ieee.org>   # Example for the terminally curious:.P --------------------------------------------------------------------------------: KA420ROM-SCSIB_130.BIN /abs /out=KA420ROM-SCSIB_130-D4.BIN !a9 ! fix Vs3100 "SCSI-A V1.30 / SCSI-B V1.30" option ROM ...i: ! ... so as to avoid SCSI disk "000000D4" self-test errorsB ! ... caused by comparing a good INQUIRY response (127 bytes max.)A ! ... to one that has been overwritten starting at the 65th byte.o !l, ! w.j.m. 25-may-1999, after KA420ROM-STRG-D4 !i !o verify/long/ascii 0003Cr 'SCSI' '-A  ' exit !u& replace/word 00034		! "SCSI-A" version4 +00001				! major (1 hex digit - only "1" seen here)% +00030				! minor (2 or 1 hex digits)n exit# +00005				! bump major version to 5e +00030 exit !y verify/long/ascii 000BCy 'SCSI' '-B  ' exit ! & replace/word 000B4		! "SCSI-B" version4 +00001				! major (1 hex digit - only "1" seen here)% +00030				! minor (2 or 1 hex digits)t exit# +00005				! bump major version to 5s +00030 exit !d !  def t6_unit_finish = 000013F3t !g verify/inst 000013B2 '	ASHL	#8,R2,R2'F '	ADDL2	I^#00000080,R2'	! INQUIRY data are at 0u80 (within DMA buffer)F '	ADDL2	I^#202D0000,R2'	! STATUS (byte) at 0uC0, MSG_IN (byte) at 0uE0A '	MOVAL	W^0080(R7),R4'	! point R4 to counted non-DMA INQUIRY dataaC '	MOVZBL	(R4)+,R1'	! R1 := length (limited to 007F by SCSI command) ) '_13CC:	CMPB	(R4)+,(R2)+'	! compare bytesh" '	BNEQ    _13D6'		! br on mismatch '	SOBGTR  R1,_13CC'	! loop '	BRB	_13DE'		! br on matchr@ '_13D6:	MOVB    #0D4,B^8(R7)'	! mismatch => unit status ttssmmD4 '	BRW     t6_unit_finish'y@ '_13DE:	MOVB	#1,B^8(R7)'	! all tests ok => unit status ttssmm01  exit !m replace/inst 000013B2+4w '	ADDL2	#00000080,R2't '	ADDL2	#202D0000,R2'y '	MOVAL	W^0080(R7),R4' '	MOVZBL	(R4)+,R1' exit6 '	ADDL2	#202D0080,R2'	! (both ADDL2 combined into one) '	MOVAL	W^0080(R7),R4' '	MOVZBL	(R4)+,R1'8 '	BICL2	#0FFFFFFC0,R1'	! limit byte count to at most 63. exit !e update exitP --------------------------------------------------------------------------------M Wolfgang J. Moeller, Tel. +49 551 201-1516/-1510, moeller@gwdvms.dnet.gwdg.deAM GWDG, D-37077 Goettingen, F.R.Germany     |    Disclaimer: No claim intended!.M http://www.gwdg.de/~moeller/ ---- <moeller@gwdg.de> ---- <w.moeller@ieee.org>d   ------------------------------   Date: 9 Oct 2003 13:10:09 -0500d; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)s. Subject: Re: What is the performance of iVMS ?3 Message-ID: <v88hVJvq$MeP@eisner.encompasserve.org>a  /  "John Smith" <a@nonymous.com> wrote in messagemD  news:SeUgb.143438$3r1.40430@news02.bloor.is.net.cable.rogers.com... >wM > On the one hand the fact that a test system of any sort is 'available' is ao
 > good thing.e >uK > On the other hand, having a test system publicly available which performsuH > more poorly than the current 'state of the art' IA64 system does HP no > service whatsoever.   D    Make up your mind, either it's a good thing or it does no service    whatsoever.  G    I think it does a lot of good for HP.  Potential customers can starteD    working with it now, instead of waiting for a production release.F    They can actually log onto VMS I64 and see for themselves that yes,E    VMS is VMS is VMS, ...  They can actually investigate some portingaF    issues.  They can actually see that although it's not optimized for8    performance, has debug code running, ... it's no dog.  A    For me, just logging on to it has been an important step as iteE    demonstrates first hand that the thing is real.  I've already beengG    through a bunch of utility code and build files and changed a lot oflF    #ifdef __alpha to #ifndef __vax, in places I didn't even realize I H    had, and I've seen for myself that that really does make things work.  H    That's why I was one of the people who asked for something like this,%    and that's why I'm glad HP did it.u   ------------------------------  # Date: Thu, 09 Oct 2003 21:52:25 GMT # From: "John Smith" <a@nonymous.com>d. Subject: Re: What is the performance of iVMS ?H Message-ID: <tMkhb.158976$3r1.5152@news02.bloor.is.net.cable.rogers.com>  I I, and we here all understand that. But when the PHB (pointy-haired boss)dI asks 'How'd your test on that IA64 thing go?' and you answer 'It was slowsI but that's to be expected at this stage of the VMS port and on the box itr3 was running on.', the PHB only hears "It was slow".m  H No offense to you Fred, but it's a myriad of things that HP collectivelyI needs to do to portray VMS as positively as possible, and having the beta L versios of the VMS port running on the fastest hardware is a step along thatJ road. VMS can't afford to lose ANY customers, for any reason. How freakin'H hard is it to get the fastest box installed? And I hope to hell that youK aren't going to say that it needs to go through the Priorities and PlanningsI Committee that meets once per quarter on Tuesdays but only if the moon iss full.r  L Please ask to have the beta/in-progress 'test drive' always available on the currently fastest machine.   Thanks.          Fred Kleinsorge wrote:G > We are torn about trying to the the "right" thing.  We want people to F > be able to try things, port things, check it out - as soon as we canB > get them stuff that works.  But we don't want it used to club usD > bloody about performance - which we EXPLICITLY have NOT addressed.< > The release is built mostly unoptimized.  Debug stuff likeF > SYSTEM_CHECK are enabled.  The compiler back-end generates Itanium-1 > optimized code.a >0F > Drawing conclusions about V8.0 performance to the production releaseG > in 2004, would be like using Alpha V1.0 Beta as a characterization ofI > Alpha VMS performance. >i >n >/0 > "John Smith" <a@nonymous.com> wrote in messageE > news:SeUgb.143438$3r1.40430@news02.bloor.is.net.cable.rogers.com...H >>= >> On the one hand the fact that a test system of any sort is  >> 'available' is a good thing.t >>C >> On the other hand, having a test system publicly available whichVG >> performs more poorly than the current 'state of the art' IA64 systemDG >> does HP no service whatsoever. Early opinions and judgements will beyG >> formed on the basis of the lesser system. HP should be ensuring thatnF >> the very 1st machine of each iteration is available for public testD >> drives to ensure that the opportunity exists to put its best foot) >> forward at the earliest possible time.e >>B >> Many managements will take the test result you garner from thisE >> slowpoke system and say 'That's what the numbers say - the numbers/G >> don't lie. I have to justify our future direction based on facts noteF >> HP promises.' It may be short-sighted, it may be wrong, but it does
 >> happen.   ------------------------------  % Date: Thu, 09 Oct 2003 16:21:32 -0700t+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>t. Subject: Re: What is the performance of iVMS ?# Message-ID: <3F85ED7C.709@MMaz.com>o   John Smith wrote:=  J >I, and we here all understand that. But when the PHB (pointy-haired boss)J >asks 'How'd your test on that IA64 thing go?' and you answer 'It was slowJ >but that's to be expected at this stage of the VMS port and on the box it4 >was running on.', the PHB only hears "It was slow". > I >No offense to you Fred, but it's a myriad of things that HP collectivelyeJ >needs to do to portray VMS as positively as possible, and having the betaM >versios of the VMS port running on the fastest hardware is a step along that&K >road. VMS can't afford to lose ANY customers, for any reason. How freakin'.I >hard is it to get the fastest box installed? And I hope to hell that youDL >aren't going to say that it needs to go through the Priorities and PlanningJ >Committee that meets once per quarter on Tuesdays but only if the moon is >full. >"M >Please ask to have the beta/in-progress 'test drive' always available on thee >currently fastest machine.A >l >  i >3E Speaking of test drives, there was an Encompass query as to how more iF value could be brought to the user group community.  Does anyone else H see the merit in allowing subscribed, paid members, the ability to have I access to the alpha/beta program (and presumably the released product in tH the future), at their own choosing and risk, without support, under the E terms of a non-Production type license even, with maybe the only two 2E caveats being that the user can report bugs, flaws, irritations, and  G that the same the user cannot discuss these findings (ie. NDA) outside  E of HP and possibly a closed Encompass forum designated just for this?     I One point that still seems apparent is the generation of interest in VMS  H on the I2 as well as good will within the VMS community.  It would seem D that for those who are staunch VMS folks, that enjoy rolling up the D sleeves and getting the 'ol handles dirty, this would generate good H will, perhaps even commercial interest within the sites doing this, and G a sense that HP is extending or reaching out to the VMS community that a is so alienated..e     Any thoughts on that?i     Barry    -- o  > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                        e   ------------------------------  # Date: Thu, 09 Oct 2003 23:08:11 GMTD& From: Rick Jones <foo@bar.baz.invalid>. Subject: Re: What is the performance of iVMS ?2 Message-ID: <vTlhb.6752$Gu4.4552@news.cpqcorp.net>  " John Smith <a@nonymous.com> wrote:E > I, and we here all understand that. But when the PHB (pointy-haired0D > boss) asks 'How'd your test on that IA64 thing go?' and you answerF > 'It was slow but that's to be expected at this stage of the VMS port@ > and on the box it was running on.', the PHB only hears "It was > slow".  F Would the better answer be "The test ran fine." without any mention ofA speed? The purpose of that system is, IIRC, to test functionality  right?  = > Please ask to have the beta/in-progress 'test drive' alwaysu- > available on the currently fastest machine.   D Even if it were the fastest machine, I would think that the presence@ of all the debug stuff in the beta bits would still leave it notA running as fast as with final bits, so one is still left with the B question of how to answer the PBH when he asks "How'd your test onD that IA64 thing go?"  Fastest hardware may be a necessary condition,C but it does not seem a sufficient condition to be able to put speedn assesments into the answer.t  
 rick jones -- tG oxymoron n, commuter in a gas-guzzling luxury SUV with an American flageF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...1   ------------------------------  $ Date: Thu, 9 Oct 2003 21:47:44 -0400* From: "Bill Todd" <billtodd@metrocast.net>. Subject: Re: What is the performance of iVMS ?2 Message-ID: <MxicnR2JOK4gkhuiXTWJiw@metrocast.net>  6 "Hans Vlems" <hvlems.nieuw@zonnet.nl> wrote in message3 news:bm0lg8$g6lhm$1@ID-143435.news.uni-berlin.de...  >y; > "JF Mezei" <jfmezei.spamnot@istop.com> schreef in berichti% > news:3F83BEA2.E7681027@istop.com...0 > > Hans Vlems wrote:tJ > > > Based on the (in)famous VUPS DCL utility the 2600 that is accessible to > the H > > > internet runs at 166 Vups. That's about the performance of an EV56	 > runninge > > > at 400 MHz.t > >dG > > Yes, be we are constantly told to wait for the next generation IA64  whichp > willH > > provide much better performance. IA64 will eventually exceed Alpha's > speed. By I > > then however, the future might be clearer with regards to Intel going  forr > a 647 > > bit 8086, so IA64's perfornance will be quite moot.  > >CJ > > My gut tells me that most VMS customers will not migrate to IA64, they > will& > > migrate from Alpha to 64 bit 8086. >aL > According to Intel (during the dutch VMS tech. upd. days) the IA64 will be4 > speeded up considerably within the next 24 months.  J I'd love to hear more details about that:  everything I've heard indicatesG that the *only* performance advances in that time frame will be  1) the0I addition of another 3 MB of on-chip L3 cache to Madison next year, likelyWK with a 10% increase in clock speed (to 1.65 GHz),  2) the introduction next L year of HP's dual-chip module (this won't improve Itanic performance at all,J but will allow more of them in a more compact configuration, assuming thatJ you can cool it adequately), and  3) the process-shrink to 90 nm. with theH introduction of Montecito in 2005 (which will effectively just double upI everything on the chip, but which may not be able to increase clock ratesEK much over next-year's values without significantly exceeding the 130W power,F envelope which McKinley/Madison/Montecito supposedly are limited to by. design, unless one of the cores is left idle).  I So unless you're willing to throw away one of the cores on your Montecito9K chip to allow the other one to clock faster there may very well not be much0K performance increase at all (save for any possible compiler advances, whichPI aren't coming nearly as thick and fast as the more optimistic of Itanic's D advocates had predicted) until 2006-7, when the Alpha team makes itsJ contribution with the 'Tanglewood' product (probably in 65 nm., reportedlyI with 8 cores on the chip - but little other information is yet public, ineK particular whether they're creating an entirely new core design to help get,# away from the limitations of EPIC).   @ That said, I agree that it's entirely unfair to use the existingF pre-production, unoptimized, instrumented system to try to predict VMSE performance on Itanic - and still would be even if it were a high-end K Madison box (which of course it should be just to avoid the *perception* ofvK slowness as much as possible:  it's not like that would take away a Madisonr sale to a real customer...).   - bill   ------------------------------  # Date: Fri, 10 Oct 2003 02:33:55 GMT-# From: "John Smith" <a@nonymous.com>r. Subject: Re: What is the performance of iVMS ?J Message-ID: <nUohb.269450$Lnr1.36741@news01.bloor.is.net.cable.rogers.com>   Rick Jones wrote:b$ > John Smith <a@nonymous.com> wrote:F >> I, and we here all understand that. But when the PHB (pointy-hairedE >> boss) asks 'How'd your test on that IA64 thing go?' and you answeroG >> 'It was slow but that's to be expected at this stage of the VMS porttA >> and on the box it was running on.', the PHB only hears "It wasa	 >> slow".  >nH > Would the better answer be "The test ran fine." without any mention ofC > speed? The purpose of that system is, IIRC, to test functionalitys > right? >i> >> Please ask to have the beta/in-progress 'test drive' always. >> available on the currently fastest machine. >oF > Even if it were the fastest machine, I would think that the presenceB > of all the debug stuff in the beta bits would still leave it notC > running as fast as with final bits, so one is still left with theiD > question of how to answer the PBH when he asks "How'd your test onF > that IA64 thing go?"  Fastest hardware may be a necessary condition,E > but it does not seem a sufficient condition to be able to put speedn > assesments into the answer.n    I Some of us tend to be far too honest and are more apt to say 'It was slowa7 but that's to be expected at this stage of the VMS portdI and on the box it was running on' than we are to say that 'The test driver, system is the best thing since canned beer'.  K We all understand that with all the debug crap in the o/s it isn't going ton	 run fast.S  C So here's an alternative to HP not providing its LOYAL customers ansI opportunity to test drive the fastest IA64 system with a debug version oftD VMS - how about having a 2nd IA64 running a non-debug version of VMSK available....or can't HP afford that huge additional expense for a group ofuJ customers that bring in $800MM profit to HP (if that any longer) annually?C Seems to me that cost is only about a week's worth of manicures for 
 carly(tm).   ------------------------------  # Date: Fri, 10 Oct 2003 02:35:11 GMTH# From: "John Smith" <a@nonymous.com>s. Subject: Re: What is the performance of iVMS ?K Message-ID: <zVohb.269463$Lnr1.134390@news01.bloor.is.net.cable.rogers.com>e   Barry Treahy, Jr. wrote: > John Smith wrote:8 > F >> I, and we here all understand that. But when the PHB (pointy-hairedE >> boss) asks 'How'd your test on that IA64 thing go?' and you answereG >> 'It was slow but that's to be expected at this stage of the VMS portiH >> and on the box it was running on.', the PHB only hears "It was slow". >>> >> No offense to you Fred, but it's a myriad of things that HPE >> collectively needs to do to portray VMS as positively as possible,iE >> and having the beta versios of the VMS port running on the fastestoC >> hardware is a step along that road. VMS can't afford to lose ANYa@ >> customers, for any reason. How freakin' hard is it to get theE >> fastest box installed? And I hope to hell that you aren't going ton> >> say that it needs to go through the Priorities and PlanningD >> Committee that meets once per quarter on Tuesdays but only if the >> moon is full. >>> >> Please ask to have the beta/in-progress 'test drive' always. >> available on the currently fastest machine. >> >> >>F > Speaking of test drives, there was an Encompass query as to how moreG > value could be brought to the user group community.  Does anyone else D > see the merit in allowing subscribed, paid members, the ability toD > have access to the alpha/beta program (and presumably the releasedA > product in the future), at their own choosing and risk, withoutnF > support, under the terms of a non-Production type license even, withA > maybe the only two caveats being that the user can report bugs, E > flaws, irritations, and that the same the user cannot discuss thesehB > findings (ie. NDA) outside of HP and possibly a closed Encompass! > forum designated just for this?: >3 >MF > One point that still seems apparent is the generation of interest inB > VMS on the I2 as well as good will within the VMS community.  ItA > would seem that for those who are staunch VMS folks, that enjoyyF > rolling up the sleeves and getting the 'ol handles dirty, this wouldG > generate good will, perhaps even commercial interest within the sitesxE > doing this, and a sense that HP is extending or reaching out to ther& > VMS community that is so alienated.. >- >- > Any thoughts on that?     F Yes, I have a thought about that. It's so logical that HP won't do it.   ------------------------------  $ Date: Thu, 9 Oct 2003 23:09:28 -0400* From: "Bill Todd" <billtodd@metrocast.net>. Subject: Re: What is the performance of iVMS ?2 Message-ID: <38Kdncage9B7vxuiU-KYuA@metrocast.net>  . "John Smith" <a@nonymous.com> wrote in messageD news:nUohb.269450$Lnr1.36741@news01.bloor.is.net.cable.rogers.com...   ...s  E > So here's an alternative to HP not providing its LOYAL customers an K > opportunity to test drive the fastest IA64 system with a debug version of F > VMS - how about having a 2nd IA64 running a non-debug version of VMSJ > available....or can't HP afford that huge additional expense for a group ofL > customers that bring in $800MM profit to HP (if that any longer) annually?  > While it makes no sense whatsoever not to be using the currentL top-of-the-line Itanic for the Internet VMS platform, it's hardly clear thatE stripping out the debug code would help much:  Fred said that they're L currently running code compiled for Merced (though it's difficult to imagineC why, unless they require features that haven't yet been migrated tonG McKinley's compilers) that's wholly unoptimized (and understandably so:eL they want to be able to make sense of it in a debugger if they have to), andK *those* are likely the main reasons why it runs like a slug (but running oni; Madison would at least make it run like a 50% faster slug).f   - bill   ------------------------------   End of INFO-VAX 2003.561 ************************