/ INFO-VAX	Mon, 01 Jan 2001	Volume 2001 : Issue 2       Contents:) Alpha nonstrategy, was Re: Happy Holidays - Re: Alpha nonstrategy, was Re: Happy Holidays - Re: Alpha nonstrategy, was Re: Happy Holidays  Re: Giving up on VMS Re: Giving up on VMS Re: Happy New Years  Re: Happy New Years  Re: Happy New Years 0 Help for ORACLE v7.3 on VMS v7.1 and TCPIP v5.0A Re: New Year's Greetings@ Re: StingrayIII server <- FDDI Cisco conc.-> OpenVMS Alpha 7.1-2 VR241 monitor and S-video 
 Xsnow 1.41  F ----------------------------------------------------------------------   Date: 1 Jan 2001 07:35:56 GMT 2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)2 Subject: Alpha nonstrategy, was Re: Happy Holidays, Message-ID: <92pc0s$jnn@gap.cco.caltech.edu>  s In article <cR836.33559$1t.1492149@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:  > F >The stupid and meaningless distinction is apps availability. Once theM >StarOffice port to VMS is done, the OS might be more attractive as a desktop  >environment.     I It bears repeating that the availability of "desktop applications" (which H really just means any program not run in a client/server or compute farmE mode) is a general problem for the Alpha platform.  Compaq has yet to F reveal any coherent strategy for addressing this problem on any singleH one of the OS's it supports on this processor (let alone doing anything E about it for all of them.)  The direct and inevitable consequence of  G Compaq's not resolving this problem is that it restricts the alpha to a G tiny (albeit currently very lucrative) section of the market.  So while I AMD and Intel fight it out and achieve great economies of scale the Alpha L ships in tiny numbers and remains utterly irrelevant to 99% of all computer F users.  Being a member of the alpha users minority brings the singularI honor of having to split the chip development and manufacturing costs for H the chip among many fewer customers.  That's at least part of the reasonF Alpha modules cost in the thousands of dollars and AMD and Intel chipsE run about a factor of 10 less.  Without this software there's no mass G market for Linux/Alpha machines (which is the only real hope of gaining K some market share), and without the mass market, it's high cost all the way  for Alpha customers.  J We've often discussed here the customers' options when faced with a futureH of declining software support and rising costs.  Put simply, most of us E have to jump ship, and those that are left have to be prepared to pay H ever increasing prices to use VMS.  That's the customer's options - whatH about Compaq's, or more specifically, the VMS group's contingency plans?@ The Intel and AMD 32 bit chips will likely pass the Alpha in rawE performance in the very near future (having long since blown by it in E price/ performance).  The VMS group is sitting on a 4B$/year product. E Do they try to stick it out with the Alpha after Linux/Alpha is but a L fond memory?  Do they want to bet their future that Tru64 will be around to I help support the Alpha?  Will they be able to afford to subsidize 100% of A alpha development costs (which I suspect has often been the case  H historically) - or to fall further and further behind the performance ofG commodity CPUs if they do not?  Or do they follow the CA model and just L bleed the remaining customers dry and then phase out the product?  Can they J hang onto the lucrative datacenter customers if/when the Alpha is 2X or 3XI slower than the competition?  (Recall that the VAX went through a period   like that.)   D Ideally, from the customer perspective, Compaq would carry out some P strategy that finally finally allows the Alpha to achieve a mass market, nip theG Intel/AMD 64 bit chips in the bud, and we'd all live happily ever after F without having to change platforms.  Since Compaq doesn't seem to careG that key groups of software are entirely absent from the Alpha platform I that "rosy scenario" is not currently possible :-(.  There have been all  I sorts of technical reason's put forward for why VMS can/can't run on x86, E but what about the Intel/AMD 64 bit chips?  Could it possibly be more C expensive to design a slightly modified support chip set that would K allow VMS to run on one of those than to continue design work on the Alpha? ? Would SRM/AMD or ARM/Intel cost even a fraction of the next ev? C It's likely that one of those two chips is going to succeed the x86 I as the mass market CPU.  If Compaq can't mass market the Alpha, can it at F least salvage the VMS market by migrating the OS to one of those otherG CPUs, produced by a company that does understand the CPU business?  The K move from VAX->Alpha was tricky because of 32->64 bit issues. The move from H Alpha->other 64 bit chip should not be nearly as difficult. At least notK technically.  But then, it was never technical problems that restricted the " success of the Alpha - or of VMS.    Sigh.    David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  % Date: Mon, 01 Jan 2001 08:07:49 -0800 , From: Jack Patteeuw <jjpatteeuw@voyager.net>6 Subject: Re: Alpha nonstrategy, was Re: Happy Holidays7 Message-ID: <3a5080ac$0$36809$272ea4a1@news.execpc.com>    David Mathog wrote:  >  <snip> > L > We've often discussed here the customers' options when faced with a futureI > of declining software support and rising costs.  Put simply, most of us G > have to jump ship, and those that are left have to be prepared to pay $ > ever increasing prices to use VMS.  M The same thing is happening in the Tru64 world.  We have one 3rd party vendor J who has repeatedly tried to get us to change to Solaris and has raised hisK maintenance price for his product on Tru64 100% in 2 years !!  Some vendors P won't port their products to Tru64 at all and other ship their Tru64 ports 3 - 6K months after Solaris. It's a good thing so many Australian universities run  Tru64.   <snip>1 > The VMS group is sitting on a 4B$/year product. G > Do they try to stick it out with the Alpha after Linux/Alpha is but a M > fond memory?  Do they want to bet their future that Tru64 will be around to  > help support the Alpha?     N While VMS may be bringing in the most dollars ('... while visions of WildfiresL danced in their heads ...") I suspect that the unit volume award is going to Linux.   <snip>
 > Can theyL > hang onto the lucrative datacenter customers if/when the Alpha is 2X or 3XJ > slower than the competition?  (Recall that the VAX went through a period
 > like that.)      EV8 is out "Great White Hope"   K Having been a loyal Digital customer for over 20 years (DEC 10, DEC 20, all J sorts of VAXen and almost as many Alphas, TOPS10/20 VMS 3.x-todate, OSF/1,J Digital Unix Tru64) I feel the same pain.  The reasons I keep recommendingO (defending !!!) Digital products (yes, I said the "D" word twice !!) is because P I believe they provide the best price/perfomance both in computation and uptime.      
 Jack Patteeuw    ------------------------------  # Date: Mon, 01 Jan 2001 17:47:00 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>6 Subject: Re: Alpha nonstrategy, was Re: Happy Holidays< Message-ID: <oo346.35612$1t.1793320@typhoon.ne.mediaone.net>  ? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message & news:92pc0s$jnn@gap.cco.caltech.edu...H > In article <cR836.33559$1t.1492149@typhoon.ne.mediaone.net>, "Terry C., Shannon" <terryshannon@mediaone.net> writes: > > H > >The stupid and meaningless distinction is apps availability. Once theG > >StarOffice port to VMS is done, the OS might be more attractive as a  desktop  > >environment.  >  > K > It bears repeating that the availability of "desktop applications" (which J > really just means any program not run in a client/server or compute farmG > mode) is a general problem for the Alpha platform.  Compaq has yet to H > reveal any coherent strategy for addressing this problem on any singleI > one of the OS's it supports on this processor (let alone doing anything F > about it for all of them.)  The direct and inevitable consequence ofI > Compaq's not resolving this problem is that it restricts the alpha to a ? > tiny (albeit currently very lucrative) section of the market.   L Yep. And given the massive cost of porting the aforementioned apps to Alpha,) this restriction isn't likely to go away.    ------------------------------  % Date: Mon, 01 Jan 2001 14:17:45 +0100   From: Paul Sture <paul@sture.ch> Subject: Re: Giving up on VMS + Message-ID: <VA.00000200.20d1fb7d@sture.ch>    In article  D <910612C07BCAD1119AF40000F86AF0D805284B6E@kaoexc3.kao.cpqcorp.net>,  Kerry Main wrote:    > Paul,  > B > Being a bit of a pack rat, I have kept a few pointers to some of > those old  > references you mentioned.  > ( > Check out these from Mark Russinovich:G > <http://www.winntmag.com/Articles/Index.cfm?IssueID=22&ArticleID=302> ( > <http://www.sysinternals.com/publ.htm> >  Thanks for that.  F Changing subject slightly, but still on topic, I found an interesting : article the other day discussing recovery on unix systems.  / From http://www.daemonnews.org/200012/tram.html   G "Today, if your power supply fails, your computer may take a long time  ? to fsck. What if that computer is the computer holding the main G database for your website? What if that is a large database on a large  7 200 gigabyte raid? Clearly, this is a problem, and more F people would probably pay to have this solved, if it was inexpensive. = However, the solutions have generally been expensive, so most G people opt for the default 'fault-tolerance' that unix provides. Other  ? possible solutions were Journaled Meta Data filesystems such as E the ones in AIX, IRIX, and a few others. These filesystems are still  F not in most free unix's and definitely not in a production state. TheyF require major architectural changes to an OS to support them and they , still have serious write throughput issues."* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  G So in spite of the complaints made in the past by folks here about the  E poor I/O performance of VMS vs Linux, that performance advantage can  G have a significant cost elsewhere, or you can go the (expensive) route  8 of other systems which also have poor write performance.  B With the recent announcements from OpenVMS Engineering of work to G improve caching and I/O performance I am hoping that we should be able  ! to enjoy the best of both worlds.   C The rest of the article makes interesting reading, with the author   outlining his own solution.   E Wishing you all a Happy New Year, and indeed, a Happy New Millennium   :-)  >  >  > -----Original Message-----) > From: Paul Sture [mailto:paul@sture.ch] ! > Sent: December 31, 2000 4:16 AM  > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: Giving up on VMS  >  > ; > In article <92dca5$7or$1@pyrite.mv.net>, Bill Todd wrote: + > > From: "Bill Todd" <billtodd@foo.mv.com>  > > Newsgroups: comp.os.vms ! > > Subject: Re: Giving up on VMS ) > > Date: Wed, 27 Dec 2000 13:30:17 -0500  > >  > > 9 > > Arne Vajhj <arne.vajhoej@gtech.com> wrote in message ' > > news:3A4A0484.B04D9C95@gtech.com...  > >  > > .... > > A > > > NT and VMS has no similarities for application programmers.  > > B > > Incorrect.  NT has significantly more 'cultural compatibility'
 > with VMS> > > than, say, a Unix does - e.g., things like event flags and > asynchronous > fileE > > I/O (the list is a lot longer, but I'm kind of busy today).  As a 	 > result,  > NTF > > has been relatively easy for me to approach when I've had to write > user-mode 3 > > code for it (kernel code too, for that matter).  > > @ > I agree. I'm reminded of an article in one of the NT magazines > about memory  6 > management (circa mid 1997), in which so much of the > terminology came > straight  : > from the VMS manuals. I felt I could have given a course > on the subject > after  > reading that...  > C > Again, in user mode programming (mainly command line utilities) I  > often  > found > > myself thinking "What would I call in VMS to do that?", then > search for an 3 > appropriately named routine, and hey presto, that  > routine had the same  # > parameters as its VMS equivalent.  > ? > Of course, none of the routine names were the same, and extra  > functionality 3 > was incorporated where appropriate (e.g. threaded  > processes), but writing  > the 8 > equivalent of something like SHOW SYSTEM was easy if I > "thought VMS". >    ___ 
 Paul Sture Switzerland    ------------------------------  $ Date: Mon, 1 Jan 2001 13:33:22 -0500' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: Giving up on VMS ( Message-ID: <92qibd$jcg$1@pyrite.mv.net>  + Paul Sture <paul@sture.ch> wrote in message % news:VA.00000200.20d1fb7d@sture.ch...    ...   G > Changing subject slightly, but still on topic, I found an interesting < > article the other day discussing recovery on unix systems. > 1 > From http://www.daemonnews.org/200012/tram.html  > H > "Today, if your power supply fails, your computer may take a long timeA > to fsck. What if that computer is the computer holding the main H > database for your website? What if that is a large database on a large9 > 200 gigabyte raid? Clearly, this is a problem, and more G > people would probably pay to have this solved, if it was inexpensive. ? > However, the solutions have generally been expensive, so most H > people opt for the default 'fault-tolerance' that unix provides. OtherA > possible solutions were Journaled Meta Data filesystems such as F > the ones in AIX, IRIX, and a few others. These filesystems are stillH > not in most free unix's and definitely not in a production state. TheyG > require major architectural changes to an OS to support them and they . > still have serious write throughput issues.", > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > H > So in spite of the complaints made in the past by folks here about theF > poor I/O performance of VMS vs Linux, that performance advantage canH > have a significant cost elsewhere, or you can go the (expensive) route: > of other systems which also have poor write performance.  A I think you may have misunderstood the context:  the 'poor' write F performance is when compared to ext2fs on Linux, a very fast-and-looseL approach.  Those safer systems (that avoid the need for fsck) can still look@ good compared with VMS, since with a well-designed log-protectedL implementation (I'm not privy to the internals of these products, but IRIX'sK XFS seems very well-thought-of in this regard and indeed enjoys an enviable F reputation for performance, including write performance) only a singleH synchronous log-disk write is required to attain all the safety of VMS'sH approach with in many cases significantly less operation latency (thoughH additional 'lazy' writes will eventually occur, with luck when the disksK aren't otherwise busy and with at least the hope of coalescing many updates % to the same pages into a single one).    > C > With the recent announcements from OpenVMS Engineering of work to H > improve caching and I/O performance I am hoping that we should be able# > to enjoy the best of both worlds.   I Nope:  that would take a real log-protected approach on VMS as well.  But I it'll be an improvement over the current state.  Of course, Linux is also E moving ahead:  it already has reiserfs, which IIRC is a log-protected J implementation, SGI has open-sourced its XFS code and should have it fullyK ported soon (at least one beta has been available for some time), and Peter G Braam (whether still in cooperation with Stephen Tweedie or not I don't L know) is creating another new file system which I think is log-protected and clusterable to boot.   - bill   ------------------------------  % Date: Mon, 01 Jan 2001 12:34:53 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: Happy New Years, Message-ID: <3A50BFB8.77403E6C@videotron.ca>  
 Koloth wrote: I > The weather forecast is 70 degrees ABOVE zero.  Any thoughts of openingu' > a branch of OpenVMS development here.w  8 Sorry, that is a bit hot.  30 more degrees and you boil.  9 (remember, the internet is global in nature, SI rules...)e   ------------------------------  % Date: Mon, 01 Jan 2001 11:54:01 -0600e7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>M Subject: Re: Happy New Years- Message-ID: <3A50C439.98268183@earthlink.net>D  
 Koloth wrote:O > ! > Happy New Years from San Diego!- > I > The weather forecast is 70 degrees ABOVE zero.  Any thoughts of opening-' > a branch of OpenVMS development here. I > I would love to work on OpenVMS but I like the weather here too much ton > move.   B I'd never thought of location as an issue. Linux is developed by aF world-wide network of folks. Even the crackers are a truly "world wide web".n  D I guess the "hard part" is finding folks who will work with you (for commercial gain) on such basis.    -- e David J. Dachterat dba DJE Systemse http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/p  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.p   ------------------------------  % Date: Mon, 01 Jan 2001 12:14:17 -0600m7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>n Subject: Re: Happy New Years- Message-ID: <3A50C8F9.BAA44EE8@earthlink.net>c   JF Mezei wrote:t >  > Koloth wrote:aK > > The weather forecast is 70 degrees ABOVE zero.  Any thoughts of openingc) > > a branch of OpenVMS development here.e > : > Sorry, that is a bit hot.  30 more degrees and you boil. > ; > (remember, the internet is global in nature, SI rules...)f  D By that measure, the weather (OAT - Outside Air Temperature) here inH metro Chicago has been consistently below zero (C) since early-December.A Consecutive snow-free days have been few and far between: there's H currently some 20+ inches (anyone have a metric conversion table handy?)> on the ground, with banks along the driveway from snow removalH approaching 50 inches. Current short-range forecasts indicate that there3 is no relief coming anytime in the next week or so.s   -- e David J. Dachterai dba DJE Systemst http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/    ------------------------------  + Date: Mon, 01 Jan 2001 12:04:20 -0600 (CST)t From: JBUTLER@utmem.eduh9 Subject: Help for ORACLE v7.3 on VMS v7.1 and TCPIP v5.0Ao1 Message-ID: <01JYE4RXC48290MW8K@UTMEM1.UTMEM.EDU>l  C 	I have OpenVMS v7.1 Alpha and ORACLE v7.3.2 and was using UCX v4.2vL with ECOs.  I upgraded to TCPIP v5.0A ECO1 and the ORACLE Listener no longerH works.  It seems to start up and you can successfully telnet to the port2 being used, but the SQLNET connection gives error.> 	Does anyone have experience with this?  Do you have any hints( for why the version of TCP would matter? 			Thanks, Jenny Butler  			JBUTLER@UTMEM.EDU   ------------------------------  % Date: Mon, 01 Jan 2001 01:32:45 -0800a# From: Mark Tarka <markZERO@mcn.net> ! Subject: Re: New Year's Greetingsd# Message-ID: <3A504EBD.6ACC@mcn.net>    David J. Dachtera wrote:	 [snip...]hH > This same "convention", apparently, dictates that OpenVMS has, for allC > practical intents and purposes, been relegated to the scrap pile.   7 As far as a popular os goes, don't you mean?  Surely it 6 will remain viable as a foundation system for critical' applications...or is Linux taking over?a   H > So, we'll all be less productive from this point forward and will loseH > much sleep thanx to viruses, blue screens and what-have-you. Though weE > be separated, we'll always be joined by our common experiences withf
 > OpenVMS.	 [snip...]n  9 "Dumbing down" is probably the appropriate concept, here.n> You all for the most part will likely have to survive by using8 a more broadly accepted os.  Enjoy the chaos :-) :-) :-)  2 I just popped in to see what was happening...a lot0 of pessimism here, or did I just pick too narrow2 a window of the overall discussion?  As usual, I'm probably clueless.  ( Cheers, holiday greetings, and all that.       Mark  (Carl who? :-)   ------------------------------  # Date: Mon, 01 Jan 2001 18:44:36 GMT 4 From: "Peter Ljungberg" <peter.p.ljungberg@telia.se>I Subject: Re: StingrayIII server <- FDDI Cisco conc.-> OpenVMS Alpha 7.1-2a3 Message-ID: <oe446.2492$AH6.388449@newsc.telia.net>   G David, you were right, the Cisco FDDI concentrator does NOT pass DECNeto through,H so I assume that no SCS or MSCP messages are passed along either, tested
 this today   Thank you for the hint!i   /P.Ljl  B "David J. Dachtera" <djesys.nospam@earthlink.net> wrote in message' news:3A4E6D10.ECEE829A@earthlink.net...o > Peter Ljungberg wrote: > >a > > Hi,h > >qJ > > This beats me at the moment, I'm trying to get a VMS host (UCX) to see FDDI > > based diskK > > behind a Stingray III server. The Alpha is clustered, with it self, LAN  is > > enabled (NI) asVJ > > interconnect, I have access to a VAX6000 using a similar configuration but* > > with TCPWAREK > > as tcp/ip.  Open for any clue's at the moment since I can't find why it7 not0 > > or why it should work, > > it looks like this now.c > >:D > > | disks | <- SCSI -> | Stingray III | <- FDDI -> | Cisco Conc. | <-FDDI-> <-n > > OpenVMS Alpha -> > >aL > > I have verified that the FDDI works on the VMS host by doing a telnet to
 > > it's FDDIwK > > interface ip-adress, do a $ DIR command through the systemdisk and thenm > > pulling the cableuD > > and the output stops, then I put back the fibre cable and output
 continues,I > > and on the Stingray side I can see a led lights up when the server ise4 > > started or cable pulled/inserted, and it do have > > two connectionsa > G > Well, at first glance you appear to be greatly confused about SCS andyJ > MSCP transports. Neither is dependent upon TCP/IP or any other transportG > - they are entirely independent. On the other hand, they are also DECm > proprietary and non-routable.  >6C > The Cisco device *MUST* be set to transparently pass SCS and MSCPoE > messages. If the Alpha doesn't see the disk in console mode, it's a : > better than even bet that OpenVMS won't see them either. >bF > I've seen this work with a DEC Gigaswitch and MTI StingRays, but not > with any other hardware. > 	 > FWIW...W >f > -- > David J. Dachtera  > dba DJE Systemst > http://www.djesys.com/ >n< > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/p >iH > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. >.B > Feel free to exercise your rights of free speech and expression. >uH > However, attacks against individual posters, or groups of posters, are > strongly discouraged.    ------------------------------  % Date: Mon, 01 Jan 2001 13:32:46 -0500o- From: JF Mezei <jfmezei.spamnot@videotron.ca> " Subject: VR241 monitor and S-video, Message-ID: <3A50CD4D.33DCED86@videotron.ca>   Ok, not quite VMS related...  M I have a VR241 colour monitor (from a VT-241 terminal) that sits there unused M and in perfect condition. I have NTSC composite and S-video from my macintoshm. (for video input/output, not for the monitor).  K Is it worth looking for the pin-outs of S-video to see if it has stuff likeeN synch, R G and B signals that would work with such a monitor, or is that truly a hopeless case ?t   ------------------------------   Date: 1 Jan 2001 14:18:55 +0100nO From: pmoreau@dev.ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.64.40)  Subject: Xsnow 1.41n  Message-ID: <3VOh56jblLMs@sable>   Hi all, and Happy New Year.s  L Xsnow 1.41 (the December 2000 version with enhanced Santa) is now available $ from the DECWindows archive at urls:   http://decwarch.free.fr/  ' http://www.multimania.com/pmoreau/decw/a  
 Best Regards,i   Patricko --O ===============================================================================tO pmoreau@cena.dgac.fr  (CENA)     ______      ___   _           (Patrick MOREAU)n4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================    ------------------------------   End of INFO-VAX 2001.002 ************************