1 INFO-VAX	Wed, 27 Apr 2005	Volume 2005 : Issue 233       Contents: Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this?  Re: Could a PC do this? = create new operator.log file from batch (I should know this.) A Re: create new operator.log file from batch (I should know this.)  Dynamic Volume Expansion+ Executable Code redirected to screen output / Re: Executable Code redirected to screen output / Re: Executable Code redirected to screen output / Re: Executable Code redirected to screen output / Re: Executable Code redirected to screen output 2 How do I block an ip address in tcpip for OpenVMS?6 Re: How do I block an ip address in tcpip for OpenVMS?6 Re: How do I block an ip address in tcpip for OpenVMS?6 Re: How do I block an ip address in tcpip for OpenVMS?4 Re: How to install DCPS 2.4 without stopping queues?4 Re: How to install DCPS 2.4 without stopping queues?4 Re: How to install DCPS 2.4 without stopping queues?4 Re: How to install DCPS 2.4 without stopping queues?" Re: IP Failover: strange behaviour" Re: IP Failover: strange behaviour" RE: IP Failover: strange behaviour" Re: IP Failover: strange behaviour" Re: IP Failover: strange behaviour" Re: IP Failover: strange behaviour$ ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability!( Re: ISE proves OpenVMS future viability! Re: Legato NetWorker8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business....8 Re: Maybe HP should get out of the hardware business.... Multia needs new OS  Re: Multia needs new OS ' OpenVMS Pearl from today from IT Weekly  This is strange  This weeks boot camp update  Re: TK50 Re: TK50 Re: TK50 Updated VMS information   F ----------------------------------------------------------------------  % Date: Wed, 27 Apr 2005 01:11:55 +0200 3 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com>   Subject: Re: Could a PC do this?= Message-ID: <426ecabb$0$78285$157c6196@dreader1.cybercity.dk>   0 "Doc." <doc@openvms-rocks.com> wrote in message 1 news:Xns9640E38DF980Bdcovmsrox@212.100.160.126... , > %NEWS-I-NEWMSG, Stanley F. Quayle wrote in' > news:42691E98.7156.2F05890C@localhost  > , >> On 22 Apr 2005 at 20:38, Dr. Dweeb wrote:* >>> So, how about CHARON-ALPHA or similar?I >>> Now that the Alpha is dead and smelly, it seems that this is the next  >>> obvious development. >>? >> Well, you can still buy new Alphas, so it's not as urgent as + >> replacing VAXen.  However, stay tuned...  > K > Isn't there the issue of having a processor with enough "oomph" to run an J > emulator and original platform software at an acceptable speed?  The wayK > I've seen things posted recently it's a big deal that Charon-VAX can run   > onH > a PC and have better performance than the best VAX ever.  That's now,  > which 4 > is *how* many years after VAX development stopped? >   H True, but for people like me, multiple VMs running different OSs on one L machine has great appeal, rather than several physical boxes (I am a VMWare M user as well).  Performance of an Alpha emulator only needs to be "adequate"  M from my point of view - I do not intend doing performance tests, but to test  1 functionality, and performance is not a big deal.   	 Dr. Dweeb    >  > Doc. > --  I > OpenVMS:     Eight out of ten hackers prefer *other* operating systems. J > http://www.openvms-rocks.com    Deathrow Public-Access OpenVMS Cluster.    ------------------------------  % Date: Tue, 26 Apr 2005 16:27:28 -0700 # From: "Tom Linden" <tom@kednos.com>   Subject: Re: Could a PC do this?( Message-ID: <opspu4r206zgicya@hyrrokkin>  / On Wed, 27 Apr 2005 01:26:36 +0200, Dr. Dweeb   ( <NOSPAM_5msg0h202@sneakemail.com> wrote:  # > The noble art of deconstruction ! I > I think I have also made the comment on another occasion that only HP    > calls  > IA64 industry standard. 4 > In fact I saw it on a VMS engineering slide today!  5 The slide lacks integrity and is wishful daydreaming.    ------------------------------  % Date: Wed, 27 Apr 2005 01:26:36 +0200 3 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com>   Subject: Re: Could a PC do this?= Message-ID: <426ece2a$0$78283$157c6196@dreader1.cybercity.dk>   9 "Karsten Nyblad" <nospam@nospam.nospam> wrote in message  7 news:426b3340$0$67262$157c6196@dreader2.cybercity.dk...  > Main, Kerry wrote:H >> JF - If you want to know what Intel is really positioning for x86 andC >> IA64 (as opposed to making up your own views), check out Intel's ( >> whitepaper comparing x86 and Itanium: >>K >> http://www.intel.com/business/bss/products/server/64-bit_tipping_point.p  >> df  >>M >> Extract: "Intel offers two complementary architectural choices that cover   >> theH >> full range of 64-bit requirements. One is Intel Itanium architecture,A >> which is designed for the most demanding and business-critical J >> enterprise and technical applications. The other is the family of IntelJ >> Xeon processor based systems with Intel EM64T. Though not equivalent toI >> Itanium architecture in terms of capacity, performance, and RAS, these G >> platforms enable a more gradual migration to 64-bit solutions, since K >> they provide native support for existing, legacy 32-bit applications. In J >> most enterprise computing environments, both platforms will be needed." > J > And what does Intel promise in this text? Nothing, nothing and nothing. I > The Intel site is full of white papers that make it seem like Intel is  M > 100% committed to Itanic, but the white papers are worded with great care.  K > Intel never writes that Itanic is an industry standard.  They write that  K > it is based on industry standards, and they let partners like HP and IDC  M > say that it is.  They even seem pleased with that.  Intel does not promise  J > that they will continue to develop Itanic anywhere in your quote.  They K > make it appear like they are backing Itanic 100%, but when you carefully  H > read their wording, you realize that there is nothing anybody can use 2 > against Intel should they decide to drop Itanic. > M > Intel's statements are like statements of Bill Clinton:  You had better be  E > sure to listen carefully, because they are designed to give you an  E > impression of something, while they are saying something different.   ! The noble art of deconstruction !   L I think I have also made the comment on another occasion that only HP calls  IA64 industry standard. 2 In fact I saw it on a VMS engineering slide today!  
 Dr. Dweeb    ------------------------------  % Date: Wed, 27 Apr 2005 01:30:43 +0200 3 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com>   Subject: Re: Could a PC do this?= Message-ID: <426ecf23$0$78287$157c6196@dreader1.cybercity.dk>   6 "Bill Todd" <billtodd@metrocast.net> wrote in message 7 news:5KOdnTb9kboFwvHfRVn-iw@metrocastcablevision.com...  > Main, Kerry wrote: >  > ...  >  >  They state "we expect to J >> release.." or "First Customer ship date is expected ..". No vendor ever >> says "we promise ..". > J > I see that you've conveniently forgotten the Heil/Lipcon 'commitment to J > Alpha' letter, so allow me to refresh your memory (note, in particular, J > the use of the phrase "we WILL" with respect to EV8, in addition to the J > multiple very specific 'commitments' and flat statements such as "Alpha H > WILL become the engine for future generations of our Compaq NonStopTM  > Himalaya systems").  >  > - bill >  >  > To Our Valued Customers: > L > Over the past few months, we have taken a close look at Compaqs platform J > strategy and the needs of our customers. We concluded that we needed to L > simplify our strategy, more clearly define our value proposition for you, M > and reinforce our message to you that Compaq is unequivocally committed to   > Alpha for the long term. > = > The Compaq NonStopTM server platform strategy is clear and  I > straightforward. We are focused on two key segments: Industry Standard  H > Servers (Compaq ProLiant) and Business Critical Servers for customers J > requiring the highest levels of availability, scalability, reliability,  > data integrity and security. > I > As our underlying processor technology, Alpha is absolutely key to our  J > profitable growth and market leadership in the Business Critical Server I > segment. As a result, we are investing aggressively in multiple future  J > generations of Alpha chip technology and a robust Alpha system roadmap. M > Our plan is to drive Alpha at the high end of the enterprise market, where  E > our strengths in 64-bit platforms, Compaq NonStopTM technology and  E > clustering help you build a competitive advantage. We have already  K > announced an aggressive plan to grow Tru64 UNIX on Alpha systems in such  C > key markets as high performance technical computing, e-commerce,  H > telecommunications and enterprise applications, among others. We will M > drive Alpha volumes by leveraging the growth of Linux. We will continue to  G > maintain the highest levels of customer satisfaction for our OpenVMS  I > customers. This includes a five-year rolling roadmap and investment in  K > OpenVMS in the areas of business critical capabilities and software that  J > enable Compaq NonStopTM solutions. And as we also announced, Alpha will L > become the engine for future generations of our Compaq NonStopTM Himalaya 
 > systems. > F > Our commitment to Alpha is a sound one that provides Compaq and our G > customers with unique competitive advantages. As you know, Alpha has  K > maintained its unquestioned performance leadership against all other CPU  M > architectures since January 1993. We plan to maintain and extend this lead  M > with a fully funded R+D program to ensure continued delivery of leadership   > products to the market.  > M > Specifically, we are now shipping our third-generation EV6 CPU chip in our  H > full line of Compaq AlphaServer systems, available today with 1 to 14 H > processors, and have begun shipping faster versions of these products G > based on the EV67 CPU chip. In addition, we have just introduced the  G > AlphaServer SC series of supercomputers to extend our #1 position in  K > mid-range high performance technical computing into the traditional >$1M  D > supercomputer space. By early 2000, we will begin rolling out our K > next-generation high-end AlphaServer with up to 32 processors. Our Alpha  M > manufacturing partner, Samsung, recently publicly demonstrated an advanced  H > development version of the EV68 CPU chip, the first to break the 1GHz M > barrier. And we have an exciting Alpha roadmap ahead of us, including EV7,  J > EV8, EV9 and EV10, with a plan to offer a full line of systems based on F > these generations. In EV8, we will implement a new CPU methodology, E > Simultaneous Multi-Threading, which was recently introduced at the  / > MicroProcessor Forum in San Jose, California.  > K > With these commitments, Compaq offers the most powerful set of platforms  J > and the widest range of choices to deliver the greatest value for you  L > from Windows NT on our ProLiant servers and Professional Workstations . . J > . to Tru64 UNIX, Linux and OpenVMS on Alpha . . . to NonStopTM Himalaya. > J > We appreciate your business, we value our relationship with you, and we A > look forward to building an even stronger partnership together.  >  > Sincerely, >  > Bill Heil  >  > Bill Heil $ > Vice President and General Manager# > Business Critical Server Division  >  > Jesse Lipcon >  > Jesse Lipcon > Vice President > Alpha Technology   Bill,   L Glad you've still got a copy.  I remember that letter well and it serves as G a cold reminder that words are not worth the paper upon which they are   printed.  
 Dr. Dweeb    ------------------------------  % Date: Wed, 27 Apr 2005 01:16:04 +0200 3 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com>   Subject: Re: Could a PC do this?= Message-ID: <426ecbb2$0$78284$157c6196@dreader1.cybercity.dk>   ; "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message  - news:DhmO96fjucNC@eisner.encompasserve.org... I > In article <opsppggslkzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com>  	 > writes:  > K >> The fact that there are still a lot of VAXen out there might lead you to > >> the conclusion that the Alpha really wasn't that successful > D > Why on earth should someone replace something that does their work > adequately ?  D Support costs, lack of spare parts availability, increasing risk of I catastrophic hardware failure over time etc. etc.  The charon-vax solves  A these issues. Logically you are correct, until the hardware dies.   
 Dr. Dweeb    ------------------------------  % Date: Tue, 26 Apr 2005 21:21:29 -0400 # From: "John Smith" <a@nonymous.com>   Subject: Re: Could a PC do this?, Message-ID: <Mv-dnTpoIYyFdPPfRVn-oA@igs.net>   Bill Todd wrote: > Main, Kerry wrote: >  > ...  >  >   They state "we expect toE >> release.." or "First Customer ship date is expected ..". No vendor  >> ever says "we promise ..".  > F > I see that you've conveniently forgotten the Heil/Lipcon 'commitment@ > to Alpha' letter, so allow me to refresh your memory (note, inE > particular, the use of the phrase "we WILL" with respect to EV8, in ? > addition to the multiple very specific 'commitments' and flat = > statements such as "Alpha WILL become the engine for future 9 > generations of our Compaq NonStopTM Himalaya systems").  >  > - bill    F I wonder if Mark Hurd ever read the Heil/Lipcon letter......perhaps he should.    ------------------------------  % Date: Tue, 26 Apr 2005 16:38:50 -0400  From: norm.raphael@metso.comF Subject: create new operator.log file from batch (I should know this.)Q Message-ID: <OF0F9D115F.D7B9F6BF-ON85256FEF.00713AFA-85256FEF.007142C4@metso.com>   @ How does one do this (create a new operator.log file) from batch where there is no terminal?    $ reply/enable $ reply/log  $ reply/disable    ------------------------------  % Date: Tue, 26 Apr 2005 16:59:50 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> J Subject: Re: create new operator.log file from batch (I should know this.)B Message-ID: <1114549186.3fecf55d587fd69378f49b81c0bce2ba@teranews>   norm.raphael@metso.com wrote:  > B > How does one do this (create a new operator.log file) from batch > where there is no terminal?  >  > $ reply/enable
 > $ reply/log  > $ reply/disable    Try:   $define sys$command OPA0:  $DEFINE sys$input OPA0:  $define TT OPA0:
 $reply/log   ------------------------------    Date: 26 Apr 2005 14:28:58 -0700" From: dave.baxter@bannerhealth.com! Subject: Dynamic Volume Expansion C Message-ID: <1114550938.903596.127720@g14g2000cwa.googlegroups.com>    Help,   E    Can any of you guys help me out here?    Its about DDS and DVE.  I G want to grow a 36GB Drive(DSA152 Single Unit $1$dga1521:), into a 72 GB D drive by adding $1$DGA551:.   I thought I had it until the very last minute.    These were the commands I used  . $ init/sys/size=71114623/limit $1$dga551: temp$ %INIT.....    CLUSTER defaulted to 8 $mount/over=id $1$dga551   This showed   ! Total Blocks            142229253 " Logical Volume Size       71114623" Expansion Size Limit    2147450880" Free Blocks               71044936   So all looked well.   ; $ mount/sys/noass DSA152:/shad=$1$DGA551: AZCERT02 AZCERT02 . %MOUNT-I-MOUNTED, AZCERT02 mounted on _DSA152:F %MOUNT-I-SHDMEMCOPY, _$1$DGA551: (MILLC1) added to the shadow set with a copy operationD %MOUNT-I-ISAMBR, _$1$DGA1521: (MILLC1) is a member of the shadow set  	 Still OK.   
 Copy finished    $  dismount  $1$dga1521:   $ Show Device DSA152:   C Device         Device       Error    Volume         Free  Trans Mnt C  Name          Status       Count     Label        Blocks Count Cnt C DSA152:       Mounted         0     AZCERT02      6094640     1   2 C $1$DGA551:    (MILLC1)  ShadowSetMember      0  (member of DSA152:)  $ Set Volume /Size DSA152   + The volume only expands to 78315520 blocks.   2 Show Dev/full shows Expansion Size Limit  78315520  	 When I do    $SYSMGR>> anal/disk dsa152: F Analyze/Disk_Structure for _DSA152: started on 26-APR-2005 10:48:22.41  C %ANALDISK-I-SHORTBITMAP, storage bitmap on RVN 1 does not cover the 
 entire device + %ANALDISK-I-OPENQUOTA, error opening QUOTA. % SYS-SYSTEM-W-NOSUCHFILE, no such file  $SYSMGR   G Do you know if this is because HBMM is enabled on the Volume, and can I G avoid this by disabling it.    Unfortunately I have already rolled back F to my start point, but could I have fixed this without rolling  back??  ! I would appreciate your comments.   C P.S.   I redid it with HBMM disabled on volume DSA152 but I got the  same result      Dave Baxter    (602) 495-4771   ------------------------------    Date: 26 Apr 2005 11:24:30 -0700' From: "dirf" <david.frid@tierserve.com> 4 Subject: Executable Code redirected to screen outputC Message-ID: <1114539870.636432.188320@f14g2000cwb.googlegroups.com>   D I installed TCPware on a older VMS Alpha server that I am working onG for a customer.  After installing the product I have run into a strange  issue.  E When executing .com files, the code is redirected to the screen along F with the normal output.  this does not seem to cause any problems withG execution, its just annoying and makes it difficult to catch everything D that I need to see in the text based menus. (unfortunately this is aE serial terminal on a stand-alone system - hoping to network it soon).   C Does anyone know if there is a setting that could have been flipped C (and how to fix it) so that the basic code is not redirected to the  screen?    Thanks,    ------------------------------    Date: 26 Apr 2005 11:26:59 -0700' From: "dirf" <david.frid@tierserve.com> 8 Subject: Re: Executable Code redirected to screen outputC Message-ID: <1114540019.952172.189000@o13g2000cwo.googlegroups.com>    Btw, this is an old system:    OpenVMS 6.2  TCPware 5.2    ------------------------------    Date: 26 Apr 2005 11:39:15 -0700) From: "Ken Robinson" <kenrbnsn@rbnsn.com> 8 Subject: Re: Executable Code redirected to screen outputB Message-ID: <1114540755.153630.90690@g14g2000cwa.googlegroups.com>   dirf wrote: E > Does anyone know if there is a setting that could have been flipped E > (and how to fix it) so that the basic code is not redirected to the 	 > screen?    Make sure you have the line:   $ set noverify  ( at the start of your command procedures.  C BTW, command procedures are NOT executables. Command procedures are  interpreted, not executed.   Ken    ------------------------------    Date: 26 Apr 2005 11:53:44 -0700' From: "dirf" <david.frid@tierserve.com> 8 Subject: Re: Executable Code redirected to screen outputB Message-ID: <1114541624.732554.73040@f14g2000cwb.googlegroups.com>   Thanks,   $ and thank you for the information!!!   -david   ------------------------------  % Date: Tue, 26 Apr 2005 12:58:24 -0700  From: Z <Z@no.spam> 8 Subject: Re: Executable Code redirected to screen output) Message-ID: <z3xbe.7468$f6.2953@fe04.lga>    dirf wrote: F > I installed TCPware on a older VMS Alpha server that I am working onI > for a customer.  After installing the product I have run into a strange  > issue. > G > When executing .com files, the code is redirected to the screen along H > with the normal output.  this does not seem to cause any problems withI > execution, its just annoying and makes it difficult to catch everything F > that I need to see in the text based menus. (unfortunately this is aG > serial terminal on a stand-alone system - hoping to network it soon).  > E > Does anyone know if there is a setting that could have been flipped E > (and how to fix it) so that the basic code is not redirected to the 	 > screen?    $ SET NOVERIFY   Better?    ------------------------------  % Date: Tue, 26 Apr 2005 15:56:40 -0400 * From: "Stewart, Bill" <wjs-corp@kaman.com>; Subject: How do I block an ip address in tcpip for OpenVMS? < Message-ID: <1E4B06029E11D211B47C0000F8207F4D031E9616@ESKC2>  D 	Is there a way to block specific ip addresses in tcpip for OpenVMS?   Thanks!    Bill Stewart   :-) Kaman Corporation  1332 Blue Hills Avenue Bloomfield, Connecticut, 06002 (860) 243-7058   ------------------------------   Date: 26 Apr 2005 20:08:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)? Subject: Re: How do I block an ip address in tcpip for OpenVMS? , Message-ID: <3d7ldaF6t2t4oU2@individual.net>  < In article <1E4B06029E11D211B47C0000F8207F4D031E9616@eskc2>,- 	"Stewart, Bill" <wjs-corp@kaman.com> writes:  > F > 	Is there a way to block specific ip addresses in tcpip for OpenVMS? >    Put it behind a firewall.    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 26 Apr 2005 16:55:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ? Subject: Re: How do I block an ip address in tcpip for OpenVMS? B Message-ID: <1114548919.89cef302d27f47d14b8f9c678fa92737@teranews>   "Stewart, Bill" wrote: > M >         Is there a way to block specific ip addresses in tcpip for OpenVMS?    With TCPIP Servcices:    TCPIP> HELP SET COMM /REJECT  F This will block all calls from an IP or network from being accepted by
 that node.  C You need to do both a SET COMM and SET CONF COMM to make the change  permanent and survive reboots.   ------------------------------    Date: 26 Apr 2005 15:25:11 -0700 From: bob@instantwhip.com ? Subject: Re: How do I block an ip address in tcpip for OpenVMS? C Message-ID: <1114554311.633461.324920@f14g2000cwb.googlegroups.com>   D with TCPware, you can create a packet filter and block ip addresses,D ports of ip addresses (services), subnets ... i don't think ucx can.   ------------------------------  % Date: Tue, 26 Apr 2005 16:38:06 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: How to install DCPS 2.4 without stopping queues? B Message-ID: <1114547884.1062d642692a92d6d5a53bc8a5fda5ff@teranews>   Larry Fahnoe wrote: = > If Paul is lurking here, I'll add my vote to have 2.5 allow 4 > installations to continue without stopping queues.    = Why would the stopping of queues have been made "necessary" ?   G Is it because the installation wants full access to the .TLBs and those H are constantly opened by the symbiont ? (sometimes, some libraries can'tH be updated if they are already opened by someone else, but in that case,? you can create a new version of it, and update the new version.   D Once the symbiont is started, isn't it correct to state that all theA images that it needs will have been opened/installed and that the G installation procedure would simply add new versions of the executables 8 that would be used only when the software is restarted ?   ------------------------------  # Date: Tue, 26 Apr 2005 21:03:31 GMT / From: "Jeff Goodwin" <jgoodwin@maine.rrr-r.com> = Subject: Re: How to install DCPS 2.4 without stopping queues? 6 Message-ID: <D0ybe.9065$mG3.4472@twister.nyroc.rr.com>  : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message< news:1114547884.1062d642692a92d6d5a53bc8a5fda5ff@teranews... > Larry Fahnoe wrote: ? > > If Paul is lurking here, I'll add my vote to have 2.5 allow 6 > > installations to continue without stopping queues. >  > ? > Why would the stopping of queues have been made "necessary" ?  > I > Is it because the installation wants full access to the .TLBs and those J > are constantly opened by the symbiont ? (sometimes, some libraries can'tJ > be updated if they are already opened by someone else, but in that case,A > you can create a new version of it, and update the new version.   H The DCPS installation procedure wants to replace the DCPS symbiont image= itself, so it wants the queues running that symbiont stopped.    > F > Once the symbiont is started, isn't it correct to state that all theC > images that it needs will have been opened/installed and that the I > installation procedure would simply add new versions of the executables : > that would be used only when the software is restarted ?   ------------------------------  % Date: Tue, 26 Apr 2005 17:15:15 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> = Subject: Re: How to install DCPS 2.4 without stopping queues? B Message-ID: <1114550128.b6159343a46ec0024d47641f653388d4@teranews>   Jeff Goodwin wrote: J > The DCPS installation procedure wants to replace the DCPS symbiont image? > itself, so it wants the queues running that symbiont stopped.   F Unless it does a COPY/OVERLAY, the installation procedure would simplyF create a new version of the .EXE file. It might try to install it, andE even if it did, the running symbiont already has all the links to its # images and wouldn't cause problems.   H I could see some issues if the IVP tries to test the new version of DCPS
 on that node.    ------------------------------  # Date: Tue, 26 Apr 2005 21:30:34 GMT * From: Paul Anderson <paul.anderson@hp.com>= Subject: Re: How to install DCPS 2.4 without stopping queues? 5 Message-ID: <260420051730388990%paul.anderson@hp.com>   E In article <1114547884.1062d642692a92d6d5a53bc8a5fda5ff@teranews>, JF + Mezei <jfmezei.spamnot@teksavvy.com> wrote:   ? > Why would the stopping of queues have been made "necessary" ?   E The old VMSINSTAL kit let you stop all queues, or stop no queues.  We E dropped the second option in the PCSI kit, thinking you should always 3 stop all queues, but have realized we went too far.   E We also realized that stopping all queues in the cluster is too big a C hammer, since there could be queues running from other system disks B that would not be affected at all by the DCPS installation on this particular node.  C > Is it because the installation wants full access to the .TLBs and / > those are constantly opened by the symbiont ?   @ The installation procedure replaces, not updates, the libraries.  F > Once the symbiont is started, isn't it correct to state that all theC > images that it needs will have been opened/installed and that the = > installation procedure would simply add new versions of the F > executables that would be used only when the software is restarted ?  E That's true.  All _images_ are still open by the symbiont.  But other 7 components, like the libraries, have now been replaced.   E Those queues running the old version might be happy for a long time.  E They might not.  The best thing to do is stop them first, install the ? software and then restart them.  But individual system managers B probably have some good ideas why they _don't_ want to stop queues? right now.  DCPS V2.5 will give them that option, plus the more = sensible option of stopping only those queues affected by the 
 installation.    Paul   --    Paul Anderson   OpenVMS Engineering    Hewlett-Packard Company    ------------------------------  % Date: Tue, 26 Apr 2005 13:40:57 -0400 ) From: "Scott Greig" <jsgreig@geminaq.com> + Subject: Re: IP Failover: strange behaviour 9 Message-ID: <Y%ube.3259$gA5.366565@news20.bellglobal.com>   C "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in message & news:426e5997$1@news.langstoeger.at...? > In article <3dd11af5.0504252332.72d19069@posting.google.com>, ' ksidibaba@gmail.com (ksidibaba) writes: H > >just trying to get to grisp with VMS, we are encountering quite a few7 > >unexpected problems, one of which being IP-Failover.  > 7 > Please consider LAN failover (instead of IP Failover) ) > $ MCR LANCP SET DEVICE/FAILOVER_SET=...   8 I concur however, when I approached HP support with this; on my DS10, I found out that LAN failover was not supported < for the on-board DE500 style interfaces (N.B. not supported, but probably works).  9 On ES47's with DE600 series (3X-DE602-BB to be exact) LAN 8 failover works like a charm, with the added bonus of ALL: LAN protocols (MOP, LAT, TCP/IP, DECnet, SCS &etc) failing' over transparently to all applications.    SCott  >  > --   > Peter "EPLAN" LANGSTOEGER ' > Network and OpenVMS system specialist  > E-mail  peter@langstoeger.atH > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 26 Apr 2005 12:54:51 -0700 From: bob@instantwhip.com + Subject: Re: IP Failover: strange behaviour B Message-ID: <1114545291.628362.82670@f14g2000cwb.googlegroups.com>  5 nic failover works fine on de500ba's with TCPware ...    ------------------------------  % Date: Tue, 26 Apr 2005 19:55:50 -0400 ' From: "Main, Kerry" <kerry.main@hp.com> + Subject: RE: IP Failover: strange behaviour R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB5ECD94@tayexc19.americas.cpqcorp.net>   > -----Original Message-----3 > From: Scott Greig [mailto:jsgreig@geminaq.com]=20  > Sent: April 26, 2005 1:41 PM > To: Info-VAX@Mvb.Saic.Com - > Subject: Re: IP Failover: strange behaviour  >=20 >=20E > "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in message ( > news:426e5997$1@news.langstoeger.at...A > > In article <3dd11af5.0504252332.72d19069@posting.google.com>, ) > ksidibaba@gmail.com (ksidibaba) writes: A > > >just trying to get to grisp with VMS, we are encountering=20 
 > quite a few 9 > > >unexpected problems, one of which being IP-Failover.  > > 9 > > Please consider LAN failover (instead of IP Failover) - > > $ MCR LANCP SET DEVICE/FAILOVER_SET=3D...  >=20: > I concur however, when I approached HP support with this= > on my DS10, I found out that LAN failover was not supported > > for the on-board DE500 style interfaces (N.B. not supported, > but probably works). >=20; > On ES47's with DE600 series (3X-DE602-BB to be exact) LAN : > failover works like a charm, with the added bonus of ALL< > LAN protocols (MOP, LAT, TCP/IP, DECnet, SCS &etc) failing) > over transparently to all applications.  >=20 > SCott  > >     B For future reference - a wp on the TCPIP failsafe and LAN failover	 features: ? http://h71000.www7.hp.com/openvms/journal/v2/articles/tcpip.pdf      Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  % Date: Tue, 26 Apr 2005 19:38:00 -0500 ' From: "Tom M" <kryios@spam.comcast.net> + Subject: Re: IP Failover: strange behaviour 0 Message-ID: <xtGdnWUeWONxQvPfRVn-vw@comcast.com>  4 "Scott Greig" <jsgreig@geminaq.com> wrote in message3 news:Y%ube.3259$gA5.366565@news20.bellglobal.com...  > E > "Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in message ( > news:426e5997$1@news.langstoeger.at...A > > In article <3dd11af5.0504252332.72d19069@posting.google.com>, ) > ksidibaba@gmail.com (ksidibaba) writes: J > > >just trying to get to grisp with VMS, we are encountering quite a few9 > > >unexpected problems, one of which being IP-Failover.  > > 9 > > Please consider LAN failover (instead of IP Failover) + > > $ MCR LANCP SET DEVICE/FAILOVER_SET=...  > : > I concur however, when I approached HP support with this= > on my DS10, I found out that LAN failover was not supported > > for the on-board DE500 style interfaces (N.B. not supported, > but probably works).  G The latest LAN ECO for VMS 7.3-2 is supposed to take care of this.  I'm ? looking forward to installing it on one of our systems that has  SCSI/Ethernet combo boards.    > ; > On ES47's with DE600 series (3X-DE602-BB to be exact) LAN : > failover works like a charm, with the added bonus of ALL< > LAN protocols (MOP, LAT, TCP/IP, DECnet, SCS &etc) failing) > over transparently to all applications.  >  > SCott  > >  > > --   > > Peter "EPLAN" LANGSTOEGER ) > > Network and OpenVMS system specialist   > > E-mail  peter@langstoeger.atJ > > A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist >  >    ------------------------------  # Date: Wed, 27 Apr 2005 04:41:00 GMT 0 From: "Matt Muggeridge" <Matt.Muggeridge@hp.com>+ Subject: Re: IP Failover: strange behaviour > Message-ID: <wJEbe.30190$5F3.24434@news-server.bigpond.net.au>   Karim,  K That is the documented behaviour.  The bottom line is this is a problem on eC quiet networks only.  Be sure to read the docs on requirements for h% configuring failSAFE IP in a network.l  L To be brief, the algorithm used is to monitor the receive bytes of the NIC. J On quiet networks, this means the failSAFE service could interpret a good K controller as failed (since the NIC receive bytes counter doesn't change). cJ To counter this, failSAFE uses a broadcast MAC-level traffic generator to M keep all interfaces receive-byte counter ticking over.  This works, provided oI there are at least two interfaces available, since an interface does not  + receive the broadcast traffic it generates.I  J The docs suggest having failSAFE monitor a minimum of 3 interfaces, so if L one interface fails, the other two will see each other's broadcast traffic. M Alternately, customers with reliable routers use periodic OSPF HELLO packets .? to broadcast on their LAN.  There are many other possibilities.t  L FWIW, there is work in the pipeline which will keep the address on the last G surviving interface active, regardless of the state of the interface's o receive bytes counter.   Matt.i  3 "ksidibaba" <ksidibaba@gmail.com> wrote in message v7 news:3dd11af5.0504252332.72d19069@posting.google.com...V	 > Hi all,i >lG > just trying to get to grisp with VMS, we are encountering quite a fewtC > unexpected problems, one of which being IP-Failover. We are usingvE > OpenVMS 7.3-2, with all recommended actual patches on 2 DS15, *not* A > participating in an OpenVMS cluster, both connected to the sametF > switch. On both machines, 2 NICs are configured to take part into IPD > Failover. As long as both machines are up and running, IP failoverF > behaves the way one would expect it to work (i.e. pulling one of theD > network cables from one active NIC results in the other one takingG > over). But when one of the machine is powered down, the other machinefD > starts losing connectivity. It looks as if the system is trying toF > reconfigure the IP address of the failover-enabled NICs. Is this theE > expected behaviour? that would imply that if a machine breaks down,mD > the other one would lose connectivity (!). Any help on that matter! > would be very much appreciated!5 > Thanks in advance, >D > Karim    ------------------------------    Date: 27 Apr 2005 07:10:44 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)+ Subject: Re: IP Failover: strange behavioure, Message-ID: <426f3af4$1@news.langstoeger.at>  e In article <Y%ube.3259$gA5.366565@news20.bellglobal.com>, "Scott Greig" <jsgreig@geminaq.com> writes: k >"Peter 'EPLAN' LANGSTOEGER" <peter@langstoeger.at> wrote in message news:426e5997$1@news.langstoeger.at...th >> In article <3dd11af5.0504252332.72d19069@posting.google.com>, ksidibaba@gmail.com (ksidibaba) writes:I >> >just trying to get to grisp with VMS, we are encountering quite a feww8 >> >unexpected problems, one of which being IP-Failover. >>8 >> Please consider LAN failover (instead of IP Failover)* >> $ MCR LANCP SET DEVICE/FAILOVER_SET=... >d9 >I concur however, when I approached HP support with thise< >on my DS10, I found out that LAN failover was not supported= >for the on-board DE500 style interfaces (N.B. not supported,* >but probably works).A >e: >On ES47's with DE600 series (3X-DE602-BB to be exact) LAN9 >failover works like a charm, with the added bonus of ALLp; >LAN protocols (MOP, LAT, TCP/IP, DECnet, SCS &etc) failingr( >over transparently to all applications.  ' Have you seen the VMS732_LAN V3.0 eco ?o  2                6.1.4.1  Functionality Description:  D                OpenVMS V7.3-2, included LAN Failover support for theH                DE600, DEGPA, DEGXA, and variant devices.  This patch kit-                adds support for the DE500-BA.o                  Images Affected:-  ,                 -  [SYS$LDR]SYS$EWDRIVER.EXE  4                 -  [SYS$LDR]SYS$EWDRIVER_DE500BA.EXE  ,                 -  [SYS$LDR]SYS$LLDRIVER.EXE     -- P Peter "EPLAN" LANGSTOEGERs% Network and OpenVMS system specialistA E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 26 Apr 2005 11:20:34 -0700 From: bob@instantwhip.coma- Subject: ISE proves OpenVMS future viability!aB Message-ID: <1114539633.988809.79040@z14g2000cwz.googlegroups.com>  6 thank goodness not everyone in the world is stupid ...  : http://h71000.www7.hp.com/openvms/brochures/ise/index.html   ------------------------------  % Date: Tue, 26 Apr 2005 14:57:55 -0400e# From: "John Smith" <a@nonymous.com>d1 Subject: Re: ISE proves OpenVMS future viability!n, Message-ID: <pPWdnTTXn5OpEvPfRVn-uA@igs.net>   bob@instantwhip.com wrote:8 > thank goodness not everyone in the world is stupid ...    K Thankfully not everyone in the world is as uninformed as you are - they arenI running on Alpha and praying that Itanic isn't killed before they have tot migrate from Alpha in 2011.e   --F OpenVMS - The never advertised operating system with the dwindling ISV base.I   ------------------------------    Date: 26 Apr 2005 12:51:54 -0700 From: bob@instantwhip.com 1 Subject: Re: ISE proves OpenVMS future viability!>C Message-ID: <1114545114.693707.257130@z14g2000cwz.googlegroups.com>e  @ if HP did that, they would be killing off any and all chances ofF retaining a lot of high dollar, high profile accounts and create a lotF of angry, nasty cusotmers who would despise the HP firm forever ... do& you really think they are that stupid?   ------------------------------   Date: 26 Apr 2005 20:07:08 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)1 Subject: Re: ISE proves OpenVMS future viability!e, Message-ID: <3d7lbcF6t2t4oU1@individual.net>  C In article <1114545114.693707.257130@z14g2000cwz.googlegroups.com>,  	bob@instantwhip.com writes:B > if HP did that, they would be killing off any and all chances ofH > retaining a lot of high dollar, high profile accounts and create a lotH > of angry, nasty cusotmers who would despise the HP firm forever ... do( > you really think they are that stupid? >   ' Is that supposed to be rhetorical?  :-)    bill   -- eJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 26 Apr 2005 15:57:36 -0400.# From: "rob kas" <bob@paychoice.com>t1 Subject: Re: ISE proves OpenVMS future viability!u0 Message-ID: <116t79j8435bs28@corp.supernews.com>  
     yes......       ' <bob@instantwhip.com> wrote in message g= news:1114545114.693707.257130@z14g2000cwz.googlegroups.com... B > if HP did that, they would be killing off any and all chances ofH > retaining a lot of high dollar, high profile accounts and create a lotH > of angry, nasty cusotmers who would despise the HP firm forever ... do( > you really think they are that stupid? >    ------------------------------  % Date: Tue, 26 Apr 2005 16:49:25 -0400s- From: JF Mezei <jfmezei.spamnot@teksavvy.com>e1 Subject: Re: ISE proves OpenVMS future viability!wB Message-ID: <1114548569.8688ab5c329e0526406f105d3d2549d6@teranews>   bob@instantwhip.com wrote: > B > if HP did that, they would be killing off any and all chances ofH > retaining a lot of high dollar, high profile accounts and create a lotH > of angry, nasty cusotmers who would despise the HP firm forever ... do( > you really think they are that stupid?  A Since there is no love nor great adoption of IA64 from commercial 1 customers, killing IA64 today would be applauded.u  F The argument to kill Alpha to go towards commodity platform had *some*@ value. Problem is that they chose an inferior platform that mostH certaintly isn't commodity and whose future is more incertain today than Alpha's was on June 24th 2001.  C IA64 is a mistake. Killing it today would be a relief and customerstB could now look forwrad to VMS running on the 8086 and come back toG workstation and small server market and compete head to head with othernE OSs sicne they's be running on the same hardware. And customers wouldoE look forward to just one migration from Alpha to the 8086. Right now,oF migrating to IA64 is pointless if you know that you'll need to migrateC to the 8086 a few years later. This is why IA64 sales that are madeeA really public aren't really sales, they are contribution to largeo0 research labs who don't need platform longevity.  F The 16 bit toy controller has evolved into a respectable almost 64 bitE chip. Like it or not, it has the performance and gaining the featuresiH needed to run enteroprise, and competition is driving its performance up* faster than IA64, and keeping prices down.  ; IA64 is proprietary, single supplier low volume niche chip.m   ------------------------------  % Date: Tue, 26 Apr 2005 18:08:35 -0400,# From: "John Smith" <a@nonymous.com>l1 Subject: Re: ISE proves OpenVMS future viability!e, Message-ID: <l4qdnQRlgKx_JvPfRVn-pw@igs.net>   bob@instantwhip.com wrote:B > if HP did that, they would be killing off any and all chances ofH > retaining a lot of high dollar, high profile accounts and create a lotH > of angry, nasty cusotmers who would despise the HP firm forever ... do( > you really think they are that stupid?    K ChumHPaq has already kissed-off billions of dollars of revenues and profitsc# by killing Alpha they way they did.T  & History has a way of repeating itself.     --F OpenVMS - The never advertised operating system with the dwindling ISV base.r   ------------------------------  % Date: Tue, 26 Apr 2005 18:16:06 -0400p# From: "John Smith" <a@nonymous.com>u1 Subject: Re: ISE proves OpenVMS future viability! , Message-ID: <_6mdnQbbN_M4IPPfRVn-qQ@igs.net>   JF Mezei wrote:d > bob@instantwhip.com wrote: >>C >> if HP did that, they would be killing off any and all chances ofnE >> retaining a lot of high dollar, high profile accounts and create arF >> lot of angry, nasty cusotmers who would despise the HP firm forever0 >> ... do you really think they are that stupid? >nC > Since there is no love nor great adoption of IA64 from commercialf3 > customers, killing IA64 today would be applauded.C >cH > The argument to kill Alpha to go towards commodity platform had *some*B > value. Problem is that they chose an inferior platform that mostE > certaintly isn't commodity and whose future is more incertain todayj% > than Alpha's was on June 24th 2001.s >eE > IA64 is a mistake. Killing it today would be a relief and customersrD > could now look forwrad to VMS running on the 8086 and come back toC > workstation and small server market and compete head to head withrG > other OSs sicne they's be running on the same hardware. And customersaB > would look forward to just one migration from Alpha to the 8086.C > Right now, migrating to IA64 is pointless if you know that you'lleG > need to migrate to the 8086 a few years later. This is why IA64 salesl; > that are made really public aren't really sales, they arelH > contribution to large research labs who don't need platform longevity. >nH > The 16 bit toy controller has evolved into a respectable almost 64 bitG > chip. Like it or not, it has the performance and gaining the features G > needed to run enteroprise, and competition is driving its performances/ > up faster than IA64, and keeping prices down.t >g= > IA64 is proprietary, single supplier low volume niche chip.v    L At the time of the Alphacide, Alpha was more of a commodity chip than Itanic	 is today.o  @ It had a second source supplier (Samsung), 3rd-party motherboardL manufacturers, and a higher chip count coming off the assembly line. Oh yes,4 a larger number of ISV's and better performance too.  L With the way AMD's chip performance is stacking up these days, Hector Ruiz'sK goal of a 15% market share will almost certainly be exceeded. And that 15%+ K will be coming straight out of Intel's pocket. How long will Intel continuet= to fund a money-loser when their lunch is being eaten by AMD?n     --F OpenVMS - The never advertised operating system with the dwindling ISV base.-   ------------------------------  % Date: Tue, 26 Apr 2005 21:16:38 -0700S( From: Jeff Cameron <roktsci@comcast.net> Subject: Re: Legato NetWorker-/ Message-ID: <BE946036.CC74%roktsci@comcast.net>.  H On 4/26/05 5:57 AM, in article 00A42DBE.03D65B0D.3@tachysoft.com, "Wayne$ Sewell" <wayne@tachysoft.com> wrote:  ( >> Date: Mon, 25 Apr 2005 19:56:16 -0700  >> Subject: Re: Legato NetWorker+ >> From: Jeff Cameron <roktsci@comcast.net>s >> X-Newsgroups: comp.os.vms2 >> Message-ID: <BE92FBE0.CB2C%roktsci@comcast.net> >> MIME-Version: 1.0 >  > N >> The biggest flaw with tapesys is that they provide their own hacked versionK >> of Backup, so if a VMS patch comes out with a new backup.exe you have tok, >> wait until tapesys hacks the new version. > M > Huh??  What millenium are you in?  Yes, the original version of tapesys didtI > this in the 1980s, but not for at least a decade, probably much longer.  > F I stand corrected, it has been about that long ago that I used TapeSys >  >> CN >> TapeControl achieves the same functionality by intercepting backup (as wellN >> as initialize, mount and dismounts [dcl and system services]) doing what itO >> has to do to manage the tape volumes, then passes the operation onto the VMSe >> native facility.  >>   > M > Non-ancient versions of tapesys use pure native vms backup as well.  I have O > never seen the patching thing in operation, and my first contact with tapesys M > was in 1992.  The only reason I even knew about the patching was because ofoK > historical residue in the source tree, which I cleaned up many years ago.f >  > L >> Legato networker does the same too, but using open tape format instead of >> VMS backup savesets.r >>   > L > You make that sound like a benefit.  Many people here feel that it is not,N > given that you cannot *restore* your disks without legato being in the loop.I > If vms savesets are the medium, only standalone backup is required.  NoD > network, no foreign system.E? I agree, I do not think it is a benefit, but rather a drawback.( > G > Actually the "intercepting backup...doing what it has to...passes the @ > operation onto the VMS native facility" thing is outmoded too. > H > tapesys uses the system service and rtl intercepts when running on vms
 > versionsJ > prior to 7.1.  For vms 7.1 and later, it does not use backup.exe at all,P > instead using the callable backup api (backupshr).  This way *no* hacks of anyP > kind are needed, including system service intercepts.  Everything is done withN > calls to straight hp-supplied code.  All of the tapesys-specific stuff is in > callbacks. > O > Does tapecontrol use the backup API?  Does networker?  SLS does not appear tod2 > (no reference to backupshr in the backup image). TapeControl : Yes, NetWorker : No > K > The system service intercept thing will not work on itanium, at least not F > without a massive recoding effort.  The mechanism for system serviceO > dispatching and for calling procedures is radically different.  AFAIK, no one O > has yet worked out the technique for the system service intercepts, includingyN > vms engineering.  There is a project in progress for this, at the request ofO > myself (I have another product that still uses intercepts) and others, but it.B > is still in a preliminary stage and has produced no actual code. > I The TapeControl intercept works using logical names and installed images, H with the addition of additional command qualifiers using CDU (not systemG service intercepts), so the intercept should still work in 8.2. But I'm25 speaking from supposition as I have not tried it yet.5N > I suspect that this is one of the major reasons that SLS is not being ported > to > itanium.   > P > In contrast, tapesys is already running on itanium and performing backups.  ItO > is still in test, but it appears to be fully operational.  I haven't receivedD > a ) > bug report from the test guys in weeks.n >  Cool!  > N > It would be a pretty big rewrite of a backup module to switch to the API andN > off the system service intercepts.  We went through this exercise years ago,) > when the API first came out in vms 7.1.  >  > WayneD > O ==============================================================================>o =iP > Wayne Sewell, Tachyon Software Consulting  (281)812-0738   wayne@tachysoft.com: > http://www.tachysoft.com/www/tachyon.html and wayne.html > O ==============================================================================>A =DK > Jake Blues:"You traded the Caddy for a microphone? ...... Okay, I can buy  > that."   ------------------------------   Date: 26 Apr 2005 18:01:27 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)A Subject: Re: Maybe HP should get out of the hardware business....u, Message-ID: <3d7dvnF6euqtnU1@individual.net>  , In article <E-ydnUtUa-Cc__PfRVn-oQ@igs.net>,& 	"John Smith" <a@nonymous.com> writes: > Alan Greig wrote:  >> John Smith wrote:B >>> ....and just sell operating systems. If HP can't/won't build aB >>> workstation for VMS at a competitive price-point, please don't@ >>> hobble us with the inability to run VMS on hardware that areC >>> price/performance leaders (please don't bring up the $2000 DSPPt" >>> 'deal' as a counter argument). >>> > >>> The rationalization of going Itanic in the first place wasC >>> 'commoditization', but at this juncture Opteron is arguably thetA >>> commodity processor of choice for most OEM's, and it will get 0 >>> cheaper and faster more quickly than Itanic. >>D >> Seems that AMD have managed to make a very scalable system - muchD >> better than the 64 bit Xeon. Intel can't allow AMD to get too farB >> ahead so there's every reason to expect future Intel X86-64 bitA >> processors that scale well and outperform Itanium in large SMPp >> configurations. >>I >> The release of the HP benchmarks makes sense of something I read in an F >> HP employee blog which seemed to hint at such an astonishingly wellG >> performing SMP Opteron system. Makes me wonder when/if we see X86-64c >> variants of Integrity.g >  >  > <cynical>1N > With zero advertising for VMS, only slightly more for NSK and HP-UX, HP doesL > not seem to be concerned with growing the market for Itanic-based systems.7 > Pretty soon there'll be no need for Integrity at all.  >  > </cynical> >   G I thought it was the general opinion of this group that all "Integrity"g# was abandoned on 25 June 2001.  :-)w   bill   -- aJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 26 Apr 2005 11:23:19 -0700 From: bob@instantwhip.com.A Subject: Re: Maybe HP should get out of the hardware business....5B Message-ID: <1114539799.428082.26290@g14g2000cwa.googlegroups.com>   care to rethink that statement?   : http://h71000.www7.hp.com/openvms/brochures/ise/index.html   ------------------------------  % Date: Tue, 26 Apr 2005 14:56:13 -0400 # From: "John Smith" <a@nonymous.com>aA Subject: Re: Maybe HP should get out of the hardware business....:, Message-ID: <PbWdnVEOOqZTE_PfRVn-gg@igs.net>   bob@instantwhip.com wrote:! > care to rethink that statement?  >n< > http://h71000.www7.hp.com/openvms/brochures/ise/index.html    & They are running on Alpha, not Itanic.   --F OpenVMS - The never advertised operating system with the dwindling ISV base.d   ------------------------------  % Date: Tue, 26 Apr 2005 15:54:37 -0400n' From: Dave Froble <davef@tsoft-inc.com>cA Subject: Re: Maybe HP should get out of the hardware business.... 0 Message-ID: <116t73p9jocmr85@corp.supernews.com>   Alan Greig wrote:a > John Smith wrote:n > @ >>....and just sell operating systems. If HP can't/won't build a > 
 > workstationa > G >>for VMS at a competitive price-point, please don't hobble us with theiE >>inability to run VMS on hardware that are price/performance leadersr > 	 > (please- > > >>don't bring up the $2000 DSPP 'deal' as a counter argument). >>< >>The rationalization of going Itanic in the first place wasA >>'commoditization', but at this juncture Opteron is arguably the7 >  > commodity9 > A >>processor of choice for most OEM's, and it will get cheaper ando > 
 > faster mores >  >>quickly than Itanic. >  > C > Seems that AMD have managed to make a very scalable system - much0I > better than the 64 bit Xeon. Intel can't allow AMD to get too far aheadGF > so there's every reason to expect future Intel X86-64 bit processorsE > that scale well and outperform Itanium in large SMP configurations.d  G I seem to recall it being reported that an Alpha developer, when asked ,I about Hammer, smiled and said "mini EV7", or something like that.  A big b1 difference, development on Opteron hasn't ceased.   H > The release of the HP benchmarks makes sense of something I read in anE > HP employee blog which seemed to hint at such an astonishingly well F > performing SMP Opteron system. Makes me wonder when/if we see X86-64 > variants of Integrity.  D Now that WILL be a significant sign, indicating the eventual end of  IA-64.  Not good for VMS.0   -- 54 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road> Vanderbilt, PA  15486t   ------------------------------    Date: 26 Apr 2005 13:40:12 -0700* From: "Alan Greig" <greigaln@netscape.net>A Subject: Re: Maybe HP should get out of the hardware business.... C Message-ID: <1114548012.934381.164710@z14g2000cwz.googlegroups.com>t   Dave Froble wrote:   >OB > I seem to recall it being reported that an Alpha developer, when asked-F > about Hammer, smiled and said "mini EV7", or something like that.  A big 3 > difference, development on Opteron hasn't ceased.r  @ Just for laughs I've checked the High Performance Computing SpecG benchmark figures OMPM2001. Sun's posted figures for the 8 core Opteron B server is 17,230. Presumably the new HP variants will be about theF same. According to published HP figures the Alphaserver EV7/1300 postsE 13,125 at 8 processors. You need to go up to 16 processor EV7 systemscG to significantly beat the 8 core Opteron. As the Opteron seems to scale1< well I guess you need a 32 processor EV7 to give about a 20%G performance improvement over the maximum shipping Opteron SMP (16 core)o configuration today.  D Or put it bluntly even HP's little Opteron Proliant server currentlyB shipping outperforms almost every single VMS box in the field. TheF longer it takes for HP to announce a port the more the chance that VMSE still does die with Alpha. The current Itanium efforts are a waste ofy! time. The wrong horse was picked.t  G >From HP's point of view pushing these systems like hell makes a lot of D sense. Dell have been wrong-footed and cannot compete in SMP systemsF unless they switch to AMD or wait for Intel to catch up. HP and othersF are going to push this advantage home and, in the process, hammer (pun+ intended) another nail in Itanium's coffin.s  G > > The release of the HP benchmarks makes sense of something I read in3 anG > > HP employee blog which seemed to hint at such an astonishingly well A > > performing SMP Opteron system. Makes me wonder when/if we see$ X86-64 > > variants of Integrity. >eE > Now that WILL be a significant sign, indicating the eventual end of0 > IA-64.  Not good for VMS.f >r > --6 > David Froble                       Tel: 724-529-04506 > Dave Froble Enterprises, Inc.      Fax: 724-529-0596@ > DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com > 170 Grimplin Roade > Vanderbilt, PA  15486    Fr   ------------------------------  % Date: Tue, 26 Apr 2005 16:33:01 -0400r- From: JF Mezei <jfmezei.spamnot@teksavvy.com>sA Subject: Re: Maybe HP should get out of the hardware business....sB Message-ID: <1114547583.592c35cb97b223f32d721a3212f44f1f@teranews>   Alan Greig wrote:vC > Seems that AMD have managed to make a very scalable system - much I > better than the 64 bit Xeon. Intel can't allow AMD to get too far aheaddF > so there's every reason to expect future Intel X86-64 bit processorsE > that scale well and outperform Itanium in large SMP configurations.a  G On June 25 2001, all the charts were changed to show IA64's performancetE curve eventually surpassing that of Alpha. (prior to that, IA64 would-G never catch Alpha). And Compaq management said that it was time to killrC Alpha since it was now evident that IA64 would surpass Alpha. WhiletF these were bullshit/lies, one should perhaps apply their opwn logic to IA64 itself...  H With the 8086 curve now appearing to eventually surpass IA64,  HP should! just give up on IA64 and go 8086.t    F When Compaq gave up on making Alpha popular, it used the argument thatE Alpha being a niche market chip wouyldn't have the volumes to compete R and going with an industr standard commodity chip would make VMS more competitive.  B Now that it is obvious that IA64 has been relegated to a niche lowH volume chip and will never achieve "commodity" status, it is time for HPD to use its own logic and move to the 8086. The 8086 is where all the@ action is, there is healthy competition, available from multipleF sources, is truly commodity and "industry standard" and would allow HP8 to have all its products based on a single architecture.   ------------------------------  % Date: Tue, 26 Apr 2005 21:10:50 -0500@3 From: "Christopher Smith" <csmith@stu.parkland.edu>w Subject: Multia needs new OS7 Message-ID: <1114567850.df8fd9ccsmith@stu.parkland.edu>M  
 Hey everyone,o  L It's been forever since I've even read the group, but current events prompt=,  me to finally get around to re-subscribing.   So, right to the point:   L Anyone willing to help me find a copy of VMS 7.1-2 or V7.2 for my multia? :=J )  I can't seem to order it from the hobbyist page any more.  Finally got=J  it all together, and I'd hate to run NT on it.  It would be my first alp=1 ha system.  (two or three more soon to follow ;))n   Chrisc   ------------------------------  % Date: Tue, 26 Apr 2005 22:02:18 -0700 " From: Crabs <spamsucks@nospam.com>  Subject: Re: Multia needs new OS/ Message-ID: <g7idnWT9puNih_LfRVn-1w@sunset.net>    Christopher Smith wrote: > Hey everyone,l > y > It's been forever since I've even read the group, but current events prompt me to finally get around to re-subscribing.w >  > So, right to the point:w > > Anyone willing to help me find a copy of VMS 7.1-2 or V7.2 for my multia? :)  I can't seem to order it from the hobbyist page any more.  Finally got it all together, and I'd hate to run NT on it.  It would be my first alpha system.  (two or three more soon to follow ;)) >  > Chris  >  >  >  Chris:  2 You won't find it on the net, at least not easily.7 Where are you located? I'm on the left coast of the US. ? Have you joined the Hobbyist program to get your free licenses?e   TomC   ------------------------------    Date: 26 Apr 2005 16:29:54 -0700! From: susan_skonetski@hotmail.come0 Subject: OpenVMS Pearl from today from IT WeeklyC Message-ID: <1114558194.102572.268540@g14g2000cwa.googlegroups.com>:   ----Original Message-----e From: Skonetski, Susan% Sent: Tuesday, April 26, 2005 1:00 PMe To: Skonetski, SusanC Subject: HP OpenVMS Pearl - from IT Weekly - Vendors enhance serverS strategies - OK for public use       Dear Distribution Lists,  9 http://www.itp.net/features/details.php?id=2585&category=2  B This article compares AMD, Intel, IBM, Sun, FSC, Microsoft, HP andD Dell.  The portion on HP is amazing in that it mentions both OpenVMSF and NSK.  Obviously by the title the focus is on Servers.  In case youB are wondering the numbers are off, the 400K is licenses not users.  
 Warm Regards,E Sue=   ------------------------------    Date: 26 Apr 2005 20:05:40 -0700 From: tomarsin2015@comcast.net Subject: This is strangeC Message-ID: <1114571140.243540.314050@o13g2000cwo.googlegroups.com>b   HellosE Just out of interest I added a SDC qbus scsi controller to a 3600 andvE put two Segate SX118202LS (18gb) drives as a Raid 0+1. This is what I  getT QUASAR> show dev d  E Device                  Device           Error    Volume         Free-	 Trans Mnt F  Name                   Status           Count     Label        Blocks	 Count CntgF DSA10:                  Mounted              0  PUBLIC000000         0    2   1F DSA11:                  Mounted              0  PUBLIC000001         0    2   1. DPA0:         (QUASAR)  Online               0F DPA10:        (QUASAR)  Mounted              0  PUBLIC        71060409    1   1F $233$DUA0:    (QUASAR)  Mounted              0  OVMSVAXSYS     3230091  401   1F $233$DUA1:    (QUASAR)  Mounted              0  PATHWORKS      5543112   67   1B $233$DUA2:    (QUASAR)  ShadowSetMember      0  (member of DSA10:)B $233$DUA3:    (QUASAR)  ShadowSetMember      0  (member of DSA11:). DAD0:         (QUASAR)  Online               0. DNFS0:        (QUASAR)  Online               0 QUASAR>p QUASAR> show dev dpa10/fullnG Disk DPA10: (QUASAR), device type RAID0 Disk Array, is online, mounted,0 file- F     oriented device, shareable, available to cluster, error logging is enabled.  <     Error count                    0    Operations completed     36401     Owner process                 ""    Owner UICi [SYSTEM]0     Owner process ID        00000000    Dev Prot S:RWPL,O:RWPL,G:R,W2;     Reference count                1    Default buffer sizei     512l9     Total blocks            71061352    Sectors per trackI     255r;     Total cylinders             1093    Tracks per cylinder      255w$     Allocation class             256  >     Volume label            "PUBLIC"    Relative volume number       0o9     Cluster size                  69    Transaction count        1b=     Free blocks             71060409    Maximum files allowedt  507581t3     Extend quantity                5    Mount count        1A2     Mount status              System    Cache name "_$233$DUA0:XQPCACHE"aF     Extent cache size             64    Maximum blocks in extent cache 7106040-B     File ID cache size            64    Blocks currently in extent cache      0D     Quota cache size               0    Maximum buffers in FCP cache     826n0     Volume owner UIC        [SYSTEM]    Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCDT  G   Volume Status:  ODS-2, subject to mount verification, file high-watere marking,!       write-back caching enabled.-   QUASAR>-G I get 71 million blocks, using RAID version 2.6, but on a 3100-85 I get  this   PLUTO> show dev d   E Device                  Device           Error    Volume         FreeP	 Trans MntcF  Name                   Status           Count     Label        Blocks	 Count CntAF DSA100:                 Mounted              0  USERS0000000        40    2   1F DSA200:                 Mounted              0  USERS0000001        40    2   1. DPA0:          (PLUTO)  Online               0F DPA100:        (PLUTO)  Mounted              0  USER$DISK     66548820    1   1F $101$DKA0:     (PLUTO)  Mounted              0  OVMSVAXSYS     6714936  521   1F $101$DKA100:   (PLUTO)  Mounted              0  PATHWORKS     52549236  119   1C $101$DKA200:   (PLUTO)  ShadowSetMember      0  (member of DSA100:)rC $101$DKA300:   (PLUTO)  ShadowSetMember      0  (member of DSA200:)n. $101$DKA400:   (PLUTO)  Online               0. $101$DKA401:   (PLUTO)  Online wrtlck        0. $101$DKA402:   (PLUTO)  Online wrtlck        0. $101$DKA403:   (PLUTO)  Online wrtlck        0. DAD0:          (PLUTO)  Online               0. DFSC0:         (PLUTO)  Online               0. DNFS0:         (PLUTO)  Online               0  . Device                  Device           Error.  Name                   Status           Count. DFSRR0:                 Mounted              0. DFSS0:                  Online               0. DFSS1:                  Online               0 PLUTO> PLUTO> show dev dpa100/full   G Disk DPA100: (PLUTO), device type RAID0 Disk Array, is online, mounted,E file-SF     oriented device, shareable, available to cluster, error logging is enabled.  <     Error count                    0    Operations completed    2116d1     Owner process                 ""    Owner UICv [SYSTEM]0     Owner process ID        00000000    Dev Prot S:RWPL,O:RWPL,G:R,Wt;     Reference count                2    Default buffer sizeo     512 9     Total blocks            67030312    Sectors per tracka     255s;     Total cylinders             1093    Tracks per cylinderl     255 $     Allocation class             256  >     Volume label         "USER$DISK"    Relative volume number       0E9     Cluster size                  69    Transaction countc       1 =     Free blocks             66548820    Maximum files allowedS  507805a3     Extend quantity                5    Mount counti       1 2     Mount status              System    Cache name "_$101$DKA0:XQPCACHE"aF     Extent cache size             64    Maximum blocks in extent cache 6654882 B     File ID cache size            64    Blocks currently in extent cache6654895D     Quota cache size               0    Maximum buffers in FCP cache    1237o0     Volume owner UIC        [SYSTEM]    Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCDF  G   Volume Status:  ODS-2, subject to mount verification, file high-wateri marking,!       write-back caching enabled.    PLUTO>G On the 3100-85 I only have 68 million blocks, same type of drives, same G version of RAID software. I would really think the 3100 would be betteri then the old 3600 qbus card. Oh Wells Long live the qbus phillip3   ------------------------------    Date: 26 Apr 2005 12:22:04 -0700! From: susan_skonetski@hotmail.comt$ Subject: This weeks boot camp updateC Message-ID: <1114543324.523812.202930@z14g2000cwz.googlegroups.com>w   Dear Newsgroup,   C Here is this weeks boot camp update.  I am just trying to make sure,D everyone is informed and that way folks can not say "Boot Camp, whatG boot camp, I never heard of it"? We have people from Japan and ParaguayuC and Australia all over Europe, Canada and the US coming so if folkswF have not heard about it they are not listening.  We even have a personA coming on vacation time.  One of the key notes is a VP from South E Eastern Freight and another very cool one is on Friday by Clair GrantsG (VMS Engineering) "More Rocket Science from VMS Engineering" he will bev% talking about things not on roadmaps.d   GBH (Great Big Hug)i Suet     ---Original Message----- From: Skonetski, Susan% Sent: Tuesday, April 26, 2005 2:21 PM  To: Skonetski, SusanG Subject: Weekly Update - OpenVMS Advanced Technical Boot Camp - week of- April 25     Dear Distribution lists,  F Please excuse the delay (its school holidays here this week).  Here isC this weeks boot camp update.  As you can see things are progressingsC well, both the crash dump and TCP/IP pre boot camp seminars are nowa0 full.  I will start a wait list if it is needed.   Current registration is: 159# % of 200 (original registration)79%aE % of 250 (revised registration so that no one is turned away) 63% Web4 site Views 33,947 7 weeks to gom   The Pre Week Seminarss  F Crash Dump Analysis Tuesday - Saturday May 31- June 4 is now FULL - no& further registrations will be accepted  G TCP/IP Seminar Wed Jun 1 is now FULL - no further registrations will bei accepted  C Oracle Rdb seminar there are still a few seats left to reserve your  seatE http://www.oracle.com/webapps/events/EventsDetail.jsp?p_eventId=34804a  B Post Week Session: June 14/15 CHARON-VAX training, For Windows andC OpenVMS/Alpha In the facilities of: Oracle Corporation, New Englandt Development Center, One Oracle Drive, Nashua, New Hampshire, USA Training Room 1003   HEADS UP BOOT CAMP ATTENDEES  X ****************************************************************************************  D Boot Camp Hotel information:  EVERY ONE is responsible for their OWN hotel reservations  F Please do not accept ANOTHER rate other than what is advertised on theE web site http://h71000.www7.hp.com/symposium/index.html (scroll down)h  F You need to make your own hotel reservations there is now a NEW number- to call to make your reservation 877-619-0359Y  D Boot Camp attendees you will be given the opportunity to select your2 sessions approximately 2 weeks prior to the event.  X ****************************************************************************************  - Please let me know if you have any questions.'  
 Warm Regards,, Suea   ------------------------------    Date: 26 Apr 2005 14:25:18 -0700+ From: "DEC Hardware guy" <mness@bbcusa.com>: Subject: Re: TK50 C Message-ID: <1114550718.655470.288790@o13g2000cwo.googlegroups.com>g  4 Bill, I have some TK50Z-FA and TK50Z-GA drives here. Will any of those work?p   Let me know... =Marshall Ness Building Block Computers 800-272-2650 x14   Bill Gunshannon wrote: > I am back in begging mode. > C > Is there anyone who has TK50 drives (and maybe even a TK50Z) thate? > they are interested in getting rid of?  Knowing that they are@B > getting rarer every day, I think it would be a real good idea ifB > I could stockpile a few as I expect to continue to need them for > some time yet. > C > Oh yeah.  Anybody got old TK50 tapes they need to get rid of too?e >a > bill >r > --E > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Threee wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------   Date: 26 Apr 2005 21:45:33 GMT( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: TK50 , Message-ID: <3d7r3sF6n4fr2U1@individual.net>  C In article <1114550718.655470.288790@o13g2000cwo.googlegroups.com>, . 	"DEC Hardware guy" <mness@bbcusa.com> writes:6 > Bill, I have some TK50Z-FA and TK50Z-GA drives here. > Will any of those work?2  D I'm not sure of the differences in particular models (FA vs. GA) butC I assume pretty much any of them will work for my needs.  I'mm justiC trying to make sure I have a few spares for the future as they justoB get rarer and I expect my PDP-11's to start getting heavier use as" I turn the students loose on them.   bill     -- aJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Tue, 26 Apr 2005 21:18:38 -0700o( From: Jeff Cameron <roktsci@comcast.net> Subject: Re: TK50s/ Message-ID: <BE9460AE.CC75%roktsci@comcast.net>n  D On 4/26/05 6:20 AM, in article 3d6tggF6rmdkpU1@individual.net, "Bill. Gunshannon" <bill@triangle.cs.uofs.edu> wrote:   > I am back in begging mode. > C > Is there anyone who has TK50 drives (and maybe even a TK50Z) that ? > they are interested in getting rid of?  Knowing that they are B > getting rarer every day, I think it would be a real good idea ifB > I could stockpile a few as I expect to continue to need them for > some time yet. > C > Oh yeah.  Anybody got old TK50 tapes they need to get rid of too?e >  > bill1 I've often seen them on ebay for less than $10.00l   ------------------------------    Date: 26 Apr 2005 16:38:35 -0700! From: susan_skonetski@hotmail.com-  Subject: Updated VMS informationC Message-ID: <1114558715.954878.168120@o13g2000cwo.googlegroups.com>u   Dear Newsgroup,e  ; This is last weeks updated news that I sent out to my email2G distribution lists I just wanted to make sure that you have it.  PleaseHF keep in mind that this is information that I find useful or that folks< send to me and it is not an official newsletter of any kind.  
 Warm Regards,t Sueo     -----Original Message----- From: Skonetski, Susan% Sent: Friday, April 22, 2005 10:50 AM  To: Skonetski, Susan7 Subject: Updated VMS Information - OK for External use,k     Dear Distribution lists,  = Here is this weeks news, you may want to keep this for futureaB reference.  Please keep in mind that I would never, ever just takeG anyone off of distribution. So if you stop getting email from me it maytD be a "feature" of the distribution list, if that happens to you just? send me email and I will put you back on the distribution list.f   Index    Stuff from Sue 	Technical Journal! 	Useful Web Pages found this weekr   OpenVMS In the Press this week   >From our partners 	Oraclen 	Process      F Articles for the June issue of the technical journal are due on May 16C and at this point here are a list of the articles we are expecting. D This is an excellent list of articles which everyone will enjoy.  AsF always thanks to the teams that are writing the articles and the teamsE that will be editing and of course the core team of Warren Sander andgE Mary Marotta.  The VMS Technical journal receives about 50K views persD year and as such becomes a great educational and informational tool:4 http://h71000.www7.hp.com/openvms/journal/index.html  7 Porting OpenVMS to HP Integrity Servers  by Clair Grantn8 OpenVMS Bug checks by Richard Bishop and Ruth Goldenberg@ Disk partitioning on VMS: LDdriver's secrets by Jur van der BurgA Threaded tests for SMP systems by Richard Stammers Protecting andlE Monitoring OpenVMS Systems by Michael Grinnell and Gina Jones PortingnF to Itanium by Bruce Claremont Real Implementations of Legato NetWorkerD Backup for OpenVMS by Siobhan Ellis Program generation using PHP andE MySQL article by Richard Munroe Implementing a new backup environmenta in VMS with Data Protector    Useful web pages found this week  C New International Securities Exchange customer testimonial brochuref: http://h71000.www7.hp.com/openvms/brochures/ise/index.html  ? HP OpenVMS Migration Software for HP Alpha to Integrity Servers < http://h71000.www7.hp.com/openvms/products/omsva/omsais.html   Service Life-CycleL Management	http://services-global-service-fulfillment.inet.cpqcorp.net/cycl=
 e/default.aspm  . HP and Intel=AE Developer Workshops - workshopL overview	http://h21007.www2.hp.com/dspp/bus/bus_BusDetailPage_IDX/1,1252,60=
 45,00.html   OpenVMS in the Press this week  E http://biz.yahoo.com/prnews/050415/sff044.html?.v=3D3 CONNX Solutions>F Releases CONNX 9.0 SP1; Enhanced Functionality and Additional Platform2 Support: RMS on OpenVMS/Itanium, and Adabas on VSE  @ http://www.prweb.com/releases/2005/4/prweb229596.htm  AppMind=99G Delivers a Complete Management Solution for Unix, Linux and OpenVMS for ! Microsoft Operations Manager 2005l  L http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=3Dnews_=* view&newsId=3D20050419005371&newsLang=3DenD Stalker Software Partners with Mexico's Leading System Integrator to Provide VoIP TechnologieseL http://services-global-service-fulfillment.inet.cpqcorp.net/cycle/default.a= sp  . ______________________________________________  ! Partners - News from our Partners   ( JDBC for Rdb Release 7.1.3 Now Available    A          JDBC for Rdb Release 7.1.3 has just shipped.  The kit isn1 available on MetaLink and will be on OTN shortly.m            New Featuresd            - JDK 1.4/JDBC 3.0h5            - Oracle JDBC for Rdb multi-process serverl-            - New XML based configuration file ?            - Oracle SQL/Services manager to start and stop JDBCe              for Rdb servers4            - SSL-enabled client/server communication            Changed Features )            - Server Configuration options .            - Enhanced Thin Controller features9            - New connection switch "transaction=3Dmanual"e   Ginger Vollmar Rdb Engineeringr    8 ________________________________________________________  C Process Software and Sophos Partner to Offer Industry-Leading Virus 
 Protection<   to PMDF Messaging Server and PreciseMail Anti-Spam Gateway    E Framingham, MA - April 19, 2005 - Process Software, a Platinum Equityr< company and supplier of communications software solutions toE mission-critical environments, and Sophos, a global leader in networknD security, announced today a formal strategic partnership.  With this= agreement, Process Software offers its messaging customers an ? industry-leading virus scanning add-on module for both its PMDF E messaging server and PreciseMail Anti-Spam Gateway software products.nB The companies formed a partnership in response to Process SoftwareG customers' demand for a complete messaging and security solution at thed Internet gateway.   C Process Software first entered the messaging market in 2000 when itS? began developing and supporting PMDF messaging suite, a producteG previously developed by Innosoft. "To remain competitive and expand our5@ market presence in the messaging market, Process Software saw anE opportunity to combine both spam and virus protection," said Brian P.-A McDonald, Process Software president and chief executive officer.sG "Customers are viewing spam and viruses as a growing security threat toCE their business and are seeking an integrated solution to address thisfD serious issue. This partnership will allow us to meet these security challenges more efficiently."   ? Leveraging Process Software's 20-years of experience with email A technology and network security of mission critical networks, the G company developed and introduced PreciseMail Anti-Spam Gateway in 2003.sE Its multi-layer filtering technology has a proven out-of-the-box spamaB detection accuracy rate of 98% without losing legitimate messages.D PreciseMail Anti-Spam Gateway was first sold as an add-on product toF PMDF, Sendmail, and Sun Java System Messaging Server. Since late 2004,D it is also being sold to the larger messaging market as a standalone2 anti-spam solution, working with any email server.  G Process Software pursued Sophos for its industry-leading virus scanningeD technology and their support for the same platforms as both PMDF andB PreciseMail Anti-Spam Gateway operate on including Linux, Solaris,B Tru64, and OpenVMS. Prior to the partnership, Process Software andG Sophos shared some similar customers, especially in the educational andoC OpenVMS market.  Now customers will benefit from the integration of> these solutions.  B "As threats such as viruses, spam, phishing, malicious spyware andE other malware converge, increase in volume, maliciousness, complexitylF and speed, businesses require robust protection," said Richard Baldry,D head of strategic alliances at Sophos. "Process Software's messagingD clients will benefit from SophosLabs(tm), Sophos's global network ofF security threat analysis centers, to provide proactive and rapid virusB protection. We are very pleased to partner with Process Software."   ------------------------------   End of INFO-VAX 2005.233 ************************ and later, it does not use backup.exe at all,P > instead using the callable backup api (backupshr).  This way *no* hacks of anyP > kind are needed, including system service intercepts.  Everything is done withN > calls to straight hp-supplied code.  All of the tapesys-specific stuff is in > callba07

In article <v361to323jvk66@corp.supernews.com>,
 "Gooneybird" <Gooneybird23@charter.net.nospam> wrote:

> Ydusitmata wrote:
> > Kerry Moke <moke@stoke.net> wrote:
> >
> >
> >>
> >> Ydusitmata wrote:
> >>>       Saw this in another group.
> >>>
> >>>
> >>> To the tune of "If you're happy and you know it, clap your hands"...
> >>>
> >>> If you cannot find Osama, bomb Iraq.
> >>> If the markets are a drama, bomb Iraq.
> > (snip)
> >>> Even if we have no reason,
> >>> Bomb Iraq.
> >
> >> why don't you go and read a book, or go for a walk, or ride a bike, or
> >> go and see the planes take off at the local airport
> >
> > Bullseye. I hit a nerve here.
> >
> > ronh
> 
> Nah....if you'd really hit a nerve, he'd have suggested that you go play in 
> the
> traffic for a while.  :)))

And by the way; put this plastic bag over your head on your
way out. Have fun.
^~00003669:0000130631:036276:From: "Dave Brower" <lonewolf@interl.net>
Newsgroups: rec.autos.makers.vw.aircooled
References: <20030125215251.22210.00000301@mb-ca.aol.com>
Subject: Re: OT weakest link
Date: Sat, 25 Jan 2003 23:04:33 -0600
Lines: 165
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
NNTP-Posting-Host: rfm240.interl.net
Message-ID: <3e336c13_2@newsfeed>
X-Trace: newsfeed 1043557395 63.161.100.240 (26 Jan 2003 00:03:15 -0500)
X-Original-NNTP-Posting-Host: 63.161.100.240
Path: mvb.saic.com!news-out.