1 INFO-VAX	Wed, 30 Jun 2004	Volume 2004 : Issue 358       Contents:P Re: Announcing - The June 2004  issue of  The OpenVMS Technical Journal - Please" Re: Compiling CVS on OpenVMS 7.3-2" Re: Compiling CVS on OpenVMS 7.3-2 Re: dcl command - pipe Re: DECC /VAXC Compiler  Re: delete directory recursive Re: Equipment release policy?  Re: Equipment release policy?  Re: Equipment release policy? = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = RE: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article  Re: jGRASP for OpenVMS+ Re: More LAT questions on LAT$SYSTARTUP.COM  Re: NFS mounting Re: NTP and NTPDATE  Re: NTP and NTPDATE $ Re: Split I/Os to contiguous file??? Re: VAX  Spare Parts RE: VAX  Spare PartsP Re: Volume shadowing between FC Storage at different sites, and the allocation cP Re: Volume shadowing between FC Storage at different sites, and the allocation cP Re: Volume shadowing between FC Storage at different sites, and the allocation cP Re: Volume shadowing between FC Storage at different sites, and the allocation cP Re: Volume shadowing between FC Storage at different sites, and the allocation c  F ----------------------------------------------------------------------  % Date: Tue, 29 Jun 2004 21:51:55 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>Y Subject: Re: Announcing - The June 2004  issue of  The OpenVMS Technical Journal - Please + Message-ID: <40E22ACB.C22C70AC@comcast.net>    Sue Skonetski wrote: > 
 > Dear Folks,  > F > It is my pleasure to announce the availability of the newest copy ofG > the OpenVMS Technical Journal.  This issue is 180 pages in length and > > contains 11 different articles written by technical experts. > G > All articles are available in PDF and HTML and combined documents are  > available in both PDF and PS.  > F > As with any project this is the result of many hours of hard work byF > both the Authors, Writing and Web team, my deepest thanks for making > this happen. > G > Please visit http://h71000.www7.hp.com/openvms/journal for the latest  > VTJ  >  > Warm Regards,  > Sue    Thanx, Sue!    Looking forward to it!   D.J.D.   ------------------------------  % Date: Tue, 29 Jun 2004 23:06:32 +0200 3 From: "Ton van der Zwet" <ton.vanderzwet@hccnet.nl> + Subject: Re: Compiling CVS on OpenVMS 7.3-2 = Message-ID: <40e1d9ec$0$768$3a628fcd@reader20.nntp.hccnet.nl>   1 "James T Horn" <horn@shsu.edu> schreef in bericht 7 news:843706dc.0406250637.73d4bd7d@posting.google.com... H > When trying to build the CVS system on an OpenVMS 7.3-2 box, I get the error: > 
 > $ CC diff.c  > , > # include "fnmatch.h" /* Our substitute */ > ..^ G > %CC-F-NOINCLFILEF, Cannot find file "fnmatch.h" specified in #include 
 directive.3 > at line number 29 in file (file location)DIFF.C;1  >  > 6 > Any ideas why? I've tried it on bot 1.11.17 and 1.12  H I presume you use the enclosed build.com. If you use the GNV environment the H build with a few patches completes without this error. If I read the log
 file I seeA a link of fnmatch.h.in to lib/fnmatch.h. Again this is in the GNV  environment.D The resulting CVS 1.11.17 executable still has a bug. Martin Borgman	 suggested H that this is the result of incompatible open()  and fdopen() calls. This is beingG investigated. The build of a previous version (CVS 1.11.11) works as it  should. 0 Remember that CVS for VMS is client side only!!!G CVS is primairly used in opensource projects or mixed environments. CMS  is not an option there.  
 For links: build of the CVS 1.11.11: & http://www.oooovms.dyndns.org/gnv/cvs/$ opensource to OpenVMS porting guide:F http://www.oooovms.dyndns.org/reference/OpenVMS_Porting_Guide_v031.pdf    log of the 1.11.17 build so far:) http://www.4ovms.dyndns.org/buildcvs.html 0 PHPBB forum about opensource porting to OpenVMS:" http://www.4ovms.dyndns.org/phpbb/   Ton van der Zwet1 Member of the OpenOffice to OpenVMS porting team.    ------------------------------  % Date: Tue, 29 Jun 2004 20:51:36 -0500 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler>+ Subject: Re: Compiling CVS on OpenVMS 7.3-2 I Message-ID: <craigberry-374094.20513629062004@news-east.dca.giganews.com>   3 In article <2Y0x6bGyYkCj@eisner.encompasserve.org>, =  koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:   N > In article <843706dc.0406290537.32a6cafc@posting.google.com>, horn@shsu.edu  > (James T Horn) writes:" > > Does CMS work with Subversion?  H No, they are two entirely different and unrelated packages and CMS is a C proprietary package that does not, as far as I know, work with any   repositories except its own.  0 >    I don't know what you mean by "subversion",  F He didn't say "subversion"; he said "Subversion."  It's the name of a & version control system similar to CVS:   http://subversion.tigris.org/    ------------------------------  % Date: Tue, 29 Jun 2004 21:58:11 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: dcl command - pipe * Message-ID: <40E22C43.F73F99F@comcast.net>   briggs@encompasserve.org wrote:  > [snip]! > $ PIPE SEARCH foo.dat "bar" | - " >         ( READ SYS$PIPE LINE ; -. >           FIELD1 = F$ELEMENT(0," ",LINE) ; -, >           DEFINE /JOB FIELD1 &FIELD1 ) ; -$ >        FIELD1 = F$TRNLNM("FIELD1")  G Because these PIPE commands tend to get quite long, I find it advisable 
 to simply    $ PIPE - 	command | - 	command | -' 	(READ SYS$PIPE P9 ; DEFINE/JOB P9 &P9)   B ...and parse out the result of F$TRNLNM() back in the main stream.   D.J.D.   ------------------------------    Date: 29 Jun 2004 12:54:50 -0700- From: soccer13player@yahoo.com (Nom de Plume)   Subject: Re: DECC /VAXC Compiler= Message-ID: <f401eb7f.0406291154.7a00c937@posting.google.com>   h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<3rDJLLXAIqd$@eisner.encompasserve.org>...m > In article <c3661f42.0406290539.1d3e7b9f@posting.google.com>, rxp2158@ix.netcom.com (ronald piazza) writes:  > C > > What is the main difference between the DECC and VAXC compiler?  > 9 > VAXC implements an extended K&R C and runs only on VAX.  > E > DEC C implements an extended ANSI C and runs on both VAX and Alpha.   C With DEC C /STANDARD=VAXC places the compiler in VAX C mode.  There E are differences in the C language as implemented in previous versions C of VAX C and the C language as defined by ANSI (the differences are @ primarily concerned with how the preprocessor works).  This modeF provides compatibility for programs that depend on old VAX C behavior.   JMOD   ------------------------------  % Date: Tue, 29 Jun 2004 21:40:48 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>' Subject: Re: delete directory recursive + Message-ID: <40E22830.46DDAB0F@comcast.net>    Paul Repacholi wrote:  > B > "Jerome Forissier" <Jerome.Forissier@_no_._spam_.hp.com> writes: > E > > I second that. In my opinion, the new /RECURSIVE qualifier should > > > just do what it means, i.e., recurse through the directoryD > > hierarchy, but _not_ override any protection. This should be the= > > purpose of a /FORCE qualifier (or /OVERRIDE or whatever).  > G > The problem is, the ACP *DOES* recurse through the tree, in preorder. E > It would have to be changed to a postorder traversal, and foo knows ) > what would get broken as a side effect.   0 Well, no, not really - that's not the ACP's job.  F DELTREE's job should be to first traverse the tree "forward", from the? root outward collecting all the branches and leaves. Then, work A "backwards" back down, just the way true pro.'s tackle the job of G bringing a tree down in a residential area. Process the branches one at F a time: delete all the leaves on each branch, then delete each branch.   Could eat up lots of VM, but...   G Take a look at my DELTREE.COM. The one on the web is a bit stale, but I H believe it does work o.k. I just haven't uploaded my refinements in some time.    D.J.D.   ------------------------------    Date: 29 Jun 2004 11:15:49 -0700 From: deanw@rdrop.com (Dean W)& Subject: Re: Equipment release policy?= Message-ID: <197beabd.0406291015.20e3d620@posting.google.com>   V sol gongola <sol@adldata.com> wrote in message news:<40D9FBB6.A7575B82@adldata.com>... > one_of_many wrote:L > > I have a new VP who seems completely unconcerned about wiping the discs, > I > If the media is strictly VMS related, any one obtaining it will not be  K > able to just pop it into a PC and read it. That is not much of a problem.   E *blink*. FSVO "read", you are correct. But assuming it's a SCSI disk:   " dd /dev/[vms_disk] ~/vms_disk_file  > and maybe some command line options (fire up any *nix variant-F including Cygwin on top of Windows- and 'man dd') would get you a fileB that contains the raw contents of the disk- then use your favoriteD tool to search for key phrases, etc. No, you can't browse through it? with Windows, but you can get a *lot* of information off of it. F Assuming that you can't, just because most people don't have a VMS boxE handy, is dangerously naive. IMO, but I only hang out around computer ' forensics experts, I aren't one meself.    ------------------------------    Date: 29 Jun 2004 11:18:52 -0700 From: deanw@rdrop.com (Dean W)& Subject: Re: Equipment release policy?= Message-ID: <197beabd.0406291018.361358c5@posting.google.com>    Fixing my previous post:  ( dd if=/dev/[vms_disk] of=~/vms_disk_file   ------------------------------  # Date: Tue, 29 Jun 2004 19:17:00 GMT 3 From: hammond@not@peek.ssr.hp.com (Charlie Hammond) & Subject: Re: Equipment release policy?1 Message-ID: <MejEc.5013$ZU.4829@news.cpqcorp.net>    Some body wrote:  J >> If the media is strictly VMS related, any one obtaining it will not be L >> able to just pop it into a PC and read it. That is not much of a problem.  G A properly paranoid security officer might reasonably assume that media B which is "strictly VMS related" is likely to end up in a VMS shop.   --  J       Charlie Hammond -- Hewlett-Packard Company -- Ft Lauderdale  FL  USAF           (hammond@not@peek.ssr.hp.com -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 29 Jun 2004 14:04:22 -0700' From: icerq4a@spray.se (David Svensson) F Subject: Re: Intel Itanium's very survival in doubt - inquirer article= Message-ID: <734da31c.0406291304.525fe431@posting.google.com>   d Paul Repacholi <prep@prep.synonet.com> wrote in message news:<87d63jbaph.fsf@k9.prep.synonet.com>.../ > "Barry Treahy, Jr." <Treahy@MMaz.com> writes:  > H > > Just curious, how many years and how many billions have been dumped,F > > excuse me, invested into Itanic?  What do you suppose is the upper= > > limit of a negative ROI before Intel must cut its losses?  > E > No idea how many billions, but HP taemed up with intel in '93 after F > finding son-of-playdoh, aka PARISC3 heading for the too hard basket.) > Yes, it is almost older than the Alpha!  > H > Please keep in mind, the the itanic is NOT an intel thing, it is owned? > by a joint intel/hp venture, and thus free of the intel cross  > licencing deals... > H > I expect the plug will be pulled before the Alpha team is able to tapeF > out. In fact, I'm a little suprised it is still alive at all. I lost > $1 on 1 May.  C I don't expect that. It has been obvious for atleast 4-5 years that E Itanium would not replace x86. Intel wanted a high-end chip with high B profit, otherwise they would have cancelled in 2001. It would haveF been another thing if Intel were short on money, but they make lots ofF money now and will continue to make lots of money with x86-64 and thatB will in turn help them continue with Itanium. They clearly want to' have an alternative to x86 on the side.   8 There are also areas where Itanium has great performance0 http://www.dl.ac.uk/CFS/benchmarks/compchem.html   ------------------------------    Date: 29 Jun 2004 16:40:49 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) F Subject: Re: Intel Itanium's very survival in doubt - inquirer article3 Message-ID: <uSi$rsuVO7ri@eisner.encompasserve.org>   E > I don't expect that. It has been obvious for atleast 4-5 years that G > Itanium would not replace x86. Intel wanted a high-end chip with high 6 > profit, otherwise they would have cancelled in 2001.  F Perhaps more important, Intel wants a chip for which they are the sole source, avoiding clones.   ------------------------------  % Date: Tue, 29 Jun 2004 22:45:38 +0100 @ From: Andrew Harrison <andrew_remove_.harrison@_remove_.sun.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <cbsntv$17t$1@new-usenet.uk.sun.com>   Barry Treahy, Jr. wrote:  G > Just curious, how many years and how many billions have been dumped,  K > excuse me, invested into Itanic?  What do you suppose is the upper limit  5 > of a negative ROI before Intel must cut its losses?  >   ? Itanium is the based on PA-WW (Wide Word) which has its origins A in work done by Cydrome. The project started at HP proper in 1990 * staffed by engineers aquired from Cydrome.  < Intel joined, was suckered into a joint development in 1994.  : The WSJ suggested that Intel and HP between them have sunk= a total of 5 billion dollars into Itanium, however that count 3 was conducted 18 months ago so add another billion.    Regards  Andrew Harrison  > Barry  >    ------------------------------  % Date: Tue, 29 Jun 2004 19:04:13 -0400 # From: "John Smith" <a@nonymous.com> F Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <Y56dnbaoEYvlaHzdRVn-vw@igs.net>   Andrew Harrison wrote: > Barry Treahy, Jr. wrote: > G >> Just curious, how many years and how many billions have been dumped, E >> excuse me, invested into Itanic?  What do you suppose is the upper < >> limit of a negative ROI before Intel must cut its losses? >> > A > Itanium is the based on PA-WW (Wide Word) which has its origins C > in work done by Cydrome. The project started at HP proper in 1990 , > staffed by engineers aquired from Cydrome. > > > Intel joined, was suckered into a joint development in 1994. > < > The WSJ suggested that Intel and HP between them have sunk? > a total of 5 billion dollars into Itanium, however that count 5 > was conducted 18 months ago so add another billion.     G And to think that evolving Alpha to EV8 and beyond was too expensive at  $150MM per annum.   F Let's see...VMS runs on Alpha. Tru64, a better unix than PH-UX runs onI Alpha. NSK was in the throes of being ported to Alpha. NT (and unreleased H W2K) runs on Alpha.  Various penguin-like things run on Alpha. Remind me/ again...just what was the attraction of Itanic?    ------------------------------  % Date: Tue, 29 Jun 2004 17:43:22 -0700 * From: "Jack Peacock" <peacock@simconv.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <WfqdnSmBboY2kX_dRVn_iw@mpowercom.net>  . "John Smith" <a@nonymous.com> wrote in message& news:Y56dnbaoEYvlaHzdRVn-vw@igs.net...1 > again...just what was the attraction of Itanic?  > J HP would be paid (off) by Intel to move all their OSes to it, and HP couldL shut down CPU chip development too.  As the recipient of a sizeable chunk ofH that five billion it made good sense to HP.  Plus, if it goes wrong theyI dump Intel and switch to AMD, all the bases covered.  No Dell lockin type 3 agreements leaving them in a performance backwater.   L By appearances just about everyone in the Itanium program, except for Intel,J has done well from participating.  Even Dell, with the handful of rebadgedL Itanium boxes it moved the last few years, isn't hurting.  They got Intel toI copy AMD.  Based on that coup I'd bet Dell is taking order from the Devil 9 for snow plows, cuz a very hot place just turned glacial.    Jack Peacock   ------------------------------  % Date: Tue, 29 Jun 2004 18:18:45 -0700 # From: "Tom Linden" <tom@kednos.com> F Subject: RE: Intel Itanium's very survival in doubt - inquirer article9 Message-ID: <NDEMLKKEBOIFBMJLCECIEEKNDHAA.tom@kednos.com>   E Do you know for a fact that Intel actually paid HP to port their OS's ; to Itanium?  I doubt very much that Intel paid money to HP.   8 When HP embarked on the Merced I believe they had to pay Intel to work with them.     -----Original Message-----1   From: Jack Peacock [mailto:peacock@simconv.com] &   Sent: Tuesday, June 29, 2004 5:43 PM   To: Info-VAX@Mvb.Saic.Com H   Subject: Re: Intel Itanium's very survival in doubt - inquirer article    0   "John Smith" <a@nonymous.com> wrote in message(   news:Y56dnbaoEYvlaHzdRVn-vw@igs.net...3   > again...just what was the attraction of Itanic?    > L   HP would be paid (off) by Intel to move all their OSes to it, and HP could<   shut down CPU chip development too.  As the recipient of a   sizeable chunk of J   that five billion it made good sense to HP.  Plus, if it goes wrong theyK   dump Intel and switch to AMD, all the bases covered.  No Dell lockin type 5   agreements leaving them in a performance backwater.   C   By appearances just about everyone in the Itanium program, except    for Intel,L   has done well from participating.  Even Dell, with the handful of rebadgedA   Itanium boxes it moved the last few years, isn't hurting.  They    got Intel toK   copy AMD.  Based on that coup I'd bet Dell is taking order from the Devil ;   for snow plows, cuz a very hot place just turned glacial.      Jack Peacock       --- (   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------  # Date: Wed, 30 Jun 2004 03:43:02 GMT , From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article* Message-ID: <QtqEc.2201$7t3.843@attbi_s51>  G I looked through the slides that Intel presented back in April  Saw the J Tejas and Jayhawk mentioned.  They are or were follow-ons for the PrescottH and Xeon (after Nocona) respectively.  They seemed to have nothing to doK with Itanium.  So while some of the IA-32 plans were canned or changed, the ' IA-64s were not.  Not that I could see.    Dave...   K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com> ; wrote in message news:cbrh1u$cv9$1@new-usenet.uk.sun.com...  > Dave Gudewicz wrote:L > > At a recent LUG meeting (April 2004) our featured speaker from Intel hadD > > other things to say wrt Itanium/64-bit extensions/Xeon and other alphabetK > > soup.  Itanium IS Intel's chip for the high-end.  That's was the gospel L > > according to Intel.  Was the Feb. 04 IDF announcement confusing (aka didE > > Intel screw this up?)  Yep.  Was it misinterpreted?  See previous  answer.  > >  > A > That was all canned with the cancellation of Tejas and Jayhawk.  > ? > The Gospel according to Intel has changed rather dramatically 
 > since then.  > L > > Has Itanium been slow, no very slow, to ramp up?  Yep.  Has the slope ofF > > this ramp changed post Merced?  Looked like it from the #s we were shown. > >  > B > Not really. The business plan that HP and Intel presented to theB > Analysts when Itanium I was introduced made some very optimistic= > predictions about the rap in Itanium volumes. The predicted ; > takeoff simply hasn't happened and currently Itanium unit $ > volumes are running at 6K a month. > > > Its worth noting that even Alpha, always the follower in the= > non x86 processor market in terms of market share enjoyed a " > faster ramp up that Itanium has. > @ > Its fair to say that with the possible exceptions of i860 also@ > introduced by Intel the Itanium has had the worst introduction* > of any major new processor architecture. > 	 > Regards  > Andrew Harrison I > > Now can all this change?  Sure.  Has it?  Not yet near as I can tell.  > >  > > 2 > > "John Smith" <a@nonymous.com> wrote in message* > > news:SOqdnWAahsNpFn3dRVn-sw@igs.net... > >  > >>Barry Treahy, Jr. wrote: > >>$ > >>>david20@alpha2.mdx.ac.uk wrote: > >>>  > >>>  > >>>>For info :-  > >>>>8 > >>>>There is an article in the Inquirer with the title > >>>>2 > >>>>"Intel Itanium's very survival in doubt" See/ > >>>>http://www.theinquirer.net/?article=16868  > >>>> > >>>> > >>>> > >>> E > >>>Reads like a bad novel but just repeats the critical path/volume H > >>>issues that have been hounded on this list, that HP seems to avoid,F > >>>deny, or ignore, that being that if Itanic never reaches criticalE > >>>volume in sales, compliments of X86-64, it'll be just as another I > >>>proprietary chip like Alpha, PA-RISC, MIPS, except they don't own it H > >>>or control it and HP will remain at the mercy of Intel for its longH > >>>term future...  If Intel was not concerned about the loss of marketE > >>>share to AMD, they would not have introduced their alternatives, F > >>>knowing very well it would directly compete and hurt any possible > >>>Itanic growth...  > >> > >>I > >>RSN Intel will realize that there isn't going to be any Itanic growth  and - > >>dump all their eggs into the x86-64 camp.  > >>L > >>Depending on the agreement with HP about Itanic, it may cost Intel $1-2B > >  > > in > > J > >>termination fees - chump change for them. For HP it would mean the end of! > >>them as an enterprise player.  > >>7 > >>And carly(tm) would still get her golden parachute.  > >> > >> > >  > >  > >  >    ------------------------------  # Date: Wed, 30 Jun 2004 03:52:23 GMT , From: "Dave Gudewicz" <k9jdk@NOSPAMarrl.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article* Message-ID: <XNqEc.2260$7t3.263@attbi_s51>  J I remember when it was said that Alpha being sole sourced by DEC was a badL thing.  Then around the same time, didn't DEC discover some Alpha secrets inK some of Intel's chips which led to a march to the courts which led to Intel I buying DECs then new fab plant for around 3/4 billion.  Then someone else F started making the Alpha chip.  Intel also got DECs low-power and veryG popular processor (StrongARM) which was found in many things like PDAs, # GPSs, DSPs and who knows what else.     : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:uSi$rsuVO7ri@eisner.encompasserve.org...  > G > > I don't expect that. It has been obvious for atleast 4-5 years that I > > Itanium would not replace x86. Intel wanted a high-end chip with high 8 > > profit, otherwise they would have cancelled in 2001. > H > Perhaps more important, Intel wants a chip for which they are the sole > source, avoiding clones.   ------------------------------   Date: 29 Jun 2004 19:09:06 GMT From: healyzh@aracnet.com  Subject: Re: jGRASP for OpenVMS , Message-ID: <cbseoi0168b@enews1.newsguy.com>  1 Keith Brown <kbrown2720@nospamcomcast.net> wrote: R > One side issue question... Is Gnat 5.00a for OpenVMS free? Where can I get it? IO > need to run on OpenVMS 7.3-1 but cannot find a version of Gnat which will run 7 > on anything newer than 7.2-1. Can you provide a Link?   , I wish 5.00a was available for hobbyists :^(  H It looks like I'm probably running GNAT312P-OPENVMS7_1-19990629.EXE;1 onH OpenVMS 7.3-2.  I've not tried anything major with it, I just compiled aC simple "Hello, World" program since I'd not tried to use GNAT since  upgrading from 7.2-1H1.    		Zane   ------------------------------  % Date: Tue, 29 Jun 2004 21:48:03 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>4 Subject: Re: More LAT questions on LAT$SYSTARTUP.COM+ Message-ID: <40E229E3.C7AD8A1D@comcast.net>    Neil Cherry wrote: > [snip]Q > OPENVMS-ALPHA-USER DEC             0  0     100    0.0  30-NOV-2004 30-NOV-2004 Q > OPENVMS-HOBBYIST   DEC             0  0     100    0.0  30-NOV-2004 30-NOV-2004  > [snip]Q > VAX-VMS            DEC             0  0     A      0.0  30-NOV-2004 30-NOV-2004    O.K. There's your VMS licenses.   H That said, I re-read the earlier post about dynamic rating and I believe/ the comment was made about interactive logins.    H Note that this is determined not by the license (how many are allowed byH the license) but by the IJOBLIM parameter (how many are permitted by the5 Job Controller). This can be displayed in a few ways:   / $ SET LOGINS/INTERACTIVE	! No value expression!    ...or...  ( $ WRITE SYS$OUTPUT F$GETSYI( "IJOBLIM" )   ...or...   $ RUN SYS$SYSTEM:SYSGEN  SYSGEN>  USE ACTIVE  SYSGEN>  SHOW IJOBLIM    ...or...   $ MCR SYSMAN PARA SHOW IJOBLIM  7 This is a key factor in the dynamic rating calculation.    D.J.D.   ------------------------------  % Date: Tue, 29 Jun 2004 11:14:12 -0700 + From: "Barry Treahy, Jr." <Treahy@MMaz.com>  Subject: Re: NFS mounting ' Message-ID: <40E1B174.7080807@MMaz.com>    Bob Koehler wrote:  _ >In article <40e1800b$1@news.starhub.net.sg>, "Jignesh Vyas" <jignesh_vyas@hotmail.com> writes:  >    >  >>Hi,  >>) >>Can  I mount Tru64 file system on VMS ?  >> >>     >> > F >   Not the way you'ld like to.  You can mount them as foriegn volumes? >   and use block access to the disk if you know the Tru64 file  >   system internals.  >    > G Why do you say that?  Why not mount the Tru64 filesystem by way of NFS?    Barry    --    > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                            ------------------------------  # Date: Wed, 30 Jun 2004 00:57:49 GMT % From: "Louie" <lwallace@twcny.rr.com>  Subject: Re: NTP and NTPDATE: Message-ID: <heoEc.171086$j24.141344@twister.nyroc.rr.com>   Thanks to all for your help.  @ I didn't know you could telnet to port 13 and get the time back.8 I surprised to see this work on the TS-2100 time server.E This should be enough to integrate a check into the system to correct  any large time drift.   
 Thank You All  Louie.  A "Mike Rechtman" <michael.rechtman.nospam@hp.com> wrote in message   news:40DEA26F.391A16AC@hp.com... > Louie wrote: > > E > > Running UCX version 4.2 with NTP as a client on a Alpha 2100 with  OpenVMS H > > 7.1. Everything is fine until the server time jumps by more than 7.5 hours E > > following a powerdown or power blip. Then NTP won't set the time.  > > K > > Is there a NTPDATE program available for this version of UCX that I can  run " > > from a COM script during boot? > > 6 > > Or maybe a way to configure NTP to reset the date? > > J > > Upgrading to TCP/IP version 5.0 is not an option because it will break the 3 > > software that is relying on FTP in version 4.2.  > >  > > Thanks in advance 
 > > Louie. > C > The following is something I use to set the _approximate_ time at 
 > startup,% > so that NTP can take it from there. 6 > Unsupported, but works for me (run once at startup): >  > -----<start code>----- >  > $       Type SYS$INPUT >  > B >         This program and any program with which it cooperates or > exchanges I >         information and/or which has been either written or modified by J >         the undersigned is not warranted in any manner, shape or form to" >         perform any useful task.+ >         It is guaranteed to contain bugs. F >         Its use and the interpretation of any results is left solely8 >         to the discretion and imagination of the user.7 >         No claims are made or implied by its release. E >         Any distribution of any such program MUST include the above 	 > notice.  > ? >                                                Mike Rechtman, 
 > 31-Dec-2001  > $  > $! > $ vf_ = f$verify(0) 1 > $ ds = f$trnlnm("SYS$TIMEZONE_DAYLIGHT_SAVING")  > $ if (ds .nes. "") > $ then1 > $       if ((ds .eqs. "0") .or. (ds .eqs. "1"))  > $       thenF > $               d = f$integer(f$trnlnm("SYS$TIMEZONE_DIFFERENTIAL")) > $               sign = "+"  > $               if (d .lt. 0 ) > $               then$ > $                       sign = "-"# > $                       d = 0 - d  > $               endif  > $               d = d / 3600D > $               diff = "''sign'''d':00:00"      ! whole hours only > $       else$ > $               write sys$output -8 > "Illegal value ''d_s' in SYS$TIMEZONE_DAYLIGHT_SAVING" > $               exit > $       endif  > $ elseG > $       diff = "+02:00:00"                      ! Standard local time 	 > $ endif  > $! > $ a1 = f$cvtime("",,"DAY") > $ a2 = f$cvtime("",,"MONTH"), > $ a3 = f$extract(2,2,f$cvtime("",,"YEAR")) > $ today = "''a3'-''a2'-''a1'"  > $ now = f$cvtime("",,"TIME") > $ mess1 = f$envir("MESSAGE") > $ set message/nof/noi/nos/not  > $ on error then goto oops : > $ define/user sys$input  TT: ! for BATCH change to OPA0:E > $ define/user sys$output  TT: ! must be an existing terminal device  > $ define/user sys$command TT: B > $ telnet time-b.timefreq.bldrdoc.gov  /port=13/log=show_time.tmp > $ set noon > $ set message 'mess1+ > $ open/read/error=oops tmp show_time.tmp;  > $ read/error=oops tmp line > $ date = f$elem(1," ",line) ! > $ utc_time = f$elem(2," ",line) 1 > $ time = f$cvtime("''utc_time'''diff'",,"TIME") J > $ write sys$output "here: ''today':''now'      UTC: ''date':''utc_time'"  > $ if (date .eqs. today) then - >       set time='time* > $ write sys$output "Time set to ''time'" > $oops: > $ st = $STATUS
 > $ close tmp  > $ dele show_time.tmp;* > $ set message 'mess1 > $ vf_ = f$verify(vf_)  > $ exit st  > $! > ----<end code>---- >  >  > --  G > --------------------------------------------------------------------- G > Usual disclaimer: All opinions are mine alone, perhaps not even that. A > Mike Rechtman                            *rechtman@tzora.co.il* F > Kibbutz Tzor'a.                          Voice (home): 972-2-9908337D >   "20% of a job takes 80% of the time, the rest takes another 80%"G > --------------------------------------------------------------------- ! > -----BEGIN GEEK CODE BLOCK-----  > Version: 3.1< > GCM/CS d(-)pu s:+>:- a++ C++ U-- L-- W++ N++ K? w--- V+++$8 > PS+ PE-- t 5? X- tv-- b+ DI+ D-- G e++ h--- r+++ y+++@! > ------END GEEK CODE BLOCK------    ------------------------------  % Date: Tue, 29 Jun 2004 21:49:33 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: NTP and NTPDATE+ Message-ID: <40E22A3C.1F380C82@comcast.net>    Louie wrote: >  > Thanks to all for your help. > B > I didn't know you could telnet to port 13 and get the time back.: > I surprised to see this work on the TS-2100 time server.G > This should be enough to integrate a check into the system to correct  > any large time drift.   4 I would still recommend getting your hardware fixed.  * Heal the wound rather than using bandages.   D.J.D.   ------------------------------    Date: 29 Jun 2004 12:45:27 -0700$ From: gspamtackett@yahoo.com (Galen)- Subject: Re: Split I/Os to contiguous file??? = Message-ID: <bdc65a53.0406291145.515ae772@posting.google.com>   v koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote in message news:<l4$AJlesFgvI@eisner.encompasserve.org>...e > In article <CPJwD4mW0Yds@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: h > > In article <bdc65a53.0406210326.1de2666c@posting.google.com>, gspamtackett@yahoo.com (Galen) writes: > > J > >> The UCB$L_MAXBCNT for this and the other SCSI disks that I checked isA > >> indeed 20000 hex which corresponds to a limit of 256 blocks.  >   J > >> Now the problem is to determine whether the split I/Os are really the- > >> big limiting factor on write throughput.  > > F > > Try cutting the UCB$L_MAXBCNT value in half and seeing if there is > > an effect. > > 8 > > CMKRNL is your friend (at least on test systems :-). > 1 >    Gee, I thought that was what >>>d/v was for.   F Is there some way to do this with Delta? I've been trying to no avail.! All I get is something like this:   	 $ ANA/SYS 8 SDA> !(Here i proceeded to get the device's UCB address: FFFFFFFF810B05C0)  ...  SDA> SPAWN RUN SYS$SHARE:DELTA	 810B06D8/  Eh?   > Based on an older post to a different thread, I also tried the
 following:   [Q 1;M  00000000 00000001n 00010001:810B06D8/ Eh?   F This is an ES40 running V7.3-2. I would also be willing to try it from@ the system console if I could figure out how to access the right location from there.   00010001:810B06DB    ------------------------------  % Date: Tue, 29 Jun 2004 11:12:54 -0700e+ From: "Barry Treahy, Jr." <Treahy@MMaz.com>e Subject: Re: VAX  Spare Partse' Message-ID: <40E1B126.2020508@MMaz.com>s   Tom Linden wrote:q   >  -----Original Message-----'3 >  From: Barry Treahy, Jr. [mailto:Treahy@MMaz.com]e( >  Sent: Tuesday, June 29, 2004 10:10 AM >  To: Info-VAX@Mvb.Saic.Com >  Subject: Re: VAX Spare Partsi >  >i >  Keith Cayemberg wrote:e >s >  > Hi Jim, >  >J >  > here's just a "heads up" concerning a new VAX Services announcement = at, >  > OpenVMS.org by NEMONIX Engineering,Inc. >  >' >  > In this announcement they state...r >  >I >  > "NEMONIX is targeting operators of the nearly _175,000 VAX machines_sE >  > still in operation in the United States alone =96 computers that J >  > continue to power critical operations for companies across a multitu= de >  > of industries." >  ># >  > You can find the story here...e >  >G >  > *NEMONIX Launches Custom Engineering Services and VAX HotLine Sitee
 >  > Support* @ >  > http://www.openvms.org/stories.php?story=3D04/06/28/6005658 >  >J >  Too bad they weren't more interested in being reasonable about the pri= ceF >  of their upgrade solutions.  I, for one, knocked on their door many@ >  times over the past five years, prior to moving completely toI >  CHARON-VAX.  In all candor, I'm glad they wouldn't negotiate because I:F >  would feel it was money wasted today, now that I have CHARON-VAX... >RJ >FWIW, I have 7.3 installed on another emulator on a P3 500MHz and I ran = the  >PL/I-H >benchmark tests and it compared to a 4000/90.  Now I am curious what it	 >would do  >on a quad Opteron Tyan. >c > =20v >aF Can't answer that as I only have a P4/HT @ 3.4Ghz and a Dual Athlon=20I MP2800+ system.  The first rates at about 63 VUPS, the second at about=20 H 53 VUPS.  Do you have the pseudo-VUP calculator CALCULATE_VUPS.COM to=20 run on your box?   Barryv   --=20n  > Barry Treahy, Jr                       E-mail: Treahy@MMaz.com> Midwest Microwave                          Phone: 480/314-1320> Vice President & CIO                         FAX: 480/661-7028                       =20.   ------------------------------  % Date: Tue, 29 Jun 2004 11:29:39 -0700 # From: "Tom Linden" <tom@kednos.com>o Subject: RE: VAX  Spare Parts-9 Message-ID: <NDEMLKKEBOIFBMJLCECIIEKEDHAA.tom@kednos.com>      -----Original Message-----2   From: Barry Treahy, Jr. [mailto:Treahy@MMaz.com]'   Sent: Tuesday, June 29, 2004 11:13 AM6   To: Info-VAX@Mvb.Saic.Come   Subject: Re: VAX Spare Parts       Tom Linden wrote:h     >  -----Original Message-----75   >  From: Barry Treahy, Jr. [mailto:Treahy@MMaz.com]S*   >  Sent: Tuesday, June 29, 2004 10:10 AM   >  To: Info-VAX@Mvb.Saic.Com!   >  Subject: Re: VAX Spare Partst   >    >    >  Keith Cayemberg wrote:n   >i   >  > Hi Jim,   >  >=   >  > here's just a "heads up" concerning a new VAX Servicesl   announcement at .   >  > OpenVMS.org by NEMONIX Engineering,Inc.   >  >)   >  > In this announcement they state...b   >  >K   >  > "NEMONIX is targeting operators of the nearly _175,000 VAX machines_tE   >  > still in operation in the United States alone  computers thattC   >  > continue to power critical operations for companies across an   multitude    >  > of industries."   >  >%   >  > You can find the story here...e   >  >I   >  > *NEMONIX Launches Custom Engineering Services and VAX HotLine Siteh   >  > Support*i@   >  > http://www.openvms.org/stories.php?story=04/06/28/6005658   >  >C   >  Too bad they weren't more interested in being reasonable abouts   the priceiH   >  of their upgrade solutions.  I, for one, knocked on their door manyB   >  times over the past five years, prior to moving completely toK   >  CHARON-VAX.  In all candor, I'm glad they wouldn't negotiate because IuH   >  would feel it was money wasted today, now that I have CHARON-VAX...   >u@   >FWIW, I have 7.3 installed on another emulator on a P3 500MHz   and I ran then   >PL/IhJ   >benchmark tests and it compared to a 4000/90.  Now I am curious what it   >would do-   >on a quad Opteron Tyan.   >,   >u   >4E   Can't answer that as I only have a P4/HT @ 3.4Ghz and a Dual Athlon>H   MP2800+ system.  The first rates at about 63 VUPS, the second at aboutG   53 VUPS.  Do you have the pseudo-VUP calculator CALCULATE_VUPS.COM tok   run on your box?  L No, I don't.  Send me a copy if you have one, please.  The dozen or so tests I ranc excercise different aspectsa     Barryg     --  @   Barry Treahy, Jr                       E-mail: Treahy@MMaz.com@   Midwest Microwave                          Phone: 480/314-1320@   Vice President & CIO                         FAX: 480/661-7028         ---r(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ---o& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.710 / Virus Database: 466 - Release Date: 6/23/2004   ------------------------------  + Date: Tue, 29 Jun 2004 17:58:36 +0000 (UTC).6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)Y Subject: Re: Volume shadowing between FC Storage at different sites, and the allocation c 1 Message-ID: <newscache$in030i$d5r1$1@news.sil.at>   u In article <58ba0101.0406282348.c25df78@posting.google.com>, andrew.rycroft@intrinsitech.com (Andrew Rycroft) writes:oE >I have just connected to some Fibrechannel based storage from my VMSdG >system. I see all the devices as $1$DGAxxx. Even thought the ALLOCLASSs >parameter is 6 for the system.n  I Yup. The FC disks get all a $1$DGAuuuu and the FC tapes get a $2$MGAuuuu.5  E >This system will be in a cluster with a system at a remote site alsoDF >connected to FC storage, and I am sure I will also see the devices as >$1$DGAxxx.   " Of course, but this is no problem.  G >I want to use Volume Shadowing to mirror the two sites, but I am a bittC >concerned that because the allocation class is 1 for fibre channelt? >storage at both sites this may cause confusion for the clustere
 >software.  K You need to differentiate the disks by the name (and not by the alloclass).oG Common practices seems to be to use the HSG pair id in combination withVL the unit name of the virtual container of the HSG (HSGxxA> SET Dyy ID=xxyy).L This FC id then gets to $1$DGAxxyy (which you bind into a shadow set DSAzz).   -- V Peter "EPLAN" LANGSTOEGERd% Network and OpenVMS system specialistr E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  % Date: Tue, 29 Jun 2004 23:22:12 +0100 < From: "Alex Daniels" <AlexNOSPAMTHANKSDaniels@themail.co.uk>Y Subject: Re: Volume shadowing between FC Storage at different sites, and the allocation c25 Message-ID: <40e1eb95$0$4580$db0fefd9@news.zen.co.uk>   / "Lee" <lytmah@telusplanet.net> wrote in message_% news:LNdEc.37807$_5.23580@clgrps13....H > I have done multiple tests on these disks across a multi-site cluster.< > I was able to shadow $1$DGA disks with Storageworks $2$DUAD > disks (with the same number of blocks of course) with no problems.> > There was no difference in functionality of the two types of3 > physical disks or the mix of shadow sets created.d@ > Be warned that under current 7.3-1 VMS, any $1$/$1$ or $1$/$2$8 > shadow sets you create will undergo long shadow merges? > (5-12 hours) if any of your cluster nodes reboots or hiccups.  >u  D > disks (with the same number of blocks of course) with no problems.   Doesn't have to be on 7.3-2e  ? > (5-12 hours) if any of your cluster nodes reboots or hiccups.k  H Not on my boxes with Host Based Mini Merge, make that under 5 seconds...   Regards    Alex   ------------------------------    Date: 29 Jun 2004 18:22:18 -07001 From: keithparris_NOSPAM@yahoo.com (Keith Parris) Y Subject: Re: Volume shadowing between FC Storage at different sites, and the allocation cv= Message-ID: <cf15391e.0406291722.56161e70@posting.google.com>-  s Michael Austin <maustin@firstdbasource.com> wrote in message news:<jViEc.4838$Cv4.24@newssvr23.news.prodigy.com>...lI > Or, you use the EVA technology and utilize Business copy to "replicate" G > the entire EVA.  The XP series (rebranded Hitachi) also has this sort2F > of long-distance update and removes the overhead from the system andI > gives it back to the storage controller where it belongs in either syncy > or async modes...   A Controller-based replication is often the only or best (simplest)iE solution for disaster tolerance for platforms without much clusteringr@ capability, like Windows or Linux/UNIX. It's intuitively easy toB understand, and well-marketed by several companies (including HP).  C But in actual practice, most OpenVMS customers today use host-based C volume shadowing for disaster tolerance instead of controller-basedo replication, because of:' 1) Automatic failover instead of manualoD 2) Much faster failover (mere seconds instead of minutes to an hour)A 3) Access to the data from both sites instead of through only oneV controller at a timeC 4) Ability to actively run applications at both sites at once, withxB disk updates replicated in both directions at once, simultaneouslyA 5) Inter-site link costs. Most controller-based solutions requirejD either a separate Fibre Channel link between sites (in addition to aF LAN link for SCS traffic), or a set of boxes from CNT, SAN Valley, SANC Castle, Nishan, etc. to bridge Fibre Channel over a network of somee< sort. This may increase inter-site link costs significantly,! particularly at longer distances.R@ 6) Licensing costs: CA licenses may cost more than HBVS licenses  F The host overhead issue seems to mostly be a red herring -- when folks@ say that host-based RAID has high overhead, it's RAID-5 with ECC> calculations that fits that description, not host-based RAID-1 (shadowing or mirroring).m  D One could argue that MSCP-serving of disks at a remote site adds CPUC overhead, but one can eliminate that with the same inter-site FibreeC Channel link capability that one HAS to have for a controller-basedpE replication scheme, so that doesn't seem like a good argument either.e  D What I recommend is that folks determine their business requirementsE first, then choose the technology which best fits those requirements,e0 rather than choosing a favored technology first.  D Using HBVS, folks can achieve a Recovery Point Objective (data loss)F of zero, and a Recovery Time Objective (downtime) of a temporary pauseD of a small number of seconds. With controller-based replication, you? can achieve zero RPO with synchronous replication (asynchronoussE replication implies some amount of data loss risk in conjunction with,D a site failure, and thus a non-zero value for RPO); and depending onB how well you can script the failover activities, you can achieve aD best-case RTO of some number of minutes to as much as an hour or so.F (And whether or not one cares about these differences depends strongly5 on the actual business requirements for RPO and RTO.)m  ? Controller-based replication can have an advantage at very longt> distances (like 1,000s of miles), where it can do asynchronousA replication with smaller inter-site link bandwidths than would be F required for HBVS, and at distances above the officially-supported 500C miles in a VMS cluster. (But this is only an option if the businesseD can survive a non-zero RPO (data loss), of course.) And on the otherD hand, HBVS has reportedly been shown in the lab to hang together andF work correctly (albeit with increasingly reduced performance at longerA distances) to a simulated distance of about 1/6 of the way to the C moon, over the same Fibre-Channel-over-IP SAN Valley boxes that onen' might use for CA at extended distances.    ------------------------------  # Date: Wed, 30 Jun 2004 03:08:57 GMTa" From: Lee <lytmah@telusplanet.net>Y Subject: Re: Volume shadowing between FC Storage at different sites, and the allocation c2+ Message-ID: <d9qEc.38935$_5.34118@clgrps13>e  ( We're waiting for the retro-patches for:(    - shadowing of dissimilar-sized disks    - Host Based Mini Merge.O When did you receive HBMM?     Alex Daniels wrote:a1 > "Lee" <lytmah@telusplanet.net> wrote in message ' > news:LNdEc.37807$_5.23580@clgrps13...n > H >>I have done multiple tests on these disks across a multi-site cluster.< >>I was able to shadow $1$DGA disks with Storageworks $2$DUAD >>disks (with the same number of blocks of course) with no problems.> >>There was no difference in functionality of the two types of3 >>physical disks or the mix of shadow sets created.>@ >>Be warned that under current 7.3-1 VMS, any $1$/$1$ or $1$/$2$8 >>shadow sets you create will undergo long shadow merges? >>(5-12 hours) if any of your cluster nodes reboots or hiccups.h >> >  > D >>disks (with the same number of blocks of course) with no problems. >  >  > Doesn't have to be on 7.3-2a >  > ? >>(5-12 hours) if any of your cluster nodes reboots or hiccups.s >  > J > Not on my boxes with Host Based Mini Merge, make that under 5 seconds... > 	 > Regardsp >  > Alex >  >    ------------------------------  # Date: Tue, 29 Jun 2004 18:54:07 GMT 1 From: Michael Austin <maustin@firstdbasource.com>hY Subject: Re: Volume shadowing between FC Storage at different sites, and the allocation ct: Message-ID: <jViEc.4838$Cv4.24@newssvr23.news.prodigy.com>   >  > Andrew Rycroft wrote:o >  >> Hi, >>G >> I have just connected to some Fibrechannel based storage from my VMS0I >> system. I see all the devices as $1$DGAxxx. Even thought the ALLOCLASS ! >> parameter is 6 for the system.e >>G >> This system will be in a cluster with a system at a remote site alsoaH >> connected to FC storage, and I am sure I will also see the devices as
 >> $1$DGAxxx.e >>I >> I want to use Volume Shadowing to mirror the two sites, but I am a biteE >> concerned that because the allocation class is 1 for fibre channel A >> storage at both sites this may cause confusion for the cluster  >> software. >>F >> If anybody else has done this or has suggestions I would appreciate >> the feedback. >> >> With regards 	 >> Andrew  > 
 Lee wrote:  H > I have done multiple tests on these disks across a multi-site cluster.< > I was able to shadow $1$DGA disks with Storageworks $2$DUAD > disks (with the same number of blocks of course) with no problems.> > There was no difference in functionality of the two types of3 > physical disks or the mix of shadow sets created..@ > Be warned that under current 7.3-1 VMS, any $1$/$1$ or $1$/$2$8 > shadow sets you create will undergo long shadow merges? > (5-12 hours) if any of your cluster nodes reboots or hiccups.n >   G Or, you use the EVA technology and utilize Business copy to "replicate"-E the entire EVA.  The XP series (rebranded Hitachi) also has this sortmD of long-distance update and removes the overhead from the system andG gives it back to the storage controller where it belongs in either syncn or async modes...    Michael Austin.o   ------------------------------   End of INFO-VAX 2004.358 ************************was the attraction of Itanic?  > J HP would be paid (off) by Intel to move all their OSes to it, and HP couldL shut down CPU chip development too.  As the recipient of a sizeable chunk ofH that five billion it made good sense to HP.  Plus, if it goes wrong theyI dump Intel and switch to AMD, all the bases covered.  No Dell lockin type 3 agreements leaving them in a perfo}XU\mX6ѨtFf1ö;CyzNS<y[h=@WE=}fbbSC
0}KMpy`Xw7m>I«6E|(xWVKڣMjW#G8>l.nyu@k`ԎR7[J=M:#c
f[,*ebH˹s6@nf'2l(IR=Ja--*f5˽~aڞ/=@u);$p	$Ӳ84]6=J$Ts-
Dfk@FF+:I+?_.۰֒rJb=}z&	1GK=J-<8sqV=}L7ȑ-vpps׳n`1\)h=J$/'/̀
;֢>&Of.	`=JPx9v=J^j/