1 INFO-VAX	Sat, 07 Jul 2001	Volume 2001 : Issue 373       Contents:< Re: =?iso-8859-1?Q?StorageWorks=AE?= MSL 5026SL Tape Library axp 150 memory help  RE: axp 150 memory help  Check This Out!!!  1405  Check This Out!!!  2868  Check This Out!!!  8569 # Re: Excerpt from internal IBM memo.  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage  Re: Experience with EMC storage 1 Re: exploitable buffer overflows in VMS possible? 1 Re: exploitable buffer overflows in VMS possible?  Re: FUD   Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium." Re: I didn't stick it upside down!7 I Truly Appolige To ALL For The: Check This Out:   8910  RE: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World . Re: Licensing problems with Pathworks 32 (NT4)" Re: New Mailbox 0.7 (anyone using) ods5 and decc$from_vms Re: pk devices RE: POP server on tcpip5.1- Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events... 1 Re: Some thoughts on the recent turn of events...  Re: Telnet API Re: Telnet API RE: Telnet API Re: Telnet API Re: Telnet API Re: Telnet API Re: Telnet API Re: Telnet API Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid  Re: The Alpha/IA64 Hybrid 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated  Re: VAX 4000-106 qbus pinout< RE: VMS software/documentation product library (aka con dist? RE: VMS software/documentation product library (aka con dist) ? ? Re: VMS software/documentation product library (aka con dist) ? ? Re: VMS software/documentation product library (aka con dist) ? + Re: Why Compaq won't succeed on IA64 either + Re: Why Compaq won't succeed on IA64 either ) Re: Writing to OPA0: from a device driver ) Re: Writing to OPA0: from a device driver ) Re: Writing to OPA0: from a device driver   F ----------------------------------------------------------------------  % Date: Fri, 06 Jul 2001 21:58:38 -0400 ( From: Hamlyn Mootoo <univms@bigfoot.com>E Subject: Re: =?iso-8859-1?Q?StorageWorks=AE?= MSL 5026SL Tape Library + Message-ID: <3B466CCE.A7E93EA2@bigfoot.com>   C For clarification, I did not suggest creating shadow sets. I merely F suggested  having enough extra storage to do image copies of the unitsE you have to other disks.  In any case, it sounds like you're going to ? need to upgrade to a bigger, beefier RAID array (not to mention H processors) soon anyway, given your expected growth.  And if you get theB money for this, try to do RAID 1+0 instead of RAID5.  With today'sD larger capacity drives, and your need to spread data across multipleF physical spindles anyway, it would make a lot of sense, and you'll get much better write performance.   HM   "Jay E. Morris" wrote: > K > Ok, I got lots of good advice about speeding things up by creating shadow N > sets but....I have 8 DSM volume sets (database) spread across 5 spindles.  IL > have 5 RAID5 drives in my RA3000.  I'd have to shadow  RAID drives.  Don'tK > think I want to do that.  Mainly cause of the number of drives that would 
 > involve. > = > Plus I could load 20 tapes and forget about the damn thing.  > K > So since shadow sets seem to be out is there anyone using this that could # > give me real-life experience with  > it?  > 	 > Thanks.    ------------------------------  # Date: Sat, 07 Jul 2001 04:55:04 GMT  From: gobo20@lycos.com Subject: axp 150 memory help< Message-ID: <ICw17.4858$L4.722851@dca1-nnrp2.news.digex.net>  B trying to add memory to an axp 150.  i have been told that 72 pin,C true parity, 70 ns, 36 bit wide 4 or 16 mb simms would work.  for a D max memory of 128mb.  generic sticks of this sort go for 10-15 bucksE mail order.  when i check with vendors such as kingsington, they have E kits with dec equiv part numbers and want ~$140 for a four stick 64mb  kit.  D so i'm confused.  will the generic stick not work?  do i really needE to purchase one of these oem kits?  (i know they must be installed in   llike sets of 4, for two banks.)  E also, what is the max memory for this guy?  i was told 128, but there  are kits for 256.    thanks,        eddie    ------------------------------  % Date: Sat, 07 Jul 2001 06:23:55 +0100 5 From: "Steeples, Oliver" <Oliver.Steeples@compaq.com>   Subject: RE: axp 150 memory helpN Message-ID: <F498D199EDB12D468CD2C66680D3080116D5E7@reoexc04.emea.cpqcorp.net>   Hi, @ 	I have 2 sources, the first says 256mb and the second 256.  TheL approved DEC (Compaq) memory list states 16Mb SIMMS are max so 16mb*8=128.     OverviewG The PB22H-KB system module supports two banks of 128-bit wide, longword B parity protected memory. Each bank contains four SIMM connectors. L Memory Sizes The PB22H-KB System Module supports two sizes of memory option:K 16M bytes (4 1Mx36 SIMMs) and 64M bytes (4 4Mx36 SIMMs). Using combinations K of these two memory options, the system supports between 16M bytes and 128M H bytes of memory. The following shows how to install both types of memoryI modules in bank 0 and bank 1 to achieve the supported memory capacities.       Configuration Rules L Use only memory modules that are 36 bits wide and rated at a speed of 70 ns.  4 Bank 0 must contain a memory option (four modules). I A memory option consists of four memory modules. When installing a memory G option in a memory bank, you must install a memory module in all of the  connectors in that bank.  C Do not install different types of memory modules in the same bank.      J It maybe generic memory works, on the other hand it may blow up either theJ motherboard or memory.  If it does work it will not be supported by Compaq and may give memory errors.    Regards, 	Oliver        -----Original Message-----0 From: gobo20@lycos.com [mailto:gobo20@lycos.com]% Sent: Saturday, July 07, 2001 5:55 AM  To: Info-VAX@Mvb.Saic.Com  Subject: axp 150 memory help    B trying to add memory to an axp 150.  i have been told that 72 pin,C true parity, 70 ns, 36 bit wide 4 or 16 mb simms would work.  for a D max memory of 128mb.  generic sticks of this sort go for 10-15 bucksE mail order.  when i check with vendors such as kingsington, they have E kits with dec equiv part numbers and want ~$140 for a four stick 64mb  kit.  D so i'm confused.  will the generic stick not work?  do i really needE to purchase one of these oem kits?  (i know they must be installed in   llike sets of 4, for two banks.)  E also, what is the max memory for this guy?  i was told 128, but there  are kits for 256.    thanks,        eddie    ------------------------------  # Date: Sat, 07 Jul 2001 00:38:24 GMT  From: grpziu@my.com   Subject: Check This Out!!!  1405< Message-ID: <4Ss17.78753$By.1839492@typhoon.midsouth.rr.com>  1 Check out our new store at www.our-superstore.com 6 fnlmzwkeuhyjpwnsywllkxotpbnizsptyisuolulgxdjhxfovbrmxg   ------------------------------  # Date: Sat, 07 Jul 2001 00:02:29 GMT  From: mmezvr@my.com   Subject: Check This Out!!!  2868< Message-ID: <pks17.32546$By.1830430@typhoon.midsouth.rr.com>  b We Have Opened a new SuperStore for all you shopping needs. Check us out at www.our-superstore.com0 thhpykfimbwrpgvfvfefjgdxnjsxniuuvwzygjquniwfgrgy   ------------------------------  # Date: Sat, 07 Jul 2001 01:07:02 GMT  From: yijsby@my.com   Subject: Check This Out!!!  8569= Message-ID: <Wgt17.124951$By.1846447@typhoon.midsouth.rr.com>   1 Check out our new store at www.our-superstore.com  xegfsbcqtewqrxpxrmiwxrjwpscqy    ------------------------------  $ Date: Fri, 6 Jul 2001 18:03:27 -0400' From: "Bill Todd" <billtodd@foo.mv.com> , Subject: Re: Excerpt from internal IBM memo.( Message-ID: <9i5cc7$dm2$1@pyrite.mv.net>  9 "Alphaman" <alphaman64@nixspam-home.com> wrote in message 4 news:f1i17.8372$B5.1747223@news1.rdc1.tn.home.com...   ...   K > If Compaq is emulating IBM, where is Compaq's processor chip line?  I see L > IBM improving Power and trying to sell it to Apple for inclusion in futureJ > systems.  I see IBM increasing their options, not narrowing their focus;H > they are differentiating themselves, not becoming a "me too" commodity	 > player.  > E > Digipaq has been down this road before, only this is the first time  they've D > cut off both legs in the midst of learning to do handstands on the services > arm.  # The real Alphaman is back.  Hooray!    - bill   >  > Aaron  > --@ > Aaron Sakovich  http://members.home.net/sakovich/alphaman.html@ > Make April 15 just another day:        http://www.fairtax.org/? > "Are you a nerd?  How many syllables are in the word 'coax'?"  >  >  >    ------------------------------   Date: 06 Jul 2001 20:58:51 GMT' From: prosullivan@aol.com (PROSULLIVAN) ( Subject: Re: Experience with EMC storage: Message-ID: <20010706165851.19554.00001954@ng-fv1.aol.com>  ! >> Other than that, if you've got 1 >> the $,$$$,$$$ to spend, then I would go for it   2 EMC is a solution that is designed for applicationN -sharing on the same Symmetrix. If your EMC is only to be used for one machineJ and one application, then it may be rather an overkill. Yes, big cache canJ overcome slower internal scsi and internal disks, and the srdf facility is excellent.    M But, if you only want to use your storage for one machine and one application G then HSG80 and storageworks II is a lot cheaper. The lack of cache size N compared with EMC is compensated by the much faster Storageworks disks. DRM is& more fiddly and less proven than SRDF.  K One thing, if EMC kill the price to get the business, they will recoup that # difference one way or the other....    pos    ------------------------------  % Date: Fri, 06 Jul 2001 18:02:51 -0400 ( From: Hamlyn Mootoo <univms@bigfoot.com>( Subject: Re: Experience with EMC storage+ Message-ID: <3B46358B.926ACF9D@bigfoot.com>    Bart Zorn wrote: > < > It is kind of hard to believe. A positive story about EMC.I > However, the part about the pre-sales rituals make me a bit suspicious.  > N > Still, for me as a consultant, I find it it hard to recommend EMC. The price  H Well I went to the web site of the company that (I assume) you work for,G and it seems that the two disk storage vendors clearly touted there are F Compaq and MTI (didn't even know they were still in business).  UnlikeC you I am an INDEPENDENT consultant.  I do not sell EMC or Compaq or F anything.  I do not make my money on vigs from vendors.  EMC is a hugeF purchase and a major investment.  If a company is considering EMC withE it's high price, usually it's for a reason.  StorageWorks works quite H well for certain companies who do not need the very powerful features of
 an EMC array.   G > per Gigabyte, the lack of configuration freedom for the customer, the ' > doubtful implementation of caching...   C What do you mean by "doubtful implementation"?  Are you saying that G caching doesn't work, or that EMC caching doesn't work? Please explain. F Oh, by the way.  Have you actually implemented/used and EMC array? YouG spoke about it from a distance, so I'm assuming that you have no direct  experience with one. > M > I still am looking forward to both positive and negative stories about EMC.  > 
 > Regards, >  > Bart Zorn  >    ------------------------------  # Date: Fri, 06 Jul 2001 22:19:18 GMT - From: "Dave Pampreen" <davepampreen@home.com> ( Subject: Re: Experience with EMC storage> Message-ID: <GPq17.171743$DG1.28463845@news1.rdc1.mi.home.com>  I We were looking at the same type thing... Instead of EMC I got a EMA12000 C with 2 HSG80's.  This was a great system and can be reused in my NT . enviroment if we ever moved off Alpha/OpenVMS.   The speed is incredible.  
 My config is:  ES40/2 GIG and DS20/1Gig1 Both connected via the FC switch to the EMA12000.   L The nice thing is that if my ES40 has any issues, I can boot the DS20 on the ES40 boot partition!  @ We're running MANMAN (Oracle COSASYL formerly DEC-DBMS database)   Dave5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in message % news:3B46358B.926ACF9D@bigfoot.com...  >  >  > Bart Zorn wrote: > > > > > It is kind of hard to believe. A positive story about EMC.K > > However, the part about the pre-sales rituals make me a bit suspicious.  > > J > > Still, for me as a consultant, I find it it hard to recommend EMC. The price  > J > Well I went to the web site of the company that (I assume) you work for,I > and it seems that the two disk storage vendors clearly touted there are H > Compaq and MTI (didn't even know they were still in business).  UnlikeE > you I am an INDEPENDENT consultant.  I do not sell EMC or Compaq or H > anything.  I do not make my money on vigs from vendors.  EMC is a hugeH > purchase and a major investment.  If a company is considering EMC withG > it's high price, usually it's for a reason.  StorageWorks works quite J > well for certain companies who do not need the very powerful features of > an EMC array.  > I > > per Gigabyte, the lack of configuration freedom for the customer, the ) > > doubtful implementation of caching...  > E > What do you mean by "doubtful implementation"?  Are you saying that I > caching doesn't work, or that EMC caching doesn't work? Please explain. H > Oh, by the way.  Have you actually implemented/used and EMC array? YouI > spoke about it from a distance, so I'm assuming that you have no direct  > experience with one. > > J > > I still am looking forward to both positive and negative stories about EMC. > >  > > Regards, > > 
 > > Bart Zorn  > >    ------------------------------  $ Date: Fri, 6 Jul 2001 19:01:26 -0400' From: "Bill Todd" <billtodd@foo.mv.com> ( Subject: Re: Experience with EMC storage( Message-ID: <9i5fou$gj1$1@pyrite.mv.net>  5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in message % news:3B46358B.926ACF9D@bigfoot.com...  >  >  > Bart Zorn wrote:   ...   I > > per Gigabyte, the lack of configuration freedom for the customer, the ) > > doubtful implementation of caching...  > E > What do you mean by "doubtful implementation"?  Are you saying that I > caching doesn't work, or that EMC caching doesn't work? Please explain.   F My guess would be that he's referring to the fact that EMC's SymmetrixJ write-back cache is not mirrored, which makes it a single point of failureB (whereas virtually all other elements in the Symmetrix can be madeK fully-rudundant).  Why they haven't changed this after close to a decade of L criticism for it is hard to understand - though they do take measures (e.g.,9 memory-scrubbing) to decrease the probability of failure.    - bill   ------------------------------  % Date: Fri, 06 Jul 2001 20:22:44 -0400 ( From: Hamlyn Mootoo <univms@bigfoot.com>( Subject: Re: Experience with EMC storage+ Message-ID: <3B465654.372181DC@bigfoot.com>   H I guess I should have asked what model EMC array you are considering.  IH just took a look at the EMC web site and noticed that they are currentlyH selling lower end storage, based on the Data General Clariion arrays.  ID worked on these too, back in '94.  I hadn't realized EMC bought DataF General's Clariion storage division.  The previous comments were basedE on my experience with the EMC Symmetrix arrays, not the Clariions.  I G did like the Clariions when I used them, they are well designed.  I was G wondering why anybody would talk about StorageWorks and EMC in the same B sentence (see previous posts), but now I realize the comparison isF probably being made to the Clariion, not the Symmetrix.  The SymmetrixA is in a whole other class and size and price point of storage.  IhC noticed EMC added some Symmetrix-like features to the Clariion, but8# these two arrays are worlds apart. e  H Also responding to some previous posts, EMC arrays can use disks just asH fast as Storageworks (PROSULLIVAN comment), and Bill, the Symmetrix usesH Non-Volatile cache and internally houses two separate cache buses.  ThisC is why, I suspect, they don't use redundant cache (incidentally thewD Clariions DO use redundant cache across its two storage processors).   HM   "Koloth(Telocity)" wrote:  > G > We are investigating EMC as a possibility for storage for our OpenVMSaG > Alpha system.  We use DSM (Mumps) database.  Does anyone have good or 0 > bad experiences that they would like to share? >  > TIAk >  > Cass Witkowski   ------------------------------  $ Date: Fri, 6 Jul 2001 20:40:16 -0400' From: "Bill Todd" <billtodd@foo.mv.com>R( Subject: Re: Experience with EMC storage( Message-ID: <9i5lic$k11$1@pyrite.mv.net>  5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messagen% news:3B465654.372181DC@bigfoot.com...k   ...s  J > Also responding to some previous posts, EMC arrays can use disks just as- > fast as Storageworks (PROSULLIVAN comment),.  ? Now *that* comment may have referred to the Symmetrix's defaultoL extremely-coarse array striping, such that it's difficult to stream a singleH file at greater-than-single-disk bandwidth.  And EMC's field technicians> according to some are often unaware of finer striping options.    and Bill, the Symmetrix useseJ > Non-Volatile cache and internally houses two separate cache buses.  ThisE > is why, I suspect, they don't use redundant cache (incidentally the4F > Clariions DO use redundant cache across its two storage processors).  I Yes, the Symmetrix uses non-volatile write-back cache, and doesn't mirror K it, which is the problem:  while the single copy of a dirtied datum residesaJ in the write-back cache, it is considered persistent by the software usingH the storage but can in fact be lost if the cache hardware fails - unlike( data that's actually replicated on disk.   - bill   >a > HM >e > "Koloth(Telocity)" wrote:h > >eI > > We are investigating EMC as a possibility for storage for our OpenVMS I > > Alpha system.  We use DSM (Mumps) database.  Does anyone have good ory2 > > bad experiences that they would like to share? > >b > > TIA  > >i > > Cass Witkowski   ------------------------------  % Date: Fri, 06 Jul 2001 21:38:25 -0400m( From: Hamlyn Mootoo <univms@bigfoot.com>( Subject: Re: Experience with EMC storage+ Message-ID: <3B466811.970C54B5@bigfoot.com>t  A > Now *that* comment may have referred to the Symmetrix's default:N > extremely-coarse array striping, such that it's difficult to stream a single. > file at greater-than-single-disk bandwidth. E EMC Symmetrix arrays typically have a MINIMUM of 2 Gigabytes cache inoD front of the disks, and can go up to (at least in the model that I'm@ familiar with) 16 GIGABYTES.  And every write in an EMC array isE satisfied by cache.  I can't think of a single file that would easilym@ overwhelm cache, even on a busy box.  Even if a database file is> considered, this would only be during a maintenance operation.  K > Yes, the Symmetrix uses non-volatile write-back cache, and doesn't mirroreM > it, which is the problem:  while the single copy of a dirtied datum resideseL > in the write-back cache, it is considered persistent by the software usingJ > the storage but can in fact be lost if the cache hardware fails - unlike* > data that's actually replicated on disk.  G Agreed, and I am in no way defending the design, but if two symmetrixes:C are used, and data is being replicated at another site, the risk isa
 mitigated.   HM   ------------------------------  $ Date: Fri, 6 Jul 2001 21:52:48 -0400' From: "Bill Todd" <billtodd@foo.mv.com>d( Subject: Re: Experience with EMC storage( Message-ID: <9i5pqb$mdr$1@pyrite.mv.net>  5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messagec% news:3B466811.970C54B5@bigfoot.com... C > > Now *that* comment may have referred to the Symmetrix's defaultnI > > extremely-coarse array striping, such that it's difficult to stream a  single/ > > file at greater-than-single-disk bandwidth.,G > EMC Symmetrix arrays typically have a MINIMUM of 2 Gigabytes cache inrF > front of the disks, and can go up to (at least in the model that I'm > familiar with) 16 GIGABYTES.  H Which just sits there looking bemused if the file you're reading doesn'tL happen to be cached, in which case you stream it at the single-disk-transferL rate (though if you're streaming more than the 4 GB that I understand is theI default per-disk stripe segment size the system can be reading into cachesJ from later segments while the previous ones are being fetched).  The cacheJ does speed up modest-sized streaming writes (up to the cache size), and toJ the degree that the cache size exceeds the per-disk stripe segment size it can help speed up larger ones.   - bill   ------------------------------  # Date: Sat, 07 Jul 2001 01:39:58 GMT-$ From: Scott Vieth <svieth@wi.rr.com>( Subject: Re: Experience with EMC storage( Message-ID: <3B466906.A86F845@wi.rr.com>  A 1) Are you an IDX customer?  We had a small problem when we firsteG fired-up our new StorageWorks storage with our IDX system.  We logged a H support call with IDX (we thought that our version of ISM was choking onA the $1$DGAnn: device names) and their response was "we don't haveeH hardware like that at our location to replicate your configuration."  IfH they have trouble helping out with Compaq fc storage, imagine how far upI sh*t creek you'll be when you attach EMC to your bread-and-butter system.   F 2) There was post just a week ago about someone who was having troubleE getting EMC storage to work with VMS.  When that person called CompaqeG support, the support folks told him to take a hike (after they heard itnF was non-Compaq storage).  Is this the kind of support you want on yourI mission critical systems?  I'd rather get some sleep at night and be abledB to go out of town on vacation once a year without worrying that myI storage is going to go belly-up and Compaq is going to turn their back on  me.n   Buy StorageWorks: sleep well.l# Buy EMC: learn to live on the edge.n   -Scott   "Koloth(Telocity)" wrote:d  G > We are investigating EMC as a possibility for storage for our OpenVMSmG > Alpha system.  We use DSM (Mumps) database.  Does anyone have good orm0 > bad experiences that they would like to share? >o > TIAn >a > Cass Witkowski   ------------------------------  # Date: Sat, 07 Jul 2001 01:53:09 GMT0$ From: Scott Vieth <svieth@wi.rr.com>( Subject: Re: Experience with EMC storage) Message-ID: <3B466C1D.64FCBE47@wi.rr.com>m   Hamlyn:   P Regarding your MTI comment:  A year or two ago I looked long and hard at the MTIR solution (for NT and Netware, not VMS).  They have some very nice storage gear.  IC really liked the management software.  Kicked the hell out of SWCC.   Q I got to visit the MTI "lab" in Chicago and spoke with the engineers there.  Veryn good feeling all around.  R But one thing nagged me:  MTI was such a small company and I wasn't sure they wereN going to be around "forever".  I decided to go Compaq (even though they didn'tO have the Netware support ready) and that turned out to be a very good decision.1R MTI soon after announced big problems and the stock price went down quicker than a White House intern.a  O Even though Compaq storage was behind the rest of the players (I also reeeeally5O liked Dell's storage before EMC assimilated that product line), it turns out iteM was right storage solution for the NT and Netware servers I was working with.jN Compaq has added more features and drivers and they are offerering a top-notch solution in that space.   8 Of course, on my VMS boxen, I use only StorageWorks. :^)  P MTI had a great product but, like the Digital of old, the "business" part of theK company crushed any hopes of winning market share with superior technology.g   -Scott   Hamlyn Mootoo wrote:   > Bart Zorn wrote: > > > > > It is kind of hard to believe. A positive story about EMC.K > > However, the part about the pre-sales rituals make me a bit suspicious.m > >tP > > Still, for me as a consultant, I find it it hard to recommend EMC. The price >wJ > Well I went to the web site of the company that (I assume) you work for,I > and it seems that the two disk storage vendors clearly touted there areoH > Compaq and MTI (didn't even know they were still in business).  UnlikeE > you I am an INDEPENDENT consultant.  I do not sell EMC or Compaq or1H > anything.  I do not make my money on vigs from vendors.  EMC is a hugeH > purchase and a major investment.  If a company is considering EMC withG > it's high price, usually it's for a reason.  StorageWorks works quite J > well for certain companies who do not need the very powerful features of > an EMC array.n >bI > > per Gigabyte, the lack of configuration freedom for the customer, ther) > > doubtful implementation of caching...h >vE > What do you mean by "doubtful implementation"?  Are you saying thateI > caching doesn't work, or that EMC caching doesn't work? Please explain. H > Oh, by the way.  Have you actually implemented/used and EMC array? YouI > spoke about it from a distance, so I'm assuming that you have no direct  > experience with one. > >lO > > I still am looking forward to both positive and negative stories about EMC.  > >  > > Regards, > >1
 > > Bart Zorns > >a   ------------------------------  # Date: Sat, 07 Jul 2001 03:19:24 GMTg" From: Ed Wilts <ewilts@ewilts.org>( Subject: Re: Experience with EMC storage; Message-ID: <0dv17.1474$GI4.166852@typhoon.mn.mediaone.net>i   Bart Zorn wrote:  < > It is kind of hard to believe. A positive story about EMC.I > However, the part about the pre-sales rituals make me a bit suspicious.t  H Nobody said that EMC storage was cheap.  The Symmetrix product has high 8 margins, and EMC thinks they can afford the marketing.    H > Still, for me as a consultant, I find it it hard to recommend EMC. TheI > price per Gigabyte, the lack of configuration freedom for the customer,f+ > the doubtful implementation of caching...d  F The configuration freedom is changing.  WIth the latest ControlCenter L software (4.3) and up to date firmware on the Symmetrix, the customer has a H LOT more control than they used to.  For now (we're not quite up to the J latest and greatest Control Center yet), we're reliant on EMC configuring  the box.  H > I still am looking forward to both positive and negative stories about > EMC.  ? Although my primary paycheck is for managing VMS systems (with dL StorageWorks), I also support NT, W2K, Solaris, and Irix on our Symmetrix.  K I can't say much of anything bad about the Symmetrix.  I wish I knew a lot II more about it before we configured it, but I'm still learning.  Overall,  / I'd say the Symmetrix is a positive experience.            .../Ed -- i Ed Wilts, Mounds View, MN, USA mailto:ewilts@ewilts.org   ------------------------------  % Date: Fri, 06 Jul 2001 21:09:46 -0700E! From: Koloth <koloth@tmisnet.com>E( Subject: Re: Experience with EMC storage+ Message-ID: <3B468B8A.4AEE99D5@tmisnet.com>e  I We currently use StorageWorks but have been asked by our customer to scansH the field of other vendors.  According to the latest Gartner Group, only$ Compaq and EMC are in the top ranks.  G 1) I have concerns about EMCs performance when you do lots of little (1 E KB) random I/Os.  It reminds me of working set size issues.  For some E type of applications you could never have a working set big enough tooF prevent or dramatically reduce paging.  With our application (CHCS) weF have lots of random I/Os.  DSM (Mumps) has it's own cache in the AlphaH memory so the I/Os to disk may have a low cache hit rate.  On some disksA I've seen 12% hit rate.  So one of my questions is has anyone hadrG performance problems with EMC where no matter the cache size there just  were not enough disk spindles?  D 2) I was not aware of the cache not being mirrored or redundant.  DoG people using EMC solutions recommend two boxes and do host based volumeo" shadowing, or some other solution?  D 3) Does having the cached mirrored and the external batteries on theC Compaq's HSG80 make it reliable enough to just use controller basedr- mirroring versus host based volume shadowing?e   Thanks   Cass Witkowski Senior Systems Engineers SAIC   "Koloth(Telocity)" wrote:0  G > We are investigating EMC as a possibility for storage for our OpenVMS G > Alpha system.  We use DSM (Mumps) database.  Does anyone have good ort0 > bad experiences that they would like to share? >c > TIAS >f > Cass Witkowski   ------------------------------  % Date: Fri, 06 Jul 2001 22:43:30 +0100e+ From: "antonio.carlini" <arcarlini@iee.org> : Subject: Re: exploitable buffer overflows in VMS possible?' Message-ID: <3B463102.9104881F@iee.org>,   Arne Vajhj wrote:; > Buffer overruns can definatetly also be a problem on VMS.f  - Way back (in V5.4 I think) there was an shortm# MACRO-32 program floating around onn& JANET (the UK academic network) which,$ if I remember the details correctly,  more or less did exactly this to ANALYZE/PROCESS_DUMP.r  ' There was another one a few years later ( which did similar things for SET RIGHTS.( I never saw the exploit for that one but$ working back from the changes in the" mandatory patch, it was clear that# the code saved its current privs ina2 a local on the stack, did stuff, and then restored% the privs. There just so happened to o& be a little hole that, with the right # combination of command qualifiers, o% happened to restore the privs without # initialising them first. So all you - had to do (exercise for the student here ...)m* was arrange for the appropriate bits to be& lying around on the stack and *whoosh* you had bypass.i  $ I've not seen anything like this for  Alpha. Having done my fair share of Alpha generated code readingh! (usually in a crash dump ...) forp Alpha, I'm not in the slightest " bit surprised that there are fewer Alpha exploits kicking around.   Antoniox   -- e   --------------- - Antonio Carlini             arcarlini@iee.orgn   ------------------------------  # Date: Sat, 07 Jul 2001 04:52:43 GMT . From: "mulp" <michaelpettengill@earthlink.net>: Subject: Re: exploitable buffer overflows in VMS possible?D Message-ID: <vAw17.7053$G_1.705174@newsread2.prod.itd.earthlink.net>  @ "Robert A.M. van Lopik" <lopik@mail.telepac.pt> wrote in message% news:9i1dum$m8l$1@venus.telepac.pt...DI > Over the last year hackers/security experts (often not distinguishable)h haveK > identified unchecked buffers in lots of commercial programs (both on Unix J > and Windows). Usually this is done by sending unusually large IP-packets orD > other input to a program. There even exist tools to do these testsK > systematically. The result of such a buffer overflow is usually that someCF > other data structure or the stack is corrupted, so the program under attacksf > dies.w  L This problem generally happens because of poor API design.  unix programmersJ set a standard for simple, fragile APIs because it makes programming easy.  L VMS has a different history, drawing on languages like Fortran and operatingD systems like RSX.  C programmers hate the APIs that result.  RMS, isK particularly hated, but so are item lists.  All of these interfaces containoH a data structure that points to the buffer, has a buffer size value, andL often has a pointer or location to contain the actual data.  And then, worstK of all, the API returns a status  or two that the programmer is expected tod check.  H Its so much easier to have an API that says size=read(*here); there's no& errors, no complicated arguments, etc.  K Still, good APIs don't ensure that an error won't be made; I seem to recalleB that there once was a bug related to buffer overrun in loginout or8 something.  Still, its not a regular occurance with VMS.   ------------------------------  $ Date: Fri, 6 Jul 2001 18:43:08 -0400' From: "Bill Todd" <billtodd@foo.mv.com>k Subject: Re: FUD( Message-ID: <9i5emk$fbh$1@pyrite.mv.net>  < "Jordan Henderson" <jordan@lisa.gemair.com> wrote in message$ news:9i4j8s$bbk$1@lisa.gemair.com...   ...   F > Sigh... Haven't Mathog and Dachtera been saying this here for years?; > I guess we should have been supporting their efforts mores enthusiastically.rL > I dunno, I guess I just never thought that Alpha would be suddenly gone...I > I'm not sure what we could have realistically done, though.  DEC seemedtI > to not be listening and Compaq may have already been too late (although.5 > Alpha Proliants seemed to me to be a good idea...).h  @ There's always been significant divergence of opinion on Alpha'sH really-low-end potential, and I've tended to think that it was mostly inB non-desktop areas (compatible low-end adjuncts to higher-end AlphaK installations and inexpensive ISV development platforms, for example).  ButxI I'd sure rather have seen DEC and later Compaq do *something* rather than  *nothing* with the technology.  I Conversely, there's been very little opinion to the effect that Alpha wascK anything but near-ideally positioned to succeed in the mid-range and up, soiG I tend to think that concentrating most effort there at least initiallys would have made the most sense.k  K Instead, we've mostly just waited for Compaq to get its act together to seej0 which direction it would take.  And now we know.   - bill   >a	 > >- billm > >v > >e > >t >h > -Jordan Hendersono > jordan@greenapple.coms >p   ------------------------------  , Date: Fri, 06 Jul 2001 18:18:51 +0200 (CEST): From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>) Subject: Re: Full port of VMS to Itanium..I Message-ID: <Pine.LNX.4.21.0107061811490.6296-100000@irys.stanpol.com.pl>s  ' On Sun, 1 Jul 2001, T. S. Murphy wrote:y  / >+"Bill Todd" <billtodd@foo.mv.com> wrote [...]nN >+> I'm no expert, but I'd have to see explicit examples (e.g., non-privilegedH >+> instructions in some generation that aren't supported in some futureL >+> generation) before I believed this.  I've got XT DOS software that still/ >+> runs under Pentiums and Win9x, for example.  >+I >+Intel has retired one instruction ever, which was the move to/from testcM >+registers instruction. It was present in the 486 and retired in the Pentium  >+processor.  ?  Really: also some unprivileged but unsupported instruction wasaB changed. I am don't know the reason, but KERMIT for DOS (freeware)4 does NOT work starting with MMX-expanded processors.8  With non-MMX both Intel Pentium and AMD works properly.   [...] E >+> New instructions really do constitute features, not objectionable,M >+> incompatibilities:  it's *upward* compatibility that's usually important,:L >+> and AFAICT Intel has always done an excellent job of maintaining it.  If  :  May be, that KERMIT uses something like unsupported stack= manipulation (AFAIR here was some segment substitution, wheref< was unsupported but was the simplest way for something; I am8 definitely NOT remember what that was), then you can say$ that the author of KERMIT was wrong.  But... I am not sure.  L >+> *downward* compatibility was important to any application, it could haveL >+> achieved it simply by not using the newer instructions (and watching itsG >+> memory requirements) - but that's not an Intel responsibility but al >+> software one.h  6  Agree. Any comment about KERMIT for DOS from anyone ?    Regards - Gotfryd   -- iE =====================================================================wF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEs. $!                        GS@stanpol.zabrze.plE =====================================================================    ------------------------------  $ Date: Fri, 6 Jul 2001 18:01:39 -0400  From: John Santos <JOHN@egh.com>) Subject: Re: Full port of VMS to Itanium.t5 Message-ID: <1010706173603.1110B-100000@Ives.egh.com>-  4 On Fri, 6 Jul 2001, Gotfryd Smolik, VMS lists wrote:  ) > On Sun, 1 Jul 2001, T. S. Murphy wrote:  > 1 > >+"Bill Todd" <billtodd@foo.mv.com> wrote [...]9P > >+> I'm no expert, but I'd have to see explicit examples (e.g., non-privilegedJ > >+> instructions in some generation that aren't supported in some futureN > >+> generation) before I believed this.  I've got XT DOS software that still1 > >+> runs under Pentiums and Win9x, for example.a > >+K > >+Intel has retired one instruction ever, which was the move to/from testIO > >+registers instruction. It was present in the 486 and retired in the Pentium  > >+processor. > A >  Really: also some unprivileged but unsupported instruction wasuD > changed. I am don't know the reason, but KERMIT for DOS (freeware)6 > does NOT work starting with MMX-expanded processors.: >  With non-MMX both Intel Pentium and AMD works properly.  C There was a problem with Kermit on fast processors getting a dividegA by zero error.  (They were doing a repeated loop to determine the A processor speed, but on IIRC 200Mhz or faster processors, it tookuA less than one clock tick, so the time difference was zero.)  ThissD was fixed in the most recent MS-DOS Kermit (3.15).  This is the onlyB problem I know of.  I'm pretty sure it works okay on my 800Mhz P3.D (I usually use Kermit-95, which is completely different, but I think0 I've used MS-Kermit on it while testing modems.)   > [...].G > >+> New instructions really do constitute features, not objectionableeO > >+> incompatibilities:  it's *upward* compatibility that's usually important,rN > >+> and AFAICT Intel has always done an excellent job of maintaining it.  If > < >  May be, that KERMIT uses something like unsupported stack? > manipulation (AFAIR here was some segment substitution, whereh> > was unsupported but was the simplest way for something; I am: > definitely NOT remember what that was), then you can say& > that the author of KERMIT was wrong. >  But... I am not sure. > N > >+> *downward* compatibility was important to any application, it could haveN > >+> achieved it simply by not using the newer instructions (and watching itsI > >+> memory requirements) - but that's not an Intel responsibility but at > >+> software one.t > 8 >  Agree. Any comment about KERMIT for DOS from anyone ?  D Frank da Cruz monitors this group for Kermit posts (at least, Kermit? questions here seldom slip by him), so I'm sure he can give thea< authoritative answer.  Or ask in comp.protocols.kermit.misc. >  >  Regards - Gotfryd   --   John Santoso Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 6 Jul 2001 23:43 CDT' From: carl@gerg.tamu.edu (Carl Perkins)o+ Subject: Re: I didn't stick it upside down!e, Message-ID: <6JUL200123430357@gerg.tamu.edu>  6 rdeininger@mindspring.com (Robert Deininger) writes...% }"wabbit" is "rabbit" mis-pronounced.t } I }This particular rabbit is animated, and inhabits (or used to inhabit) TV4I }commercials for bad, brightly-colored, mostly-sugar breakfast cereal foroC }children.  (I haven't seen this for years.)   The cereal is called I }"Trix".  Our hero, the rabbit, lives to eat Trix, but every time he getsgJ }some, a bunch of kids come along and take it away, saying, "Silly wabbit,J }Trix are for kids!".  This goes on for years, and the rabbit never learns }his lesson. } I }So sometimes, when a person persists in a futile activity, we call him a G }"silly wabbit".  (I don't think the kids in the commercial pronouce itiH }"wabbit".  But at least one of the kids in the commercial must have hadI }trouble pronouncing "r", and said "wabbit", because when we say it, it'st }always "wabbit".) }Robert Deiningern  G I blame society. Well, society and Elmer Fudd. OK, society, Elmer Fudd, D and cross contamination between Bugs Bunny (who is a "scwewy wabbit"C according to Elmer Fudd, at least in some of his incarnations - thewH severity of his speah impediment has varied considerably over the years)J and the Trix Rabbit (who is a "silly rabbit" according to the cartoon kids in the cereal commercial).   --- Carl   ------------------------------  # Date: Sat, 07 Jul 2001 03:19:13 GMTs From: vsepnv@my.como@ Subject: I Truly Appolige To ALL For The: Check This Out:   8910= Message-ID: <Rcv17.171165$By.1868961@typhoon.midsouth.rr.com>:  i I truly apoloize to everyone for what happened. I was tring to send it to a test group and not the world.ag This was the first time I used Agent Poster and did relize what had happen until I got all you e-mails.o> I am truly sorry and you can be assured, it wont happen again.
 Tom Partridgea
 crpxjpbmhcwbp    ------------------------------  % Date: Fri, 06 Jul 2001 14:12:59 -0400 + From: "Main, Kerry" <Kerry.Main@compaq.com>   Subject: RE: IA64 Rocks My WorldR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7EDD@kaoexc01.americas.cpqcorp.net>   Greg,   G re: OPS in a box .. I think Andrew is trying to state somehow that a HWiJ partitioned system using separate OS's within the same system (and OPS) isK somehow not a valid benchmark. His "Customer complexity" arguments refer towK setting up Oracle Parallel Server (which any good Oracle DBA can do) and iniK fine tuning the app to run in a NUMA environment (which any Customer with al NUMA server needs to do)..  G As most here are aware, you can scale up (big SMP) or you can scale outaJ (cluster approach). Both have merit in different application environments.  I Given that one of the reasons for doing HW partitioned systems is to have @ separate OS environments, but one single view of the data, imho,J illustrating the overall performance one can get out of a single system is fine.   K This is exactly what Customers doing server consolidation today are looking  for.  D [hopefully, we can avoid another "what is a real mans TPC benchmark" discussion.. ]   Regards,  
 Kerry Main Senior Consultant  Compaq Canada Inc. Professional ServicesI Voice: 613-592-4660e Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----. From: Greg Pfister [mailto:pfister@us.ibm.com] Sent: July 6, 2001 12:06 PMu To: Info-VAX@Mvb.Saic.Comh  Subject: Re: IA64 Rocks My World     andrew harrison wrote: [snip]= > Designing a memory subsystem that had poorer memory latencym= > than a 4 year old Origin 2000 was hardly something that your > can blame on the marketeers. > A > > BTW, from what I also hear, SUN is having similar engineeringf difficultiesL > > making large scale USIII system work. Remeber those old quotes about theF > > systems scaling to 1000 processors etc? Where are the systems? Oh, right,= > > of course you can cluster lots of small ones together ;-)h > >a > 7 > All the major systems vendors have suffered delays ino: > introducing their latest high end systems. The SuperDome9 > was late, the SunFires were late and WildFire was late.   > Careful with that "all." I don't think IBM's been late yet. At< least not recently, since TPTB finally decided that the Un*x' market was something worth going after.t  8 > The problem for WildFire is that it was late but  when1 > it was announced it wasn't competitive with the,: > previous generation of servers from Compaqs competitors. > 5 > It recently reached the dizzy heights of 230,000 oni2 > TPC-C, using the latest 1001 Mhz CPU's, a result5 > puts it just ahead of the IBM P680, a machine thatso' > just about to be replaced by Regatta.c > 1 > When Rob Young started his WildFire boosting inn2 > the dark and dim past initial numbers of 200,0002 > were being bandied about, I can only assume that2 > this number was a design goal that was leaked to/ > Rob (unless he made it up). The fact that theI. > initial numbers came out way lower than that/ > and then needed OPS in a box tends to suggests& > that they missed their design goals.  A Do you know for a fact that the OPS-in-a-box solution was used inhA Wildfire? That's often rather difficult to tell from official TPC(< disclosures. If it was used, it of course makes the high TPC4 results rather meaningless (in my personal opinion).   Greg Pfister   ------------------------------  $ Date: Fri, 6 Jul 2001 17:45:47 -0400' From: "Bill Todd" <billtodd@foo.mv.com>t  Subject: Re: IA64 Rocks My World( Message-ID: <9i5bb7$d8m$1@pyrite.mv.net>  9 "Peter Boyle" <pboyle@holyrood.ed.ac.uk> wrote in message B news:Pine.SOL.4.33.0107061721150.23518-100000@holyrood.ed.ac.uk... >o >b& > On Fri, 6 Jul 2001, Bill Todd wrote: >t >?8 > >  WildFire is a serious mistake. It isn't competitiveB > > > because it is too costly to build, its big and it isn't fast
 > > > enough.r > >rK > > That must be why Compaq had its recent spate of super-computer wins (atr) > > least one of them against SUN, IIRC).y >w > Not with GS320's, however.  J I remembered after writing the above that one or more of the installationsB comprised (IIRC) ES rather than GS series nodes:  did all of them?  H In any event, it tends to demonstrate faith in Alpha's core architectureH (ignoring what it says about the memory performance of the ES machines),A which is its real differentiator and the aspect its designers goteL impressively right at the start.  Anything else can be fixed if a false step" occurs (even cache corruption...).   - bill   >l > Peterr >e >n >S >    ------------------------------  $ Date: Fri, 6 Jul 2001 17:58:07 -0400' From: "Bill Todd" <billtodd@foo.mv.com>o  Subject: Re: IA64 Rocks My World( Message-ID: <9i5c28$dle$1@pyrite.mv.net>  G "andrew harrison" <ah13473_nospam@remove_this.sun.com> wrote in message - news:3B45A85E.F049F0E9@remove_this.sun.com...e >a > Bill Todd wrote: > >eK > > "andrew harrison" <ah13473_nospam@remove_this.sun.com> wrote in messaget1 > > news:3B458E44.6465BCB4@remove_this.sun.com...t > >a > > ...t > >a > > > I disagree,h > >vG > > You're of course free to disagree, but customers don't seem to:  myo vagueoG > > recollection is that Wildfires did the better part of $1 billion ina businessK > > during the less-than-2/3 of last year they were available, despite somea > > problems meeting demand. >eE > Humm that isn't what IDC's latest quarterly breakdown of the servers > market shows at all.  H Hardly surprising, since the latest quarter didn't fall in the year 2000 last time I checked.   >o; > In the 100K to 1 million mark Compaq were 4th behind Sun,e9 > HP and IBM, Compaqs revenues went down 4% Sun and IBM's- > both grew.  G Another response (limited to comp.os.vms) indicated that HP's also went-G down, which you conveniently ignored above.  And since you neglected tohG state the magnitude of the Sun and IBM increases, we don't know whethernJ Alpha's change in acceptance was significant or marginal (though I'd guessA that the new IBM 8-CPU server may have made a noticeable impact).n  G The fact remains that Alpha sales remained significant despite Compaq'seJ continuing *complete* neglect of one of the two major operating systems onI the platform (VMS, which seems to constitute something like half of AlphasB business, though hard figures are difficult to come by).  The mainK impediment to Alpha - and GS - sales is Compaq's indifferent support of thelE platform (especially as contrasted with the vigor of its Intel-system # marketing), not memory performance.t   - bill   ------------------------------  % Date: Fri, 06 Jul 2001 18:44:00 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>t  Subject: Re: IA64 Rocks My World, Message-ID: <3B463F1C.D376B1D2@videotron.ca>   Bill Todd wrote:6 >  WildFire is a serious mistake. It isn't competitive@ > > because it is too costly to build, its big and it isn't fast > > enough.d > I > That must be why Compaq had its recent spate of super-computer wins (ata' > least one of them against SUN, IIRC).   K I am curious. I have personally never cares for Wildfires. Neat technology,e but very small market.  N However, if the wildfires are below expectations for performance and cost moreN than expected, could they be compared to the 9000 in terms of success (or lack
 thereof) ?   ------------------------------  % Date: Fri, 06 Jul 2001 18:05:47 -0500I* From: cjt & trefoil <cheljuba@prodigy.net>  Subject: Re: IA64 Rocks My World+ Message-ID: <3B46444B.4173727D@prodigy.net>o   "Main, Kerry" wrote: >  > Greg,- > I > re: OPS in a box .. I think Andrew is trying to state somehow that a HWtL > partitioned system using separate OS's within the same system (and OPS) is! > somehow not a valid benchmark. e <snip>  M Valid perhaps, but should a benchmark run on a partitioned system be comparede, directly to one on a non-partitioned system?   ------------------------------  $ Date: Fri, 6 Jul 2001 16:16:31 -04003 From: "Brad McCusker" <Brad.McCuskerSP@Mcompaq.com>h7 Subject: Re: Licensing problems with Pathworks 32 (NT4)e2 Message-ID: <a2p17.411$rc5.18167@news.cpqcorp.net>   Rob,  J We really need to know what version of PATHWORKS Server you are running on the VAX.J If Alan's suggestions don't seem to work or make sense for you, then maybeJ you are running some flavor of PATHWORKS V5.  Can you tell us what version< you ar running?  don't know?  How about an anal/image of theJ sys$system:pwrk$lmsrv.exe image and post the link date and ident.  That'll give us a starting point.e   Brad     --( The opinions expressed herein are my own' and do not reflect those of my employerg or anyone else.l   Brad    < "Rob Harrison" <robert.harrison@ch.abb.com> wrote in message7 news:df79e57d.0107060213.1a8bf5f4@posting.google.com... A > I am supporting a colleague who is in the Far East who is usingsH > Pathworks 32 to connect a PC running NT4 to an elderly VAX running VMS > 5.4 (don't ask)  >tH > We got a PAK with the software, there was nowhere to put it on PW32 soH > we installed it on the VAX and pointed the PW32 License Manager to it. > H > The only licensing options available on the version of PW that we haveD > are LAN Manager License Server and Novell License Server. We triedF > putting the VAX address in both of these without success. Every timeB > the machine boots we get an error saying that the software isn't > licensed.t >o? > Does anyone know what we need to do to sort this out, please?  >d > Many thanks, >c > Robt   ------------------------------  # Date: Sat, 07 Jul 2001 03:05:06 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>+ Subject: Re: New Mailbox 0.7 (anyone using)eA Message-ID: <C%u17.58279$2u2.1130968@e420r-sjo2.usenetserver.com>l  - Jerry Alan Braga <jabraga@flanagan.ca> wrote:  > Has anyone got this working.  	 > Config:r   > OpenVMS 7.1-1H2t > Compaq TCPIP 5.1 ECO-1 > Compaq C V6.4-005r  N > I downloaded the new version and installed it. but I try to run it I get the! > banner but then this stack dumpt   > $mc mlb_main  = > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtualN > address=000000000000( > 000A, PC=000000000003AE60, PS=0000001B9 >                         Version 0.7 -  ESME Sudria 2001n  J I'm getting a slightly different result, but it gets a SYSTEM-F-ACCVIO forL me also.  I'm running OpenVMS V7.2, TCPIP V5.0, and Compaq C V6.4-005.  I'veL got Mailbox 0.6 running on the system already (out of different directories,F and I really like it other than the way it handles *large* mailboxes).   			Zanee   ------------------------------  % Date: Fri, 06 Jul 2001 14:36:43 -0700m' From: David Mathog <mathog@caltech.edu>t Subject: ods5 and decc$from_vmst+ Message-ID: <3B462F6B.2C2471B1@caltech.edu>m  A A while back I posted a little program "VMS_TO_UNIX.C" which willc convert filenames from% VMS format to Unix format, like this:e   $ v2u [.users...]*.* /usrdisk/users/auser/r /usrdisk/users/buser/' etc.  C Anyway, I just discovered that it does not work correctly with ODS5n because it dies when ito# hits a name like:  cab63596^..fcgi;-   The problem comes at line:  *    (void) decc$from_vms(argv[1], emit, 1);  H where the emit routine is never even called with the "bad" string.  This is Compaq C V6.2-007 on  VMS/Alpha 7.2-1    Regards,   David Mathog mathog@caltech.eduj=   ------------------------------  # Date: Fri, 06 Jul 2001 18:18:43 GMT-1 From: "Mark D. Jilson" <jilly@clarityconnect.com>m Subject: Re: pk deviceso2 Message-ID: <3B4601F0.4BEFE102@clarityconnect.com>  
 OpenVMS Alpha7	 $ ANA/SYS1 CLUE CONFIGh CLUE SCSI/SUMM   Also see SYS$ETC:SCSI_INFO     steve smith wrote: > K > Is there a way to determine what scsi devices and their firmware revision  > either through DCL or SDAp >  > --
 > Steve Smithe > Manager Technical Services > Information Technology > Law Bulletin Publishing Co.' > (312)644-7067m > ssmith@LBPC.come > http://www.lawbulletin.com   --  D Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------   Date: 6 Jul 2001 22:39 CDT' From: carl@gerg.tamu.edu (Carl Perkins) # Subject: RE: POP server on tcpip5.1', Message-ID: <6JUL200122394928@gerg.tamu.edu>  % Tom Linden <tom@kednos.com> writes...aJ }OK, I can create accounts for the mail users in this manner.  But on a PC }running# }Outlook, for example, you specify,c }1. Mail serverd }2. your email address }3. login id }4. login passwd } J }So when the user opens his mailer, it automatically logs him into the POP }server. } J }Certainly I can't be the first person to try to use TCPIP5.1 to run a POP	 }service.eG }Aren't there any scripts avaialable for facilitating the process? E.g.yI }managing the POP server, adding/removing mail users, and so, or does onem }have to reinvent the wheel?  # I'm afraid I don't see the problem.n  " You enable POP in TCP/IP Services.  ? Bingo. Your existing users can now access their e-mail via POP.n? The mail server is the VMS system (for POP purposes - it may orr@ may not be your SMTP server for outgoing mail from the PCs). The= email address is the same as the login-id@the.vms.system. The = login id is the login id (generally called the username). Them% login password is the login password.r  A All you need to do is add an account for each additional user andm Bob's your uncle. You are done.n  C Account creation/removal for this is exactly like any other account D creation/removal, with the possible exception of limiting the user'sJ access to prevent them from having interactive login access to the system.   --- Carl   ------------------------------   Date: 6 Jul 2001 12:26:53 -0700l3 From: kenneth.h.fairfield@intel.com (Ken Fairfield)o6 Subject: Some thoughts on the recent turn of events...= Message-ID: <3147e88a.0107061126.36adc736@posting.google.com>i  @ In the midst  of  all  the  negativity  over  the cancelation ofH     Alpha,  I think one issue may have been missed, or not addressed  in:     sufficient depth: What does Intel get out of the deal?  H         Alpha proponents seem to  think  the cancelation is important toH     Intel  for  eliminating a competitor in the 64-bit processor  space,H     but Intel's stated vehicle is/was to be Windows 64 (or whatever theyH     call it), something  that  would  drive  high  volume  (supposedly).H     Personally,  I  doubt  Intel  cared much about Alpha.  They might beH     more concerned about Power or  whatever  AMD  may come out with, butH     Alpha  has been in a niche for a long time (all its life) and hardlyH     a threat to Intel in any of Intel's markets.   It  might  have  beenH     different  if  Win64 came out on Alpha ahead of Merced/McKinley, butH     it didn't.  That "threat" has been  dead for quite some time.  WhileH     it's  always nice to have HPTC bragging rights, I find it very  hardH     to imagine the presence or absence of Alpha would have much  bearingH     on  IA64  bottom  line.   Remember, Intel is successful because theyH     know  how  to  produce  processors  (and  memory)  in  high _volume_H     economically.   The  fate  of  IA64 does not turn on  HPTC  wins  or     losses.n  H         What else might there be  for  Intel?  The engineering talent ofH     both  the  Alpha designers and the compiler writers has been  raisedH     before and is certainly very important.  "Experience wins over youthH     and talent every time", or at least, most of the time.  There was  aH     even  a mention in the web-cast by Intel VP Paul Otellini concerningH     "new college  grads"  in  contrast  to  the  experienced  Alpha teamH     (although  I  expect the significance of that statement  might  have     been lost on most people).  H         But what I  think  has  been  missed  almost  entirely  in theseH     discussions  is  this: with NSK, VMS and, to a lesser extent,  Tru64H     being ported to IA64, Intel has immediate entr into the  enterpriseH     data  center.   The  _real_ enterprise data center.  Banks and stockH     exchanges, etc.  Thus Intel stands to gain credibility in these highH     profit market segments at the  hands  of  those who have proven theyH     know  enterprise computing, scalability and availability.   Perhaps,H     just perhaps, Intel  wasn't  entirely  comfortable  with  tying  itsH     fortunes  to  Win64,  especially  in  the  face of the dot-bomb, theH     contraction of the PC  market,  and  the  current  failure of W2K toH     penetrate  the  enterprise  data  center  in  any  significant  way.H     Perhaps HP could serve up some of that market, but my impression  isH     HP's  enterprise  presense  has  been  shrinking in recent years andH     besides, they're known more for their  PCs (and printers!) then they#     are for HPUX and the PA-RISC...e  H         None of us know what Compaq got from Intel in this deal.  But itH     _could_ have been very sweet for  all we know.  Craig Barrett didn'tH     have  much to say in the web-cast.  I'm guessing he was playing  hisH     cards close to his chest, that he wouldn't want to say  anything  toH     upset  M$,  and  he  didn't  _have_  to  say  much.   OTOH,  a  mereH     endorsement of IA-64 my one  of  Intel's favored OEM's wouldn't haveH     required  Intel to hire Compaq engineers, and this in the face of  aH     corporate-wide hiring freeze, a general trimming of the work  force,6     and selling off or closing of non-core businesses.    H         I'd also like to comment that I  was as surprised and shocked byH     the announcements as anyone.  I really like Alpha and I'm sad to seeH     it go.  But I _love_ VMS and I want to see it to survive.  My careerH     depends  upon  it!  IMHO, porting VMS to IA64 makes it more  viable,H     not less.  It certainly helps VMS' viability where I work!  :-)  :-)H     :-)  People  on this list having been asking for VMS on Intel for atH     least a decade.  And why?   Mostly  for low cost hardware that comesH     along  with  a volume product.  I think we're getting what we  askedH     for.  Arguments about the expense of Merced aside, IA64 _in  volume_H     is  the future of Intel.  Intel have done wonderful things with IA32H     (in terms of speed  and  volume)  but  everyone knows that effort isH     running  out  of  steam.  By the time VMS is ported, there  will  beH     volume shipments of IA64 processors (or Intel  will  go  under,  notH     something  I'd  bet on), and that bodes well for the price conscious,     VMS enthusiast or small-business person.  H         Finally, with the exception perhaps  of Brain Schenkenberger andH     a  few of his ilk, the change in the underlying instruction set willH     have NO effect on what we do with VMS.  Even Brian's attitude is,  IH     suspect,  colored as much by the Gatesware that runs on top of IA32,H     and the generally under-engineered,  under-tested commodity hardwareH     its  embedded in, as it is by any "quality" issues between the AlphaH     and EPIC.  EPIC may be "badly" designed, it may be "not as  good  orH     elegant"   as  the  Alpha,  but  most  programmers  won't  know  theH     difference.  Period.  Compilers _will_ produce correct assembly codeH     for EPIC, and it will run fast (not as fast as Alpha would have, butH     fast enough), and there will  be  AST's delivered and device drivers0     written.  So what's everyone so upset about?  H         I know, we're all upset that Compaq has been following Digital'sH     lead down the "road to hell" with  Alpha and VMS.  No marketing.  NoH     valuing  of  its crown jewels.  Not listening to its most loyal  andH     technical customers.  Not supporting  those  customers,  like  DavidH     Mathog, who were essentially begging to continue running VMS but gotH     NO  support  in  that  effort  from  Compaq  (his bitterness is wellH     earned!).  The fact that things didn't  _have_ to turn out this way.H     There  are  LOTS of grievances.  We've been "trained" to expect  theH     worst in the face of these changes: first when VMS was not going  toH     be  ported to Alpha at all, later when they tried to drag us kickingH     and screaming to WNT, most  recently the uncertainty (and mourning?)H     that  followed  Digital's sale to Compaq.  Each of these events  hasH     boded poorly for the future of VMS and the future  of  those  of  usH     whose  careers  depend  upon  VMS.  Of all these changes, the recent7     deal with Intel is, for me, the _least_ unsettling.n  H         Look, if the deal hadn't  been  made,  VMS would be dependent onH     Alpha.   Alpha was only viable if it gained some volume,  originallyH     to be provided by WNT.  That failed.  The volume isn't there.   It'sH     expensive  to  produce low-volume processors and you're always goingH     to be at least  one  step,  often  two, behind in process technologyH     when  you go the fab-less route.  Even if EV8 were the most advancedH     processor design on the planet, it would need to compete  for  spaceH     in  the  fabs, and to get the latest processes (newest fabs) costs aH     premium.  There would NEVER be a low-cost VMS system and chances areH     VMS (and Tru64) would retreat ever further into niches where cost isH     not a issue (like NSK).   ...Until  the  niches evaporated or becameH     too small to sustain VMS Engineering, etc.  [Bill Todd's analysis ofH     profit/loss  aside:  it's  clear  Compaq didn't want to  be  in  the     microprocessor business.]l  H         My biggest concerns at this point  are  not the loss of Alpha orH     whether  the  port of VMS to IA64 will go forward (I'm confident  itH     will).  Rather, I'm concerned about the transfer of compiler writersH     to Intel (all of them?!  some of them just to  produce  a  good  GEMH     back  end?   what what about compilers for Alpha/VMS?) and what that)     means for VMS versions of compilers .-  H         Even more so,  I'm  concerned  about  the "180 days" conversion.H     People  seem  to  be saying that Compaq wants to  turn  itself  intoH     another IBM.  Does anyone  here  _not_  remember  what  happened  toH     Digital when _they_ tried to turn themselves into another IBM duringH     the  80s?!   Furthermore, it's apparently common knowledge that whatH     Compaq wanted most of all  in  the Digital purchase was its servicesH     division.   What I heard at CETS 2000 was that services was in  VERYH     BAD shape, at least from  the  customer's  perspective,  with  callsH     being  prematurely  closed without resolution and replacement parts,H     etc., not being readily/locally  available.   Maybe  it's just a fewH     isolated  incidents,  but  during the "Compaq Listen's"  panel,  theH     services VP was taking most of the heat and it was clear  he  didn'tH     even _know_ there was a _problem_!!  Terry, is the same person stillH     running  services  and/or has there been any improvement?  You can'tH     be another IBM if you don't take  care of your customers like IBM...B     And _that_ is the biggest risk I see for the future of Compaq.           -Ken -- ...Not speaking for Intel...   ------------------------------  # Date: Fri, 06 Jul 2001 20:07:51 GMTt4 From: "Terry C. Shannon" <terryshannon@mediaone.net>: Subject: Re: Some thoughts on the recent turn of events...: Message-ID: <rUo17.645$vb6.551884@typhoon.ne.mediaone.net>  @ "Ken Fairfield" <kenneth.h.fairfield@intel.com> wrote in message7 news:3147e88a.0107061126.36adc736@posting.google.com...s   >uJ >         Even more so,  I'm  concerned  about  the "180 days" conversion.J >     People  seem  to  be saying that Compaq wants to  turn  itself  intoJ >     another IBM.  Does anyone  here  _not_  remember  what  happened  toJ >     Digital when _they_ tried to turn themselves into another IBM duringJ >     the  80s?!   Furthermore, it's apparently common knowledge that whatJ >     Compaq wanted most of all  in  the Digital purchase was its servicesJ >     division.   What I heard at CETS 2000 was that services was in  VERYJ >     BAD shape, at least from  the  customer's  perspective,  with  callsJ >     being  prematurely  closed without resolution and replacement parts,J >     etc., not being readily/locally  available.   Maybe  it's just a fewJ >     isolated  incidents,  but  during the "Compaq Listen's"  panel,  theJ >     services VP was taking most of the heat and it was clear  he  didn'tJ >     even _know_ there was a _problem_!!  Terry, is the same person still? >     running  services  and/or has there been any improvement?a  J I honestly can't remember if Peter Mercury, the new unified Services GroupL VP, was at CETS2000. As for problems with services, the most recent customerG sat info from EMEA indicates that Compaq Services has attained the sames@ satisfaction levels that Digital Services delivered prior to theE Compaq-tion. CPQ lost a lot of ground in the Services space, but they 0 finally appear to be getting their act together.  L I don't think Michael Capellas' goal is to turn CPQ into another IBM, but heL set forth a pretty ambitious agenda in the 180 Day Transformation Scheme. IfH the Grand Transmogrification doesn't materialize, the CEO will have some issues to deal with...   ------------------------------  $ Date: Fri, 6 Jul 2001 16:03:31 -05001 From: "Dave Gudewicz" <david.gudewicz@abbott.com>e: Subject: Re: Some thoughts on the recent turn of events...8 Message-ID: <9i5932$rqg$1@fizban.fizban.pprd.abbott.com>  J I believe what Ken has said is a fair and objective assessment of the what happened to Alpha and why.  9 I hope to boot a future IA-64 system and be greeted with:a   Welcome to OpenVMS.....s     Dave...   @ "Ken Fairfield" <kenneth.h.fairfield@intel.com> wrote in message7 news:3147e88a.0107061126.36adc736@posting.google.com...aB > In the midst  of  all  the  negativity  over  the cancelation ofJ >     Alpha,  I think one issue may have been missed, or not addressed  in< >     sufficient depth: What does Intel get out of the deal?  
 <big snip>   > ...Not speaking for Intel...   ------------------------------  $ Date: Fri, 6 Jul 2001 20:20:40 -0400' From: "Bill Todd" <billtodd@foo.mv.com>I: Subject: Re: Some thoughts on the recent turn of events...( Message-ID: <9i5kdq$jcj$1@pyrite.mv.net>  @ "Ken Fairfield" <kenneth.h.fairfield@intel.com> wrote in message7 news:3147e88a.0107061126.36adc736@posting.google.com... B > In the midst  of  all  the  negativity  over  the cancelation ofJ >     Alpha,  I think one issue may have been missed, or not addressed  in< >     sufficient depth: What does Intel get out of the deal? >oJ >         Alpha proponents seem to  think  the cancelation is important toJ >     Intel  for  eliminating a competitor in the 64-bit processor  space,   And they're right - see below.  J >     but Intel's stated vehicle is/was to be Windows 64 (or whatever theyJ >     call it), something  that  would  drive  high  volume  (supposedly).  ( And exactly where *is* that high volume?  K At the low end, IA32 platforms will be more than adequate for virtually allfH desktop and most server needs for the foreseeable future.  That leaves aE minor percentage of the server market and the highish-end workstationrL markets for Win64 (which of course Win64 on Alpha would have been addressingI for around a year now but for Compaq's short-sightedness) - and IA64 willeJ face competition there from Win64 on AMD-64 and from other OSs (especially; Linux) on the remaining 64-bit platforms (SPARC and POWER).d  J >     Personally,  I  doubt  Intel  cared much about Alpha.  They might beJ >     more concerned about Power or  whatever  AMD  may come out with, butJ >     Alpha  has been in a niche for a long time (all its life) and hardly2 >     a threat to Intel in any of Intel's markets.  G Not an active threat, given Compaq's disinclination to make it one, but:K always a *potential* threat should a company with more balls acquire it (ors! Compaq acquire balls of its own).   K And it's disingenuous to talk about "Intel's markets" for IA64:  THEY DON'TyL EXIST YET (and might *never* exist, especially with active Alpha competitionA on the high end and both IA32 and AMD-64 competition lower down).e      It  might  have  beenJ >     different  if  Win64 came out on Alpha ahead of Merced/McKinley, butC >     it didn't.  That "threat" has been  dead for quite some time.    Thanks to Compaq.-     While-J >     it's  always nice to have HPTC bragging rights, I find it very  hardJ >     to imagine the presence or absence of Alpha would have much  bearingJ >     on  IA64  bottom  line.   Remember, Intel is successful because theyJ >     know  how  to  produce  processors  (and  memory)  in  high _volume_ >     economically.   K And IA64 has no likely high-volume market save for low-end 64-bit systems -S? the kind with commodity-level quality, components, reliability,tL availability, scalability, and performance - where it will be competing with AMD-64 and IA32 systems.  J Why assume that a more-than-order-of-magnitude increase in the size of theI mid-range-to-high-end server market will give Intel the kind of volume itm9 would take to dramatically decrease the component cost ofe mid-range-to-high-end systems?  K Instead, assume that the size of that market won't suddenly explode.  TherePG are only a few competitors in that market today, so even if one companyaL dominated it their volume wouldn't dramatically change  production economiesJ of scale.  And in that product space the cost of each individual processorL is peanuts compared with the overall cost of the system, so any volume priceJ advantage enjoyed by basing the system on IA64 CPUs rather than some other$ processor is well down in the noise.   ...n  J >         But what I  think  has  been  missed  almost  entirely  in theseJ >     discussions  is  this: with NSK, VMS and, to a lesser extent,  Tru64J >     being ported to IA64, Intel has immediate entr into the  enterprise9 >     data  center.   The  _real_ enterprise data center.e  J It doesn't have to wait 2 years for Tru64, 3 years for VMS, or 4 years forC NSK for that entre:  it has it today, via HP/UX, and tomorrow, withtJ Superdome (said to be ready to incorporate IA64 processors as replacementsI for PA-RISC).  But I'm sure most customers will just wait a few years forsF other systems to be ported, since they have so much more confidence in Compaq than in HP.     Banks and stocke >     exchanges, etc.n  . Ah - so we're mostly talking NSK in 2005, now.  5   Thus Intel stands to gain credibility in these highcJ >     profit market segments at the  hands  of  those who have proven theyJ >     know  enterprise computing, scalability and availability.   Perhaps,J >     just perhaps, Intel  wasn't  entirely  comfortable  with  tying  itsJ >     fortunes  to  Win64,  especially  in  the  face of the dot-bomb, theJ >     contraction of the PC  market,  and  the  current  failure of W2K toJ >     penetrate  the  enterprise  data  center  in  any  significant  way.J >     Perhaps HP could serve up some of that market, but my impression  isF >     HP's  enterprise  presense  has  been  shrinking in recent years  3 Sure just received a major shot in the arm, though.e    andJ >     besides, they're known more for their  PCs (and printers!) then they% >     are for HPUX and the PA-RISC...y  ; Sort of like Compaq is mostly known for PCs and hand-helds.g   >lB >         None of us know what Compaq got from Intel in this deal.  L Malaysia plus a significant chunk of Taiwan would have been fair, I suspect.     But itJ >     _could_ have been very sweet for  all we know.  Craig Barrett didn'tJ >     have  much to say in the web-cast.  I'm guessing he was playing  hisJ >     cards close to his chest, that he wouldn't want to say  anything  toJ >     upset  M$,  and  he  didn't  _have_  to  say  much.   OTOH,  a  mereJ >     endorsement of IA-64 my one  of  Intel's favored OEM's wouldn't haveJ >     required  Intel to hire Compaq engineers, and this in the face of  aJ >     corporate-wide hiring freeze, a general trimming of the work  force,8 >     and selling off or closing of non-core businesses.  K Processor development isn't exactly a non-core Intel business, though.  AndaH if allegations about the inexperience of a fair-size percentage of theirK development force had even a small basis in reality, then I doubt that theys; were 'required' to hire those experienced Compaq engineers.s   >h >hJ >         I'd also like to comment that I  was as surprised and shocked byJ >     the announcements as anyone.  I really like Alpha and I'm sad to see? >     it go.  But I _love_ VMS and I want to see it to survive.i  J I think Alphaman put it well:  cutting off its legs seems a strange way to go about that.     My career2J >     depends  upon  it!  IMHO, porting VMS to IA64 makes it more  viable,J >     not less.  It certainly helps VMS' viability where I work!  :-)  :-)  I Er, did you mean "VMS' *visibility*" above, or have you got new orders to J place on the basis of this event that would not have been placed two weeks ago?  J >     :-)  People  on this list having been asking for VMS on Intel for at >     least a decade.t  L I suspect that if you had polled them a month ago asking whether they wantedL such a port at the expense of losing Alpha (which is of course the situation3 that has occurred) you would have found few takers.n  5   And why?   Mostly  for low cost hardware that comessJ >     along  with  a volume product.  I think we're getting what we  asked
 >     for.  H See above, and let the people who were supporting a port tell us whether this is what they wanted.i  @   Arguments about the expense of Merced aside, IA64 _in  volume_ >     is  the future of Intel.  C Yes, and a future far from assured of anything like the success youiJ postulate as a 'given' - though with Alpha out of the way that future sure looks brighter now.   ,   Intel have done wonderful things with IA32J >     (in terms of speed  and  volume)  but  everyone knows that effort isJ >     running  out  of  steam.  By the time VMS is ported, there  will  beJ >     volume shipments of IA64 processors (or Intel  will  go  under,  notJ >     something  I'd  bet on), and that bodes well for the price conscious. >     VMS enthusiast or small-business person.  C Boy, you really have confidence in your ability to predict what thexJ situation will look like 3 years out.  I guess the idea that the future is' what you make it is just old-fashioned.    > J >         Finally, with the exception perhaps  of Brain Schenkenberger andJ >     a  few of his ilk, the change in the underlying instruction set willJ >     have NO effect on what we do with VMS.  Even Brian's attitude is,  IJ >     suspect,  colored as much by the Gatesware that runs on top of IA32,J >     and the generally under-engineered,  under-tested commodity hardwareJ >     its  embedded in, as it is by any "quality" issues between the AlphaJ >     and EPIC.  EPIC may be "badly" designed, it may be "not as  good  orJ >     elegant"   as  the  Alpha,  but  most  programmers  won't  know  theJ >     difference.  Period.  Compilers _will_ produce correct assembly codeJ >     for EPIC, and it will run fast (not as fast as Alpha would have, butJ >     fast enough), and there will  be  AST's delivered and device drivers2 >     written.  So what's everyone so upset about?  G Hmmm.  Lying to customers?  Breaking yet more long-term, oft-reiterated H (right up to two weeks ago) commitments?  Cutting off VMS's legs withoutJ making *any* compensatory moves to make its future more credible (the portH doesn't qualify:  it can be fully written off as the minimum expenditureJ required to keep customers from bolting en masse)?  Yet another indicationK that Compaq has no interest in owning and developing its own technology butnL just in milking it for the short term?  Yet more proof that Compaq is run by chimpanzees?  & It's hard to know even where to begin.   >sJ >         I know, we're all upset that Compaq has been following Digital'sJ >     lead down the "road to hell" with  Alpha and VMS.  No marketing.  NoJ >     valuing  of  its crown jewels.  Not listening to its most loyal  andJ >     technical customers.  Not supporting  those  customers,  like  DavidJ >     Mathog, who were essentially begging to continue running VMS but gotJ >     NO  support  in  that  effort  from  Compaq  (his bitterness is wellJ >     earned!).  The fact that things didn't  _have_ to turn out this way.  1 See?  You even knew a lot of the answer yourself.   J >     There  are  LOTS of grievances.  We've been "trained" to expect  theJ >     worst in the face of these changes: first when VMS was not going  toJ >     be  ported to Alpha at all, later when they tried to drag us kickingJ >     and screaming to WNT, most  recently the uncertainty (and mourning?)J >     that  followed  Digital's sale to Compaq.  Each of these events  hasJ >     boded poorly for the future of VMS and the future  of  those  of  usJ >     whose  careers  depend  upon  VMS.  Of all these changes, the recent9 >     deal with Intel is, for me, the _least_ unsettling.o  J The problem is, regardless of their *relative* importance (which of courseL varies with individuals), that the overall effect is *cumulative*.  And this  will for many be the last straw.   >pJ >         Look, if the deal hadn't  been  made,  VMS would be dependent onJ >     Alpha.   Alpha was only viable if it gained some volume,  originally* >     to be provided by WNT.  That failed.  ' Rather, Compaq killed that opportunity.t      The volume isn't there.   It'sJ >     expensive  to  produce low-volume processors and you're always goingJ >     to be at least  one  step,  often  two, behind in process technology& >     when  you go the fab-less route.  I IBM seems to have been happy to help Compaq keep up in that area (or even6L move a bit ahead - has Intel got SOI technology yet?).  That's their fabbing7 model:  provide the best technology they can to anyone.e  $   Even if EV8 were the most advanced% >     processor design on the planet,o  K Your use of the subjunctive is interesting:  by many accounts, EV8 *is* thel- most advanced processor design on the planet.   %  it would need to compete  for  spacee >     in  the  fabs,  J And you don't think IBM would jump at the chance to produce Alpha chips atL the expense of Intel's fabs?  Compaq may not be inclined to compete, but IBMB hasn't shown any similar inclination:  Gerstner *does* have balls.  6  and to get the latest processes (newest fabs) costs a: >     premium.  There would NEVER be a low-cost VMS system  L For Christ's sake:  there *already is* a low-cost VMS system ($6K won't evenJ buy you much in the way of a used car, but it'll get you a shiny new DS10,H last I knew).  There just isn't a bottom-dollar VMS competitor to Wintel9 systems, and there very, very likely still never will be.a    and chances areJ >     VMS (and Tru64) would retreat ever further into niches where cost isJ >     not a issue (like NSK).   ...Until  the  niches evaporated or became0 >     too small to sustain VMS Engineering, etc.  J The applicable 'niche' is the mid-range-and-higher portion of the market -K where most of the profits are made these days.  That market isn't driven by J Windows and isn't satisfied with low-end hardware, so VMS and Alpha were a" really good fit - until June 25th.     [Bill Todd's analysis ofJ >     profit/loss  aside:  it's  clear  Compaq didn't want to  be  in  the >     microprocessor business.]:  J You know, if people would just simply say "Compaq DIDN'T WANT to be in theB microprocessor business" rather than keep trying to find some realG justification where there clearly is none, they'd look a lot less sillynJ and/or sycophantic.  But I'm glad we found at least one point to agree on.   ...y  J >         Even more so,  I'm  concerned  about  the "180 days" conversion.J >     People  seem  to  be saying that Compaq wants to  turn  itself  into >     another IBM.  I That's because Capellas has said on at least two occasions (the June 25thhJ announcement and a July 2nd InformationWeek 'interview' that gave him softI pitches that allowed him to repeat the announcement) that he's looking toi IBM as a business model.   - bill   ------------------------------  % Date: Fri, 06 Jul 2001 22:02:27 -0400e2 From: rdeininger@mindspring.com (Robert Deininger): Subject: Re: Some thoughts on the recent turn of events...L Message-ID: <rdeininger-0607012202280001@user-2iveaga.dialup.mindspring.com>  J In article <9i5kdq$jcj$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> wrote:   >   Banks and stocke > >     exchanges, etc.e > 0 > Ah - so we're mostly talking NSK in 2005, now.  J I don't think that's a fair statement.  Banks and stock exchanges also useH a lot of VMS.  I don't know the relative numbers.  But both platforms do? thinks these folks find very important, and both platforms work  side-by-side at a lot of sites.r   -- n Robert Deininger rdeininger@mindspring.coma   ------------------------------  $ Date: Fri, 6 Jul 2001 22:58:30 -0400' From: "Bill Todd" <billtodd@foo.mv.com> : Subject: Re: Some thoughts on the recent turn of events...( Message-ID: <9i5tlg$one$1@pyrite.mv.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in message F news:rdeininger-0607012202280001@user-2iveaga.dialup.mindspring.com...L > In article <9i5kdq$jcj$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> > wrote: >t > >   Banks and stock- > > >     exchanges, etc.  > > 2 > > Ah - so we're mostly talking NSK in 2005, now. >dL > I don't think that's a fair statement.  Banks and stock exchanges also use > a lot of VMS.-  J Banks at least seem to be moving away from VMS more than toward it.  SWIFTF is the example that's usually brought up, and I'm not sure whether the: European brouhaha a while ago was SWIFT or something else.  H The bottom line is that while NSK has no competition in that space (saveL perhaps for similar low-volume IBM products - including I think what used toJ be Stratus; Sun has some form of hardware-redundant offering, but it's notC clear that's made much headway in those parts), VMS is increasinglyrK replaceable by other offerings.  There's certainly no guarantee of a marketaC there in 2 - 3 years if customers perceive VMS to have an even more-) uncertain future than it had a month ago.2   - bill  ;   I don't know the relative numbers.  But both platforms dohA > thinks these folks find very important, and both platforms worky! > side-by-side at a lot of sites.n >h > -- > Robert Deininger > rdeininger@mindspring.com.   ------------------------------  # Date: Sat, 07 Jul 2001 05:36:00 GMT . From: "mulp" <michaelpettengill@earthlink.net>: Subject: Re: Some thoughts on the recent turn of events...D Message-ID: <4dx17.7095$G_1.712148@newsread2.prod.itd.earthlink.net>  G Rather than go into a point by point comment on the original note, I'lloJ instead just focus on what it means to be going from VAX and Alpha to IA64 for VMS.  I While Compaq may be shedding over time some large amount of money on chipdL development, what Compaq has just bought into is a significant investment inD tools and applications.  However, there are no plans yet on what theH investment will be.  Oh, there have been vague words about Intel funding
 this work.  L But let's consider what little we do know.  We know that Intel wants the DECF Fortran engineers and wants them to merge the Intel and Visual FortranE products for Intel.  Nothing, however, was reported about making it auK priority to deliver an IA64 Fortran compiler for unix or vms; no mention ofe4 hiring more than just the people bought from Compaq.  G My guess is that BASIC, PASCAL, maybe COBOL, certainly PL/I will be low G priorities for Intel when it comes to VMS.  They will look at the saleseE figures and conclude that the demand isn't high enough to justify the,G investment.  This is certainly way off the mark, but I don't think that G Compaq understands it any better than Intel does.  The result will be avH number of applications and products that won't be able to move to Alpha.  K There hasn't been any word about a VAX to IA64 binary code translator.  NoreL an Alpha to IA64 translator.  Simply recompile from source, right?  Sure, itL will be easy to recompile that PL/I or BASIC code.  And everyone has all theF code for everything that they bought including the software from third& parties who have gone out of business.  E The bottom line is that while DEC announced Alpha AFTER the migrationnD process was well underway (yeah, there were rumors galore along withL technology demos before hand).  This migration has been announced before anyH plans have been put in place and without any idea of what the budget andK resources will need to be.  Things are significantly different today than aeL decade ago.  A decade ago, nearly every product that needed to be ported wasG under active development and the Alpha porting work largely delayed newhF development rather than requiring added resources.  Today, most of theI critical products are in maintenance mode and doing the porting work will F require budgets that allow staffing up projects to do the development,K testing, release, and initial support.  The current statements are for $200nF million in cuts for each of the next two quarters; is that going to be) offset by $10s of millions in new hiring?c  I Oracle basically doesn't do anything without a vendor paying for it.  AndaL the situation with other ISVs is similar unless they are largely forced intoK using VMS.  Even the health care products that are so critical to VMS sales K have been ported to other platforms; some customers have been using them on J VMS for years and like VMS because of its reliability and availability andL other aspects, but I can easily imagine one of the key vendors in that space= simply staying with Alpha until its critical to move to IA64.r  J What it comes down to is that you can't move to a platform until it offersL all the products that you require.  Maybe you don't have something you would/ like, but you will have everything you require.   I For the Alpha migration, the process of just making the lists of software J that was needed started more than two years before Alpha was announced andG again, this work was done with existing product management.  The FridayeH before the IA64 deal was announced, a couple more VMS product managementJ people were axed.  The terms of the termination are that they can't returnG for one year and that when they do, they return as new employees in all H respects.  Hey, no problem, just hire a few kids out of college; they'll; have a lot of background in VMS and will understand all theo< inter-relationships between products, vendors, customers....  K And when is someone going to ask about seed units.  When are the ISVs goingsI to get IA64 seed units.  Compaq will be giving them away for free, right?vL Or will it be Intel that will be giving VMS ISVs free seed units?  May guessE is that VMS ISVs will be forking out some significant dollars for newfK hardware to support their porting efforts.  My guess is that the Alpha seedrH program will look down right generous compared to the IA64 seed program.  , The planning for this sure looks to me like:     VMS customers are loyal,     VMS ISVs are locked inI     VMS customers and ISVs will have to put up with whatever we give themjG      We'll do as little as possible, doing more only when the customerse2       and ISVs convince us that we have to do more   ------------------------------  % Date: Fri, 06 Jul 2001 13:51:00 -0400l# From: Jim Agnew <Agnew@hsc.vcu.edu>l Subject: Re: Telnet APIo+ Message-ID: <3B45FA84.DCFD7B73@hsc.vcu.edu>   I I looked into Kermit once for this... I suppose it's possible...  but,...    Jim    john nixon wrote:e  L > I probably don't have enough information or knowledge to properly ask this> > question, but I have been asked to find a TELNET API forVMS. >lI > Our programmers have been using a sort of home brewed port of somethingMK > called PS LIB (presumably from a Berkley Unix implemenation).  It doesn'tnN > work very well on our VMS systems and is missing a lot of functionality.  WeK > have customers that wish to use Telnet to talk to us, so we have a screenhJ > scraper to decode what would be output to a standard VT100.  Things likeM > scroll buttons and certain interrupts cause us a lot of problems and we get-= > a lot of access violations and terminal hangs and timeouts.e >rL > Does this make enough sense for somebody to recommend a product that I can > have them look at? >o	 > Thanks,e >      Johnu   ------------------------------   Date: 6 Jul 2001 18:21:33 GMT 0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Subject: Re: Telnet API 5 Message-ID: <9i4vjd$jnc$1@newsmaster.cc.columbia.edu>'  ? In article <8Nm17.179716$WB1.26118327@typhoon.tampabay.rr.com>,o% john nixon <jnixon@cfl.rr.com> wrote:eL : I probably don't have enough information or knowledge to properly ask this> : question, but I have been asked to find a TELNET API forVMS. : I : Our programmers have been using a sort of home brewed port of something!K : called PS LIB (presumably from a Berkley Unix implemenation).  It doesn't N : work very well on our VMS systems and is missing a lot of functionality.  WeK : have customers that wish to use Telnet to talk to us, so we have a screen J : scraper to decode what would be output to a standard VT100.  Things likeM : scroll buttons and certain interrupts cause us a lot of problems and we getA= : a lot of access violations and terminal hangs and timeouts.w : L : Does this make enough sense for somebody to recommend a product that I can : have them look at? : G On what OS, and for what language, do you need the Telnet API?  Is this . for Windows, making Telnet connections to VMS?  E Some Windows Telnet clients include VT320 terminal emulators that are I VMS-friendly, and also include a script programming language that let you H write applications over Telnet and/or automate Telnet sessions, and evenL up- and download files over the Telnet connection.  An example is Kermit 95:  )   http://www.columbia.edu/kermit/k95.htmlu  L Kermit 95 also includes a degree of screen-scraping capability, demonstrated here:f  4   http://www.columbia.edu/kermit/ckscripts.html#scra   - Frankt   ------------------------------  % Date: Fri, 06 Jul 2001 12:40:43 -0700g! From: Tom Linden <tom@kednos.com>d Subject: RE: Telnet API 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEOICOAA.tom@kednos.com>-  . putty implements ssh, i use it from W2K to VMS > -----Original Message-----9 > From: Frank da Cruz [mailto:fdc@watsun.cc.columbia.edu]e& > Sent: Friday, July 06, 2001 11:22 AM > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: Telnet API  >  >eA > In article <8Nm17.179716$WB1.26118327@typhoon.tampabay.rr.com>,,' > john nixon <jnixon@cfl.rr.com> wrote: < > : I probably don't have enough information or knowledge to > properly ask thisI@ > : question, but I have been asked to find a TELNET API forVMS. > :IK > : Our programmers have been using a sort of home brewed port of somethingaA > : called PS LIB (presumably from a Berkley Unix implemenation).n > It doesn't= > : work very well on our VMS systems and is missing a lot of  > functionality.  We? > : have customers that wish to use Telnet to talk to us, so we  > have a screenPL > : scraper to decode what would be output to a standard VT100.  Things like; > : scroll buttons and certain interrupts cause us a lot ofa > problems and we geti? > : a lot of access violations and terminal hangs and timeouts.a > :vC > : Does this make enough sense for somebody to recommend a productr > that I can > : have them look at? > :tI > On what OS, and for what language, do you need the Telnet API?  Is thism0 > for Windows, making Telnet connections to VMS? > G > Some Windows Telnet clients include VT320 terminal emulators that areiK > VMS-friendly, and also include a script programming language that let youiJ > write applications over Telnet and/or automate Telnet sessions, and evenC > up- and download files over the Telnet connection.  An example isp > Kermit 95: >m+ >   http://www.columbia.edu/kermit/k95.htmle >.A > Kermit 95 also includes a degree of screen-scraping capability,o > demonstrated > here:d >w6 >   http://www.columbia.edu/kermit/ckscripts.html#scra >o	 > - Franku >    ------------------------------  $ Date: Fri, 6 Jul 2001 15:53:51 -0400= From: "Technical Support" <Tech_Support@SoftwarePartners.com>  Subject: Re: Telnet APIs! Message-ID: <3b45a65b$1@aerostar>g  C If it is indeed a windows telnet client you're looking for.  I likei TeraTermPro.  It's open source.     1 "john nixon" <jnixon@cfl.rr.com> wrote in messagea9 news:8Nm17.179716$WB1.26118327@typhoon.tampabay.rr.com... L > I probably don't have enough information or knowledge to properly ask this> > question, but I have been asked to find a TELNET API forVMS. >gI > Our programmers have been using a sort of home brewed port of somethingcK > called PS LIB (presumably from a Berkley Unix implemenation).  It doesn'tgJ > work very well on our VMS systems and is missing a lot of functionality. WeK > have customers that wish to use Telnet to talk to us, so we have a screen J > scraper to decode what would be output to a standard VT100.  Things likeI > scroll buttons and certain interrupts cause us a lot of problems and we  getd= > a lot of access violations and terminal hangs and timeouts.t >nL > Does this make enough sense for somebody to recommend a product that I can > have them look at? > 	 > Thanks,o >      Johna >a >t   ------------------------------  % Date: Fri, 06 Jul 2001 16:09:04 -0500b0 From: Patrick Spinler <spinler.patrick@mayo.edu> Subject: Re: Telnet APIt( Message-ID: <3B4628F0.5E4DD47B@mayo.edu>  C Consider using Perl with the Net::Telnet module (installed with theo libnet bundle).r  B This solution should work regardless if the client is Win* or VMS.   -- Pat   john nixon wrote:h > L > I probably don't have enough information or knowledge to properly ask this> > question, but I have been asked to find a TELNET API forVMS. > I > Our programmers have been using a sort of home brewed port of somethingeK > called PS LIB (presumably from a Berkley Unix implemenation).  It doesn't N > work very well on our VMS systems and is missing a lot of functionality.  WeK > have customers that wish to use Telnet to talk to us, so we have a screenlJ > scraper to decode what would be output to a standard VT100.  Things likeM > scroll buttons and certain interrupts cause us a lot of problems and we getx= > a lot of access violations and terminal hangs and timeouts.b > L > Does this make enough sense for somebody to recommend a product that I can > have them look at? > 	 > Thanks,f >      John    -- r?       This message does not represent the policies or positionss1 	     of the Mayo Foundation or its subsidiaries.63   Patrick Spinler			email:	Spinler.Patrick@Mayo.EDUb'   Mayo Foundation			phone:	507/284-9485I   ------------------------------  % Date: Fri, 06 Jul 2001 16:23:55 -0500,0 From: Patrick Spinler <spinler.patrick@mayo.edu> Subject: Re: Telnet API ( Message-ID: <3B462C6B.B813BA8C@mayo.edu>  8 BTW - there also appear to be several perl modules (like8 Term::ANSIScreen) which interpret ansi escape sequences.   -- Pat   Patrick Spinler wrote: > E > Consider using Perl with the Net::Telnet module (installed with thet > libnet bundle).h > D > This solution should work regardless if the client is Win* or VMS. >  > -- Pat >  > john nixon wrote:s > > N > > I probably don't have enough information or knowledge to properly ask this@ > > question, but I have been asked to find a TELNET API forVMS. > >iK > > Our programmers have been using a sort of home brewed port of somethingmM > > called PS LIB (presumably from a Berkley Unix implemenation).  It doesn'tkP > > work very well on our VMS systems and is missing a lot of functionality.  WeM > > have customers that wish to use Telnet to talk to us, so we have a screenoL > > scraper to decode what would be output to a standard VT100.  Things likeO > > scroll buttons and certain interrupts cause us a lot of problems and we get ? > > a lot of access violations and terminal hangs and timeouts.  > >aN > > Does this make enough sense for somebody to recommend a product that I can > > have them look at? > >v > > Thanks,i
 > >      Johnw >  > --A >       This message does not represent the policies or positionso: >              of the Mayo Foundation or its subsidiaries.J >   Patrick Spinler                       email:  Spinler.Patrick@Mayo.EDU> >   Mayo Foundation                       phone:  507/284-9485   -- s?       This message does not represent the policies or positionsn1 	     of the Mayo Foundation or its subsidiaries."3   Patrick Spinler			email:	Spinler.Patrick@Mayo.EDU '   Mayo Foundation			phone:	507/284-9485    ------------------------------  % Date: Fri, 06 Jul 2001 16:31:23 -0500f0 From: Patrick Spinler <spinler.patrick@mayo.edu> Subject: Re: Telnet APIk( Message-ID: <3B462E2B.F476420E@mayo.edu>  . This is my last followup to myself, really :-/  E It appears that the perl Term::VT102 module might be the best bet forD% screen scraping a vt* telnet session.    -- Pat   Patrick Spinler wrote: > : > BTW - there also appear to be several perl modules (like: > Term::ANSIScreen) which interpret ansi escape sequences. >  > -- Pat >    --  ?       This message does not represent the policies or positionsn1 	     of the Mayo Foundation or its subsidiaries.73   Patrick Spinler			email:	Spinler.Patrick@Mayo.EDU '   Mayo Foundation			phone:	507/284-9485"   ------------------------------  $ Date: Fri, 6 Jul 2001 17:53:56 -0400) From: "Neil Rieck" <n.rieck@sympatico.ca>  Subject: Re: Telnet APIi: Message-ID: <poq17.28733$NY.2408663@news20.bellglobal.com>  F Which stack are you using? API's for TELNET and FTP are built into theC TCPware stack from Process Software (I use the TELNET library to dopK automated logins and screen scrapes of many other systems including various  flavors of UNIX).F www.process.comsC I am not aware of a similar offering in Compaq's TCPIP for OpenVMS.a  
 Neil Rieck Kitchener/Waterloo/Cambridge,p Ontario, Canada.! http://www3.sympatico.ca/n.rieck/   1 "john nixon" <jnixon@cfl.rr.com> wrote in message 9 news:8Nm17.179716$WB1.26118327@typhoon.tampabay.rr.com...ML > I probably don't have enough information or knowledge to properly ask this> > question, but I have been asked to find a TELNET API forVMS. >tI > Our programmers have been using a sort of home brewed port of something K > called PS LIB (presumably from a Berkley Unix implemenation).  It doesn'teJ > work very well on our VMS systems and is missing a lot of functionality. WeK > have customers that wish to use Telnet to talk to us, so we have a screen-J > scraper to decode what would be output to a standard VT100.  Things likeI > scroll buttons and certain interrupts cause us a lot of problems and wee getr= > a lot of access violations and terminal hangs and timeouts.o >tL > Does this make enough sense for somebody to recommend a product that I can > have them look at? >u	 > Thanks,  >      John  >b >o   ------------------------------  * Date: Fri, 6 Jul 2001 19:36:56 +0000 (UTC)/ From: Sander Vesik <sander@haldjas.folklore.ee>n" Subject: Re: The Alpha/IA64 Hybrid2 Message-ID: <994448218.294935@haldjas.folklore.ee>  3 In comp.arch Bill Todd <billtodd@foo.mv.com> wrote:t  < > "Jack Patteeuw" <jjpatteeuw@peoplepc.com> wrote in message( > news:3B43BF3C.705CD606@peoplepc.com...   > ...   L >> I can not imagine why any owner of a "group" of NFS mounted systems wouldL >> want to allow **SILENT** multiple write accesses to the same file !!!  ItK >> sends shudders down my spine knowing that what "Joe" just wrote, "Suzie"r > canrM >> overwrite in a blink, and with out file version numbering, there is no wayy0 >> that the original data can be save/recovered.  J > I must be missing something here:  VMS certainly allows concurrent writeL > (and over-write) access to files as well.  Versioning only comes into playK > when an application deliberately creates a new version of a file and thenkH > (typically, as with an editor) copies into that new version a modifiedN > version of the old version - and while it's likely that the old version willJ > stick around for a while, it's by no means guaranteed (since old-version2 > clean-up is a per-directory-settable parameter).  L > I liked versioning, but it never caught on with the rest of the world, and: > the rest of the world does manage to survive without it.  M Well, if (or rather, when) subversion finally is ready, it should be possible E to write a subversion client that was a filesystem. It would give younA versioning of things like symlinks and in-filesystem file moves. i  H The problem of 'how often do you commit changes' remains, though, and it9 would probably need a facility to 'tag' chages, though...w   [snip]   > - bill  " >   Could it be that penguin might$ >> get a smile like a Cheshire Cat ? >> >> >> Jack Patteeuw   --   	Sanderd   FLW: "I can banish that demon"   ------------------------------  $ Date: Fri, 6 Jul 2001 17:26:34 -0400' From: "Bill Todd" <billtodd@foo.mv.com>e" Subject: Re: The Alpha/IA64 Hybrid( Message-ID: <9i5a73$ch0$1@pyrite.mv.net>  < "Sander Vesik" <sander@haldjas.folklore.ee> wrote in message, news:994448218.294935@haldjas.folklore.ee...   ...   J > > I liked versioning, but it never caught on with the rest of the world, andh< > > the rest of the world does manage to survive without it. > F > Well, if (or rather, when) subversion finally is ready, it should be possibleG > to write a subversion client that was a filesystem. It would give youyB > versioning of things like symlinks and in-filesystem file moves.  G I've never heard of 'subversion', and somehow I suspect a Google searchm3 might not be very productive.  Could you elaborate?n   Thanks,b   - bill   ------------------------------  * Date: Fri, 6 Jul 2001 21:32:31 +0000 (UTC)/ From: Sander Vesik <sander@haldjas.folklore.ee>g" Subject: Re: The Alpha/IA64 Hybrid2 Message-ID: <994455155.152093@haldjas.folklore.ee>  3 In comp.arch Bill Todd <billtodd@foo.mv.com> wrote:s  > > "Sander Vesik" <sander@haldjas.folklore.ee> wrote in message. > news:994448218.294935@haldjas.folklore.ee...   > ...l  K >> > I liked versioning, but it never caught on with the rest of the world,e > ande= >> > the rest of the world does manage to survive without it.i >>G >> Well, if (or rather, when) subversion finally is ready, it should be6
 > possibleH >> to write a subversion client that was a filesystem. It would give youC >> versioning of things like symlinks and in-filesystem file moves.a  I > I've never heard of 'subversion', and somehow I suspect a Google searchl5 > might not be very productive.  Could you elaborate?a  I subversion.tigris.org is the (i believe official) hiomepage. It's basiclyeE a new take at CVS, except with full support for versioning filesystemaB operations and support for things like links (hard and soft), etc.  	 > Thanks,i   > - bill   -- w 	Sandere   FLW: "I can banish that demon"   ------------------------------  # Date: Fri, 06 Jul 2001 21:54:14 GMTw From: iddw@my-deja.com (Icarus)n" Subject: Re: The Alpha/IA64 Hybrid6 Message-ID: <3b46320f.627125598@pubnews.netcom.net.uk>  D On Fri, 6 Jul 2001 17:26:34 -0400, "Bill Todd" <billtodd@foo.mv.com> wrote: [...]lH >I've never heard of 'subversion', and somehow I suspect a Google search4 >might not be very productive.  Could you elaborate?  D You need to give Google more credit.  Searching for "subversion file! system" (without the quotes) gave   3    http://www.bootstrap.org/lists/ohs-dev/0572.htmld   as a first link, which led to        http://subversion.tigris.org/  5 I assume this was what was under discussion anyway...c   Regards,   Icarus -- -5 Experience is the name everyone gives their mistakes.e'                            -Oscar Wildei  @ A dream of competence, too closely confronted.  iddw@my-deja.com   ------------------------------  % Date: Fri, 06 Jul 2001 20:28:47 -0000 - From: wspencer@ap.nospam.org (Warren Spencer) : Subject: Re: The death of VMS has been greatly exaggerated/ Message-ID: <tkc7rv37r07v54@news.supernews.com>r  F ah13473_nospam@remove_this.sun.com (Andrew Harrison SUNUK Consultancy)2 wrote in <3B44C1F3.72185B4D@remove_this.sun.com>:   
 -- snip --  I >> - Alpha --> IA64-2 (or whatever the enhanced IA64 + Alpha architectureo
 >> is called)u >>   >p- >Requires a completely new os and ported appsb  F Huh?  I though we were porting OpenVMS -  a arguably smaller effort - I rather than creating "a completely new os".  I repectfully disagree with   the connotation here.o   ws   -- o   Warren Spencer Senior Software Engineer The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  # Date: Fri, 06 Jul 2001 21:39:41 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>: Subject: Re: The death of VMS has been greatly exaggerated: Message-ID: <xeq17.657$vb6.588549@typhoon.ne.mediaone.net>  : "Warren Spencer" <wspencer@ap.nospam.org> wrote in message) news:tkc7rv37r07v54@news.supernews.com...fH > ah13473_nospam@remove_this.sun.com (Andrew Harrison SUNUK Consultancy)3 > wrote in <3B44C1F3.72185B4D@remove_this.sun.com>:u >l > -- snip -- >UK > >> - Alpha --> IA64-2 (or whatever the enhanced IA64 + Alpha architecturem > >> is called)u > >> > >./ > >Requires a completely new os and ported apps  >kG > Huh?  I though we were porting OpenVMS -  a arguably smaller effort - J > rather than creating "a completely new os".  I repectfully disagree with > the connotation here.d >   I Gotta agree with you on that one. I understand that when the VAX to AlphaoH port was done, all the VMS device drivers and much of the OS itself wereH recoded in C, which should render this port less difficult than the last one.  I Apps? The only issue here is maintaining the existing ISV apps portfolio,nI and attracting new ISVs. Somehow I think this will be more difficult thany the actual OS port!s   ------------------------------  $ Date: Fri, 6 Jul 2001 18:20:49 -0400' From: "Bill Todd" <billtodd@foo.mv.com> : Subject: Re: The death of VMS has been greatly exaggerated( Message-ID: <9i5dcr$een$1@pyrite.mv.net>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagesF news:rdeininger-0607011032030001@user-2ivebcn.dialup.mindspring.com...L > In article <9i35rv$i9s$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> > wrote: > C > > "Robert Deininger" <rdeininger@mindspring.com> wrote in message:J > > news:rdeininger-0507012144140001@user-2ivea3q.dialup.mindspring.com...; > > > In article <3B451283.9682264D@videotron.ca>, JF Mezeia+ > > > <jfmezei.spamnot@videotron.ca> wrote:: > > >s > > >oL > > > > Consider the fud that customers have generated on their own. Imagine > > what6 > > > > Compaq's competitors will be able to generate. > > >2L > > > Actually, I doubt the highly-paid professionals can do better than you1 > > > have.  They'll be happy to tie your record.w > > K > > Au contraire:  the professionals won't be at all fettered by the truth,TF > > whereas we've been careful to stick to it (or as close to it as is possibleF > > to guess, given that Compaq has never been all that forthcoming in detailsn6 > > save for the ones that later turn out to be lies). >sL > Your posts usually have some facts in them to bolster your opinions.  JF's > rarely do.  I Thanks (I think...).  I agree that JF can get rather carried away (beyondtG any clearly-demonstrable foundation) in some of his pronouncements, buttK suggest that there's still likely to be a difference between what I believeaF are honestly-held fears on his part and the work of paid manipulators.  J Whether Andrew qualifies as a paid manipulator or just does it for the funL of it isn't clear, but I suspect he's in a somewhat difficult position rightI now (though it's not obvious how much he realizes it).  Making Alpha lookeL bad makes Compaq's decision look good, and vice versa - and which is more inL Sun's short-term interest (i.e., which will do more harm to short-term AlphaK sales) isn't at all clear, but my guess is that he'll try to stress Alpha'soK 'inadequacy' out of one side of his mouth and Compaq's duplicity out of thecJ other.  On the third hand, *any* attempt on his part to capitalize on thisG event could backfire:  people on both sides of the argument are alreadylK pretty pissed, and if I were Sun or IBM I'd be inclined to tread a bit more-L lightly and have competent sales and technical people visit Compaq customersJ stressing the virtues of their own products rather than explicitly runningH down Compaq's, leaving the more overt FUD to plants in the media and the analyst community.   - bill   >.: > You'll have to try harder if you want to catch up to JF. >e > -- > Robert Deininger > rdeininger@mindspring.comm   ------------------------------  # Date: Fri, 06 Jul 2001 22:15:50 GMT - From: goathunter@goatley.com (Hunter Goatley)e: Subject: Re: The death of VMS has been greatly exaggerated/ Message-ID: <3b463834.9185828@news.process.com>e  P On Fri, 06 Jul 2001 21:39:41 GMT, "Terry C. Shannon" <terryshannon@mediaone.net> wrote: >rJ >Gotta agree with you on that one. I understand that when the VAX to AlphaI >port was done, all the VMS device drivers and much of the OS itself werec >recoded in C,  J That's not true.  A few drivers, maybe, and some pieces of the OS, but the" majority is still BLISS and MACRO.  ; >which should render this port less difficult than the lasta >one.   F This should still be true, as the BLISS and MACRO-32 compilers now useG the GEM backend, same as any other compiler, so once a new GEM is done,a4 a lot of the port should be pretty straight-forward.   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/d9 goathunter@goatley.com     http://www.goatley.com/hunter/B   ------------------------------  # Date: Fri, 06 Jul 2001 22:49:25 GMTw= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)e: Subject: Re: The death of VMS has been greatly exaggerated0 Message-ID: <009FE9D4.D7BB65F8@SendSpamHere.ORG>  _ In article <3b463834.9185828@news.process.com>, goathunter@goatley.com (Hunter Goatley) writes:.Q >On Fri, 06 Jul 2001 21:39:41 GMT, "Terry C. Shannon" <terryshannon@mediaone.net>  >wrote:  >>K >>Gotta agree with you on that one. I understand that when the VAX to AlphalJ >>port was done, all the VMS device drivers and much of the OS itself were >>recoded in C,  > K >That's not true.  A few drivers, maybe, and some pieces of the OS, but the                           ^-- new # >majority is still BLISS and MACRO.i  I Recently, I was looking through the source listings to see if/where some sH mod_STD$routine was used.  Much to my chagrin, DEC created them but theyJ seldom use them.  Why?  Because so much of OpenVMS was ported with little H more than a compile.  In the Macro-32 case, the addition of .directives G to assist the compiler with knowledge it might no be able to gleen from " scanning and parsing the source.     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM-            rJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  % Date: Fri, 06 Jul 2001 21:49:52 -0400 2 From: rdeininger@mindspring.com (Robert Deininger): Subject: Re: The death of VMS has been greatly exaggeratedL Message-ID: <rdeininger-0607012149520001@user-2iveaga.dialup.mindspring.com>  J In article <9i5dcr$een$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> wrote:  L > Whether Andrew qualifies as a paid manipulator or just does it for the funN > of it isn't clear, but I suspect he's in a somewhat difficult position rightK > now (though it's not obvious how much he realizes it).  Making Alpha lookeN > bad makes Compaq's decision look good, and vice versa - and which is more inN > Sun's short-term interest (i.e., which will do more harm to short-term AlphaM > sales) isn't at all clear, but my guess is that he'll try to stress Alpha'saM > 'inadequacy' out of one side of his mouth and Compaq's duplicity out of thegL > other.  On the third hand, *any* attempt on his part to capitalize on thisI > event could backfire:  people on both sides of the argument are already M > pretty pissed, and if I were Sun or IBM I'd be inclined to tread a bit moretN > lightly and have competent sales and technical people visit Compaq customersL > stressing the virtues of their own products rather than explicitly runningJ > down Compaq's, leaving the more overt FUD to plants in the media and the > analyst community.    H I pretty much agree with this.  I'll add that any time a vendor finds itI easier to beat up someone else's product, rather than sing the virtues ofoG their own, they are in a somewhat weak position.  Such a strategy won'tpJ work against a competitor that has a) good products, and b) good marketing
 and outreach.-  I Or, putting it more bluntly:  Andrew would be invisible, if Compaq wasn'tr invisible first.   -- i Robert Deininger rdeininger@mindspring.comg   ------------------------------  % Date: Fri, 06 Jul 2001 20:48:15 -0500e1 From: "David J. Dachtera" <djesys.nospam@fsi.net>d: Subject: Re: The death of VMS has been greatly exaggerated' Message-ID: <3B466A5F.4BF73F96@fsi.net>r   "Terry C. Shannon" wrote:a > [snip]K > Apps? The only issue here is maintaining the existing ISV apps portfolio, K > and attracting new ISVs. Somehow I think this will be more difficult thanh > the actual OS port!n  H Very true! Without afordable hardware amd an affordable licensing scheme2 for end users, I don't see that happening. Period.   -- 5 David J. Dachtera- dba DJE Systems- http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.m   ------------------------------  % Date: Fri, 06 Jul 2001 21:53:10 -0400o2 From: rdeininger@mindspring.com (Robert Deininger): Subject: Re: The death of VMS has been greatly exaggeratedL Message-ID: <rdeininger-0607012153100001@user-2iveaga.dialup.mindspring.com>  O In article <009FE9D4.D7BB65F8@SendSpamHere.ORG>, system@SendSpamHere.ORG wrote:r  H > In article <3b463834.9185828@news.process.com>, goathunter@goatley.com (Hunter Goatley) writes:7 > >On Fri, 06 Jul 2001 21:39:41 GMT, "Terry C. Shannon"a <terryshannon@mediaone.net>b	 > >wrote:o > >>M > >>Gotta agree with you on that one. I understand that when the VAX to AlphasL > >>port was done, all the VMS device drivers and much of the OS itself were > >>recoded in C,o > >tM > >That's not true.  A few drivers, maybe, and some pieces of the OS, but the " >                         ^-- new % > >majority is still BLISS and MACRO.d > K > Recently, I was looking through the source listings to see if/where some iJ > mod_STD$routine was used.  Much to my chagrin, DEC created them but theyL > seldom use them.  Why?  Because so much of OpenVMS was ported with little J > more than a compile.  In the Macro-32 case, the addition of .directives I > to assist the compiler with knowledge it might no be able to gleen froml$ > scanning and parsing the source.    B I guess that's good and bad news.  If they could port once by justI compiling, they can almost certainly port the module the same way again. u. That's good, since it leads to a quicker port.  8 The bad part is that they missed a chance to upgrade theJ quality/maintainability of these modules, and will probably miss many such chances again this time.  H On the other hand, if it ain't broke, don't fix it still applies.  Every; time someone tweeks a module, there's a chance to break it.    -- a Robert Deininger rdeininger@mindspring.comn   ------------------------------  # Date: Sat, 07 Jul 2001 05:45:47 GMTi. From: "mulp" <michaelpettengill@earthlink.net>: Subject: Re: The death of VMS has been greatly exaggeratedD Message-ID: <fmx17.7103$G_1.714731@newsread2.prod.itd.earthlink.net>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4AD7EDA@kaoexc01.americas.cpqcorp.net...G > The OpenVMS Eng folks have a great deal of experience in dealing withfL > porting issues and mixed cluster support, so I am confident that with themJ > working closely with the Alpha EV8 team that is going to work with Intel onL > improving the Itanium architecture, any technical issues will be resolved.  L A few have, but it is increasingly a matter of HAD.  A significant amount ofI the critical software does not come from the VMS engineering group itselfuG but from the wider DEC engineering organization that was developing VMSoF products and tools.  Massive parts of that organization are long gone.  H For example, I don't think that any of the people involved with vest areE still around.  A lot of the product management folk who worked issueslE related to figuring out which products actually exist and are used by:F customers to figuring out the 2-5-2 number that needs to go on the SSB submit form are long gone.  I Its quite a leap to go from making the mundane stuff happen to having thedD VMS engineers work with engineers designing a new generation if IA64L processor to be released maybe a decade out, given Intel's delivery history.   ------------------------------  # Date: Sat, 07 Jul 2001 05:53:13 GMTe. From: "mulp" <michaelpettengill@earthlink.net>: Subject: Re: The death of VMS has been greatly exaggerated> Message-ID: <dtx17.2$qa6.981@newsread1.prod.itd.earthlink.net>  : "Warren Spencer" <wspencer@ap.nospam.org> wrote in message) news:tkc7rv37r07v54@news.supernews.com...l  G > Huh?  I though we were porting OpenVMS -  a arguably smaller effort - J > rather than creating "a completely new os".  I repectfully disagree with > the connotation here.   = If it is an effort to port the OS, then the effort is doomed.0  K What the effort needs to be is to migrate all the applications currently incL use on VAX and Alpha to IA64 AND migrate all the ISVs and all their products AND migrate all the customers.  L If you do the first two, but don't migrate the customers, then the effort is wasted.a  K If you do the first, but not the second, then there is no way that customerr will be able to migrate.  I Success depends on reaching 300%  where the port of the OS is achieved toaK 100% level, migration of products and ISVs is done to 100%, and 100% of thenD customer are migrated, or at least have no impediments to migrating.  L Growth will occur only when the total hits 400% - a 100% effort to grow VMS.H The recent "auccessful" efforts in this are are at about the 10% level -G just buy a VMS product manager a couple of drinks and ask for an honestC assessment.o   ------------------------------  % Date: Fri, 06 Jul 2001 21:17:00 +0100 + From: "antonio.carlini" <arcarlini@iee.org> % Subject: Re: VAX 4000-106 qbus pinoutr' Message-ID: <3B461CBC.F1BC20BA@iee.org>(   mulp wrote:  > 9 > "Dave McDonald" <browser@acenet.co.za> wrote in message ) > news:9hrjj3$85c$1@ctb-nnrp1.saix.net...-A > > This may not be the ideal group, but there's no hardware.vax.a > >(J > > I'm looking for the pinout of the Qbus expansion connectors on the VAX > 4000 > > 105 and 106. > C > I noticed VAX hardware microfiche listed on ebay - search for vaxr  3 I've looked in a couple of the VAX 4000-10x manualsm6 (a Customer Technical Info, a System Maintenance Guide- and one other tech one whose title escapes mee& right now) without finding the pinout.  , Always worth picking up fiche though (except- in this case I suspec that these machines are5  far too new to be on any fiche).   Antonio    -- :   ---------------.- Antonio Carlini             arcarlini@iee.orgs   ------------------------------  % Date: Fri, 06 Jul 2001 14:28:47 -0500 * From: WILLIAM WEBB <WWEBB1@email.usps.gov>E Subject: RE: VMS software/documentation product library (aka con dist - Message-ID: <0033000028513981000002L012*@MHS>-   =0AMicrofortnightly.  : (Sound of deluge of CDs clattering on floor in background)   WWWebb   > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET5& > Sent: Friday, July 06, 2001 12:08 PMF > To: Webb, William W - Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNETH > Subject: RE: VMS software/documentation product library (aka con dist=   >  >tF > We got June in the same boxes as 7.3. Alpha came first and then VAX. >q >e> > "Dave Gudewicz" <david.gudewicz@abbott.com> wrote in message4 > news:9i4m62$p7b$1@fizban.fizban.pprd.abbott.com...6 > > Anyone here receive the June 2001 VMS software and > documentation CDs? > >tH > > My last was March 2001.  Did the distribution frequency change from=   > > quarterly? > >M > > Dave...e > >  > >s >=   ------------------------------  % Date: Fri, 06 Jul 2001 14:20:23 -0400-+ From: "O'Connor, Marty" <MOConnor@DVFS.COM> H Subject: RE: VMS software/documentation product library (aka con dist) ?F Message-ID: <85C741006DA1D0119CE00000F8752CE305004188@msexc1.dvfs.com>  & I received mine for both Alpha and VAX   Martye  8 From: 	Dave Gudewicz [mailto:david.gudewicz@abbott.com]   E Anyone here receive the June 2001 VMS software and documentation CDs?o  C My last was March 2001.  Did the distribution frequency change from>
 quarterly?   Dave...U   ------------------------------  $ Date: Fri, 6 Jul 2001 15:17:31 -0400. From: "Kenneth Randell" <kenr@datametrics.com>H Subject: Re: VMS software/documentation product library (aka con dist) ?+ Message-ID: <9i52rk$bhe$1@bob.news.rcn.net>a  J I received the ALPHA SPL about 3 weeks ago.  The VAX SPL came about 1 week ago.   Ken Randell   : Dave Gudewicz <david.gudewicz@abbott.com> wrote in message2 news:9i4m62$p7b$1@fizban.fizban.pprd.abbott.com...G > Anyone here receive the June 2001 VMS software and documentation CDs?  >sE > My last was March 2001.  Did the distribution frequency change froms > quarterly? >e	 > Dave...  >s >r   ------------------------------  # Date: Sat, 07 Jul 2001 01:57:37 GMTi$ From: Scott Vieth <svieth@wi.rr.com>H Subject: Re: VMS software/documentation product library (aka con dist) ?) Message-ID: <3B466D29.9AE47C54@wi.rr.com>c   Dave:e   I'm pretty sure I got mine.e  = Maybe your copy got misplaced in the Abbott mail system?  ;^)e   -Scott in Milwaukee :^)r   Dave Gudewicz wrote:  G > Anyone here receive the June 2001 VMS software and documentation CDs?  >nE > My last was March 2001.  Did the distribution frequency change from> > quarterly? > 	 > Dave...e   ------------------------------  % Date: Fri, 06 Jul 2001 18:41:08 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>.4 Subject: Re: Why Compaq won't succeed on IA64 either, Message-ID: <3B463E70.83FDC0DE@videotron.ca>   Bill Todd wrote:H > That's the kind of internal idiocy I was talking about.  While advanceF > knowledge of pending screw-ups would certainly be of interest to theK > customer base, Terry was suggesting the Compaq might know something aboutoM > the real, outside world that we didn't - whereas all evidence suggests that : > Compaq wouldn't recognize reality if it tripped over it.  N You are assuming that Compaq's decisions are stupid. I think not. I think thatM Compaq actually does have  serious roadmap of where it wants to go. It took anJ while for Compaq to figure out a way to get from where it was, loaded withL Tandem and Digital stuff as well as its core wintel to where it wants to go.  I VMS loyalists may not like what Compaq is doing, but it doesn't mean thata Compaq is stupid.l  M Look at Alpha. Sure, Compaq *COULD* have made that into the de-facto standardtJ had it *wanted* to. But it doesn't want to get into the chip business. AndJ look at it this way: with the big wad of cash they are getting from Intel,K Compaq can finally start to move in a direction where it wants to go. And IaN suspect that from an investment point of view, the solutions/support companies4 Compaq will buy may yield better results than Alpha.  N I get the imporession that the Pfeiffer acquisitions (Tandem/Digital) were theK right "reason" but the wrong buys. Compaq does want to become an enterprise J company, but it wants to do so in a field that doesn't include proprietaryN obscure operating systems, it wants to be the leader in implementing wintel at the enterprise level.n  J From a growth perspective, when you have massive microsoft marketing moneyM shoving WINTEL crap up enterprises and attacking high end systems with wintelnM crap, the growth potential is FAR greater than trying to maintain a small VMSaS customer base and fighting against microsoft's advances into the enterprise market.t  I And enterprise level wintel crap is in fact profitable. It is the desktopo which is not profitable.  G I think that it is time to face the fact. VMS is actually controlled bywC Microsoft and it ain't going nowhere. Not killing a product doesn'tn6 automatically make it a success or grow significantly.   ------------------------------  $ Date: Sat, 7 Jul 2001 01:03:26 -0400' From: "Bill Todd" <billtodd@foo.mv.com>e4 Subject: Re: Why Compaq won't succeed on IA64 either( Message-ID: <9i64vo$sf2$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B463E70.83FDC0DE@videotron.ca...   ...I  K > You are assuming that Compaq's decisions are stupid. I think not. I thinke thatE > Compaq actually does have  serious roadmap of where it wants to go.   I Being moronic and following a roadmap aren't incompatible:  it just meansn the roadmap is moronic.   
  It took aL > while for Compaq to figure out a way to get from where it was, loaded withJ > Tandem and Digital stuff as well as its core wintel to where it wants to go., > K > VMS loyalists may not like what Compaq is doing, but it doesn't mean that. > Compaq is stupid.u  E Certainly not.  What makes Compaq stupid is throwing away potentiallylI profitable opportunities/differentiators that it already owns, not simply-J doing things VMS people don't like.  Well, that plus actively alienating a very profitable customer base.   >:F > Look at Alpha. Sure, Compaq *COULD* have made that into the de-facto standardH > had it *wanted* to. But it doesn't want to get into the chip business.  L And it (or rather DEC) even figured out a half-reasonable way to avoid beingJ in the chip business, by out-sourcing the fabbing.  That may actually haveK been a pretty good way to hedge its bets without throwing the baby out withd- the bath water - but now the baby's gone too.     AndL > look at it this way: with the big wad of cash they are getting from Intel,G > Compaq can finally start to move in a direction where it wants to go.   K Unfortunately, Compaq shows no sign now of knowing any better what it wantsgK to be when it grows up than when it acquired DEC.  Perhaps signs of knowingcL even less, in fact:  Pfeiffer at least seemed to have some kind of vision ofL what he wanted to do, whereas the current management seems mostly just to beK flailing around trying to find something - anything - that they won't screwg up.f    And IF > suspect that from an investment point of view, the solutions/support	 companies-6 > Compaq will buy may yield better results than Alpha.  L Except for Tandem (which Compaq seems to have had the sense largely to leaveH alone), Compaq seems to have the proverbial black thumb when it comes toE cultivating acquisitions:  why should the next ones be any different?m   >iL > I get the imporession that the Pfeiffer acquisitions (Tandem/Digital) were thee$ > right "reason" but the wrong buys.  K I suspect that they may have been the right buys for Pfeiffer's vision, buteK that the BoD at the time didn't have the patience (especially given the hitnJ Compaq's PC divisions were taking right then from Dell) to let that vision develop.  )  Compaq does want to become an enterpriseoL > company, but it wants to do so in a field that doesn't include proprietaryF > obscure operating systems, it wants to be the leader in implementing	 wintel ats > the enterprise level.e  F Being a leader at *anything* seems to require far more competence thanA Compaq has.  And in the particular area of any kind of enterpriseaG leadership, it would have to shoulder aside IBM - which is anything butoK incompetent in that arena and actively leverages its entire product line tooL differentiate itself from 'integrators' with nothing special of their own to offer.   >yL > From a growth perspective, when you have massive microsoft marketing moneyH > shoving WINTEL crap up enterprises and attacking high end systems with wintelK > crap, the growth potential is FAR greater than trying to maintain a smallC VMS'B > customer base and fighting against microsoft's advances into the enterprise market.  L Small problem:  first, you have to convince customers that they should trustB you not to screw up their businesses as much as you have your own.  = Second point:  there's nothing incompatible with growing yourgJ Alpha/VMS/Tru64 customer base (and NSK) on the one hand while you grab forJ that purported Wintel gusto with the other.  Unless you're Compaq.  And itB hedges your bets just in case the imminent Wintel take-over of theK enterprise is just as much an illusion as it was back when DEC made exactly, the same mistake.1  H IBM has it right:  they'll help you understand what you need, sell it toF you, and make it work for you.  Compaq will tell you you need a Wintel; solution, sell it to you, and promise you it'll work great.s   - bill   ------------------------------  # Date: Fri, 06 Jul 2001 18:58:08 GMTcB From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>2 Subject: Re: Writing to OPA0: from a device driver6 Message-ID: <4Tn17.9852$Kf3.112325@www.newsranger.com>  , On Thu, 05 Jul 2001 14:19:11 GMT, in articleJ <009FE8C4.65AA3B66@SendSpamHere.ORG>, Brian Schenkenberger, VAXman- wrote: >fd >In article <ELRXNPvGNNjJ@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:| >>In article <s4I07.7053$Kf3.69664@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes: >>> R >>> What are the various methods used by VMS device drivers to write (for example,M >>> debugging text) to the system console and which method do people prefer ?1 >>H >>Generally they don't.  It's somewhat difficult in any device driver to: >>write to any device other than the one being controlled. >>B >>I've got device drivers that use the OPCOM mailbox, they haven'tI >>successfully sent out a message in years.  I haven't bothered debuggingo: >>this because the messages they did send out are useless. >>N >I use IOC$BROADCAST and/or IOC$CONBRDCST extensively for outputting messages.N >You need to observe IPL requirements so you might not be able to invoke theseM >routinese everywhere you might wish.  In general, you can use these as you'dw >like at fork IPL. >   J Thanks to everyone for their responses, especially Hunter's (which has not? turned up at Newsranger, but I got it ok on my local newsfeed).    Simon.  F PS: As a matter of interest, how would have I gone about finding theseM routines and structures, other than looking through the VMS source listings ? M Or is it expected that if you do this kind of thing that you will have a copye of the listings available ?    --  ; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPnK Worrying idea #101: What if Microsoft goes into the Ada compiler business ?t   ------------------------------  # Date: Fri, 06 Jul 2001 21:31:39 GMTe- From: goathunter@goatley.com (Hunter Goatley) 2 Subject: Re: Writing to OPA0: from a device driver/ Message-ID: <3b462d1a.6344122@news.process.com>g  / On Fri, 06 Jul 2001 18:58:08 GMT, Simon Clubleyr5 <simon_clubley@remove_me.excite.com-Earth.UFP> wrote:aG >PS: As a matter of interest, how would have I gone about finding thesemN >routines and structures, other than looking through the VMS source listings ?N >Or is it expected that if you do this kind of thing that you will have a copy >of the listings available ? >iH When I first started, I didn't have access to the source listings or theK I&DS book.  SDA was my best friend.  I learned about a lot of things simplyeH by looking at the symbols defined in SDA, using EXAM/INST to look at theF system code to try to figure out what it was doing, etc.  I also spent? a lot of time looking at examples found on the DECUS SIG tapes.4  J The main reason Ed & I wrote our series for DSJ was to provide informationH that isn't readily documented or easily found.  Unfortunately, a plannedG book never materialized, thanks to some bad promises we'd received froml; Digital Press, and so the articles are no longer available.n  I Technically, they're owned by Cardinal Business Media, but they no longer.H exist, and my last efforts to track down somebody who could authorize meG to post them on a web site failed.  If there's interest, I may just putpE them up until someone from CBM asks me to take them down, which wouldl probably never happen.   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/d9 goathunter@goatley.com     http://www.goatley.com/hunter/t   ------------------------------  % Date: Fri, 06 Jul 2001 23:19:24 +0100e+ From: "antonio.carlini" <arcarlini@iee.org>s2 Subject: Re: Writing to OPA0: from a device driver' Message-ID: <3B46396C.B975A457@iee.org>u   Simon Clubley wrote:H > PS: As a matter of interest, how would have I gone about finding theseO > routines and structures, other than looking through the VMS source listings ?sO > Or is it expected that if you do this kind of thing that you will have a copy- > of the listings available ?   . Most "standard driver things" you can do just - by using the docs. Once you step beyond that,d) you really do need the listings. In fact,e* even if you don't step beyond the contents. of the manuals, you'll often need the listings# to get very far with the occasionalt crash dumps :-)   ( The I&DSM is very useful too and I would* also recommend the Hanrahan and Leahy book (at least for VAX).    Antonio    -- e   ---------------c- Antonio Carlini             arcarlini@iee.org    ------------------------------   End of INFO-VAX 2001.373 ************************