1 INFO-VAX	Mon, 28 Jul 2003	Volume 2003 : Issue 414       Contents:# Any semi-current Mop registry info? $ Campus and Pathworks/Advanced Server Cluster communications on DS10" Re: Cluster communications on DS107 Re: Compilers XD Ada, MIL-STD-1750A, CORAL, PERSPECTIVE ' Re: Creating an EVE or TPU Section File P Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful   PerformanceO Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance O Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance O Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance O Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance N Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful PerformanceP Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance PP Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance PP Re: DEC-AXPVMS-VMS731_CDRECORD-V0100--4.PCSI v.  DEC-AXPVMS-VMS731_PCSI-V0100--4P Re: DEC-AXPVMS-VMS731_CDRECORD-V0100--4.PCSI v. DEC-AXPVMS-VMS731_PCSI-V0100--4." Re: DECnet over IP (timeout query) DSSI problem Re: duplicating system disks Re: duplicating system disks Re: duplicating system disks Re: DVD compatibility with VMS Re: DVD compatibility with VMS Re: EMC on VMS Re: HP FUDBusting + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense + Re: HP World: Why Alpha's Omega Makes Sense , Re: IDC: HP ranks No. 1 in 2002 HPTC revenue, RE: IDC: HP ranks No. 1 in 2002 HPTC revenue, Re: IDC: HP ranks No. 1 in 2002 HPTC revenueP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World:  Why AlpP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why AlphP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why AlphP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why AlphP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why AlphP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why AlphP Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alph2 Re: Migrate obsolete VAX/VMS SW to OpenVMS Itanium2 Re: Migrate obsolete VAX/VMS SW to OpenVMS Itanium2 Re: Migrate obsolete VAX/VMS SW to OpenVMS Itanium  Re: NEWBIE: DECWindows Bit Depth1 Re: OpenVMS homepage and 'sales.liveperson.net' ? " Re: Packed decimal arithmetic in C" Re: Packed decimal arithmetic in C" RE: Packed decimal arithmetic in C Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Re: PDP-11 OS Release Dates  Problems with NFS  Re: Problems with NFS  Re: Problems with NFS G Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ?   F ----------------------------------------------------------------------    Date: 28 Jul 2003 09:44:10 -0700$ From: gspamtackett@yahoo.com (Galen), Subject: Any semi-current Mop registry info?= Message-ID: <bdc65a53.0307280844.3468798e@posting.google.com>   ? Could anyone here provide MOP registry information that is more C up-to-date than the "22 March 1993" copy that I have? This was once @ available from DEC as an update to Appendix A of the "MainenanceF Operations Protocol Functional Specification V4.0.0" June 1992 edition= (the order number for that was EK-DNA11-FS-001 in case you're 	 curious).    ------------------------------  % Date: Mon, 28 Jul 2003 16:01:13 +0100 * From: "Mark Iline" <system@meng.ucl.ac.uk>- Subject: Campus and Pathworks/Advanced Server * Message-ID: <bg3de5$mto$1@uns-a.ucl.ac.uk>  H After much pursuit via our excellent reseller, a Pathworks Client Access> Licence has appeared on the June 2003 DECcampus CDs in the UK.  I The PAK is PWLMXXXCA07.03 , and is just like the temporary PAKs we'd been I using, except that whereas these had 3500 units (350 clients, I believe), E the campus one has zero units. (Actually, the campus one  also had an G obvious typo in its name, but fixing that allowed it to be registered).   A The equivalent ASDU PAK also has zero units, and allows unlimited ( connections to Advanced Server on Tru64.  D However, Pathworks 6.0 treats the Campus PAK as having no units, and: allowing zero clients. This is not particular;ly useful...   The questions:  " Is anyone else playing with this ?  H Is this PAK 'wrong' ? ie it ought to have a large number of units rather than zero ?   I Would this PAK work with AS7 (for VMS) to give unlimited connections, but  just doesn't work with PW6 ?     Mark  
 Mark Iline UCL Mech Eng   ------------------------------  % Date: Mon, 28 Jul 2003 08:26:10 -0500 . From: Larry Schuldt <lschuldt@Rudenessdls.net>' Subject: Cluster communications on DS10 8 Message-ID: <8u8aiv86uefiiio9g2itii9lvop9lnl7r2@4ax.com>  C I remember a post from a month or two ago.... Someone was trying to F run SCS communications over a fast ethernet full duplex connection andF couldn't get it to work. Was there ever a resolution to this issue? We have the same problem.   Thanks,  larry  --  = To reply by e-mail, be polite. Rudeness will get you nowhere.    ------------------------------  % Date: Mon, 28 Jul 2003 11:56:15 -0400 " From: "Hal Kuff" <kuff@tessco.com>+ Subject: Re: Cluster communications on DS10 - Message-ID: <bg3h45$phk@library1.airnews.net>   H     We're running DS10's in clusters with ES40 systems over 100MBit fullL duplex, no issues... I assume you set the ewa* and ewb* setttings in the SRM to 100 full fastfd    ; "Larry Schuldt" <lschuldt@Rudenessdls.net> wrote in message 2 news:8u8aiv86uefiiio9g2itii9lvop9lnl7r2@4ax.com...E > I remember a post from a month or two ago.... Someone was trying to H > run SCS communications over a fast ethernet full duplex connection andH > couldn't get it to work. Was there ever a resolution to this issue? We > have the same problem. > 	 > Thanks,  > larry  > --  ? > To reply by e-mail, be polite. Rudeness will get you nowhere.    ------------------------------  % Date: Mon, 28 Jul 2003 10:48:17 +0100 * From: Nic Clews <sendspamhere@[127.0.0.1]>@ Subject: Re: Compilers XD Ada, MIL-STD-1750A, CORAL, PERSPECTIVE' Message-ID: <bg2rd5$ci6$1@lore.csc.com>    Didier Morandi wrote:  >  > Gary Knight wrote:J > > This site active will give info and contacts to anybody needing to use/ > > these and associated products worth a look.  > >  > >  > > www.swep-eds.com > * > Super. Will XD Ada be ported to Itanium?  E I've been in contact with the guys and the answer is yes, details are  actually on their website.   --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------    Date: 28 Jul 2003 07:02:37 -0700' From: hari@transcomm.uk.com (HariHaran) 0 Subject: Re: Creating an EVE or TPU Section File= Message-ID: <2de080f3.0307280602.70d86c9f@posting.google.com>    "POWERS, John" <John.POWERS@reading.sema.slb.com> wrote in message news:<95544AF90752D211AC0300A0C9E01D32019FFA1A@reaes4.sema.co.uk>...  > The command is > ( > EDIT /TPU/NODISPLAY/NOINITIALIZATION -& >      /COMMAND=SYS$EXAMPLES:EVE$BUILD > K > It's all described nicely in the explanatory comments at the beginning of F > SYS$EXAMPLES:EVE$BUILD.TPU - a great read. Everything you need to do$ > to prepare your code for building. >  > Have fun!  >  > John > 
 > John Powers  > SchlumbergerSema > Messaging Solutions.  D Hi Guys!  Many thanks for all your help.  It's all working now, ta. E It didn't use to be as complicated as it is now, with all that master C file and version file stuff.  No wonder it wasn't working the vague  way that I remembered it.  Hari    ------------------------------  # Date: Mon, 28 Jul 2003 17:32:34 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> Y Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful   Performance 0 Message-ID: <S6dVa.971$ng1.155@news.cpqcorp.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message # news:3F25583A.98CC22E1@istop.com...  > jlsue wrote:L > > While I agree with these as being considered "dirty tricks", what in theH > > IA64 compilers meets the above so that JF would characterize them as "dirty > > tricks". > L > You didn't get my point. My point was that those benchmarks may be good toC > compare raw performance, but the EPIC nature makes those far less + > representative of real world performance.  > H > It is one thing to calculate PI to 2 billion decimals really fast, but another 8 > thing to have a program with lots of conditional code. >   F But the variety of code in the benchmarks is hardly "calculate PI to 2J billion places", and by-and-large, most code will take the same code paths- for the same types of input most of the time.   L > It is like measuring a Car A to a Car B. Both may have similar top speeds, but J > in real life, in a country road, "A" will handle curves much faster than "B" K > since "B" will have to slow down significantly whenever there is a curve.  >   K No.  Think of this as - once I've driven this road a few times, I generally G know it's layout and how to drive it at the fastest speed.  So feedback J driven optimization will make it faster when driving the normal route.  IfI you decide to take a detour, you may not get the highest possible speed - K but you'll still do just fine.  If taking the detour becomes the norm, then * re-optimization would seem to be in order.  L > Calculating PI to 2 billion decimals is like a straight highway. Real life7 > programs are like courntry roads with lots of curves.  > K > EPIC may be really fine to help calaculate PI to 2 billion decimals since  the J > compiler can then perform all the optimisation it wanst since the code'sL > execution can be well predicted. But in real-life with lots of conditionalJ > code, can EPIC really handle all those curves so well sicne the chip has far I > less smarts in it and the compiler is long gone by the time the program  runs ?  J If you have a 100 mile trip with 100 x 10 mile sections that can be taken,J you can optimize each of the 10 mile sections, and predict the typical setL of 10 sections that are normally driven.  If you take a different route, youG may not be as fast as you *might* have been, but you'll still be plenty  fast.   I You seem to be intent on believing that typical code never takes the same E route twice, and that the only a single code path can be predicted or 
 optimized.   ------------------------------  # Date: Mon, 28 Jul 2003 14:33:55 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>X Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance8 Message-ID: <21daivoh10jptj47ijeltlb4t81vmo7eoi@4ax.com>  0 On Fri, 25 Jul 2003 17:27:45 -0700, Robert Klute' <robert_klute_removethis@hp.com> wrote:   C >On Fri, 25 Jul 2003 22:03:31 GMT, jlsue <jefflsxxxz@sbcglobal.net>  >wrote:  >   M >>That's strange.  How do you make this comparison to other compilers?  Where L >>do you draw the line between compilers written for their architecture, and >>those pulling "dirty" tricks?  >>G >>Alpha compilers had to incorporate a lot of new ideas to get the best 1 >>performance on that architecture.  Who doesn't?  > H >Compilers that gen code based on the routine name.  Compilers that lookE >for specific coding sequences, only commonly used in benchmarks, and D >insert hand tuned code.  Compilers that restructure the data to getE >performance gains.  When compilers start tuning specifically for the F >benchmark and not because a customer has a similar need, then it is aG >trick.  I will admit, as benchmarks get more sophisticated, there is a D >large grey area as to what is customer driven and what is benchmark	 >sniping.  >   H While I agree with these as being considered "dirty tricks", what in theK IA64 compilers meets the above so that JF would characterize them as "dirty  tricks".   ------------------------------  # Date: Mon, 28 Jul 2003 14:35:44 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>X Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance8 Message-ID: <f6daivgnks1ua9t57dj6182qt0qo3e5iep@4ax.com>  H On Fri, 25 Jul 2003 20:17:41 -0400, JF Mezei <jfmezei.spamnot@istop.com> wrote:  
 >jlsue wrote: N >> Right now, since the big crash after 9/11/2001, there is very little profit) >> in ANYONE's enterprise systems units.   > K >Recession started before that. Somewhere between Nov 4 2000 and January 17 O >2001. Sept 11 was just an accelerator that made things drop one big notch, but E >there is no telling how the economy would have behaved without 9-11.   H This is EXACTLY what I've been saying (though I didn't use exact dates).   ------------------------------  % Date: Mon, 28 Jul 2003 10:05:47 -0700 3 From: Robert Klute <robert_klute_removethis@hp.com> X Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance8 Message-ID: <4blaivocqmli264hh3a574jv62r1rhc8g9@4ax.com>  B On Mon, 28 Jul 2003 14:33:55 GMT, jlsue <jefflsxxxz@sbcglobal.net> wrote:  1 >On Fri, 25 Jul 2003 17:27:45 -0700, Robert Klute ( ><robert_klute_removethis@hp.com> wrote: > D >>On Fri, 25 Jul 2003 22:03:31 GMT, jlsue <jefflsxxxz@sbcglobal.net> >>wrote: >> > N >>>That's strange.  How do you make this comparison to other compilers?  WhereM >>>do you draw the line between compilers written for their architecture, and   >>>those pulling "dirty" tricks? >>> H >>>Alpha compilers had to incorporate a lot of new ideas to get the best2 >>>performance on that architecture.  Who doesn't? >>I >>Compilers that gen code based on the routine name.  Compilers that look F >>for specific coding sequences, only commonly used in benchmarks, andE >>insert hand tuned code.  Compilers that restructure the data to get F >>performance gains.  When compilers start tuning specifically for theG >>benchmark and not because a customer has a similar need, then it is a H >>trick.  I will admit, as benchmarks get more sophisticated, there is aE >>large grey area as to what is customer driven and what is benchmark 
 >>sniping. >> > I >While I agree with these as being considered "dirty tricks", what in the L >IA64 compilers meets the above so that JF would characterize them as "dirty	 >tricks".   E Nothing that I know of.  It does statically decide on and parallelize E code flows that are done dynamically on a superscalar implementation. H The ability to guess that right could be considered cheating by some. OnG the other hand, HP has had profile based optimization for a long time.     ------------------------------  # Date: Mon, 28 Jul 2003 17:22:50 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> X Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful  Performance0 Message-ID: <KZcVa.967$yb1.543@news.cpqcorp.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message # news:3F255622.6923C59E@istop.com...  > jlsue wrote:J > > If they determined that Intel's chip would be more profitable, then itL > > would be wrong for them not to follow this course of action, as stewards of > > the business.  > J > If they determined that their relationship with Intel was more important inI > order to preserve the wintel business, then they would gladly sacrifice  their G > competing products even if it meant lower profits.  HP and Compaq are  measuredJ > in volume , not in profits. Their motivation is to see growth in numbers and K > the easiest way is through wintel junk.  It isn't the couple dozen Tandem J > systems they sell a year that will give them the visibility/numbers that WallA > Stree Casino Analysts want to see when they compare HP to Dell.  > K > What those "niche" system do is provide HP with the funding to wage their  war I > against Dell at the wintel level. So HP sees them as necessary evils to  pay 2 > for the implementation of their wintel strategy. > K > Oh, another one who killed its own profitable products in order to help a K > competitor was Digital. Not only did they make sure that their own Alphas  wereI > priced sufficiently higher than Wintel that it never competed directly,  but F > Digital also killed off so many of its software products in order to please
 > Bill Gates.   J No, the death of many software products was a sorry story that had less to% do with Microsoft than you may think.    ------------------------------  # Date: Mon, 28 Jul 2003 14:30:41 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>W Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance 8 Message-ID: <a9caiv8dtl04gqc8cd93ahoijafop3l1c1@4ax.com>  H On Fri, 25 Jul 2003 23:22:36 -0400, "Bill Todd" <billtodd@metrocast.net> wrote:   > 4 >"jlsue" <jefflsxxxz@sbcglobal.net> wrote in message3 >news:mj93ivspfl9uanv2lb1o95i093rn6f4lds@4ax.com... K >> On Wed, 23 Jul 2003 18:07:34 -0400, "Bill Todd" <billtodd@metrocast.net> 	 >> wrote:  >>( >> >Sure there are:  I've provided them. >> >> You've provide some.  > G >More to the point, I've provided - and examined - all the numbers that H >Compaq did, but instead of just waving them around ("Gee - $150 million > 9 >>  How do you know that they are all the pertinent data?  > J >They were the data that Compaq used to try to make its case.  It's not my >fault if they chose poorly.  D Whatever numbers they chose to publish externally to summarize theirF position is no indication of what numbers they actually have available internally.    > F >> What inside financial information do you have that nobody else has? > K >The only piece of 'inside' financial information I had was Rich Marcello's M >personal statement that VMS systems brought in $800 million in annual profit K >(since his statement that they brought in $4 billion in annual revenue was L >corroborated elsewhere in public materials).  The rest, as noted many timesM >already, came directly from Compaq's public statements - and, once again, if H >they failed to make public other information that would have made theirG >financial case more solid that's hardly *my* fault (not that I see any > >reason to believe that any such 'other' information existed).  J Yes, $800MM in annual profit.... but for how long?  And at what additionalK cost to continue?  Again, I'm not privy to (and I'm certain that you aren't H either) all of the financial analysis that they may have used to come to their decision.     K There are many people who never believed that we made money on Alpha in the J first place.  I never saw the sources for their opinions and analysis, but< it was pretty open in some internal discussions.  So, if theI externally-available information was all there is, why would these people * continue to believe the complete opposite?   >  >  AndJ >> based on where the BOD may have wanted to go, how do you know that they. >> didn't choose the direction with open eyes? > G >That, of course, is the real crux of the matter:  the fact that Compaq M >attempted to fabricate financial and technical bases for its actions ('where K >the BOD may have wanted to go') rather than coming straight out and saying K >"We just don't want to be in this business, regardless of what promises we J >made earlier and how profitable it might be."  Those fabrications are the' >basis for calling them outright liars.   K I think they said it pretty plainly.  My interpretation is that after their G analysis, predictions, investment requirements, etc., they decided that H Alpha wouldn't keep up with the competition.  This means much, much moreH than mere chip performance - it must be taken in context with the entireI business, including marketing costs and what it would take to improve the  market position.  F If they determined that Intel's chip would be more profitable, then itK would be wrong for them not to follow this course of action, as stewards of 
 the business.   G The statements they gave aren't all lies, they just aren't the level of ! detail that you'd need to concur.   K Now, how this plays with their previous statements of "commitment" made for J a very bad situation.  But expecting an open, public apology is just plainK silly, imho.  I'm sure that they discussed this directly with many of their G key customers leadership, and it must have placated them enough to keep B business going.  Frankly, we still continue to sell quite a lot ofD AlphaServer systems - including Tru64 UNIX, which has been announced* end-of-life in the not too distant future.  C So it's pretty safe to assume that the business world had moved on.    ------------------------------  % Date: Mon, 28 Jul 2003 12:58:11 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>Y Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance P ) Message-ID: <3F255622.6923C59E@istop.com>    jlsue wrote:H > If they determined that Intel's chip would be more profitable, then itM > would be wrong for them not to follow this course of action, as stewards of  > the business.   K If they determined that their relationship with Intel was more important in M order to preserve the wintel business, then they would gladly sacrifice their N competing products even if it meant lower profits.  HP and Compaq are measuredL in volume , not in profits. Their motivation is to see growth in numbers andI the easiest way is through wintel junk.  It isn't the couple dozen Tandem M systems they sell a year that will give them the visibility/numbers that Wall ? Stree Casino Analysts want to see when they compare HP to Dell.   M What those "niche" system do is provide HP with the funding to wage their war K against Dell at the wintel level. So HP sees them as necessary evils to pay 0 for the implementation of their wintel strategy.  I Oh, another one who killed its own profitable products in order to help a N competitor was Digital. Not only did they make sure that their own Alphas wereK priced sufficiently higher than Wintel that it never competed directly, but K Digital also killed off so many of its software products in order to please  Bill Gates.    ------------------------------  % Date: Mon, 28 Jul 2003 13:07:07 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>Y Subject: Re: D.H. Brown: EV7 AlphaServers Deliver Enhanced RAS and Powerful Performance P ) Message-ID: <3F25583A.98CC22E1@istop.com>    jlsue wrote:J > While I agree with these as being considered "dirty tricks", what in theM > IA64 compilers meets the above so that JF would characterize them as "dirty 
 > tricks".  J You didn't get my point. My point was that those benchmarks may be good toA compare raw performance, but the EPIC nature makes those far less ) representative of real world performance.   N It is one thing to calculate PI to 2 billion decimals really fast, but another6 thing to have a program with lots of conditional code.  N It is like measuring a Car A to a Car B. Both may have similar top speeds, butL in real life, in a country road, "A" will handle curves much faster than "B"I since "B" will have to slow down significantly whenever there is a curve.   J Calculating PI to 2 billion decimals is like a straight highway. Real life5 programs are like courntry roads with lots of curves.   M EPIC may be really fine to help calaculate PI to 2 billion decimals since the H compiler can then perform all the optimisation it wanst since the code'sJ execution can be well predicted. But in real-life with lots of conditionalL code, can EPIC really handle all those curves so well sicne the chip has farN less smarts in it and the compiler is long gone by the time the program runs ?   ------------------------------  # Date: Mon, 28 Jul 2003 12:31:15 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) Y Subject: Re: DEC-AXPVMS-VMS731_CDRECORD-V0100--4.PCSI v.  DEC-AXPVMS-VMS731_PCSI-V0100--4 / Message-ID: <nI8Va.941$hI.670@news.cpqcorp.net>   . In article <87brvhosns.fsf@prep.synonet.com>, . Paul Repacholi <prep@prep.synonet.com> writes:  > >To the conterary, I'd expect everyone to have that much spaceD >available on a system disk. VMS plus a full fruit LP is 2-3 GB, and5 >you are scratching to get a new disk under 20GB now.   D While I agree with you, it is often the case that that "extra space"/ gets used for one form of user data or another.   B >PCSI renames files rather than supersceding them, and now will be@ >putting stuff into seperate directory trees. So why does it not> >use version numbering to preserve old versions? OK, delete by@ >renaming would still be needed, but why is PCSI totally versionA >number adverse? Are versions to be removed from the file system?   F I do not know what you mean by "renames files rather than supersceding them".  E Although it appears to be a rhetorical question, but, for the record, D I know of no intention to remove file versions from the file system.  E The original developers of the PCSI utility did not believe that they F could control file version numbers adequately.  Hence they implementedB the "generation" numbers, which are provided in kits and stored inC the PCSI database.  Also, generations are more generallized -- they 5 can apply to objects other than files.  e.g. modules.    --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  # Date: Mon, 28 Jul 2003 12:20:54 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) Y Subject: Re: DEC-AXPVMS-VMS731_CDRECORD-V0100--4.PCSI v. DEC-AXPVMS-VMS731_PCSI-V0100--4. / Message-ID: <Gy8Va.940$hI.524@news.cpqcorp.net>   ? Responses provided by PCSI developers... Hope they are helpful.   @ In article <OF42BE5FEF.294FE607-ON85256D6D.004A22BF@metso.com>,  norm.raphael@metso.com writes: ..J >Does PCSI check for enough space for the recovery data on the system disk >before proceeding?   ? Yes, the disk space algorithm takes recovery data into account.   ? > Is there a message informing how much space will be required?   % Yes.  You'll see messages similar to:        $ product install test     ... E     %PCSI-E-INSVOLSPC, insufficient space on volume DISK$AV71_F980113 H     -PCSI-I-VOLSPC, 164 blocks required; 102 blocks free; -62 blocks netI     Terminating is strongly recommended.  Do you want to terminate? [YES]      I If you use /LOG you will get an expanded summary of expected disk usage,  B but then you will also get a log of all file activity which may be quite lengthy.  H [NOTE: The "disk space algorithm" is not perfect -- For example, it can I only guess about space that may be used by an EXECUTE procedure. -- cwh]    J > Can the [/SAVE_RECOVERY_DATA] option be changed on-the-fly if the space  >is deemed inadequate?  I No, if you don't have enough disk space, you'll only be asked if you want . to terminate (strongly suggested).  See above.  > > Is the process terminated if the space is deemed inadequate?  / Yes, unless you choose to continue.  See above.   ; > Can the recovery data be stored/accessed on another disk?   B No, recovery data sets are always stored on the system disk in theG sys$sysdevice:[pcsi$undo_nnn...] directory trees (one per recovery data " set where _001 is the latest one).  > > [This seems akin to the dump-off-the-system-disk situation.] >   8 We made a conscious decision to store recovery data setsC only on the system disk to simplify the implementation and the user F interface.  Since recovery data sets for patches contain copies of theF product database, they must be rolled back (via PRODUCT UNDO PATCH) in4 the reverse order in which they were installed.  ...  D [As I mentioned elsewhere, this is exactly analogous to rollback in I a geralized database management or transaction processing system. -- cwh]   F                                              ... The PCSI utility mustH know about all of them.  With everything on the system disk, they can beG found easily without keeping pointers to them and/or without asking the  user any questions.    --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 28 Jul 2003 07:55:18 -0700+ From: graham.fletcher@dai.ltd.uk (graham F) + Subject: Re: DECnet over IP (timeout query) = Message-ID: <d23ec733.0307280655.239c97dc@posting.google.com>   F I have just been doing the same thing, most things work very well. TheA only problem remaining occurs during a network outage. The source > machine for a decnet connection spots the link going down veryD quickly. However, the destination machine never spots the connectionC going down. Setting the TCP/IP keep alive timers causes the  source B machine to spot the connection fail. Setting the decnet keep aliveB with " ncl set nsp keepalive time 10 " apears to have no effect on either end.    Does anybody have any ideas? Thanks in advance.          m bob@instantwhip.com (Bob Ceculski) wrote in message news:<d7791aa1.0307191851.1587ad5f@posting.google.com>... q > Martin Hunt <martin.hunt@fairfaxnz.co.nz> wrote in message news:<pl8ehvkb85qug7bcnhid4hgghna86tq3dr@4ax.com>... G > > My employer would like to stop running DECnet over its WAN, so I am  > > trying out DECnet over IP. > > H > > It works well, but the documentation is a bit brief in places, and IJ > > haven't found out how to make IP the default transport beteen nodes. IF > > want users to be able to do "SET HOST NODE", rather than "SET HOSTB > > NODE.DOMAIN". How do I do this? Each node is, in general, in aJ > > different domain (each of our operating divisions has its own domain). > >  > > ---  > > Martin Hunt  > > Systems Administrator  > > Fairfax New Zealand Limited  > > Wellington > > New Zealand  > D > if you have TCPware, you can run true phase IV over IP ... a piece( > of cake to configure and implement ...   ------------------------------   Date: 28 Jul 2003 11:18:12 GMT2 From: Thierry Dussuet <thierry@squeeeez.no-ip.com> Subject: DSSI problem 0 Message-ID: <slrnbia1jk.gh.thierry@VENUS.Family>   Hello!J I have a VAX 4000/300 here with 3 RF72 disks in it, as well as a TK70 tapeN drive.  Everything went well until someday I realised it was quite dusty, so IO took one drive out to see if it was really that dusty - but it wasn't, so I put M it back in.  And now it doesn't see the disks anymore! All vanished, although J the disks themselves have the green light on, and I hear them from time toL time.  The startup tests show no errors, either, and trying to boot from the system disk does not work.  	 >>>sh dev  DSSI Bus 0 Node 6 (*)    DSSI Bus 1 Node 7 (*)     UQSSP Tape Controller 0 (774500) -MUA0 (TK70)   Ethernet Adapter -EZA0 (08-00-2B-16-E7-33)  >>>   K They were on Bus 0.  Does anybody have a hint?  Something that I could have * done wrong while putting the disk back in?   Thierry    ------------------------------  % Date: Mon, 28 Jul 2003 06:57:47 -0000 ! From: Z  <zarlenga@conan.ids.net> % Subject: Re: duplicating system disks / Message-ID: <vi9ibbqtmg0rc7@corp.supernews.com>   , Rob Young <young_r@encompasserve.org> wrote:K :> : (BACKUP/IMAGE/IGNORE=INTER SYS$SYSDEVICE: {target disk})   This way, I  :> ...Q :> : Compaq/HP support is fine with this method since we have all of the required  :>  C :> They're fine with backing up the system disk while the system is " :> running with /ignore=interlock? :>   :> I don't think so.  9 : 	Sure.  You do want to back up your system disk between  : 	semi-annual downtimes.   B HP support in my region tells me booting to CD and then backing upB the system disk is the only way to be sure the backup is reliable.  2 Anything less allows for possible file corruption.  B If your app is so critical that it can't be down, and it's running@ on a non-redundant system architecture, you've got more problems than making backup tapes.   A If it is on a redundant system arch., then you can bring down one  system to back it up.    ------------------------------    Date: 28 Jul 2003 01:54:20 -0700# From: dooleys@snowy.net.au (dooley) % Subject: Re: duplicating system disks = Message-ID: <1ca82fc6.0307280054.1f3be194@posting.google.com>   X Z  <zarlenga@conan.ids.net> wrote in message news:<vi92h09vvvkdfe@corp.supernews.com>...& > Mike Naime <mnaime@kc.rr.com> wrote:J > : (BACKUP/IMAGE/IGNORE=INTER SYS$SYSDEVICE: {target disk})   This way, I >  ...P > : Compaq/HP support is fine with this method since we have all of the required > B > They're fine with backing up the system disk while the system is! > running with /ignore=interlock?  >  > I don't think so.eD I have used this before without problems, but I think a backup/image0 does lock indexf and bitmap on the source drive./ I agree that a safer method is to boot from cd l' and mount the source drive as /noshare.n' I also use the /noalias on system disksv Phil   ------------------------------  + Date: Mon, 28 Jul 2003 13:16:26 +0000 (UTC)h7 From: moroney@world.std.spaamtrap.com (Michael Moroney) % Subject: Re: duplicating system diskso( Message-ID: <bg37na$nli$1@pcls4.std.com>  % dooleys@snowy.net.au (dooley) writes:e  C >> They're fine with backing up the system disk while the system isA" >> running with /ignore=interlock? >> n >> I don't think so.E >I have used this before without problems, but I think a backup/imageS1 >does lock indexf and bitmap on the source drive.e  H Have you _restored_ those backups?  Are the files corrupted, if you did? Are you sure??  G BTW, it is not the files indexf and bitmap.sys you have to worry about. D You have to worry about any files where it prints out the interlock 	 warning..e -- l -Mike    ------------------------------    Date: 28 Jul 2003 14:20:43 +0200C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann)n' Subject: Re: DVD compatibility with VMS - Message-ID: <3f25151b$1@news.uni-konstanz.de>e  = In article <d7791aa1.0307251144.5378f615@posting.google.com>,a* bob@instantwhip.com (Bob Ceculski) writes:J |>"eberhard heuser-hofmann" <vaxinf@chclu.chemie.uni-konstanz.de> wrote in5 |>message news:<013101c34de7$d34e1600$0501a8c0@jo>...  |>? |>so can I dump my DAT tape drives, create a VMS backup saveset ? |>then ZIP it then do a backup or copy to a CD-RW drive withouto> |>first having to do a 2048 to 512 byte block conversion using> |>Glen Everhards program, or is the 512 issue only with DVD's?  9 The 512 issue is a problem of reading a SCSI-CD/SCSI-DVD!g  7 For IDE drives this is being solved by the IDE-driver.     Is this statement clear enough?P  > |>Can someone here answer this question plainly and precisely?> |>And if so, is this done using CDRECORD or CDWRITE or both or= |>straight from VMS ... I am talking about both doing this onS |>SCSI and IDE ... |>  ; cdrecord/cdwrite doesn't care about 512/2048 block jumpers.t   eberhard   ------------------------------    Date: 28 Jul 2003 10:23:05 -0700( From: bob@instantwhip.com (Bob Ceculski)' Subject: Re: DVD compatibility with VMSC= Message-ID: <d7791aa1.0307280923.1b9411c8@posting.google.com>e  x vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann) wrote in message news:<3f25151b$1@news.uni-konstanz.de>...? > In article <d7791aa1.0307251144.5378f615@posting.google.com>,t, > bob@instantwhip.com (Bob Ceculski) writes:L > |>"eberhard heuser-hofmann" <vaxinf@chclu.chemie.uni-konstanz.de> wrote in7 > |>message news:<013101c34de7$d34e1600$0501a8c0@jo>...a > |>A > |>so can I dump my DAT tape drives, create a VMS backup saveset.A > |>then ZIP it then do a backup or copy to a CD-RW drive withoutd@ > |>first having to do a 2048 to 512 byte block conversion using@ > |>Glen Everhards program, or is the 512 issue only with DVD's? > ; > The 512 issue is a problem of reading a SCSI-CD/SCSI-DVD!  > 9 > For IDE drives this is being solved by the IDE-driver. n > ! > Is this statement clear enough?a > @ > |>Can someone here answer this question plainly and precisely?@ > |>And if so, is this done using CDRECORD or CDWRITE or both or? > |>straight from VMS ... I am talking about both doing this onD > |>SCSI and IDE ... > |> > = > cdrecord/cdwrite doesn't care about 512/2048 block jumpers.C > 
 > eberhard  7 so what is the difference between cdrecord and cdwrite?.4 do they both use vms images, or backups or copies or% what to write data from disk to a cd?    ------------------------------  % Date: Mon, 28 Jul 2003 10:58:29 +0100eO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>e Subject: Re: EMC on VMS / Message-ID: <bg2s46$qf$1@new-usenet.uk.sun.com>    Rob Young wrote: > In article <bfp1im$hv9$1@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: >  >>Rob Young wrote: >  > & >>>>with black and white type answers  >>>n >>> = >>>	Nitpicking is all you have to offer, I'm not surprised.  i >>>h >> >>Don't be an arse Rob.n >>8 >>EMC's arn't fault tollerent and they do go away and if9 >>you really want me to make you look small I can provide 1 >>you with plenty of examples of them going away.  >> >  > ) > 	Plenty?  Hah.  gunbroker.com - sure.  3 >  >   8 The customer I used to advise lost 4 symetrix in one go.  9 An EMC engineer was doing a bit of proactive maintance onu8 the EMC estate which involved upgrading the microcode on< the machines, unfortunately the code release had a bug which hung the symetrix.  5 We got a support call in Tokyo to tell us that one ofo8 the Sun servers had failed, the customer stopped logging6 calls at ~the 6th machine because it was obviously not7 a Sun problem, they were also loging calls on their IBM- AIX estate at the same time.  5 By the time the customer worked out what was going on"7 they had lost 1 of their symetrix boxes in Singapore asn well.     8 The only good thing as far as the customer was concerned9 was that they had been negociating with EMC to be able tol; manage their own boxes, the outage tipped the deal in theirt favour.t      : >>Upgrading to a duff version of the microcode is just one9 >>example.  Not having a mirrored write cache is another.p >  > 7 > 	The mirrored cache FUD is a good one.  Of course you.@ > 	probably have a dozen public examples of cache boards blowing > 	out, right?  No.n >   ; So is it or is it not mirrored Rob, answers in one line Robt not your usual verbose BS.  A > 	You are getting in on this very late.  The issue that you havelB > 	your nose in here is HBVS and EMC.  If you are shadowing acrossB > 	two datacenters, losing storage isn't the problem.  The problem= > 	is bad blocks, okay?  EMC doesn't deliver bad blocks.  EMCLE > 	storage doesn't go away.  (Now there is an implied "mostly" there, B > 	you are just nitpicking my friend).  AND if the storage somehowH > 	went away (datacenter outtage), you don't have filesystem corruption,@ > 	you are running VMS.  The write made it or it didn't.  If theD > 	writes are that important, they go to two different PLACES at theD > 	same time and we have 3 separate OSes performing that trick using > 	varying techniques. >   @ What has this got to do with your completely incorrect statement< that EMC doesn't go away period. Its still BS whatever point- in the discussion you choose to inject it in.u  A As for blanket statements read your own BS first before replying.    Regards  Andrew Harrison6   ------------------------------   Date: 28 Jul 2003 17:02:41 GMT, From: bill@gw5.cs.uofs.edu (Bill Gunshannon) Subject: Re: HP FUDBusting9 Message-ID: <bg3kvg$jtmk7$1@ID-135708.news.uni-berlin.de>T  5 In article <20030722205651.4071.qmail@gacracker.org>,X7 	Doc.Cypher <Use-Author-Address-Header@[127.1]> writes:eH > On Tue, 22 Jul 2003, "Brian Tillman" <Tillman@sparkingwire.com> wrote:B >>>I guess people who're primarly programmers prefer Unix, whereas >>administrators prefer VMS  >>M >>Perhaps among the programmers you know, but that's a self-selected list and! >>very atypical. >  > Quite. > P > When you've horribly mangled something and have a versioning filesystem you'll > be thankful.  eI 1.  Any programmer worth his salt saves intermediate versions of his workIB in case a roll back is required.  Even if the system has versions.  H 2.  Any of the source management tools some of which have been availableH on Unix since the early days (RCS, SCCS, CVS) make rollbacks possible if" you decide you went the wrong way.  E But, just like with VMS, it is the programmers responsibility to makeoD use of the tools available to him. (you can set the versions to 1 inF your login.com and I have seen students do this in order to save space because their quotas were low.)m  J It always comes back to the same thing, On ei snot necessarily better thanJ the other, just different.  Better or worse is in the eye of the beholder.   bill   -- oJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   n   ------------------------------  # Date: Mon, 28 Jul 2003 14:16:57 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense8 Message-ID: <q1caivosfbil487ms4q24pr6noj3muivna@4ax.com>  J On Sun, 27 Jul 2003 04:56:11 +0800, Paul Repacholi <prep@prep.synonet.com> wrote:  ) >jlsue <jefflsxxxz@sbcglobal.net> writes:r > = >> Not sure what you mean by "dismiss", but there are just noiE >> server-class systems vendors - today - that I know of making planseE >> for this chip.  That may just be an initial problem, and Intel mayh/ >> lose in the end, we'll have to wait and see.  >r >So how do you rate Cray?   D Cray is a very niche player.  Not too many businesses go to them for% general-purpose server-class systems.   K If they're planning to use AMD's cpus, that's fine with me.  But the market,& penetration will be very minimal, imo.   ------------------------------  % Date: Mon, 28 Jul 2003 12:52:32 -0400h* From: JF Mezei <jfmezei.spamnot@istop.com>4 Subject: Re: HP World: Why Alpha's Omega Makes Sense) Message-ID: <3F2554CF.4F662D26@istop.com>c   jlsue wrote:F > Cray is a very niche player.  Not too many businesses go to them for' > general-purpose server-class systems.. > M > If they're planning to use AMD's cpus, that's fine with me.  But the markete( > penetration will be very minimal, imo.  H Same argument could be made for why Intel spent so much to subsidize theL porting of VMS to IA64. Niche market. nobody will hear about it. But it willL just add to the list of niche systems that can run on IA64 to make IA64 look more popular than it really is.m  N The thing about Cray is that if they win some supercomputer contract, whateverH chip they are using will get lots of visibility and "glory" even if suchL contract is small (in terms of numbers). And that would help give AMD's chipA more credibility helping to gain more system makers as customers.-   ------------------------------  # Date: Mon, 28 Jul 2003 17:20:14 GMTl9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>74 Subject: Re: HP World: Why Alpha's Omega Makes Sense/ Message-ID: <iXcVa.966$we1.35@news.cpqcorp.net>m  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messaget# news:3F2554CF.4F662D26@istop.com...o > jlsue wrote:H > > Cray is a very niche player.  Not too many businesses go to them for) > > general-purpose server-class systems.e > > H > > If they're planning to use AMD's cpus, that's fine with me.  But the market* > > penetration will be very minimal, imo. >lJ > Same argument could be made for why Intel spent so much to subsidize the > porting of VMS to IA64.e  H Eh?  What money?  As far as I know, our budget doesn't include any moneyL from Intel.  But hey, if you say it enough maybe it'll make it true.  But soJ far, I haven't heard anything indicating direct or indirect funding of the& VMS operating system from a 3rd party.  6 > Niche market. nobody will hear about it. But it willI > just add to the list of niche systems that can run on IA64 to make IA64i look! > more popular than it really is.r >g  I Huh?  False popularity.  Interesting idea.  "Those sales shouldn't count,r because they use *that* O/S".i  G > The thing about Cray is that if they win some supercomputer contract,w whateverJ > chip they are using will get lots of visibility and "glory" even if suchI > contract is small (in terms of numbers). And that would help give AMD's: chipC > more credibility helping to gain more system makers as customers.:  D Hmmm.   Did the Cray based on Alpha's ignite a wave of Alpha buying?L Building lunatic fringe systems is cool stuff, but I'm not quite sure it hasF much bearing on the purchasing of most consumers "Hey, lets buy that 4K processor Operon-thingy -- Cray uses thousands of them in that big-*ssed MPr system, so it must be good".   ------------------------------   Date: 28 Jul 2003 17:05:44 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)5 Subject: Re: IDC: HP ranks No. 1 in 2002 HPTC revenuee9 Message-ID: <bg3l58$jtmk7$2@ID-135708.news.uni-berlin.de>d  = In article <734da31c.0307232259.2a34d805@posting.google.com>,y* 	icerq4a@spray.se (David Svensson) writes: > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<bfm842$gqn$2@new-usenet.uk.sun.com>...D >> David Svensson wrote: >> > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote in message news:<bfh0jr$lsd$1@new-usenet.uk.sun.com>... >> >   >> >>Keith Parris wrote: >> >>:" >> >>>From HP World News, July 17: >> >>>@ >> >>>"HP ranks No. 1 in 2002 high-performance computing revenue >> >>>T >> >>>HP cited industry research firm IDC to claim it is the worldwide market leaderT >> >>>for High Performance Technical Computing (HPTC) in 2002. IDC's "Worldwide HighO >> >>>Performance Systems Technical Computing Census 2002" report shows that HPtT >> >>>commands 34 percent revenue share, more than a five percentage point lead over >> >>>IBM."o >> >>>2 >> >>>http://biz.yahoo.com/bw/030714/145265_1.html >> >>n >> >>aF >> >>Shame that the 3 big DARPA contracts for HPTC systems in the HPCS@ >> >>program have gone in a pretty even split of ~50 million per" >> >>company to IBM, Sun and Cray. >> > a >> >  F >> > I can understand that Sun and Cray are in need for help, but IBM? >> eC >> Interesting Idea HP didn't get a DARPA award because they didn't  >> need it ! >> m
 >> Nice spin.k >>   > C > Yes. :) I was looking at the latest TOP500 supercomputer list anddD > there were very few Sun and Cray machines there. On the other hand) > there were lots of IBM and HP machines.h  J And, remembering the name of this newsgroup, how many of them were running OpenVMS?   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   h   ------------------------------  % Date: Mon, 28 Jul 2003 13:20:34 -0400-# From: "Dan Allen" <dallen@nist.gov>25 Subject: RE: IDC: HP ranks No. 1 in 2002 HPTC revenuez: Message-ID: <JFEPKAPBPMDFDBOIANGDGEJPDLAA.dallen@nist.gov>   > > E > > Yes. :) I was looking at the latest TOP500 supercomputer list and.F > > there were very few Sun and Cray machines there. On the other hand+ > > there were lots of IBM and HP machines.u > L > And, remembering the name of this newsgroup, how many of them were running
 > OpenVMS? >  > bill >  > --  L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |C > Scranton, Pennsylvania   |         #include <std.disclaimer.h>     >d  , 	Hmmm..... Info-Vax is were I'm standing ;-)   	Dan     ------------------------------   Date: 28 Jul 2003 17:31:34 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)5 Subject: Re: IDC: HP ranks No. 1 in 2002 HPTC revenuee9 Message-ID: <bg3mlk$jtmk7$4@ID-135708.news.uni-berlin.de>b  : In article <JFEPKAPBPMDFDBOIANGDGEJPDLAA.dallen@nist.gov>,& 	"Dan Allen" <dallen@nist.gov> writes: >  >  >> > "F >> > Yes. :) I was looking at the latest TOP500 supercomputer list andG >> > there were very few Sun and Cray machines there. On the other hand , >> > there were lots of IBM and HP machines. >>  M >> And, remembering the name of this newsgroup, how many of them were running  >> OpenVMS?r >> D >> billo > . > 	Hmmm..... Info-Vax is were I'm standing ;-) >  > 	Dan s  O OK, same question with one small change.  How many of the top 500 were VAX? :-)l   bill$ (who is reading this on comp.os.vms)   -- eJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   x   ------------------------------  # Date: Mon, 28 Jul 2003 15:35:57 GMTa& From: jlsue <jefflsxxxz@sbcglobal.net>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World:  Why Alp 8 Message-ID: <ucgaiv4hopkutpgc2rq50fi77psqfdng15@4ax.com>  7 On Fri, 25 Jul 2003 22:57:28 -0500, "David J. Dachtera"v <djesys.nospam@fsi.net> wrote:  
 >jlsue wrote:e >>  N >> His story doesn't have to change.  That's no longer the point, imo.  He hasK >> every right feel the way he does and to state so.  But to color each andMI >> every future comment/announcement based on something that happened twomL >> years ago is just not productive.  And it's just not accurate to continue( >> to use that same out-dated yardstick. >nA >I have a major problem with that analogy: unless there's been antI >official change issued by the bureau of standards, weights and measures, D >then a yardstick is a yardstick, a metrestick is a metrestick, etc.  J If you've got some measure that 's controlled by the official bureau, thenE you've got a point.  In this case, it's getting to be the spurned aree upset.   >fF >All in all, trust once broken is not easily won back, except from theC >gullible. As the proverb goes, fool me once, shame on you; fool me( >twice, shame on me. t  F I totally agree.  But to be able to win back that trust, there must beG opportunity.  And those opportunities must occur over time.  As much asrK there is some screaming for a quick solution so that trust can be returned,  this just can't happen.t  K But also don't forget that sometimes actions are taken contrary to previousaF business plans.  It may be imperative for those actions to be taken inG order to maintain a business presence.  Those on the outside may not benH aware of all of the issues involved, and it's not always right for thoseC with the responsibility to disclose everything that goes into theirt decision making.  K If stock holders feel they are being lead astray, then they should organize D and revolt.  Lacking that, it's possible that they, too, believe the! company is doing the right thing.t   ------------------------------  # Date: Mon, 28 Jul 2003 14:48:07 GMTy& From: jlsue <jefflsxxxz@sbcglobal.net>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alphd8 Message-ID: <jadaiv4hhf8670qq0n273tj6k4v7snvqnt@4ax.com>  H On Sat, 26 Jul 2003 01:25:50 -0400, "Bill Todd" <billtodd@metrocast.net> wrote:   >a4 >"jlsue" <jefflsxxxz@sbcglobal.net> wrote in message3 >news:cbb3ivg2tfbquv39ustoo7oojqg55sel4t@4ax.com... K >> On Wed, 23 Jul 2003 18:27:52 -0400, "Bill Todd" <billtodd@metrocast.net>t	 >> wrote:y >> > >>H >> I'm working with many, many customers, and though nobody was entirely >happy( >> about this, almost all have moved on. > H >Many to other vendors - though you're probably not 'working with' those >particular people any more.  C In which case, they've moved on... which has been my point exactly.n+ They've got nothing to gripe about anymore.h   >>K >> Making predictions about supposed future behavior is nothing but FUD, nop# >> matter how you like to couch it.n >t >tG >Claiming that past behavior should not be considered in dealing with atL >company is just plain stupid.  Such a claim coming from an employee of that; >company might be considered something even less admirable.f  H That's not what I'm claiming, of course.  Saying you're skeptical is oneG the thing, but making grand claims about future failures is an entirely  different one.  H The basic fact is that NOTHING that HPQ can do will make you happy.  YouI insincerely claim something about wanting an apology... which is merely a A convenient excuse to never change your mind since you know that'sy impossible.    > B >  And if you're proved to be right, I'd even give you the "I told >> you so".e >gM >I don't choose to wait around to be proved right yet again:  I choose to try  >to force a different outcome.  H This is utter hogwash.  If you were trying to force a different outcome,F you wouldn't waste your time writing diatribes in cov.  Nobody in here> believes that something written here will change the company.    >M >>K >> It's the constant pounding, and using that to drive home that nobody cane >bea >> trusted anymore, so why try,  > A >I've never claimed that *nobody* could be trusted, just cHumPaq.e >e' >> that makes the effort so much waste.p >iJ >If *I* thought it were a waste, I wouldn't waste my time on it.  The factJ >that the Alphacide appears to have cost cHumPaq a *net* loss in profit ofL >hundreds of millions of dollars annually, and the likelihood that this lossJ >would have been far less if they had been allowed to lead their customersJ >like sheep without any opposition, makes me feel that the effort has been >worthwhile.  G What?  You think your writing in here had anything to do with all that?  Really?    >>I >> And the "consequences" that would befall them in this free-market is alG >> significant loss of customers.  That hasn't happened, so maybe, justr >maybe,e >> there's more to the story.e >oK >Let's see:  VMS systems went from $4 billion in annual revenue (June, 2000lI >statement by Rich Marcello, repeated in a March, 2001 slide presentationoC >*well* after the dot-com boom started going bust - and the limitedaD >information in the quarterly reports from Compaq corroborated VMS'sM >resilience in the face of that bust right up to the Alphacide) to $2 billiontK >in annual revenue (December, 2001 figure in a Compaq response to a GartneriF >comment).  And that's for a system that *was* planned to be ported toK >Itanic, so one can hardly imagine that Tru64 revenues ($3 billion annuallyf( >prior to the Alphacide) did any better. >rL >Even recently, VMS system revenues were reportedly stated by Mark Gorham toI >be only $2.5 - $3 billion, with $500 million annual profit (vs. the $800tK >million Marcello quoted).  And Mark is hardly likely to have *under*statedt
 >the figures.t > L >No 'significant loss of customers'?  Bullshit.  When you consider how largeG >a percentage of the remaining system revenue likely came from on-goingbJ >service agreements for equipment no one was about to throw away before itJ >required an upgrade rather than new-equipment purchases, the loss becomes >even more staggering. >v  J Of course, these are only "obvioius" if you completely ignore the downturnK that was beginning in Nov 2000 (according to some), and became an avalancheaD after the 9/11 attacks.  The complete shutdown of the airlines aloneE destroyed lots of companies' business (consulting, for example).  ThetF entire market went way south, and it's not surprising at all that some: areas would see worse hits than others in uncertain times.  H Your analysis is incomplete if it ignores these and only quotes straight numbers.   ------------------------------  # Date: Mon, 28 Jul 2003 15:14:06 GMTl& From: jlsue <jefflsxxxz@sbcglobal.net>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alphr8 Message-ID: <6eeaiv03sf3akkc0ghroe0b534vtohilr0@4ax.com>  F On Sat, 26 Jul 2003 16:09:10 GMT, "John Smith" <a@nonymous.com> wrote:   >0E >I think that many of the complaints and concerns about the Alphacide  >stem from a few basic issues: >CG >1) The feeling that Compaq was 'two-faced' about the future of Alpha -aE >cheerfully promoting the future of Alpha to all until the day of thee >announcement on June 25, 2001.e  I I don't disagree with the problems that this has caused... but that was 2 
 years ago.   >l? >2) That all public documents from Compaq until the date of theyA >announcement indicated a substanital chip performance and systemeE >advantage for Alpha over IA64 for as far out as any foreseeable time ' >horizon could be reasonably predicted.S  C But chip performance is only one metric that makes for a successfulgI business.  When they say that it would be better than the competition, iteI needed to be MUCH better than the competition to have real impact to groweF the business.  During the huge market boom we weren't able to grow theH business for Alpha... in a downturn they could only expect it to get hit worse.  K And just going by recollections of Sun and IBM FUD against Alpha just prioroH to all that, it hadn't enjoyed all that much of a lead in performance in? the 2 years or so leading up to June 25th.  Sure, it'd leapfrogt3 competition, but was it enough to sustain business?i   >mG >3) A stated 25-year minimum life span for Alpha (whether that was from F >the date somebody first thought of an Alpha-like architecture in 1961< >;-)  or from the date of first-ship in 1992 can be argued).  J So what?  The chip certainly had that capability, but the business didn't.I And at the time that Alpha was starting up, nobody expected that business G critical computing would be served by so many cheap Intel systems.  Not B that this was the right thing for businesses to do - these systemsH certainly cause them multiple headaches - but most of the business world= seems to be controlled by bean counters, not technical gurus.-   >SF >4) That the manner in which the announcement was done, ie. everythingF >you've told your bosses about Alpha based on Compaq's committments toC >you is now null and void and one now looks like a total asshole toeD >your organization - kiss any chance of promotion, or bonus, or evenC >having a job tomorrow goodbye - your personal credibility is shot.i  I Yep.  Big problem.  Not that cpq was responsible for the idiot management G and how they reacted.  The fact is that even since that time there haveoH been significant improvements, and one's management could continue theirJ plans for quite a long time and still reap the benefits.  If they panicked: and reacted adversely, it's more their problem, not CPQ's.  G We still have some significant orders for AlphaServer systems - running K OpenVMS, and also lots of them for Tru64.  Apparently there are some coolersG heads who realize that the lifespan of their systems is well within theaI range of supportability, and they're getting new systems even today based  on this "dead" technology.   >aG >5) That there isn't any indication in the commercial market even todayhG >that uptake of IA64 is approaching any kind of commercially successfuleD >volumes - which appears to negate any statements about lower costs.  I That is not at all a reasonable conclusion.  IA64 is NOT a mature product J yet.  Sure, it's late - much later than previous releases - but it's stillH very early in it's lifecycle.  Commercial success for most systems isn'tG graded until they have a few years of production-grade systems built on  them.t   >sB >6) The sudden impact the announcement had on sales of Alpha & VMSG >which in the minds of many customers created a very real threat to thetG >survival of VMS, notwithstanding the greasy similitudes of Capellas toiB >the contrary. In other words, FUD of Comapq's own creation due to8 >distrust of the organization and the senior management. >y  F Hokay.... now it's two years later, re-stated AlphaServer roadmaps areK being implemented as planned, customers can still get the systems they needeJ (and many are), and the IA64 port is going very well.  Customer's see thatF they'll be able to move from alpha to IA64 if/when they determine it'sH best..  Much of the FUD spread about what CPQ/HPQ intended to do to/withD VMS have proven to be false ("The port of OpenVMS to IA64 will never occur").   ------------------------------  # Date: Mon, 28 Jul 2003 15:28:55 GMTt& From: jlsue <jefflsxxxz@sbcglobal.net>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alphh8 Message-ID: <pjfaiv4mqthj52p9c8pk8qak5g12hnns0l@4ax.com>  F On 26 Jul 2003 09:36:02 GMT, "Dave Weatherall" <djweath@attglobal.net> wrote:  D >On Fri, 25 Jul 2003 22:47:29 UTC, jlsue <jefflsxxxz@sbcglobal.net>  >wrote:e >eI >> On 25 Jul 2003 06:40:57 GMT, "Dave Weatherall" <djweath@attglobal.net>s	 >> wrote:3 >3G >> >Ok, then just accept Bill and the other people who've feel they've sJ >> >been let down, or other, stronger, emotions, as one of the risks. They7 >> >will complain and seek to document their complaint.c >> tN >> And they continue to complain, and complain, and complain, as if it's going >> to change the past. >> nK >> If you want to effect a positive change, that's not going to do it.  AndsI >> besides, who in this forum is in any position to do anything about it.k >> iJ >> If I have to accept that they will complain about it, then they have toJ >> accept that I'll continue to complain about their complaints... ;-) ;-) >oG >Well as Dave D, with echoes from Bill, pointed out, forgetting how you F >were done over once leads you getting done over again (and again and  >again....).  F Nobody ever said to forget.  And I also expect folks to be suspicious.J Voicing suspicions is quite a bit differently than stating some prediction as fact, though.  H And constantly bringing up the so-called analysis of 2001 isn't all that! useful for anyone anymore anyway.e   >eG >You can probably dismiss this as the response of someone who has seen OF >yet another Sun machine arrive and on the same day be told that some G >mangement figures have decided they will remove the dependency on VMS .D >systems and move all our stuff to Unix. It won't be on HP machines  >either.  J I don't deny that some customer will choose this route.  But the only realG thing that HP can do now is show a consistent pattern of reliability ind their business commitments.-  B This expected "pattern" implies that there's no way that it can beF short-cutted by any other company "announcement".  It only comes afterJ time.  So the most that we can say is let us show you over this time.  YouK don't have to buy-in to every commitment made, but at least realize that inuK order to show this "pattern" they do have to make commitments and show thatf they keep them.a  E It's just as invalid for the naysayers to set up a "test" that has nohI possible solution (i.e., you've shown us to be untrustworthy, we want youeB to prove yourself trustworthy but we deny you the ability to prove
 yourself).   ------------------------------    Date: 28 Jul 2003 16:51:03 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alph26 Message-ID: <20030728165103.21734.qmail@gacracker.org>  < On Mon, 28 Jul 2003, jlsue <jefflsxxxz@sbcglobal.net> wrote:   <snip>  G >Hokay.... now it's two years later, re-stated AlphaServer roadmaps are L >being implemented as planned, customers can still get the systems they needK >(and many are), and the IA64 port is going very well.  Customer's see thatoG >they'll be able to move from alpha to IA64 if/when they determine it'sEI >best..  Much of the FUD spread about what CPQ/HPQ intended to do to/withoE >VMS have proven to be false ("The port of OpenVMS to IA64 will never>	 >occur").n  K There's just one thing missing, a gaping hole in any strategy for VMS . . .=    . . . Marketing.I    I I've seen indications that almost every other issue that's been a bone of I contention on this newsgroup is being addressed (Or at least well-meaningDK attempts to do so exist).  Yet, nobody seems to have come to the conclusionsL that a few well-placed adverts will help to kill off the "VMS is dead" meme,+ *and* back up some of those other efforts. t  G It needs to be a two-pronged approach.  Firstly, the techies need to besM cluebatted with VMS information - witness the recent crossposted thread wherecJ unix people were completely unaware of what "standard" open source runs onJ VMS.  Secondly, those that make the buying decisions need targetted.  MakeN them aware VMS still exists, isn't going away anytime soon, and is more stable- and secure than any competing unix platform. s     Doc. -- mK OpenVMS.         Eight out of ten hackers prefer *other* operating systems.rK [New PGP Key - Get via finger]        http://deathrow.vistech.net/BOFH/doc/T   ------------------------------  # Date: Mon, 28 Jul 2003 15:58:42 GMTw& From: jlsue <jefflsxxxz@sbcglobal.net>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alphk8 Message-ID: <qpgaivcmm411jp9h7em0d2lgaugld2qskn@4ax.com>  H On Sat, 26 Jul 2003 02:09:43 -0400, "Bill Todd" <billtodd@metrocast.net> wrote:   >.4 >"jlsue" <jefflsxxxz@sbcglobal.net> wrote in message3 >news:h7d3iv0dd82odeq3u9lplj4dv0pisdgbrq@4ax.com...eI >> On Tue, 22 Jul 2003 12:48:48 -0400, David Froble <davef@tsoft-inc.com> 	 >> wrote:  >3 >... >  >> >Some of the holes: >> >K >> >Some HP employees now publically embrace the questionable story put outk >byeG >> >Compaq.  There may be more self interest for them doing so than ther >actions ofTL >> >others.  While I can understand such self interest, I can also recognize >it. >>L >> Some of us don't embrace or non-embrace it.  Some (many?  most?) are justI >> working to make a success of that busines in which we're living.  Whatr6 >> might have been really just doesn't matter anymore. >iL >One can understand why it may not matter to *you* (though the reputation ofI >my employer would matter at least somewhat to *me*), and why *you* would E >just like to move on with minimal fuss.  However, customers may have-K >significantly different goals than yours are - and therefore significantlyuK >more interest in ascertaining whether the kinds of things that happened toi >Alpha might happen to VMS.3  K Some time you might read the AA prayer.  I worry about things I can change,sH and realize that others will do what they will.  If the decisions made 2K years ago were too damaging to the company, then that would effect negativeeK results in business terms... and the company would be careful not to repeatr those actions.  I I have no idea what the consequences of (or even they're understanding ofi  the consequences of) 6/2001 are.  K And I have NEVER trivialized what customers feel about those decisions.  OnsK the other hand it's not always healthy to let the past keep drawing up suchD negative emotions.   >i >> >> >K >> >Compaq used statements from those who may have had differences with thee >AlphaK >> >CPU developers to support it's story, but not one word from those Alpha  >CPUH >> >developers, the very ones who you'd expect to have the most relavent >statementsSJ >> >to make.  Now there were some rumors of off-the-record statements from >someeI >> >Alpha CPU developers, it's understandable if they fear to dispute the2 >'official'rK >> >statements of their employer, who can exert enormous financial pressureM >on suchJ >> >employees.  I'd think that if the Alpha CPU developers agreed with the >story,o. >> >there would have not been any such rumors. >eJ >Those weren't 'rumors', they were (at least in my case) direct reports ofF >statements made by Alpha architects with the proviso that they not beI >attributed (and in some cases with the requirement that they be somewhat L >paraphrased, and in a few cases just as deep background not for publicationM >at all).  Of course, Brannon Batson made a few *on- the-record comments both  >here and in comp.arch as well.R >rF >Those architects made it clear that  1) there were *no* unanticipatedL >problems with EV8 (for example, Terry's suggestion that SMT would have costL >1 GHz in processor speed was complete crap),  2) that they had every reasonH >to believe - right up until *after* the Alphacide - that EV8 would haveK >beaten the pants off contemporary Itanics, and  3) that they felt that hadsM >Compaq wished to back Alpha rather than marginalize it Alpha would have beena1 >both highly successful and immensely profitable.s >D  K But, again, there are many sides to this discussion.  You have probably not8H been privy to the many disagreements as to whether Alpha was really ever profitable.i  H I personally believe it was profitable.  But apparently there was enough- information about to call that into question.-  K That outside business reports would show it to be profitable is no surprise E to me.  Hey, I have contact with lots of different companies, and I'moE beginning to think that many of them (maybe even most of them) aren'trH really making money at all - that it's all accounting gimmicks.  I mean,G I've seen companies spend $20+ million dollars on projects that have nooK business benefit whatsoever.  Seriously.  But that's not what gets reported>J to upper management, you can bet your bottom on that one.  (joke intended)  M >> Look, superior is judged on many levels.  More than architecture elegance,fG >> and speed.  The desire for the business to continue investing in thep >entireeM >> internal infrastructure to support the Alpha, and including the real majoreG >> investment they'd have to make in marketting to "catch up" in market  >share,e >nI >Even with lack-lustre support, Tru64 was *already* catching up in marketeK >share:  it was growing far faster than the larger Unixes (and they weren'tdL >*infinitely* larger anyway:  IIRC HP-UX had about 3x Tru64's market share -I >when you add in VMS's market, that made Alpha a *significant* competitorl >even without half-trying).   4 OS success is not the same as AlphaServer success.   >cK >> may have just been outweighed by the easier route of using the IA64, andw8 >> tagging-along on the marketing of that large company. >iE >Unfortunately, that's not what they *said*:  they claimed that Alpha G >couldn't be profitable (a lie:  it already *was* profitable, even with D >minimal marketing - zero marketing for VMS) and couldn't maintain aM >significant performance lead over Itanic (another lie, at least based on the>C >statements of the architects in the best position to evaluate thatT >question).a  G Again, there were insiders who, presumably have better information thanm> you, who disagree with this "already 'was' profitable" claim).   >  >  And it would have tonG >> last some number of years for the Alpha investment to recover marketi >share, 2 >> and begin paying back and making it worthwhile. >eK >Alpha *already* was profitable despite being sorely neglected:  to suggestsH >that visible (and credible) better treatment by its owner wouldn't haveG >significantly improved its market penetration (and started paying backa! >*immediately*) is more bullshit.a  J Again, you make assumptions that you have all the information necessary toK second-guess the info that the BOD had - that's armchair management at it'sS5 best, and you don't have to take on any of the risks.r   >t >  Many many people wereL >> calling it a dying chip already - even our most infamous Sun contributor. >tJ >The *reason* they were calling it a dying chip was because of the visible+ >presence of its owner's knife in its back.e  I No, the reason was because they saw that incredible performance lead slipeI away.  There's no evidence that this was done due to a knife in the back.r   >l >>D >> Taking all that in (and it's not the complete story), include theM >> Micro-Econ 101 concept of opportunity cost, and a past of least resistanceu >> makes a lot of sense. >sK >If you're not intersted in exploiting proprietary advantages for profit, I2J >suppose.  Which is why treating VMS the same way would also make a lot of" >'sense' to these kinds of people.  A I never deny that it's a possibility.  But, claiming that it's ano, eventuality is also not backed by any facts.   >sE > I'm really kind of surprised by some of this business analysis that I >> contends that Alpha was such a winner for the company.  There were/are M >> folks inside who called Alpha the sink-hole that never made a dime for theoK >> company.  some of these people are very loud in extolling their opinionse >oniL >> this topic.  I wished they showed up in c.o.v, becasue you'd be surprisedJ >> at how vitriolic THEY get - they make Bill Todd look positively docile. >bM >Guess I'll have to work more on being assertive, then.  As for their showingoH >up here, I'd welcome it - *if* they had any credible numbers to back upJ >their contentions (as I do for mine) rather than just wanted to blow more >smoke.   J Why would you believe that YOUR numbers are more credible than theirs?  DoF you think external financial statements tell the whole story?  Really?   >aH >If you'd like to become informed about this issue, you could start withK >back-copies of quarterly reports for the duration of Compaq's ownership ofoL >Alpha - or you could dig around in some of my old posts.  Suffice it to sayL >that Alpha systems made a *great deal* more money for Compaq than any otherK >business it conducted (Tandem may have had better margins, but it was only-+ >about 1/5 the size of the Alpha business).u >0  J I do not make any claims about profitabililty of Alpha.  I believe that itK was profitable... how much so, and whether it was enough and sustainable isiI not information that I would have access to.  I merely recognize that noteH all information required to fully understand the decision will appear inD public documents.  It pretty easy to understand that those documentsH reflect the story that the company officials want them to tell.  This is true of any company.   ------------------------------  % Date: Mon, 28 Jul 2003 13:10:09 -0400 * From: JF Mezei <jfmezei.spamnot@istop.com>Y Subject: Re: Intel's had Dirty Bombs Anthrax and everything! (Was: Re: HP World: Why Alph ) Message-ID: <3F2558EF.71C14127@istop.com>n   jlsue wrote:E > The basic fact is that NOTHING that HPQ can do will make you happy.n  L It wouldn't take much of HP to make me happy. However, due to the total lackN of trust, HP would have to show this in a sustained way before I beleived they really meant it.   ------------------------------  # Date: Mon, 28 Jul 2003 12:39:09 GMTy# From: "John Smith" <a@nonymous.com>y; Subject: Re: Migrate obsolete VAX/VMS SW to OpenVMS ItaniumsH Message-ID: <NP8Va.73904$vz%.48376@news01.bloor.is.net.cable.rogers.com>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3F21FD4D.B80F6CA6@fsi.net...n > "Stanley F. Quayle" wrote: > > / > > On 25 Jul 2003 at 12:29, Bob Koehler wrote: F > > >    I thought an updated version had been released to expand this to? > > >    later versions.  Of course, you may have code from 1.x 
 running on > > >    your VAX. > >w > > From release notes:t > > E > > - DECmigrate (VEST) 1.1A can migrate code that runs on VAX V5.4-2v ifC > > it was linked on V4.0 or later.  Images linked after V5.4-2 mayg failA > > (or not).  Requires Alpha V6.1 or later on the target system.s > >sE > > - OpenVMS Migration Software for VAX to Alpha (OMSVA) (previously E > > known as DECmigrate) can migrate code that runs on VAX V7.3 if itc was:D > > linked on V4.0 or later.  Images linked after V7.3 [not yet, butB > > check the roadmaps] may fail (or not).  Requires Alpha V6.2 or laters > > on the target system.6 > >p' > > The release notes for OMSVA are at:e > >c > >aF http://h71000.www7.hp.com/openvms/products/omsva/omsva_012_release_not
 > > es.pdf > > C > > Note that NO ATTEMPT was made to migrate from versions prior to  V4.0.e& > > How many people does this affect?? >mD > I have a better question: How many more VMS sites can we afford to lose?b    C As many as HP decides to lose through inaction, lack of advertisingnE and effective marketing, neglect, stupidity, and deliberate action tos* force VMS from the minds of new customers.   ------------------------------    Date: 28 Jul 2003 14:09:14 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>; Subject: Re: Migrate obsolete VAX/VMS SW to OpenVMS Itaniuma6 Message-ID: <20030728140914.18598.qmail@gacracker.org>  9 On Mon, 28 Jul 2003, "John Smith" <a@nonymous.com> wrote:u= >"David J. Dachtera" <djesys.nospam@fsi.net> wrote in messaget" >news:3F21FD4D.B80F6CA6@fsi.net... >> "Stanley F. Quayle" wrote:i >> >0 >> > On 25 Jul 2003 at 12:29, Bob Koehler wrote:G >> > >    I thought an updated version had been released to expand this  >to @ >> > >    later versions.  Of course, you may have code from 1.x >running onp >> > >    your VAX.h >> > >> > From release notes: >> >F >> > - DECmigrate (VEST) 1.1A can migrate code that runs on VAX V5.4-2 >ifyD >> > it was linked on V4.0 or later.  Images linked after V5.4-2 may >failtB >> > (or not).  Requires Alpha V6.1 or later on the target system. >> >F >> > - OpenVMS Migration Software for VAX to Alpha (OMSVA) (previouslyF >> > known as DECmigrate) can migrate code that runs on VAX V7.3 if it >wasE >> > linked on V4.0 or later.  Images linked after V7.3 [not yet, but C >> > check the roadmaps] may fail (or not).  Requires Alpha V6.2 orb >later >> > on the target system. >> >( >> > The release notes for OMSVA are at: >> > >> >G >http://h71000.www7.hp.com/openvms/products/omsva/omsva_012_release_noti >> > es.pdfs >> >D >> > Note that NO ATTEMPT was made to migrate from versions prior to >V4.0.' >> > How many people does this affect??s >>E >> I have a better question: How many more VMS sites can we afford too >lose? >o >wD >As many as HP decides to lose through inaction, lack of advertisingF >and effective marketing, neglect, stupidity, and deliberate action to+ >force VMS from the minds of new customers.o  N Go to the following URL, print the graphic out on stiff card, trim to size and' address to your favourite person in hp.>  + http://vmsbox.cjb.net/graphics/postcard.JPGC  ; I'm sure John can provide a list of people who'd like this.h     Doc. --  K OpenVMS.         Eight out of ten hackers prefer *other* operating systems.mK [New PGP Key - Get via finger]        http://deathrow.vistech.net/BOFH/doc//   ------------------------------  % Date: Mon, 28 Jul 2003 13:47:13 -0400 0 From: "Brian Tillman" <Tillman@sparkingwire.com>; Subject: Re: Migrate obsolete VAX/VMS SW to OpenVMS Itaniumn$ Message-ID: <3f2561a2$1@news.si.com>  D >Some people are perfectly happy on their VAXes (or PDP-11's or ...)< >They work, they don't have sources or development staffs or@ >(non-defunct) vendors.  These people are never going to migrate@ >and wouldn't even if there were brand-new 500 VUP MicroVAX-XVII# >systems for sale in every CompUSA.e  I But then others of us would.  We can migrate our apps from one machine todJ another of the same architecture, but changing architectures would cost us	 millions.n --  I Brian Tillman         Internet: Brian.Tillman at smiths-aerospace dot com 5 Smiths Aerospace  Addresses modified to prevent SPAM.nD 3290 Patterson Ave. SE, MS 1B3 Replace "at" with "@", "dot" with "." Grand Rapids, MI 49512-1991 8        This opinion doesn't represent that of my company   ------------------------------  # Date: Mon, 28 Jul 2003 16:54:38 GMTd9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>H) Subject: Re: NEWBIE: DECWindows Bit DepthA/ Message-ID: <izcVa.962$Ic1.55@news.cpqcorp.net>   I The PCI and AGP versions of this card should be available (single headed)rJ right now.  Multi-headed 2 and 3D should be available in ~ a month.  It isI supported on all EV6 and EV7 based platforms except TurboLaser (8xxx) andhK the XP1000.  The XP1000 firmware was not updated, so while we don't supporth) it - a single head Radeon 7500 will work.s   Public Service Announcement:  J Only the HP card is "supported".  Off-the-shelf 7500's will probably work,B but we do not test them (cards can vary from bugs/revisions/memoryJ speeds/memory sizes), and if you have any problems -- don't call us unlessG you can reproduce it on an HP card.  Besides, your purchase of the cardm1 allows us to continue providing graphics for VMS.I      + "Dirk Munk" <munk@home.nl> wrote in messageD, news:bft59b$b1e$1@news4.tilbu1.nb.home.nl... > Hoff Hoffman wrote:AL > > In article <bfs881$s2l$1@pcls4.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:sL > > :Semi-related:  What is the highest resolution now available on VMS, and" > > :what card supports that size? > >nG > >   The HP 3X-PBXGG-AB (Radeon 7500) AGP card, AFAIK, at 2048 x 1536?A > >eK > >     http://h18002.www1.hp.com/alphaserver/products/graphics/radeon.htmlV > > J > >   Check the support for the card, as there are (or at least were) someK > >   (at least initial) platform restrictions around OpenVMS Alpha supporteK > >   for this graphics controller, and I don't know off-hand if there is an= > >   PCI version that (presently) has OpenVMS Alpha support.  >lH > The PCI version is officially supported on the DS10. I'm using a clone versionaK > on my (hobby) DS10, works like a dream. If I'm not mistaken the Radeon is  onlyJ > supported on the systems with EV6x and EV7x cpu's. I suppose there is no realI > reason to assume a PCI Radeon 7500 would not work on other such systemse then a DS10. >RJ > But please read the release notes for the Radeon driver (in the graphics patch < > for VMS7.3-1), because there are certain restrictions etc. >. > >  (And mostK > >   Alpha systems do not have an AGP slot -- but since you indicated onlynL > >   "VMS" in your question and (unfortunately) did not indicate a specificA > >   architecture or specific platform, this answer might be tooe generic...)o > >nJ > >   Please check the AlphaServer and AlphaStation hardware compatibilityB > >   lists for details of supported peripherals on specific Alpha
 platforms,L > >   of course.  (I expect you know the location of these support matrixes,H > >   but for those that do not, please see the URL in the OpenVMS FAQ.) > >yL > >   Other high-end cards include the PowerStorm 350 and 3DLabs Oxygen VX1,/ > >   with both having support for 1920 x 1200.' > >t1 > >   PowerStorm 4D20 gets as far as 1600 x 1200.r > >rH > >   There may well be some other moderate-resolution cards around (and thatK > >   also have OpenVMS Alpha support, of course), this list has various of(K > >   the higher-resolution (and supported) graphics cards I am immediately  > >   aware of.  > >p* > >  ---------------------------- #include' <rtfaq.h> ----------------------------- 5 > >     For additional, please see the OpenVMS FAQ --u www.hp.com/go/openvms/faqp. > >  --------------------------- pure personal# opinion --------------------------- I > >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.come > >m >t   ------------------------------  # Date: Mon, 28 Jul 2003 12:47:56 GMTo# From: "John Smith" <a@nonymous.com>l: Subject: Re: OpenVMS homepage and 'sales.liveperson.net' ?H Message-ID: <0Y8Va.73952$vz%.16897@news01.bloor.is.net.cable.rogers.com>  : "Jonathan Boswell" <jsb@ost.cdrh.fda.gov> wrote in message* news:3F21918B.713FFB5D@ost.cdrh.fda.gov... > John Smith wrote:o6 > > But you'd only want the VMS server catalog anyway. >-D > I don't remember ever seeing one of those.  There was from time to time aB > hardware edition, a software edition, a full-line catalog, and I think I sawHF > network editions and workstation editions.  (I can't lay my hands on
 an example# > of the latter two at the moment.)   E I recall the same catalogs as you do above, however my point was thatbB *if* HP ever got around to being an effective marketer in the sameE sense that Dell is, they'd have catalogs/flyers in the mail each weekdD to those on their mailing list. You know the ones - 16 pages printerC on flimsy glossy stock with 7 lines of text beside each picture (inmF other words, just enough information for the average PHB in government> or corporate America to make a multi-million dollar purchasing
 decision).  C In Dell's case they sell only Wintel so it makes some sense to havehE everything from laptops and low-end destops through to servers in thed one catalog.  F If HP decided to create similar catlogs/flyers, it would make sense toF have some mention of Alpha & IA64 baoes in the general public-at-largeD catlog/flyer, but it would also make a great deal of sense to mail aA separate Alpha - IA64 server/workstation catalog/flyer as well toe) CIO/CTO/managers and grunts in the field.s  > It was to this latter category of 'publication' to which I was
 referring.   ------------------------------    Date: 28 Jul 2003 08:02:32 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)r+ Subject: Re: Packed decimal arithmetic in C.3 Message-ID: <jIkNbQoNB2Q0@eisner.encompasserve.org>g  f In article <bfs9e5$ieqqm$1@ID-120847.news.uni-berlin.de>, "John Travell" <john@travell.uk.net> writes: > J > For the benefit of us Brit's, to whom a penny is part of our currency, aH > coin valued at precisely 100th part of one pound sterling, can someone6 > explain EXACTLY what America refers to as a 'penny'.  E    US penny is 1/100 of a US dollar.  For the last several decades itoC    looks to be made out of copper, but hasn't been solid copper fora    quite a while.I   ------------------------------  % Date: Mon, 28 Jul 2003 15:08:00 +0100b* From: "John Travell" <john@travell.uk.net>+ Subject: Re: Packed decimal arithmetic in Ct9 Message-ID: <bg3apm$kgvsn$1@ID-120847.news.uni-berlin.de>s  H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:jIkNbQoNB2Q0@eisner.encompasserve.org...oJ > In article <bfs9e5$ieqqm$1@ID-120847.news.uni-berlin.de>, "John Travell" <john@travell.uk.net> writes:i > >sL > > For the benefit of us Brit's, to whom a penny is part of our currency, aJ > > coin valued at precisely 100th part of one pound sterling, can someone8 > > explain EXACTLY what America refers to as a 'penny'. >tG >    US penny is 1/100 of a US dollar.  For the last several decades ittE >    looks to be made out of copper, but hasn't been solid copper fors >    quite a while.h >e  # Clearly the problem is terminology.eL I now understand that 'penny' is the unofficial slang or common (?) use name8 for the unit of currency 'officially' known as the Cent.  H It looks like at least some yanks cannot completely shake off their brit heritage :-)     -- John Travell  VMS crashdump expertise for hire john@jomatech.com  +44-(0)23-92552229 http://www.jomatech.com/       ---r& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.504 / Virus Database: 302 - Release Date: 24/07/2003p   ------------------------------  % Date: Mon, 28 Jul 2003 07:37:36 -0700u# From: "Tom Linden" <tom@kednos.com>h+ Subject: RE: Packed decimal arithmetic in Ct9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEIDHKAA.tom@kednos.com>a   >-----Original Message-----n0 >From: John Travell [mailto:john@travell.uk.net]$ >Sent: Monday, July 28, 2003 7:08 AM >To: Info-VAX@Mvb.Saic.Com, >Subject: Re: Packed decimal arithmetic in C >l >  >cI >"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in messagem. >news:jIkNbQoNB2Q0@eisner.encompasserve.org...K >> In article <bfs9e5$ieqqm$1@ID-120847.news.uni-berlin.de>, "John Travell"  ><john@travell.uk.net> writes: >> >B >> > For the benefit of us Brit's, to whom a penny is part of our  >currency, aK >> > coin valued at precisely 100th part of one pound sterling, can someonei9 >> > explain EXACTLY what America refers to as a 'penny'.a >>H >>    US penny is 1/100 of a US dollar.  For the last several decades itF >>    looks to be made out of copper, but hasn't been solid copper for >>    quite a while. >> >t$ >Clearly the problem is terminology.A >I now understand that 'penny' is the unofficial slang or common a
 >(?) use namel9 >for the unit of currency 'officially' known as the Cent.  >-I >It looks like at least some yanks cannot completely shake off their brit 
 >heritage :-)x3 Or Brits their German heritage penny < pfenning ;-)s >t >x >--e
 >John Travell:! >VMS crashdump expertise for hireD >john@jomatech.com >+44-(0)23-92552229. >http://www.jomatech.com/  >0 >0 >T >---' >Outgoing mail is certified Virus Free.I; >Checked by AVG anti-virus system (http://www.grisoft.com).hB >Version: 6.0.504 / Virus Database: 302 - Release Date: 24/07/2003 >  >  >---' >Incoming mail is certified Virus Free.r; >Checked by AVG anti-virus system (http://www.grisoft.com).hA >Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003r >e ---a& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003   ------------------------------  # Date: Mon, 28 Jul 2003 06:44:46 GMTa! From: inwap@inwap.com (Joe Smith)d$ Subject: Re: PDP-11 OS Release Dates9 Message-ID: <yD3Va.601$603.31853@iad-read.news.verio.net>g  + In article <bg1qka$dr2$1@bob.news.rcn.net>,t0 Glenn Everhart  <Everhart-nospam@gce.com> wrote:F >... It was common to refer to memory as "core" back then, whether it G >was made of MOS or ferrite, so pervasive had core become for a while. aE >After all you wanted to make sure nobody confused it with disk. The uF >older machines that used disk or drums for their main memory were of + >course not much remembered by the mid 70s.o   Remember IBM's nomenclature?    Primary Storage = core memory.A   Secondary Storage = Direct Access Storage Device (DASD) = disk.i  F It was funny listening to a IBM mainframe salesman talking about IBM'sG 80286 systems when they came out.  He said, "these applications requirehG 256 kilobytes of storage".  I pointed out to him the most people in theuI room interpreted that as needing a single floppy, as opposed to 256K RAM.d 	-Joe  -- t8 See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.   ------------------------------    Date: 28 Jul 2003 07:38:32 -0700( From: Patrick Scheible <kkt@drizzle.com>$ Subject: Re: PDP-11 OS Release Dates) Message-ID: <tqmfzkq67iv.fsf@drizzle.com>   1 Thomas Dickey <dickey@saltmine.radix.net> writes:l  @ > In comp.os.vms Glenn Everhart <Everhart-nospam@gce.com> wrote: > M > > Back then of course you'd spend a few thou to buy 16K words (16 bits) of tM > > memory. It was common to refer to memory as "core" back then, whether it  J > > was made of MOS or ferrite, so pervasive had core become for a while.  > - > perhaps you did (or recall people who did).o, > I didn't, and did not know anyone who did.  @ Just another datapoint, but calling memory "core" whether it wasE actual core or RAM was common where I was, silicon valley in the lateeD 1970s.  You can also see the remains of this usage today in the Unix core files.   
 -- Patrick   ------------------------------  % Date: Mon, 28 Jul 2003 18:53:10 +0800d, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: PDP-11 OS Release Dates- Message-ID: <87zniyorc9.fsf@prep.synonet.com>a  6 Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:  F > Semiconductor memory was referred to as MOS memory when it came out:. > core was ferrite torii on boards in drawers.  F As I remember, the 11/45 could be had with either MOS or Bipolar solid state memory, or good old core.    -- c< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.h@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 28 Jul 2003 20:12:15 +0800a, From: Paul Repacholi <prep@prep.synonet.com>$ Subject: Re: PDP-11 OS Release Dates- Message-ID: <8765lmonog.fsf@prep.synonet.com>   ! aek@spies.com (Al Kossow) writes:   D >> By the way, RSX-15 was released late 1970, then was ported to the >> 11 as RSX-11D (Hank Krejci).t  A > I've just scanned a 1971 version of the RSX-15 reference manualo> > www.spies.com/aek/pdf/dec/pdp15/DEC-15-GRQA-D_RSX15_1971.pdf  C > Do you happen to know where what the roots of the RSX design cameeC > from ? It doesn't seem to come from any DEC operating system fromh > the 60's.d  B 11M was descended from a real-time exec DC did at Du Pont. I'm not? sure how much it influenced the D side, or A, B, and C for thatn matter.e   -- u< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.6@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 28 Jul 2003 16:59:38 +01000' From: Elliott Roper <elliott@yrl.co.uk>t$ Subject: Re: PDP-11 OS Release Dates2 Message-ID: <280720031659385420%elliott@yrl.co.uk>  < In article <8765lmonog.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> wrote:  # > aek@spies.com (Al Kossow) writes:B > F > >> By the way, RSX-15 was released late 1970, then was ported to the! > >> 11 as RSX-11D (Hank Krejci).r > C > > I've just scanned a 1971 version of the RSX-15 reference manualt@ > > www.spies.com/aek/pdf/dec/pdp15/DEC-15-GRQA-D_RSX15_1971.pdf > E > > Do you happen to know where what the roots of the RSX design camesE > > from ? It doesn't seem to come from any DEC operating system from 
 > > the 60's.  > D > 11M was descended from a real-time exec DC did at Du Pont. I'm notA > sure how much it influenced the D side, or A, B, and C for thatt	 > matter.p  G Not a lot. RSX11D and everything else except 11S predated M. M's systemoF services macros were exactly the same as D's so that user code writtenF for D would run in M. For example, M's QIO arg lists included a coupleG of trailing commas that were intended to stop D code falling over, eveno# though the args meant nothing to M.a  E The internals of D, IAS etc. remained for ever quite different from Ms/ and its sibs. At least while I was looking. ;-)f  B If I may add a word of thanks to Dan Brevic for posting the RSX-15F history this morning. It did not do wonders for my day's productivity, but it was a fascinating read.   ------------------------------    Date: 28 Jul 2003 02:44:59 -0700, From: Georg.Nowak@sms-demag.de (Georg Nowak) Subject: Problems with NFS< Message-ID: <e7d8e959.0307280144.cc2073d@posting.google.com>   Hello,  F I'm trying to get NFS Maestro running with a VMS 7.3 machine (HP TCPIP: 5.1) and I'm always getting themessage "Bad Network Name".  D So I decided to test if the NFS Server is running OK on VMS. I tried to donF following mount on the same system, and i get following error message:  > TCPIP> mount dnfs0: /host=10.136.6.28 /path="/dkc600/SMSdemag"< %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS7:[000000]! -SYSTEM-F-TIMEOUT, device timeout"  C On a second terminal I enabled reply, and I got following messages:t8 %%%%%%%%%%%  OPCOM  28-JUL-2003 11:29:13.46  %%%%%%%%%%%% Message from user TCPIP$NFS on ALPH31u9 %TCPIP-S-NFS_MNTSUC, mounted file system /dkc600/SMSdemagu5 -TCPIP-S-NFS_CLIENT, uid=-2 gid=-2 host_name = ALPH31   8 %%%%%%%%%%%  OPCOM  28-JUL-2003 11:29:29.65  %%%%%%%%%%%% Message from user TCPIP$NFS on ALPH31<> %TCPIP-S-NFS_UMNSUC, file system /dkc600/SMSdemag is unmounted5 -TCPIP-S-NFS_CLIENT, uid=-2 gid=-2 host_name = ALPH31y   What am I doing wrong ?2      < Here are some more information, which might help to help me:   TCPIP> sh serv  F Service             Port  Proto    Process          Address            Statev  F BIND                  53  TCP,UDP  TCPIP$BIND       0.0.0.0             EnabledF BOOTP                 67  UDP      UCX$BOOTP        0.0.0.0           	  DisabledtF ESNMP                705  UDP      ESNMP            0.0.0.0           	  DisabledsF FINGER                79  TCP      UCX$FINGER       0.0.0.0           	  DisabledrF FTP                   21  TCP      TCPIP$FTP        0.0.0.0             EnabledF LPD                  515  TCP      TCPIP$LPD        0.0.0.0             EnabledF MOUNT                 10  TCP,UDP  TCPIP$MOUNTD     0.0.0.0             EnabledF NFS                 2049  UDP      TCPIP$NFS        0.0.0.0             EnabledF NTP                  123  UDP      TCPIP$NTP        0.0.0.0             EnabledF PCNFS               5151  TCP,UDP  TCPIP$PCNFSD     0.0.0.0             EnabledF POP                  110  TCP      UCX$POP          0.0.0.0           	  DisablediF PORTMAPPER           111  TCP,UDP  TCPIP$PORTM      0.0.0.0             EnabledF REXEC                512  TCP      TCPIP$REXEC      0.0.0.0             EnabledF RLOGIN               513  TCP      not defined      0.0.0.0             EnabledF RSH                  514  TCP      TCPIP$RSH        0.0.0.0             EnabledF SNMP                 161  UDP      TCPIP$SNMP       0.0.0.0           	  DisablednF TELNET                23  TCP      not defined      0.0.0.0             EnabledF TFTP                  69  UDP      TCPIP$TFTP       0.0.0.0             EnabledF XDM                  177  UDP      TCPIP$XDM        0.0.0.0             Enabled   TCPIP> sh proxy   ; VMS User_name     Type      User_ID    Group_ID   Host_namea  3 GNOW              ON              0           0   *93 UCX$NOBODY        ON             -2          -2   *2  
 TCPIP> sh mapl"             Dynamic Filesystem Map; Pathname                                Logical File Systema  / /dkc600                                 DKC600:m   TCPIP> sh export  1 File System                             Host namec  ) /dkc600                                 * ) /dkc600/SMSdemag                        *      Thanks!b George   ------------------------------  % Date: Mon, 28 Jul 2003 13:29:54 +0100e* From: Nic Clews <sendspamhere@[127.0.0.1]> Subject: Re: Problems with NFS' Message-ID: <bg34s4$fih$1@lore.csc.com>c   Georg Nowak wrote:  H > I'm trying to get NFS Maestro running with a VMS 7.3 machine (HP TCPIP< > 5.1) and I'm always getting themessage "Bad Network Name". > F > So I decided to test if the NFS Server is running OK on VMS. I tried > to dorH > following mount on the same system, and i get following error message: > @ > TCPIP> mount dnfs0: /host=10.136.6.28 /path="/dkc600/SMSdemag"> > %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS7:[000000]# > -SYSTEM-F-TIMEOUT, device timeouta  E Isn't DNFS0 the template, try DNFS1:, or as this error states, DNFS7:gA (Note: could be a bad steer, I've not tried mounting DNFS0 before  perhaps it does work)o  A As to your original error, you are using a 10.x.y.z address so be G careful which side of routers this address is expected to be used (i.e.r you may need a bridge).o  F Try replacing your 10.136.6.128 with 127.0.0.1 on the local system for
 your testing.a  0 (I'm not an NFS expert, just a few suggestions). -- a? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesg nclews at csc dot como   ------------------------------  # Date: Mon, 28 Jul 2003 16:21:38 GMTt; From: "John Gemignani, Jr." <jon-nope@thiswontworkossc.net>t Subject: Re: Problems with NFS; Message-ID: <m4cVa.4796$gn6.737534@news1.news.adelphia.net>t  9 "Georg Nowak" <Georg.Nowak@sms-demag.de> wrote in messagep6 news:e7d8e959.0307280144.cc2073d@posting.google.com... > Hello, >hH > I'm trying to get NFS Maestro running with a VMS 7.3 machine (HP TCPIP< > 5.1) and I'm always getting themessage "Bad Network Name". > F > So I decided to test if the NFS Server is running OK on VMS. I tried > to douH > following mount on the same system, and i get following error message: >h@ > TCPIP> mount dnfs0: /host=10.136.6.28 /path="/dkc600/SMSdemag"> > %TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS7:[000000]# > -SYSTEM-F-TIMEOUT, device timeoutl >aE > On a second terminal I enabled reply, and I got following messages:t: > %%%%%%%%%%%  OPCOM  28-JUL-2003 11:29:13.46  %%%%%%%%%%%' > Message from user TCPIP$NFS on ALPH31 ; > %TCPIP-S-NFS_MNTSUC, mounted file system /dkc600/SMSdemagh7 > -TCPIP-S-NFS_CLIENT, uid=-2 gid=-2 host_name = ALPH31s >s: > %%%%%%%%%%%  OPCOM  28-JUL-2003 11:29:29.65  %%%%%%%%%%%' > Message from user TCPIP$NFS on ALPH31 @ > %TCPIP-S-NFS_UMNSUC, file system /dkc600/SMSdemag is unmounted7 > -TCPIP-S-NFS_CLIENT, uid=-2 gid=-2 host_name = ALPH31d >p > What am I doing wrong ?l >T >y >s> > Here are some more information, which might help to help me: >o > TCPIP> sh serv >t= > Service             Port  Proto    Process          Addresse > Statee >t= > BIND                  53  TCP,UDP  TCPIP$BIND       0.0.0.0 
 >  Enabled= > BOOTP                 67  UDP      UCX$BOOTP        0.0.0.0m >  Disabled = > ESNMP                705  UDP      ESNMP            0.0.0.0r >  DisabledD= > FINGER                79  TCP      UCX$FINGER       0.0.0.0a >  Disabledo= > FTP                   21  TCP      TCPIP$FTP        0.0.0.0s
 >  Enabled= > LPD                  515  TCP      TCPIP$LPD        0.0.0.0a
 >  Enabled= > MOUNT                 10  TCP,UDP  TCPIP$MOUNTD     0.0.0.0 
 >  Enabled= > NFS                 2049  UDP      TCPIP$NFS        0.0.0.0s
 >  Enabled= > NTP                  123  UDP      TCPIP$NTP        0.0.0.0 
 >  Enabled= > PCNFS               5151  TCP,UDP  TCPIP$PCNFSD     0.0.0.0l
 >  Enabled= > POP                  110  TCP      UCX$POP          0.0.0.0s >  Disabled = > PORTMAPPER           111  TCP,UDP  TCPIP$PORTM      0.0.0.0b
 >  Enabled= > REXEC                512  TCP      TCPIP$REXEC      0.0.0.0r
 >  Enabled= > RLOGIN               513  TCP      not defined      0.0.0.0o
 >  Enabled= > RSH                  514  TCP      TCPIP$RSH        0.0.0.0>
 >  Enabled= > SNMP                 161  UDP      TCPIP$SNMP       0.0.0.0t >  Disabledr= > TELNET                23  TCP      not defined      0.0.0.0 
 >  Enabled= > TFTP                  69  UDP      TCPIP$TFTP       0.0.0.0r
 >  Enabled= > XDM                  177  UDP      TCPIP$XDM        0.0.0.0c
 >  Enabled >e > TCPIP> sh proxy  >w= > VMS User_name     Type      User_ID    Group_ID   Host_namei >e5 > GNOW              ON              0           0   *k5 > UCX$NOBODY        ON             -2          -2   *p >a > TCPIP> sh mapm$ >             Dynamic Filesystem Map= > Pathname                                Logical File System> >y1 > /dkc600                                 DKC600:s >  > TCPIP> sh export >i3 > File System                             Host name  >f+ > /dkc600                                 *y+ > /dkc600/SMSdemag                        *  >l > 	 > Thanks!  > Georgf   Georg,  I I recall an issue with V5.1 in that area in the initial release.  Be sureaJ that you get the last ECO to V5.1 installed.  Better yet, if you could getH your mitts on V5.3+ you can also pick up some rather serious performance enhancements as well.,   -Johnr   ------------------------------  % Date: Mon, 28 Jul 2003 09:02:01 +0200 < From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de>P Subject: Re: [DECnet-Plus V7.3-1 ECO2] What has happened to the DECNET_VERSION ?8 Message-ID: <bg2hq4$kbdt0$1@ID-56200.news.uni-berlin.de>  / Peter 'EPLAN' LANGSTOEGER wrote on 26-APR-2003:pD > It seems that the ECO2 of DECnet-Plus V7.3-1 (which is, as you canA > see on the version number, for the Alpha platform) did make thee$ > DECNET_VERSION some kind of bogus: >i- > $ write sys$output f$gets("decnet_version") 
 > 00050500 > F > I vaguely remember, with ECO1 the version number was slightly higher > (like 00050E05 or similar).a   That's the correct number, seeL http://h18000.www1.hp.com/support/asktima/communications/0095A86D-DBD41A20-1
 C0096.html    > Can anyone confirm this and/or: > does anyone know what has happened and/or how to fix it?  @ As I just recently stumbled over this (when installing DECosap): Anything new with this issue?a  < I kind of solved it by removing the DECnet version test from: KITINSTAL.COM (and got it installed and running), but that clearly is a Bad Thing(tm).a   cu,    Martin --F   OpenVMS:                | Martin Vorlaender  |  VMS & WNT programmer3    The operating system   | work: mv@pdv-systeme.delF    God runs the           |   http://www.pdv-systeme.de/users/martinv/:    earth simulation on.   | home: martin@radiogaga.harz.de   ------------------------------   End of INFO-VAX 2003.414 ************************