1 INFO-VAX	Fri, 24 Feb 2006	Volume 2006 : Issue 109       Contents:" Re: "A Historical Look at the VAX"P Re: =?ISO-8859-1?Q?R=E9f=E9rences_de_OVMS_en_Suisse_=28?= =?ISO-8859-1?Q?_romand Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: AMD blew it big time!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor!  Re: Boy, do I like VMS humor! ! Re: Can VMS make files immutable? " Re: Entry-level Integrity Servers?K Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!) K Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!) K Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!) P Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!) leve% Re: Itanium still not on alpha level! % Re: Itanium still not on alpha level! M Re: New Features, Product Information?  (Was: Entry-level Integrity Servers?) , Re: object names from executable image files, Re: object names from executable image files, Re: object names from executable image files, Re: object names from executable image files, Re: OpenVMS proves superior to all other OSs, Re: OpenVMS proves superior to all other OSs, Re: OpenVMS proves superior to all other OSs Re: save_set on DVD  Re: save_set on DVD  save_set on DVD  Re: save_set on DVD  Re: save_set on DVD  Re: save_set on DVD  Re: save_set on DVD 2 Secure purchases now available at Island Computers, Windows XP inner workings revealed publicly.0 Re: Windows XP inner workings revealed publicly.0 Re: Windows XP inner workings revealed publicly.  F ----------------------------------------------------------------------    Date: 24 Feb 2006 00:20:47 -06002 From: "Dave Weatherall" <djw-nothere@nospam.nohow>+ Subject: Re: "A Historical Look at the VAX" ? Message-ID: <DTiotGxQ0bj6-pn2-HdNJTF8vTwsD@dave2_os2.home.ours>   E On Wed, 22 Feb 2006 16:31:56 UTC, nothome@spammers.are.scum (Malcolm   Dunnett) wrote:   A > In article <DTiotGxQ0bj6-pn2-YzVWq5MdeDbc@dave2_os2.home.ours>, 9 >    "Dave Weatherall" <djw-nothere@nospam.nohow> writes:  > I > >> time.  I suspect that is the FCS vs RMS difference mentioned.  If I  H > >> recall correctly RSX-11M-Plus came standard with the indexed files L > >> capability.  But it was a lot more expensive and needed more resources  > >> than we had available.  > > J > > ISTR wanting to try it on an 11/60 but was a little memory constrained > > :-)  > >  > L >     I hope I'm allowed to mention RSTS ( most old-time VMS folks here seemK > to have come from the RSX world ). I recall RSTS having RMS indexed files ) > which we used extensively with BASIC+2.  > H >     Task builds were a thing of terror, often taking 10-15 minutes (onI > an 11/40 ) only to find you'd run out of memory and had to find an even I > more creative way to edit ones overlay tree ( or split your source code G > into smaller modules ). I spent a lot of hours poring over map files.   E Ah the joys of ODL. Memory and and disk-mapped overlays. What fun :-)    --   Cheers - Dave W.   ------------------------------  # Date: Fri, 24 Feb 2006 04:03:21 GMT   From: John Santos <john@egh.com>Y Subject: Re: =?ISO-8859-1?Q?R=E9f=E9rences_de_OVMS_en_Suisse_=28?= =?ISO-8859-1?Q?_romand , Message-ID: <dAvLf.29320$gh4.12676@trnddc06>   noone wrote: > Michel HERRSCHER wrote:  >  >> Bonjour,  >>G >> Pour prouver  un de mes prospects que VMS est loin d'tre mort, je  ; >> dois lui donner qq ref de VMS  actifs en CH (F), ou (D).  >>K >> Quel harware ( Vax, Alpha, Itanium) ( autre via CHAROn ou quivalent ) ?  >>3 >> Si BD prsente laquelle ( RDB, Oracle autre...)?  >>< >> Me prciser si je peux citer le nom de la socit ou pas) >> >> Merci de votre aide >> --  >> Michel HERRSCHER CONSULTANT >> >> >   > rough translation from Google: > J > "Hello, to prove with one my prospective customers that VMS is far from I > to have died, I must give him qq ref. of active VMS in CH (F), or (D).    B I believe CH refers to Switzerland, and (F) or (D) means French or< German.  (I.e. he is seeking French or German-speaking Swiss references.)    K > Which harware (VAX, Alpha, Itanium) (other via CHAROn or equivalent)? If  K > data base presents which (RDB, different Oracle...)?  To specify me if I  F > can quote the name of the company or not) Merci for your assistance" >   = Google doesn't know "Merci" (Thank you)?  It is one the words ( taught in your very first French lesson.    H > You may be able to contact your local HP representative to be able to % > giver you some of this information.  >  > and a Google translation:  > Traduction de Google: J > "Vous pouvez pouvoir entrer en contact avec votre reprsentant local de A > HP pour pouvoir en mesure au donateur vous une partie de cette   > information."  >  >      --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 23 Feb 2006 15:33:14 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: AMD blew it big time!, Message-ID: <43FE1C0A.BDD3648C@teksavvy.com>   bob@instantwhip.com wrote:I > for their oopsterons would suffice, but eventually it will run into the ' > x86 boat anchor performance wall ...     Bob, Bob, Bob...  F Never underestimate a competitor. Yeah, there is plenty to laugh aboutH the 8086's life. But in the end, the predictions that it had reached itsF architectural limits were proven wrong because both Intel and AMD wereE able to scale the 8086 into enterprise level systems with performance T that is not to sneeze at and at a price you can't beat because there is competition.  F And because the volumes are so high, Intel and AMD can afford to spendA the big bucks to support 8086 instructions onto modern machines.    G It isn't Alpha , Power or Sparc that will sign IA64's death warrant, it E will be the 8086. And don't sneeze at the 8086 because in the end, it B may be the very thing which saves VMS from oblivion and gives it a! chance to expand its marketplace.    ------------------------------  % Date: Thu, 23 Feb 2006 15:50:39 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: AMD blew it big time!, Message-ID: <43FE201E.4E8AFE81@teksavvy.com>   bob@instantwhip.com wrote: > G > no x86 emulated processor will ever run the high end as well as alpha  > does.   G Nobody is debating that Alpha has a superior instruction set that leads   to better implementation tricks.  G However, the 8086 toy controller has a simple enough instruction set to G allow many of those tricks to be applied and it has proven itself to be H a worthy adversary. And with Alpha out fo the picture, Power will be theC high end processor, with Sparc as a sidelined one, and 8086 will be H mainstream. Improvements to the 8086 will come not only from competition6 against Power, but also against itself (AMD vs Intel).  F Improvements go where there is money to be made. So the money is going to the 8086 development.   ------------------------------  % Date: Thu, 23 Feb 2006 14:12:45 -0700 6 From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>" Subject: Re: AMD blew it big time!/ Message-ID: <KypLf.47$qR3.1351@news.uswest.net>      K And the Alpha can't run over 90% of commercial software on the market.  The G Opteron can.  Without a software base, the Alpha processors are a niche I market.  Both Intel and AMD have learned a lot about processor design and L engineering from the Alpha and they have incorporated those lessons, thereby$ improving their own processor lines.  H High performance Linux clusters, which by the way, are becoming more andE more common, are based on the X86 architecture, so I doubt that X86's F performance future is that limited.  Your argument sounds like the oldF "RISC" (Reduced Instruction Set Computing, aka PowerPC) is better thanK "CISC" (Complex Instruction Set Computing, aka Intel) argument.  Anyone who K has watched the processor development should realize that the best features H of RISC technology has been incorporated into the X86 processors.  TheseL processors are RISC internally but with high powered instruction decoders onA the front end to support a CISC instruction set.  This merging of I technologies has allowed the processors themselves to be highly optimized J for throughput while keeping the binary image size of programs written forC them about half the size of the same programs written for pure RISC  processors.   K As an aside, why would anyone want to run a Beta copy of Windows 2000?  The H Release To Manufactoring version has had 4 major upgrades in the form of3 service packs and several dozen patches since SP 4.   
 Mike Ober.  & <bob@instantwhip.com> wrote in message< news:1140717990.943345.24660@g14g2000cwa.googlegroups.com...G > no x86 emulated processor will ever run the high end as well as alpha  > does.  > D > I said AMD could still have their x86 64 bit emulator chip for the > massesB > who feel trapped on x86 but could have still beat IBM, Intel and
 > everyone* > else also in the high end with alpha ... > I > and by the way, alpha runs windoze 2000 ... I know where to get you the  > beta 3 CD if you want one ...  >  >    ------------------------------  % Date: Thu, 23 Feb 2006 14:14:59 -0700 6 From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>" Subject: Re: AMD blew it big time!/ Message-ID: <PApLf.49$qR3.1493@news.uswest.net>      K Probably was.  VAX/VMS was a threat to the PDP-11/TOPS-20 OS and there were H a lot of people inside DEC who were emotionally committed to the PDP-11.   Mike  : "William Webb" <william.w.webb@gmail.com> wrote in messageC news:8660a3a10602230946v566dcd00s4bed092cc9f0f1c8@mail.gmail.com... A On 2/23/06, Michael D. Ober <obermd.@.alum.mit.edu.nospam> wrote:  >    {SNIP}  " > VMS has been marginalized in theE > market by over three decades of marketing neglect by DEC/Compaq/HP.   ! VMS 1.0 release date was in 1978.   E So I guess that VMS marginalization began even before it was released  on the market.   WWWebb   --C NOTE: This email address is only used for noncommerical VMS-related  correspondence. C All unsolicited commercial email will be deemed to be a request for 8 services pursuant to the terms and conditions located at# http://bellsouthpwp.net/w/e/webbww/    ------------------------------    Date: 23 Feb 2006 16:38:10 -0800 From: bob@instantwhip.com " Subject: Re: AMD blew it big time!B Message-ID: <1140741490.868409.83820@u72g2000cwu.googlegroups.com>  / so you are saying their is patent infringement?   = I also didn't know that there were 4 more releases of windoze  2000 for the alpha ...   ------------------------------  % Date: Fri, 24 Feb 2006 00:06:33 -0500 ( From: Bill Todd <billtodd@metrocast.net>" Subject: Re: AMD blew it big time!= Message-ID: <Ko2dndSjMITBCWPeRVn-pA@metrocastcablevision.com>    Michael D. Ober wrote: >   M > Probably was.  VAX/VMS was a threat to the PDP-11/TOPS-20 OS and there were J > a lot of people inside DEC who were emotionally committed to the PDP-11.  I You really should stop blowing smoke out of your ass:  it just makes you   look stupid.  H There was indeed some less-than-friendly rivalry between the 36-bitters E and VAX/VMS, but any rivalry between the PDP-11 and VMS was amicable  F (well, the RSTS people were frustrated that VMS wouldn't adopt a more G RSTS-like upgrade path for their users, but that didn't mean that they  & failed to appreciate VMS's strengths).  = Those of us working on the 11 were all too well aware of its  I address-space limitations:  while working within them was in some ways a  E pleasurable challenge, three was no question whatsoever that a wider  I architecture would be required to remain competitive by the beginning of  G the '80s if not before - and VAX/VMS was a far more compatible upgrade  < path for 11 users than the 36-bit platforms would have been.  F So while one can argue (as I did at the time) that DEC may have wound B down 16- (and perhaps even more so 36-) bit development a bit too G quickly (DEC was arguably large and strong enough to have pursued them  E for a while longer along with VAX, and the fact was that VAX was not  H able to take up the slack in a cost-effective - with respect to the 11s E - and a performance-effective - with respect to the 36-bit systems -  H manner as soon as the DEC transition would have had it do so), the idea B that people in the 11 world were actively sabotaging it is absurd.   - bill   ------------------------------    Date: 23 Feb 2006 14:33:22 -0800) From: "Ken Robinson" <kenrbnsn@gmail.com> & Subject: Re: Boy, do I like VMS humor!C Message-ID: <1140734002.167052.136880@e56g2000cwe.googlegroups.com>    Larry Kilgallen wrote:H > Square dance teachers say to put your hands in front of you with palmsF > down and thumbs extended.  The one that looks like the letter "L" is > the Left.   : Of course that doesn't help anyone with two left feet. :-)   To keep on topic ...  G I am reading the V8.2 New Features Manual and in the section on Updates D to DCL Commands and DCL Documentation, there is this entry for "SHOW PROCESS" -- D "New /CASE_LOOKUP and /TOKEN qualifiers; revised example for Red Sox fans."   Ken    ------------------------------  + Date: Fri, 24 Feb 2006 00:52:11 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) & Subject: Re: Boy, do I like VMS humor!( Message-ID: <dtllbr$r1g$1@pcls4.std.com>  F Hmmm, maybe there really is some truth to the rumors of the secret VMS8 porting project taking place in the dungeons of ZK03....  " $ write sys$output f$message(3244)   (probably only works on V8.2)   G Also slightly humorous are the IDENTIFICATION fields of f$message(4050)  and f$message(4090).   ------------------------------  % Date: Thu, 23 Feb 2006 20:04:41 -0500 % From: BRAD <bradhamilton@comcast.net> & Subject: Re: Boy, do I like VMS humor!* Message-ID: <43FE5BA9.8030405@comcast.net>   Michael Moroney wrote:H > Hmmm, maybe there really is some truth to the rumors of the secret VMS: > porting project taking place in the dungeons of ZK03.... > $ > $ write sys$output f$message(3244)   On VMS V7.3-2:  write sys$output f$message(3244)H %SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW, 
 PC=!XH,PS=!XL    ------------------------------  % Date: Thu, 23 Feb 2006 20:19:36 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> & Subject: Re: Boy, do I like VMS humor!, Message-ID: <43FE5F14.1283F43D@teksavvy.com>   BRAD wrote:  > On VMS V7.3-2:" > write sys$output f$message(3244)I > %SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW,  > PC=!XH,PS=!XL    Doesn't work on VAX though...   I And on Alpha, HELP/MESSAGE doesn't find any text to explain this message.    ------------------------------  % Date: Thu, 23 Feb 2006 20:59:46 -0500 % From: BRAD <bradhamilton@comcast.net> & Subject: Re: Boy, do I like VMS humor!* Message-ID: <43FE6892.8090005@comcast.net>   JF Mezei wrote: 
 > BRAD wrote:  >  >>On VMS V7.3-2:" >>write sys$output f$message(3244)I >>%SYSTEM-F-IA32_TRAP, IA-32 trap, reason_mask=!XW, vector=!XB, code=!XW,  >>PC=!XH,PS=!XL  >  >  > Doesn't work on VAX though...  > K > And on Alpha, HELP/MESSAGE doesn't find any text to explain this message.  >   C Perhaps an example of "latent support"	:-)	Any comment from hp?	:-)    ------------------------------    Date: 23 Feb 2006 21:56:31 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) * Subject: Re: Can VMS make files immutable?3 Message-ID: <9536qq1+9QE6@eisner.encompasserve.org>   c In article <11vsu3l7bh0ep9f@corp.supernews.com>, Glenn and Mary Everhart <everhart@gce.com> writes: ( > Re making a file "immutable" in VMS... > = > If he at least recompiles Safety (on VMS SIG tapes c. 2000) > > it will allow this. It can prevent access by anyone desired,> > or if desired can block access by processes with extra privsA > while allowing it to the peons who have only netmbx and tmpmbx. A > I replied to the guy via email already, will try to post later.   C Certainly it cannot defend against suitable programming with Change  Mode To Kernel.    ------------------------------  # Date: Fri, 24 Feb 2006 00:06:39 GMT % From: Rick Jones <rick.jones2@hp.com> + Subject: Re: Entry-level Integrity Servers? 1 Message-ID: <j6sLf.3614$wk5.496@news.cpqcorp.net>   $ Hoff Hoffman <hoff@hp.nospam> wrote:? >   The entry-level Integrity rx1620 series server is currently F >   capable of dual-processor operations, but I expect you can acquire! >   a uniprocessor configuration.   C Indeed, the rx1620 is a two socket system, which can be bought with . just one socket filled with a single-core CPU.   http://www.hp.com/go/rx1620    The rx2620 is similar.  
 rick jones --  D The glass is neither half-empty nor half-full. The glass has a leak.) The real question is "Can it be patched?" F these opinions are mine, all mine; HP might not want them anyway... :)D feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...   ------------------------------  # Date: Thu, 23 Feb 2006 21:44:39 GMT # From: hoff@hp.nospam (Hoff Hoffman) T Subject: Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!)2 Message-ID: <b1qLf.3595$Cd5.3476@news.cpqcorp.net>  _ In article <1140718230.280546.134340@v46g2000cwv.googlegroups.com>, bob@instantwhip.com writes: = :what about a single cpu box?  will there still be single cpu : :itaniums available in a few years?  doesn't sound like it
 :to me ...  E   What are your particular application or business requirements here?   H   If you have a particular requirement for a uniprocessor configuration,H   I expect that something might well be worked out to meet your specificC   requirements, whether through hardware or licensing or otherwise.   H   The entry-level Integrity rx1620 series server is currently capable ofH   dual-processor operations, but I expect you can acquire a uniprocessor   configuration.  H   As for performance (part of the discussion earlier in the thread), theF   first-generation Integrity rx2600 server that I work with is on par F   with and is usually faster than the EV67-class AlphaStation system I   work with.  F   As for futures, I am not in a particular position to discuss productH   futures for either Intel or for HP.  For the available discussions of J   the current and of upcoming platform plans for OpenVMS Alpha and OpenVMSH   I64 and for the current entry-class, mid-range and high-end Integrity I   servers, the websites and the OpenVMS roadmap have the available public 
   details:      <http://www.hp.com/go/openvms>"   <http://www.hp.com/go/integrity>  G   There's a webcast coming up that might be of interest, with Mark Hurd G   and Paul Otellini (HP and Intel CEOs) -- the webcast is scheduled for    2-Mar-2006 at 08:30 PST.  D   The Intel Developer's Forum is also coming up, and I'd expect thatF   folks from Intel might be discussing their current product lines and8   potentially some of the plans for their product lines.  C   And for what OpenVMS Engineering is currently up to and currently 6   has planned, the bootcamp is coming up in May, 2006:  )   <http://www.hp.com/go/openvms/bootcamp>   N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  # Date: Thu, 23 Feb 2006 23:23:08 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) T Subject: Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!)L Message-ID: <rdeininger-2302061823060001@user-uinj4ma.dialup.mindspring.com>  5 In article <43FE22C5.F7B0313D@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:    >Hoff Hoffman wrote:K >>   If you have a particular requirement for a uniprocessor configuration, K >>   I expect that something might well be worked out to meet your specific F >>   requirements, whether through hardware or licensing or otherwise. >  >  ... nonsense omitted...     I >So, if you do not offer low or medium level systems whose information is I >easily found on the HP web site, potential customers aren't going to try & >to convince HP to build one for them.  J Information about all the Integrity systems is available on the web site. I That includes everything from single-processor rx1620 systems all the way  up to Superdomes.   H Just because a few people like to rant about the non-existance of stuff,% doesn't mean it really doesn't exist.   M HP still makes and sells single-CPU Integrity systems, and VMS supports them. 3 They are not particularly hard to find or purchase. < They are a lot less expensive than single-CPU Alpha systems.; They are significantly faster for almost every application.   G >VMS management must stop atering only to the installed base. They need I >leadership and the styrength to convince HP upper management to let them 0 >spend money on development and take some risks. > F >Will updating DECTERM only bring in tons of customers ? Probably not.G >But updating DECTERM, updating TPU, updating this , updating that will F >in the end put enough shine and gloss on VMS to pay off and bring the >new customers.   E If you think you can explain, without frothing at the mouth, why your I particular pet projects would bring in more VMS business (new or existing J customers) than the projects we are actually doing, go ahead and explain. J I'll just note that real customers with real needs spending real money are* driving the development trade-offs in VMS.  H Up to now, you've struck me as almost totally unqualified to gripe aboutG VMS on Itanium, as I've never seen a shred of evidence that you've ever 4 taken advantage of the many opportunities to try it.   ------------------------------    Date: 23 Feb 2006 16:52:41 -0800 From: bob@instantwhip.com T Subject: Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!)C Message-ID: <1140742361.173292.140340@u72g2000cwu.googlegroups.com>   A have you been locked up with Fred?  Go back 20 years and remember C all of the pdp mini computer and microvax environments ... remember ? dibol and mcba accounting software ... there were many software A packages for these small business systems ... and you have thrown C away alot of that business over the years and even now ignoring the E small and medium end and just thinking big iron ... we need 1p prices E in the future alos, not just now!  i hear no plans beyond the rx1620,  but E heard intel say that itanium was for big tin ... DEC was built on not  justA big tin customers, but on microvax and pdp11 small workgroups ... B these are still in existence even though DEC and compaq and now HPD forgot all about them ... no wonder all three of these companies are@ doomed to fail, you still don't understand your own user base!!!   ------------------------------  % Date: Thu, 23 Feb 2006 16:02:00 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Y Subject: Re: Entry-level Integrity Servers? (was: Itanium still not on alpha level!) leve , Message-ID: <43FE22C5.F7B0313D@teksavvy.com>   Hoff Hoffman wrote: J >   If you have a particular requirement for a uniprocessor configuration,J >   I expect that something might well be worked out to meet your specificE >   requirements, whether through hardware or licensing or otherwise.     F You need a reality check. Consider that existing customers have a hardE enough time getting the time of day from HP on VMS related issues. Do C you really think that some potential customer will use artillery to = break the brick wakll that separates potential customers from D knowledgeable VMS people within HP ? NOP. He'll simply look at other; competing products if he can't easily find the information.   H So, if you do not offer low or medium level systems whose information isH easily found on the HP web site, potential customers aren't going to try% to convince HP to build one for them.     F VMS management must stop atering only to the installed base. They needH leadership and the styrength to convince HP upper management to let them/ spend money on development and take some risks.   E Will updating DECTERM only bring in tons of customers ? Probably not. F But updating DECTERM, updating TPU, updating this , updating that willE in the end put enough shine and gloss on VMS to pay off and bring the  new customers.   ------------------------------  % Date: Thu, 23 Feb 2006 14:17:02 -0700 6 From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>. Subject: Re: Itanium still not on alpha level!/ Message-ID: <JCpLf.50$qR3.1203@news.uswest.net>      
 Hear Hear.  
 Mike Ober.  , "noone" <noone@nowhere.com> wrote in message7 news:PonLf.34241$Jd.29705@newssvr25.news.prodigy.net...  > bob@instantwhip.com wrote:J > > that is from 5 year old alpha technology ... just think where EV79 andH > > EV8 would have put alpha ... the results would have been drastically7 > > different ... not bad for 5 year old technology ...  > >  >  > D > I am in no way a nay-sayer when it comes to Alpha and OpenVMS, butG > 'bob', give it a rest.  you have been beating this dead horse for way G > too many years. it is a "done deal" and no amount of whining from any  > user community will fix that.  > I > We all know that VAX, Alpha and OpenVMS are the best, but we do have to H > move on. I liked the Amiga, it is dead and gone too... People who likeA > the MAC are going to need to realize that Intel will now be the H > processor of choice and are going to have to move on.  we just have toH > bury it and get on with our lives.  some of us get to continue workingJ > with OpenVMS, some of us have to face reality and learn new technologiesJ > and just take solice in knowing that most of the technology we use todayA > would never have been possible were it not for Ken Olsen's DEC.  > F > If the morons on Wall Street could only get an inkling of the damageJ > they have caused in EVERY industries R&D, they would board a wooden boatB > and never set foot on dry land again.  there is very little trueJ > innovation in technology today because wall street wants a profit NOW... > What short-sited idiots. >    ------------------------------    Date: 23 Feb 2006 16:47:31 -0800 From: bob@instantwhip.com . Subject: Re: Itanium still not on alpha level!B Message-ID: <1140742051.624330.73030@i40g2000cwc.googlegroups.com>  A so everyone finally caught up to 5 year old technology Andrew ... @ if EV8 was out, all off the above would be struggling to compete, with it, and you know it coming from sun ...   ------------------------------  # Date: Thu, 23 Feb 2006 22:56:38 GMT # From: hoff@hp.nospam (Hoff Hoffman) V Subject: Re: New Features, Product Information?  (Was: Entry-level Integrity Servers?)1 Message-ID: <G4rLf.3600$dh5.131@news.cpqcorp.net>   \ In article <43FE22C5.F7B0313D@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: :Hoff Hoffman wrote:K :>   If you have a particular requirement for a uniprocessor configuration, K :>   I expect that something might well be worked out to meet your specific F :>   requirements, whether through hardware or licensing or otherwise. :  :  :You need a reality check.  /   Um, waiter?  My reality check, please?  :-)   *   Bullwinkle, that trick never works.  :-)  F :                         Consider that existing customers have a hardF :enough time getting the time of day from HP on VMS related issues. DoD :you really think that some potential customer will use artillery to> :break the brick wakll that separates potential customers fromE :knowledgeable VMS people within HP ? NOP. He'll simply look at other < :competing products if he can't easily find the information.  8   Here are some useful URLs relevent to this discussion:     http://www.hp.com/go/openvms/ #   http://www.hp.com/go/openvms/faq/ (   http://www.hp.com/go/openvms/bootcamp/!   http://www.hp.com/go/integrity/ '   http://www.hp.com/go/productbulletin/   @   It's been my experience that the feedback links at the website@   do work -- enough email lands in my mailbox from these -- that>   I'm certain that folks that want specific configurations canA   get to knowledgeable OpenVMS or Integrity folks.  And the folks =   can also get to the above information resources, obviously.   A   As for finding information, I maintain the FAQ specifically as  @   a way for folks to locate useful resources and tools -- to get(   access to answers to common questions.   ..    F :Will updating DECTERM only bring in tons of customers ? Probably not.G :But updating DECTERM, updating TPU, updating this , updating that will F :in the end put enough shine and gloss on VMS to pay off and bring the :new customers.   J   I'd not expect DECterm and TPU to be of interest outside of the existingJ   customer base, and while there are most certainly existing customers andI   OpenVMS components that depend on these, new work and new applications  H   tend to be based on GTK or other such graphics libraries, and at other>   such mechanisms and tools.  Not on DECterm or TPU or such.    G   As for new features and capabilities, I'm adding new support, as are  H   various other engineers.  We're working on what the partners want, andF   on what the customers want, of course -- on various of the customer G   requests that regularly arrive here in OpenVMS Engineering.  GTK, for H   instance (while discussing displays and display interfaces), and on a G   number of updates to libraries and tools, and various enhancements to    the base operating system.    F   Now if y'all will excuse me, the system I've been working on has nowF   finished its AUTOGEN and its subsequent reboot, and I can go figure    out what just happened. :-)     N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------    Date: 23 Feb 2006 14:48:34 -0800 From: bdhobbs18@acm.org 5 Subject: Re: object names from executable image files C Message-ID: <1140734914.159289.247020@p10g2000cwp.googlegroups.com>   ? The linker doesn't like an executable image file as input ... a 9 shareable maybe, but not an executable.  After a bunch of = %LINK-W-RECTYP and %LINK-W-SEQNCE messages, link aborted with  %SYSTEM-F-ACCVIO.   D I'm pretty sure that the info I want is in the executable, otherwiseD how would a COBOL call data-name work when the value in data-name is" assembled at run time.  Example atG http://h71000.www7.hp.com/doc/82final/6297/6297pro_090.html#callv .  It G seems that there is no method available to mere mortals to extract that  info from the executable.   @ I thought that analyze/image would be the command to give me theF information I'm looking for.  If I analyze/image a VAX image made fromD multiple objects, would the object names be displayed?  Is the extraE level of symbol reference on the Alpha preventing me from getting the  names?  A Hmmm ... looking at the link/map listing, I see there are several F psects containing the object names.  Is there a system routine(s) thatF can get a specified psect from an image file and list the entries?  IsD there any DECUS or unsupported software to do this?  I stumbled overG descriptions of GLOB and SYMBOLS at the DECUS site that may help, but I % can't seem to actually get the files.    ------------------------------  # Date: Fri, 24 Feb 2006 00:07:02 GMT # From: hoff@hp.nospam (Hoff Hoffman) 5 Subject: Re: object names from executable image files 2 Message-ID: <G6sLf.3615$295.1047@news.cpqcorp.net>  ] In article <1140648329.441495.186940@g47g2000cwa.googlegroups.com>, bdhobbs18@acm.org writes: H :I'm trying to figure out what programs are in use on my system and what :programs can be retired. ...   B :So, given an executable image file, how would one figure out what& :objects went into creating that file?  #   From the link map, most commonly.   @   The debugger needs to know the source file names involved, but@   images not built with debug tend to avoid storing this sort of	   detail.   C   Put another way, you cannot reliably determine what you want (the A   lists of objects that went into the image) from what is usually A   available (the various images) without the contents of the link A   maps that were (optionally) created when the images were built.   @   ANALYZE/IMAGE can tell you the structure of the image, and youA   can perform test DUMP operations with an image you are familiar B   with.  DUMP the image to a file, then search for substrings from@   the object module names.  You'll (not) find the information in   many of the images.   ?   If the images were built with debug, you can potentially look B   at the constituent files using the debug records, but it is very-   likely you will encounter non-debug images.   @   I'd buy a bigger disk, if this is strictly a storage question.  ?   If I were worried about neatness, I'd be looking at moving to >   a newer or faster system as part of the effort here, as what@   you are doing verges on a port -- and you might as well end up<   with a faster system, if you're going to expend the effort;   involved here.  (And just going to a newer system can get <   you various performance and capacity benefits, of course.)  >   But to target your requirements (and since you likely do not>   have linker maps), I'd tend to look at what built the images>   and I'd be taking a serious look at rebuilding the images I @   was using with current tools -- this helps with improved code B   generation, and it also helps ensure you have all of the source @   code and tools needed for the task of rebuilding.  I'd tend to@   go forward from source to images, and not backward from images   to source.  >   The aging of data is another issue entirely, of course, and @   there can be administrative or regulatory requirements around .   the preservation of or the disposal of data.  >   As for identifying images that are active, you can use image?   accounting (which generates reams of data) or security audits =   (on specific images of interest).  Enable the tracking, and A   wait.  There are other ways to get this information, of course, $   but these two are common choices.   ?   But getting back to the object modules and ultimately to the  ?   source code -- basically disassembly or reverse engineering,  =   depending on the context -- isn't necessarily an easy task.   =   If you DO have a debug symbol table, then the symbol table  ;   definitions are around -- if you have the OpenVMS source  =   listings, the definition file is something like DSTRECRDS.* =   (But it's going to be a chunk of work to try this approach, >   assuming you do have the information -- DUMP can help verify?   if the information is present in a typical image, of course.)   N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  # Date: Fri, 24 Feb 2006 00:18:01 GMT # From: hoff@hp.nospam (Hoff Hoffman) 5 Subject: Re: object names from executable image files 1 Message-ID: <ZgsLf.3618$295.966@news.cpqcorp.net>   ] In article <1140734914.159289.247020@p10g2000cwp.googlegroups.com>, bdhobbs18@acm.org writes:   E :I'm pretty sure that the info I want is in the executable, otherwise E :how would a COBOL call data-name work when the value in data-name is # :assembled at run time.  Example at B :http://h71000.www7.hp.com/doc/82final/6297/6297pro_090.html#callv     ps...   A   That's a list of symbols and the call chain.  Even that may be  @   optimized away, as it's not necessary for run-time operations.  @   The CALL to SUB, for instance, can be replaced by a CALLG to a@   relative or absolute address within an OpenVMS VAX environmentB   or the equivalent JSR magic within an OpenVMS Alpha environment.?   The SUB name gets replaced by its address, and information on B   the object is removed when the various sections of code and dataB   in the objects are sliced apart and reconstituted into the image   (program) sections.   A   Shareable images DO have external symbols and there can be some ?   image fix-ups that are required during image activation, but  ?   there is not necessarily a requirement that this information  <   be preserved outside of that and of similar contexts.  The?   linker tries to replace symbols with values, after all, as it .   is the values that can actually be executed.  B   Put another way, the linker accepts information from the objects@   and from the linker options files, and generates images -- theC   information that can be resolved during the link is replaced with >   the appropriate values, and only that (debug information, if=   requested, etc) which is requested or needed is propogated     through into the images.  <   Do see a LINK/FULL/MAP for some idea of what goes on here,>   and for how the various hunks of code and data are processed:   and re-organized into program sections, and prepared for:   execution.  And yes, do remember that ANALYZE/OBJECT and/   ANALYZE/IMAGE and DUMP are your friends here.       N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  % Date: Thu, 23 Feb 2006 19:45:32 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: object names from executable image files , Message-ID: <43FE5719.D9FC3CB1@teksavvy.com>   bdhobbs18@acm.org wrote:F > how would a COBOL call data-name work when the value in data-name is > assembled at run time.    E Actually, at run time, the image doesn't need to know the name of the 9 subroutines. Only the offset from the start of the image.   E The object files would contain the name of the subroutines and global F variables. The linker is the one that resolves everything to addressesF instead of subroutine names. And this includes sharaeable images whereH the linker finds the name of the surboutine and its offset from start of shareable image.    F There are instances where the name of a subroutine remains a name. YouE can use LIB$FIND_IMAGE_SYMBOL to give it a subroutine name and a file A name, and it will give you the address of that symbol (usually an D address of the entry point of a subroutine) after it has loaded that shareable image into memory.    " For shareable images. you can use     6 PIPE ANA/IMAGE filename.exe | search sys$input Symbol:  H That gives you a list of public symbols that a program can link against.   ------------------------------  # Date: Thu, 23 Feb 2006 23:01:27 GMT % From: Rob Brown <mylastname@gmcl.com> 5 Subject: Re: OpenVMS proves superior to all other OSs C Message-ID: <Pine.LNX.4.61.0602231600180.694@localhost.localdomain>   3 On Thu, 23 Feb 2006 VAXman-@SendSpamHere.ORG wrote:   7 > BTW, what was the greatest thing before sliced bread?    Unsliced bread.   : Wait.  Unsliced bread is better than sliced bread now too.   --    B Rob Brown                        b r o w n a t g m c l d o t c o mA G. Michaels Consulting Ltd.      (866)438-2101 (voice) toll free! 6 Edmonton                         (780)438-9343 (voice)5                                   (780)437-3367 (FAX) 2                                   http://gmcl.com/   ------------------------------    Date: 23 Feb 2006 16:42:24 -0800 From: bob@instantwhip.com 5 Subject: Re: OpenVMS proves superior to all other OSs A Message-ID: <1140741744.149938.7850@e56g2000cwe.googlegroups.com>   B well, if their are no decent terminal emulators, and no decwindows6 enhancements, and VT520 production shuts down like you& predict, how will anyone log onto vms?   ------------------------------  % Date: Thu, 23 Feb 2006 19:47:00 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 5 Subject: Re: OpenVMS proves superior to all other OSs , Message-ID: <43FE5772.22DB51E6@teksavvy.com>   Rob Brown wrote:< > Wait.  Unsliced bread is better than sliced bread now too.  F But it isn't very polite to grab the whole loaf of bread and just biteF into it (compared to slicing your own slice that you can then eat) :-)   ------------------------------  # Date: Thu, 23 Feb 2006 20:51:16 GMT " From:   VAXman-  @SendSpamHere.ORG Subject: Re: save_set on DVD0 Message-ID: <00A51C19.71D0FD2A@SendSpamHere.ORG>  M In article <K3pLf.397$PR1.60@fe07.lga>, "Dan Moore" <dmoore@sosu.edu> writes:  >  >  >Greetings,  > N >  I need a solution to write OpenVMS backup save_set's to DVD media and then 4 >access the files stored in the save_set by OpenVMS. > M >  We burned a DVD on a PC that had transfered a save_set via ftp (bin) from  H >a VMS (Alpha 7.3-1) system. VMS could see the save_set file on the DVD N >created by the PC (ISO 9660), but could not access files within the save_set K >(save_set/list). So we copied the save_set file directly to a disk on the  L >VMS system (from the DVD rom), and then corrected the file characteristics < >using OpenVMS. We were then able access the save_set files. > L >  Any suggestions on getting the PC out of the loop or at least preserving B >the save_set file characterisitic when burning the DVD on the PC?  G Assuming you are creating the backup saveset with its normal block size ' of 32,256, you can mount the DVD with :   8 $ MOUNT/OVER=ID/UNDEF=(FIXED:NONE:32256) dvd-device-name   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  # Date: Thu, 23 Feb 2006 20:53:00 GMT A From: "Colin Butcher" <colin_DOT.butcher_AT@xdelta_DOT.co_DOT.uk>  Subject: Re: save_set on DVD= Message-ID: <MgpLf.25449$wl.10870@text.news.blueyonder.co.uk>   - At least two alternatives present themselves:   J - ZIP the savesets (with the "-V" switch to preserve VMS file attributes),$ then burn the ZIP files to DVD / CD.  F - Copy the saveset onto a VMS LD device (see LDDRIVER) and burn the LD container file as an image.    --     Hope this helps, Colin. ) colin DOT butcher AT xdelta DOT co DOT uk E It's not mine, but I like this definition: Legacy = stuff that works.    ------------------------------  % Date: Thu, 23 Feb 2006 14:38:56 -0600 # From: "Dan Moore" <dmoore@sosu.edu>  Subject: save_set on DVD' Message-ID: <K3pLf.397$PR1.60@fe07.lga>   
 Greetings,  M   I need a solution to write OpenVMS backup save_set's to DVD media and then  3 access the files stored in the save_set by OpenVMS.   L   We burned a DVD on a PC that had transfered a save_set via ftp (bin) from G a VMS (Alpha 7.3-1) system. VMS could see the save_set file on the DVD  M created by the PC (ISO 9660), but could not access files within the save_set  J (save_set/list). So we copied the save_set file directly to a disk on the K VMS system (from the DVD rom), and then corrected the file characteristics  ; using OpenVMS. We were then able access the save_set files.   K   Any suggestions on getting the PC out of the loop or at least preserving  A the save_set file characterisitic when burning the DVD on the PC?    Thanks,   	 Dan Moore & Southeastern Oklahoma State University   ------------------------------  % Date: Thu, 23 Feb 2006 15:33:24 -0600 # From: "Dan Moore" <dmoore@sosu.edu>  Subject: Re: save_set on DVD% Message-ID: <OSpLf.38$IY4.7@fe06.lga>    >>L >>  Any suggestions on getting the PC out of the loop or at least preservingC >>the save_set file characterisitic when burning the DVD on the PC?  > I > Assuming you are creating the backup saveset with its normal block size ) > of 32,256, you can mount the DVD with :  > : > $ MOUNT/OVER=ID/UNDEF=(FIXED:NONE:32256) dvd-device-name >  > --  3 > VAXman- A Bored Certified VMS Kernel Mode Hacker   > VAXman(at)TMESIS(dot)COM     That did the trick. Thanks!   	 Dan Moore    ------------------------------  # Date: Thu, 23 Feb 2006 22:39:05 GMT # From: hoff@hp.nospam (Hoff Hoffman)  Subject: Re: save_set on DVD2 Message-ID: <dQqLf.3598$dh5.2842@news.cpqcorp.net>  M In article <K3pLf.397$PR1.60@fe07.lga>, "Dan Moore" <dmoore@sosu.edu> writes:   N :  I need a solution to write OpenVMS backup save_set's to DVD media and then 4 :access the files stored in the save_set by OpenVMS. : M :  We burned a DVD on a PC that had transfered a save_set via ftp (bin) from  H :a VMS (Alpha 7.3-1) system. VMS could see the save_set file on the DVD N :created by the PC (ISO 9660), but could not access files within the save_set K :(save_set/list). So we copied the save_set file directly to a disk on the  L :VMS system (from the DVD rom), and then corrected the file characteristics < :using OpenVMS. We were then able access the save_set files.  A   I am guessing that BACKUP reported various saveset corruptions.   C   You can variously salvage file attributes using the MOUNT command C   qualifier /UNDEFINED_FAT.  Using that, you can potentially set up B   the file attributes appropriately for a BACKUP saveset.   That'sA   usually fixed records, and with a record size from whatever was    used for the BACKUP saveset.  L :  Any suggestions on getting the PC out of the loop or at least preserving B :the save_set file characterisitic when burning the DVD on the PC?  ?   Larry Kilgallen has tools that write attributes onto ISO-9660 <   disks, as I recall.  (www.ljk.com)  This lets you have the)   attributes set when the disk is burned.   A   The external field test of OpenVMS V8.3 has DVD+R/RW recording  >   support, and the V8.3 field test is just starting -- there's=   information on the SDK coming out through various channels, @   and I've seen a copy posted over at www.openvms.org.  (For theB   folks in that, there is a parallel test of the recording tools.)  =   There are other DVD recording tools around for OpenVMS, and >   these are listed in the OpenVMS FAQ -- there are open source!   tools, and commercial packages.   >   Here, I'd probably generate a disk image using LD -- get the@   V8.0 or V8.1 kit off the OpenVMS Freeware site, or the current>   LD ECO kit -- and then dismount and disconnect the LD device?   from its backing storage, and I'd then transfer the file over ;   to the PC for a raw/binary/block/ISO burn.  ("ISO" can be A   somewhat ambiguous, where some folks and some tools can assume  @   that means the ISO-9660 volume structure is involved, and some?   can assume a block-oriented burn.  I'm refering to the latter 
   case here.)   C   With LD, you can use INITIALIZE normally, and set up the contents C   of an ODS-2 or ODS-5 disk, COPY in the saveset, and -- when this  B   file or this LD device is eventually transfered to CD-R/RW or toC   DVD+R/RW media, OpenVMS and specifically BACKUP can directly read /   the volume structure and the file attributes.   >   Ask The Wizard (9820) has a fairly detailed write-up on this=   sort of thing, and there is rather more detail (and what is >   effectively a newer version of (9820) going into the OpenVMS
   manuals.  N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------G        Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[\0100]hp.com    ------------------------------  % Date: Thu, 23 Feb 2006 21:35:34 -0500 7 From: "Tom Simpson" <thomas.simpson1@fubar.comcast.net>  Subject: Re: save_set on DVD: Message-ID: <9uudnQsrbZll7WPenZ2dnUVZ_tmdnZ2d@comcast.com>  K I burn directly to DVD using Eberhard Heuser-Hofmann's DVDwrite driver.  I  K have a procedure that zips files to the LD disk everyday and when the disk  I is full (about every 3 days) it initiates the DVD burn.  It's completely  M automated and been working for more than 2 years now.  The DVD driver is not  % expensive and support has been great.   J I simply replaced the CD-ROMs on our ES40 systems with DVD+-RW drives and E wrote the necessary DCL to support the process.  Eberhard supplied a  7 template procedure to execute the actual DVD burn part.    Regards, Tom   / "Dan Moore" <dmoore@sosu.edu> wrote in message  ! news:K3pLf.397$PR1.60@fe07.lga...  > Greetings, > I >  I need a solution to write OpenVMS backup save_set's to DVD media and  : > then access the files stored in the save_set by OpenVMS. > M >  We burned a DVD on a PC that had transfered a save_set via ftp (bin) from  I > a VMS (Alpha 7.3-1) system. VMS could see the save_set file on the DVD  F > created by the PC (ISO 9660), but could not access files within the I > save_set (save_set/list). So we copied the save_set file directly to a  I > disk on the VMS system (from the DVD rom), and then corrected the file  G > characteristics using OpenVMS. We were then able access the save_set   > files. > L >  Any suggestions on getting the PC out of the loop or at least preserving C > the save_set file characterisitic when burning the DVD on the PC?  > 	 > Thanks,  >  > Dan Moore ( > Southeastern Oklahoma State University >  >    ------------------------------  % Date: Thu, 23 Feb 2006 18:41:23 -0800 ( From: Jeff Cameron <roktsci@comcast.net> Subject: Re: save_set on DVD0 Message-ID: <C023B253.1C087%roktsci@comcast.net>  L The file system would have to support RMS file attributes, and the only file system that does is Files-11.   J Once a backup saveset is copied in binary format to another file system itJ looses its RMS attributes. We use FIXSAVESET.COM to restore the attributes@ based on the blocksize stored in the saveset header. You can get FIXSAVESET.COM from this link:  < http://support.mti.com/VMS2005cd/supportfiles/FIXSAVESET.TXT  K It is saved as FIXSAVESET.TXT to avoid the PC thinking it is an executable.    Jeff  F On 2/23/06 12:38 PM, in article K3pLf.397$PR1.60@fe07.lga, "Dan Moore" <dmoore@sosu.edu> wrote:   > Greetings, > N >   I need a solution to write OpenVMS backup save_set's to DVD media and then5 > access the files stored in the save_set by OpenVMS.  > M >   We burned a DVD on a PC that had transfered a save_set via ftp (bin) from H > a VMS (Alpha 7.3-1) system. VMS could see the save_set file on the DVDN > created by the PC (ISO 9660), but could not access files within the save_setK > (save_set/list). So we copied the save_set file directly to a disk on the L > VMS system (from the DVD rom), and then corrected the file characteristics= > using OpenVMS. We were then able access the save_set files.  > L >   Any suggestions on getting the PC out of the loop or at least preservingC > the save_set file characterisitic when burning the DVD on the PC?  > 	 > Thanks,  >  > Dan Moore ( > Southeastern Oklahoma State University >  >    ------------------------------  % Date: Thu, 23 Feb 2006 14:44:22 -0500 C From: "David Turner, Island Computers US Corp" <dbturner@icusc.com> ; Subject: Secure purchases now available at Island Computers 8 Message-ID: <l7oLf.39345$bW.1544@bignews8.bellsouth.net>  @ Island now offers secure purchasing options through our webstore       --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html    ------------------------------  % Date: Thu, 23 Feb 2006 18:30:45 -0800 ( From: Jeff Cameron <roktsci@comcast.net>5 Subject: Windows XP inner workings revealed publicly. 0 Message-ID: <C023AFD5.1C082%roktsci@comcast.net>  E The technical diagram of Windows XP inner workings revealed publicly.    http://blueballfixed.ytmnd.com/    ------------------------------    Date: 23 Feb 2006 21:55:36 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 9 Subject: Re: Windows XP inner workings revealed publicly. 3 Message-ID: <$flKTpq0sow7@eisner.encompasserve.org>   [ In article <C023AFD5.1C082%roktsci@comcast.net>, Jeff Cameron <roktsci@comcast.net> writes: G > The technical diagram of Windows XP inner workings revealed publicly.  > ! > http://blueballfixed.ytmnd.com/   E Beware - that page has sound embedded (not good in a room where one's  family members are sleeping).    ------------------------------  % Date: Thu, 23 Feb 2006 23:23:53 -0500 / From: "William Webb" <william.w.webb@gmail.com> 9 Subject: Re: Windows XP inner workings revealed publicly. I Message-ID: <8660a3a10602232023k6a6396a6h4e96e7b4769f11d4@mail.gmail.com>   5 On 2/23/06, Jeff Cameron <roktsci@comcast.net> wrote: G > The technical diagram of Windows XP inner workings revealed publicly.  > ! > http://blueballfixed.ytmnd.com/  >  >    That's not the real one.    This is:  http://acarol.woz.org/   WWWebb   --C NOTE: This email address is only used for noncommerical VMS-related  correspondence. C All unsolicited commercial email will be deemed to be a request for 8 services pursuant to the terms and conditions located at# http://bellsouthpwp.net/w/e/webbww/    ------------------------------   End of INFO-VAX 2006.109 ************************