1 INFO-VAX	Sun, 19 Aug 2001	Volume 2001 : Issue 459       Contents:8 Re: Can't compile sourcecode that import from a JAR-fileE Re: Compaq destroys Storageworks (was Re: 7.3 system disk corruption) ! Re: Essential Web Services Summit  I have an opportunity for you  Re: Internal Raid on DS20E? N Re: OT:  Yugo -- was You Get What You Pay For, a.k.a., There's No Free   LunchN Re: OT:  Yugo -- was You Get What You Pay For, a.k.a., There's No Free   LunchN Re: OT:  Yugo -- was You Get What You Pay For, a.k.a., There's No Free   Lunch# Re: OT: TOPS-20 and TOPS-10 live on $ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64$ Re: Terry Shannon Tech Talk on Tru64 Re: The Final Knell Has Sounded  Re: The Final Knell Has Sounded  Re: The Final Knell Has Sounded 
 tpcip upgrade  VLC keyboard connector pinouts?  Re: What system-call to use   F ----------------------------------------------------------------------  % Date: Sat, 18 Aug 2001 20:39:49 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> A Subject: Re: Can't compile sourcecode that import from a JAR-file ) Message-ID: <3B7EB675.54D5FF50@gtech.com>   6 Nice to see someone doing Java on VMS ! I like that !!  0 1)  Do not use JDK 1.1.8 - use 1.2.2 (or 1.3.x).8 2)  Do not use the CLASSPATH logical - use the classpath!     specifier for javac and java.    So:   1 $ javac -classpath xerces.jar parse_test_dom.java / $ java -classpath .:xerces.jar "Parse_test_dom"   . I would be very surprise if that did not work.   Arne  E PS: Underscores are not in fashion among Java programmers (most would      have used ParseTestDOM).     Mats Bjornlund wrote:  >  > Hey everybody,F > when I compile my java-file parse_test_dom.java that import from the' > xerces.jar I get the following error:  >  > [****  > AXP AF 092%> show def  >   DISK1:<USER.BJORNLUND>( > AXP AF 092%> javac parse_test_dom.javaD > parse_test_dom.java:9: Class javax.xml.parsers.DocumentBuilder not > found in impo  > rt. + > import javax.xml.parsers.DocumentBuilder; 
 >        ^H > parse_test_dom.java:10: Class javax.xml.parsers.DocumentBuilderFactory > not found 
 >  in import. 2 > import javax.xml.parsers.DocumentBuilderFactory;
 >        ^ > ...  > ****]  > ; > My own written file (parse_test_dom.java) look like this:  >  > [**** ' > AXP AF 092%> type parse_test_dom.java  > /* > Made By: Bjornlund > Date: 2001-08-14
 > Version: >  >         1  > .0 Bjornlund - First Version > */ >  > import java.io.IOException; + > import javax.xml.parsers.DocumentBuilder; 2 > import javax.xml.parsers.DocumentBuilderFactory;5 > import javax.xml.parsers.FactoryConfigurationError; 8 > import javax.xml.parsers.ParserConfigurationException; > import org.w3c.dom.Document;" > import org.xml.sax.SAXException; >  > //...  >  > public class Parse_test_dom { + > public static void main(String [] args) { A > String xmlFile = "file:///xerces-2_0_0_beta/data/personal.xml";  > try { % >    DocumentBuilderFactory factory = ' > DocumentBuilderFactory.newInstance(); < >    DocumentBuilder builder = factory.newDocumentBuilder();0 >    Document document = builder.parse(xmlFile);) > } catch (FactoryConfigurationError e) { D >    System.out.println("Unable to get a Documant Builder Factory");, > } catch (ParserConfigurationException e) {: >    System.out.println("Parser unable to be configured"); > } catch (SAXException e) {) >    System.out.println("Parsing Error");  > } catch (IOException e) { ) >    System.out.println("I/O Exception");  > }  > }} > AXP AF 092%> > ****]  >  > The CLASSPATH is set to: >  > [**** & > AXP AF 092%> show log JAVA$CLASSPATH: >    "JAVA$CLASSPATH" = "DISK1:<USER.BJORNLUND>XERCES.JAR" > (LNM$PROCESS_TABLE)  > AXP AF 092%> > ****]  > G > If I check what xerces.jar contains, then it holds among other things  > the following files: >  > [****   > AXP AF 092%> jar tf xerces.jar > META-INF/  > META-INF/MANIFEST.MF > javax/ > javax/xml/ > javax/xml/parsers/ > org/ > .... > javax/Makefile > javax/xml/Makefile) > javax/xml/parsers/DocumentBuilder.class 0 > javax/xml/parsers/DocumentBuilderFactory.class3 > javax/xml/parsers/FactoryConfigurationError.class  > javax/xml/parsers/Makefile  > javax/xml/parsers/package.html6 > javax/xml/parsers/ParserConfigurationException.class# > javax/xml/parsers/SAXParser.class * > javax/xml/parsers/SAXParserFactory.class > ...  > ****]  > > > The files parse_test_dom.java and xerces.jar are in the same& > directory, "DISK1:<USER.BJORNLUND>". > @ > What do I need to do to be able to use the files stored in theF > xerces.jar file. This is the first time I use jar- files. Can anyone" > see what I have done wrong here. > H > Can anyone help me ? I have tried to read from forums and also manuals  > but can't find any help there. >  > Thanks in Advance  > MB   ------------------------------  % Date: Sun, 19 Aug 2001 00:34:27 +0100 , From: "Simon Dodsley" <simon@sdinfotech.com>N Subject: Re: Compaq destroys Storageworks (was Re: 7.3 system disk corruption): Message-ID: <3b7efb56_1@mk-nntp-1.news.uk.worldonline.com>  * Yeah, we all want to upgrade to HSG80's !!  E That wonderful bit of kit that, currently, can only have its firmware I upgraded by shutting down every system connected to it.  What a wonderful G way to keep your Wildfires running on 24x7 - Sorry Mr Business Critical D Customer, your 24x7 solution you paid an arm and a leg for has to beL shutdown to upgrade the disk arrays. What's that you say, can't you do it onG the fly like the old controllers? No, sorry, not yet, Compaq screwed up  again...    2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:k7p2mt8nvji1g5bi8ok9rnh60k6e3ojth9@4ax.com...3 > On Fri, 27 Jul 2001 13:28:25 +0100, "Tim Jackson"   > <tim.jackson@amsjv.com> wrote: > - > >Yes, we have been making backups as we go!  > > B > >As for the configuration, there are two points we are currently > >investigating: H > >               1.  HSZ22 controllers don't appear to be listed in the+ > >OpenVMS Cluster Configuration Guidelines G > >                    manual, although the HSZ22 manuals themselves do ) > >talk about multi-host and VMSclusters.  > G > You might be interested to know that the RA3000/HSZ22 is on a list of F > controllers now being retired even though it is A CURRENTLY SHIPPING > PRODUCT!!!!!! ? > http://www.compaq.com/products/storageworks/RA3000/index.html  >   > Compaq have gone f**king nuts. > G > I have just received a letter from Compaq which states "we have begun @ > a retirement process for the distribution and services for the3 > software of the following storage hardware items:  > G > HS1CP, HSD30, HSD50, HSJ30, HSJ40, HSJ50, HSZ40, HSZ50, HSZ70, RA410,  > RA450, RA3000 with HSZ22." > F > Software support ends on 30-JAN-2002 except for some limited configs; > of the RA3000 which will be supported until 31-July-2003.  > G > "As a result of this retirement, Compaq SOFTWARE Services (ie license B > subscription, software update distribution services and softwareG > telephone support) will no longer be available for the above items as E > of 30th Jan 2002. Note hardware maintenance continues for the above # > items (but for how long - Alan)."  > C > It then adds the suggested upgrade for RA3000 (as the poster I am G > following up to has) "RA3000 with HSZ22 migrate to HSG80"  Yeh right!  > F > So if you hit a data corruption type software bug you wall not get aF > fix although they will continue to maintain the hardware for a whileH > longer. Corporate policy would not permit me to continue to use any ofG > these controllers without full software support. Luckily our critical G > production cluster is dual HSZ80 based but we were actually quoted an F > HSZ70 based system just two years ago. If we had taken that option IH > would today be forced to perform an unbudgeted upgrade to HSG80 by the > end of January.  > E > Compaq's suggested solution is to upgrade to an HSG80. So Compaq is F > now decimating its highly profitable storage division and destroying; > customer confidence. Compaq's management are incompetent, B > business-blind, moronic, creeps and I just wish VMS was owned by; > someone else so I never had to deal with them ever again.  > E > The letter is signed Trish Sandys (Compaq UK)  and provides a handy F > call number for customers to phone to upgrade to an HSG80. They'd be, > better off just giving Sun's phone number. >  > -- > Alan   ------------------------------  % Date: Sat, 18 Aug 2001 19:56:20 +0200 = From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> * Subject: Re: Essential Web Services Summit) Message-ID: <3B7EAC44.B8FD052D@gtech.com>    Brian Tillman wrote:A > >                                    Come hear instructors from @ > >DevelopMentor cover three equally important technologies: theF > >Common Language Runtime, Web Services and IntelR VTune? Performance; > >Analyzer. The Common Language Runtime provides a secure, B > >type-oriented runtime environment for components written in any > >language. > J > Over and over again, Digital's and, now, Compaq's competitors have givenM > them so many opportunities to play up the strengths of their products, like N > OpenVMS, whose run time interface has been language-independent from Day OneK > twenty-odd years ago, and they fail to capitalize on those opportunities.  > Sad.  F The MS .NET CLR basicly solves the same problem that Digital solved 25 years G ago: multiple preferred languages (with .NET MS add C# to VB and VC++).   E But you should go and hear it ! Because even though it basicly solves @ the same problem, then the solution is Java/JVM inspired not VMSE inspired. And even though I am not a big MS fan, then I must say that ) it is also a much more advanced solution.   A The VMS solution is 1 .OLB plus several .H/.INC/.PEN one for each 	 language. ) It was a very good solution for its days.   ? But times has changed and programming has switched from classic 2 procedural languages to object oriented languages.  A The .NET CLR let compilers compile sourec code to an intermediate A language (a bit like Java compilers generating .class files). The = CLR translates this intermediate code to real executable code < on the fly (it caches the output for future usage). This has some advantages:A   - it is possible to inherit between languages (you can extend a *     class written in VC++ in your C# code)B   - all the information about types are in the binary intermediate/     code making it easy to keep things in synch B Not a bad idea. If ISV's has decided to write C/C++/Fortran/Pascal@ compilers that generated .class files, then they would be in the? same position. As it is then I think GNAT (GNU Ada) is the only 5 non-Java compiler capable of generating .class files.   0 They also thrown in a few other features in CLR:@   - Garbage Collection (Vb and C#, optional i VC++). Evil people@     would say that MS has given up on removing memory leaks from;     their code and has decided to go for Garbage Collection ;   - it supports multiple versions of the same "DLL" running      at the same time  . [info based on reading a book - not by trying]  . So CLR is not the same as the VMS RTL concept.   Arne   ------------------------------  # Date: Sun, 19 Aug 2001 03:41:27 GMT  From: bvozzp@zwallet.com& Subject: I have an opportunity for you: Message-ID: <HzGf7.74371$Ii6.1061070@wagner.videotron.net>  3 For more information about this opportunity, please L send a blank email to this email adress mailto:free_bizopp@getresponse.com. 6 It will be sent automatically to you in a fiew seconds   ------------------------------  % Date: Sat, 18 Aug 2001 15:37:45 -0400 9 From: "D.B. Turner, islandco.com" <dbturner@islandco.com> $ Subject: Re: Internal Raid on DS20E?/ Message-ID: <tntgi5193fnq0f@news.supernews.com>   + Supported - maybe not - but it works fine !   8 We use a 3 Channel KZPAC-CA in a DS20e 6/500 for testing   (We also sell them)    David    -- David Turner   We sell Alpha's & Alpha Parts  http://www.islandco.com  sales@islandco.com Island Computers US Corp.  2700 Gregory Street  Savannah GA 31404  Tel: 912 447 6622  Fax: 912 201 0096   @ Graham Harrison <graham@the-shades.demon.co.uk> wrote in message7 news:ed1713eb.0108180625.5ebf7544@posting.google.com...  > Hi,  > < > As the KZPAC-AA is not a supported option for use with the9 > DS20E's drive cage and disks, is there anyway of having = > Internal Raid - without using the SW-RAID5 software driver?  > = > I was told by Compaq sometime ago that there was a new raid @ > card coming out, and they even sent a snippet from the manual.A > But as far as I can tell the new card (can't remember the code)   > is only suppoted under Tru 64. > 	 > Cheers,  > Graham   ------------------------------  + Date: Sat, 18 Aug 2001 16:30:45 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>W Subject: Re: OT:  Yugo -- was You Get What You Pay For, a.k.a., There's No Free   Lunch @ Message-ID: <20010818233045.99376.qmail@web20201.mail.yahoo.com>  
 Very ugly ...    Click at  0 http://orbita.starmedia.com/~matuta011/fotos.htm  / this is the brazilian "Fiat 147". Do you know ?    Regards    FC  . --- Jerry Leslie <leslie@clio.rice.edu> wrote:1 > Fabio Cardoso (fabiopenvms@yahoo.com.br) wrote:  > : I am new in this:  > :  > : What is/was Yugo ? > : 0 > : I had a Serbian girlfriend a long time ago ! > 4 > A poorly-made clone of a Fiat, made in Yugoslavia. > Here's a picture  % > of one along with more information:  >  >    > = http://www.highway-one.com/Classifieds/Yugo/GreenYugoCab.html  >   1990 Yugo Cabrio >  > --Jerry Leslie    2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/    ------------------------------  + Date: Sat, 18 Aug 2001 16:30:42 -0700 (PDT) . From: Fabio Cardoso <fabiopenvms@yahoo.com.br>W Subject: Re: OT:  Yugo -- was You Get What You Pay For, a.k.a., There's No Free   Lunch @ Message-ID: <20010818233042.15160.qmail@web20210.mail.yahoo.com>  
 Very ugly ...    Click at  0 http://orbita.starmedia.com/~matuta011/fotos.htm  / this is the brazilian "Fiat 147". Do you know ?    Regards    FC  . --- Jerry Leslie <leslie@clio.rice.edu> wrote:1 > Fabio Cardoso (fabiopenvms@yahoo.com.br) wrote:  > : I am new in this:  > :  > : What is/was Yugo ? > : 0 > : I had a Serbian girlfriend a long time ago ! > 4 > A poorly-made clone of a Fiat, made in Yugoslavia. > Here's a picture  % > of one along with more information:  >  >    > = http://www.highway-one.com/Classifieds/Yugo/GreenYugoCab.html  >   1990 Yugo Cabrio >  > --Jerry Leslie    2 __________________________________________________ Do You Yahoo!?H Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/    ------------------------------  % Date: Sat, 18 Aug 2001 20:06:01 -0700 % From: Dean Woodward <deanw@rdrop.com> W Subject: Re: OT:  Yugo -- was You Get What You Pay For, a.k.a., There's No Free   Lunch ) Message-ID: <3B7F2D19.91DB317C@rdrop.com>    Jerry Leslie wrote:  > 1 > Fabio Cardoso (fabiopenvms@yahoo.com.br) wrote:  > >  > > What is/was Yugo ? > E > A poorly-made clone of a Fiat, made in Yugoslavia. Here's a picture % > of one along with more information:  > A >   http://www.highway-one.com/Classifieds/Yugo/GreenYugoCab.html  >   1990 Yugo Cabrio  B Oh, my.  The owner wants $20,000 USD for it- 500% of it's purchase? price ten years ago.  Either he made a good investment, or he's A got hold of some very interesting drugs.  I'm not sure which, but  I know which way I'm leaning...    ------------------------------  % Date: Sat, 18 Aug 2001 12:38:49 -0700 * From: "Jack Peacock" <peacock@simconv.com>, Subject: Re: OT: TOPS-20 and TOPS-10 live on; Message-ID: <6szf7.114$p4.4126@e420r-sjo3.usenetserver.com>   2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:f75qntgm9l6qu29ot4jefoftg6bmstetdd@4ax.com...H > I haven't done any real benchmarks but on a 500 Mhz Pentium III thingsF > look at least as fast as a real 2020 (the baby of the PDP-10 family)D > and a 2020 was around 1/5th speed of a KL10 from distant memory (IG > last used a 2020 in 1985). So the 2020 was comparable to a VAX 11/780C > (or maybe 750) >oH Though it has been quite a few years (1977), my first systems programmer= job was on a 2020.  It could handle up to 8 COBOL interactiveeG programmers working at the same time but slowed dramatically on the 9thEB programmer.  Our benchmarks on overnight batch processing of COBOLH financial apps showed it to be slightly faster than our IBM 370/138 (wasE there a 138 model?  that's the one that sticks in my decaying memory)k running VM.N  F From my strictly personal observations not founded on any kind of testG the 2020 felt faster than a 11/750 at the keyboard using COBOL, FMS and > DBMS).  DBMS on a VAX was a speed killer, more so than the 20.   Jack Peacock   ------------------------------  % Date: Sat, 18 Aug 2001 17:26:32 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>u- Subject: Re: Terry Shannon Tech Talk on Tru64-, Message-ID: <3B7EDD79.CD759673@videotron.ca>   Jeff Killeen wrote: I > Rumor has it Compaq received a very favorable reaction at the CIO leveleI > (after that is when they went public) and then Compaq found a differentmF > reaction as they started moving into the ranks of the technologists.  N If the information was presented to CIOs the same way it was presented to WallL Street, I can see how CIOs were not immediatly opposed to that move. Compaq,M as part of its 180 plan, would streamline the number of products to cut coststJ and be more competitive. And if you portray the move of VMS to IA64 as oneM which will allow VMS to run on commodity hardware, then you make it look likenN VMS will run on cheap deasktops and that appearently would be good. And if youN tell the CIOs that Alpha was already slow compared to competing chips and thatL a move to IA64 woudl make VMS run faster, then CIOs would have no choice but say good things.  N The problem is the CIOs are polite with the vendors and won't say nasty thingsV in their face. So Compaq's impressions of customers supporting its moves are a facade.  J But to those who have fought hard to try to preserve VMS at some sites seeH thos move as yeta another step in what Palmer had begun, albeit a slower better executed step.   I If there was ever a time to use the "snake oil" term , it was to describe Q Compaq's empty promises with regards to the murder of Alpha and adoption of IA64.   M The announcement was made much more to please the wall street casino analysts0N than VMS actual customers. The "180 day" program was timed to show that CompaqJ had already undertaken serous steps to cut losses, so that it looked to beD very pro-active about this as opposed to announcing such steps AFTER announcing the bad financials.  L That 180 day thing has brought nothing positive to the VMS marketplace. JustF uncertainty about VMS's future. Heck, how can you see such a move in aK positive light when it takes over a month before some engineer can actually I state that after having looked at the specs of IA64, they think they have N found a way to implement VMS's memory protection schemes into the more limited IA64 ones ?m  L You'd think that this is something they would have taken a very serious look/ at BEFORE going public on the IA64 commitment. t  M And another thing that worries me. VMS engineers have worked with Alpha since"L its inception and know it intimately. But now, they have been given a "rush"B project to port this to a totally new , unknown chip architecture.  F I do not wish to belittle the VMS engineers for whom I still hold muchJ respect, but is it reasonable to ask these engineers to start to make suchF huge architectural decisions on a chip they know little of and have no experience with ?"   ------------------------------  % Date: Sat, 18 Aug 2001 17:58:21 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>e- Subject: Re: Terry Shannon Tech Talk on Tru64g( Message-ID: <9lmodm$p41$1@pyrite.mv.net>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageI/ news:QkAf7.52$uC2.21494@typhoon1.gnilink.net...m   ...a  F > No disagreement that Compaq could have handled the announcement much better.mI > Rumor has it Compaq received a very favorable reaction at the CIO levelyI > (after that is when they went public) and then Compaq found a differentaF > reaction as they started moving into the ranks of the technologists.  A If the CIOs they talked with were as clueless technologically and D strategically as the ex-CIO currently running Compaq, that's not too surprising.s     ToomH > bad they didn't do some message testing at that level before they went > public...t  H Too bad they didn't do some better evaluation in a lot of areas and then  scrap the idiotic idea entirely.   - bill   ------------------------------  % Date: Sat, 18 Aug 2001 13:50:32 -0500I1 From: "David J. Dachtera" <djesys.nospam@fsi.net> - Subject: Re: Terry Shannon Tech Talk on Tru64 ' Message-ID: <3B7EB8F8.CDB1A868@fsi.net>-   Jeff Killeen wrote:  > [snip]N > About the comment below.  The more one knows about the decision the more one0 > comes to see the logic of it was unavoidable.   G Let me say this here in this thread, also, to help emphasize the point:e  E The decision, at least not the entire decision, is not the issue. ThetB issue is the way it was brought to the market, and the surrounding- "decisions" that were subsequently announced.   H Compaq could have saved a spitload of face, not to mention ill will, hadH they announced plans to embrace IPF and parnter with Intel, but left theG lid on the "Alpha end of life" bit. That is to say, it should have been G handled identically to the VAX to Alpha transition. The two should have F been left to co-exist through the development and deployment stage, atE which time Alpha would have appeared inarguably redundant and the EOL2G announcement would have seemed logical and right, as opposed to the way F it was handled, which has left scores of people, some vocal here (suchC as yours truly) with serious doubts as to Compaq's trustworthiness,  truthfulness and intelligence.  C Doing it has never been the issue - the issue is *HOW* it was done.e  
 Questions?   > I also believe the decision * > likely saved VMS rather than killed it.   A That would have been true had this been handled in a more orderlyoE manner. As it is, the "death of Alpha" can only be interpreted as theeC "death of VMS". Even so, there are still those who ask me, and thiswD newsgroup, "does VAX run on Alpha?" because to them VAX was VMS, andB vice-versa - they never made the connection between the OS and theH underlying hardware as "portable" as the concept is in reality, which, I= grant you, is, as we "speak", still limited to VAX and Alpha.a  # > IMO economics would have required5; > killing it within 5 years if it stayed on the Alpha chip.,  C Well, we've been hounding them about VMS on Intel since the days of D Emerald. There never was, is not now, and never will be a law sayingC that you couldn't build an IA32 mobo that provides what "commodity"AH mobos lack but VMS needs. Had this been done as the logical evolution ofG Emerald, we would not now be having this discussion, since VMS on InteltH would have been a reality long before the merger, and IA32 -> IA64 wouldC have been a more logical transition than Alpha -> nothing - > IA64, C if/when IPF ever becomes a PRACTICAL reality. (Before you reply andn? insert comments about that "PRACTICAL reality" bit, please read  further...)    K > Talking recently with some Compaq folks they pointed out to me that AlphaiN > had two advantages - clock speed and it was 64-bit.  People tend to focus onM > the clock speed but it was also the 64-bit architecture that gave Alpha itsfI > performance advantage.   When one goes beyond clock speed one begins tosJ > understand that once well developed high volume 64-bit processors becomeL > available a major Alpha advantage goes away - even if Alpha could maintain > better clock speed.t  ? The key phrase there is "once well developed high volume 64-bitrC processors become available". As of now, they are not. IA64, in itseC present form, is experimental at best: beta, early-adopter quality,aC definitely not "ready for prime time", roughly similar to the firstt5 Alpha CPUs that were released to the market at large.o  " > [Blade related comments snipped]I > The more information someone gets the more they understand this was thenK > inevitable conclusion that one comes to when the analysis is done withoutj
 > emotion.  F Again, THAT it was done was never the issue, IMO. *HOW* it was done is" almost the entirety of the issue.   H Had Compaq been interested in avoiding an emotional response, they wouldD have taken that into consideration before pulling such a bone-headedG move as announcing Alpha's EOL before IPF chips equal in quality to theC* current Alpha chips become available, IMO.  C >  Bob the reason why Terry has been saying what he has been sayingnK > since 6/25 isn't because he is towing the company line but because he hasgK > been ahead of us on the information curve.  Once everyone who can look atm  > this issue without the emotion  A At this point, the horse is out of the barn - a little late to ber closing the doors.  ) > gets all the data they will see nothingh# > nefarious about Terry's analysis.,  F No argument on that point. The only issue I have with it is that it isF based on what you wish had happened, as opposed to what did happen and is still happening.E  LM > The only thing that stands between Compaq and success is can they pull they  > conversion off in 24 months.  G Burning your ships is one thing - blowing the damn harbor right off thet map is something else entirely.e  , > If they do few will argue that it wasn't aI > really smart move.  It they don't pull it off in 36 months IMO they didt6 > nothing to speed up the end of life of VMS anyway...  # Clearly, we disagree on that issue..  3 Of course, and as always, IMHO - YMMV considerably.s   --   David J. Dachterau dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/h   ------------------------------  # Date: Sat, 18 Aug 2001 20:36:00 GMTe& From: "Jeff Killeen" <Jeff@IDM-IO.com>- Subject: Re: Terry Shannon Tech Talk on Tru64d5 Message-ID: <QkAf7.52$uC2.21494@typhoon1.gnilink.net>e  G > The decision, at least not the entire decision, is not the issue. ThebD > issue is the way it was brought to the market, and the surrounding/ > "decisions" that were subsequently announced.   L No disagreement that Compaq could have handled the announcement much better.G Rumor has it Compaq received a very favorable reaction at the CIO level/G (after that is when they went public) and then Compaq found a different I reaction as they started moving into the ranks of the technologists.  ToocF bad they didn't do some message testing at that level before they went	 public...t  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3B7EB8F8.CDB1A868@fsi.net...M > Jeff Killeen wrote:i
 > > [snip]L > > About the comment below.  The more one knows about the decision the more oneo1 > > comes to see the logic of it was unavoidable.  >tI > Let me say this here in this thread, also, to help emphasize the point:i >oG > The decision, at least not the entire decision, is not the issue. The-D > issue is the way it was brought to the market, and the surrounding/ > "decisions" that were subsequently announced.D >HJ > Compaq could have saved a spitload of face, not to mention ill will, hadJ > they announced plans to embrace IPF and parnter with Intel, but left theI > lid on the "Alpha end of life" bit. That is to say, it should have beensI > handled identically to the VAX to Alpha transition. The two should have H > been left to co-exist through the development and deployment stage, atG > which time Alpha would have appeared inarguably redundant and the EOLsI > announcement would have seemed logical and right, as opposed to the waylH > it was handled, which has left scores of people, some vocal here (suchE > as yours truly) with serious doubts as to Compaq's trustworthiness,c  > truthfulness and intelligence. >mE > Doing it has never been the issue - the issue is *HOW* it was done.7 >2 > Questions? >0 > > I also believe the decisionh+ > > likely saved VMS rather than killed it.e >1C > That would have been true had this been handled in a more orderlyKG > manner. As it is, the "death of Alpha" can only be interpreted as theaE > "death of VMS". Even so, there are still those who ask me, and thishF > newsgroup, "does VAX run on Alpha?" because to them VAX was VMS, andD > vice-versa - they never made the connection between the OS and theJ > underlying hardware as "portable" as the concept is in reality, which, I? > grant you, is, as we "speak", still limited to VAX and Alpha.  >h% > > IMO economics would have required = > > killing it within 5 years if it stayed on the Alpha chip.s >fE > Well, we've been hounding them about VMS on Intel since the days ofuF > Emerald. There never was, is not now, and never will be a law sayingE > that you couldn't build an IA32 mobo that provides what "commodity"tJ > mobos lack but VMS needs. Had this been done as the logical evolution ofI > Emerald, we would not now be having this discussion, since VMS on InteliJ > would have been a reality long before the merger, and IA32 -> IA64 wouldE > have been a more logical transition than Alpha -> nothing - > IA64, E > if/when IPF ever becomes a PRACTICAL reality. (Before you reply and A > insert comments about that "PRACTICAL reality" bit, please readr
 > further...)  > G > > Talking recently with some Compaq folks they pointed out to me that9 Alpha G > > had two advantages - clock speed and it was 64-bit.  People tend to_ focus onK > > the clock speed but it was also the 64-bit architecture that gave Alphao itssK > > performance advantage.   When one goes beyond clock speed one begins toeL > > understand that once well developed high volume 64-bit processors becomeE > > available a major Alpha advantage goes away - even if Alpha could. maintain > > better clock speed.g >DA > The key phrase there is "once well developed high volume 64-bit E > processors become available". As of now, they are not. IA64, in its E > present form, is experimental at best: beta, early-adopter quality,-E > definitely not "ready for prime time", roughly similar to the firstv7 > Alpha CPUs that were released to the market at large.  >h$ > > [Blade related comments snipped]K > > The more information someone gets the more they understand this was the E > > inevitable conclusion that one comes to when the analysis is donei without  > > emotion. >wH > Again, THAT it was done was never the issue, IMO. *HOW* it was done is# > almost the entirety of the issue._ >_J > Had Compaq been interested in avoiding an emotional response, they wouldF > have taken that into consideration before pulling such a bone-headedI > move as announcing Alpha's EOL before IPF chips equal in quality to the6, > current Alpha chips become available, IMO. > E > >  Bob the reason why Terry has been saying what he has been saying'I > > since 6/25 isn't because he is towing the company line but because hel hasoJ > > been ahead of us on the information curve.  Once everyone who can look at" > > this issue without the emotion >fC > At this point, the horse is out of the barn - a little late to beo > closing the doors. > + > > gets all the data they will see nothingr% > > nefarious about Terry's analysis.  >hH > No argument on that point. The only issue I have with it is that it isH > based on what you wish had happened, as opposed to what did happen and > is still happening.. >'J > > The only thing that stands between Compaq and success is can they pull they  > > conversion off in 24 months. >:I > Burning your ships is one thing - blowing the damn harbor right off theT! > map is something else entirely.- > . > > If they do few will argue that it wasn't aK > > really smart move.  It they don't pull it off in 36 months IMO they didt8 > > nothing to speed up the end of life of VMS anyway... >m% > Clearly, we disagree on that issue.s > 5 > Of course, and as always, IMHO - YMMV considerably.D >0 > -- > David J. Dachteraa > dba DJE Systemsf > http://www.djesys.com/ >I* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/o   ------------------------------  % Date: Sat, 18 Aug 2001 14:06:20 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>n( Subject: Re: The Final Knell Has Sounded, Message-ID: <3B7EAE9C.9F130C79@videotron.ca>  & "Brian Schenkenberger, VAXman-" wrote:2 > >http://www.cets2001.com/cets/controller/catalog >   >     The system is experiencing! >     problems with your browser.  > < >     Either your session has become inactive or you need to= >     turn on cookies. Try logging in again or enable cookiesd= >     in your browser. For help enabling cookies, click here.   J How soon will companies learn that they overly fancy web sites are in factG turning away customers ? What is more important, knowing the customers'eK underwear colour, or giving the customer the information about the sessions.K that may convince the customer to pay real money to attend the conference ?D   ------------------------------  % Date: Sat, 18 Aug 2001 16:12:12 -0400d' From: "Bill Todd" <billtodd@foo.mv.com>e( Subject: Re: The Final Knell Has Sounded( Message-ID: <9lmi6j$lhe$1@pyrite.mv.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B7EADD6.34D64938@videotron.ca... > John Wisniewski wrote:K > > and time I fully expect will be VMS.  Not because of flash or guilding,t3 but because VMS has features that are unique in thesJ > > computer marketplace that provides a level of service no other OS even comes close to...  >e > Fully agreed.s  L I agree too, except that the tense is increasingly becoming past rather thanE present.  Unix systems acquired things like optional direct access todI storage and asynchrony (albeit not always very elegant) quite a few yearsnK ago, and are now catching up in clustering as well.  And while they may notaH keep running for decades, they often do run for years without rebooting.  J Just spent some time rummaging around the white-paper section of Sun's WebH site.  They've finally got their cluster file system out (so one doesn'tG have to make do with highly-available but otherwise less-than-ideal NFStF intra-cluster access any more).  It looks a lot like Tru64's approach,G including distributed caching facilities, and seems pretty respectable. L Found documentation on fail-over times for the (old) NFS-style intra-clusterH distributed file system mechanism:  21 seconds for a planned switch of aJ single filesystem (rising to 35 when a couple of dozen filesystems residedJ on the node), vs. 60 - 80 seconds for an unplanned (crash-style) fail-overJ (rising by another 10 - 15 seconds when dozens of filesystems exist).  TheL documentation for the new CFS (and for V3 Clustering as a whole) claims that3 fail-over is now faster, but doesn't specify times.   J And of course Linux is quickly acquiring a whole raft of features, many ofB them donated from existing commercial software.  I think I've seenJ references to a port of SGI's CXFS (the cluster version of their respectedL XFS log-protected, extent-based Unix file system that they've already portedD to Linux), and Compaq has its own porting effort of Tru64 clusteringG goodies - leaving aside the plethora of non-commercial Linux clusteringm efforts.  K Too bad the senior VMS developers will now for a significant period of timecG be mostly involved with the port rather than devoting their energies to 8 maintaining (or even extending) what lead VMS still has.   - bill   ------------------------------  % Date: Sat, 18 Aug 2001 22:14:33 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>g( Subject: Re: The Final Knell Has Sounded' Message-ID: <3B7F2F19.DE52F99A@fsi.net>l   John Wisniewski wrote: > [snip]~ > The DFWCUG has moved to new content presentations  after you consoldated all the introductory sessions into a single weekend > seminar...  G I was asked to participate in the bootcamp seminar. I had no other part ; in its planning except to collaborate with Rob Lyons on theC
 presentation.1  t > The Weekday Sessions were designed to be more advanced..  You have all the IntroVMS topics during your BOOTcamp.../ > How can you say there are no newbie Sessions?  > 8 > WHO TOLD YOU THAT NONE OF OUR SESSIONS WERE ACCEPTED..  E The same person who asked me to take part in the weekend seminar. SherG called to say it had been cancelled, along with (apparently) all of thesD newbie sessions, including DFW's and Wayne Sauer's. Per the list youE posted, her information seems to have been accurate. I was not aware,mC based on the info. available to me, that DFW had any other sessions  going.   >  HAVE YOU EVEN CHECKED > THE WEBSITE?  C Once the bootcamp was cancelled, my interest in pursuing the matter- further went to zero.   D I'm glad you guys will be there. Carry on the tradition - VMS is the best...m   -- t David J. Dachterar dba DJE Systemsa http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------    Date: 18 Aug 2001 13:11:56 -07000 From: techwebsite@netscape.net (Michael Angello) Subject: tpcip upgrade= Message-ID: <34e80f93.0108181211.29c8426f@posting.google.com>n  
 Excuse me,  E Is it possible to upgrade from TCP/IP Services V5.0 (AXP) to a higheruE version (i.e. V5.1) without upgrading the OS (currently using V7.2)?,t? and if so, how may I accomplish that task, looking what kind of  information?  C I'd like to upgrade those services because I had some problems with 
 the systemD due to It crashes sometimes due to INCONSTATE, Inconsistent I/O data base.aC I was looking for issues about it on DejaNews, and accordinf what I * read address me to upgrade such a service.  D Please, really excuse me again for such matter, but I just found theE Install docs regarinf OS and TCPIP Services, but I did not see such ad= scenery or any comments about it are appreciated in advanced.s     Thanks   Mike   ------------------------------  # Date: Sun, 19 Aug 2001 03:47:16 GMTu$ From: info@adroso.com (New VLC User)( Subject: VLC keyboard connector pinouts?: Message-ID: <3b7f362f.171350322@news.jamison1.pa.home.com>  F Does anyone know the pinouts for a VLC's keyboard connector?  Also, is it TTA0: or TTA1:?   ------------------------------  % Date: Sat, 18 Aug 2001 19:22:27 +0200h= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>n$ Subject: Re: What system-call to use) Message-ID: <3B7EA453.22D74FF2@gtech.com>h   Peter wrote:G > Does anyone have an idea about which systemcall in C I should use, to A > pinpoint one or more of the following information from a file :    Try look at:+   ftp://ftp.hhs.dk/pub/vms/misc/file_size.ci for inspiration !a   Arne   ------------------------------   End of INFO-VAX 2001.459 ************************