1 INFO-VAX	Mon, 29 Oct 2001	Volume 2001 : Issue 602       Contents:( Another missed opportunity for Alpha/VMS, Re: Another missed opportunity for Alpha/VMS3 Re: assaults on web servers - multinet IP filtering / Re: assaults on web servers from the billyworld / Re: assaults on web servers from the billyworld / Re: assaults on web servers from the billyworld  Re: C programming..  Re: C programming.. , Re: CLD & error handling from within program, Re: CLD & error handling from within program Re: Compaq blasts HP Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq blasts HP Re: Compaq financial humour !  Re: Compaq financial humour ! ! Re: DCPS and manual feed timeout. % Global Sections for IPC - performance ) Re: Global Sections for IPC - performance ) Re: Global Sections for IPC - performance ) Re: Global Sections for IPC - performance ) Re: Global Sections for IPC - performance ) Re: Global Sections for IPC - performance A Re: How to redirect output&error into a single file in sys$creprc A Re: How to redirect output&error into a single file in sys$creprc A Re: How to redirect output&error into a single file in sys$creprc  Installing CC060 on VMS VAX 6.1   Re: MIME Compliant Mail from VMS/ Peter Blackmore says nothing positive about VMS  PLUG: txt2pdf 5.3  RWINS 	 Re: RWINS 7 Re: SHOCK, HORROR, VMS & TRU64 STAFF RUSHED TO HOSPITAL ! Re: Single or Multiple Sys Disks? ! Re: Single or Multiple Sys Disks? 2 Re: Slightly OT - how failed computers kill ships. Re: SSH for Alpha VMS  Re: SSH for Alpha VMS 5 windows xp already hacked ... while vms "unhackable"!  Re: [MOZILLA] Applications ?  F ----------------------------------------------------------------------  % Date: Mon, 29 Oct 2001 04:13:29 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Another missed opportunity for Alpha/VMS , Message-ID: <3BDD1DB7.A361E9D2@videotron.ca>   from: 5 http://mars.jpl.nasa.gov/odyssey/mission/command.html  ##J All of Odyssey's computing functions are performed by the command and dataH handling subsystem. The heart of this subsystem is a RAD6000 computer, aE radiation-hardened version of the PowerPC chip used on most models of I Macintosh computers. With 128 megabytes of random access memory (RAM) and K three megabytes of non-volatile memory, which allows the system to maintain I data even without power, the subsystem runs Odyssey's flight software and 7 controls the spacecraft through interface electronics.   ##  J How difficult would it have been to create a radiation hardened version of6 Alpha (were ant radiation hardened vaxes produced ?) ?  8 Does Alpha consume about the same power as the PowerPC ?  J Considering that the military is one of the few remaining niches for VMS, H wouldn't a hardened version of the Alpha have allowed it to make further5 inroads into the military in the days before Compaq ?    ------------------------------    Date: 29 Oct 2001 13:04:16 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 5 Subject: Re: Another missed opportunity for Alpha/VMS H Message-ID: <y4g082r6tb.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * You would also need VxWorks for the Alpha.  H As the same chip was used on Mars Pathfinder in 1997, this must be "old" technology.    	Jan   ------------------------------    Date: 29 Oct 2001 12:29:05 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> < Subject: Re: assaults on web servers - multinet IP filteringH Message-ID: <y4itcyr8fy.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * bob@instantwhip.com (Bob Ceculski) writes:  N > the multinet packet filter process is similar to tcpware ... however instead$ > of "dropping" the packets, do this > ' >   deny ip x.x.x.x 255.255.255.255 0 0   L That depends on what drop and deny do. If drop just doesn't reply (throw theL packet in the bit bucket) and deny returns a connect reject, you might want M the former. Reason: It will take a timeout for the drop and will be inhibited M from doing something in this period. For the deny, it will receive a response F and immediately continue on its merry way, probably trying a differentM vulnerability, port, ip address. With drop, the attacker's overall throughput  likely is reduced.   	Jan   ------------------------------    Date: 29 Oct 2001 12:19:48 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 8 Subject: Re: assaults on web servers from the billyworldH Message-ID: <y4r8rmr8vf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ? system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:   M > After the side effects of Code Red (ARP storms) took Optimum Online service A > its knees, OOL placed a block on all port 80 traffic in bound.    3 Unfeasable if you're actually running a web server.    	Jan   ------------------------------  % Date: Mon, 29 Oct 2001 13:55:19 +0000 ( From: Nic Clews <sendspamhere@127.0.0.1>8 Subject: Re: assaults on web servers from the billyworld) Message-ID: <3BDD5FC7.B5ECEBE1@127.0.0.1>    Jan Vorbrueggen wrote: > A > system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:  > O > > After the side effects of Code Red (ARP storms) took Optimum Online service B > > its knees, OOL placed a block on all port 80 traffic in bound. > 5 > Unfeasable if you're actually running a web server.   E Yes and no. We restarted our webserver on a different port (8080) and E told those that needed to know. Worked fine although I agree it stops H normal usage. (We had to do this as we are being a firewall that blocked/ those ports, even though we've a VMS webserver)    --  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot com    ------------------------------  # Date: Mon, 29 Oct 2001 15:40:23 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) 8 Subject: Re: assaults on web servers from the billyworld0 Message-ID: <00A043EE.940A64E0@SendSpamHere.ORG>   In article <y4r8rmr8vf.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:@ >system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes: > N >> After the side effects of Code Red (ARP storms) took Optimum Online serviceB >> its knees, OOL placed a block on all port 80 traffic in bound.  > 4 >Unfeasable if you're actually running a web server. >  >	Jan   I Not really.  The T&Cs of OOL service prohibits servers of any sort.  Most H of the Code Red hits were from service such as Cable and DSL, and nearlyI all of these broadband service providers prohibit servers.  I'm delighted I that OOL took such draconian measures to stop Code Red.  Now if they'd do I something more draconian -- like keeping all of the world's PeeCee dweebs 4 off of the internet -- my world would be much nicer. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  # Date: Mon, 29 Oct 2001 07:18:56 GMT , From: "Paul Dennis" <comedyox@earthlink.not> Subject: Re: C programming..C Message-ID: <Ap7D7.7357$I4.654840@newsread1.prod.itd.earthlink.net>   5 > how does a C program accept a command line argument   ) Via a lib$get_foreign builtin.  Try this:    $ create arse.c  /*9 ** argv[0] is the image spec, that's why we start from 1.  */ #include <stdio.h> main(char argc, char **argv) {    int i;     for (i=1; i<=argc; i++) '     printf("arg %d: %s\n", i, argv[i]);    } 	 $ cc arse  $ link arse % $ mc []arse arg1 argr2 arg3 arg4 arg5  arg1 arg2 arg3 arg4 arg5     .pd. A  Really Simple Example    ------------------------------  % Date: Mon, 29 Oct 2001 05:39:54 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: C programming..; Message-ID: <3bdcdd9a.524144494f47414741@radiogaga.harz.de>   . Michael Austin (miaustin@bellsouth.net) wrote:2 > > Michael Austin (miaustin@bellsouth.net) wrote:; > > > my brain is fried... I need a quick example of how to  > > > J > > > 1) start a program written in C that accepts 1 command line argument > > - > >  $ program_that_accepts_one_argument == - E > >      "$device:[dir.ect.ory]PROGRAM_THAT_ACCEPTS_ONE_ARGUMENT.EXE" 5 > >  $ program_that_accepts_one_argument one_argument  > L > how does a C program accept a command line argument (such that your answerK > works.) However, now that I  have got some sleep, I have found an example . > that can be hacked to do what I need it too.   It really is easy: Given  " int main( int argc, char *argv[] )  M argc    holds the number of elements in argv[] (i.e. number of arguments +1), . argv[0] is the name the program was called by, argv[1] is argument #1, etc.   argv[argc] always is NULL.   cu,    Martin --  G So long, and thanks        | Martin Vorlaender  |  VMS & WNT programmer 4 for all the books...       | work: mv@pdv-systeme.deK In Memoriam Douglas Adams  |       http://www.pdv-systeme.de/users/martinv/ ;             1952-2001      | home: martin@radiogaga.harz.de    ------------------------------   Date: 29 Oct 2001 12:07:49 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann) 5 Subject: Re: CLD & error handling from within program 0 Message-ID: <9rjgql$6na$1@n.ruf.uni-freiburg.de>  e In article <DTiotGxQ0bj6-pn2-pBKxKvgOnDgr@localhost>, djweath@attglobal.net (Dave Weatherall) writes: 3 >On Sat, 27 Oct 2001 00:36:22, "David J. Dachtera"   ><djesys.nospam@fsi.net> wrote:  >  >snip... > H >> > : %CLI-W-IVKEYW, unrecognized keyword - check validity and spelling >> > :  \HUGO\6 >> > : %TRACE-W-TRACEBACK, symbolic stack dump followsQ >> > :   image    module    routine             line      rel PC           abs PC V >> > :                                             0 FFFFFFFF8006F0C0 FFFFFFFF8006F0C0V >> > :                                             0 FFFFFFFF8006F0C0 FFFFFFFF8006F0C0V >> > :                                             0 FFFFFFFF8006F0C0 FFFFFFFF8006F0C0V >> > :  MIST                                       0 00000000000106B4 00000000000206B4V >> > :  MIST  MIST  P_GET_COMMAND                 27 0000000000000120 0000000000020120V >> > :  MIST  MIST  MIST                          39 00000000000001F8 00000000000201F8V >> > :                                             0 FFFFFFFF855ED178 FFFFFFFF855ED178 >> > : RC=    229472 >> >  G >> > I have never used CLD from Pascal but have from C and don't recall G >> > having to trap any signals.  Was this an accvio?  Can you post the 8 >> > few lines before and after line 27 of your program? >>  % >> No, it wasn't an ACCVIO, it was a:  >>  H >> > : %CLI-W-IVKEYW, unrecognized keyword - check validity and spelling >> > :  \HUGO\ >>  $ >> ....and it was a warning at that. > D >And a very useful one at that... It usually tells you that CLD and G >code are out of step, unless an illegal entity has been entered on the ! >command line, but you knew that.  > C >I use LINK /NOTRACE for my production images. But maybe using the  G >exception handler might address another problem I've got. <exit stage   >left with thinking cap on>.  M It is obviously an inherent "feature" of the cli$-routines to not only return N a status but to signal a condition as well. Since I wrote now my own conditionI handler the problem is solved. It is nothing special, it simply returns a M "ss$_continue". And you have two routines in Pascal, establish and revert, to / activate and deactivate your condition handler.    Regards,    Christoph Gartmann   H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  % Date: Mon, 29 Oct 2001 17:29:50 -0000 / From: Michael Zarlenga <zarlenga@conan.ids.net> 5 Subject: Re: CLD & error handling from within program / Message-ID: <ttr4geaqqgk3dc@corp.supernews.com>   0 David J. Dachtera <djesys.nospam@fsi.net> wrote:F :> : %CLI-W-IVKEYW, unrecognized keyword - check validity and spelling :> :  \HUGO\  " : ...and it was a warning at that.  ? I must be getting forgetful, because as I remember CLD/CLI, bad A keywords were trapped by the CLI and the program never sees them.    --   -- Mike Zarlenga   ------------------------------    Date: 29 Oct 2001 05:13:44 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Compaq blasts HP 3 Message-ID: <g3S$dBxVYdaP@eisner.encompasserve.org>   ` In article <ovaqttkpbt1219orh6g2searh847a8tafa@4ax.com>, Alan Greig <a.greig@virgin.net> writes: > H > There's an astonishing Compaq internal memo quoted on The Inquirer. ItB > says HP sales have been  hammering Compaq sales since the merger> > announcement and spreading 'FUD'. Compaq goes on the attack.G > Unfortunately., imho, with words only. HP sales say one thing. Compaq  > sales say another.  > Prior to merger, US law requires they act as true competitors.   ------------------------------  % Date: Mon, 29 Oct 2001 10:20:46 +0000 % From: Alan Greig <a.greig@virgin.net>  Subject: Compaq blasts HP 8 Message-ID: <ovaqttkpbt1219orh6g2searh847a8tafa@4ax.com>  F There's an astonishing Compaq internal memo quoted on The Inquirer. It@ says HP sales have been  hammering Compaq sales since the merger< announcement and spreading 'FUD'. Compaq goes on the attack.E Unfortunately., imho, with words only. HP sales say one thing. Compaq C sales say another. In the combined company HP are clearly the major  players. Who do you believe?   Here's the article: ' http://www.theinquirer.net/29100102.htm   , Compaq and HP engaged in vicious FUD battle   & Moon of Love shines over Carly, Curly & By Mike Magee, 29/10/2001 09:08:41 BST    F SENIOR SALES STAFF at Compaq have compiled a remarkable document whichE appears to show that field sales staff at Hewlett "Carly" Packard are E using the shotgun wedding with the Compaq "Curly" Corporation to sell + more of their kit and gain more commission. F That has forced Compaq to issue a counter blast to the FUD, when facedB with a series from questions posed to corporate customers by their future colleagues at HP.  E Heads will have to roll over this one, which is so astounding that we , can hardly believe it's true. But it is...   
 Introduction  D Ever since the proposed HP/Compaq merger was announced, Compaq fieldF people and partners have encountered a considerable amount of FUD fromF the Hewlett-Packard field. This FUD involves everything from "Alpha isC a dead-end platform," to "HP-UX will be the surviving UNIX," to "no E porting will be needed for HP-UX customers." This document identifies D many of the more common FUD points HP is using and provides you with ideas to counter the FUD.   F 1. Customers do not need to recompile HP-UX applications to go to IPF.  E RESPONSE: The current shipping version of HP-UX is HP-UX 11i, version F 1.5. It has a full 64-bit kernel that supports 64-bit applications andD also runs 32-bit binaries transparently. As part of HP-UX 11i, thereE is a binary translator  code named "Aries"  that translates PA-RISC A instructions dynamically into Itanium instructions during runtime C (see: unix-cds.zk3.dec.com/k/4175/4175.pdf for details). We feel HP A will continue to offer this binary translator when the new merged D (HP-UX and Tru64) UNIX comes out. It is for that reason only that HPD can claim there is no need to recompile applications in the future.   @ This is a marketing claim not supported by any relevant history.E Experience tells us that customers and ISVs do not accept translators > as a functional answer for their critical, mainstream businessC applications. No ISV is going to support an application on a binary = translator and no IT manager is going to deploy an enterprise E application on a translator. That means the translator will mostly be2F used for older 32-bit applications where the source code has been longA lost (see #4 below), and cases where the company does not want tosD invest the engineering work to make the source code compile on IPF.   D 2. HP-UX will be the UNIX that attracts ISV attention going forward,E not Tru64. Now that Tru64 UNIX is end-of-life, ISVs will rapidly losen9 interest. Customers should migrate to HP-UX immediately. i  E RESPONSE: Tru64 is the most modern, mature 64-bit operating system inaF the industry. It was designed from the ground up as a 64-bit UNIX. TenD years later, that investment has paid off handsomely with Tru64 UNIXA having the largest, most stable portfolio of 64-bit optimized ISVpE applications in the industry. Because these applications have alreadyuE been tuned and optimized for 64-bit environments, Tru64 UNIX versionsfF of these applications will cleanly recompile to run on IPF and deliverA the best performance with the least effort for the ISVs. HP has a ; hodgepodge of mainly 32-bit applications that would requireiF significant engineering work to bring up to 64bits and then to IPF. HPD desperately needs a translator for those applications. Moving to IPFF without a translator will be a major transition for most current HP-UX applications.   E 3. HP provides the smoothest migration path to IPF. In fact, HP-UX ise$ running on IPF today; Tru64 is not.   A RESPONSE: This is a half-truth. HP-UX is running on IPF today andSD Tru64 UNIX is not. But customers are not buying IPF systems today toE run their enterprise applications. HP-UX on IPF is a first generationuE platform that is clearly not mature enough to handle mission criticalwD applications. Compilers and applications need more time to mature asE well. Only early adopters, such as ISVs, are purchasing these systems-? today. When HP-UX on IPF is finally ready to be deployed in thezC 2004-2006 timeframe, HP-UX and Tru64 UNIX will have been merged andtC over 10,000 native ISV applications will be available on the mergedm operating system.   F When the time is right, the ease or difficulty of transitioning from aF 64-bit HP-UX application to the combined UNIX product, or from a Tru64? application to the combined product will be virtually identicaldB because most 64-bit applications will need only a simple recompileB (see #4 below). But there are few 64-bit HP-UX applications today.B Most of the HP-UX portfolio is still 32-bit and those applications= will encounter much more difficulty in moving to a native IPFtE environment. This makes HP-UX the more difficult path to IPF for ISVs  and end-users, not Tru64 UNIX. v  C 4. "Customers will encounter a number of difficult migrations to gotF from Tru64 UNIX to HP-UX in the future. However, there is no migration@ needed for HP customers. All current HP-UX applications will runE unchanged on IPF today, and on the new combined UNIX in the future." p  A RESPONSE: This is simply not true. HP is making the claim of easedE based on the fact that they have a binary translator that will take a2F PA-RISC binary and run it on IPF without recompilation. But as we saidC earlier, the translator answer is a red herring. We know because weh? tried the translator route ourselves years ago with FX!32 (see:-F http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJP00/). CustomersA demand natively compiled applications that are fully supported byeF ISVs. We have said this is a marketing answer. Let's look closely at aE number of scenarios to see how this HP claim simply does not apply tou true enterprise applications:   F a. Customer has old PA-RISC binary, but can't locate the source code.   F This is a perfect candidate for HP's binary translator. The timing mayE not be right to replace the old application, so running the binary on D a newer industry-standard IPF system may make good business sense toE some customers. That eliminates the need for the customer to retain aoC PA-RISC system solely for one old application. (Remember that Tru64i> applications don't suffer from the legacy 32-bit syndrome, and' therefore this would not be an issue.) f  D b. Customer uses a major application, such as SAP or PeopleSoft, and wants to switch to IPF.   E With the combined market shares of HP-UX and Tru64 UNIX, HP will haveiB the second largest selling UNIX with a substantial installed base.D This will be very attractive to ISVs and virtually all current Tru64F and HP-UX ISVs will choose to move their applications to the new UNIX.C But none of them will choose the binary translator route because of:F product support and stability issues. Every ISV will go through a fullB porting and recertification effort. It will certainly be worth theE effort because the application will then be able to take advantage ofcE the architectural features within the Intel IPF architecture, such asO predication and speculation. 0  E Because all Tru64 applications have been 64 bits from day one and arerD the most mature, 64-bit optimized applications in the industry, mostF ISVs will be recompiling t heir Tru64 application binaries for the newF combined UNIX, not their 32-bit HP-UX binaries. The newer 64-bit Tru64F UNIX source code should compile much cleaner on IPF and deliver a muchF better final product with less effort than 32-bit HP-UX code. When theE customer is ready to make the move to IPF, it simply will be a matter,E of contacting the appropriate ISVs and making the licensing and mediai arrangements.   D c. Customer has internally developed applications running on PA-RISCA (or Alpha) and wants to deploy them on the combined UNIX on IPF. f  E Tools and assistance programs are being developed to ease the portingeD of customer applications to the combined UNIX on IPF. But the bottomD line is customers will want to recompile and recertify almost all ofE their applications on the new architecture because it will be a major0@ operating system release with numerous changes and enhancements.B Without recompiling, the application will be running on the binaryC translator (for HP-UX applications) and no IT manager will trust an<A enterprise application running on a translator. For customers whorA choose not to recompile and recertify on IPF, perhaps it would be @ better to continue running the application on Alpha or PA-RISC.   = 5. "Customers should not consider purchasing Tru64 UNIX on anu< AlphaServer. It's a dead product. In fact, customers running; AlphaServers today should migrate as soon as possible to ann" architecture with a longer life."   C RESPONSE: This is standard FUD that all our competitors are using  C not just HP. When you look at the timeline for Alpha and Tru64, theeE issue of "dead product" is more emotional than factual. This industryeB moves very rapidly, so changes are occurring all the time. ProductE lifetimes are shorter than they used to be. Customers need to addresso> problems today and for the foreseeable future. Alpha and Tru64B investments are still very desirable given the capabilities of theF products and the commitments we have made for supporting products well? into the future. Compaq has given customers a very long producti7 roadmap for the eventual retirement of Alpha products.    @ Think back to 1991 for a moment. HP controlled the emerging UNIX? enterprise computing market, which was dominated by proprietaryCF architectures such as IBM AS/400, HP3000, and DEC VAX. Convex and Cray@ Research dominated the technical server market and both appearedD unstoppable. You could get a nice mainframe from IBM, but their UNIXE servers were not worth buying. The DEC VAX line was beginning to slowiA as customers waited for Alpha. Sun was struggling to maintain itsoA leadership in engineering workstations and soon decided that they E needed to enter the UNIX server market to continue growing. MicrosoftrD was servicing a small but growing market for desktop PC's, and Linux was nowhere in sight.   D How things change! So at some point in the future, when AlphaServersE will no longer be supported, the market will be vastly different than E it is today. Which brings us to the point of this exercise. Customersu< should buy the best server that is available today for theirB applications. In most cases, that server is an AlphaServer runningD Tru64 UNIX and TruCluster Server. Many servers are deployed for onlyE three to five years, but there is no need to stop buying AlphaServerstA and there is certainly no need to replace existing AlphaServers. U  E Here are some reasons to continue to select AlphaServers over HP 9000 	 servers: C  F  World-class leadership in cluster technology. When you need to scaleF out, TruCluster Server is the worlds premiere UNIX clustering product.@ HP's cluster product lags all other vendors in functionality and> technological sophistication. MC/ServiceGuard is based on old,1 obsolete technology with no plans to be updated. n  A  The combination of TruCluster Server and the AlphaServer GS wasaE ranked BEST IN CLASS for reliability, availability and serviceability  (RAS) by D. H. Brown (see|8 http://www-unix.zk3.dec.com/www/competitive/dhba_ras.pdfA http://www-unix.zk3.dec.com/www/competitive/dhbarasreport2.pdf).    B  Superiority of AlphaServer hardware. -- High performance under a@ broad set of application loads and blazingly fast floating-point< performance make them especially ideal for compute-intensive? applications. PA-RISC servers do not have strong floating-pointn< performance and do not deliver the broad performance and RAS, capabilities that AlphaServers can provide.   E  A leader in the high performance computing markets. The AlphaServer F SC leads in markets where customers demand the absolute highest levelsE of computational performance available in general purpose servers. Wek? anticipate that AlphaServers will continue to do so for years. C  D  Compaq's TruCluster Server forms the basis of Oracle's new 9i RAC.A This is unique technology collaboration with the industry-leading  database vendor.    F  Compaq's AlphaServer roadmap and performance. We anticipate Compaq'sE previously announced roadmap for Alpha will outperform IPF for years.>D When IPF finally does surpass Alpha, customers can choose to migrate on their own timetable.   6 6. The new merged UNIX will be HP-UX, not Tru64 UNIX.   D RESPONSE: HP has a great general-purpose data center UNIX with broad< ISV coverage. Compaq has great clustering; RAS (reliability,C availability, scalability) and performance characteristics, gaining ? share especially in high-performance technical computing marketFD places. Converging the best of each onto the next generation ItaniumC platform will provide our customers with the most robust enterprisen UNIX on the market.         -- Alan   ------------------------------  % Date: Mon, 29 Oct 2001 12:21:18 +0100 = From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <noone@dummy.com>E Subject: Re: Compaq blasts HPk) Message-ID: <3BDD3BAE.FDA1A2E3@dummy.com>    From the article :  A "We [Compaq] anticipate Compaq's previously announced roadmap forlB Alpha will outperform IPF for years. When IPF finally does surpass? Alpha, customers can choose to migrate on their own timetable."    Jan-Erik Sderholm.f   ------------------------------  + Date: Mon, 29 Oct 2001 03:57:29 -0800 (PST)a. From: Fabio Cardoso <fabiopenvms@yahoo.com.br> Subject: Re: Compaq blasts HPb@ Message-ID: <20011029115729.50176.qmail@web20209.mail.yahoo.com>  5 I am imagining the merge in the perspective of the=20 % Professional Services. What mess !=20   & Compaq destroied the Digital Services.+ I hope the Master Mind of HP Services still / controlling the Service Business or Compaq will,+ destroy the good reputation of HP Services.h2 I am not saying specifically about the IT personal2 but the management staff... They dont have respect. for the "human" working behind the technology.3 Me and my team know a lot abour lack of respect ando! confidence of Compaq C. Services.   3 My brother-in-law works for HP/Brazil and he doesnt ) have any word to say about HP management.|  , But the Compaq management which I work for.. I prefer dont comment now !- Until I dont get a new job !=20d   Regardsi   FC=20h        * --- Alan Greig <a.greig@virgin.net> wrote: >=204 > There's an astonishing Compaq internal memo quoted > on The Inquirer. Itn1 > says HP sales have been  hammering Compaq sales  > since the merger6 > announcement and spreading 'FUD'. Compaq goes on the	 > attack..5 > Unfortunately., imho, with words only. HP sales sayd > one thing. Compaqd3 > sales say another. In the combined company HP area > clearly the majoru > players. Who do you believe? >=20 > Here's the article: ) > http://www.theinquirer.net/29100102.htmo >=200 > Compaq and HP engaged in vicious FUD battle=20 >=20* > Moon of Love shines over Carly, Curly=20( > By Mike Magee, 29/10/2001 09:08:41 BST >=20 >=20. > SENIOR SALES STAFF at Compaq have compiled a > remarkable document whichm3 > appears to show that field sales staff at Hewlettr > "Carly" Packard area3 > using the shotgun wedding with the Compaq "Curly"n > Corporation to selle- > more of their kit and gain more commission. 4 > That has forced Compaq to issue a counter blast to > the FUD, when faceds1 > with a series from questions posed to corporatet > customers by their > future colleagues at HP. >=204 > Heads will have to roll over this one, which is so > astounding that we0 > can hardly believe it's true. But it is... =B5 >=20 > Introduction=20 . > Ever since the proposed HP/Compaq merger was > announced, Compaq fielda5 > people and partners have encountered a considerablea > amount of FUD from. > the Hewlett-Packard field. This FUD involves > everything from "Alpha isa- > a dead-end platform," to "HP-UX will be the  > surviving UNIX," to "nor3 > porting will be needed for HP-UX customers." Thisl > document identifiesl4 > many of the more common FUD points HP is using and > provides you witha > ideas to counter the FUD.  >=20- > 1. Customers do not need to recompile HP-UX  > applications to go to IPF. >=204 > RESPONSE: The current shipping version of HP-UX is > HP-UX 11i, version0 > 1.5. It has a full 64-bit kernel that supports > 64-bit applications andS5 > also runs 32-bit binaries transparently. As part ofh > HP-UX 11i, there8 > is a binary translator =97 code named "Aries" =97 that > translates PA-RISC4 > instructions dynamically into Itanium instructions > during runtime0 > (see: unix-cds.zk3.dec.com/k/4175/4175.pdf for > details). We feel HP4 > will continue to offer this binary translator when > the new merged2 > (HP-UX and Tru64) UNIX comes out. It is for that > reason only that HP 6 > can claim there is no need to recompile applications > in the future.=20. >=200 > This is a marketing claim not supported by any > relevant history.d4 > Experience tells us that customers and ISVs do not > accept translators, > as a functional answer for their critical, > mainstream businessr- > applications. No ISV is going to support ani > application on a binaryt4 > translator and no IT manager is going to deploy an > enterprise- > application on a translator. That means theH > translator will mostly bei5 > used for older 32-bit applications where the sourcee > code has been long2 > lost (see #4 below), and cases where the company > does not want to5 > invest the engineering work to make the source code  > compile on IPF.=20 >=20- > 2. HP-UX will be the UNIX that attracts ISVn > attention going forward,5 > not Tru64. Now that Tru64 UNIX is end-of-life, ISVs  > will rapidly loseR- > interest. Customers should migrate to HP-UXt > immediately.=20t >=203 > RESPONSE: Tru64 is the most modern, mature 64-bits > operating system inn5 > the industry. It was designed from the ground up ase > a 64-bit UNIX. Ten6 > years later, that investment has paid off handsomely > with Tru64 UNIXe5 > having the largest, most stable portfolio of 64-bit  > optimized ISV - > applications in the industry. Because thesen > applications have alreadyd3 > been tuned and optimized for 64-bit environments,w > Tru64 UNIX versionsm5 > of these applications will cleanly recompile to runp > on IPF and deliver4 > the best performance with the least effort for the > ISVs. HP has a5 > hodgepodge of mainly 32-bit applications that wouldt	 > requiret4 > significant engineering work to bring up to 64bits > and then to IPF. HPg* > desperately needs a translator for those > applications. Moving to IPFt5 > without a translator will be a major transition forn > most current HP-UX > applications.=20 >=205 > 3. HP provides the smoothest migration path to IPF.6 > In fact, HP-UX is,( > running on IPF today; Tru64 is not.=20 >=205 > RESPONSE: This is a half-truth. HP-UX is running on  > IPF today andn5 > Tru64 UNIX is not. But customers are not buying IPFw > systems today to6 > run their enterprise applications. HP-UX on IPF is a > first generation6 > platform that is clearly not mature enough to handle > mission critical4 > applications. Compilers and applications need more > time to mature ass. > well. Only early adopters, such as ISVs, are > purchasing these systems1 > today. When HP-UX on IPF is finally ready to bem > deployed in thea5 > 2004-2006 timeframe, HP-UX and Tru64 UNIX will havef > been merged and - > over 10,000 native ISV applications will bea > available on the mergedn > operating system.=20 >=203 > When the time is right, the ease or difficulty ofr > transitioning from a/ > 64-bit HP-UX application to the combined UNIX  > product, or from a Tru64- > application to the combined product will bed > virtually identicali3 > because most 64-bit applications will need only ad > simple recompile0 > (see #4 below). But there are few 64-bit HP-UX > applications today.61 > Most of the HP-UX portfolio is still 32-bit andt > those applications4 > will encounter much more difficulty in moving to a > native IPF2 > environment. This makes HP-UX the more difficult > path to IPF for ISVs# > and end-users, not Tru64 UNIX.=20  >=204 > 4. "Customers will encounter a number of difficult > migrations to go2 > from Tru64 UNIX to HP-UX in the future. However, > there is no migrationh, > needed for HP customers. All current HP-UX > applications will runt6 > unchanged on IPF today, and on the new combined UNIX > in the future."=20 >=205 > RESPONSE: This is simply not true. HP is making they > claim of ease 6 > based on the fact that they have a binary translator > that will take a* > PA-RISC binary and run it on IPF without > recompilation. But as we said 5 > earlier, the translator answer is a red herring. Wei > know because we 5 > tried the translator route ourselves years ago witht
 > FX!32 (see:o >o< http://www.research.compaq.com/wrl/DECarchives/DTJ/DTJP00/). > Customersu6 > demand natively compiled applications that are fully > supported by6 > ISVs. We have said this is a marketing answer. Let's > look closely at am5 > number of scenarios to see how this HP claim simplyg > does not apply too" > true enterprise applications:=20 >=206 > a. Customer has old PA-RISC binary, but can't locate > the source code.=20n >=20- > This is a perfect candidate for HP's binary  > translator. The timing may1 > not be right to replace the old application, sos > running the binary ont4 > a newer industry-standard IPF system may make good > business sense to 2 > some customers. That eliminates the need for the > customer to retain a0 > PA-RISC system solely for one old application. > (Remember that Tru642 > applications don't suffer from the legacy 32-bit > syndrome, andC+ > therefore this would not be an issue.)=20v >=206 > b. Customer uses a major application, such as SAP or > PeopleSoft, ands > wants to switch to IPF.=20 >=204 > With the combined market shares of HP-UX and Tru64 > UNIX, HP will have4 > the second largest selling UNIX with a substantial > installed base.y4 > This will be very attractive to ISVs and virtually > all current Tru64s* > and HP-UX ISVs will choose to move their > applications to the new UNIX.o4 > But none of them will choose the binary translator > route because of6 > product support and stability issues. Every ISV will > go through a fulls- > porting and recertification effort. It willn > certainly be worth the5 > effort because the application will then be able toc > take advantage ofd1 > the architectural features within the Intel IPFs > architecture, such asa! > predication and speculation.=20d >=202 > Because all Tru64 applications have been 64 bits > from day one and are3 > the most mature, 64-bit optimized applications ini > the industry, most3 > ISVs will be recompiling t heir Tru64 applicationv > binaries for the new5 > combined UNIX, not their 32-bit HP-UX binaries. Then > newer 64-bit Tru645 > UNIX source code should compile much cleaner on IPFb > and deliver a much3 > better final product with less effort than 32-bit  > HP-UX code. When the6 > customer is ready to make the move to IPF, it simply > will be a matter3 > of contacting the appropriate ISVs and making ther > licensing and mediat > arrangements.=20 >=203 > c. Customer has internally developed applicationsa > running on PA-RISC5 > (or Alpha) and wants to deploy them on the combinedm > UNIX on IPF.=20i >=206 > Tools and assistance programs are being developed to > ease the porting2 > of customer applications to the combined UNIX on > IPF. But the bottoms. > line is customers will want to recompile and > recertify almost all ofP4 > their applications on the new architecture because > it will be a major4 > operating system release with numerous changes and > enhancements.w6 > Without recompiling, the application will be running > on the binarys/ > translator (for HP-UX applications) and no IT  > manager will trust ani5 > enterprise application running on a translator. Forl > customers whom/ > choose not to recompile and recertify on IPF,r > perhaps it would be 5 > better to continue running the application on Alphao > or PA-RISC.=20 >=204 > 5. "Customers should not consider purchasing Tru64 > UNIX on an6 > AlphaServer. It's a dead product. In fact, customers	 > running . > AlphaServers today should migrate as soon as > possible to an& > architecture with a longer life."=20 >=20- > RESPONSE: This is standard FUD that all ourt > competitors are using =96n6 > not just HP. When you look at the timeline for Alpha > and Tru64, the0 > issue of "dead product" is more emotional than > factual. This industry6 > moves very rapidly, so changes are occurring all the > time. ProductP- > lifetimes are shorter than they used to be.u > Customers need to addressl6 > problems today and for the foreseeable future. Alpha > and Tru64e0 > investments are still very desirable given the > capabilities of theo/ > products and the commitments we have made fora > supporting products well4 > into the future. Compaq has given customers a very > long product. > roadmap for the eventual retirement of Alpha > products.=20 >=204 > Think back to 1991 for a moment. HP controlled the > emerging UNIXo5 > enterprise computing market, which was dominated bym
 > proprietaryr3 > architectures such as IBM AS/400, HP3000, and DECA > VAX. Convex and Cray4 > Research dominated the technical server market and > both appearedd2 > unstoppable. You could get a nice mainframe from > IBM, but their UNIX.5 > servers were not worth buying. The DEC VAX line wasa > beginning to slowt6 > as customers waited for Alpha. Sun was struggling to > maintain its1 > leadership in engineering workstations and soone > decided that theyd4 > needed to enter the UNIX server market to continue > growing. Microsoft6 > was servicing a small but growing market for desktop > PC's, and Linuxr > was nowhere in sight.=20 >=204 > How things change! So at some point in the future, > when AlphaServersD1 > will no longer be supported, the market will bei > vastly different thanr3 > it is today. Which brings us to the point of thiso > exercise. Customersi4 > should buy the best server that is available today > for theirg0 > applications. In most cases, that server is an > AlphaServer runningP4 > Tru64 UNIX and TruCluster Server. Many servers are > deployed for onlyn3 > three to five years, but there is no need to stop  > buying AlphaServersi4 > and there is certainly no need to replace existing > AlphaServers.=20 >=20- > Here are some reasons to continue to selectr > AlphaServers over HP 9000t
 > servers:=20o >=208 > =B7 World-class leadership in cluster technology. When > you need to scalee4 > out, TruCluster Server is the worlds premiere UNIX > clustering product.o0 > HP's cluster product lags all other vendors in > functionality ande2 > technological sophistication. MC/ServiceGuard is > based on old,o5 > obsolete technology with no plans to be updated.=20l >=202 > =B7 The combination of TruCluster Server and the > AlphaServer GS was4 > ranked BEST IN CLASS for reliability, availability > and serviceability > (RAS) by D. H. Brown (seef >t8 http://www-unix.zk3.dec.com/www/competitive/dhba_ras.pdf >s@ http://www-unix.zk3.dec.com/www/competitive/dhbarasreport2.pdf). >=20 >=202 > =B7 Superiority of AlphaServer hardware. -- High > performance under aC3 > broad set of application loads and blazingly fast  > floating-point, > performance make them especially ideal for > compute-intensivef2 > applications. PA-RISC servers do not have strong > floating-point6 > performance and do not deliver the broad performance	 > and RASa0 > capabilities that AlphaServers can provide.=20 >=200 > =B7 A leader in the high performance computing > markets. The AlphaServer0 > SC leads in markets where customers demand the > absolute highest levels 3 > of computational performance available in generali > purpose servers. Wec5 > anticipate that AlphaServers will continue to do sou > for years.=20  >=203 > =B7 Compaq's TruCluster Server forms the basis ofe > Oracle's new 9i RAC.2 > This is unique technology collaboration with the > industry-leading > database vendor.=20S >=206 > =B7 Compaq's AlphaServer roadmap and performance. We > anticipate Compaq'sb- > previously announced roadmap for Alpha willc > outperform IPF for years.e4 > When IPF finally does surpass Alpha, customers can > choose to migrated > on their own timetable.=20 >=201 > 6. The new merged UNIX will be HP-UX, not Tru64r
 > UNIX.=20 >=206 > RESPONSE: HP has a great general-purpose data center > UNIX with broadn0 > ISV coverage. Compaq has great clustering; RAS > (reliability, , > availability, scalability) and performance > characteristics, gaining0 > share especially in high-performance technical > computing market3 > places. Converging the best of each onto the nextt > generation Itanium3 > platform will provide our customers with the mostg > robust enterprisev > UNIX on the market. =B5o >=20 >=20 >=20 > -- > Alan     =3D=3D=3D=3D=3DuL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Dn F=E1bio dos Santos Cardoso OpenVMS System Manager Rio de Janeiro - Brazil  fabiopenvms@yahoo.com.brL =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D3  2 __________________________________________________ Do You Yahoo!?, Make a great connection at Yahoo! Personals. http://personals.yahoo.com   ------------------------------    Date: 29 Oct 2001 06:25:11 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)- Subject: Re: Compaq blasts HP-3 Message-ID: <OGa8FloVaRtP@eisner.encompasserve.org>   ` In article <n2hqttkand1lg89ch2q0cfsmr88gfs0vhd@4ax.com>, Alan Greig <a.greig@virgin.net> writes:8 > On Mon, 29 Oct 2001 12:21:18 +0100, Jan-Erik Sderholm > <noone@dummy.com> wrote: >  >>From the article : >>C >>"We [Compaq] anticipate Compaq's previously announced roadmap fortD >>Alpha will outperform IPF for years. When IPF finally does surpass > G > HP probably anticipates that as well which is *exactly* why they willv9 > close down Alpha in favour of IA64 as fast as they can.   $ They aren't doing that with PA-RISC.   ------------------------------  % Date: Mon, 29 Oct 2001 07:20:49 -0500k- From: JF Mezei <jfmezei.spamnot@videotron.ca>e Subject: Re: Compaq blasts HPb, Message-ID: <3BDD4AD6.D7A9C6BC@videotron.ca>   Alan Greig wrote:s > H > There's an astonishing Compaq internal memo quoted on The Inquirer. ItB > says HP sales have been  hammering Compaq sales since the merger> > announcement and spreading 'FUD'. Compaq goes on the attack.  K There isn't much that Compaq can do to answer back. Compaq killed Alpha and. end-of-lifed Tru64.   K While there was one good argument about "buy what will serve you now, don'taN buy for a future nobody knows about",  the future of Digital products is stillN uncertain.  Buy what you need now, but you do need some assurance of a certain life for the products.    L That letter is pretty damming for Digital products though. It shows one sideL of the HP mentality, and that side may in fact win when HP gets its hands onL Compaq. And since Compaq has a record of not strongly publicly defending itsF alpha products, it is likely that the HP folks will succeed in furtherB relegating the ex-Digital products to the dark and humid basement.   ------------------------------  % Date: Mon, 29 Oct 2001 12:03:01 +0000u% From: Alan Greig <a.greig@virgin.net>o Subject: Re: Compaq blasts HPh8 Message-ID: <n2hqttkand1lg89ch2q0cfsmr88gfs0vhd@4ax.com>  6 On Mon, 29 Oct 2001 12:21:18 +0100, Jan-Erik Sderholm <noone@dummy.com> wrote:   >From the article :  >uB >"We [Compaq] anticipate Compaq's previously announced roadmap forC >Alpha will outperform IPF for years. When IPF finally does surpassd  E HP probably anticipates that as well which is *exactly* why they wills> close down Alpha in favour of IA64 as fast as they can. It's aA fascinating use of words "Compaq anticipate ( A company that soontA won't exist anticipates....)... roadmap for Alpha will outperformrD (note not that Alpha will outperform but the paper roadmap would!!)"  @ >Alpha, customers can choose to migrate on their own timetable."  C Great - left to myself my Alpha migration timetable would be never.oE Glad Compaq will support me with state-of-the-art machines that long.    >0 >Jan-Erik Sderholm.   -- Alan   ------------------------------  # Date: Mon, 29 Oct 2001 14:51:34 GMTn4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Compaq blasts HPn> Message-ID: <W1eD7.160420$vq.39216070@typhoon.ne.mediaone.net>  E > In article <n2hqttkand1lg89ch2q0cfsmr88gfs0vhd@4ax.com>, Alan Greigr <a.greig@virgin.net> writes:: > > On Mon, 29 Oct 2001 12:21:18 +0100, Jan-Erik Sderholm > > <noone@dummy.com> wrote: > >g > >>From the article : > >>E > >>"We [Compaq] anticipate Compaq's previously announced roadmap foroF > >>Alpha will outperform IPF for years. When IPF finally does surpass > >XI > > HP probably anticipates that as well which is *exactly* why they will ; > > close down Alpha in favour of IA64 as fast as they can.  >s  G "As fast as they can" and "for years" are not mutually exclusive. It'llnK probably be three years or more before IPF edges out Alpha. Until IPF has atB large NATIVE apps base, glueless interconnect technology, etc; the2 technology is not in a position to displace Alpha.  I Sure, HP has an IPF-ready platform (Superdome) but how well is it sellingi! when compared with the GS-series?T  L There's no reduction of activity in Marvel Mansion, so EV7 systems remain on2 track and almost certainly will continue to do so.   ------------------------------  % Date: Mon, 29 Oct 2001 15:35:30 +0000e% From: Alan Greig <a.greig@virgin.net>d Subject: Re: Compaq blasts HP 8 Message-ID: <8ctqtt4nuka6ubkuglrsjgpifop14rqf42@4ax.com>  4 On Mon, 29 Oct 2001 14:51:34 GMT, "Terry C. Shannon"" <terryshannon@mediaone.net> wrote:  H >"As fast as they can" and "for years" are not mutually exclusive. It'llL >probably be three years or more before IPF edges out Alpha. Until IPF has aC >large NATIVE apps base, glueless interconnect technology, etc; theU3 >technology is not in a position to displace Alpha.   F Arguably Unix is still not in a position to replace VMS and neither isE NT. Both have been pushed by Compaq over VMS and both were incredibly D inferior when DEC first started pushing them. All but a small subsetB of customers can live with the limitations. Only a small number of4 customers (other than VMS...) actually *need* Alpha.  D HP sales are signaling that Alpha is a dead end technology right nowC and are saying so to customers. How much damage will this do before D the merger goes through? Enough for HP to say: "the market has voted with its feet"?t > J >Sure, HP has an IPF-ready platform (Superdome) but how well is it selling" >when compared with the GS-series? >nM >There's no reduction of activity in Marvel Mansion, so EV7 systems remain ont3 >track and almost certainly will continue to do so.n  ? Oh, I'm sure EV7 systems will appear. I just doubt they will befF developed as far as current roadmaps suggest. Production quantity willC go way down and hence the price will rocket for those customers whop actually need them.-   My opinions of course!     -- Alan   ------------------------------    Date: 29 Oct 2001 09:37:57 -0800( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Compaq blasts HPa= Message-ID: <d7791aa1.0110290937.5509e792@posting.google.com>g  h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<g3S$dBxVYdaP@eisner.encompasserve.org>...b > In article <ovaqttkpbt1219orh6g2searh847a8tafa@4ax.com>, Alan Greig <a.greig@virgin.net> writes: > > J > > There's an astonishing Compaq internal memo quoted on The Inquirer. ItD > > says HP sales have been  hammering Compaq sales since the merger@ > > announcement and spreading 'FUD'. Compaq goes on the attack.I > > Unfortunately., imho, with words only. HP sales say one thing. Compaqe > > sales say another. > @ > Prior to merger, US law requires they act as true competitors.  F forget emulators ... you will kill roughly half of the cpu ... i had aF brief stint on an ibm as400 running system34 emulation under os400 andG it absolutely killed the cpu ... hp unix doing the same thing on itanicPH will perform worse!  charon vax is also in the same boat and no one fromJ compaq hp or whatever better try to push a vms emulator on me ... the portJ to itanic better be done and the new vms better perform or we will stay onF alpha as long as we can (10 years?) then goto ibm ... ibm charges highJ prices for inferior products but at least they understand the high end andK their risc processor is improving ... why couldn't have ibm bought digital,h4 they would have known what to do with alpha and vms!   ------------------------------  % Date: Mon, 29 Oct 2001 19:55:30 +0100I& From: John McLean <mcleanj@dplanet.ch> Subject: Re: Compaq blasts HP * Message-ID: <3BDDA622.DCFD09FC@dplanet.ch>   Bob Ceculski wrote:l > j > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<g3S$dBxVYdaP@eisner.encompasserve.org>...d > > In article <ovaqttkpbt1219orh6g2searh847a8tafa@4ax.com>, Alan Greig <a.greig@virgin.net> writes: > > > L > > > There's an astonishing Compaq internal memo quoted on The Inquirer. ItF > > > says HP sales have been  hammering Compaq sales since the mergerB > > > announcement and spreading 'FUD'. Compaq goes on the attack.K > > > Unfortunately., imho, with words only. HP sales say one thing. Compaqt > > > sales say another. > >rB > > Prior to merger, US law requires they act as true competitors. > H > forget emulators ... you will kill roughly half of the cpu ... i had aH > brief stint on an ibm as400 running system34 emulation under os400 andI > it absolutely killed the cpu ... hp unix doing the same thing on itanic.J > will perform worse!  charon vax is also in the same boat and no one fromL > compaq hp or whatever better try to push a vms emulator on me ... the portL > to itanic better be done and the new vms better perform or we will stay onH > alpha as long as we can (10 years?) then goto ibm ... ibm charges highL > prices for inferior products but at least they understand the high end andM > their risc processor is improving ... why couldn't have ibm bought digital, 6 > they would have known what to do with alpha and vms!  C I heard a story some time ago about Digital (yes, it was back then)oH creating an emulator (on Alpha) for one of IBM's operating systems.  TheC rumour was that it was good stuff but fearing a look-and-feel courtt+ battle, DEC dropped any ideas in that area.r  & Does anyone know any more about this ?     John McLeant   ------------------------------    Date: 29 Oct 2001 11:41:51 +0100G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>0& Subject: Re: Compaq financial humour !H Message-ID: <y4u1wiramo.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  " Steve.Spires@yellgroup.com writes:  B > Surely there can't be much profit in a $50m deal which includes  > 50,000 Proliant servers?  L This also means that the average selling price for such a server is now justI one thousand dollars. I hadn't realized it was that low. How much do theyo8 loose on each of them - another $1k at least, I suppose?   	Jan   ------------------------------  # Date: Mon, 29 Oct 2001 14:59:14 GMTf4 From: "Terry C. Shannon" <terryshannon@mediaone.net>& Subject: Re: Compaq financial humour !> Message-ID: <69eD7.160425$vq.39219160@typhoon.ne.mediaone.net>  9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagee' news:87k7xkr0ez.fsf@prep.synonet.com...o1 > JF Mezei <jfmezei.spamnot@videotron.ca> writes:  >aF > > > > By the way, did anyone else notice a total absence of anythingD > > > > about the transfer of Alpha to Intel ?  What did Compaq do ?! > > > > Did they give it away ???p >cF > > Considering that on June 25 when Alpha was murdered, Curly alreadyG > > knew that he was going to hand over Compaq to Carly, I would not beeG > > surprised if the Alpha deal with Intel was structured in such a wayr. > > to benefit HP once the merger is consumed. >l@ > > So payment for the murder of Alpha may start only next year. > = > Do you mean after HP take over? If so, the Q's shareholdersr" > would have a field day in court! >o  I Yet another reason to buy a few shares of CPQ while the stock price is inmK the cellar. One share will get you the coveted ducat that guarantees access D to stockholder meetings. What's more, said ownership will make you aG potential party to any class-action litigation that might rear its headf sometime down the road...h   ------------------------------  % Date: Mon, 29 Oct 2001 11:19:43 +0100H% From: "Fred Zwarts" <F.Zwarts@KVI.nl>p* Subject: Re: DCPS and manual feed timeout.. Message-ID: <9rjag1$e1s$1@info.service.rug.nl>  ? "Paul Anderson" <paul.r.anderson@compaq.com> wrote in message =e5 news:241020011404121791%paul.r.anderson@compaq.com...e< > In article <9r6kgv$pnd$1@info.service.rug.nl>, Fred Zwarts > <F.Zwarts@KVI.nl> wrote: >=20E > > On our first generation postscript printers, which we used with =s DCPS,oH > > we were used to set the manual feed time-out to a rather short time.> > > We did this with a piece of PostScript like the following: > >=20G > >     serverdict begin xxxx exitserver        % xxxx is the printer =  password > >=20 > >     statusdict beginI > >     0 60 0 setdefaulttimeouts              % job manualfeed wait 60 =t seconds  > >     end  > >=20F > > For the newer generation of HP printers, however, this does work = anymore.> > > The above piece of postscript exits with an error message:G > >     invalidaccess: Attempt to acces restricted object or capability 1 > >     - offending command is setdefaulttimeoutsa > ...snip... > >=20J > > I know that with PostScript level 2 and later, the exitserver method = is notF > > recommended anymore, but I can not find how to change the manual = feed=20 H > > timeout now. This seems to be a printer specific extension of the=20D > > PostScript standard. The PostScript standard does not mention=20G > > setdefaulttimeouts and for the HP printers we could not find the=20r/ > > documentation for the PostSript extensions.p >=20G > 'Setdefaulttimeouts' is a PostScript Level 1 compatibility operator =g andtA > is mentioned in the Adobe PostScript Language Reference Manual:  >=20 >     setdefaulttimeouts@ >       job manualfeed wait setdefaulttimeouts =AD (statusdict = dictionary)u >=20? >     sets the values of the system parameters JobTimeout and =d WaitTimeout ? >     (see Table 3.2 on page 15), and the page device parametera? >     ManualFeedTimeout (Table 2.2 on page 5) to job, wait, and  >     manualfeed, respectively.e >=20H >     This operator always accepts three operands, even if one or more = ofG >     the relevant system or page device parameters are not present. IfdG >     JobTimeout or WaitTimeout is absent, the corresponding operand iseH >     ignored; if ManualFeedTimeout is absent, the Policies dictionary = isH >     consulted and the applicable recovery policy is invoked (see PLR3, >     Section 6.2.7).l >=20E > I sent your code to a Compaq Laser Printer LNM40 and an HP LaserJeteF > 8150.  The Compaq printer accepted the code but the HP printer did = not,( > returning the 'invalidaccess' message. >=20C > This particular Compaq printer has Adobe PostScript, while the HPhD > printer does not.  It appears the problem is not with 'exitserver'F > since I can change the HP printer's password using 'exitserver', but? > rather with the HP implementation of the 'setdefaulttimeouts'b > compatibility operator.p  H OK. I already expected something like this. Does anyone know how HP's=20? 'setdefaulttimeouts' is implemented? Or where it is documented?t                   F.Z.   ------------------------------  # Date: Mon, 29 Oct 2001 09:59:56 GMTr* From: mark@*NO*SPAM*.co.uk (Mark Williams). Subject: Global Sections for IPC - performance. Message-ID: <3bdd281f.5550050@news.force9.net>   Hi,a  B We use global sections for IPC between separate processes and haveA noticed that it is now slower than the old mailbox solution.  CanSA anyone suggest any ideas for checking/optimizing the performance?q  A Also is there a big overhead in mapping a global section?  At thehA moment some mappings are done when needed.  Could it be better to   do all the mappings on start-up?   TIAq  
 Mark Williamsa   ------------------------------  # Date: Mon, 29 Oct 2001 11:16:32 GMTr? From: Jim.Johnson@software-exploration.nospam.com (Jim Johnson)f2 Subject: Re: Global Sections for IPC - performance/ Message-ID: <3bdd39fb.9566986@news.demon.co.uk>   < Well, the obvious first question is what has changed in yourE environment?  Has your software changed?  Has the OS version changed? @ Has the size of the global section changed?  Are you seeing more pagefaults than in the past?   Jim.    F On Mon, 29 Oct 2001 09:59:56 GMT, mark@*NO*SPAM*.co.uk (Mark Williams) wrote:   >Hi, > C >We use global sections for IPC between separate processes and havexB >noticed that it is now slower than the old mailbox solution.  CanB >anyone suggest any ideas for checking/optimizing the performance? >0B >Also is there a big overhead in mapping a global section?  At theB >moment some mappings are done when needed.  Could it be better to! >do all the mappings on start-up?M >g >TIA >e >Mark Williams >    Jim Johnsono Software Exploration, Ltd.) (remove '.nospam' from the reply address)3   ------------------------------  % Date: Mon, 29 Oct 2001 11:38:33 +0000  From: Roy Omond <Roy@Omond.net>e2 Subject: Re: Global Sections for IPC - performance) Message-ID: <3BDD3FBA.49F148EE@Omond.net>e   Mark Williams wrote:   > Hi,m >iD > We use global sections for IPC between separate processes and haveC > noticed that it is now slower than the old mailbox solution.  Can<C > anyone suggest any ideas for checking/optimizing the performance?i >eC > Also is there a big overhead in mapping a global section?  At the C > moment some mappings are done when needed.  Could it be better toa" > do all the mappings on start-up?  @ You may be sharing data between processes using global sections,B but what are you using for *communicating* between these processes4 (e.g. common event flags, DLM, RPC etc. etc. etc.) ?  	 Roy OmondA Blue Bubble Ltd.   ------------------------------   Date: 29 Oct 2001 13:00:26 GMT- From: forkosh@panix1.panix.com (John Forkosh) 2 Subject: Re: Global Sections for IPC - performance) Message-ID: <9rjjta$4uv$1@news.panix.com>-  + Mark Williams (mark@*NO*SPAM*.co.uk) wrote:eD : We use global sections for IPC between separate processes and haveC : noticed that it is now slower than the old mailbox solution.  Can C : anyone suggest any ideas for checking/optimizing the performance?t :aC : Also is there a big overhead in mapping a global section?  At thekC : moment some mappings are done when needed.  Could it be better tog" : do all the mappings on start-up?  9 If you were using mailboxes for ipc, maybe you don't needr< to map the global section at all.  Just keep it as a section: of shared memory.  Below is some code that works that way.9 Zeros in the middle of the $crmpsc call avoid mapping the  section to a file. John (forkosh@panix.com)  M /* ==========================================================================i0  * Function:	vmscrmpsc ( gsdnam, pagcnt, inadr ).  * Purpose:	Creates and maps a global section.M  * -------------------------------------------------------------------------- 7  * Arguments:	gsdnam (I)	addr of char string containing-/  *				name of the global section to be created. 6  *		pagcnt (I)	int containing number of 512-byte pages  *				in the global section.4  *		inadr (O)	ptr to addr of unsigned char returning-  *				starting addr where section was mapped.eM  * --------------------------------------------------------------------------'>  * Returns:	( int )		SS$_NORMAL if mapped to existing section,.  *				SS$_CREATED if section was just created,!  *				VMS error status otherwise.iM  * --------------------------------------------------------------------------h	  * Notes:sM  * ======================================================================= */x0 char	inbuf[64];				/* dummy target for crmpsc */ /* --- entry point --- */p' int	vmscrmpsc ( gsdnam, pagcnt, inadr )w
 char	*gsdnam;p int	pagcnt; 
 void	**inadr;i {tL /* ------------------------------------------------------------------------- Allocations and DeclarationsM -------------------------------------------------------------------------- */ B int	inadr_quadwd[2],retadr_quadwd[2];	/* inadr,retadr quadwords */$ int	flags;					/* type of section */3 static	char gsdbuf[64];			/* section name buffer */:1 struct	dsc$descriptor_s			/* gsdnam descriptor */q< 	gsd_desc = { 0, DSC$K_DTYPE_T, DSC$K_CLASS_S, &gsdbuf[0] };. int	vms_stat;				/* sys$crmpsc return status*/L /* ------------------------------------------------------------------------- Issue $crmpsc and returnM -------------------------------------------------------------------------- */ < flags = SEC$M_GBL | SEC$M_WRT | SEC$M_PAGFIL | SEC$M_EXPREG;8 inadr_quadwd[0] = inbuf;			/* starting addr of section*/4 inadr_quadwd[1] = 0;				/* ending addr of section */: strcpy ( gsdbuf, gsdnam );			/*local desc copy of gsdnam*/A gsd_desc.dsc$w_length = strlen(gsdbuf); 	/* desc string length */s vms_stat = SYS$CRMPSCu 		( . 		inadr_quadwd,			/* requested virtual addrs*/- 		retadr_quadwd,			/* actual virtual addrs */I 		0,				/* access mode */r& 		flags,				/* type of section mask */, 		&gsd_desc,			/* section name descriptor */$ 		0,				/* ident - version number */% 		0,				/* relpag- 1st page mapped */n% 		0,				/* chan- for file accessed */'* 		pagcnt, 			/* number pages in section */% 		0,				/* vbn- virtual blk in file*/l$ 		0,				/* prot - file protection */ 		0				/* pfc - cluster size */- 		);< if ( (vms_stat == SS$_CREATED) || (vms_stat == SS$_NORMAL) )= 	*inadr = (void *)(retadr_quadwd[0]);	/* start addr of sect*/t else/ 	*inadr = NULL;				/* return 0 if not mapped */O return ( vms_stat );+ } /* --- end-of-function vmscrmpsc() --- */t   ------------------------------  # Date: Mon, 29 Oct 2001 14:24:36 GMTs* From: mark@*NO*SPAM*.co.uk (Mark Williams)2 Subject: Re: Global Sections for IPC - performance/ Message-ID: <3bdd6612.21409154@news.force9.net>g  D On Mon, 29 Oct 2001 11:38:33 +0000, Roy Omond <Roy@Omond.net> wrote:   >Mark Williams wrote:i >  >> Hi, >>E >> We use global sections for IPC between separate processes and haveSD >> noticed that it is now slower than the old mailbox solution.  CanD >> anyone suggest any ideas for checking/optimizing the performance? >>D >> Also is there a big overhead in mapping a global section?  At theD >> moment some mappings are done when needed.  Could it be better to# >> do all the mappings on start-up?s >oA >You may be sharing data between processes using global sections, C >but what are you using for *communicating* between these processes 5 >(e.g. common event flags, DLM, RPC etc. etc. etc.) ?t   sys$hiber, sys$wake.  0 We use the lock manager for coordinating access.  D (The global sections are not mapped to files - we use SEC$M_PAGFIL).   Cheers,i  
 Mark Williams    ------------------------------    Date: 29 Oct 2001 07:50:10 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)r2 Subject: Re: Global Sections for IPC - performance= Message-ID: <cf15391e.0110290750.14b81a78@posting.google.com>   + mark@*NO*SPAM*.co.uk (Mark Williams) wrote:-2 > We use the lock manager for coordinating access.  < Do you often see the communicating processes in RWSCS state?  A If you check SHOW CLUSTER/CONTINUOUS with ADD CONNECTIONS and ADD.B CR_WAITS, do you see a lot of credit waits on VMS$VAXcluster SYSAP; connections?  (If so, consider raising the SYSGEN parametert
 SCS_CREDITS.)t  F > (The global sections are not mapped to files - we use SEC$M_PAGFIL).  B That just means they're mapped to a pagefile instead of some otherB file.  Is there plenty of free memory?  Do you see a lot of paging	 activity?g  $ Or did you mean to say SEC$M_PFNMAP?C -------------------------------------------------------------------lC Keith Parris | parris at encompasserve dot org | VMS consulting on:oC Clusters, Disaster Tolerance, Internals, Performance, Storage & I/Oe   ------------------------------    Date: 29 Oct 2001 08:05:03 -0800, From: ezharkov@yahoo.com (Eugene A. Zharkov)J Subject: Re: How to redirect output&error into a single file in sys$creprc= Message-ID: <af0b5c61.0110290805.6fd30bab@posting.google.com>e  k hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<AXkB7.853$RL6.9604@news.cpqcorp.net>...in > In article <af0b5c61.0110231245.5771adeb@posting.google.com>, ezharkov@yahoo.com (Eugene A. Zharkov) writes:C > :The following example creates two versions of the test.log file. 9 > :Is there an easy way to tell creprc to make just one ?m >  .. D > :    int status = sys$creprc (NULL, &image, NULL, &output, &error,1 > :			     0, 0, &name, 0, 0, 0, PRC$M_DETACH);  - > D >   You could specify the error argument as NULL, causing errors and- >   output to both be routed to the output...   B I tried error as NULL. In that case stderr does not get redirected to the output.   ------------------------------  # Date: Mon, 29 Oct 2001 16:35:49 GMTe= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)8J Subject: Re: How to redirect output&error into a single file in sys$creprc0 Message-ID: <00A043F6.5204075F@SendSpamHere.ORG>  l In article <af0b5c61.0110290805.6fd30bab@posting.google.com>, ezharkov@yahoo.com (Eugene A. Zharkov) writes:l >hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<AXkB7.853$RL6.9604@news.cpqcorp.net>...o >> In article <af0b5c61.0110231245.5771adeb@posting.google.com>, ezharkov@yahoo.com (Eugene A. Zharkov) writes:.D >> :The following example creates two versions of the test.log file.: >> :Is there an easy way to tell creprc to make just one ? >>  ..E >> :    int status = sys$creprc (NULL, &image, NULL, &output, &error,m2 >> :			     0, 0, &name, 0, 0, 0, PRC$M_DETACH);   >> aE >>   You could specify the error argument as NULL, causing errors andy. >>   output to both be routed to the output... >aC >I tried error as NULL. In that case stderr does not get redirected  >to the output.s  I Ah... C!  That's your fault for using a poor implementation language.  :)   G Here's what I've done in the past for logging operations in my productss/ unfortunately sourced in C.  Here's an example:d   /*! ** Copyright 2001 TMESIS SOFTWARE ! ** Contact me if you want to use.  */ #include <stdio.h> #include <unixio.h>s main()   {      char logfilenm[255];        fgetname(stdout, logfilenm);     fclose(stdout);s     delete(logfilenm);I     stdout = fopen(logfilenm,"w","shr=get","rfm=var","rat=cr","mrs=255");r     stderr = stdout;  *     printf("This is written to STDOUT\n");*     perror("This is written to STDERR\n");   }0    G Also, I modify the access semantics of the log file so that I can view i1 its contents at the application is writing to it.!     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMs            mJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesp   ------------------------------    Date: 29 Oct 2001 10:56:33 -0600 From: briggs@encompasserve.orgJ Subject: Re: How to redirect output&error into a single file in sys$creprc3 Message-ID: <9z3P1MF5XA0e@eisner.encompasserve.org>   l In article <af0b5c61.0110231245.5771adeb@posting.google.com>, ezharkov@yahoo.com (Eugene A. Zharkov) writes:B > The following example creates two versions of the test.log file.8 > Is there an easy way to tell creprc to make just one ?  B $CREPRC doesn't make the two versions.  Your program (or the C RTL living underneath it) does.   F All $CREPRC is going to do with the input, output and error parametersB is to pass them as predefined values for the SYS$INPUT, SYS$OUTPUTA and SYS$ERROR logical names.  It will not pre-open them as files.e  E From the point of view of your program, the SYS$INPUT, SYS$OUTPUT and @ SYS$ERROR logical names are pure text.  That they are most oftenB associated with the file names for standard input, standard outputB and standard error is merely a matter of convention.  Your program$ is free to interpret them otherwise.  @ In the case at hand, your program is using STDIO to do output onA standard output and standard error.  It is depending on the C rune= time library to open up the standard output and error streamsh automatically as needed.  0 You have at least the following ways to proceed:  A 1.  Check the SYS$OUTPUT and SYS$ERROR logical names yourself ando( reopen the appropriate streams to taste.  C 2.  Use SYS$SYSTEM:LOGINOUT.EXE as the launched image.  Its default-8 behavior is to open SYS$INPUT as a DCL command procedure? and to open SYS$OUTPUT as a process permanent file and set bothe: SYS$OUTPUT and SYS$ERROR to point to this pre-opened file.   3.  Use LIB$SPAWN() or SYSTEM().   	John Briggs   ------------------------------    Date: 29 Oct 2001 06:26:34 -0800! From: soterro@yahoo.com (Soterro).( Subject: Installing CC060 on VMS VAX 6.1= Message-ID: <d5440555.0110290626.4470edb8@posting.google.com>w   Hello,  B I'm trying to install the C compiler on the named machine, and got" stuck by a 'file not found' error:   ...hB All questions have been answered. The installation will take 10-30 min.+ depending on system load and configuration.e=         The C Runtime Library headers and Starlet headers are0 installed asA         a Text Library (.TLB).  The traditional text form  of then headers0F         (.H files) is also provided (for  reference  purposes only) inD         the directories: SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] and 6         SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C].C         Please note that the compiler does not search the reference  areasi7         SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] and <         SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C] during compilation.8         Instead headers are taken from the text library.& (note: stays here for a loooong while) %RMS-E-FNF, file not found %RMS-E-FNF, file not found= %VMSINSTAL-E-INSFAIL, The installation of CC V6.0 has failed.f ...e  F I extracted KITINSTAL.COM with backup out of the installation kit, and, (I think) the problem is in this subroutine:   ...t  $provide_lotsa_files: SUBROUTINE* $ ON CONTROL_Y THEN VMI$CALLBACK CONTROL_Y $ ON WARNING THEN EXIT $STATUS
 $ HEADER = P1  $ target_dir = p2s $ datafile_name = p3 $!! $ if f$parse(target_dir) .eqs. ""i $ then1 $	VMI$CALLBACK CREATE_DIRECTORY USER 'target_DIR'e' "/PROTECTION=(S:RWED,O:RWED,G:RE,W:RE)"u $ endif , $ open/write outfile vmi$kwd:'datafile_name' $! $more_headers2:a> $ ccxx$filespec = f$search(f$parse("VMI$KWD:",HEADER,"*.H"),1)3 $ if ccxx$filespec .eqs. "" then goto done_headers2 Q $ ccxx$filespec = f$parse(ccxx$filespec,,,"NAME")+f$parse(ccxx$filespec,,,"TYPE") 4 $ write outfile "X ''ccxx$filespec' ''target_dir' C" $ goto more_headers2 $done_headers2:e $ close outfilee; $ VMI$CALLBACK PROVIDE_FILE "" vmi$kwd:'datafile_name' "" TP $ ENDSUBROUTINEy ...s  D The directory is created fine, but after the failure I find no filesD in it. Anyway, I wanted to make sure that is the problem, so I addedE some neat messages to the KITINSTAL.COM and tried to put it back intodE the kit. Well that didn't work anymore. It is not about my changes, IsC tried to put back the version I extracted and still the same. I usep, the command as seen in the backup file, with   $ backup cc060.a/save/list   so the command is like:h   $ BACKUP/COMMENT="DEC C Binary? Kit"/INTERCHANGE/LOG/VERIFY/IGNORE=LABEL/NOASSIST kitinstal.com' cc060.a/LABEL=(C)/SAVE  E I must say I omitted in the command line the directories that DigitaloC used to have to store the stuff. No complaints here, but this givesh: the following quick result when trying to install the kit:   ...-4 * Enter installation options you wish to use (none):) The following products will be processed: 	   CC V6.0o2         Beginning installation of CC V6.0 at 14:066 %VMSINSTAL-I-RESTORE, Restoring product save set A ...= %VMSINSTAL-E-INSFAIL, The installation of CC V6.0 has failed.h ...    Any ideas here?t  F ..and yes, for each problem I post here I ask first the Compaq support8 people, from which I had NO working solution ever (yet).   Thanks,  Sorin Costea   ------------------------------  % Date: Mon, 29 Oct 2001 07:46:02 -0700t4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>) Subject: Re: MIME Compliant Mail from VMS 0 Message-ID: <MYdD7.16$b%2.44265@news.uswest.net>   Patrick,  I Did you get my bug report?  v0.7 of Mailbox won't allow me to send a bodyI2 file and an attachment file on our VMS 7.3 system.   --
 Mike Ober.  : "Patrick LE QUERE" <plequere@hotmail.com> wrote in message5 news:66f3c2.0110271053.1879c0e0@posting.google.com...r > Hi,a >dH > I have written a freeware utility called MAILBOX, which supports MIME. >lC > MAILBOX features a full-screen interface, but may also be used ina > command procedures.k >l- > The following example is self-explanatory :i > > > $ MLB_CMD SEND /Subject="Here are the files you requested" - > /Body=MESSAGE_BODY.TXT -C > /Attachments=("INTRO.TXT", "CHART.XLS", "LISTING.C", "PIC.BMP") -n- > /To=(fred, "thisguy@sky.com", bob, chris) -e1 > /Cc=("myboss@my-firm.com", "@colleagues.dis") -  > /Bcc="mulder@fbi.gov"e >e+ > Have a look at http://patrick.lequere.netp >s > Sincerely, >g	 > Patrick  >r >iA > "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> wrote in messageo, news:<LOWB7.458$Mw.95212@news.uswest.net>...K > > How can I attach a file to a VMS generated SMTP Mail Message?  The file 4 > > needs to appear as an attachement in MS-Outlook. >p   ------------------------------  % Date: Mon, 29 Oct 2001 11:43:23 +0000t% From: Alan Greig <a.greig@virgin.net>o8 Subject: Peter Blackmore says nothing positive about VMS8 Message-ID: <ajfqtt8dq45ru4joua6jte6cl5fss8vr73@4ax.com>  @ Compaq have filed yet another SEC document. This time it's PeterF Blackmore talking to UK Compaq employees. I'll quote two sections here   http://quicken.elogic.com/sec_grab.asp?ticker=CPQ&faddr=edgar%2Fdata%2F714154%2F0000912057%2D01%2D536344%2Etxt&fkey=0000912057%2D01%2D536344&ftype=425   Quote 1: =======n They see the synergies infE bringing the two companies together, they see the strength in an evenL moreC capable, larger services organization with huge critical mass. They- see the-E strengthening of the Unix portfolio, the strengthening of the storage(
 portfolio,D and obviously the industry standard servers will go from strength to	 strength,@C Himalaya is unchanged, and the Access devices, we have even greatere critical mass.o  C Hmm what about VMS then? And, of course, it's obvious that the losswC making industry standard group will go from strength to strength...e   Quote 2: =======i At any time if youF need the help of any manager in Compaq -- whether it's myself, Michael	 Capellas,eC Jeff Clarke, Mary McDowell, Howard Elias, Mark Lewis, Mike Winkler,a just anyoneg -- you have only to ask. It cann  A But doesn't bother to mention  Mark Gorham or even Rich Marcello. F You'd think, given the Alphacide and the 'FUD'  Compaq complains HP ofE all companies is spreading, that Rich Marcello might have been top ofa
 the list..  F Only mention of VMS is in "There's a new investment protection programE for the whole of the Alpha, Unix and Open VMS range that comes out inr the next week"  E Hmm given the supposed future life of Alpha it will be interesting to-A see exactly why I would need my investment protected now and what  from...m       -- Alan   ------------------------------    Date: 29 Oct 2001 10:30:33 -0800, From: sanface@sanface.com (SANFACE Software) Subject: PLUG: txt2pdf 5.3= Message-ID: <18712ccd.0110291030.72a568c2@posting.google.com>   / We would like to announce txt2pdf 5.3 version. a# http://www.sanface.com/txt2pdf.html-E txt2pdf is shareware; it is a very flexible and powerful PERL5 script B that converts text files to PDF format files, so you can use it inE every operating systems supported by PERL5, including MPE/iX, OpenVMS-C and EPOC. If you prefer we also distribute executables for Windows, F Linux, Solaris, AIX, HP-UX, and FreeBSD. Inside the Windows version is Visual txt2pdf, a VB GUI.b   What's new in this version  @ Now the text can contain Mac EOL (end of line) (\r), Windows EOL (\r\n), Unix EOL (\n). FAQ. n   Test txt2pdf 5.3!a6 You can find it at http://www.sanface.com/txt2pdf.html   ------------------------------  % Date: Mon, 29 Oct 2001 14:45:42 +0300-4 From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> Subject: RWINS0 Message-ID: <3BDD4166.62D48168@SMTP.DeltaTel.RU>   Hi All!/ 	What is RWINS status ?o  O 21891645 TOT_SRV$IO      RWINS    5   109317   0 00:00:58.46      3253   1707 Mr   -- 	 Cheers,aF +OpenVMS [Sys|Net] HardWorker .......................................+E  Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222-E  191119,St.Petersburg,Transportny per. 3                     116-3222mF +http://starlet.deltatel.ru ................. SysMan rides HailStorm +   ------------------------------  # Date: Mon, 29 Oct 2001 14:17:39 GMTC1 From: "Mark D. Jilson" <jilly@clarityconnect.com>a Subject: Re: RWINS2 Message-ID: <3BDD6529.169652FC@clarityconnect.com>  C This means you have a threaded application and the 'main' thread iscH waiting on an inner mode semaphore.  You will need to use SDA to look atC the state of each of the threads.  I have seen this with JAVA basedqF applications (i.e. one thread was in RWMBX so the 'main' thread was in INNER)   "Ruslan R. Laishev" wrote: > 	 > Hi All!e  >         What is RWINS status ? > Q > 21891645 TOT_SRV$IO      RWINS    5   109317   0 00:00:58.46      3253   1707 Mf >  > --	 > Cheers, H > +OpenVMS [Sys|Net] HardWorker .......................................+G >  Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222iG >  191119,St.Petersburg,Transportny per. 3                     116-3222)H > +http://starlet.deltatel.ru ................. SysMan rides HailStorm +   --  D Jilly	- Working from Home in the Chemung River Valley - Lockwood, NY0 	- jilly@clarityconnect.com			- Brett Bodine fan. 	- Mark.Jilson@Compaq.com			- since 1975 or so, 	- http://www.jilly.baka.com               -   ------------------------------    Date: 29 Oct 2001 05:30:21 -0800. From: SPAMSINK2001@YAHOO.COM (Alan E. Feldman)@ Subject: Re: SHOCK, HORROR, VMS & TRU64 STAFF RUSHED TO HOSPITAL= Message-ID: <343f30ae.0110290530.6a59b2d5@posting.google.com>c  M Dirk Munk <munk@home.nl> wrote in message news:<3BD950C3.FB5D73D1@home.nl>...wF > A few days ago VMS and Tru64 staff in The Netherlands were rushed to > hospital.mI > Without any prewarning they were subjected to a Compaq radio commercialoI > promoting the use of VMS and Tru64 clusters ! NO, not Windooz clusters,i4 > but REAL clusters ! And VMS was mentioned first !!       Holy SYS$PETUNIAS!!!  G > It took experienced brain specialists several hours to restore normalm8 > Alpha wave activity in the brains of the poor victims.  %     I hope their SYS$BRAINs are okay.$  J > At the same time the Royal Dutch Airforce scrambled interceptor fightersJ > to investigate strange objects on the radar screens. Once in the air theI > pilots discovered large flocks of flying pigs, migrating south to spend5 > the winter in Africa !       Speeded-up SYS$EVOLUTION!s   > J > Our Compaq account manager was even able to supply us with a MP3 file ofG > the commercial. Needless to say it is now a integral part of the homem" > page of our VMS intranet server.       I'm about to sys$faint!o   > J > On request I can send it to anyone interested. It is in Dutch of course,D > but you can clearly hear the words VMS, Tru64 and cluster ! And it@ > mentions a report by DH Brown where VMS and Tru64 clusters are > recommended. >  > WOOOOOOW   !!!!t       SYS$WOW!!!  < Disclaimer: JMHO                                     SYS$BRO Alan E. Feldmanj afeldman      blah blah blah gfigroup.com  - Replace "      blah blah blah^M" with at-signm   ------------------------------  % Date: Mon, 29 Oct 2001 10:29:04 +0000C( From: Nic Clews <sendspamhere@127.0.0.1>* Subject: Re: Single or Multiple Sys Disks?) Message-ID: <3BDD2F70.438EC283@127.0.0.1>|   John McLean wrote: >  > Ed Wilts wrote:r > > = > > In article <3BD58F71.1E80C13C@vmmc.org>, "Jack Trachtman"-$ > > <Jack.Trachtman@vmmc.org> wrote: > >0M > > > After all these years managing stand alone VMS systems, I'll finally betA > > > getting to manage two clustered systems: 2xES45 and 3xES45.1 > > >5H > > > My question: How to choose between single system disk and multipleJ > > > disks.  The first is easier to manage, but the second allows rolling. > > > upgrades w/less down time for the users. > >oP > > I'd vote for 2 system disks, plus a separate common disk that will hold your. > > sysuaf, rightslist, vmsmail profiles, etc.  G > I missed the start of this thread but I'd opt for one system disk butuI > make it shadowed.  Upgrade by dropping one member out of the shadow seteH > to keep it in reserve in case the upgrade goes to mush and you have to > reinstate the old system.   A With this class of system I'd prefer seperate system disks from aLH performance point of view, I certainly would not want to MSCP serve overF a LAN, so I'd only share if there was a SCSI or other controller basedD sharing of the data. I'd be wary of dependence on one system for all data.e  H Maybe Hoff or someone would like to comment on what the read level wouldG typically be on a booted system disk? (Ignore writing of security logs,s accounting and page and swap).  @ I'm interested. (I know it depends, but what is typically read?)  HH > As for dump files, since about VMS7.2 (I think) your dump files can be" > on disks other than system disk.  G Since about 6.2 (or was it a typo, probably) and it works well. In this G situation I'd be encouraged to have page and swap and dump on a 'local': dedicated disk.w   -- e( Regards, Nic Clews CSC Computer Sciences nclews at csc dot come   ------------------------------    Date: 29 Oct 2001 08:50:33 -0600+ From: young_r@encompasserve.org (Rob Young)d* Subject: Re: Single or Multiple Sys Disks?3 Message-ID: <$85pOqTfTsGO@eisner.encompasserve.org>t  S In article <3BDC7358.37B7031C@dplanet.ch>, John McLean <mcleanj@dplanet.ch> writes:h >  >  > Ed Wilts wrote:t >> u< >> In article <3BD58F71.1E80C13C@vmmc.org>, "Jack Trachtman"# >> <Jack.Trachtman@vmmc.org> wrote:g >> pL >> > After all these years managing stand alone VMS systems, I'll finally be@ >> > getting to manage two clustered systems: 2xES45 and 3xES45. >> >G >> > My question: How to choose between single system disk and multiplelI >> > disks.  The first is easier to manage, but the second allows rolling - >> > upgrades w/less down time for the users.e >> "O >> I'd vote for 2 system disks, plus a separate common disk that will hold yourh- >> sysuaf, rightslist, vmsmail profiles, etc.i >> tI >> My thinking is that you can always install patches on one system disk,gE >> and even if all hell breaks loose, you can mount the busted set ontK >> another system and fix the darn thing.  Rolling upgrades become simpler,(D >> and although you have to do all your patches twice,  the benefitsJ >> far outweigh the gains.  The first time you need to have another systemY >> up and running to fix a broken disk will be the day you vow never to limit yourself to0 >> a single system disk. >> eH >> Also to consider:  the size of your crash dump files, whether they'reF >> common or individual (5 individual dump files on 1 system disk willJ >> probably fill your disk depending on how much memory you have), and how >> busy the system disks are.i >>   >>         .../Edm >> r >> --w! >> Ed Wilts, Mounds View, MN, USA  >> mailto:ewilts@ewilts.orgc > G > I missed the start of this thread but I'd opt for one system disk butrI > make it shadowed.  Upgrade by dropping one member out of the shadow setoH > to keep it in reserve in case the upgrade goes to mush and you have to > reinstate the old system.Y > H > As for dump files, since about VMS7.2 (I think) your dump files can be" > on disks other than system disk. >   @ 	Since about VMS 6.2 and there is a fairly comprehensive article< 	on DSNlink that talks about and gives "how tos" to do DOSD.   				Robr   ------------------------------  % Date: Thu, 25 Oct 2001 23:27:33 +0100o. From: Roger Barnett <roger@natron.demon.co.uk>; Subject: Re: Slightly OT - how failed computers kill ships. 1 Message-ID: <EtmXmjAVHJ27EwXd@natron.demon.co.uk>I  J In article <d7791aa1.0110161241.78d7f12f@posting.google.com>, Bob Ceculski <bob@instantwhip.com> writesQ >Steve.Spires@yellgroup.com wrote in message news:<00256AE7.0055AFE9.00@quegw01.b$ >> TR >> For those in the UK, or who have Channel 4 available via SKY there is a programS >> tonight at 9:30pm called 'Going Critical' which details the series of errors and K >> failures [including the computer systems shutting down] which led to HMScR >> Coventry [of which I am an ex-stoker] being sunk by old, relatively slow planes# >> with bombs during the Falklands.S >> .L >> It should be compulsory viewing for all those who make decisions on using >> computers to run ships.  L Well if it was Ferranti Argus + Coral then we're talking 1960s technology...  O The root cause was, as usual, poor management; first from the 'planners' in not S understanding the shortcomings of the technology (or perhaps they preferred to justlS trust the spiel from the ex-navy chaps that sold it to them), second in the captainsO who allowed his ship to move between the attacking planes and his only defence.   d  L >hopefully someone from the u.s. navy dept. watches it and begins to realize= >how dumb it was to pick nt over vms for our ship operations!   R The reason for using PC-type technology is to present a computer games -style userR interface to forces personnel who it is assumed will be increasingly dependent on,T and skilled with, graphical presentations (the old fashioned term is illiterate). As> far as I know the US defence chiefs are quite open about this.  T Of course there is also the side benefit of reducing the personal connection between action and consequence.n   -- a
 Roger Barnetto  = "OpenVMS is today what Microsoft wants Windows NT v8.0 to be"u Compaq Web Site, 22-Sep-1998   ------------------------------    Date: 29 Oct 2001 05:48:12 -0800( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: SSH for Alpha VMS< Message-ID: <d7791aa1.0110290548.e205a79@posting.google.com>  ` "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message news:<3BDCCB13.59548EC7@fsi.net>...E > > > > > > Is there anyway of getting sn SSH server pre-compiled foriI > > > > > > an Alpha VMS system since I don't have access to DEC C having(: > > > > > > surrendered our VAX C license many years ago ?	 > > > > >a > > > > > Amy Lewis_ > > > >aO > > > > run tcpware ... it performs alot better than either multinet or ucx ...p > > >.1 > > > Do you have any statistics to back this up?a > > >x@ > > > Ed James                           ed.james@telecomsys.com; > > > TeleCommunications Systems, Inc.   voice 410-295-19192A > > > 2024 West Street, Suite 300              800-810-0827 x1919"; > > > Annapolis, MD 21401-3556           fax   410-280-1094  > > > Bob Ceculski wrote:bI > > i certainly do ... we went thru several months of performance testingtL > > on our alpha web server using ucx, multinet and tcpware ... we ran threeG > > different web servers, osu, apache and purveyor ... tcpware ran theoL > > crispest hands down ... the same thing happened with ucx from vms kernelI > > based 4 to inix kernel based version 5 ... it got "slower"!  our vice0L > > president took part in the testing an the response times were definitiveF > > same for purveyor ... it was written for vms (processed based) ...F > > even folks at process software agreed with me when i told them theJ > > results and said that they had done some adjustments to narrow the gapC > > but admit it still exists ... properly written vms kernel basediF > > software will always out run unix based, thats common sense and weG > > proved it ... both products are almost identical in features on vmslG > > except i love using decnet phase iv over ip, something no other vmssJ > > ip stack can do ... so why not use "the" premier ip stack for vms that2 > > was "written" for vms by former vms engineers? > & > IMO, the management interface sucks. > E > Multinet has its drawbacks, also, but sucks much less than TCPware.i > B > Both could have taken a lesson from NCP, without making the same > mistakes as UCX.  L they have a management interface if you want to pay extra, but i think netcuJ management is easy ... most of time i can configure want i want by editingJ the tcpware configuration file if you know what you are doing ... also theM logic of the commands is much easier than ucx ... multinet and tcpware on thekK command level are very similiar because process software owns both, the big7J difference being that tcpware runs best because it is vms kernel based ...L multinet and ucx are unix based ... we did extensive testing and tcpware wonI conclusively ... you can accept our findings or ignore them ... your lossw on performance!l   ------------------------------  % Date: Mon, 29 Oct 2001 10:37:22 -0500u  From: jamese@beast.dtsw.army.mil Subject: Re: SSH for Alpha VMS0 Message-ID: <01102910372245@beast.dtsw.army.mil>  I bob@instantwhip.com (Bob Ceculski) wrote on 29 Oct 2001 05:48:12 -0800 ing1 <d7791aa1.0110290548.e205a79@posting.google.com>:a  N > they have a management interface if you want to pay extra, but i think netcuL > management is easy ... most of time i can configure want i want by editingL > the tcpware configuration file if you know what you are doing ... also theO > logic of the commands is much easier than ucx ... multinet and tcpware on thelM > command level are very similiar because process software owns both, the big0L > difference being that tcpware runs best because it is vms kernel based ...N > multinet and ucx are unix based ... we did extensive testing and tcpware wonK > conclusively ... you can accept our findings or ignore them ... your lossm > on performance!o  M You have again posted statements without any backup documentation. Why shouldbL we accept your "findings" when you don't support them with facts? Until then- I have to take your statements as subjective.   
 Again, I say:y  + Do you have any statistics to back this up?i  : Ed James                           ed.james@telecomsys.com5 TeleCommunications Systems, Inc.   voice 410-295-1919T; 2024 West Street, Suite 300              800-810-0827 x1919n5 Annapolis, MD 21401-3556           fax   410-280-1094    ------------------------------    Date: 29 Oct 2001 09:53:38 -0800( From: bob@instantwhip.com (Bob Ceculski)> Subject: windows xp already hacked ... while vms "unhackable"!= Message-ID: <d7791aa1.0110290953.10f1d39f@posting.google.com>   C inquirer article about the new windows xp security enhancements ...=B now takes 2 seconds instead of the previous one second to hack!  i think is& am going to be on vms for a long time!  ' http://www.theinquirer.net/26100112.htm   C SOMEONE AT THE MICROSOFT LAUNCH asked Steve Ballmer yesterday aboutoC automated installation files that crack the anti-piracy features inh" the spanking new operating system.) Ballmer did not respond to that question.s  C There's a telling picture over at the Taipei Times which shows justnF how fast the counterfeiting has started with XP Pro costing $1.30, and which you can view here.  E But now Bitarts Labs has claimed that illegal installation files thathE bypass registration for WinXP were available within hours of it being 	 for sale.   B The files are on Web sites in the Far East and are now donloadable3 from Warez sites all over the across, Bitarts said.   > That means it's only a short step to pirated boxed counterfeit; software being available in the bazaars of Asian countries.6  B John Safa, CTO at Bitarts, a Nottingham firm, said: "Crackers have= studied and bypassed the security by using publicly availablea? monitoring tools. The cracks are simplistic in their nature andtF reflect an uncanny naivety from the Redmond giant on the high level of7 technical intellect within today's cracking community."n   ------------------------------  # Date: Mon, 29 Oct 2001 11:57:47 GMT,' From: Colin Blake <colin@theblakes.com> % Subject: Re: [MOZILLA] Applications ? - Message-ID: <3BDD443A.2D5AEA0D@theblakes.com>   P I believe so. The way Mozilla is at the moment (and as far as I know, it'll stayQ this way), if you want to add support for a new protocol then you need to write atO component that loads at Mozilla startup time and identifies itself as being ther handler for the new protocol.v  M In order to make it easier for people to add new protocols there is a projectRO called protozilla. You can read all about this at http://protozilla.mozdev.org/   P And, also as far as I know, mozilla.org are still planning on shipping "terminalB clients" for things such as telnet, rlogin, and ssh, see bug 94344Q (http://bugzilla.mozilla.org/show_bug.cgi?id=94344), its just that there's no oner to do the work just yet.   Colin.   ------------------------------   End of INFO-VAX 2001.602 ************************