1 INFO-VAX	Tue, 04 Dec 2001	Volume 2001 : Issue 673       Contents:P Another Webcast -configuration concerns and rules regarding combining EV67 and EP Re: Another Webcast -configuration concerns and rules regarding combining EV67 aP Re: Are multiple disks with same label okay if privately mounted       /overrideP Re: Are multiple disks with same label okay if privately mounted       /override+ Re: AS4100 for VMS Hobbyist in Chicago area  Re: DEC is DEAD  RE: DEC is DEAD  Re: DEC is DEAD  Re: ftp performance  Re: Future of VMS ? / Help needed: FTP Server & PASV connection ports 3 Re: Help needed: FTP Server & PASV connection ports 3 Re: Help needed: FTP Server & PASV connection ports < Re: Hidden accounting: was Re: No surprise about Tru64 death< Re: Hidden accounting: was Re: No surprise about Tru64 death< Re: Hidden accounting: was Re: No surprise about Tru64 death< Re: Hidden accounting: was Re: No surprise about Tru64 death< Re: Hidden accounting: was Re: No surprise about Tru64 death< Re: Hidden accounting: was Re: No surprise about Tru64 death Re: IEQ11 Driver VMS, Re: Installing Icon permanently to CDE menu?' Re: Is it a DEC C problem, or is it me?  Letter from Michael D. Capellas # Re: Letter from Michael D. Capellas # Re: Letter from Michael D. Capellas # Re: Letter from Michael D. Capellas 
 Memory Search 9 Re: Microsoft Pyramid Collapses Enron and Hewlett Packard ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death  Oracle problems. Re: Oracle problems. Re: Oracle problems.P Re: Q: Tool or script to remove nonprinting characters from a SET HOST log? log? Re: RECALL does not work RL02 disk drive ? Re: SKC Musings on "Recent IPF Unpleasantness" at www.tru64.org . Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues) Re: The real story about Alpha's death ?? E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))   Re: tubes (was: RE: DEC is DEAD)  Re: tubes (was: RE: DEC is DEAD)  Re: tubes (was: RE: DEC is DEAD) Webmail Server Re: Webmail Server Re: Webmail Server Re: Webmail Server  F ----------------------------------------------------------------------  $ Date: Mon, 3 Dec 2001 15:48:43 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>Y Subject: Another Webcast -configuration concerns and rules regarding combining EV67 and E 0 Message-ID: <sxRO7.86$BK1.2461@news.cpqcorp.net>  L I just got notified of this web cast by one of my friends and he gave me the< approval to post this externally so you can call in as well.  # If you are interest please sign up.   
 Warm regards,    sue   L ____________________________________________________________________________ __________________________   .Sue,   L You can send this to anyone internal that may be interested. There is no NDAB needed for the webcast. Anyone that can register i.e. partners at:C http://www.presentationselect.com/compaq/compaq.asp can attend. The I presentation is being conducted this way so as to make it available to as  wide an audience as possible.   - Many thanks for getting the word out on this.    John  	 Good day,   ? There will be a webcast on December 13, 2001 that discusses the J configuration concerns and rules regarding combining EV67 and EV68 CPUs inJ the GS320/160/80 series AlphaServer systems. The HPS AlphaServer TechnicalL Training organization taped my presentation of the updated material and willF archive it in case you are unable to attend the December 13 broadcast.G Although I am a rookie with these webcast tapings, the content is still I worth viewing and much of the material was taken from what we have on our  TECHPort website.   H Please visit TECHPort, http://techport.tay.cpqcorp.net/, for information, regarding the broadcast and how to register.  J The following url will direct you to the section on TECHPort with the EV68K Zip file that contains additional support material. I will be updating this L file shortly with material that was not available at the time of the taping.  L http://techport.tay.cpqcorp.net/dec/nav/hwalphaservergs160configuration.htm  - The file is titled:   I Visual Configuration Aids and Rules for Combining EV67 (731 MHz) and EV68 J (1001 MHz) in a System 10/18/01 Content provided by Enterprise Server Team  L The webcast and the material on our TECHPort website will provide you with aJ good overview and refresher concerning combining EV67 and EV68 in the sameB system or when upgrading an EV67 based system to one that is EV68.   fyi,   John   ------------------------------  % Date: Tue, 04 Dec 2001 07:08:57 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch> Y Subject: Re: Another Webcast -configuration concerns and rules regarding combining EV67 a 5 Message-ID: <3C0C6879.32D89C9C@swissonline.delete.ch>    Sue,  F I can't speak for everyone but this message appeared just fine, single spaced and wrapped just nicely.   H thanks for whatever you did ...  or maybe no thanks for whatever you did on the previous ;-)      John       Sue Skonetski wrote: > N > I just got notified of this web cast by one of my friends and he gave me the> > approval to post this externally so you can call in as well. > % > If you are interest please sign up.  >  > Warm regards,  >  > sue  >    ... snipped    ------------------------------  $ Date: Mon, 3 Dec 2001 15:50:58 -0500  From: norm.raphael@jamesbury.comY Subject: Re: Are multiple disks with same label okay if privately mounted       /override 4 Message-ID: <C2256B17.00723D84.00@jklh21.valmet.com>  A First of all, to create the BACKUP/IMAGE, the target disk must be B Mounted "/FOREIGN" and so using it does not involve standard label processing.   C You would need to dismount/remount it after the backup completes to  do something else.  B Then, you can have one disk mounted public "/SYSTEM" or "/CLUSTER"B and another one mounted process-private, both with the same label.  = You can also, of course, change a disk's label after mount by  SET VOLUME/LABEL=newlabel ddcu:   ? In order to accomplish your task, this technique may be of use.         0 SPAMSINK2001@yahoo.com on 12/03/2001 01:44:44 PM  ( Please respond to SPAMSINK2001@yahoo.com   To:   Info-VAX@mvb.saic.com  cc: > Subject:  Are multiple disks with same label okay if privately       mounted/override=id?         Hello,  C I know from the manuals that one must have unique labels within any F domain (system, group, private). But can one use /OVERRIDE=ID to mount> more than one disk with the same label privately from the same process?   Example:  B I create and populate an LD disk, then copy the contents to CD via- CDRECORD. Then I want to do a BACKUP/COMPARE.    $ MOUNT LDA1: /OVERRIDE=ID+ $ MOUNT DKA0: /OVERRIDE=ID  !(cd-ROM DRIVE) " $ BACKUP/IMAGE/COMPARE DKA0: LDA1:  B Now, if I do this, both disks are mounted with the same label. CanD this cause a problem (with locks or something else?) or is it betterF for me to change the label on LDA1 before re-mounting it? I understandC that this at least causes DISK$label to be superseded by the second D mount, which is not a problem for me. Is this a concern perhaps only for shareably mounted drives?    TIA.   Disclaimer: JMHO Alan E. Feldman  afeldman & gfigroup.com    ------------------------------  # Date: Mon, 03 Dec 2001 21:32:28 GMT 8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)Y Subject: Re: Are multiple disks with same label okay if privately mounted       /override 0 Message-ID: <MbSO7.87$BK1.2486@news.cpqcorp.net>  5 In article <C2256B17.00723D84.00@jklh21.valmet.com>,  " norm.raphael@jamesbury.com writes: ..C >   ...you can have one disk mounted public "/SYSTEM" or "/CLUSTER" C >and another one mounted process-private, both with the same label.  > > >You can also, of course, change a disk's label after mount by  >SET VOLUME/LABEL=newlabel ddcu: ..   (Hi, Norm.)   C There are many things in OpenVMS that one "can" do, but should not. 6 This is one that should be avoided if at all possible.  B This particular thing has caused me and others problems when usingA the POLYCENTER Software Installation (PCSI) utility.  It is UGLY, , and the cause of the problem is not obvious.  K Other software that used DISK$... logical names will have similar problems.   M Another thing to be aware of is that when you SET VOLUME/LABEL=newlabel ddcu: K the logical name DISK$newlabel does NOT get into the data structures in the K same way as it does when you MOUNT a disk labled newlabel.  This has caused L me (and others!) problems too.  I regard it as good practice to dismount and* remount a disk after changing the label.    I SOoo...  I would first change the label and then dismount and remount one ; of the disks, then mount the other disk and do the compare.   G Opinions will vary, and one can "probably" get away without doing this, & but it is soooooo simple to be 'safe'!   --  K     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  % Date: Mon, 03 Dec 2001 13:45:12 -0600 . From: Duncan Brown <brown_du@eisner.decus.org>4 Subject: Re: AS4100 for VMS Hobbyist in Chicago area0 Message-ID: <3C0BD648.C9D645D8@eisner.decus.org>   Dave Gudewicz wrote: > F > There is an Encomapss (DECUS) meeting in Chicagoland this Wednesday,
 > 12/5/01. > I > See //eisner.decus.org/lugs/carts/  for more details about the meeting.  > L > I'll make a note of this and mention it at the meeting.  Of course, you're= > welcome to come to the meeting and mention this personally.   G I'll be the guy in the pickup truck with the AS4100 in the back and the < "Will trade Alpha for food" sign on the side, heh heh heh...  A Sadly, I'm busy Wednesday - going to see the Radio City Rockettes  Christmas spectacular!   Duncan   ------------------------------  # Date: Tue, 04 Dec 2001 04:48:54 GMT " From: Art Rice <arice@myhouse.org> Subject: Re: DEC is DEAD9 Message-ID: <WAYO7.1133$kT5.230506@dfiatx1-snr1.gtei.net>    Bill Gunshannon wrote:  8 > In article <BlMO7.27$y4.15015@paloalto-snr1.gtei.net>,' >  Art Rice <arice@myhouse.org> writes:  > |> Antonio wrote:  > |>  I > |> > I remember the days when transistors started to replace the vacuum K > |> > tube, and you guessed it, there were people that beleived it was all , > |> > things evil. How time repeats itself. > |>  G > |> And there are still ligimate uses for vacuum tubes (valves) today.  > |>   > G > Most (probably more than 99%) of televisions still have at least one. J > As do a very high percentage of computers for the very same reason.  :-) >  > bill > K Oh, as in CRT?  He he :>)   I was also thinking about other applications.   K Just ask any guitarist about the warmth (no pun intended) of a tube driven  ? amp.  And, the natural distortion is also difficult to imitate.  --   Art Rice, Tandem Admin Special Data Processing Corp ----------------------------L All opinions are my own and do not reflect the views of the above mentioned 	 employer.    ------------------------------  # Date: Tue, 04 Dec 2001 04:55:36 GMT " From: Art Rice <arice@myhouse.org> Subject: RE: DEC is DEAD9 Message-ID: <cHYO7.1149$kT5.234315@dfiatx1-snr1.gtei.net>    WILLIAM WEBB wrote:    > 9 > Perhaps he just did this to make Andrew look reasonable  > in comparison. >  > WWWebb  K I do hope you were speaking of Antonio.  And where is our Solaris spouting   Andrew these days?   >  > -----Original Message-----1 > From: Info-VAX-Request@Mvb.Saic.Com at INTERNET * > Sent: Monday, December 03, 2001 10:18 AMD > To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET > Subject: RE: DEC is DEAD >  >  > Antonio wrote: >  >> Greetings from Antonio, >>L >> I hope I am not coming across as rude, but you guys seem to attach to allL >> things DEC like a baby to its mother. I'm not here to argue the merits or# >> lack thereof of Dec, but really?  >>H >> Reading the posts in this newsgroup is like getting trapped in a time8 >> warp. I can't beleive you guys are still talking Dec! >>G >> You people need to stop clinging to old technology like its the only 5 >> thing you know. The whole world has passed you by.  >>K >> I cut my teeth on Dec stuff, been around it for years - it used to be my I >> bread and butter. But I moved on, I adapted to new technology and went L >> with the flow - for better or worse. I left the past in the past. No good >> looking back you know.... >>I >> Face the facts - Dec is dead and has been for a long time now, but you " >> guys just can't seem to let go. >>K >> I remember the days when transistors started to replace the vacuum tube, H >> and you guessed it, there were people that beleived it was all things! >> evil. How time repeats itself.  > D > And there are still ligimate uses for vacuum tubes (valves) today. >  >  >>   --   Art Rice, Tandem Admin Special Data Processing Corp ----------------------------L All opinions are my own and do not reflect the views of the above mentioned 	 employer.    ------------------------------  # Date: Tue, 04 Dec 2001 05:23:38 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>  Subject: Re: DEC is DEAD/ Message-ID: <3C0C5D0E.3FF5AEF1@cableinet.co.uk>    Art Rice wrote:    K > Oh, as in CRT?  He he :>)   I was also thinking about other applications. L > Just ask any guitarist about the warmth (no pun intended) of a tube drivenA > amp.  And, the natural distortion is also difficult to imitate.    ( Hmmm, did you surf to www.line6.com yet?  L OK, its not QUITE like having a real valve power amp moving air, but you canO do it any time of day without annoying the neighbours or moving to an extermely S remote and lonely location. There is even software to emulate expensive microphones  these days.   P Now, I might just try hooking the POD up to the stereo one day, as David hinted. --   Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.    ------------------------------   Date: 4 Dec 2001 03:56:00 GMT - From: Joe Heimann <heimann@nog.ecs.umass.edu>  Subject: Re: ftp performance, Message-ID: <9uhhgg$4d6$1@odo.ecs.umass.edu>  3 Chris Sharman <chris.sharman@ccagroup.co.uk> wrote:  > Oh mumble.L > The Mac (100Mb card, connected to 100Mb switch) has negotiated itself down
 > to 10Mb.   > Sorry, > Chris   H Apple has an "unsupported" utility to set its 10/100 ethernet interfacesJ to set speeds and duplex status.  It is available as a download from theirH support site.  I don't have the URL, since I have never needed it.  ThatE may take care of the Mac server not negotiating the correct speed and & duplex settings using autonegotiation.   Joe Heimann    heimann@ecs.umass.edu    (rest snipped)   ------------------------------  # Date: Tue, 04 Dec 2001 03:55:30 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: Future of VMS ?' Message-ID: <3C0C4946.9CD7C0DA@fsi.net>    BERTRAND Jol wrote: > $ > Le Fri, 30 Nov 2001 11:18:46 -0500: > Fred Kleinsorge <kleinsorge@star.zko.dec.com> crivait :% > >BERTRAND Jol wrote in message ... ! > >>Le 30 Nov 2001 08:29:26 -0600 6 > >>Bob Koehler <koehler@encompasserve.org> crivait :; > >>>In article <slrna0btrj.c5o.bertrand@perceval.cnam.fr>, G > >bertrand@perceval.cnam.fr (BERTRAND =?iso-8859-1?Q?Jo=EBl?=) writes:  > >>>>L > >>>>         Don't forget that OpenVMS is only avalaible on VAX and APX. I
 > >believeC > >>>> that this system can be more used if it is avalaible on more  > >architecture.N > >>>> Thus, I have restarted the old FreeVMS project. First, I was alone, butM > >>>> we are currenty about 30. We are working on kernel, libraries and DCL, 9 > >>>> and we have a SRM-like console which runs on i386.  > >>>> > >>> H > >>>   The page says the kernel is Posix, and FreeVMS is that plus DCL.8 > >>>   If that's really all you're doing, it ain't VMS. > >>@ > >> It's a starting point. We need more contributers to write aF > >>real OS which can works on several architectures. Any help will be > >>welcome. > >> > >  > >sM > >IMHO - a "freeVMS" project would do well to use a widely available kernel,iF > >such as Linux.  While replicating the VMS API's, utilities and userL > >interface.  Providing source level compatability for "many" applications.J > >This ignores, of course, issues like availability of languages like DEC8 > >Fortran, BLISS, and anything with old DEC-extensions. > > N > >Yes, it's not "VMS", but writing true OS support for multiple platforms andL > >architectures is a great deal of very technical work... and not something6 > >that really lends itself to part time contribution. > M >         I have released the 0.0.1a kernel the last friday and it runs on my I > laptop for 2 days without any trouble. We work on memory management andn? > we need some VMS expert which know VMS and i386 assembler ;-)   > I find it interesting and refreshing that, in spite of all the3 nay-sayers, Joel is going boldly forward with this.m  D Guess I'll have to get up to speed on C so I can help him out. Maybe= pick up a little 386 ASM and OS theory along the way, also....   -- - David J. Dachtera- dba DJE Systemso http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/o   ------------------------------  # Date: Mon, 03 Dec 2001 19:46:10 GMTu  From: adroso@home.com (VLC User)8 Subject: Help needed: FTP Server & PASV connection ports9 Message-ID: <3c0bc8ca.33184302@news.jamison1.pa.home.com>g  F I'm not a super-experienced VMS person, so if I sound stupid please be
 gentle ...  E I have a VAXstation 4000 VLC (VMS 7.2) and I'm running the FTP Serveri> that's found in the DIGITAL TCP/IP Services for OpenVMS SERVER= Components menu in the TCPIP$CONFIG command procedure.  I can D successfully connect to and transfer files with the VLC's FTP Server within my LAN.  E I'm also running a Serv-U FTP Server (on port 22) on a Win98SE PC and-C I had to set up my router to forward a range of additional ports torB Serv-U for PASV connections for external users since it's behind aB firewall.  Most importantly, I had to modify Serv-U to select fromE this specific range of ports rather than just selecting one randomly,R% as well as specifying the Passive IP.A  B I assume I have to do the same for the FTP Server on my VLC, but ID can't find anything about specifying a range of additional ports forF PASV connections or Passive IPs for external users.  Can this be done,F and if so, how?  Hopefully, everything I said makes sense ... sorry if it doesn't.t   ------------------------------  # Date: Mon, 03 Dec 2001 21:52:35 GMTh4 From: "Matt Muggeridge" <Matt.Muggeridge@compaq.com>< Subject: Re: Help needed: FTP Server & PASV connection portsA Message-ID: <DuSO7.410213$bY5.1729158@news-server.bigpond.net.au>s  D FTP PASV mode is supported in TCP./IP V5.1.  At the FTP prompt type:       FTP> HELP SET PASSIVEt  F If you are unsure about the version of TCP/IP you have installed, use:       $ TCPIP SHOW VER   Matt.     - "VLC User" <adroso@home.com> wrote in messagew3 news:3c0bc8ca.33184302@news.jamison1.pa.home.com... H > I'm not a super-experienced VMS person, so if I sound stupid please be > gentle ... >mG > I have a VAXstation 4000 VLC (VMS 7.2) and I'm running the FTP ServerY@ > that's found in the DIGITAL TCP/IP Services for OpenVMS SERVER? > Components menu in the TCPIP$CONFIG command procedure.  I can F > successfully connect to and transfer files with the VLC's FTP Server > within my LAN. > G > I'm also running a Serv-U FTP Server (on port 22) on a Win98SE PC and-E > I had to set up my router to forward a range of additional ports toeD > Serv-U for PASV connections for external users since it's behind aD > firewall.  Most importantly, I had to modify Serv-U to select fromG > this specific range of ports rather than just selecting one randomly,c' > as well as specifying the Passive IP.  >aD > I assume I have to do the same for the FTP Server on my VLC, but IF > can't find anything about specifying a range of additional ports forH > PASV connections or Passive IPs for external users.  Can this be done,H > and if so, how?  Hopefully, everything I said makes sense ... sorry if
 > it doesn't.c   ------------------------------  # Date: Tue, 04 Dec 2001 04:38:19 GMT   From: adroso@home.com (VLC User)< Subject: Re: Help needed: FTP Server & PASV connection ports9 Message-ID: <3c0c51b9.68244494@news.jamison1.pa.home.com>y  D TCP/IP is version V5.0 and there is no SET PASSIVE option.  I assumeF V5.1 and above has this, eh?  Other than upgrading to V5.1+, are there any other things I can do?  6 >"Matt Muggeridge" <Matt.Muggeridge@compaq.com> wrote:E >FTP PASV mode is supported in TCP./IP V5.1.  At the FTP prompt type:e >c >    FTP> HELP SET PASSIVE >iG >If you are unsure about the version of TCP/IP you have installed, use:e >t >    $ TCPIP SHOW VERh >  >Matt.  / >>"VLC User" <adroso@home.com> wrote in message 5 >>news:3c0bc8ca.33184302@news.jamison1.pa.home.com...PI >> I'm not a super-experienced VMS person, so if I sound stupid please beo
 >> gentle ...e >>H >> I have a VAXstation 4000 VLC (VMS 7.2) and I'm running the FTP ServerA >> that's found in the DIGITAL TCP/IP Services for OpenVMS SERVERe@ >> Components menu in the TCPIP$CONFIG command procedure.  I canG >> successfully connect to and transfer files with the VLC's FTP ServerR >> within my LAN.a >>H >> I'm also running a Serv-U FTP Server (on port 22) on a Win98SE PC andF >> I had to set up my router to forward a range of additional ports toE >> Serv-U for PASV connections for external users since it's behind aiE >> firewall.  Most importantly, I had to modify Serv-U to select fromvH >> this specific range of ports rather than just selecting one randomly,( >> as well as specifying the Passive IP. >>E >> I assume I have to do the same for the FTP Server on my VLC, but IhG >> can't find anything about specifying a range of additional ports fordI >> PASV connections or Passive IPs for external users.  Can this be done,sI >> and if so, how?  Hopefully, everything I said makes sense ... sorry ife >> it doesn't. >  >-   ------------------------------  % Date: Mon, 03 Dec 2001 13:01:09 -0800m' From: David Mathog <mathog@caltech.edu>:E Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deathh+ Message-ID: <3C0BE815.14A7DDF2@caltech.edu>o   John McLean wrote: >  > David Mathog wrote:t? I'm not a stockholder in either company but if I was I'd reallyo > > like to know the+ > > value and full conditions of that deal 1 > >h > C > As I said the other day, I don't believe that much money directlyd1 > changed hands at the time of the announcement.     EXACTLY!!!!!  E Since it wasn't a deal valued in dollars the value of the transaction H is not clear to stockholders.  Never mind forward estimates of the value	 of futurem: alpha based products, we don't even know in any sense what "considerations" IntelF gave Compaq in exchange.  That is, we have a pretty good understanding of what Compaq gave Intel,E but no idea at all of the value of what Intel gave Compaq.  So how ist anybody outside Compaq supposed to evaluate this deal?n  F By the way, I do agree with your evaluation that Cappelas was thinking like an accountantE and decided to take the investment in Alpha technologyoff the books. gC It's called "eating the seed corn" and MC must have figured that hef= could get away with it because hey, they could just buy IntelED CPUs and run on that (or ditch everything but Wintel, which fits the scenario even better - no.G non Wintel expenditures at all, never mind the profits.) My analysis islE that this action has basically destroyed Compaq's technical advantagee3 and dooms them to playing "me too" in future in theuG technical computing arena.  That is, kiss the mega supercomputer marketd good-bye because ifoD it's Itanic versus Itanic they have to go head to head with Dell and everybody on priceH with no technological advantage to let them sell into the "any price for even a slightly faster CPU"  market.p   Regards,  o David Mathog mathog@caltech.edu   ------------------------------  % Date: Mon, 03 Dec 2001 22:43:45 +0100m1 From: John McLean <mcleanj@swissonline.delete.ch>2E Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deathn5 Message-ID: <3C0BF211.B52B3F46@swissonline.delete.ch>    David Mathog wrote:c >  > John McLean wrote: > >bE > > As I said the other day, I don't believe that much money directlym2 > > changed hands at the time of the announcement. >  > EXACTLY!!!!! > G > Since it wasn't a deal valued in dollars the value of the transaction J > is not clear to stockholders.  Never mind forward estimates of the valueF > of future alpha based products, we don't even know in any sense whatL > "considerations" Intel gave Compaq in exchange.  That is, we have a prettyI > good understanding of what Compaq gave Intel, but no idea at all of theaD > value of what Intel gave Compaq.  So how is anybody outside Compaq! > supposed to evaluate this deal?s  G Most of them will just look at the bottom line and think that Compaq isiE doing not so badly.  They won't see that Compaq has perhaps burnt itsT bridges to any high-end future.:  E I say "perhaps" because I think it is the kind of decision that a CEOiE has to make from time to time, although whether this was one of thoseeE times is debatable considering that it is the PC area where they havea7 been making little or no money over the last few years.   @ (Like PC's accounted for 53% of the total expenses 1998-2000 butG returned only 2.0% of the total income.  Compaq actually spent 50% moresB on PCs than on the Enterprise stuff, but the Enterprise stuff made# almost 30 times as much in profit.)s  B What I especially don't like is that the theory that I proposed onG Saturday fits the known facts better and holds more water than Compaq'sp justification of the decision.  C I don't like dishonesty and incompetence in anyone or any company. e    H > By the way, I do agree with your evaluation that Cappelas was thinking@ > like an accountant and decided to take the investment in AlphaI > technologyoff the books. It's called "eating the seed corn" and MC mustTJ > have figured that he could get away with it because hey, they could justL > buy Intel CPUs and run on that (or ditch everything but Wintel, which fitsN > the scenario even better - no non Wintel expenditures at all, never mind theL > profits.) My analysis is that this action has basically destroyed Compaq'sI > technical advantage and dooms them to playing "me too" in future in theoI > technical computing arena.  That is, kiss the mega supercomputer market L > good-bye because if it's Itanic versus Itanic they have to go head to headN > with Dell and everybody on price with no technological advantage to let themB > sell into the "any price for even a slightly faster CPU" market.  F Well, suppose the HP merger goes ahead, which I think was what CapellaF was trying to engineer. No Tru64 so that means any supercomputer stuffG would be on HP Unix.  If they continue to use the current processor foreH the "merged" Unix I suspect that supercomputing can be forgotten becauseF the performance is not there.  Even moving HP Unix to Alpha would only@ prolong any involvement in the supercomputer area until Alpha isG replaced by IFP, so the effort of porting HP Unix is probably not worth E it.  As you say, when everyone is using IPF there is no technological , advantage that HP/CPQ will be able to offer.    E As I've said before, I hope the merger fails, I hope the HP board andr8 stockholders have the good sense to reject the proposal.  H If it goes ahead then I expect that all vestige of Compaq will disappearE within a few years.  In that time VMS might not die but be in a coma, F and decisions about pulling the plug on life-support may be necessary.C   And all the time Capellas is getting very well paid by the mergedoF company for what amounts to his incompetence and failure to look after0 the interests of Compaq and its stockholders...      John McL   ------------------------------  % Date: Mon, 03 Dec 2001 17:06:27 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca>aE Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deathl, Message-ID: <3C0BF760.7265B29A@videotron.ca>   John McLean wrote:I > would be on HP Unix.  If they continue to use the current processor foriJ > the "merged" Unix I suspect that supercomputing can be forgotten because  > the performance is not there.   H Who did Alpha recently beat for the #1 position in supercomputing ? IBM.M So when Alpha goes away, guess who will get all the supercomputing accounst ?e  K HP won't be getting any supercomputing business for a long while with theirg& sole offering of Intel's bloated chip.   ------------------------------  # Date: Mon, 03 Dec 2001 22:55:38 GMT * From: "Bill Todd" <billtodd@metrocast.net>E Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deathoA Message-ID: <KpTO7.64818$ox2.4026766@bin4.nnrp.aus1.giganews.com>6  4 "David Mathog" <mathog@caltech.edu> wrote in message% news:3C0BE815.14A7DDF2@caltech.edu...e   ...s  H > By the way, I do agree with your evaluation that Cappelas was thinking > like an accountantF > and decided to take the investment in Alpha technologyoff the books.E > It's called "eating the seed corn" and MC must have figured that he ? > could get away with it because hey, they could just buy Intel F > CPUs and run on that (or ditch everything but Wintel, which fits the > scenario even better - no I > non Wintel expenditures at all, never mind the profits.) My analysis is2G > that this action has basically destroyed Compaq's technical advantagel5 > and dooms them to playing "me too" in future in the I > technical computing arena.  That is, kiss the mega supercomputer markets > good-bye because if F > it's Itanic versus Itanic they have to go head to head with Dell and > everybody on priceJ > with no technological advantage to let them sell into the "any price for > even a slightly faster CPU"t	 > market.   J I really do think it's worse than just losing the technical/supercomputingI market, which I suspect is more ego-gratifying than directly remunerative > (though every bit of publicity helps) when compared with otherI commercial/server markets.  Higher-performance processors really are morebK cost-effective in multi-processor servers then lower-performance processorseI (just price out the difference between any server and another of the sameuE architecture but twice the number of processors to see that the pricenK difference swamps any difference in the cost of the processors themselves),eF which means that Itanic won't be able to compete cost-effectively withJ anyone but SPARC (and God help it when Hammer arrives as a less-expensive,H higher-performance, more IA32-compatible, *true* commodity alternative).   - bill   ------------------------------  # Date: Tue, 04 Dec 2001 04:53:31 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>DE Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deatht/ Message-ID: <3C0C55F6.E3768E55@cableinet.co.uk>C   John McLean wrote:  (D > I don't like dishonesty and incompetence in anyone or any company.  l# so, why are you working in IT John?e  & Don't worry, I have a similar failing.   regardsp   --   Tim.Llewellyn@cableinet.co.uk  o  C Standard disclaimer applies. My views in no way represent those of e! my employers or service provider.M   ------------------------------  % Date: Tue, 04 Dec 2001 07:01:24 +0100-1 From: John McLean <mcleanj@swissonline.delete.ch> E Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deathl5 Message-ID: <3C0C66B4.C9655BA2@swissonline.delete.ch>    Tim Llewellyn wrote: >  > John McLean wrote: > F > > I don't like dishonesty and incompetence in anyone or any company. > % > so, why are you working in IT John?. > ( > Don't worry, I have a similar failing.  E It's funny you should ask Tim, I spent 5 years at university doing an B architecture course and before results my known for the final year4 (which I passed), I'd enrolled in Computing Studies.  H At the time I found it like a breath of fresh air.  No longer did I haveH to put up with vague opinions about what was better and what was right. F IT people would argue with facts and logic - and that made things just
 so simple.   Time's change ....  :-(      John   ------------------------------  # Date: Mon, 03 Dec 2001 19:35:29 GMT " From: "Hans Vlems" <hvlems@iae.nl> Subject: Re: IEQ11 Driver VMSa0 Message-ID: <5uQO7.325$d21.1555@typhoon.bart.nl>  J Compaq in the netherlands tried to dig it up and declared the IEQ11 driver lost.iJ It just does not exist any more. Perhaps you have access to the VMS source	 listings.aE That might help, because the IEX11 and IEQ11 drivers are not terriblys affected by the J driver changes that apparently took place between VMS versions 5, 6 and 7.K Anyway, the changes to IEX11 were minor. Provided that you know what you'rei doing...  K So you might try and take, say, the V5.5 IEQ11 driver source and port it tow anotheriF version. Which was your original post. Are you interested in the IEX11 source?t   Hans  + SteveF23 <srf23@yahoo.com> wrote in messagem7 news:e8f65efb.0112021914.3e591388@posting.google.com... 7 > I actually need the IEQ11 - and Compaq is not willingo3 >   to dig it up.  Yes I know that it is an ancient & >  artifact, but mine is a long story. >f/ > "Hans Vlems" <hvlems@iae.nl> wrote in messaged* news:<sZoO7.63$d21.191@typhoon.bart.nl>...? > > IIRC there is a difference between the IEX11 and the IEQ11.h? > > Both interfaces connect to the IEEE bus (aka as the HP-IB).c@ > > The IEQ11 is a Q-bus controller, the IEX11 is a SCSI device. > > @ > > The source code for the IEQ11 is gone, the IEX11 sources are2 > > still available (at least in the Netherlands).K > > We had the IEX-11 driver modified for VMS V7.1 (by Compaq) and it worksS	 > > fine. F > > I'm not sure I can post the source code legally, but you could askA > > for the modified drivers at Compaq. The price was reasonable.T > >v > > Hans Vlems > >  > >l/ > > SteveF23 <srf23@yahoo.com> wrote in messageW; > > news:e8f65efb.0112011733.3df6c7f9@posting.google.com...oA > > > I am involved in a project using an IEQ11, on VMS using theeC > > >  IEX driver.  I have the IEX driver binaries and license, butSB > > >  I would like to see the source code to the driver.  Anybody: > > >  out there have the source in a attic or somewhere ?   ------------------------------   Date: 3 Dec 2001 12:09:05 -0800b' From: doran167w@aol.com (Doran Werling)g5 Subject: Re: Installing Icon permanently to CDE menu?a= Message-ID: <75749e0a.0112031209.70d461f6@posting.google.com>w  m "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message news:<sMMO7.65$BK1.1939@news.cpqcorp.net>... K > Mostly I suppose, since CDE is something we ported, and didn't write.  SoaM > you can generally find stuff on it on the market.  Just as we don't publishD > an OpenGL programming manual.s >  >  > " > Bob Koehler wrote in message ...H > >In article <BsON7.2174$RL6.63665@news.cpqcorp.net>, "Fred Kleinsorge"( >  <kleinsorge@star.zko.dec.com> writes:M > >> After having had to help some people on the COE project in customizationU >  ofdN > >> the desktop (of which I knew nothing).  My suggestion is to get a copy ofL > >> some good CDE documentation, and hand edit the appropriate files - some >  ofeH > >> which will be in your [.DT] directory, and for all users in the CDE > >> directories.t > >> > > E > >   And why doesn't that "good documentation" show up on my OpenVMSe > >   documentation CD?c > >.  # >>> You can find the CDE docset at  \ >>> http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V50A_HTML/SYSADMIN/TITLE.HTM  	 Regards, p
 Doran Werlingn RW/SCS Inc.    ------------------------------  % Date: Tue, 04 Dec 2001 04:29:09 +0100e2 From: martin@radiogaga.harz.de (Martin Vorlaender)0 Subject: Re: Is it a DEC C problem, or is it me?; Message-ID: <3c0c4305.524144494f47414741@radiogaga.harz.de>r  , John Eisenschmidt (jeisensc@aaas.org) wrote:0 > "John Eisenschmidt" <jeisensc@AAAS.ORG> wrote:H > > We have a 3rd party application we use here that has a TCP/IP socketH > > listener written in C. It's currently running on our 7.1 system, butG > > we're having problems trying to migrate it to 7.2-1. The vendor has,F > > supplied new header files since 7.1 uses UCX and 7.2-1 uses TCPIP.L > > Anyway we compile the code, link it, all goes well, but when the program > > gets called it explodes. > > K > > The vendor can't seem to find their problem (Solaris is their strength,0L > > not VMS), and I wanted to make absolutely sure it wasn't something on my > > end. > >I > > $ TCPIP SHOW VERSION > >aE > >   DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A - ECO 3 A > >   on a COMPAQ AlphaServer DS10 617 MHz running OpenVMS V7.2-1   D Hmmm... in earlier versions you couldn't do that if the stack wasn't up and running.F   > > $ CC /VERSION * > > DEC C V5.7-004 on OpenVMS Alpha V7.2-1 > >P> > > Are there any issues with this version of DEC C and 7.2-1?  = IMHO, the DEC C V6.x are better (for porting anyway), but no.0  C > > The program is compiled and linked with the following switches:e7 > > $ CC /STANDARD=VAXC/NOMEMBER_ALIGN/ASSUME=NOALIGNEDl > >e+ > > When called, the program abends thusly:2 > > H > > %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=6 > > 0000000000000000, PC=FFFFFFFF8095C8E8, PS=0000001B3 > > %TRACE-F-TRACEBACK, symbolic stack dump followscE > >   image    module    routine    line      rel PC           abs PC I > >                                   0 0000000000000000 FFFFFFFF8095C8E8dI > >  ADMC_GUI                         0 00000000000228E8 00000000000328E8>I > >  ADMC_GUI                         0 0000000000021E24 0000000000031E24rI > >  ADMC_GUI                         0 0000000000021868 0000000000031868pI > >  ADMC_GUI                         0 00000000000203D4 00000000000303D4aI > >  ADMC_GUI                         0 0000000000020070 0000000000030070 I > >  PTHREAD$RTL                      0 00000000000312FC 000000007BBAB2FCgI > >  PTHREAD$RTL                      0 0000000000012B48 000000007BB8CB48 I > >                                   0 FFFFFFFF854ED3F4 FFFFFFFF854ED3F4d  F Whenever I see the pthread library involved in a problem, I'd look for	 VMS ECOs.   # > This just gets uglier and uglier.m >rG > I'm trying to walk through the program and the header files that makeaD > this mess up. I have a couple questions I hope someone can answer. >eE > First, I think this works in our current 7.1 production environmenttI > because we were sent binaries. When those didn't work, they sent us the  > "new, working source". > I > They use a set of DCL procedures to compile and link the application. IuC > decided to compile them interactively. They usually compile their & > programs with the following options: >v7 > $ CC /STANDARD=VAXC/NOMEMBER_ALIGN/ASSUME=NOALIGNED -e( >         /INCLUDE=TCPWARE_INCLUDE foo.c  7 This uses the header files of a different TCP/IP stack!d) TCPware is a product of Process Software.a  A > So I figured I'd be brave and see how incompatible the code is.d >d+ > $ CC /DEBUG/INCLUDE=TCPWARE_INCLUDE foo.co >e7 >     if (getpeername(sockp, &clit_addr, &addrlen) < 0)i > ..........................^pJ > %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointerJ > value "&clit_addr" is "struct sockaddr_in", which is not compatible with > "struct sockaddr".; > at line number 256 in file DSA100:[QUXX.R71A.SRC]foo.c;59M  ; I don't know enough about network programming to rate this.y  7 >     if (getpeername(sockp, &clit_addr, &addrlen) < 0)h) > ......................................^nJ > %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointerI > value "&addrlen" is "int", which is not compatible with "unsigned int".h; > at line number 256 in file DSA100:[QUXX.R71A.SRC]foo.c;59e  J Ignore this one. If you change addrlen's declaration to "unsigned int", it4 will probably generate a warning at some other line.  " >     sprintf(id, "%x", getpid()); > .....................^N > %CC-I-IMPLICITFUNC, In this statement, the identifier "getpid" is implicitly > declared as a function.k; > at line number 438 in file DSA100:[QUXX.R71A.SRC]foo.c;59-  L You'll need the /PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES qualifier to remove this1 one. Using this is a good idea with DEC C anyway.R  5 >       ErrMsghandler(ERRALVUNKNOWN, MERRALVUNKNOWN);t > .....^J > %CC-I-IMPLICITFUNC, In this statement, the identifier "ErrMsghandler" is$ > implicitly declared as a function.; > at line number 636 in file DSA100:[QUXX.R71A.SRC]foo.c;59m  J This says there is no prototype for ErrMsghandler(), but also sets up one.6 VAX C didn't need prototypes, DEC C in ANSI mode does.  2 >            AMLTRMT(&TransArea.GUI_DATA, &which);* > .......................................^J > %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointerM > value "&which" is "array [1] of char", which is not compatible with "char".d; > at line number 782 in file DSA100:[QUXX.R71A.SRC]foo.c;59h  F Now this looks like an error. A char[] is not the same as a char. LookI at the prototype of AMLTRMT() and the declaration of "which" to determinetC what should be in there (my guess is that the parameter should reade "which" without the &).   - > void ErrMsgHandler(int errcode, char msg[])  > ....^aJ > %CC-W-DUPEXTERN, The declaration of "ErrMsgHandler" will map to the sameH > external name as the declaration of "ErrMsghandler" at line number 636) > in file DSA100:[QUXX.R71A.SRC]foo.c;59.h< > at line number 1473 in file DSA100:[QUXX.R71A.SRC]foo.c;59  G As the compiler supplied a prototype above, this declaration triggers ae warning.  E > Suddenly not feeling as brave as before, I used the listed options:  >tM > $ CC /STANDARD=VAXC/NOMEMBER_ALIGN/ASSUME=NOALIGNED/INCLUDE=TCPWARE_INCLUDEp > foo.c  >h- > void ErrMsgHandler(int errcode, char msg[])h > ....^oJ > %CC-W-DUPEXTERN, The declaration of "ErrMsgHandler" will map to the sameH > external name as the declaration of "ErrMsghandler" at line number 636) > in file DSA100:[QUXX.R71A.SRC]foo.c;59.y< > at line number 1473 in file DSA100:[QUXX.R71A.SRC]foo.c;59  ) Same cause as above: a missing prototype.a  I > I was surprised to see the use of "TCPWARE_INCLUDE" since we use TCPIP.e  F You can determine which stack you're running by a simple $SHOW SYSTEM.C If there are "TCPWARE_xxx" processes, you're indeed running ProcesshB Software's TCPware. Compaq TCP/IP processes are named "TCPIP$xxx".  A > I took a look in SYS$SHARE, and found only the TCPIP files. I'miJ > wondering if this is a problem. I assume the compiler isn't smart enoughH > to assume "hey, I explicitly said I wanted to use Networking librariesC > of Type A, but I really use Type B, so I'll fix this for you". MybH > uneducated guess is that the socket definitions this program wants are( > actually in SYS$SHARE:TCPIP$INETDEF.H?  ( Depends on what stack is really running.  E > I was also surprised to see that the compiler generated object code E > despite a warning. Is that normal? If it didn't compile, why did iti > generate object code?a  K They're just warnings, not errors. Like the "int" vs. "unsigned int" issue,uL they can be harmless. But the other type conflict - char[] vs. char - really looks like an error.  5 If you don't like to see the warnings, you can alwayso1 /WARNINGS=DISABLE=(...) - DON'T! I'M JUST JOKING!t  J > In any event, it appears our fine vendor friends were linking right past > that:o >o > $ LINK foo,SYS$INPUT/OPTIONS% > SYS$SHARE:TCPWARE_SOCKLIB_SHR/SHAREi  = which is consequent after compiling with the TCPware headers.a  G As it looks like they're using threads: you should also clarify whetherh' the TCPware parts used are thread safe..   Hope it helps,   Martin -- tD                     | Martin Vorlaender    |    VMS & WNT programmer-   Smiert Spamionem  | work: mv@pdv-systeme.denD                     |       http://www.pdv-systeme.de/users/martinv/4                     | home: martin@radiogaga.harz.de   ------------------------------  % Date: Mon, 03 Dec 2001 17:37:10 -0700 $ From: Lee Y T Mah <lytmah@cha.ab.ca>( Subject: Letter from Michael D. Capellas) Message-ID: <3C0C1AB5.EDD948C5@cha.ab.ca>0  H I just opened up a letter dated November 27, 2001 from Mr. Capellas.  It@ discusses the proposed merger of Compaq and Hewlett-Packard.  ItD mentions ProLiant, Himalaya, AlpaServer, Presario, even IPAQ.   I am? near-sighted, so I got eyestrain and a headache looking for anyrF reference to OVMS.  Even after going through the letter three times, I? couldn't find OVMS.  I was prepared to fire off a letter to Mr.hE Capellas, but if I was mistaken in my search for that elusive word, IlF would be embarrassed.  I'll let someone else confirm that there was no7 mention of OVMS in the letter.  Then they can complain.g   -- Lee   ; Lee Y T Mah                        Capital Health Authority-? Email: lytmah@cha.ab.ca            Information Systems, RAH CSCB4 Phone:  (780) 477-4725, 477-4233   10240 Kingsway NW? Fax:      (780) 491-5119, 491-5619    Edmonton, AB, CAN  T5H3V9    ------------------------------  % Date: Mon, 03 Dec 2001 20:23:33 -0500a- From: JF Mezei <jfmezei.spamnot@videotron.ca>1, Subject: Re: Letter from Michael D. Capellas+ Message-ID: <3C0C2581.AE89BA4@videotron.ca>p   Lee Y T Mah wrote:H > reference to OVMS.  Even after going through the letter three times, IA > couldn't find OVMS.  I was prepared to fire off a letter to Mr.h > Capellas,h    M Consider that any omissions of VMS are intentional. The Compaq top managementdJ are fully aware that VMS customers are very sensitive to VMS being omittedI from Compaq public statements. So whenever VMS is omitted, you can safelyME conclude that Compaq management is intentionally sending a message byh intentionally omitting VMS.   K Compaq isn't killing VMS because it knows that killing it would mean losingiH the remaining VMS customers. So it will just just do the bare minimum to prevent mass desertion.v   ------------------------------  # Date: Tue, 04 Dec 2001 05:06:08 GMTo" From: Art Rice <arice@myhouse.org>, Subject: Re: Letter from Michael D. Capellas9 Message-ID: <4RYO7.1174$kT5.238598@dfiatx1-snr1.gtei.net>u   Lee Y T Mah wrote:  J > I just opened up a letter dated November 27, 2001 from Mr. Capellas.  ItB > discusses the proposed merger of Compaq and Hewlett-Packard.  ItF > mentions ProLiant, Himalaya, AlpaServer, Presario, even IPAQ.   I amA > near-sighted, so I got eyestrain and a headache looking for anyrH > reference to OVMS.  Even after going through the letter three times, IA > couldn't find OVMS.  I was prepared to fire off a letter to Mr.oG > Capellas, but if I was mistaken in my search for that elusive word, IoH > would be embarrassed.  I'll let someone else confirm that there was no9 > mention of OVMS in the letter.  Then they can complain.  >  > -- > Leee > = > Lee Y T Mah                        Capital Health AuthoritytA > Email: lytmah@cha.ab.ca            Information Systems, RAH CSC-6 > Phone:  (780) 477-4725, 477-4233   10240 Kingsway NWA > Fax:      (780) 491-5119, 491-5619    Edmonton, AB, CAN  T5H3V9d >  >  > H All of the above are servers not operating systems.  Did it mention NT, / NSK, Tru-64, etc..., or were they left out too?    -- i Art Rice, Tandem Admin Special Data Processing Corp ----------------------------L All opinions are my own and do not reflect the views of the above mentioned 	 employer.y   ------------------------------  # Date: Tue, 04 Dec 2001 05:17:35 GMTe* From: Lee Y T Mah <lytmah@telusplanet.net>, Subject: Re: Letter from Michael D. Capellas/ Message-ID: <3C0C5D36.FBB657B3@telusplanet.net>o   ...aE Our AlphaServer product line ...most scalable UNIX platform today,...   O Good thing I didn't send off my letter.  Reading all the doom and gloom in thist) newsgroup must be having an effect on me.M   Art Rice wrote:    > Lee Y T Mah wrote: >nL > > I just opened up a letter dated November 27, 2001 from Mr. Capellas.  ItD > > discusses the proposed merger of Compaq and Hewlett-Packard.  ItH > > mentions ProLiant, Himalaya, AlpaServer, Presario, even IPAQ.   I amC > > near-sighted, so I got eyestrain and a headache looking for any J > > reference to OVMS.  Even after going through the letter three times, IC > > couldn't find OVMS.  I was prepared to fire off a letter to Mr.uI > > Capellas, but if I was mistaken in my search for that elusive word, IdJ > > would be embarrassed.  I'll let someone else confirm that there was no; > > mention of OVMS in the letter.  Then they can complain.e > >1 > > -- > > Leer > >H? > > Lee Y T Mah                        Capital Health AuthoritygC > > Email: lytmah@cha.ab.ca            Information Systems, RAH CSCd8 > > Phone:  (780) 477-4725, 477-4233   10240 Kingsway NWC > > Fax:      (780) 491-5119, 491-5619    Edmonton, AB, CAN  T5H3V9  > >e > >t > >aI > All of the above are servers not operating systems.  Did it mention NT,f1 > NSK, Tru-64, etc..., or were they left out too?  >c > -- > Art Rice, Tandem Admin > Special Data Processing Corp > ----------------------------M > All opinions are my own and do not reflect the views of the above mentionedi > employer.d   -- Leew   lytmah@telusplanet.net   ------------------------------  % Date: Mon, 03 Dec 2001 15:04:43 -0800 . From: Jack Trachtman <Jack.Trachtman@vmmc.org> Subject: Memory Search( Message-ID: <3C0C050B.2B7CC1F6@vmmc.org>  6 Does anyone have any old DEC MS16-DA 32MB memory cards" that they would like to part with?  < I'm using an old AlphaServer 3300 has my VMS Workstation and 64MB will no longer cut it.    ------------------------------   Date: 3 Dec 2001 20:56:27 GMTe) From: leslie@clio.rice.edu (Jerry Leslie)IB Subject: Re: Microsoft Pyramid Collapses Enron and Hewlett Packard' Message-ID: <9ugotr$ons$3@joe.rice.edu>,  4 Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote:M : Since I was eating lunch, I read the entire page you point at.  This guy istL : so far out, it's hard to seperate out the facts  from the fantasy.  All heL : needed to do was throw in the Queen and Aliens to make himself look like aL : total crackpot.  He spent as much telling me how "the BillParishReport.com : will show" as anything else. : " I found the Bill Parish site from:        http://www.netslaves.com/1      NetSlaves: What are you lookin' up here for?o  C There's a thread about being unable to find a full-time IT job for  9 a whole year, "Happy Anniversary: One Year Without Work".e  D One of the more recent entries on that thread paints a scary picture8 of the Southern MA & NH area (URL wrapped to two lines):  F    http://www.netslaves.com/cgi-bin/yabb/YaBB.pl?action=display&board=#    005&num=1007032630&start=105#114i      Posted by slamitbobby  /    Re: Happy Anniversary: One Year Without Work9  F   "I use to be a Cisco Network Engineer and Architect, i designed and G    built from the ground up, $50 million dollar e-business, e-commerce rI    etc networks on a global level....i have been looking for a job EVERY tF    SINGLE DAY for 6 months now.  It is just like youve been reading!  I    It's worse than the great depression, i guess all of youy lucky folks oJ    that still hold jobs just would rather prefer to walk thru this entire J    thing with blinders on  and pretend it isnt happening?  CASE IN POINT: N    I have spent the last 2 weeks going to every single company with a network L    and an IT department in the entire Southern NH and MA areas, ive in this L    2 week  period printed over 100 resumes (mine are 4 pages long as i have F    many years and much experience) and hand delivered them to over 100H    companies.....let me tell you some statistics iv'e learned (of courseE    youll never hear about these companys statistics because their not.I    Enrons or large enough for the magor news organizations to even bothero	    with)._  G    FACT 1- Every single one of these 100 companys has had magor layoffsnE    in the last 2 months, and laying off more by the week these last 20	    weeks!   G    FACT 2- 25% of them are already in Chapter 11 and struggling just to *    keep their doors open every single day!  I    FACT 3- Another 25% of them are shutting their doors completely withine)    days and or over the next week or two!   H    And every single receptionist ive been greeted by when i lay my spielF    on them that i am a laid off Network Engineer pounding the pavementH    looking for work, has gotten a good chuckle and wished me the best asG    they will all soon be in the same boat as me and the million + otherUG    laid off IT workers out there in lala land (they say the figure is ae    million+..."t      4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Mon, 03 Dec 2001 19:32:58 +0000M4 From: Andrew Swallow <andrew.swallow@baesystems.com>* Subject: Re: No surprise about Tru64 death. Message-ID: <3C0BD36A.E1ADA1F4@baesystems.com>  
 cjt wrote: >  [snip] 5N > Good question.  By then they might be in a position to keep their lines busy( > making 700 MHz Pentiums for the X-Box.  7 Intel prefers to make chips that it can sell for least C7 100 US dollars.  It will not refuse to make any costing 2 less than 50 dollars.  The X-Box ones will have to come from a colon manufacture. -- x7 _______________________________________________________g Andrew Swallow   ------------------------------  % Date: Mon, 03 Dec 2001 19:57:00 +0000A4 From: Andrew Swallow <andrew.swallow@baesystems.com>* Subject: Re: No surprise about Tru64 death. Message-ID: <3C0BD90C.9963561E@baesystems.com>   Andrew Swallow wrote:0 >  > cjt wrote: > >E > [snip]P > > Good question.  By then they might be in a position to keep their lines busy* > > making 700 MHz Pentiums for the X-Box. > 8 > Intel prefers to make chips that it can sell for least; [> 100 US dollars.  It will not refuse to make any costing]0 Opps, that should have said 4  100 US dollars.  It will refuse to make any costing  4 > less than 50 dollars.  The X-Box ones will have to  > come from a colon manufacture. > --9 > _______________________________________________________3 > Andrew Swallow     -- A7 _______________________________________________________0+ Andrew Swallow (7605) 2225   Cowes site, UK  andrew.swallow@baesystems.com7   ------------------------------  $ Date: Mon, 3 Dec 2001 23:07:17 -0000; From: "Leigh G. Bowden" <LGBowden@bowdenfamily.fsnet.co.uk>5 Subject: Oracle problems. / Message-ID: <9uh0g8$7kk$1@newsg1.svr.pol.co.uk>p  F We have an AlphaServer 2100 4/200 with two CPU's and 1GB of memory andG plenty of disks - all shadowed. As far as I am aware it is using Oraclek 7.1.5 on OpenVMS 6.2 AXP.a  J It appears to be unreliable. After about three weeks this system will lockG up and the console will report "Insufficient memory for operation" typeeJ errors and will allow nobody to logon even at the console. The only way to" get out of this to power cycle it.  G Has anybody experienced this before and got any suggestions for a fix??v   ------------------------------  # Date: Mon, 03 Dec 2001 23:23:44 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Oracle problems.P0 Message-ID: <4QTO7.89$BK1.2688@news.cpqcorp.net>  m In article <9uh0g8$7kk$1@newsg1.svr.pol.co.uk>, "Leigh G. Bowden" <LGBowden@bowdenfamily.fsnet.co.uk> writes:oG :We have an AlphaServer 2100 4/200 with two CPU's and 1GB of memory ando! :plenty of disks - all shadowed. k  H   That's a comparitively old and slow EV4-class Alpha platform, and one K   gigabbyte of main memory is comparatively small by current configuration t   standards.  B :As far as I am aware it is using Oracle 7.1.5 on OpenVMS 6.2 AXP.  D   You will want to confirm this, since this version information willF   be central to most of the subsequent research that is required here.H   Your version of OpenVMS Alpha lacks various of the enhancements aroundG   sixty-four bit addressing that were added for V7.0, and thus has the fF   VAX limitations around stuffing most everything of consequence into F   the S0 and S1 space (2TB) address range -- this probably likely willF   not help with the apparent leak reported here, but I've encountered G   numerous Alpha (pre-V7) systems with the resulting addressing limits.   K :It appears to be unreliable. After about three weeks this system will lock H :up and the console will report "Insufficient memory for operation" type :errors   C   You will want to get the specific error message, not the type of lD   message.  (No offense is intended.)  There are many similar error G   messages, and the specific and full error message text is invaluable dB   evidence when determining the details of the particular problem.E   Abbreviations or any other alterations to the reported text should cE   be carefully avoided, given the likelyhood these changes will serveC   only to introduce ambigiuity.n  G :...and will allow nobody to logon even at the console. The only way tor# :get out of this to power cycle it.   E   This initially appears to be a memory leak, either in OpenVMS or in.G   the database software.  You will want to apply the mandatory ECO kitscE   for OpenVMS Alpha, and you will want to check with Oracle (classic,iG   I assume, since that is not an Rdb version) for any database patches,.F   and you will want to configure a sufficiently large system crashdumpE   file and learn how to force an OpenVMS system crash from the system 
   console.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 04 Dec 2001 04:25:33 GMTS1 From: "David J. Dachtera" <djesys.nospam@fsi.net>p Subject: Re: Oracle problems.c' Message-ID: <3C0C5050.9C4F1828@fsi.net>n   Hoff Hoffman wrote:  > o > In article <9uh0g8$7kk$1@newsg1.svr.pol.co.uk>, "Leigh G. Bowden" <LGBowden@bowdenfamily.fsnet.co.uk> writes:LI > :We have an AlphaServer 2100 4/200 with two CPU's and 1GB of memory ando" > :plenty of disks - all shadowed. > I >   That's a comparitively old and slow EV4-class Alpha platform, and one L >   gigabbyte of main memory is comparatively small by current configuration >   standards. > D > :As far as I am aware it is using Oracle 7.1.5 on OpenVMS 6.2 AXP. > F >   You will want to confirm this, since this version information willH >   be central to most of the subsequent research that is required here.J >   Your version of OpenVMS Alpha lacks various of the enhancements aroundH >   sixty-four bit addressing that were added for V7.0, and thus has theG >   VAX limitations around stuffing most everything of consequence into H >   the S0 and S1 space (2TB) address range -- this probably likely willG >   not help with the apparent leak reported here, but I've encounteredbI >   numerous Alpha (pre-V7) systems with the resulting addressing limits.b > M > :It appears to be unreliable. After about three weeks this system will locklJ > :up and the console will report "Insufficient memory for operation" type	 > :errors  > D >   You will want to get the specific error message, not the type ofE >   message.  (No offense is intended.)  There are many similar erroreH >   messages, and the specific and full error message text is invaluableD >   evidence when determining the details of the particular problem.F >   Abbreviations or any other alterations to the reported text shouldG >   be carefully avoided, given the likelyhood these changes will serveM! >   only to introduce ambigiuity.t > I > :...and will allow nobody to logon even at the console. The only way toK% > :get out of this to power cycle it.W > G >   This initially appears to be a memory leak, either in OpenVMS or ineI >   the database software.  You will want to apply the mandatory ECO kitsfG >   for OpenVMS Alpha, and you will want to check with Oracle (classic, I >   I assume, since that is not an Rdb version) for any database patches,gH >   and you will want to configure a sufficiently large system crashdumpG >   file and learn how to force an OpenVMS system crash from the system  >   console.  F Sounds familiar! Like Hoff said, check for patches - VMS *AND* Oracle!A If memory serves (and it frequently doesn't), this may be a knownL problem with a fix available.    -- - David J. Dachtera8 dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/e   ------------------------------  # Date: Tue, 04 Dec 2001 04:13:28 GMTr1 From: "David J. Dachtera" <djesys.nospam@fsi.net>IY Subject: Re: Q: Tool or script to remove nonprinting characters from a SET HOST log? log?h' Message-ID: <3C0C4D7D.FF47DEC0@fsi.net>    Nic Clews wrote: > , > Alan Winston - SSRL Admin Cmptg Mgr wrote: > >m > > Comp.os.vmsers --r > > L > > I remember vaguely reading something about a tool or script specificallyA > > designed to clean up the log files you get from SET HOST/LOG.g > F > Umph, a quick and dirty way is to use EDT and create a listing file. >  > From command line mode:  >  > SET NONUMBERSe > PRINT filespec.LIS  ) Yeah - that's what I was gonna suggest...    --   David J. Dachtera9 dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------   Date: 3 Dec 2001 23:16 CST' From: carl@gerg.tamu.edu (Carl Perkins)2! Subject: Re: RECALL does not work , Message-ID: <3DEC200123163936@gerg.tamu.edu>  5 "Chris Townley" <news@townleyc.demon.co.uk> writes... ; }"Hunter Goatley" <goathunter@goatley.com> wrote in messages+ }news:3c0700e8.12870116@news.process.com...eI }> On Thu, 29 Nov 2001 18:34:07 -0500, David Froble <davef@tsoft-inc.com>s }wrote:  }>F }> >Speculating.  I'd think that RECALL is implemented in the terminalI }> >driver, and such is not used in batch jobs, thus no capability there.n }> >K }> The terminal driver does support command-line recall, but only one line.SK }> DCL's RECALL buffer is pure DCL code.  (I used to have (well, it's stillmG }> there, but few people need it these days) a program that would patchvG }> DCL to extend the command recall buffer from 20 commands to 63 (VAX)o }> or more (Alpha).c }>	 }> Hunter  } J }I think you will find the 20 limit went out years ago, wasnt it VMS 5.0 ? }  }--s }Chris   VMS V5.5-2 had a limit of 20.   G VMS 6.1, on Alpha at least, had a much larger limit - the same limit as 	 now: 254.h  ; I don't know what the limit on 6.0 or the Alpha's V1.5 was.s   --- Carl   ------------------------------  * Date: Mon, 3 Dec 2001 16:40:52 -0500 (EST)' From: <pat@cart-server.purdueriots.com>e Subject: RL02 disk driveP Message-ID: <Pine.LNX.4.33.0112031616540.9534-100000@cart-server.ecn.purdue.edu>  E I'm looking for documentation on the hardware of the RL02 disk drive.rA I've purchased a few drives from my university, but would like toeJ understand how the interface operates. I've found a description of the pinD out in a 'pocket service manual' for it.  Now I need to know how the' controller communicates with the drive.i   Thanks for the help!   -- Pat   ------------------------------   Date: 4 Dec 2001 00:22:20 -06000+ From: kuhrt@encompasserve.org (Marty Kuhrt)-H Subject: Re: SKC Musings on "Recent IPF Unpleasantness" at www.tru64.org3 Message-ID: <YIRCgW95EPvi@eisner.encompasserve.org>T  i In article <3C06763C.F67C548F@swissonline.delete.ch>, John McLean <mcleanj@swissonline.delete.ch> writes:- > "Terry C. Shannon" wrote:  >> o	 >> Folks,w >>  C >> Given the controversy that my special SKC issue entitled "Compaq-I >> Cartographers Drew the IPF Roadmap" (.html | .pdf) precipitated when I N >> posted the piece, it seemed like the best thing to do was wite a follow-up.O >> If you haven't read the original document, feel free to do so. Draw your own M >> conclusions, but please take a moment to review the follow-up as per belowm >> (Nov 10, 2001)a >> e >>       Shannon knows Compaqr) >>       An Outpouring of Alphacide Angst  >>       (Nov 28, 2001)  > D > The problem with Compaq is more than just poor communication, poorJ > marketing, poor press-releases, poor understanding of the user community1 > ... etc, etc.  The problem is their competence.S > G > There have been too many errors of judgement (eg. extreme emphasis onaJ > the PC side of the business, roadmaps and commitments that are cancelledI > before the ink is dry) and their credibility now rates somewhere in the  > negatives. > I > Once customers lose confidence in a supplier they rapidly start to look D > elsewhere; those customers who stay with the product, for whateverG > reason, become extremely skeptical of any statement from that company 9 > and will examine every statement in microscopic detail.  > I > This is what has happened with Compaq and all too often that detail hasaC > been found to be wanting, thus diminishing their credibility evenK
 > further. > E > Communication is a small part of their problem.  Credibility is the  > bigger issue.  > 
 > John McLeanr   I'll second that emotion.D  @ In our environment CPQ severly lacks credibility.  Their actions? over the last year have shown, beyond a shadow of a doubt, that ? "betting the business" on CPQ would be irresponsible.   I won'tn@ even touch on the attrocious decline in hardware support quality? since the CPQ takeover of Digital, or the clueless sales drones-> that wouldn't give us quotes for Alphas because they wanted toA pitch Proliants.  I'll just reiterate what _I've_ run up against, 	 recently.B  ? We are still running VMS for stock market stuff, but that is iny@ the process of being ported (to another OS and HW platform).  We; _had_ most of our number crunching and portfolio management A running on VMS, but that has been ported with the end date slated6 for year end.  e  > I had an opportunity to get the company I work for to consider= VMS for a "very big project", or VBP, for short (so sue me, I@A like three letter acronyms that start with V).  I argued long andt= hard to explain that VMS could provide the scalability, faultt@ tolerance and performance that they would be hard pressed to get' from any other platform and OS combo.  t  @ I convinced them that they didn't need "VMS people" for the VBP,= which is the usual argument from the developer types, since Ii= could provide them with SAS, C, Java, Weblogic, Apache, Perl,i? Perforce... The Works!  (with the exception of unix shells, butl= most of the commands they'd be using could be 'symbolized' too9 look just like a unix shell, and it wasn't a deal breakere anyway).  : Then the Alpha bomb dropped.  So much for the time I spent@ porting some of their applications and showing them how they ranA faster on a lowly DS10 compared to their other platforms.  "Yep",.> they'd say nicely, "you convinced us that Alpha was faster and@ would probably would have been so for the forseeable future, andA that VMS was the superior OS to base it on, but that doesn't seemk@ like the case now."  "Besides," they hrrumph'd, "Compaq seems toA have a credibility problem, didn't they say a while back that then# Alpha was good for another decade?"g  A "Um, yeah, I showed you that processor comparison white paper andy@ letter from a CPQ muckity-muck a while back", suddenly wondering why the AC had stopped working.   = "But VMS on IA64 will still be rock solid!  You won't have toe? invest in those multiple vendors with barely proven products to 9 get the multi-site data center, data coherence, and fault : tolerance that has been in VMS for well over a decade!", I
 countered.  < "You can get VMS on IA64, now?", they said to me with arched	 eyebrows.1  > "Um, well, no.  But Compaq has said that they have started the port"r  8 "But we need it now.  Also, since HP is buying CPQ, what? guarantees that VMS will be ported, more or less survive?", nowl> given the look that is usually reserved for the "spare change" people on the city streets.   ; At that point I realize that point it is futile to continueF? arguing, because they'd just start making circular motions withf9 their index fingers pointed at their ears if I continued.k  9 But then again, what do they know.  They just produce thea: software that manages one quarter of the world's wealth.     ------------------------------  $ Date: Mon, 3 Dec 2001 20:02:40 -0600$ From: "del cecchi" <dcecchi@msn.com>7 Subject: Re: the Compaq pseudo-technical spin continues 1 Message-ID: <l9WO7.36$yC2.3049@eagle.america.net>l  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message* news:VpMO7.59$BK1.1372@news.cpqcorp.net... > Toon Moene wrote in message + <3C08D1CC.92DA3E0C@moene.indiv.nluug.nl>...  > >Fred Kleinsorge wrote:e > > H > >> For the sake of argument, lets just say that Compaq decided to stop Alphan. > >> production completely on a complete whim. > >i6 > >> Does that have some fallout with customers?  Yes. > >0< > >Duh !  For the last week, I mostly have seen fallout from
 *prospective*o? > >customers, due to peeking into the insides of some ITTs (andD	 resulting4& > >contracts) I was asked to evaluate. > > C > >Nobody is going to buy into an architecture that's on death row.i > >u >  >aE > I am quite sure that any number of our field specialists in OpenVMSt will beeB > happy to work with you to overcome the doubts of your customers.  G Doubts about what?  The future of Alpha?  The wonderfulness of Itanium, * and the vapor port?  Is Itanium bi-endian? >_C > The OpenVMS Alpha platforms will be among the best performers out-	 there for G > a while, and we will continue to support them for quite a while, justl likeH > we still support EV4 systems built nearly a decade ago.  The crossover toC > Itanium can then be managed as it's performance exceeds the Alpha:
 platforms,F > with source compatability, and well as binary translation for legacy > applications.   B They will be in the top ten for a couple more years.  And you will) support them as long as HP feels like it.   B The performance will stagnate for years, until Itanium catches up.  
 del cecchi >U >o >r >  >w   ------------------------------  $ Date: Mon, 3 Dec 2001 20:05:30 -0600$ From: "del cecchi" <dcecchi@msn.com>7 Subject: Re: the Compaq pseudo-technical spin continues_1 Message-ID: <%bWO7.38$yC2.2673@eagle.america.net>_  < "Sander Vesik" <sander@haldjas.folklore.ee> wrote in message- news:1007397853.264749@haldjas.folklore.ee...wC > In comp.arch Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:cH > > Honestly, most customers are interested in solutions to their needs. ThekE > > last thing on the list of criteria for selection of a solution isl probably > > the ISA of the chip. > E > > IMHO what most VMS customers want is VMS.  They'd be really happyw
 with a VAX$ > > that ran the speed of a pentium. >nC > > If OpenVMS continues to provide high performance solutions, andw= > > oh-by-the-way happens to find itself on a more maonstreamu architecture 3-5G > > years from now - do you care what the ISA is as long as it is stills meetingo > > your needs?u >fG > Assuming OpenVMS by that time still is what they want, that they willnE > accept having to put up with all the bugs that will be in the firstoC > couple of incarnations of the port. Time spent on porting is timef	 obviously % > not spent on features or bugfixing.- >  > -- > Sander >n > +++ Out of cheese error +++<  F Don't forget the fun of debugging all that old code that the source is lost or decayed.  
 del cecchi   ------------------------------  # Date: Tue, 04 Dec 2001 04:22:21 GMTt3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>e7 Subject: Re: the Compaq pseudo-technical spin continuesa/ Message-ID: <3C0C4E86.DBD7CC13@cableinet.co.uk>r   del cecchi wrote:   t > H > Don't forget the fun of debugging all that old code that the source is > lost or decayed. >  > del cecchi  J ah yes, but the "answer" to that is to re-engineer your business processesN at the same time you port, that way you just junk all the old code and systemsO and staff and charge the client an even fatter fee for the latest off the shelf  labour intensive solution.  n -- u Tim.Llewellyn@cableinet.co.uk  n  C Standard disclaimer applies. My views in no way represent those of b! my employers or service provider.    ------------------------------  # Date: Tue, 04 Dec 2001 06:26:27 GMT- From: Joe Keane <jgk@jgk.org>a7 Subject: Re: the Compaq pseudo-technical spin continues 8 Message-ID: <n0_O7.879$He.17981@sea-read.news.verio.net> Keywords: dominate  2 In article <wHSN7.2188$RL6.63696@news.cpqcorp.net>5 Fred Kleinsorge <kleinsorge@star.zko.dec.com> writes:tE >We are now moving to an architecture with a WIDESPREAD ACCEPTANCE in E >the industry as being the next generation 64-bit platform.  In fact,aA >everyone but Sun has embraced Itanium as the future for 64 bits.    Speak for yourself, butthead.o  > I am not Sun.  I don't embrace Itanium.  I recently said that,, basically, Hammer is the future for 64 bits.   --  Joe Keane, amateur mathematician   ------------------------------  # Date: Tue, 04 Dec 2001 04:10:11 GMTt1 From: "David J. Dachtera" <djesys.nospam@fsi.net>i2 Subject: Re: The real story about Alpha's death ??' Message-ID: <3C0C4CB6.399E6D28@fsi.net>    John McLean wrote: >  > "David J. Dachtera" wrote: > >h > > John McLean wrote: > > > [snip]N > > > If he can get rid of Alpha, then he can save about $350 million per year > > > off the bottom line. > >cG > > Unless "Curly's a dope!", as quoted from a musical number ina ThreeoI > > Stooges film, doesn't hold water. He can add $350 million back to the-I > > bottom line; but to do it, he's gotta kill their Alpha-only cash cows K > > Tru64 and VMS, thus SUBTRACTING $5 billion from the bottom line, ending- > > up seriously in the red! > C > Not at all.  Switching them to IPF in a few years will work.  ThenH > current state of Alpha, with enhancements that are close to completionJ > (and thus development costs will be paid for in the income) are all that9 > customers need to carry on with until IPF is available.g  . ...and is all we *CAN* carry on with, for now!  = > > You think Enron is in trouble? You ain't seen *SHIT* yet!L > >G7 > > >  More to the point, if he can announce it to take F > > > effect in a few years, then he's saved money during that time onN > > > development (which for now produces no profit) and even if Compaq has toM > > > pay for its processors in five years, he probably won't be around to bev > > > held accountable.i > >iL > > The only way that logic works, since IA64 is still unviable, is to startF > > with an IA32 port, then step back up to 64 bits when Intel finally  > > delivers a saleable IPF CPU. > @ > You're forgetting about the "momentum" from various EV7 steps.   Hardly.p  MB > I'm not an accountant but it seems to me that he has looked at aA > long-term asset and decided that it is a short-term liability. i  G Exactly my point. Myopia. Can't see the future. Gotta take a short-termd hit to gain a long term profit.t   > Hisb/ > solution helps Compaq's financial state now, a   ...or does it?  G How much of the drop in revenue or stock price can be attributed to theg economy? ...9/11? ...Alphacide?p   > helps the merger talks now  @ BEYOND help! (...or even the man-pages! Sorry, couldn't resist!)  @ > ... and what happens in 3 or 4 or 5 years (when VMS is on IPF   F ...(assuming IPF is a reality by then! How late is it now? Three yearsB or more? ..and still no light at the end of tunnel? ...despite the approaching express train?)d   > - and ; > there's no Tru64 anymore) will be someone else's problem.   ) It already *IS* "someone else's problem":v  D o The customer who must now dump plans to upgrade their Alpha(s) and@ migrate instead to a shipping platform with a foreseeable futureG (though, off the top of my head, I can't think of *ANY* besides IA32 orn Sparc!).  8 o The ISVs whose VMS/Tru64 Alpha market just evaporated.  @ o The resellers with inventories of Alphas and two hands full of cancelled upgrade orders.   F o People like Gaitan, Hoff, etc. who will live or die (professionally)E by whether or not they can make VMS work on SOMEthing besides VAX and  Alpha.  8 The ships were burned, alright! Prophetic words, I fear!  8 Gotta face it, man - Alphacide was one COLOSSAL cock-up!   -- c David J. Dachteraa dba DJE Systemso http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/f   ------------------------------  # Date: Tue, 04 Dec 2001 03:52:46 GMT'1 From: "David J. Dachtera" <djesys.nospam@fsi.net>bN Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))' Message-ID: <3C0C48A2.25474D47@fsi.net>t   Bob Koehler wrote: > P > In article <9uandc$bfd@web.nmti.com>, peter@abbnm.com (Peter da Silva) writes:L > > You now, that wouldn't be bad. So long as it's Tru64 under the hood, andR > > I suspect parts of the native API exposed as a "Tru64 compatibility extension"Q > > because system programs will need to talk to the *real* kernel, it's not that G > > important what minor variations in the common UNIX API get exposed.g > D >    There are issues further out than the API.  Did you ever try toC >    figure out what printer a print queue on HP-UX was driving (ortI >    supposed to be driving)?  How can such a simple piece of informatione >    become so hard to get?R  ; But, isn't that true of any poorly documented installation?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Tue, 04 Dec 2001 04:20:35 GMTl1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ) Subject: Re: tubes (was: RE: DEC is DEAD)3' Message-ID: <3C0C4F26.CE329E19@fsi.net>@   Phillip Helbig wrote:t > I > > Most (probably more than 99%) of televisions still have at least one.7L > > As do a very high percentage of computers for the very same reason.  :-) > F > One area where tubes are still preferred to transistors is in guitarI > amplifiers.  The idea here is NOT high-fidelity; the tubes and speakersdG > contribute substantially to the sound.  (Specifically, the non-lineardI > effects of the tubes when overdriven leads to a "soft" distorted sound,rH > and the typical speakers act as low-pass filters, which is why even inD > the studio the sound going into the mixing desk often comes from aH > microphone placed in front of a speaker, rather then directly from theG > amplifier or even the guitar itself (perhaps after a pre-amp), thoughyE > this is not uncommon for bass guitars, where most amps and speakerst( > contribute less to the sound quality.)  A There's a device called a "tube pre-amp" which is exactly that: awC "valve" circuit (as the Brits would say) which imparts its inherent-E "warmth" to the tone of the sound. Goes after your digital tape deck  D and mixing board or CD player and before your power amp for a really sweet playback!N  2 Makes for some rather tasty music, actually, IMHO.  F I don't get to play much anymore, and when I do play, it's mostly bassG these days. Sometimes, I still pick up the 12-string guit-box and strume+ an old familar tune just to hear the music.    *HEARTFELT SIGH*   -- p David J. Dachterat dba DJE Systemsf http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Tue, 04 Dec 2001 04:58:03 GMT0" From: Art Rice <arice@myhouse.org>) Subject: Re: tubes (was: RE: DEC is DEAD) 9 Message-ID: <vJYO7.1161$kT5.235899@dfiatx1-snr1.gtei.net>Y   Phillip Helbig wrote:a  H >> Most (probably more than 99%) of televisions still have at least one.K >> As do a very high percentage of computers for the very same reason.  :-)  > F > One area where tubes are still preferred to transistors is in guitarI > amplifiers.  The idea here is NOT high-fidelity; the tubes and speakerscG > contribute substantially to the sound.  (Specifically, the non-linearoI > effects of the tubes when overdriven leads to a "soft" distorted sound,fH > and the typical speakers act as low-pass filters, which is why even inD > the studio the sound going into the mixing desk often comes from aH > microphone placed in front of a speaker, rather then directly from theG > amplifier or even the guitar itself (perhaps after a pre-amp), thoughcE > this is not uncommon for bass guitars, where most amps and speakersg( > contribute less to the sound quality.) > I You read my mind.  That was my initial thought in my response.  NOT CRTs.e   -- g Art Rice, Tandem Admin Special Data Processing Corp ----------------------------L All opinions are my own and do not reflect the views of the above mentioned 	 employer.    ------------------------------  # Date: Tue, 04 Dec 2001 05:02:05 GMTa" From: Art Rice <arice@myhouse.org>) Subject: Re: tubes (was: RE: DEC is DEAD)o9 Message-ID: <hNYO7.1168$kT5.237415@dfiatx1-snr1.gtei.net>t   David J. Dachtera wrote:   > Phillip Helbig wrote:e >> iJ >> > Most (probably more than 99%) of televisions still have at least one.I >> > As do a very high percentage of computers for the very same reason. e >> > :-) >> eG >> One area where tubes are still preferred to transistors is in guitarCJ >> amplifiers.  The idea here is NOT high-fidelity; the tubes and speakersH >> contribute substantially to the sound.  (Specifically, the non-linearJ >> effects of the tubes when overdriven leads to a "soft" distorted sound,I >> and the typical speakers act as low-pass filters, which is why even in E >> the studio the sound going into the mixing desk often comes from avI >> microphone placed in front of a speaker, rather then directly from thefH >> amplifier or even the guitar itself (perhaps after a pre-amp), thoughF >> this is not uncommon for bass guitars, where most amps and speakers) >> contribute less to the sound quality.)c > C > There's a device called a "tube pre-amp" which is exactly that: auE > "valve" circuit (as the Brits would say) which imparts its inherenthF > "warmth" to the tone of the sound. Goes after your digital tape deckF > and mixing board or CD player and before your power amp for a really > sweet playback!  > 4 > Makes for some rather tasty music, actually, IMHO. > H > I don't get to play much anymore, and when I do play, it's mostly bassI > these days. Sometimes, I still pick up the 12-string guit-box and strums- > an old familar tune just to hear the music.o >  > *HEARTFELT SIGH* >   L Antonio had no idea what he was starting.  You can't beat DEC and you can't . beat the warm glow of a Fender Twin Reverb :>)   -- A Art Rice, Tandem Admin Special Data Processing Corp ----------------------------L All opinions are my own and do not reflect the views of the above mentioned 	 employer.j   ------------------------------  % Date: Mon, 03 Dec 2001 14:24:28 -0800A* From: "Rodolfo Segleau" <segleaur@wwc.com> Subject: Webmail Serveri, Message-ID: <web-1643935@mx1.relaypoint.net>  < I know you guys are probably tired of seeing these emails on: webmail apps, but there's something that got me scratching; my head. Since I understand the MultiNet's IMAP server doesf; not create its own database (banks off of VMSMail), then anh; application such as Twig (PHP) or KBMail (Java-based) won'th% work? Does OpenVMS even support PHP? y   Cheers,      Rodolfo    ------------------------------  % Date: Mon, 03 Dec 2001 23:34:54 +0100I= From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@dummy.com>f Subject: Re: Webmail Servere) Message-ID: <3C0BFE0E.32FED94E@dummy.com>s   Hi.wD Dave Jones, who developes the OSU DECthreads based http server, have? released a pre-version of a port of PHP to the server. Below iss& one of his posts to the OSU mail-list. Best Regards Jan-Erik Sderholm.     ! *** Begin included message... ***cA I've updated http://www.er6.eng.ohio-state.edu/~jonesd/php/ so itt* contains a new kit, PHP_FOR_VMS_X02.zip.     The primary changes are:H     - This kit uses the newly released PHP 4.0.5 kit as the base instead       of 4.0.4pl1.  *     - Some bug fixes to the build process.  D     - The core shareable image is now named PHP_'version'_CORE_SHARED       to make it easier for multiple versions to coexist on the same server. D       WWWEXEC.COM was updated to use a trick to automatically searchB       www_system for the shareable if the appropriate logical name       not defined.  G     - Added a PHP_STARTUP.COM procedure to define logical names for the F       OSU server environment.  A php.ini customized for the OSU server        is included in [sapi.osu].  A     - Dynamically loaded extensions now work.  I used the sessionsF       module ([ext.session], MMS build only) for my test build becauseB       it is about the only extension that doesn't depend upon someG       other extension.  By default, PHP will use PHP_EXTENSION_DIR:.EXEeF       as the default file specification when loading extension images.G       The extension directory (by default www_root:[system.phpext]) is o&       a settable parameter in php.ini.  C     - Added preliminary HPSS-based PHP engine.  With HPSS, the samelD       process handles multiple requests for better performance.  TheE       HPSS standalone daemon (hpss_php_master) isn't quite there yet,iF       but the worker program can be run interactively making it easier       to debug the php core.  9     - Rework default file paths to use logical names, see "       php_root:[vms]aaareadme.txt.     Rodolfo Segleau wrote: > > > I know you guys are probably tired of seeing these emails on< > webmail apps, but there's something that got me scratching= > my head. Since I understand the MultiNet's IMAP server doest= > not create its own database (banks off of VMSMail), then anl= > application such as Twig (PHP) or KBMail (Java-based) won'tw& > work? Does OpenVMS even support PHP? > 	 > Cheers,l > 	 > Rodolfoi   ------------------------------  % Date: Mon, 03 Dec 2001 17:43:08 -0500n' From: Ken Robinson <kenrbnsn@rbnsn.com>c Subject: Re: Webmail ServermA Message-ID: <5.1.0.14.2.20011203174122.04b44ec0@mail.eclipse.net>   1 At 02:24 PM 12/3/01 -0800, Rodolfo Segleau wrote:e  = >I know you guys are probably tired of seeing these emails on ; >webmail apps, but there's something that got me scratching,< >my head. Since I understand the MultiNet's IMAP server does< >not create its own database (banks off of VMSMail), then an< >application such as Twig (PHP) or KBMail (Java-based) won't% >work? Does OpenVMS even support PHP?n  J Compaq has released a version of PHP that works with their version of the O Apache Web Server. Check <http://www.openvms.compaq.com/> for more information.r   Ken Robinson kenrbnsn@rbnsn.com   ------------------------------  # Date: Tue, 04 Dec 2001 03:51:39 GMTaL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") Subject: Re: Webmail Server 8 Message-ID: <00A05FBC.6348C2F2@SSRL04.SLAC.STANFORD.EDU>  > In article <web-1643935@mx1.relaypoint.net>, "Rodolfo Segleau" <segleaur@wwc.com> writes:   >e= >I know you guys are probably tired of seeing these emails onp; >webmail apps, but there's something that got me scratching < >my head. Since I understand the MultiNet's IMAP server does< >not create its own database (banks off of VMSMail), then an< >application such as Twig (PHP) or KBMail (Java-based) won't& >work? Does OpenVMS even support PHP?  >   I I'm unfamiliar with how Twig and KBMail work.   As others have mentioned,eH PHP has been ported to VMS, and so has Java.  If these applications talkI IMAP on one side and HTML on the other, then it shouldn't matter what thefI underlying message store is.  If they address the message store directly,hH then IMAP doesn't enter into the equation.  (The one gotcha about using L exclusively VMSmail message stores is that there's no such thing as a publicK folder, so you can't drop one copy of a message somewhere and have all yournH users receive it; you need to mail them each a copy.  Also, I understand; performance is worse than on the PMDF-built message store.)c  F I am aware of other sites that have webmail apps running on Unix that K talk IMAP to VMS; the ones I know about use PMDF IMAP, which can use either 1 the VMSMail message store or a PMDF-provided one.o  J If the idea is just to have a web-based interface that runs on VMS, on theJ same machine or in the same cluster as the VMSMail stores that you want toI serve, forget IMAP and use Mark Daniels' yahMAIL.  My site uses this very J happily, and I've verified it working under OSU and Apache.  (I'm willing N to believe that it works under WASD, since the same author wrote that server.)J (Dave Jones, the author of OSU, has released a set of patches called TurboL yahMAIL, which make it run faster, but we generally get adequate performance without using them.)  B Check the OpenVMS Freeware or look at wasd.vsm.co.au  for yahMAIL.   -- Alano  O ===============================================================================e0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056rM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210aO ===============================================================================a   ------------------------------   End of INFO-VAX 2001.673 ************************