1 INFO-VAX	Sun, 19 Dec 2004	Volume 2004 : Issue 703       Contents: Re: HP exodus to Intel RE: HP exodus to Intel RE: HP exodus to Intel% Re: more LPD problems with TCPIP V5.4 % Re: more LPD problems with TCPIP V5.4  Re: More on Tru64  Re: More on Tru64 9 Re: OT: Deutsche Borse wants to buy London Stock Exchange . Re: SMTP problem: TCPIP$SMTP: Record not found Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald?  Re: Time to revive Emerald? 7 Re: Translating errno and vaxc$errno to real error code  Re: VESA/VGA BIOS emulation   F ----------------------------------------------------------------------  % Date: Sun, 19 Dec 2004 19:02:24 +1100 4 From: Paddy O'Brien <paddy.o'brien@transgrid.com.au> Subject: Re: HP exodus to Intel / Message-ID: <41C53590.4030409@transgrid.com.au>    JF Mezei wrote:   ! [snipping the personality things]   F > Prediticting the demise of Linux when it is growing is not credible.  H I forget where, but Linux has had comments against it because of having C one designer.  Not sure what to look in Google, etc., to find this  
 reference. > P > But VMS has been on a decline, at least in appearance, for 15 years. VMS is noM > longer the recipient of the biggest software library, a big sell for VMS in 
 > the 1980s.   > H Agreed, and I assume you mean that all big software houses were written C to include VMS in their test suites, e.g., Mathworks which gave up   support several years ago.  M > Many potential customers wont even RFP for VMS solutions because they don't ; > want to invest in a platform that has been declared dead.  > L > VMS may not be officialy dead. But for all practical purposes, it has beenZ > relegated to such a small niche market that it has become irrelevant to the IT industry. >   C The expression "niche market" crops up so often.  What is it, this   particular market?  B As you may know from other posts of mine, I use it as a fantastic H Fortran number cruncher.  The compiler is excellent, and performance is * very good.  CXML adds to that performance.  O > The reason that there are on going discussions about VMS here is that many of * > us still believe that VMS has potential. > G Not only potential, but many of us have massive .COM files and various  I procedures that will take a long while to replicate.  In the bid to move  E   our corporate applications away from VMS, some colleagues who look  I after electrical relays are being faced with over $1m (.au) to have this  G re-written by consultants as Perl scripts.  My section uses DECset for  I quality control of our sources and we have invested a lot of effort into  G building .COM files to make our life easier.  I doubt there is an easy  1 equivalent of CMS/MMS/DTM for us to translate to.   M > But one by one, people come to realise that it is a losing battle not worth G > fighting and the need to buy food and shelter forces all but the very I > fortunate to prostitute themselves and work on Windows or Unix systems.   F I guess I might be lucky.  Much as I love VMS, if it came down to the E nitty-gritty, my forte is as a mathematical programmer and not as an  G administrator.  Having said that, it looks as if I am lucky in that we  F shall have our VMS systems (which I do maintain for our 50 engineers) * until I retire -- that's only one year :-)   Regards, Paddy      G ***********************************************************************   C "This electronic message and any attachments may contain privileged > and confidential information intended only for the use of the B addressees named above.  If you are not the intended recipient of C this email, please delete the message and any attachment and advise B the sender.  You are hereby notified that any use, dissemination, 7 distribution, reproduction of this email is prohibited.   A If you have received the email in error, please notify TransGrid  A immediately.  Any views expressed in this email are those of the  = individual sender except where the sender expressly and with  C authority states them to be the views of TransGrid.  TransGrid uses > virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************    ------------------------------  % Date: Sun, 19 Dec 2004 13:01:24 -0500 ' From: "Main, Kerry" <kerry.main@hp.com>  Subject: RE: HP exodus to Intel R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB4E9E83@tayexc19.americas.cpqcorp.net>   > -----Original Message------ > From: John Smith [mailto:a@nonymous.com]=20 ! > Sent: December 17, 2004 2:37 PM  > To: Info-VAX@Mvb.Saic.Com ! > Subject: Re: HP exodus to Intel  >=20 > Jack Peacock wrote: B > > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message0 > > news:JoEwd.4723$Bb5.4010@news.cpqcorp.net...H > >> HP saw more than 180 SAP customers move to Itanium in 180 days (see@ > >> http://www.hp.com/hpinfo/newsroom/press/2004/041118a.html). > >>/ > > The article is about SAP on HP-UX, not VMS.  > >>> > >> I visited some VMS customers in NYC a couple of months=20 > ago, and they B > >> were eagerly starting to get VMS running on rx2600 and rx4640, > >> systems to start their porting efforts.C > > And therein lies the problem.  Everything you quote is existing H > > customers, not new ones.  Where are the articles of users converting' > > a large Sun or IBM site to Itanium?  >=20 >=20B > Indeed, where are the articles of conversions *to* OpenVMS on=20 > any platform?? >=20 >=20  > Well, you likely have already seen this, but since you asked -C University porting open source applications to Itanium and OpenVMS:   . http://h71000.www7.hp.com/news/ospp_turin.htmlH "OpenVMS is the current hot topic among computer engineering students atE Italy's Politecnico di Torino, which is the first university to fully A implement the HP OpenVMS on Integrity servers Open Source Porting A Program. Under the initiative, HP is placing two rx2600 Integrity F servers and two Alpha XP1000 workstations at the university to support5 classroom and graduate projects that port open source H applications-typically running on Linux or Open64-to OpenVMS.....[snip]"  C Not necessarily a new conversion, but a large financial institution A reviews IBM, HP and EMC options and chooses OpenVMS DT multi-site % cluster with high end Alpha GS1280's:   + http://h71000.www7.hp.com/news/genbank.html   G "When General Banking and Trust Company Limited (GBT), one of Hungary's > leading financial institutions, decided to upgrade its OpenVMSE production environment, it demanded a solution that would deliver not ? only high performance and capacity for growth, but also greater F availability and more disaster tolerance. After carefully evaluating aG range of options from HP, IBM, and EMC, the Budapest-based bank decided E to deploy a production site of two OpenVMS AlphaServer GS1280 systems @ (with eight processors and 32GB memory) and a five-terabyte (TB)) StorageWorks XP1024 disk array. [snip..]"    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  % Date: Sun, 19 Dec 2004 13:11:10 -0500 ' From: "Main, Kerry" <kerry.main@hp.com>  Subject: RE: HP exodus to Intel R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB4E9E84@tayexc19.americas.cpqcorp.net>   > -----Original Message-----E > From: ranjit_mathews@yahoo.com [mailto:ranjit_mathews@yahoo.com]=20 ! > Sent: December 17, 2004 6:08 PM  > To: Info-VAX@Mvb.Saic.Com ! > Subject: Re: HP exodus to Intel  >=20H > The potential new customers are eagerly waiting in the wings for Linux; > on Xen on VMS on IA64, with VMS clustering APIs passed=20  > through to Linux> > ... so that they can have something equivalent to Linux with > TruClusters:-) >=20  H Yeah right - and the first time a kernel or key driver or security patchE is released, the clustering software breaks and when cluster software ) breaks, it can be a very nasty situation.   F Same issue was found with Digital Windows NT clustering software. WhenE Microsoft released a kernel or key driver or security patch Customers E would install it on the very first weekend it was available and guess = what - the Digital clustering software often had problems.=20   D Bottom line is that unless you own or have control of the OS kernel,D where new patches can be tested on the cluster software before beingF released, it is extremely difficult to implement an integrated cluster sub-system.=20   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  % Date: Sun, 19 Dec 2004 06:57:24 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: Re: more LPD problems with TCPIP V5.4, Message-ID: <41C56C84.E0709C61@teksavvy.com>  . > <VAXman- @SendSpamHere.ORG> wrote in message  F > > The remote host is always listed with a RNF error in the log file.  J Does the queue manager run on a different node than the LPD queue ? Do the# nodes have separate SYSUAF files ?    I I found out that any equivalent to SUBMIT/USER causes not only the SUBMIT K comand to locally verify the username, but also the queue manager to verify O the existence of the username on whatever node teh queue manager is running on.   I So if you have the LPD stuff running on one node only, make sure that the L username (probably TCPIP$LPD) is defined on any node that can potentially be running the queue manager.   ------------------------------  # Date: Sun, 19 Dec 2004 12:30:44 GMT " From:   VAXman-  @SendSpamHere.ORG. Subject: Re: more LPD problems with TCPIP V5.40 Message-ID: <00A3C925.1D64BB34@SendSpamHere.ORG>  \ In article <41C56C84.E0709C61@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:/ >> <VAXman- @SendSpamHere.ORG> wrote in message  > G >> > The remote host is always listed with a RNF error in the log file.  > K >Does the queue manager run on a different node than the LPD queue ? Do the $ >nodes have separate SYSUAF files ?   I Queue manager and all print queues are on the same node.  The only queues I on remote systems are batch queues are used for production builds.   Only I one SYSUAF file and it resides on the node with queue manager and printer  queues.    --  < http://www.ProvN.com  for the *best* OpenVMS system security=                       solutions that others only claim to be.  --  , Cyber-Terrorism (si'-ber tayr'-or-iz-em) n.:M   The release of, the sale of, or the use of any Micro$oft software product!   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM    ------------------------------  % Date: Sun, 19 Dec 2004 00:34:48 -0800 ! From: gokrix <gokrix@hotmail.com>  Subject: Re: More on Tru64B Message-ID: <1103445300.6176fa529969420bc7278ffc2a2b3496@teranews>   Bob Kaplow wrote: h > In article <1103309527.28b4c56f335928a752c005e3b169c721@teranews>, gokrix <gokrix@hotmail.com> writes: >  >>Bob Kaplow wrote:  >>U >>>In article <I8adnZh54fWRZl_cRVn-2A@igs.net>, "John Smith" <a@nonymous.com> writes:  >>>  >>> P >>>>What's really amazing though is the sh*t will sell when it has advertising &K >>>>marketing behind it. Too bad Tru64 and VMS never had the marketing push 2 >>>>behind them to the same extent that PH-UX had. >>>  >>> L >>>I don't know if that's a typo or intentional, but it's the funniest thing >>>I've seen all week! >> >>It's an old joke.  See >>A >>http://www.oclug.on.ca/pipermail/oclug/2002-January/015697.html  >  > M > Interesting. The place I used to work ran VMS, Tru64, and HPUX side by side L > before all the mergers. As bad as DEC was, we said HPs job was to make DECM > look good. We refered to HP as "HOURLY PATCHES": my colleague who took care K > of that system was installing more patches **EVERY WEEKEND** to the HP-UX 5 > system than I installed in 4 years running VMS 7.2.  >  > 3 > 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" ( > 		>>> To reply, remove the TRABoD! <<<M > Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf N >     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org > P > ... One nation under survielence, divisive, with liberty and justice for none.  B Yeah, HPUX is one of the screwier Unix implementations out there. E Reputedly the HPUX linker is one of the weirdest on the planet, even  D weirder than the AIX one, which takes some doing (the AIX linker is F weird by design but this one is screwy by implementation).  Add those H 'just to be different from the others' features like .sl extensions for I shared libraries and you got something of a mess.  And then there is the  D tiny matter of having to recompile the kernel each time you add new I hardware because the damn thing does not support loadable driver modules   even now...    All in all, a very sad case.   Thanks,  --GS   ------------------------------  # Date: Sun, 19 Dec 2004 15:59:11 GMT 2 From: Bob Willard <BobwBSGS@TrashThis.comcast.net> Subject: Re: More on Tru64- Message-ID: <izhxd.525511$wV.63381@attbi_s54>   
 gokrix wrote:    > Bob Kaplow wrote:  > F >> In article <1103309527.28b4c56f335928a752c005e3b169c721@teranews>, & >> gokrix <gokrix@hotmail.com> writes: >> >>> Bob Kaplow wrote:  >>> ? >>>> In article <I8adnZh54fWRZl_cRVn-2A@igs.net>, "John Smith"   >>>> <a@nonymous.com> writes:  >>>> >>>>E >>>>> What's really amazing though is the sh*t will sell when it has   >>>>> advertising & I >>>>> marketing behind it. Too bad Tru64 and VMS never had the marketing  
 >>>>> push4 >>>>> behind them to the same extent that PH-UX had. >>>> >>>> >>>>I >>>> I don't know if that's a typo or intentional, but it's the funniest  
 >>>> thing >>>> I've seen all week! >>>  >>>  >>> It's an old joke.  See >>> C >>> http://www.oclug.on.ca/pipermail/oclug/2002-January/015697.html  >> >> >>J >> Interesting. The place I used to work ran VMS, Tru64, and HPUX side by  >> side J >> before all the mergers. As bad as DEC was, we said HPs job was to make  >> DECJ >> look good. We refered to HP as "HOURLY PATCHES": my colleague who took  >> care L >> of that system was installing more patches **EVERY WEEKEND** to the HP-UX6 >> system than I installed in 4 years running VMS 7.2. >> >>= >>     Bob Kaplow    NAR # 18L    TRA # "Impeach the TRA BoD" / >>         >>> To reply, remove the TRABoD! <<<  >> Kaplow Klips & Baffle:     7 >> http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf D >>     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org     >> www.nar.org >>H >> ... One nation under survielence, divisive, with liberty and justice  >> for none. >  > D > Yeah, HPUX is one of the screwier Unix implementations out there. G > Reputedly the HPUX linker is one of the weirdest on the planet, even  F > weirder than the AIX one, which takes some doing (the AIX linker is H > weird by design but this one is screwy by implementation).  Add those J > 'just to be different from the others' features like .sl extensions for K > shared libraries and you got something of a mess.  And then there is the  F > tiny matter of having to recompile the kernel each time you add new K > hardware because the damn thing does not support loadable driver modules  
 > even now...  >  > All in all, a very sad case. > 	 > Thanks,  > --GS  K Mind your manners, GS.  After all, this NG is devoted to software from DEC, J the company which produced the ugliest linker of all time - TKB.  In fact,H TKB was IMHO one of the major forces driving RSX folks to switch to VMS. --   Cheers, Bob    ------------------------------  % Date: Sun, 19 Dec 2004 15:24:38 +0100 * From: Paul Sture <nospam@sture.homeip.net>B Subject: Re: OT: Deutsche Borse wants to buy London Stock Exchange, Message-ID: <32lh95F3ntlcfU1@individual.net>   JF Mezei wrote:   L > BBC reports that the german stock market is making a bid to buy the London7 > Stock Exchange (something like 2.5 billion US bucks).  > L > Does Deutsche Borse use VMS ? Any chance they may influence the LSE's next, > technological decisions in favour of VMS ?  " And according to the BBC report at  / http://news.bbc.co.uk/2/hi/business/4108831.stm   E The Deutsche Boerse bid was rejected, and Euronext (formed after the  L Brussels, Paris and Amsterdam exchanges merged) is 'poised to make LSE bid'.  & Anyone know what systems Euronext use?   ------------------------------  % Date: Sun, 19 Dec 2004 06:54:25 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: SMTP problem: TCPIP$SMTP: Record not found , Message-ID: <41C56BD2.8563CC46@teksavvy.com>  G Ok, so I took out the artillery and enable all tracing on the symbiont.   M I then submitted the control file to the queue and listened as the disk drive G worked heavily, logging billlions and billions of lines of information.   N Well, wouldn't you know it, the same message which consistently refused to get> sent before was succesfully sent  with all tracing turned on.   L However, at the very end, the symbiont tried to process the very file it hadK just succesfully deleted and the issued messages about invalid control file J :-)  (I'll blame this on on the fact that I used SUBMIT to put the control file back into the queue).   ----  N In terms of the TCPIP$SMTP username issue, I find it interesting that the SMTPG receiver had no problems submitting messages to the SMTP queue, but the I symbiont itself (runs under SYSTEM) couldn't submit new entries under the  TCPIP$SMTP name.  J My theory is that a SUBMIT without /USER doesn't trigger a queue manager'sF verification of username, whereas a /USER= causes the queue manager toI reverify the username against the SYSUAF on the node it is running under.    ------------------------------  % Date: Sun, 19 Dec 2004 12:06:19 +0100 * From: Paul Sture <nospam@sture.homeip.net>$ Subject: Re: Time to revive Emerald?, Message-ID: <32l5lbF3nf737U1@individual.net>   Tom Linden wrote:   1 > On Fri, 17 Dec 2004 14:12:36 +0000, Roy Omond   & > <Roy.Omond@BlueBubble.UK.Com> wrote: >  >>C >> I'm going out on a limb here, but my bet is that VMS Engineering D >> is smart enough to have taken advantage of the whole IA64 porting5 >> effort to have done work on "other platforms" too. ; >>  My guesstimate is to look out in the "near" future for:  >>  OPENVMS-AMD64  >> andOPENVMS-POWER52 >>  (definition of "near" intentionally left blank >  > D > It could be argued that not having done it would be a dereliction. >  Indeed.    --  H The above address no longer works. Lastname and decuserve.org get me at  the moment.    ------------------------------  % Date: Sun, 19 Dec 2004 08:11:58 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> $ Subject: Re: Time to revive Emerald?6 Message-ID: <n6fxd.46$Z%3.10033@news20.bellglobal.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:41C4AA26.E0448CEE@teksavvy.com... > Neil Rieck wrote: I >> If the renovated Alpha code base was designed to only deal with 64-bit D >> CPU's, then using it to port to IA-32 isn't going to be possible. > - > Forget about porting to 32 or 16 bit 8086s.  > I > The "current" 8086 is 64 bits. There is no point in porting VMS to the   > older I > versions of the 8086. So, porting VMS to the 64 bit version of the 8086 G > shouldn't be that difficult, provided the chip provides the necessary 7 > functions, and from what has been said here, it does.   J Really? I thought the latest Pentium-4 style CPUs from AMD and Intel were L still based upon a 32-bit core with extensions that allow addressing into a  64-bit memory space.  8 http://www.intel.com/design/pentium4/specupdt/252046.htm  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Sun, 19 Dec 2004 08:40:22 -0500 # From: "John Smith" <a@nonymous.com> $ Subject: Re: Time to revive Emerald?, Message-ID: <TOWdnXNvjK5UGVjcRVn-ug@igs.net>   Neil Rieck wrote:  > Time to revive Emerald?  >   K If anybody ever wanted to make Alpha 'industry standard' all they'd have to ; do is give China the unrestricted rights to manufacture it.   3 1 billion chips before you could say 'Peking Duck'.    ------------------------------  % Date: Sun, 19 Dec 2004 08:24:52 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> $ Subject: Re: Time to revive Emerald?6 Message-ID: <uifxd.48$Z%3.11703@news20.bellglobal.com>  $ <icerq4a@spray.se> wrote in message = news:1103386040.750541.153340@f14g2000cwb.googlegroups.com...  >  [...snip...] > G > I don't know what would have been easier, but the thread support were H > terrible in Tru64 for many years, it had the worst pthread performanceD > and bugs of all UNIX:es. I though actually think it has been fixed > during the last two years. > & > As a normal UNIX, except clustering,> > Tru64 was not in any way better than the other UNIX systems. > M I think your opinion may be a matter of perspective. First off, using LSM to  H manage RAID sets in 1997 (DUNIX 4.x) was much easier than what I saw in M February of 2004 when I watched a colleague set up RAID sets on a Solaris-9.  M Secondly, I didn't do any programming on the Tru64 platform in our shop so I  I can't comment on thread support, but I do remember pthread support being  M terrible for almost a year after I upgraded one of my VAX systems to OpenVMS  6 6.2 so maybe this problem was larger than DUNIX/Tru64.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html     ------------------------------  % Date: Sun, 19 Dec 2004 09:57:45 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> $ Subject: Re: Time to revive Emerald?7 Message-ID: <xFgxd.201$Z%3.25264@news20.bellglobal.com>   / "John Smith" <a@nonymous.com> wrote in message  & news:TOWdnXNvjK5UGVjcRVn-ug@igs.net... > Neil Rieck wrote:  >> Time to revive Emerald? >> > K > If anybody ever wanted to make Alpha 'industry standard' all they'd have   > to= > do is give China the unrestricted rights to manufacture it.  > 5 > 1 billion chips before you could say 'Peking Duck'.  >   I I agree and would be all for it except we all know that Intel is somehow  F involved in killing off Alpha (eliminate the competition?) and so the  China-thing would never happen.   M But just as a clarification, I believe the main focus of the "Prism Project"  G was hardware (Alpha) while the main focus of the "Emerald Project" was  J software. I'm assuming that it's too late to save Alpha but would like to * see more future possibilities for OpenVMS.  	 * * * * *   G BTW, can anyone confirm whether the facts in the following article are  	 accurate? C http://en.wikipedia.org/wiki/Dave_Cutler#Prism_and_Emerald_Projects     
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Sun, 19 Dec 2004 10:45:41 -0500 2 From: Chip Coldwell <coldwell@physics.harvard.edu>$ Subject: Re: Time to revive Emerald?@ Message-ID: <Pine.LNX.4.61.0412191021050.5916@frank.harvard.edu>  & On Sun, 19 Dec 2004, Neil Rieck wrote:   > < > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message( > news:41C4AA26.E0448CEE@teksavvy.com... >> Neil Rieck wrote:J >>> If the renovated Alpha code base was designed to only deal with 64-bitE >>> CPU's, then using it to port to IA-32 isn't going to be possible.  >>. >> Forget about porting to 32 or 16 bit 8086s. >>I >> The "current" 8086 is 64 bits. There is no point in porting VMS to the  >> olderJ >> versions of the 8086. So, porting VMS to the 64 bit version of the 8086H >> shouldn't be that difficult, provided the chip provides the necessary8 >> functions, and from what has been said here, it does. > K > Really? I thought the latest Pentium-4 style CPUs from AMD and Intel were M > still based upon a 32-bit core with extensions that allow addressing into a  > 64-bit memory space.  E It's even weirder than that.  I have the IA-32 Architecture Software  B Developer's Manual (a four-volume beast) on my lap as I write the  following quote from page 3-2:  J    "Any task or program running on an IA-32 processor can address a linearG     address space of up to 4 GBytes (2^32 bytes) and a physical address I     space of up to 64 GBytes (2^36 bytes).  (See Section 3.3.3, 'Extended I     Physical Addressing' for more information about addressing an address "     space greater than 4 GBytes.)"  K The reality is that since the P6, the IA-32 has been a 36-bit architecture  F if you measure the size of an architecture by the width of a physical K address.  Intel calls this "Physical Address Extensions" (PAE).  The weird  G part is that for compatibility, the virtual addresses remained 32-bits  K wide.  In a sense, Intel turned the whole concept of virtual memory on its  G head -- whereas in every other VM implementation the virtual memory is  H larger than the physical memory (using backing store on disk to make up H the difference), with Intel's P6 the physical memory is larger than the  virtual memory.   I The idea is that you could have several processes with up to 4 GBytes of  E memory each resident in core at the same time.  Although none of the  J processes could address more than 4 GBytes, the kernel wouldn't be forced F to swap between them because of a lack of physical memory.  At least, F that's how the Linux kernel uses PAE; apparently Windows uses it in a K different mode that does allow the process virtual address space to exceed  ) 4 GBytes using a segmented memory scheme.   J The latest Xeons from Intel have now implemented an AMD-compatible 64-bit I core.  Intel calls it "EMT", and apparently were very reluctant to admit  H that it was AMD-compatibile, making no mention whatsoever of AMD in the J architecture reference manual.  I don't know if these Xeons still support I PAE as well, but that would bring the total number of addressing schemes  ) supported by the processor to about five.   C Quoting Peter van der Linden, "The Intel 80x86 Family: Putting the  % 'Backward' in 'Backward Compatible'".    Chip   --   Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388   ------------------------------  # Date: Sun, 19 Dec 2004 18:13:01 GMT % From: Roger Ivie <rivie@ridgenet.net> $ Subject: Re: Time to revive Emerald?3 Message-ID: <slrncsbh80.jnk.rivie@Stench.no.domain>   B On 2004-12-19, Chip Coldwell <coldwell@physics.harvard.edu> wrote:G >  In a sense, Intel turned the whole concept of virtual memory on its  I > head -- whereas in every other VM implementation the virtual memory is  J > larger than the physical memory (using backing store on disk to make up J > the difference), with Intel's P6 the physical memory is larger than the  > virtual memory.   C It's actually not that unusual. PDP-8 and PDP-11 worked this way as D well; in the PDP-8, a 12-bit virtual address is extended to a 13-bitC (8/i), 15-bit (8/e), or 17-bit (8/a) physical address. On PDP-11, a G 16-bit virtual address is turned into an 18-bit (UNIBUS, early QBus) or $ 22-bit (late QBus) physical address. --  
 Roger Ivie rivie@ridgenet.net http://anachronda.webhop.org/  -----BEGIN GEEK CODE BLOCK----- 
 Version: 3.12 H GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+? PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++   ------END GEEK CODE BLOCK------    ------------------------------  + Date: Sun, 19 Dec 2004 08:53:40 +0000 (UTC) ( From: ExGuardianReader <noway@noway.com>@ Subject: Re: Translating errno and vaxc$errno to real error code0 Message-ID: <cq3fij$e7m$1@sparta.btinternet.com>   JF Mezei wrote: " > VAX VMS 7.2 TCPIP Services 5.3-2 > P > When I try to send a long message (about 600k) through the SMTP server from my1 > mac to the internet, I almost consistently get:  > J > smtp_sender_close shutdown R0 status = -1, errno = 54, vaxc$errno = 8472 > L > (The smtp software then proceeds to lose the msssage, even though the file- > remains on the system in an unusable state.  > P > Question: how does one go about translating the above error messages into real= > VMS messages to have some clue on why this problem arises ?   4 I thought vaxc$errno was the VMS status code, so its  ) %SYSTEM-W-TOOMANYREDS, too many redirects    ------------------------------  % Date: Sun, 19 Dec 2004 13:01:58 -0500 2 From: Chip Coldwell <coldwell@physics.harvard.edu>$ Subject: Re: VESA/VGA BIOS emulation@ Message-ID: <Pine.LNX.4.61.0412191258300.8500@frank.harvard.edu>  J   This message is in MIME format.  The first part should be readable text,K   while the remaining parts are likely unreadable without MIME-aware tools.   ' ---141794438-553533232-1103479318=:8500 ; Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed + Content-Transfer-Encoding: QUOTED-PRINTABLE   : On Sat, 18 Dec 2004, [iso-8859-1] M=E5ns Rullg=E5rd wrote:  6 > Chip Coldwell <coldwell@physics.harvard.edu> writes: >  > [reverse engineering]  > I >> 0x41534556 is 'VESA' in ASCII on a little-endian machine.  The version G >> code 0x0300 occupies the next two bytes.  I'm pretty sure I've found I >> it. But there are still some strange things about it, such as the fact " >> that it's not longword-aligned. > E > That does sound somewhat odd.  Does the following data seem to make  > sense?   Yes and no.  Here's what I get:   ? 8b8622f5: 41534556 00000300 00010000 00000000  VESA............ ? 8b862305: 00000000 00000000 00000000 00000000  ................ ? 8b862315: 001b0000 00400007 a0000040 00000000  ......@.@....... ? 8b862325: 000f0000 00200007 b8000020 00000000  ...... . ....... ? 8b862335: 614d0000 786f7274 61724720 63696870  ..Matrox Graphic ? 8b862345: 6e492073 4d002e63 6f727461 614d0078  s Inc..Matrox.Ma ? 8b862355: 786f7274 35344720 30300030 45425600  trox G450.00.VBE ? 8b862365: 41474d2f 00000101 00000000 01023f00  /MGA.........?.. ? 8b862375: 1074143c 1d770b3c e432fcfb 2e93e0d1  <.t.<.w...2..... A 8b862385: 553da7ff 0f03fb80 80080284 840f05fb  ..=3DU............ ? 8b862395: 01eb080a ffffb890 cb8b51cf 01ffe181  .........Q...... ? 8b8623a5: 746af983 02f98106 81087501 81f600e3  ..jt.....u...... ? 8b8623b5: 590102cb 565350c3 811f0e1e 8d01ffe3  ...Y.PSV........ A 8b8623c5: ad526136 0774d83b 75ffff3d 1fc00bf6  6aR.;.t.=3D..u.... ? 8b8623d5: c3585b5e 571ed88b 0e525156 0000ba1f  ^[X....WVQR..... A 8b8623e5: 3d816626 32454256 01ba0375 80b95700  &f.=3DVBE2u....W..   ; (once again, note that the addresses on the left are not=20 J longword-aligned).  The OemString, OemVendorName and OemProductName are=20G pretty clearly in there.  I haven't made any sense of the pointers yet.   J I discovered that this data is already in memory before I call out to any= =20 I of the VGA BIOS functions.  So it's left over from a BIOS call the SRM=20  console itself made.   Chip   --=20  Charles M. "Chip" Coldwell System Administrator Harvard Physics Department 617-495-3388) ---141794438-553533232-1103479318=:8500--    ------------------------------   End of INFO-VAX 2004.703 ************************                      ,wq/=$cU>{2FD,2<?X;lkCOׄQR2z;0
a(#&	#uhCԲ)˲(QI5#x8w ec\)G]3NIoj"WހF!/"XJ/շBC<ltN9]0Սa+FvXyGqFS/\hdsrx<=Ow&'*	seVzߢF;<abx}dG7ꛦ]~Iԟ9mY>!yN9ö'^3(ZHaeE4e0RJN9LCFg@t\C(|ﳝo'J15 ,Bgl<jr}5Ek<hhf
#cm+֡gq<(|jV4!uE#<_eoEۥcVzqgvrZ3C0i|[lvL璍ʽSJSN[{ΕYc"탵^zNflmnoɐia%}w#?Zv~+;pAR}I3^^z퐖Ў}	ŭo0J>_ڦf_j<q0.vw
Eȍ;ws 4shke%QNp{4|3|=X>M|` sgg&[}P(8ugr.(!CS;wܶ}QF?8[*ȯHߢ~_BL<ǄbvIV죓ivbB{<7}?]O PgMDKR\c]Re+Xxx0rbG=|l|7a|1仓ɷ.,#(O;	i"^K	"N&E7ܘv??U
Fl"eW^/&LğxoB
