1 INFO-VAX	Sat, 25 Sep 2004	Volume 2004 : Issue 533       Contents: "Oracle RDB" licensing question # Re: "Oracle RDB" licensing question  Bunjee Love , Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations, Re: HP admits discontinued IA64 workstations Re: HTTP proxy server for VMS?G Re: OT:   I'm entering the job market for the second time since 1984... = Re: Slashdot is reporting HP is dropping Itanium workstations = Re: Slashdot is reporting HP is dropping Itanium workstations = Re: Slashdot is reporting HP is dropping Itanium workstations   Re: TCP/IP cluster interconnect?$ VMS omitted again from press release( Re: VMS omitted again from press release: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.< Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command< Re: [DCL REQUEST] New ignore keyword for DIFFERENCES command  F ----------------------------------------------------------------------  % Date: Sat, 25 Sep 2004 11:16:28 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> ( Subject: "Oracle RDB" licensing question: Message-ID: <wZf5d.32095$pA.2264488@news20.bellglobal.com>  M I'm having difficulty getting this answered by Oracle sales so I thought I'd   try the user community.   K I'm running OpenVMS on a single Alpha-Server-DS20e with 2-CPUs (SMP) and I  L need to get a quote on Oracle Rdb licensing for this machine for a business J case. I've learned that Oracle Rdb is licensed on a "per processor" basis ) and this is where the confusion comes in.   M Some companies consider "processor count" to be the "CPU count" while others  : consider "processor count" to be the "cluster node count".    So do I need one license or two?  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html  G p.s. On my first day working with "Oracle Marketing" I always used the  K phrase "Oracle Rdb" but later discovered that everything I had been quoted  0 was only related to "Oracle 10i". What a mess...   ------------------------------  % Date: Sat, 25 Sep 2004 15:53:55 +0000 - From: David B Sneddon <dbsneddon@bigpond.com> , Subject: Re: "Oracle RDB" licensing question* Message-ID: <41559493.2050601@bigpond.com>    Neil Rieck was overheard to say:O > I'm having difficulty getting this answered by Oracle sales so I thought I'd   > try the user community.  > M > I'm running OpenVMS on a single Alpha-Server-DS20e with 2-CPUs (SMP) and I  N > need to get a quote on Oracle Rdb licensing for this machine for a business L > case. I've learned that Oracle Rdb is licensed on a "per processor" basis + > and this is where the confusion comes in.  > O > Some companies consider "processor count" to be the "CPU count" while others  < > consider "processor count" to be the "cluster node count". > " > So do I need one license or two? >  > Neil Rieck > Kitchener/Waterloo/Cambridge,  > Ontario, Canada.: > http://www3.sympatico.ca/n.rieck/links/cool_openvms.html > I > p.s. On my first day working with "Oracle Marketing" I always used the  M > phrase "Oracle Rdb" but later discovered that everything I had been quoted  2 > was only related to "Oracle 10i". What a mess...  I About 5 years ago I tried to get a quote from Oracle about RDB licensing. ? After several months of getting absolutely nowhere I gave up...   
 Good luck!   Regards, Dave.  --  I David B Sneddon (dbs)    VMS Systems Programmer     dbsneddon@bigpond.com I Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/ I DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm I "Life is what happens to you while you're busy making other plans" Lennon    ------------------------------  # Date: Sat, 25 Sep 2004 15:48:01 GMT  From: steveyoung@yahoo.com Subject: Bunjee Love. Message-ID: <Rqg5d.502766$M95.429569@pd7tw1no>  k Pictures of me and my girlfriend having sex at the end of a Bunjee Rope 100 meters off a bridge in Scotland   + http://bunjeelove.fsckme.net/BunjeeLove.zip    ------------------------------  # Date: Sat, 25 Sep 2004 08:38:22 GMT ! From: Nigel Barker <nigel@hp.com> 5 Subject: Re: HP admits discontinued IA64 workstations 8 Message-ID: <r2bal01ithtqs7jqnp4vdlv63n59dreclk@4ax.com>  F On Sat, 25 Sep 2004 01:37:57 GMT, rdeininger@mindspringdot.com (Robert Deininger) wrote:   6 >In article <4154C05C.84F7535F@teksavvy.com>, JF MezeiG >One of these workstations is just a reconfigured rx2600 server, with a G >slightly different case and an alternate IO cage that has one AGP slot  >instead of just PCI slots.  > K >The only significant loss here is the AGP slot.  Apparently there wasn't a K >lot of demand for AGP in Itanium systems.  Pretty similar to the situation 
 >on Alpha.  O Not having AGP is unimportant nowadays. Even desktop PCs are all going to PCI-X O which gives higher bandwidth than AGP. All the latest graphics cards from ATI & J Nvidia are PCI-X & at the high end are probably the last generation of AGP cards.   -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  % Date: Sat, 25 Sep 2004 10:36:25 +0200  From: Dirk Munk <munk@home.nl>5 Subject: Re: HP admits discontinued IA64 workstations 2 Message-ID: <cj3ame$bvl$1@news3.zwoll1.ov.home.nl>   JF Mezei wrote: ) > Another aspect about that announcement:  > P > It isn't being read as HP discontinuing two specific models, but rathers as HP& > permanently pulling out of a market.  P Exactly ! The IA64 is suppose to be the successor of the PA-Risc and the Alpha, I including the operating systems. If HP is discontinuing the IA64 line of  L workstations permanently, than that means they will not be any HP-UX or VMS @ workstations in the future. Not a very good signal at this time.     > O > Had HP said that it was streamlining its production and combining workstation F > with low end servers, the news would have been much better received. > N > However the message here is that HP is widthdrawing from a market and givingK > the *impression* that there won't be any IA64 based workstations anymore.  > P > If HP can't manage news, image and perceptions, then it is incompetant. And weF > know that carly knows exactly how important image and perception is.   ------------------------------  # Date: Sat, 25 Sep 2004 08:46:22 GMT ! From: Nigel Barker <nigel@hp.com> 5 Subject: Re: HP admits discontinued IA64 workstations 8 Message-ID: <odbal09uq8auhg4sb7ag5rkhpo6bsc2tgs@4ax.com>  K On Fri, 24 Sep 2004 20:58:25 -0400, JF Mezei <jfmezei.spamnot@teksavvy.com>  wrote:  K >If HP wants to be a hardware company, then it doesn't make sense for it to M >continue with "parralel" products such as VMS or HP-UX if it could make more N >money selling large servers that run Linux which would cost HP very little inX >development costs, yet would generate lots of support revenus. Same applies to Windows.  M Linux doesn't run well on large servers unless you slice them up into lots of  small hard partitions.  K >I, for one, would not be surprised if HP were to indefinitely postpone the M >commercial launch of VMS on IA64. Avoiding a 5 year support commitment for a ; >product that just isn't selling well woudl be a good idea.   K Rubbish. HP-UX is shipping on Integrity servers today & that's a far larger O market than OpenVMS. The support implications for OpenVMS on Integrity are tiny J considering that all the hardware development & qualification is basicallyB funded by HP-UX. OpenVMS will not be paying the Alpha tax anymore.   -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  # Date: Sat, 25 Sep 2004 09:00:47 GMT ! From: Nigel Barker <nigel@hp.com> 5 Subject: Re: HP admits discontinued IA64 workstations 8 Message-ID: <2ecal0pld8254pc41m8hgkigf7fm8mipu7@4ax.com>  C On Sat, 25 Sep 2004 10:36:25 +0200, Dirk Munk <munk@home.nl> wrote:    >JF Mezei wrote:* >> Another aspect about that announcement: >>  Q >> It isn't being read as HP discontinuing two specific models, but rathers as HP ' >> permanently pulling out of a market.  > Q >Exactly ! The IA64 is suppose to be the successor of the PA-Risc and the Alpha,  J >including the operating systems. If HP is discontinuing the IA64 line of M >workstations permanently, than that means they will not be any HP-UX or VMS  A >workstations in the future. Not a very good signal at this time.   K For some years the Alpha workstations have been identical to servers except ; mounted vertically for those workstation traditionalists:-)    -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  # Date: Sat, 25 Sep 2004 13:45:48 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) 5 Subject: Re: HP admits discontinued IA64 workstations L Message-ID: <rdeininger-2509040954260001@user-uinj4fd.dialup.mindspring.com>  5 In article <4154F255.F37E1FC9@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:   ( >Another aspect about that announcement: > O >It isn't being read as HP discontinuing two specific models, but rathers as HP % >permanently pulling out of a market.   H Ok.  HP stopped the last models of IA64 workstations, which were gettingB somewhat long in the tooth.  In the normal scheme of things it wasJ probably approximately the right time to retire them.  So surprise so far.  G There's nothing more in the pipeline, but there hasn't been anything in G the pipeline for quite a while.   The systems were due for a refresh if E they were going to continue to be sold.  Nobody has seemed to care in H recent months that there were no follow-on systems.  The folks who claimG the EOL announcement is a big deal, should have already been up in arms 0 because the IA64 workstation pipeline was EMPTY.  N >Had HP said that it was streamlining its production and combining workstationE >with low end servers, the news would have been much better received.   G I doubt it.  The usual crowd who looks for a cloud in any silver lining D would have reacted in the usual way, regardless of facts or details.  M >However the message here is that HP is widthdrawing from a market and giving J >the *impression* that there won't be any IA64 based workstations anymore.  G Yup.  HP has no plans to make more IA64 workstations.  And they haven't I had any such plans for a while.  Are you suggesting that they should have J spun this fact  to make it sound better?  That would be a reversal of your usual point of view.    O >If HP can't manage news, image and perceptions, then it is incompetant. And we E >know that carly knows exactly how important image and perception is.   I I tend to agree that HP is pretty weak in this area.  But in this case, I I think they have been completely clear about their IA64 workstation plans.    ------------------------------  # Date: Sat, 25 Sep 2004 13:50:18 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) 5 Subject: Re: HP admits discontinued IA64 workstations L Message-ID: <rdeininger-2509040958580001@user-uinj4fd.dialup.mindspring.com>  F In article <cj3ame$bvl$1@news3.zwoll1.ov.home.nl>, munk@home.nl wrote:   >JF Mezei wrote:* >> Another aspect about that announcement: >>  C >> It isn't being read as HP discontinuing two specific models, but 
 rathers as HP ' >> permanently pulling out of a market.  > I >Exactly ! The IA64 is suppose to be the successor of the PA-Risc and the  Alpha,  J >including the operating systems. If HP is discontinuing the IA64 line of M >workstations permanently, than that means they will not be any HP-UX or VMS  A >workstations in the future. Not a very good signal at this time.   H I don't know about PA-risc, but in the Alpha case there haven't been anyG new workstation systems for a long time.  The last one was the XP1000.  F Since then, Alpha "workstations" have been servers with graphics cards plugged in to them.   J The "server with graphics" model is still available for both VMS and HP-UX  (and linux and windows) on IA64.  I The traditional workstation business has been dying for a decade or more, H as Fred K. has pointed out more than once.  The mass market for graphicsI is PCs for games, which has completely different hardware needs than real F workstations.  I don't think HP EVER had any plans to pursue IA64 game boxes.   ------------------------------  # Date: Sat, 25 Sep 2004 14:00:09 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) 5 Subject: Re: HP admits discontinued IA64 workstations L Message-ID: <rdeininger-2509041008480001@user-uinj4fd.dialup.mindspring.com>  5 In article <4154DCFB.FA42B219@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:     / >> What did Intel have to do with this decsion?  > L >You can bet that HP and Intel are working closely together on the future ofN >IA64 and a strategic announcement of further retrenchement oa IA64 would have0 >been made with Intel's knowledge/participation.  I Yes, HP and Intel do work pretty closely together on IA64 futures.  There E is a lot in the pipeline, and both companies are pushing hard to keep  things moving.  K >> I guess you'd have a valid point if HP was dropping their IA-64 servers.  > H >How come so many are not convinced this is NOT the long term plan ? (or inevitable).  : Dunno.  I don't dwell on other folks' fantasies very much.  < But I know the product pipeline is full, nearly overflowing.   ...   L >> They discontinued the workstations, and you find it interesting that they >> stopped production?  Huh? > K >Stopped production Sept 1. News came out sept 24. Sounds like HP wanted to N >keep this quiet, but it came out and then HP had to confirm. If they don't doJ >proper damage control, then it means that HP is intending for the news to >cause damage to IA64's image.  H I assume there is enough inventory to fill all the orders they expect byH Oct. 1.  And last-sale dates are routinely adjusted to use up inventory.  J Or maybe not.  If you want to make HP look foolish, order a bunch of theseJ workstations so they have to reject your order.  Prove they can't manage a
 supply chain.     M >> If there was sudden demand for these systems, they'd just order more parts  >> and build more systems. > H >There can't be demand for those systems if they are no longer listed in
 >catalogues.    N Surely all the negative press you cited above will generate some interest. ;-)   Or do any real customers care?   ...     M >The products that run on IA64 are suffering the sanme fate as VMS and Alpha: N >by artificially restricting the product to a smaller and smaller market niche  @ I don't think there was any artificial restriction.  I think theI workstations were poor sellers all along, compared to the architecturally  similar rx2600 server.   ------------------------------  % Date: Sat, 25 Sep 2004 11:57:40 -0400 ( From: David Froble <davef@tsoft-inc.com>5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <41559574.6020900@tsoft-inc.com>   Nigel Barker wrote:   E > On Sat, 25 Sep 2004 10:36:25 +0200, Dirk Munk <munk@home.nl> wrote:  >  >  >>JF Mezei wrote:  >>* >>>Another aspect about that announcement: >>> Q >>>It isn't being read as HP discontinuing two specific models, but rathers as HP ' >>>permanently pulling out of a market.  >>> R >>Exactly ! The IA64 is suppose to be the successor of the PA-Risc and the Alpha, K >>including the operating systems. If HP is discontinuing the IA64 line of  N >>workstations permanently, than that means they will not be any HP-UX or VMS B >>workstations in the future. Not a very good signal at this time. >> > M > For some years the Alpha workstations have been identical to servers except = > mounted vertically for those workstation traditionalists:-)  >  > -- > Nigel Barker! > Live from the sunny Cote d'Azur  >   K Correct.  Some didn't even have that much difference.  Not much difference  8 between an AlphaServer 1200 and an Ultimate Workstation.  P That's not the issue.  Three years ago the itanic was presented as greater than O sliced bread.  It would be the next industry standard.  It's performance would    be far ahead of everything else.  Q Some of us weren't so sure.  Alpha and Power were currently performance leaders,  P and there just wasn't anything except hype to suggest that would change.  Well, O curly could change it for Alpha, by dropping future development.  Even so, the  N latest Alpha seems to be a bit of a handful for the itanic to exceed.  As for M Power, you can find some task that the itanic does well, tweak the compilers  I repetitively, and be respectable, but overall the itanic isn't fit to be  " compared to the latest Power CPUs.  L Then there was the work at AMD, and how that might put a brass ring through M Intel's nose.  Many claimed that AMD would never do what has now transpired.  P Any comments from that 'many'.  Thought not, you've all snuck back to your hole ) and won't dare to comment on the subject.   P Even Intel backed off from the early extravagant claims about the itanic.  Last P week the itanic was listing badly, compared to the hype of three years ago, and P now this new development, while probably not a real issue, gives the appearance # of the itanic taking on more water.   I There is concern that a bit more water, and it will follow it's namesake.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 25 Sep 2004 12:06:44 -0400 ( From: David Froble <davef@tsoft-inc.com>5 Subject: Re: HP admits discontinued IA64 workstations , Message-ID: <41559794.1080201@tsoft-inc.com>   Nigel Barker wrote:   M > On Fri, 24 Sep 2004 20:58:25 -0400, JF Mezei <jfmezei.spamnot@teksavvy.com>  > wrote: >  > L >>If HP wants to be a hardware company, then it doesn't make sense for it toN >>continue with "parralel" products such as VMS or HP-UX if it could make moreO >>money selling large servers that run Linux which would cost HP very little in Y >>development costs, yet would generate lots of support revenus. Same applies to Windows.  >> > O > Linux doesn't run well on large servers unless you slice them up into lots of  > small hard partitions. >  > L >>I, for one, would not be surprised if HP were to indefinitely postpone theN >>commercial launch of VMS on IA64. Avoiding a 5 year support commitment for a< >>product that just isn't selling well woudl be a good idea. >> > M > Rubbish. HP-UX is shipping on Integrity servers today & that's a far larger Q > market than OpenVMS. The support implications for OpenVMS on Integrity are tiny L > considering that all the hardware development & qualification is basicallyD > funded by HP-UX. OpenVMS will not be paying the Alpha tax anymore. >  > -- > Nigel Barker! > Live from the sunny Cote d'Azur  >   N The problem with that seemingly good news is that in 2001 VMS could afford to O pay the 'Alpha tax'.  The changes since then, all directly a result of killing  ( Alpha, may have changed that capability.  P It's real simple.  If a port to IA-64 had been announced, without the 'gleeful' N announcement of the end of Alpha, customers would have taken it as good news, M and the VMS base quite likely would have grown, not shrunk, drastically with   respect to new sales.   Q Anyone wanting to argue that can also explain how AMD could never, never, never,  ' cause Intel to make an abrupt 'U' turn.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Sat, 25 Sep 2004 07:34:07 GMT L From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)' Subject: Re: HTTP proxy server for VMS? 6 Message-ID: <00A3861F.D4955EC3@SSRL.SLAC.STANFORD.EDU>  q In article <MihAVkJ8Lfqw@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:  >In article <00A3854F.7A30307F@SSRL.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing) writes: >>  M >> CSWS has mod_proxy support; OSU has proxy/cache code.  Another poster has  N >> already pointed out that WASD does it.  I've tested each of these enough toL >> know that they all can be made to work under at least some circumstances. > H >   I already have OSU, but I didn't see where to set up a proxy server.F >   Can you point me to the right part of the doc set, or is the proxy3 >   server something I get without doing any setup?  >   L Well, neither.  It's been a couple of years now, but I think I learned aboutH the proxy options by reading the source code.  There's a CGI script that8 functions as a gateway, and a fuller-blown proxy server.  L I've forwarded the relevant chapter from my webservers-on-VMS book in email. I hope you'll find it helpful.   -- Alan    ------------------------------   Date: 25 Sep 2004 07:33:48 GMT+ From: "Doc." <doc.cypher@openvms-rocks.com> P Subject: Re: OT:   I'm entering the job market for the second time since 1984...7 Message-ID: <Xns956F616204D7Edcovmsrox@212.100.160.123>   % %NEWS-I-NEWMSG, William Webb wrote in 5 news:bf98c417.0409241338.3cb6e5df@posting.google.com    ? > In case any of you wondered where I'd vanished to as of late-  > 9 > Client instituted staffing reductions on our account;   ' > My last day with EDS was 21-SEP-2004.  >  > FYI:   > F > Any eds.com or usps.gov addresses you may have on file for me are no > longer valid;  > H > 15 years of solid VMS VAX and Alpha experience ranging from desktop to0 > clusters; Hardware/Software/System Management. > 9 > I may be reached at the openvms-rocks.com mail address.  >  > Thanks to you all.   Sorry to hear the news.   I If you want a chuckle log into the cluster and check conference GENERAL,  ; note 170.0.  A job offer for 3-4 Linux Systems Programmers.   G "They will be system programming in C and C++ under Linux and BSD/Unix  @ environments.  Experience coding the kernel.  This will include H developing custom routines for File Handling, Packets and Communication G Layers, Messaging and Message Threading Routines, custom code libraries I and patches and Porting OS Systems from old VAX/VMS environment to Linux   based systems."   ) Really sounds like "turn Linux into VMS".      Doc. --  G OpenVMS:     Eight out of ten hackers prefer *other* operating systems. G http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.    ------------------------------  # Date: Sat, 25 Sep 2004 06:41:42 GMT 3 From: Vance Haemmerle <vance@toyvax.Glendale.CA.US> F Subject: Re: Slashdot is reporting HP is dropping Itanium workstations= Message-ID: <Fq85d.19797$QJ3.4151@newssvr21.news.prodigy.com>    Fred Kleinsorge wrote:1 > "Glenn Everhart" <gce@gce.com> wrote in message " > news:41545022.7050107@gce.com... > A >>Anyone able to tell if it is so? If so what of our favorite OS?  >>Glenn Everhart >  > L > Those paying attention would have noticed that the zx2000 and zx6000 never# > showed up on the OpenVMS roadmap.  > J > While I am not happy about it, I have said for a long time that it isn't8 > possible to compete with a high-end PC on the desktop. >  >  >   A    Here's the chance to get VMS supported on Itanium workstations  from other vendors. ;)   ------------------------------  # Date: Sat, 25 Sep 2004 08:32:59 GMT ! From: Nigel Barker <nigel@hp.com> F Subject: Re: Slashdot is reporting HP is dropping Itanium workstations8 Message-ID: <cbaal0p0tv8l5r8nfl2amr36tokh2anhpc@4ax.com>  K On Fri, 24 Sep 2004 17:57:35 -0400, JF Mezei <jfmezei.spamnot@teksavvy.com>  wrote:   >Glenn Everhart wrote: >>  B >> Anyone able to tell if it is so? If so what of our favorite OS? >> Glenn Everhart  > T >If this is only a slashdot thing, then I don't take it as completely authoritative. > L >Having said this, I am not surprised at all. When Intel announced years agoM >that IA64 wasn't going to make it to desktop and would be relegated to niche I >high end computing, it effectively meant that it woudln't make it in the  >workstation market. > M >Assuming this the story is real, one must now keep our eyes opened to see if I >HP will produce something like the DS15 that can be used both as a small  >server and a workstation.   That would be the rx1600.   O >The possible impact of having no longer any workstations is that VMS engineers N >will be forced to drop Xwindows support/development since they won't have any >hardware to run it on.   ? Not true. VGA output is available on all the Integrity servers.    -- Nigel Barker Live from the sunny Cote d'Azur    ------------------------------  + Date: Sat, 25 Sep 2004 13:29:24 +0000 (UTC)  From: david20@alpha2.mdx.ac.ukF Subject: Re: Slashdot is reporting HP is dropping Itanium workstations) Message-ID: <cj3rrk$olb$1@news.mdx.ac.uk>   R In article <37ednUavhN8A-cncRVn-iA@igs.net>, "John Smith" <a@nonymous.com> writes: >John Reagan wrote:  >> John Smith wrote: >>> Glenn Everhart wrote:  >>> D >>>> Anyone able to tell if it is so? If so what of our favorite OS? >>>> Glenn Everhart  >>>  >>>  >>> G >>> The HP apologists will say that the effort over the past 3 years of B >>> porting VMS to Itanic will not have been wasted, that the codeH >>> cleanup alone will have been worth the loss of sales and profits and >>> reputation.  >>> G >>> The realists will be wanting to find a couple of lengths of rope, a F >>> nearby tree, and deputize a posse looking for curly and carly(tm). >>>  >>>  >>G >> While this is all news to me as well, OpenVMS I64 isn't targetted to E >> the workstations anyway.  The rx1600, rx2600, rx4640, etc. are all C >> rackmounted server machines.  All of OpenVMS' intended supported % >> configuartions are still in place.  >  > M >Economies of scale my lad. Without workstations, which are sold in multiples K >of server sales, the process never ramps up enough to slide costs down the J >production cost curve enough to make the chip anything but a niche bit of9 >silicon. Alpha redux. Next step - outright cancellation.  > L >And even if that's not the case, what do you think that Sun and IBM will beH >telling every single HP customer -- PH-UX, Tru64, VMS, NSK?? They'll beK >saying that HP can't be trusted and here's the proof, and many will agree. M >The unix/linux  users will disappears faster and easier than the VMS and NSK  >customers because they can. > L >The VMS and NSK customers will be harder to convert but they will over timeK >as HP does nothing to keep them happy or add to the roster of customers to I >replace the defections. Soon there isn't enough critical mass to support  >further development. EOL. > K Besides which many system managers and developers want a VMS workstation on L their desk NOT another rack-mounted server when they are testing things out.G Also how many hobbyists are going to by a rackmounted server for home - J quite a few of those hobbyists will be working with VMS at work and others8 will be in the industry and might argue for VMS at work.  
 David Webb Security Team leader CCSS Middlesex University   ------------------------------  % Date: Sat, 25 Sep 2004 15:56:15 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>) Subject: Re: TCP/IP cluster interconnect? 6 Message-ID: <41558713$0$22764$db0fefd9@news.zen.co.uk>  @ "David J Dachtera" <djesys.nospam@comcast.net> wrote in message % news:414F7DF7.C54A6E94@comcast.net...  <SNIP>0 > Being more "tightly-woven into the 'fabric' ofI > OpenVMS", there is no SCSACP as there is NETACP (DECnet), LATACP (LAT),   $ It is called SCACP, drop the last S.  : > UCX$INETD (was early UCX, not sure what its called now),J > MULTINET_SERVER, etc. You can't turn it on and off - only enable/disable) > it at boot time via a system parameter.  <SNIP>  M You can turn it on and off (and more), in the aforementioned SCACP, and also   with code in SYS$EXAMPLES.   Alex     ------------------------------  % Date: Sat, 25 Sep 2004 03:06:35 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> - Subject: VMS omitted again from press release , Message-ID: <415518F5.1DAFBEA7@teksavvy.com>  K In a press release bragging that HP has won 200 enterprise contracts in the A last 18 months, HP talks about its adaptive enterprise offerings:    ##M The Sun Eclipse Program, a comprehensive portfolio of services and incentives  from HP,R helps Sun customers move to Adaptive Enterprise solutions. In the Americas, HP hasE augmented the migration services it offers Sun customers with special  incentives andI system trade-ins across its industry-standard servers, with the choice of  HP-UX, Linux or ' Microsoft Windows(R) operating systems.  ##  H Why is  VMS not mentioned ? Why is VMS not a choice ? Isn't it easier to: migrate from Solaris to VMS than from Solaris to Windows ?    	 full url:  > http://www.nyse.com/cgi-bin/ny_news?df=NY&r=S&sym=HPQ&sl=BW-09/24-18:00-1235|BW-09/21-16:48-2213|ON-09/21-13:53-675|BW-09/21-05:55-117|BW-09/20-14:11-1883|&sp=3  > HP Lands More than 200 Sun Server Customers; Customers Benefit.      with Better Solutions for Their Business         9/21/04 5:55am    ------------------------------  % Date: Sat, 25 Sep 2004 12:10:59 +0200 - From: Alex van Denzel <vandenzel@hotmail.com> 1 Subject: Re: VMS omitted again from press release 7 Message-ID: <415543df$0$76540$b83b6cc0@news.wanadoo.nl>    JF Mezei wrote: J > Why is  VMS not mentioned ? Why is VMS not a choice ? Isn't it easier to< > migrate from Solaris to VMS than from Solaris to Windows ?  I Actually, people (the ones that have to sign the order at least) already  E know how Windows works. At least, they think they do. VMS however is   completely new to them.    -- Alex.    ------------------------------  + Date: Sat, 25 Sep 2004 00:57:04 -0500 (CDT)  From: sms@antinode.orgC Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions. ) Message-ID: <04092500570433@antinode.org>   F    Apparently Info-VAX has dropped a few items for me lately, so I wasD checking the Google record of comp.os.vms.  I see now that I've been missing out on some real humor.   - From: John Laird (nospam@laird-towers.org.uk)  Date: 2004-09-21 08:26:58 PST   H > I refer you to the description of -V.  There is no misbehaviour. [...]  	    Right.    > It is not K > intended to provide a zip file that may or may not work elsewhere.  It is ? > intented to provide a zip file that will work on VMS systems.   A    What made you think that these goals were mutually exclusive?  ? They're not.  It's just that up to now, it hasn't worked right.    >   For this to J > happen, it must include all file metadata as well as what one might termM > "real" data.  The simplest solution is to read all blocks up to and include M > the EOF block for sequential files and ALQ block for others.  However, once L > this is stored in the archive, how is a non-VMS UNZIP supposed to know the4 > difference - all it will see is a stream of bytes.  E    Partly right.  The solution is to read all the blocks always.  The G non-VMS UnZip simply needs an accurate file byte count (which it wasn't ' getting), and then it can do just fine.   @ > > > [... reading all blocks even the allocated-but-unused ...]  G > >   Second, what makes you think it does this now?  (Not that I would I > >rule it out.)  How would I test the results?  For example, does BACKUP ) > >/COMPARE check "all allocated blocks"?    < I don't need to think,  !    You should have stopped there.    >  I *know* it currently works.   2    Just as some folks know that the Earth is flat.   >   You can see the code in * > one of the source files you referred to.  G    As someone who has actually _looked_ at the code in question, what I ; _can_ see is that it did _not_ do what you "*know*" it did.    > [...] M > To be honest, I would say that if you are not sure how to test the veracity H > of your changes on all file types, then you should not be making those
 > changes.  F    I'm sure that I should be listening to advice from the likes of you instead.  E >   By all means do this for your own use but please don't take stepsDJ > to meld these into the publicly available versions until you are totally/ > satisfied there are no unwanted side-effects.o  F    Be my guest if you have doubts.  I don't need to test it, because IE "*know*" it works right with my changes.  Luckily, the Info-ZIP folks . seem to be more clueful than some other folks.  E > [...]  I did look at your source files but could not identify exacto> > changes very well without access to the unmodified versions,  B    Just the stock Zip 2.3 source, available from oodles of places.   >  so will not comment further.l      Well, that's a mercy.  F    Of all the things for Info-VAX to lose, it had to pick this one.   @ (Some folks make being right _so_ much more fun than it would be ordinarily.)    F    By the way, I found a fix for yet another odd-ball Zip problem.  IfE you have SET PROC /PARSE = EXT engaged, and your default directory is F not all-upper-case, Zip can become confused when it tries to strip the> current directory off the in-archive file names.  For example:  4 ALP $ set def ALP$DKA0:[UTILITY.SOURCE.ZIP.ZIP-2_3X]  5 ALP $ zip "-V" test_uc-v.zip [.x]TEST_?.SLF     ! OK.r(   adding: [.X]TEST_4.SLF (deflated 100%)(   adding: [.X]TEST_5.SLF (deflated 100%)   but-  4 ALP $ set def ALP$DKA0:[UTILITY.source.zip.ZIP-2_3X]  
 ALP $ sho def (   ALP$DKA0:[UTILITY.source.zip.ZIP-2_3X]  G ALP $ zip "-V" test_lc-v.zip [.x]TEST_?.SLF      ! What could go wrong?nD   adding: [.UTILITY.SOURCE.ZIP.ZIP-2_3X.X]TEST_4.SLF (deflated 100%)D   adding: [.UTILITY.SOURCE.ZIP.ZIP-2_3X.X]TEST_5.SLF (deflated 100%)6            ============================          ! Oh.  ?    The fix for this one is in VMSZIP.C. of which a fresh one is  available at the usual place:o  +       http://www.antinode.org/ftp/info-zip/n&       ftp://ftp.antinode.org/info-zip/  F    Oh, no!  Maybe it was _supposed_ to do that!  It _does_ only happenF with "-V", after all.  I guess it must have been intentional.  Sorry.  Forget I mentioned it.  Please.t  D    Also, in the stroll-down-memory-lane department, the revised codeD seems to compile and run on VMS V5.5-2 with DEC C V4.0-000.  Who hasA something older?  VAX C?  (I tossed my VAX C due to RD54 capacityr limits.  Sigh.)   H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org-    Saint Paul  MN  55105-25474   ------------------------------  % Date: Sat, 25 Sep 2004 11:48:37 +0100R- From: John Laird <nospam@laird-towers.org.uk> C Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions. 8 Message-ID: <johal0de9v90s8uins4bncfuvdvfcgp9i4@4ax.com>  A On Sat, 25 Sep 2004 00:57:04 -0500 (CDT), sms@antinode.org wrote:p  A >(Some folks make being right _so_ much more fun than it would bed
 >ordinarily.)   J After testing, it turns out you are right.  Most likely, I have not had toG restore any relative or indexed files with EOF not correctly set beforehJ ZIP'ing (it could well be argued that such files could in any case containH inconsistencies and ought not to be regarded as candidates for archivingA without a prior ANAL/RMS run and possible CONVERT).  I apologise.   F Nevertheless, it is still a concern that you have posted references toC corrected code without a similar reference to uncorrected code, andOL apparently expect others to go find said code to make their own comparisons.J You may find your own changes easy to spot as you wrote them, but the sameG is not true of other people.  There were no particularly obvious change I bars, comment blocks or commented-out replaced lines that made eyeballingeH your work any easier.  In one module, you may have written an entire new" function, but I could not be sure.  H And I notice you're still asking others to test out "odd" files for you.K Which is it - you are completely right and don't need to test, or not ?  ItwB should be easy enough to grab a copy of a sample indexed file (sayK SYSUAF.DAT) and use SET FILE/ATTR=(EBK:) to artificially truncate the file.-F Zip and unzip it, then reset the end-of-file block on the copy and theJ unzipped version and use DUMP to make sure the blocks beyond the incorrect< EOF have been saved in the zip file and restored with unzip.  I Strictly speaking, files with EOF incorrectly set are potentially corrupttC anyway, but both COPY and BACKUP will transfer all allocated blockseK regardless.  It is obviously preferable that ZIP succeeds in emulating thisi (and the code clearly tried).n   -- s4 Press any key to continue or any other key to quit.    Mail john rather than nospam...    ------------------------------  + Date: Sat, 25 Sep 2004 09:13:15 -0500 (CDT). From: sms@antinode.orgC Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.r) Message-ID: <04092509131563@antinode.org>a  - From: John Laird <nospam@laird-towers.org.uk>e  L > After testing, it turns out you are right.  Most likely, I have not had toI > restore any relative or indexed files with EOF not correctly set beforeyL > ZIP'ing (it could well be argued that such files could in any case containJ > inconsistencies and ought not to be regarded as candidates for archivingC > without a prior ANAL/RMS run and possible CONVERT).  I apologise.&  :    I tried arguing that, briefly, but all I got was abuse.  H > Nevertheless, it is still a concern that you have posted references toE > corrected code without a similar reference to uncorrected code, andnN > apparently expect others to go find said code to make their own comparisons. > [...]3  ?    If you don't already have Zip 2.3 source, what good are you?s  J > And I notice you're still asking others to test out "odd" files for you.I > Which is it - you are completely right and don't need to test, or not ?e  H    I'm not yet convinced.  I only "*know*" it, and we both have seen how unreliable that can be.    >   ItD > should be easy enough to grab a copy of a sample indexed file (sayM > SYSUAF.DAT) and use SET FILE/ATTR=(EBK:) to artificially truncate the file. H > Zip and unzip it, then reset the end-of-file block on the copy and theL > unzipped version and use DUMP to make sure the blocks beyond the incorrect> > EOF have been saved in the zip file and restored with unzip.  D    Apparently, every time I've done HELP SET FILE /ATTR I've skippedF right past this (looking for RAT and RFM).  My most recent experimentsG suggest that BACKUP quits at the EOF, too, or else DUMP /ALLOC is lyings to me.  I'm still looking.  K > Strictly speaking, files with EOF incorrectly set are potentially corrupt-E > anyway, but both COPY and BACKUP will transfer all allocated blocks M > regardless.  It is obviously preferable that ZIP succeeds in emulating this  > (and the code clearly tried).5  E    As I said, I'm still trying to convince myself of that, but you'ref# welcome to provide a demonstration.   H    I'm starting to think that on VMS V5.5-2, DUMP /ALLOC is not entirely trustworthy:  . WEAK $ dump /all CRC32.VAX_DECC_OBJ_bac /block [...]    Dump of fileW DUA1:[UTILITY.SOURCE.ZIP.ZIP-2_3X.X]CRC32.VAX_DECC_OBJ_BAC;1 on 25-SEP-2004 09:28:36.04c6 File ID (331,12,0)   End of file block 2 / Allocated 3  3 Virtual block number 2 (00000002), 512 (0200) bytese  <  D65108AC D0635160 42CD5163 1808EF52 R..cQB`QcЬ.Q 000000<  EF52FFFF FF008FCA 5263CC52 619A08AC ..aRcR.....R 000010<  ACD10CAC 08C26351 6042CDB3 51631808 ..cQB`Qc..Ѭ 000020<  0004CCDE 29130CAC D5FF0331 031F080C ....1..լ..).. 000030<  CA5263CC 52619A08 ACD65108 ACD00153 S.Ь.Q֬..aRcR 000040<  63516042 CD516318 08EF52FF FFFF008F .....R..cQB`Qc 000050<  54D05404 ACFFFFFF FF8FCDDD 120CACD7 ׬........TT 000060<  0000FFFF 01000000 00000003 00080450 P............... 000070<  00000000 00000000 00000000 00000000 ................ 000080<  00000000 00000000 00000000 00000000 ................ 000090 [...]h   Dump of fileW DUA1:[UTILITY.SOURCE.ZIP.ZIP-2_3X.X]CRC32.VAX_DECC_OBJ_BAC;1 on 25-SEP-2004 09:28:36.04e6 File ID (331,12,0)   End of file block 2 / Allocated 3  3 Virtual block number 3 (00000003), 512 (0200) bytes1  <  D65108AC D0635160 42CD5163 1808EF52 R..cQB`QcЬ.Q 000000<  EF52FFFF FF008FCA 5263CC52 619A08AC ..aRcR.....R 000010<  ACD10CAC 08C26351 6042CDB3 51631808 ..cQB`Qc..Ѭ 000020<  0004CCDE 29130CAC D5FF0331 031F080C ....1..լ..).. 000030<  CA5263CC 52619A08 ACD65108 ACD00153 S.Ь.Q֬..aRcR 000040<  63516042 CD516318 08EF52FF FFFF008F .....R..cQB`Qc 000050<  54D05404 ACFFFFFF FF8FCDDD 120CACD7 ׬........TT 000060<  0000FFFF 01000000 00000003 00080450 P............... 000070<  00000000 00000000 00000000 00000000 ................ 000080<  00000000 00000000 00000000 00000000 ................ 000090 [...]A  3    Looks a lot like block 2, coincidentally, while:   : WEAK $ dump /all CRC32.VAX_DECC_OBJ_bac /block = start = 3   Dump of fileW DUA1:[UTILITY.SOURCE.ZIP.ZIP-2_3X.X]CRC32.VAX_DECC_OBJ_BAC;1 on 25-SEP-2004 09:28:43.83 6 File ID (331,12,0)   End of file block 2 / Allocated 3  3 Virtual block number 3 (00000003), 512 (0200) bytesn  <  00000000 00000000 00000000 00000000 ................ 000000<  00000000 00000000 00000000 00000000 ................ 000010<  00000000 00000000 00000000 00000000 ................ 000020<  00000000 00000000 00000000 00000000 ................ 000030<  00000000 00000000 00000000 00000000 ................ 000040   [...]   4    It's a poor workman who blames his tools, but ...  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-orgh    Saint Paul  MN  55105-2547r   ------------------------------  % Date: Sat, 25 Sep 2004 10:19:51 -0500i6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler>C Subject: Re: ZIP "-V" v. UNIX, et al.: Problem, possible solutions.dD Message-ID: <craigberry-C6873A.10195125092004@news.isp.giganews.com>  A In article <04092500570433@antinode.org>, sms@antinode.org wrote:e  H >    By the way, I found a fix for yet another odd-ball Zip problem.  IfG > you have SET PROC /PARSE = EXT engaged, and your default directory isiH > not all-upper-case, Zip can become confused when it tries to strip the@ > current directory off the in-archive file names.  For example: > 6 > ALP $ set def ALP$DKA0:[UTILITY.SOURCE.ZIP.ZIP-2_3X] > 7 > ALP $ zip "-V" test_uc-v.zip [.x]TEST_?.SLF     ! OK.i* >   adding: [.X]TEST_4.SLF (deflated 100%)* >   adding: [.X]TEST_5.SLF (deflated 100%) >  > buts > 6 > ALP $ set def ALP$DKA0:[UTILITY.source.zip.ZIP-2_3X] >  > ALP $ sho defe* >   ALP$DKA0:[UTILITY.source.zip.ZIP-2_3X] > I > ALP $ zip "-V" test_lc-v.zip [.x]TEST_?.SLF      ! What could go wrong?tF >   adding: [.UTILITY.SOURCE.ZIP.ZIP-2_3X.X]TEST_4.SLF (deflated 100%)F >   adding: [.UTILITY.SOURCE.ZIP.ZIP-2_3X.X]TEST_5.SLF (deflated 100%)8 >            ============================          ! Oh. > A >    The fix for this one is in VMSZIP.C. of which a fresh one is. > available at the usual place:y  B It would be better to preserve case and make the comparisons case G blind, as in the patch to the GNV version of ZIP to which I posted the mH URL earlier in this thread.  The basic procedure is to remove the calls G to strlower() and strupper() and change all the strncmp() calls to use 1 strncasecmp() instead.    C You can find the GNV version by installing GNV and then looking in oF GNU:[SRC.GNV.ZIP.VMS].  You can find my change on the patches page of  the GNV SourceForge project: eH <http://sourceforge.net/tracker/?group_id=2506&atid=302506>.  The patch D also turns foo^.bar.baz into foo.bar.baz in the archive so that the C caret escape doesn't show up when the archive is unpacked on other o
 systems.    G If you are in communication with the Info-Zip maintainers, it would be tH a great service to see the GNV changes reconciled and incorporated into  the authoritative sources.   ------------------------------   Date: 25 Sep 2004 08:08:36 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>E Subject: Re: [DCL REQUEST] New ignore keyword for DIFFERENCES commands? Message-ID: <DTiotGxQ0bj6-pn2-cyESPVHlfmwh@dave2_os2.home.ours>m  1 On Fri, 24 Sep 2004 17:36:00 UTC, Dave Greenwood a <greenwoodde@ornl.gov> wrote:d   <Snip>  nI > /IGNORE=SPACING ignores "Extra blank spaces or tabs within data lines." L > according to HELP DIFF/IGNORE.  So I think that would solve the problem ofK > "$" and "!" separated by any combination of spaces and tabs - assuming it E > was applied before checking for multi-character comment delimiters.e >  > Dave > --------------; > Dave Greenwood                Email: Greenwoodde@ORNL.GOV J > Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself  A I seem to remember that I still occasionally curse the fact that 0C /ig=sp still gives me differences when one file has spaces and the FB other tabs. You said in another thread you believed that multiple F white space was collapsed to single occurrence (of that character) andE that's fair. I'd still occasionally like to be able to force DIFF to IF have the single tab or space treated as equals and be ignored. I'm notC saying I would like the bahaviour changed (hey I'm a VMS bigot and  E backward compatibility is a big thing for me) but a new option would t
 be nice. e.g.e   	/ignore=white_space   -- g Cheers - Dave.   ------------------------------  % Date: Sat, 25 Sep 2004 08:52:24 -0400e) From: Andrew Robert <arobert@townisp.com>rE Subject: Re: [DCL REQUEST] New ignore keyword for DIFFERENCES commandu0 Message-ID: <10laqc1mhlsts63@corp.supernews.com>   Dave Weatherall wrote:H > On Thu, 23 Sep 2004 20:14:40 UTC, hammond@not@peek.ssr.hp.com (Charlie > Hammond) wrote:, >  >  >>SOMEbody wrote:g >> >>H >>>>Alan's original post suggested the problem lies with lines that are L >>>>comments.  As I understand it he said that DIFFERENCES with the various M >>>>flags to ignore comments treated a line "$! This is a comment" as if the nL >>>>line actually said "$" and could get itself confused and start matching L >>>>these lines with similarly treated comments at a different point in the  >>>>other file.t >>" >>Ah, yes.  Been there. Done that. >>H >>The workaround for this is to use /MATCH=x, where x is large enough to" >>prevent this sort of miss-match. >>M >>The drawback to this is that you may reduce the numer if different sections < >>and get sections with a lot of non-different lines listed. >>K >>But I also agree with another comment: Comments are important.  SometimesyG >>the are as important or even more inportant than the code.  Why would 8 >>you NOT want to examine the differences in comments??? >  > H > Sometimes you do but it is nice to be able to choose to check only theG > executable bits. Which is why DIFF has those wonderful qualifiers of u	 > course.l > H > The other use for a field exclusion specifier would have been to diff A > line-numbered files. I haven't seen one for quite a while tho' r9 > although DIFFing .DIF (or ,DMP ?)  files comes close...- > G It may be even better to design a script in Perl to do the extractions.i  A I've found that its abilities far exceed VMS due to the power of A expressions.  C Stripping items outs, compressing white space, etc are childs play.    ------------------------------   End of INFO-VAX 2004.533 ************************ezei wrote:  >>* >>>Another aspect about that announcement: >>> Q >>>It isn't being read as HP discontinuing two specific models, but rathers as HP ' >>>permanently pulling out of a market.  >>> R >>Exactly ! The IA64 is suppose to be the successor of the PA-Risc and the Alpha, K >>including the operating systems. If rred.  <<< PORT 83,31,172,66,150,1625 >>> 200 Port 150.162 at Host 83.31.172.66 accepted. <<< RETR local.tecY >>> 150 IMAGE retrieve of /disk$misc/decus/vax80a/teco1/local.tec (2022 bytes) started.t: >>> 226 Transfer completed.  1027 (8) bytes transferred. <<< PORT 83,31,172,66,150,16315 >>> 200 Port 150.163 at Host 83.31.172.66 accepted.a <<< RETR search.tec Z >>> 150 IMAGE retrieve of /disk$misc/decus/vax80a/teco1/search.tec (3072 bytes) started.: >>> 226 Transfer completed.  200