1 INFO-VAX	Mon, 23 Jul 2001	Volume 2001 : Issue 405       Contents:( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate Alpha:  ostriches and sheep  Re: Alpha:  ostriches and sheep  Re: Alpha:  ostriches and sheep & Re: Compaq FUD and lack of information Re: FS(UK) Alphastation 500/400 % help mounting drives 3000/300 vms 5.5 ) Re: help mounting drives 3000/300 vms 5.5 " Re: LPs on the Web (Was: Re: DCPS)" Re: LPs on the Web (Was: Re: DCPS) Re: No chance for OpenVMS  Re: No chance for OpenVMS  Re: No chance for OpenVMS 2 Reference for VMS anti-hacker credentials required$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ? Re: The PC and Software Museum, Re: VMS remains secure at DEFCON hacker fest Re: Zero Quadword Time Poll 0 Re: [Q] CXX, global variables, Shareable library  F ----------------------------------------------------------------------  # Date: Sun, 22 Jul 2001 16:54:25 GMT + From: Anne & Lynn Wheeler <lynn@garlic.com> 1 Subject: Re: Alpha:  an invitation to communicate ) Message-ID: <uu204lxcc.fsf@earthlink.net>   1 Peter Hancock <peter@premise.demon.co.uk> writes:  > E > I though VM was the underlying thing, and MVS was one of the things  > VM could host?   > H > ISTM that its not at all improbable that sometime soon we will need orC > have some kind of virtual machine technology that could allow all D > kinds of bizarre software monstrosities to run in whatever kind of4 > crazy environment they want.  Is this a platitude?  D it is possible that a lot more familiar with the resource managementF and industrial strength features of MVS ... than are familiar with the; resource management and industrial strength features of VM.    random ref: . http://www.garlic.com/~lynn/subtopic.html#disk1 http://www.garlic.com/~lynn/subtopic.html#wsclock 3 http://www.garlic.com/~lynn/subtopic.html#fairshare - http://www.garlic.com/~lynn/subtopic.html#smp / http://www.garlic.com/~lynn/subtopic.html#hacmp 2 http://www.garlic.com/~lynn/subtopic.html#360mcode   --  H Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/    ------------------------------  % Date: Sun, 22 Jul 2001 23:30:39 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B5B9A5D.CA4ADB86@videotron.ca>   Peter Hancock wrote:E > I though VM was the underlying thing, and MVS was one of the things  > VM could host?  M This was the "old way".  But MVS-only shops can run multiple instances of MVS K on a 390 or higher without the presence of VM. This saves a lot of overhead " since IO is not intercepted by VM.  L I did hear that VMS was making a comeback to run multiple instances of Linux on IBM mainframes though.    ------------------------------  % Date: Sun, 22 Jul 2001 20:56:36 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> $ Subject: Alpha:  ostriches and sheep( Message-ID: <9jfsfs$aa0$1@pyrite.mv.net>  I It seems to be time to tie together a few issues, and Robert's post below  touches on some of them.  I I'll start with a disturbing email I received yesterday, with the subject L line "You were right about Alpha".  It came from someone who had been fairlyL vigorously (and politely) suggesting (as Robert does below) that things likeL private statements from Alpha engineers and arm's-length analysis of (mostlyJ public) financial information weren't anything like a reasonable basis for= assessing Compaq's statements about Alpha's future viability.   F Specific earlier suggestions from this individual had included that weL really didn't have any indication that EV8 hadn't run into serious technicalK or schedule problems of one kind or another and/or that Alpha wouldn't have B had difficulty retaining a significant performance lead over IA64.  L Indeed, several people have advanced the thesis that because our informationL on such matters is far from perfect we really aren't justified in concludingJ *anything*.  Perhaps they were unduly influenced by the study of NewtonianI mechanics at an early age, but I suspect that it may say more about their I reluctance to believe ill of their vendor:   there's something just a tad L disingenuous about refusing to accept tangible (even if incomplete) evidenceJ on one side of an issue simply because it does not also include proof that9 evidence on the other side of that issue could not exist.   L To return to the email, it indicated that the author had just been contactedJ privately by "someone I trust deeply on knowing Alpha internals as well asG R/D futures" and was now happy to "concede that there probably isn't an I internal technical gap inside Alpha engineering w.r.t. to feasibility (as ( Dennis vaguely hinted at in comp.arch)."  G The disturbing part of the email was that it began with this statement: F "I'm keeping this private to avoid further speculation in c.o.v."  TheE author, who had been himself vigorously speculating in comp.os.vms in K defense of Compaq's position when he had no real information on the matter, L was suddenly reluctant to say anything now that he actually had something of2 substance (as least in his opinion) to contribute.  K I pointed this out to him, and he responded that his interest in the matter I had been to try to provide balance rather than to take any active side on H the issue (getting involved in such things not being his cup of tea).  IK accept that explanation and certainly respect his wish to remain anonymous, I but since he did not request confidentiality for the information provided L (nor do his reasons for not getting involved himself imply such a desire) itD seems reasonable to release it - since I believe it's significant inK multiple respects and I'd like others to have the opportunity to draw their  own conclusions about it.    Moving onward:  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in message F news:rdeininger-2207011410280001@user-2ive7ua.dialup.mindspring.com...   ...   L > I've followed most of your discussions.  I haven't seen anything blatantlyF > wrong with your numbers.  However, I think your interpretation is on > thinner ice.  L The question is, thinner than what?  It certainly appears to be considerably> thicker than the ice that Compaq's assertions are standing on.   > F > I don't recall anyone from Compaq saying that Alpha was a money pit.  H My response was to someone who did (that's why I quoted him).  And whileJ that particular phrase may not have been used by any Compaq official, it'sK certainly the impression they've been attempting to convey (as you state in G your next sentence) via those people (particularly Terry) who have been  fronting for them.   ...   K > We have seen hints, if not outright statements from Compaq, that the cost G > of funding future alpha development was a factor in the cancellation. L > Your analysis of past expenditures really doesn't, and can't, address whatE > they would have had to spend to complete EV8 as it should have been J > completed.  Maybe there were significant problems on the horizon that we > haven't heard about.  I And maybe an asteroid will strike the Alpha engineering team tomorrow, in ? which case future funding would of course turn out to have been 
 questionable.   K Aside from the points I made (and the additional input I related) above, we  have the following to guide us:   D 1.  Alpha has a 10-year development history already, and a long-termJ development plan that has emphasized a staged implementation in an orderlyL manner (i.e., without assumptions of the form "here a miracle occurs").  TheI road ahead was clearly delineated and no evidence (not even hearsay) of a  major detour has been offered.  J 2.  The 1999 annual report (page 42) projected future R&D expenditures forJ yet-unrealized technology out through 2005 at about $500 million (per yearK for all development; another later comment suggests that the largest single H contributor would have been storage, with Alpha a solid second) annuallyI through 2003 and then decreasing.  While schedule slips could have pushed K out the 'knee' in this curve, it suggests that planned funding was at least  fairly constant at that time.   K 3.  The 2000 annual report indicates (on page 17) that the development-cost L estimates had been reduced by about $100 million per year (compared with theE 1999 estimates) for the years 2001 - 2004.  This reflects either even > greater confidence in the ability to continue to develop AlphaI cost-effectively or that killing Alpha was already contemplated when that  report was issued.  5   If Compaq could not or would not commit to spending D > enought money to ensure success in the face of difficult technicalL > problems, it's quite possible that the more technical folks would start to" > seriously consider alternatives.  I If you can't produce even a hint of evidence of such 'difficult technical L problems' (beyond the admitted inherent difficulty of leading microprocessorK development, but that's been factored in all along), the preceding sentence  is nothing but hot air.   J And here is as good a place as any to confront Dennis' contention that theD VMS revenue/profit numbers I related from a year ago in defense of aD reasonable level of Alpha development expenditure were fabricated (aH contention as vacuous as the rest of his posts on the subject).  While IK have other sources for some of that information, the 'unimpeachable' source H is known to both Terry Shannon and Rob Young, both of whom can hardly beH considered to be on my side of this issue.  If one of them would like toL offer arguments against this source's credibility, I'll be happy to name himF and allow people to make their own judgement:  the information was notH accompanied by a request for anonymity, but other things being equal I'mH inclined to allow people to identify themselves if they choose to rather" than take it upon myself to do so.  L Thanks to 'billmuy' for providing the pointer to the 2000 annual report thatC doesn't seem to be available on Compaq's Web site.  It confirms the I conclusions I drew from the quarterly figures I reported previously:  the L Enterprise Computing segment lead in both percentage and total profitabilityA in 2000, even after the services portion was split out, while the I business/consumer PC side of the house contributed less than 11% to gross J income even though it accounted for about 50% of revenue.  In other words,K the Enterprise and services areas were over 8 times as profitable - in both L absolute and percentage terms - as the business/consumer PC business in 2000D (before the latter dropped into the red in 2001Q1 and made the ratio
 meaningless).   F Pages 11 - 13 make interesting reading.  They indicate that EnterpriseC Computing's 10% revenue bump over 1999 was almost completely due to K increased sales of industry-standard servers (at least when storage revenue J is ignored), but are much more coy about attributing credit for the nearlyE 80% profit increase in the same time frame, saying only that "Margins H improved due to a mix shift toward the high-end and increased enterprise	 storage."   J Combine this with the statement that "Strong growth in enterprise storage,K which consisted of external storage, software and high-end tape, was offset K by lower attached storage" and you have at least the suggestion that, while E 'industry-standard' servers may have accounted for more than half the K revenue (and all the revenue growth) when storage was *not* included, Alpha L and Tandem systems (especially if you include their associated storage) wereH generating most of the profit (which supported selling industry-standardL servers at near-cost in order to hold or gain market share - gee, where have we seen *that* before?).  5 Add in the statement that Alpha sales suffered due to J GS-introduction-related component shortages and this hardly constitutes anG indictment against Alpha's current and future profitability (rather the H reverse) - and the numbers remain consistent with the conclusions I drew  previously from the 1999 report.  E I realize that many people may not particularly enjoy plowing through G financial statements and extracting information from them - I certainly H don't.  But people who aren't willing to do so really don't have much toI base their opinions on in such matters compared with those of us who have F made that effort - and they shouldn't expect too much respect for such! comparatively unfounded opinions.   )   If your study of past financials allows C > you to predict what alpha's future costs would have been with any E > certainty, well, I guess I missed that post in the recent blizzard.   J Certainty in most things is unattainable, so people in the real world tendI to operate on the best information available (which is what I've tried to F present).  If Compaq or its apologists have released *any* informationL supporting their assertions on these questions, I haven't seen it:  it's allL been speculation similar to what you've offered above (and you even state so& explicitly in the following sentence).   > D > I don't have any facts to support this kind of scenario.  I'm justK > pointing out that your analyses (which have started to get rather shrill, I > btw) do not exhaust all the possibilities.  You seem to want to put the K > worst possible face on Compaq's actions _and_ motives.  That's fine.  You K > have your axe, feel free to grind it.  But perhaps you should re-evaluate J > your supposed monopoly on the Truth before you shout "bullspit" at those > you disagree with.  B I think 'bullshit' is an entirely appropriate characterization forJ statements made persistently and without accompanying evidence of any kindJ that purport to refute other assertions that have been at least moderatelyI well-documented.  In fact, that comes close to a definition of the idiom.   I And I don't apologize for becoming annoyed at times with people seemingly K (and again persistently) incapable of understanding this difference between ' substantiated argument and demagoguery.    - bill   >  > -- > Robert Deininger > rdeininger@mindspring.com    ------------------------------  % Date: Sun, 22 Jul 2001 23:54:36 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ( Subject: Re: Alpha:  ostriches and sheep, Message-ID: <3B5B9FF8.6EC32640@videotron.ca>   Rob Young wrote:N >         yon.  The exact numbers I am sure are confidential and quite franklyJ >         they do bounce around , but that is understandable.  Competitive= >         info and all that.  But it is a profitable segment.   L It is obvious that VMS is profitable otherwise Compaq and Digital would haveH killed it during those times where killing VMS was seriously considered.  I The question is whether VMS profits are truly substantial compared to the E other profitable operations at Compaq. By lumping together all of the F "enterprise" stuff, we don't know if the big driver for profits in the? enterprise server section is wintel servers, VMS, NSK or Tru64.   N For all I know, VMS profits might be just big enough that Compaq can't justifyK killing it, even though they may be insignificant to the whole bottom line.   F And it also depends on whether you lump Alpha sales as well as support8 contracts. Does Compaq do much VMS consulting business ?   ------------------------------    Date: 22 Jul 2001 22:14:04 -0500+ From: young_r@encompasserve.org (Rob Young) ( Subject: Re: Alpha:  ostriches and sheep3 Message-ID: <QQ0ZUyK$oxDt@eisner.encompasserve.org>   R In article <9jfsfs$aa0$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes:  	 > While I M > have other sources for some of that information, the 'unimpeachable' source J > is known to both Terry Shannon and Rob Young, both of whom can hardly be. > considered to be on my side of this issue.     	Re: VMS profits.   < 	Just to clarify a bit.  I am imperfectly recalling what hasA 	been mentioned or passed on to me in non-NDA sessions hither and E 	yon.  The exact numbers I am sure are confidential and quite frankly A 	they do bounce around , but that is understandable.  Competitive 4 	info and all that.  But it is a profitable segment.   				Rob    ------------------------------  % Date: Sun, 22 Jul 2001 19:40:38 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com>/ Subject: Re: Compaq FUD and lack of information ' Message-ID: <3B5B2C36.2B44A250@GCE.com>    John McLean wrote: >  > Hoff,l > D > I cite various engineering issues as a way of illustrating that itJ > appears that Compaq's decision has been made purely by the bean-countersH > without input by technical people and, it seems, without any reference= > to people involved with marketing the Alpha-based products.P > H > If the technical people had been appraised of the idea before the JuneE > 24 announcement then I imagine your team would be further advanced,nJ > rather than starting work at or about that date, and only just receiving > IPF documentation. [...]e  @ There are some things that could be upsides, if they are seen to
 be happening.o  C For example, the I/O stack in VMS has numerous type bits in the IRP ? to handle raid, striping, shadowing, mountverify, and a host of-@ others (I believe caching is there too). Also there are a number of bits of code that look like      tstl  #globaladdressi    beql   1$    jsb   g^globaladdress 1$:f  < (in very rough form). I could add that the current irp$l_pid' hook for postprocessing is an ugliness.i  ; An i/o layering system, which would define this cleanly, is : not that difficult to do. Many of the preliminaries exist,; and a system where there is a chance to lay out IRPs, UCBs,y: and so on anew could benefit by defining a layering system< that allows layered drivers to be inserted or removed in any8 order and that captures major driver entry point layers.> (FDT, start-io, and postprocessing are essential. Mount verify> start/end, I/O cancel, and others really should be there too.)  9 To handle legacy code, a driver layer that implements the ( existing hooks could be present at need.  6 There may very well be major holes in this notion, but= the point is that if we hear about internal entropy reductionw? rather than only a bug-compatible port, I believe we may justly/@ be encouraged. The converse is also true. There are two or three: years before Alpha new models end (and that too may change= if IA64 does not pan out as expected). That is time enough to ? get some issues right in the internals which were not revisited. in the VAX -> Alpha transition.R  > If the VMS engineering group has a reputation for anything, it9 is for great skill in doing things right...where they are ; given time. Evidence in the form of some hints as to thingsM; BEING DONE right should quiet worries, and quiet suspicionsa@ that Compaq is not "really" funding anything more than a holding
 operation.  ; A further caution: something like a VMS "streams" interfacey7 (as outlined above) will take time to bake. I'd welcomem@ a hint that someone is looking into it, but nobody should expect> such a thing to come out quickly. There are many special casesD and such a system is worth doing only if essentially all the special= cases can be rolled into it and made clean. That I personallys? think they can be does not prove anything since I have not done * the detail checking work to be sure of it.  ; Imagine too how nice it would be for a VMS to have a way toi; let Linux filesystem code be plugged in and used? I believedA that as long as ODS2/5 remain and such bits are options users canb? insert, they could be loaded and used and there would be no GPLn= issues...or at least there could be kits of such made up thato; would have none, perhaps requiring each site to do the linkp step.   9 Potential upsides. Keep that in mind. We will see whethers. we hear about some such becoming real, or not.   Glenn Everhart   ------------------------------  + Date: Sun, 22 Jul 2001 20:18:18 +0000 (UTC)b) From: jon@eoin.demon.co.uk (Jon Laughton)h( Subject: Re: FS(UK) Alphastation 500/4000 Message-ID: <9jfcea$1ga$2@INDY.eoin.demon.co.uk>  L If anyone replied to my ad for this, I would be grateful if they could emailA me again, because some of my email has been accidentally deleted.i  - Thankyou and apologies for any inconvenience.c   ------------------------------   Date: 22 Jul 2001 22:30:23 GMT' From: cassidy@netaxs.com (Kyle Cassidy)u. Subject: help mounting drives 3000/300 vms 5.5# Message-ID: <9jfk5v$l8a@netaxs.com>a  D howdy kids -- i just got vms 5.5 installed on a vax 3000/400 and i'mJ having a dilly of a time mounting the drives .... when i try (for example)   mount r1squa$dia0:  J i'm asked for a label and a log file, i make some up, get a request on theI screen to physically mount the disk (whih isn't what i'm looking for) andwG nothing .... i'm assuming i need to mount the disks before i can accesse them... yes?  # thanks for your time and expertise,p   kc   ------------------------------  % Date: Sun, 22 Jul 2001 19:51:33 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)2 Subject: Re: help mounting drives 3000/300 vms 5.5L Message-ID: <rdeininger-2207011951340001@user-2ivea99.dialup.mindspring.com>  L In article <9jfk5v$l8a@netaxs.com>, cassidy@netaxs.com (Kyle Cassidy) wrote:  F > howdy kids -- i just got vms 5.5 installed on a vax 3000/400 and i'mL > having a dilly of a time mounting the drives .... when i try (for example) >  > mount r1squa$dia0: > L > i'm asked for a label and a log file, i make some up, get a request on theK > screen to physically mount the disk (whih isn't what i'm looking for) andhI > nothing .... i'm assuming i need to mount the disks before i can accesse > them... yes? > % > thanks for your time and expertise,n     $ HELP MOUNT     MOUNTd  D      The Mount utility (MOUNT) allows you to make a disk or magnetic*      tape volume available for processing.        Formate  7        MOUNT  device-name[:][,...] [volume-label[,...]]                  [logical-name[:]]n  E The first parameter is the device name.  You seem to have that right.   H The second parameter is the volume label.  Unless the volume is foreign,G that is required for disks (I think).  If you don't know the label, youp can instead do   $ MOUNT/FOREIGN r1squa$dia0:  0 ... and it will tell you the volume label.  Then   $ DISMOUNT r1squa$dia0:u  < ... and mount it non-foreign, with the label on the command.   $ MOUNT r1squa$dia0: <label>  E The label is partly a safety device.  If you specify the wrong label,tH MOUNT catches the error and requests the volume with the correct label. I This goes back to the days when disks were more likely than today to havewC removable media in them.  But it's still an issue when SCSI IDs canmD similar address information for a disk can change from time to time.  G The third parameter to MOUNT is a logical name (not a log file), and isnG optional.  If you specify it, the system will define that logical name,e( which will translate to the device name.  G If you want the disk to be mounted for all the processes on the system, % include /SYSTEM on the mount command.a  3 There are a number of other qualifiers for MOUNT...s   -- d Robert Deininger rdeininger@mindspring.como   ------------------------------  % Date: Sun, 22 Jul 2001 14:18:46 -0400e2 From: rdeininger@mindspring.com (Robert Deininger)+ Subject: Re: LPs on the Web (Was: Re: DCPS)iL Message-ID: <rdeininger-2207011418470001@user-2ive7ua.dialup.mindspring.com>  
 In articleG <Pine.LNX.4.21.0107220907340.17294-100000@firewall.freddym.org>, Freddy(' Meerwaldt <frederik@freddym.org> wrote:,   > Hi!e > K > >   Now that DCPS licenses are included with VMS, how about changing thatd > > andlJ > > also including them on the VMS distribution CDs?  The license for Java > > JDKsC > > are also included with VMS and they are distributed on the web.) > L > Why doesn't Compaq make all Layered Products available for Download on the > web?5 > Everyone who doesn't have the license can't use it.(G > But there are Hobbyist Users (like me), who do have the PAKs from the 7 > Hobbyist Program - so I may use the software legally. , > But it's very hard to get to the software. > 2 > How expensive is such a Layered Product Library?  H The library is very expensive.  Shamefully expensive.  Recent prices forE OS+Doc+LP libraries approach $1000 per platform (i.e. alpha and Vax), E depending on who's buying and what clod at Compaq generates the price * quote.  That's for something like $20 CDs.  F It seems that at Compaq, CD are still new and exotic technology, which) cost a fortune to produce and distribute.t  I If Rich Marcello could discover the MORON at Compaq who's responsible forrE this kind of pricing, and send him to be the field service rep at thecG south pole, he'd earn his pay for the month.  These CD kits ought to bewI sold for a nominal cost.  $100 for the whole batch should more than coveruI Compaq's costs, and it would make an order for VMS CDs more pleasant than # a trip to the dentist for a change.h   -- o Robert Deininger rdeininger@mindspring.comr   ------------------------------  % Date: Sun, 22 Jul 2001 14:22:09 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)+ Subject: Re: LPs on the Web (Was: Re: DCPS)mL Message-ID: <rdeininger-2207011422090001@user-2ive7ua.dialup.mindspring.com>  3 In article <ifp9K9ctb1V3@eisner.encompasserve.org>,t: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:  D > In article <3B5A5A08.66546A3@toyvax.Tucson.AZ.US>, Vance Haemmerle# <vance@toyvax.Tucson.AZ.US> writes:i > > Freddy Meerwaldt wrote:u >  > 5 > >> How expensive is such a Layered Product Library?r > > C > > On the OpenVMS store, the Layered Products library is $1,070.00n >  > On eBay, about $100.  D Usually the eBay kits are a bit stale, sometimes very stale.  Still,  they're fine for most hobbyists.  F There was a VAX VMS 7.3 + LP kit on ebay not long ago, and it sold WAYJ below retail.  I suspect everyone needed it for their business had alreadyG payed for the subscription, so it when for hobbyist price (around $200,lE IIRC).  This was the only up-to-date VMS kit I recall seeing at ebay.    --   Robert Deininger rdeininger@mindspring.comt   ------------------------------  # Date: Sun, 22 Jul 2001 22:01:26 GMTs. From: "Duane Sand" <duane.sand@mindspring.com>" Subject: Re: No chance for OpenVMSA Message-ID: <W2I67.241716$%i7.135039115@news1.rdc1.sfba.home.com>e   > John McLean asked:F > > IIRC, we also have an issue with big-endian and little-endian dataK > > with Alpha and IPF.  Does this go all the way through to files on disk?e3 > > (I don't know and I ask the question honestly.)u   antonio.carlini guessed:) > Alpha and Intel are both little-endian.i+ > (Alpha can be configured to be big-endiano  > but AFAIK only Cray did that).  6 Alpha and IPF both support both big- and little-endian; operating systems and applications.  (Alpha belatedly addeda= this about five years ago.)  Besides Cray, the now-redirectedr9 port of NonStop Himalaya from Mips onto Alpha was also toeC be big-endian.   HP's port of its legacy OS onto IPF is big-endian.i> The restarted port of NonStop Himalaya onto IPF is big-endian.- Most other uses of IPF will be little-endian.c  1 VMS and Tru64 users will have no endian issues in 5 migrating from Alpha to IPF; those OS's will continue : to be exclusively little-endian.  Himalaya users will have7 no endian issues in migrating from Mips to IPF; that OSg+ will continue to be exclusively big-endian.    ------------------------------  # Date: Sun, 22 Jul 2001 22:15:12 GMTt0 From: John Santos <john.santos@post.harvard.edu>" Subject: Re: No chance for OpenVMS= Message-ID: <MPG.15c51a7ac3dbe9a98968a@news.bellatlantic.net>d  B In article <W2I67.241716$%i7.135039115@news1.rdc1.sfba.home.com>, ! duane.sand@mindspring.com says...n > > John McLean asked:H > > > IIRC, we also have an issue with big-endian and little-endian dataM > > > with Alpha and IPF.  Does this go all the way through to files on disk? 5 > > > (I don't know and I ask the question honestly.)e >  > antonio.carlini guessed:+ > > Alpha and Intel are both little-endian.r- > > (Alpha can be configured to be big-endiant" > > but AFAIK only Cray did that). >f8 > Alpha and IPF both support both big- and little-endian= > operating systems and applications.  (Alpha belatedly added9? > this about five years ago.)  Besides Cray, the now-redirected   < Are you sure?  ISTR that Alpha was both-endian from day one.  ; > port of NonStop Himalaya from Mips onto Alpha was also tonE > be big-endian.   HP's port of its legacy OS onto IPF is big-endian.t@ > The restarted port of NonStop Himalaya onto IPF is big-endian./ > Most other uses of IPF will be little-endian.o > 3 > VMS and Tru64 users will have no endian issues ins7 > migrating from Alpha to IPF; those OS's will continuee< > to be exclusively little-endian.  Himalaya users will have9 > no endian issues in migrating from Mips to IPF; that OSm- > will continue to be exclusively big-endian.a   ------------------------------  % Date: Sun, 22 Jul 2001 22:59:25 -0400'- From: JF Mezei <jfmezei.spamnot@videotron.ca>g" Subject: Re: No chance for OpenVMS, Message-ID: <3B5B930C.A72C82F1@videotron.ca>   John McLean wrote:G > will need two copies of the executable.  Some of us went through thisuG > with Vax and it was a major pain but at least we had the choice abouta) > when we completed to the move to Alpha.i  L Consider that one statement from Compaq appears to say that VMS on IA64 willI be available in 2004. Consider that EV7 will be available between now andt sometime in the future.bK Consider that Compaq is likely to stockpile a bunch of EV7s during the lastx Alpha fabbing.  I It seems to me that those on Alpha will have plenty of time to migrate tohH whatever. And I suspect that for the "valued customers" (those importantL enough to warrant a visit by Compaq), Compaq will make that transition quiteN easy from a management/contract point of view. And if by that time, Compaq hasI an equivalent solution on NT, I would bet money that Compaq would make it L cheaper for a customer to migrate to IA64-NT than to IA64-VMS. As far as theG other customers, they will still be able to run their alphas and find ai5 solution on their own. (Compaq doesn't seem to care).w    N However, from the customer's point of view, the transition to the new platformM will represent internal costs and require money and manpower to test/validateuK the new system and its sofware and develop the transition schedule etc etc. M This exercise might make customers look at their current applications and seeoI if newer/better applications are available on the market. And if a betterrN application is available on a different platform, the customer might take that  opportunity to switch platforms.  L Lets assume that Compaq really does listen to its valued customers. The factJ that those valued customers doesn't seem to mind the lack of VMS marketingH would indicate to me that those valued customers don't car about lack ofG availability of applications on VMS. (marketing->new customers->growingt8 installed base->ISV attracted to VMS->new applications).  J VMS might become like Tandem-NSK where much of the growth is from existingM customers adding more CPU horsepower to handle greater transaction loads, but J otherwise leaving the platform very stable with no new software and as few changes as possible.   ------------------------------  # Date: Mon, 23 Jul 2001 01:15:15 GMTh) From: rob.buxton@wcc.govt.nz (Rob Buxton) ; Subject: Reference for VMS anti-hacker credentials required-2 Message-ID: <3b5b78d8.1473410512@news.wcc.govt.nz>   Hi All,0  F At a no longer recent VMS Seminar a point was made that VMS was one ofE (or the only) OS that had not been hacked by a certain expert hacker.   D I haven't been able to find an actual article to back this claim and. would like pointers to any WWW pages for info.  B There's a fear here about access to all Computers and I want to be@ able to make a clear point with some good reference material the inherant security of VMS.    TIA    Rob.   ------------------------------  % Date: Sun, 22 Jul 2001 14:10:27 -0400n2 From: rdeininger@mindspring.com (Robert Deininger)- Subject: Re: Selling VMS to another company ?mL Message-ID: <rdeininger-2207011410280001@user-2ive7ua.dialup.mindspring.com>  J In article <9je9r2$6qn$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> wrote:  3 > "john nixon" <jnixon@cfl.rr.com> wrote in message 9 > news:9Gl67.41901$uo3.6177001@typhoon.tampabay.rr.com...v > >  Alpha was a money pit > K > Care to offer any actual evidence that the above statement isn't completeGF > bullshit?  I've offered rather a large amount that at least suggestsN > strongly that it is, but I'll be happy to discuss anything you might wish to > bring up.e  J I've followed most of your discussions.  I haven't seen anything blatantlyD wrong with your numbers.  However, I think your interpretation is on thinner ice.  E I don't recall anyone from Compaq saying that Alpha was a money pit.  A Indeed, one of the problems is that they have been starving alphaeF development to some extent.  You have said all along that Compaq couldG have upped revenues significantly by marketing VMS and other products. h  I We have seen hints, if not outright statements from Compaq, that the costIF of funding future alpha development was a factor in the cancellation. J Your analysis of past expenditures really doesn't, and can't, address whatC they would have had to spend to complete EV8 as it should have been H completed.  Maybe there were significant problems on the horizon that weI haven't heard about.  If Compaq could not or would not commit to spendingpB enought money to ensure success in the face of difficult technicalJ problems, it's quite possible that the more technical folks would start toI seriously consider alternatives.  If your study of past financials allowsoA you to predict what alpha's future costs would have been with anyaC certainty, well, I guess I missed that post in the recent blizzard.e  B I don't have any facts to support this kind of scenario.  I'm justI pointing out that your analyses (which have started to get rather shrill,lG btw) do not exhaust all the possibilities.  You seem to want to put the I worst possible face on Compaq's actions _and_ motives.  That's fine.  YoujI have your axe, feel free to grind it.  But perhaps you should re-evaluatenH your supposed monopoly on the Truth before you shout "bullspit" at those you disagree with.   -- e Robert Deininger rdeininger@mindspring.come   ------------------------------  # Date: Sun, 22 Jul 2001 17:21:01 GMTs& From: "john nixon" <jnixon@cfl.rr.com>- Subject: Re: Selling VMS to another company ?a< Message-ID: <1YD67.48019$rt.6614584@typhoon.tampabay.rr.com>  E Well,  maybe "money pit" was not exactly the right word.  A money pitrD conjures up images of a hole into which money is poured, without anyH tangible return.  In this case, the return was arguably the best  (don't1 make me define best), computer chip in the world.t  K However, producting a high quality computer chip costs a lot.  (Do you care:L to dispute that?)  The more of them you sell, the farther you can spread outL the R&D costs.   For whatever reason, Digital/Compaq was not able to sell asL many Alpha chips as Intel could sell  X86 chips.  Therefore Intel could sellC their chips for less.  It became a cycle.  They sell them for less,aJ therefore they sell more of them.   They sell more of them, therefore theyH sell them for less.   The alpha never achieved the critical  (marketing)& mass necessary to initiate this cycle.  G Had Compaq attempted and succeeding in marketing VMS, then the sales ofpK Alpha would have followed, boosting the viability of both.  As it was, theyrD both seemed to hold each other back.  I think that killing Alpha andJ spinning off VMS would open a whole new realm of possibilites for the best os in the world.  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9je9r2$6qn$1@pyrite.mv.net... >i3 > "john nixon" <jnixon@cfl.rr.com> wrote in messageo9 > news:9Gl67.41901$uo3.6177001@typhoon.tampabay.rr.com...- > >  Alpha was a money pit > K > Care to offer any actual evidence that the above statement isn't completecF > bullshit?  I've offered rather a large amount that at least suggestsK > strongly that it is, but I'll be happy to discuss anything you might wishh to > bring up.e >a > - bill >o >o >y >a   ------------------------------  % Date: Sun, 22 Jul 2001 23:27:11 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>a- Subject: Re: Selling VMS to another company ?a+ Message-ID: <3B5B998D.64A8034@videotron.ca>g   Bill Todd wrote: > >  Alpha was a money pit > K > Care to offer any actual evidence that the above statement isn't completed > bullshit?   L it depends on whether you look at the small picture of the big picture. I amJ quite sure that the Compaq beancounters were able to use Intuit accountingL software  on their wintel box to segregate Alpha development costs such thatM they showed no revenus, hence conclusion that Alpha is a money pit, and hences  Compaq's decision to dump Alpha.  J Remember, beancounters' jobs are to play with the number to make them lookL like what high management wants the numbers to say. Those beancounters couldC have made Alpha look quite profitable had they been asked to do so.e  M The killing of Alpha is simply a corporate decision by Compaq because this isv- not where Compaq wants to go in its strategy.i   ------------------------------  % Date: Mon, 23 Jul 2001 01:06:15 +010001 From: "Chris Townley" <news@townleyc.demon.co.uk>r' Subject: Re: The PC and Software Museum A Message-ID: <995847271.18722.0.nnrp-12.d4e45fa5@news.demon.co.uk>a  % <fgythy@nowasia.net> wrote in messagen' news:9jabub$5cc$258@usenet.otenet.gr... , > - Do you like OLD computers and software ?: > - Would you like to download some OLD Windows Versions ?  2 I presume that is old X-windows software versions?   -- ChrisP   ------------------------------  % Date: Sun, 22 Jul 2001 16:40:11 -0400i) From: "Neil Rieck" <n.rieck@sympatico.ca>f5 Subject: Re: VMS remains secure at DEFCON hacker festn9 Message-ID: <mVG67.6333$eY6.299639@news20.bellglobal.com>l  ? "Patrick Jankowiak" <pjankowi@usa.alcatel.com> wrote in messageh) news:3B585A62.A772C066@usa.alcatel.com...  > Hi.u >lJ > A couple friends and I, on our own and for the drunken fun of it, took aH > VMS box configured with apache webserver and telnet and ftp and set upJ > to automagically generate user accounts and default web pages for anyoneF > who telnetted and answered the questionnaire, to defcon9, the yearly# > hackers' convention in las vegas.  >hI > It was subjected for 3 days to the attendees, over 5000 hackers. People I > you should be afraid of. It stayed on the intranetwork with the hackerseC > for the whole time and was not hacked, and it was not for lack ofeJ > attempts by some very expert and accomplished people, although one LuserE > did manage to (ahem) accidentally trip over the power cord. detailsr > later. >o% > #3||0!, is VMS Marketing listening?e  L I wonder if OpenVMS systems will still be this solid once they're running on< IA-64? (with inferior memory management hardware protection)  
 Neil Rieck Kitchener/Waterloo/Cambridge,o Ontario, Canada.! http://www3.sympatico.ca/n.rieck/a   ------------------------------  % Date: Sun, 22 Jul 2001 23:15:07 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>-$ Subject: Re: Zero Quadword Time Poll, Message-ID: <3B5B96B9.2469AE0A@videotron.ca>   John Vottero wrote:nL > I don't see the problem.  If you subtract zero from something, you wind up > with the same thing.  J Subtract an absolute time from an absolute and you get a delta time. (now)J Subtract a delta time from an absolute and you get an absolute. (proposed)  N The system calls will continue to return a success in the vast majority of the. cases, but the result will be quite different.  F I guess it comes back to the engineer's original question: does anyoneF calculate delta-time between an absolute date and the smitsonian date.  M Such a change would require that everyone check their code to ensure that thevL change won't affect their code. Changing their code might be easy, but it isK still a change to some code to make it work (with all the hassles of having / different code depending on version of the OS).t  % What benefit would the change bring ?v   ------------------------------    Date: 22 Jul 2001 21:50:32 -07002 From: dugald_peacock@yahoo.com.au (Dugald Peacock)9 Subject: Re: [Q] CXX, global variables, Shareable library)= Message-ID: <fcdcb36b.0107222050.2eb0699f@posting.google.com>    Tryc ;  FRED.MAR         .TITLE  FRED ;22 ;       File:           FRED.MAR                  , ;       Created:        20-JUL-2001 00:00:00 ;r   variable2  == 2e variable1  == 1c           .END   $macro fredt  $ $link/share fred,cglob+sys$input/opt%  symbol_vector=(procedure=procedure,-e  variable1=data,-h  variable2=data)
  (ctrl-z).  # I think this will do what you want.    Dugald   ------------------------------   End of INFO-VAX 2001.405 ************************