0 INFO-VAX	Thu, 12 Feb 2004	Volume 2004 : Issue 85      Contents:$ Re: Analyzing TCPIP network failures! Re: Boeing 747 turns 35 Years Old ! Re: Boeing 747 turns 35 Years Old  Re: disk drive partition?  Re: File transfers to a PC Re: File transfers to a PC' Re: Help needed - Hobbyist license, etc ' Re: Help needed - Hobbyist license, etc > HP OpenView Operations Agent for OpenVMS V1.0 - Available now!8 Re: HP/Intel Itanium is dead, long life to HP/AMD AthlonP Re: Intel and Microsoft provide higher 32-bit applications performance on Itaniu: Re: It is almost certain now, INTEL will have 64bit x86 !!: Re: It is almost certain now, INTEL will have 64bit x86 !!: Re: It is almost certain now, INTEL will have 64bit x86 !!: Re: It is almost certain now, INTEL will have 64bit x86 !! Re: Microvax vs Vaxstation 3100  Re: Microvax vs Vaxstation 3100  Re: Microvax vs Vaxstation 3100  Re: OpenVMS Feelings Re: Other CVS on VMS problems  Re: Other CVS on VMS problems  Re: Other CVS on VMS problems A Re: page- and swap-files, autogen, modparams.dat, file-naming etc  Re: PSION, another Digital Re: Rumours of (CPU) Wars  SFTP/SCP on VMS  Re: SFTP/SCP on VMS > Re: SYS$STARTUP:MMOV$STARTUP.COM -- lacks something (priority) Re: VMS and Unicode  Re: VMS and Unicode  Re: Why was VAX abandonned ?- [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full 1 Re: [OT] Solaris crashes itself when /tmp is full   F ----------------------------------------------------------------------  # Date: Thu, 12 Feb 2004 15:28:26 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>- Subject: Re: Analyzing TCPIP network failures 8 Message-ID: <dr6n20tr2d9q5aj87u4nt28jng93e42k54@4ax.com>  H I would usually use tools like ping and traceroute to track down network  failures during troubleshooting.  J For monitoring, there are lots of tools.  You may want some tool that usesI a combination of ping, traceroute, and snmp to watch for network outages. < There are also some non-free tools to monitor the enterpriseJ infrastructure, and these can often use a rules base to correlate multipleF 'events' into a more meaningful one (e.g., if a router is unavailable,H don't send events/alerts for the 1000+ systems on the other side of that router).    H On Wed, 11 Feb 2004 11:35:55 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:  O >1- It would be neat if there were some hook in the inetACP such that a process N >could be notified  whenever a connection attempt from the VMS host to another >host fails. >  > O >2- In cases where you suspect a network failure somewhere upstream, how do you  >track it down ?   > K >Do you hardcode specific IP adresses of upstream routers to ping to see at M >what point connectivity would have been lost ?  (if the path to a DNS server 5 >is gone, you may not be able to ping by host name) ?  > M >If you keep the IP addresses of relevant routers in a command procedure, how 4 >often to you check to ensure they are still valid ? > M >In a similar vein, is there a trick to get a local DNS server to always keep P >an updated copy in cache of a list of host names (that don't belong to you) ?   > O >This way, in case of a ISP's DNS server failing, your own DNS would still have  >IP adresses of relevant hosts.    --- jls 0 The preceding message was personal opinion only.6 I do not speak in any authorized capacity for anyone,  and certainly not my employer.- (get rid of the xxxz in my address to e-mail)    ------------------------------  # Date: Wed, 11 Feb 2004 15:16:41 GMT  From: "None" <none@nospam.org>* Subject: Re: Boeing 747 turns 35 Years Old? Message-ID: <tHrWb.109$WW3.77@newsread2.news.pas.earthlink.net>   K AA still has a few 47s sitting in the desert.  Delta and CO have none left, I having sold them off to foreign concerns.  AA could get smart and convert J their 47s for cargo use and just start flying cargo with them.  Could be a; big money maker considering all the cargo they haul anyway.    --   ***/***/***  When life gives you lemons Skullfuck everyone in sight! http://wonderofitall.com/    ***/***/*** 0 "edo" <nobody@cryptorebels.net> wrote in message9 news:e7288af81938cfc944e3948cbc5a3da3@cryptorebels.net...    ------------------------------  % Date: Wed, 11 Feb 2004 07:49:47 -0800 , From: "Tarver Engineering" <jtarver@sti.net>* Subject: Re: Boeing 747 turns 35 Years Old, Message-ID: <0s6dnXpWIbu50rfdRVn-gw@sti.net>  ) "None" <none@nospam.org> wrote in message 9 news:tHrWb.109$WW3.77@newsread2.news.pas.earthlink.net... / > AA still has a few 47s sitting in the desert.    LOL    ------------------------------    Date: 12 Feb 2004 05:50:50 -0800, From: JimStrehlow@data911.com (Jim Strehlow)" Subject: Re: disk drive partition?= Message-ID: <4b6ec350.0402120550.180bce46@posting.google.com>   ( "Richard B. Gilbert" wrote in message...J > Oracle recommends that a database be spread over some minimum number of I > disks; I seem to recall that at least five are recommended.  (At least  K > this is true of Oracle 7.x and Oracle 8.x; I've not yet managed a system   > with Oracle 9.x)@ > You can take one very large disk and put everything on it but ) > performance will almost certainly suck!   F Although Oracle recommends multiple disks, most RAID arrays handle the: load for at least our suite of applications on one "disk".F Having said that, the AlphaServer DS10L does not have an internal RAID array.A Also, it is for travel to be used by "sales", so the fewer moving 7 parts the better (no additional external disks for it.)   	 Catch-22: 0  Oracle 8i only officially supports ODS-2 disks.0  Oracle 9i only officially supports ODS-5 disks.  E A "problem" is that we have currently only certified our applications D against Oracle 8i (8.1.7.4) (rule-based versus cost-based) ... so we' will probably format for ODS-2 for now.   B When we want to use 9i, we will have to convert the disk to ODS-5,' remove Oracle 8i and install Oracle 9i.   B We have other servers, RAID arrays, etc. for temporary work, ODS-2 disks, ODS-5 disks, etc.  > If there is a need, we may experiment with the LD logical disk software later.   # Thank you all for your suggestions. 2 Jim Strehlow, Data911.com, OpenVMS Systems Manager   ------------------------------    Date: 12 Feb 2004 08:56:05 -0800* From: kcoughlin@theunionleader.com (Kevin)# Subject: Re: File transfers to a PC ; Message-ID: <ce501608.0402120856.2237dd@posting.google.com>   D You're not pulling this data through a serial port at 9600 baud, are you?  F  Yes, we are connecting through the serial port, but at 38400 baud. WeB connect to DEC servers with RS232. The PC is also connected to theC network in the usual way and uses TCPIP. It's my understanding that F the 2 networks are separate, thats why the 2 connections on my PC. I'mF not sure about TCP IP on the Vax. I think if it was available on ours,D someone would have used it before this. Unfortunatly, out Vax expert3 retired last year and I know very little about Vax.   F  Once you get the connectivity right, you could use ZIP on the VAX to E  make the files smaller.  I assume they're text -- they should smash    down by about 50%.   ? Tell me more about zipping on the Vax. Some of the files we are > domnloading are almost 300,000 blocks and take over 7 hours toA download to the PC. If we can compress the files, this would help E quite a bit. Once the files are in the PC, the transfer time from one C PC to another using ethernet by mapping the drives is minutes. Much  faster.    ------------------------------  % Date: Thu, 12 Feb 2004 13:16:57 -0500 2 From: "Stanley F. Quayle" <squayle@insight.rr.com># Subject: Re: File transfers to a PC . Message-ID: <402B7CC9.22959.5D38F4A@localhost>  E >  Yes, we are connecting through the serial port, but at 38400 baud. ' > We connect to DEC servers with RS232.   F This probably won't work very well.  The max you can really expect is  (usually) more about 9600 baud.     >The PC is also connected to theE > network in the usual way and uses TCPIP. It's my understanding that D > the 2 networks are separate, thats why the 2 connections on my PC.  D There's two separate network cards?  Or does one card just have two  different connectors?   ' > I'm not sure about TCP IP on the Vax.   @ Since it's an added-cost item, you may or may not have it.  You A almost certainly have DECnet, however.  And you must have LAT --  ( which the terminal server probably uses.  F If you load Linux on your system, you can get the free DECnet and LAT  packages at:  &   http://linux-decnet.sourceforge.net/  A If you have an older version of Reflections (*not* freeware), it  . might be able to speak DECnet or LAT, as well.   > Unfortunatly, out Vax expert5 > retired last year and I know very little about Vax.   F None of us live forever.  Please contact me directly, and we might be  able to arrange something.  ( > Tell me more about zipping on the Vax.  = Info-ZIP can create ZIP files on the VAX that are completely  ? compatible with WinZIP.  This only makes sense for text files,  B however.  Info-ZIP can be found on the Freeware disk off the main ) OpenVMS web site (www.hp.com/go/openvms).   
 --Stan Quayle  Quayle Consulting Inc.  
 ----------C Stanley F. Quayle, P.E. N8SQ  +1 614-868-1363  Fax: +1 614 868-1671 1 8572 North Spring Ct. NW, Pickerington, OH  43147 = Preferred address:  stan@stanq.com       http://www.stanq.com    ------------------------------  % Date: Wed, 11 Feb 2004 05:58:03 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>0 Subject: Re: Help needed - Hobbyist license, etc) Message-ID: <402A0A89.9B0F3897@istop.com>    Tux Wonder-Dog wrote: L > Well, I'm in St Albans, Christchurch, New Zealand; I've got at least threeJ > freely-redistributable Vax emulators (SIMH, TS10, and evax) for my Linux: > machine - all I need is a helping hand and the software.  L If you pay for my transport, I'll gradly go there. Am in Montreal canada :-) :-) :-) :-) :-)   I You might want to contact DECUS New Zealand (or whatever its name is this L week) as they may be able to put you in touch with folks on the south island& that might be able to lend you a copy.   ------------------------------  % Date: Thu, 12 Feb 2004 22:51:48 +1300 1 From: Tux Wonder-Dog <wes.parish@paradise.net.nz> 0 Subject: Re: Help needed - Hobbyist license, etc4 Message-ID: <C4IWb.23733$ws.2942128@news02.tsnz.net>   JF Mezei wrote:    > Tux Wonder-Dog wrote: G >> Well, I'm in St Albans, Christchurch, New Zealand; I've got at least K >> three freely-redistributable Vax emulators (SIMH, TS10, and evax) for my A >> Linux machine - all I need is a helping hand and the software.  > 5 > If you pay for my transport, I'll gradly go there.    8 ;^)  Wouldn't we all!  A change is as good as a holiday!   > Am in Montreal canada  > :-)  > :-) :-) :-) :-)  > K > You might want to contact DECUS New Zealand (or whatever its name is this G > week) as they may be able to put you in touch with folks on the south / > island that might be able to lend you a copy.   J I've posted a message about it on the encompass-nz email list, but so far,! no luck.  It's a very quiet list.    Thanks all the same.  
 Wesley Parish  --  G "Good, late in to more rewarding well."  "Well, you tonight.  And I was K lookintelligent woman of Ming home.  I trust you with a tender silence."  I C get a word into my hands, a different and unbelike, probably - 'she = fortunate fat woman', wrong word.  I think to me, I justupid. G Let not emacs meta-X dissociate-press write your romantic dialogs...!!!    ------------------------------    Date: 12 Feb 2004 06:38:30 -0800. From: fabiopenvms@yahoo.com.br (Fabio Cardoso)G Subject: HP OpenView Operations Agent for OpenVMS V1.0 - Available now! = Message-ID: <f30679fb.0402120638.71e76397@posting.google.com>    Click   9 http://www.openvms.org/stories.php?story=04/02/11/5591697      February 11, 2004   C I am pleased to announce the availability of HP OpenView Operations @ Agent for OpenVMS version 1.0, a management solution for OpenVMS> AlphaServer systems which can be seamlessly integrated with HP# OpenView Operations (OVO) software.     A OpenView Operations is a true end-to-end, distributed large-scale E management solution that monitors, controls and reports on the health F and performance of the heterogeneous IT environment across boundaries,A thereby improving uptime for all layers that compose the adaptive B enterprise environments of today: the network, systems, databases,( applications, services and the Internet.    D OpenView Operations Agent for OpenVMS version 1.0 presents real-timeF OpenVMS AlphaServer system monitoring and event management to both OVOB UNIX and OVO Windows servers utilizing the native agents and Smart; Plug-ins (SPI). The agent monitors the performance, detects C bottlenecks, and reports on the availability of the OpenVMS systems E and can send alarms and notifications, based on thresholds set by the E operations staff through policies based on the filtering criteria, to  the OVO server.    BUT ....   This link is not working  C http://h71000.www7.hp.com/openvms/products/vms_ovo_agent/index.html    Regards    FC   ------------------------------  % Date: Thu, 12 Feb 2004 17:38:28 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> A Subject: Re: HP/Intel Itanium is dead, long life to HP/AMD Athlon 0 Message-ID: <c0gdmk$3h5$1@new-usenet.uk.sun.com>   John Smith wrote: * > Andrew Harrison SUNUK Consultancy wrote: >  >  > <snip> > F >>The next question is how compatible with x86-64 will the 64bit IntelG >>x86 processor be, Microsoft says very, very, very do you really think  >>that Intel will dissobey.  >  > G > Which only demonstrates that if one wants to have control of your own K > destiny as a computer manufacturer/systems vendor, then you must own your E > own operating system and advertise/promote it every chance you get.  >   F Its one reason that Sun has always put forward for doing SPARC/SolarisC it allows us to control our own destiny instead of having a destiny  dictated to us.     = > Otherwise you might as well be selling only ink cartridges.  >   * Don't knock it toner is high margin stuff.   Regards  Andrew Harrison  >    ------------------------------  % Date: Thu, 12 Feb 2004 11:27:56 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> Y Subject: Re: Intel and Microsoft provide higher 32-bit applications performance on Itaniu 0 Message-ID: <c0fnvs$ot9$1@new-usenet.uk.sun.com>   Rick Jones wrote: R > Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> wrote: >  >>Rick Jones wrote:  >>E >>>BTW, how many of those 12000 "SPARC" applications are Solaris 8 or ! >>>earlier rather than Solaris 9?  >  >  > 3 >>Solaris 8 with a large % supported for Solaris 9.  >  > ) > What is the definition of "large" here?  >  >   / ~70% but Solaris 9 isn't required for any SPARC 6 platform so I don't expect the gap to close completely7 until there are new platforms that only support Solaris  9.  > >>But its not the same as HP-UX/AIX etc because Sun provides a; >>binary compatibility guarantee to our ISV's, run your app ? >>in our test harness, if it passes we guarantee to fix Solaris ? >>is a future version breaks your app. A number of IVS's that I @ >>work with have qualified with Solaris 8 plus the guarantee and@ >>don't intend to specifically qualify with 9 because they don't
 >>need to. >  > B > And how many of those 12000 applications have had their ISVs run > through that test harness?  E I have no idea, one of the two most important Apps used by my current D client has. The other is developed on Solaris so they probably arn't& so interested in the Binary Guarantee.   Regards  Andrew Harrison  >  > rick jones   ------------------------------  % Date: Wed, 11 Feb 2004 05:51:01 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! ) Message-ID: <402A08E4.BABDF3A7@istop.com>    Rob Young wrote:O > Here's the basic problem. Were you aware that Intel actually writes a heap of N > drivers for Windows? And that when Windows XP was being launched, both IntelN > and Microsoft helped out some hardware vendors by assisting them with driver
 > writing?  L How much are drivers specific to a motherboard ? When I buy Windows, does itM come with all possible drivers for all possible motherboards ? I realise that L people like Compaq loved to have their own proprietary drivers for keyboards etc. But this wasn't necessary.   J if the AMD 64 buit 8086 can run 32 bit Windows out of the box, just like aN Dell box can, then as a start, AMD doesn't need to fund a rewrite of Windows.   M Now, compare AMD with Digital: AMD has every intention to push and market its K chip. Digital had every intention to prevent Alpha from being marlketed and M competing head to head against Intel's 8086. Microsoft is therefore much mroe ? likely to work with AMD to get Windows running on the AMD 8086.   N Furthermore, with Linux running on 64 bit machines, including the 64 bit 8086,M you can bet your <part of anatomy> that Microsoft will also want a version of L Windows , at least for servers, to run on it. (The different between now and0 then is that Linux is taken very seriously now).  B >         It will Intel's deep pockets that will get Win64 off theO >         ground on x86-64.  Will you be shocked if Win64 for x86-64 is still a ! >         beta 6 months from now?   N But Microsoft already has the experience from its port of Windows to Alpha. SoN porting the current version of window to the 64 bit 8086 shouldn't be that big a project for Microsoft.  G >         Secondly, Fister says Itanium = Xeon in cost in a few years.    G 3 years is very long in CPU years. It could very well be a garage sale, M liquidation of the last batch of IA64s that are sold at a loss. It could very M well be that Intel has decided it will lose money in the long term to support K this bloated and expensive chip. Or it could be that XEON will be dead in 3 L years and a new, far cheaper version of the 80-86 will be out on the market.N So while IA64 may come down in price to the levels of the last batch of Xeons,K it would still not be competitive with the products available at that time.   N The problem with IA64 is that all the promises are made relative to today, notM relative to what will be available at that time.  If IA64 lags today, it will L lag in 3 years. If IA64 is expensive today, it will be expensive in 3 years.  = >         at all.  Intel has billions and is making billions:   I From its 8086 line, and Intel isn't about to jeoperdize those billions by M cannabalising is 8086 line to push a dead end bloated expensive architecture.   L Intel needs to have a chip that is easy to upgrade and make faster and which5 it can achieve faster than AMD or other competitors.    I >         I will bet that if they can make the x86 ISA pig fly, they will K >         make Itanium fly AND will throw the proper hundred million dollar F >         chunks in the correct directions to ensure it is successful.  H The thing is that the 8086 is like a feather whereas the IA64 is like anH anvil. Which one is easier to make fly ? Which one costs less to lift to higher altitude/speed ?    >         HP must M >         be excited to see high-end server costs come down to the Xeon level J >         (they make bucks on VMS services and NSK services).  IBM and Sun# >         aren't nearly as excited.   H HP is excited at having yet another excuse to provide to customers "waitM another 3 years, IA64 will e better by then".  People didn't laugh at Merced. L We knew how painful it had been for Intel to produce that junk. We were thenN told to wait for McKinley which would be what Intel had truly intended IA64 toH be. So now, there are no longer any reason for customers to give Intel aM break. Are current IA64 offerings TODAY what Intel wanted IA64 to be, or must K we wait another 3 years before we see what Intel really wants IA64 to be ?    L Sorry, but HP must stand on its own with whatever Intel offers TODAY.  If HPN starts telling its customers to wait hold off on purchases for anyther 3 yearsI until IA64 is really ready for prime time, guess what will happen to HP's  business computing unit ?   K And in 3 years, assuming IA64 is still alive, will you be telling customers N about that great promise from Intel that 3 years from then (6 from now), Intel3 intends to deliver an IA64 that also makes coffee ?    ------------------------------    Date: 11 Feb 2004 08:50:21 -0600+ From: young_r@encompasserve.org (Rob Young) C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! 3 Message-ID: <wevLx5nXZrHS@eisner.encompasserve.org>   V In article <402A08E4.BABDF3A7@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > Rob Young wrote:P >> Here's the basic problem. Were you aware that Intel actually writes a heap ofO >> drivers for Windows? And that when Windows XP was being launched, both Intel O >> and Microsoft helped out some hardware vendors by assisting them with driver  >> writing?  > N > How much are drivers specific to a motherboard ? When I buy Windows, does itO > come with all possible drivers for all possible motherboards ? I realise that N > people like Compaq loved to have their own proprietary drivers for keyboards! > etc. But this wasn't necessary.   C 	But it most likely is a big problem for Windows.  Especially given = 	the myriad combinations of hardware - not just motherboards.    > L > if the AMD 64 buit 8086 can run 32 bit Windows out of the box, just like aP > Dell box can, then as a start, AMD doesn't need to fund a rewrite of Windows.  >   @ 	Right.  But it comes back to Win64.  Win64 for Itanium is fully% 	funded, and Win64 for Opteron isn't.      > P > But Microsoft already has the experience from its port of Windows to Alpha. SoP > porting the current version of window to the 64 bit 8086 shouldn't be that big > a project for Microsoft. >   = 	It isn't a problem for Micrsoft.  It is a problem for AMD.    	Remember this:   ) http://www.theinquirer.net/?article=14049   M Here's the basic problem. Were you aware that Intel actually writes a heap of L drivers for Windows? And that when Windows XP was being launched, both IntelL and Microsoft helped out some hardware vendors by assisting them with driver writing?  O Unfortunately, Windows for AMD64 is not a high priority for Microsoft. By which M we mean that it's not going to go out of its way to help out AMD, without the L chip company paying a heap of money for the effort. And AMD's pockets aren'tN that deep, nor has it that many software developers it can spare for the task.    @ 	On re-reading those two paragraphs, is the problem any clearer?   > > >>         at all.  Intel has billions and is making billions: > K > From its 8086 line, and Intel isn't about to jeoperdize those billions by O > cannabalising is 8086 line to push a dead end bloated expensive architecture.  >   ? 	Ah, contraire.  Perhaps you need to pick up "Only the paranoid ? 	survive" by Andy Grove.  Intel has a history of cannabilizing,  	slashing and burning, etc.   ? 	Now granted, 8086 is the breadwinner.  But according to Intel, 3 	all things come to pass, hence a new architecture.   N > Intel needs to have a chip that is easy to upgrade and make faster and which7 > it can achieve faster than AMD or other competitors.    > 	Or just as fast, cheaper and backed by billions in marketing, 	development and promotion.    > J >>         I will bet that if they can make the x86 ISA pig fly, they willL >>         make Itanium fly AND will throw the proper hundred million dollarG >>         chunks in the correct directions to ensure it is successful.  > J > The thing is that the 8086 is like a feather whereas the IA64 is like anJ > anvil. Which one is easier to make fly ? Which one costs less to lift to > higher altitude/speed ?  >   = 	Well there are hints of which has a lot more headroom.  With A 	IA32 hardware removed, the IA64 logic is 17 million transistors. @ 	Prescott logic is 70 million transisitors.  Give the Alpha boys? 	20 or 30 million logic transistors to play with... you get the 	 	picture.    >>         HP mustN >>         be excited to see high-end server costs come down to the Xeon levelK >>         (they make bucks on VMS services and NSK services).  IBM and Sun $ >>         aren't nearly as excited. > J > HP is excited at having yet another excuse to provide to customers "wait0 > another 3 years, IA64 will e better by then".   ( 	Shoot , it is better now in many areas.   > N > Sorry, but HP must stand on its own with whatever Intel offers TODAY.  If HPP > starts telling its customers to wait hold off on purchases for anyther 3 yearsK > until IA64 is really ready for prime time, guess what will happen to HP's  > business computing unit ?  >   A 	Keith mentioned 30% cheaper Itanium hardware.  That obviously is C 	a beginning point.  VMS running on much cheaper hardware is a good  	thing.   M > And in 3 years, assuming IA64 is still alive, will you be telling customers P > about that great promise from Intel that 3 years from then (6 from now), Intel5 > intends to deliver an IA64 that also makes coffee ?     A 	No.  Just give Intel's billions time to work its magic.  Keep in @ 	mind, it is all about running a highly successful business.  To@ 	suppose they lost their edge and direction is something I'm notB 	seeing (otherwise the 2 billion in profits they made last quarter 	are an anomoly?)   E 	It will be two-pronged - development and marketing.  The development ? 	that will make the difference will be building block high-end  @ 	servers.  OEM's high-end server staff will be much smaller.  We@ 	can predict this by looking at EV7 and cranking that technology= 	up a notch whereby the OEM would literally snap Intel pieces C 	together.  That is the scary part about it.  True commodization of ; 	high-end servers - brought to you by Intel.  A guess on my H 	part?  Not much of a guess.  Aaron used to be quite vocal, he now works; 	for Intel.  There are a number of posts like this.  He had = 	very legitimate points then - now he is on the other side of - 	the fence and that group is HIGHLY talented:     b http://groups.google.com/groups?selm=sfqaffk5ugg.fsf%40kraftwerk.pa.dec.com&oe=UTF-8&output=gplain  . From: Aaron Spink <spink@kraftwerk.pa.dec.com>/ Subject: Re: DEC/Intel deal and Alpha future...  Date: 1997/11/04    ? Performance!  Don't assume that IA64 will be a magic bullet for > intel.  They will still be off of the performance curve and byE designing your own chips and systems together as an integrated system E you can come out way ahead.  Remember, processors are just the grease E for the systems that they go in.  Processors are really quite useless B without a system that can take advantage of them and visa versa.      = 	It isn't much of an assumption that the team he is a part of B 	is designing an -integrated system-.  A system on a chip ala EV7. 	But just a guess ;-)    				Rob     B Men with walkie-talkie                  I'm home again to you babeC Men with flashlights waving             You know it makes me wonder G Up upon the tower                       Sittin' in the quiet slipstream > The clock reads daylight savin'         Rollin' in the thunder  .                                 -- Neil Young    ------------------------------  % Date: Wed, 11 Feb 2004 15:03:25 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! 0 Message-ID: <c0dg7u$1uk$2@new-usenet.uk.sun.com>   Keith Parris wrote: Z > Dirk Munk <munk@home.nl> wrote in message news:<bvbham$ald$1@news1.tilbu1.nb.home.nl>... > Q >>What many of us have been predicting for the last couple of years now is going  3 >>to be a reality. Intel will have 64bit x86 cpu's.  >  > D > A lot of folks are making a very big assumption here: that Intel's3 > 64-bit extensions would be compatible with AMD's.  >   9 No we arn't Microsoft don't want to do another 64bit port   C > While this would be great for AMD, how would it be for Intel?  It F > would put Intel into "me-too" territory and catch-up mode, when they? > prefer to be thought of as industry leaders.  I think Intel's H > engineering pride and their sense that they have great marketing powerA > would most likely push them to do a "better" set of extensions,  > incompatible with AMD's. > ? > We'll know more once the Intel Developer's Forum is underway.    ------------------------------    Date: 11 Feb 2004 09:39:25 -0600+ From: young_r@encompasserve.org (Rob Young) C Subject: Re: It is almost certain now, INTEL will have 64bit x86 !! 3 Message-ID: <GpaCM8kcy2Oe@eisner.encompasserve.org>    In article <c0dg7u$1uk$2@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes: > Keith Parris wrote: [ >> Dirk Munk <munk@home.nl> wrote in message news:<bvbham$ald$1@news1.tilbu1.nb.home.nl>...  >>  R >>>What many of us have been predicting for the last couple of years now is going 4 >>>to be a reality. Intel will have 64bit x86 cpu's. >>   >>  E >> A lot of folks are making a very big assumption here: that Intel's 4 >> 64-bit extensions would be compatible with AMD's. >>   > ; > No we arn't Microsoft don't want to do another 64bit port  >   9 	Microsoft may not have to.  You may be looking at a port = 	that is fully funded by Intel.  Intel throwing a few hundred E 	million and a few thousand bodies at the port.  After all, if Win64  A 	is going to take flight for x86-64 who is going to do the heavy  	 	lifting?   @ >> We'll know more once the Intel Developer's Forum is underway.  " 	Yep.  More than hints from there.   				Rob    ------------------------------  % Date: Thu, 12 Feb 2004 13:09:39 +0100 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> ( Subject: Re: Microvax vs Vaxstation 3100' Message-ID: <402B6D03.D07AAAAC@aaa.com>    JF Mezei wrote:  > N > I was under the impression that the Microvax 3100 model 30 was the same as a > Vaxstation 3100 model 30,...   Hi.   8 AFAIK, the mVAX and VAXstation had a *similar* numbering+ scheme, but was rather different systems...   	 Jan-Erik.    ------------------------------  % Date: Thu, 12 Feb 2004 13:09:00 +0000 - From: John Laird <nospam@laird-towers.org.uk> ( Subject: Re: Microvax vs Vaxstation 31008 Message-ID: <fkum2097oe5776jd69ugchv3p3kjkcdrgk@4ax.com>  H On Thu, 12 Feb 2004 03:40:54 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:  ( >Something has puzzled me for some time. > M >I was under the impression that the Microvax 3100 model 30 was the same as a L >Vaxstation 3100 model 30, except for some byte in ROM that said otherwise, ! >and the name glued to the front.  > M >However, looking back at a SOC and on various 31000 web pages, it seems that O >inside, they are quite different, with the Microvax using MS44 memory inserted L >vertically in the middle of the motherboard, while the VAXstation has thoseH >large MS42 memory boards  sandwiched horizontally over the motherboard. > J >Is there any background on why those two would be so different when their >names seem to be so similar ? > I >Did I get bad information or were those two really so different inside ? H >(Heck, I have even read that I am supposed to have 3 serial ports on my >vaxstation !)  K See http://www.algonet.se/~tucker/VaxCPUtable.txt for details of CPU family E likenesses.  The 3100 family spanned a long time and encompassed many L different technologies.  And don't get confused with Decstation 3100s either :-)    --  8 Can you still know nothing, if you don't know anything?    Mail john rather than nospam...    ------------------------------    Date: 12 Feb 2004 07:48:25 -0800& From: jordan@ccs4vms.com (Rich Jordan)( Subject: Re: Microvax vs Vaxstation 3100= Message-ID: <cc5619f2.0402120748.1d7d19a1@posting.google.com>   [ JF Mezei <jfmezei.spamnot@istop.com> wrote in message news:<402B3BED.38CD984C@istop.com>... ) > Something has puzzled me for some time.  > N > I was under the impression that the Microvax 3100 model 30 was the same as aM > Vaxstation 3100 model 30, except for some byte in ROM that said otherwise, n" > and the name glued to the front. >   = The VAXstation 3100-30 is actually a close cousin (though notk# identical) to the MicroVAX 3100-10.s  N > However, looking back at a SOC and on various 31000 web pages, it seems thatP > inside, they are quite different, with the Microvax using MS44 memory insertedM > vertically in the middle of the motherboard, while the VAXstation has those I > large MS42 memory boards  sandwiched horizontally over the motherboard.t >   A VAXstation 3100-30 uses the same ~2.4VUP CPU/memory config as theiB MicroVAX 3100-10/20.  The VAXstation 3100-38 uses the same ~3.8VUPE CPU/memory config as the Microvax 3100-10e/20e.  These models use thewF MS42-xx memory boards.  VAXstations have built in monochrome graphics,C expansion port for a color board, and lose the modem control serialn port of the MicroVAX models.  E The VAXstation 3100-76 is a later 7.6VUP system that uses the MS44-AAl4 SIMMs for memory.  There was no MicroVAX equivalent.  C The MicroVAX 3100-30/40 are 'next generation' systems released wellr> after the VAXstation 3100-30 and MicroVAX 3100-10/10e, and useE different MS44 SIMMs, not compatible with the VS3100-76 memory, but IMF believe shared with the VAXstation 4000-60 and 90-series workstations.  K > Is there any background on why those two would be so different when theirO > names seem to be so similar ?m > J > Did I get bad information or were those two really so different inside ?I > (Heck, I have even read that I am supposed to have 3 serial ports on mym > vaxstation !)O  = Unfortunate naming choice on DEC's part; since the VAXstationaA 3100-30/38/40/48 existed well before the MicroVAX 3100-30/40 werenB released, confusion was probably unavoidable when those names wereE chosen.  VAXstations 3100s do have three serial ports; one is for theuE mouse (and actually a fourth is for the keyboard).  You just lose theuD modem control port, a problem that was corrected on the 4000 series.   Rich Jordan  CCS    ------------------------------  # Date: Thu, 12 Feb 2004 14:24:40 GMTo# From: "John Smith" <a@nonymous.com>o Subject: Re: OpenVMS Feelings H Message-ID: <I0MWb.13057$cBH.12901@news04.bloor.is.net.cable.rogers.com>   Chris wrote:> > Consider yourself very fortunate.  10 years ago I might haveG > described a similar atmosphere, but creeping Windowism has turned alleC > references to the (still mission-critical) VMS systems to "legacylE > systems".  Yet day in, day out, the 30 or so "legacy" Alpha and VAX E > systems are the only ones not being constantly patched for securityeC > bugs, locking up or crashing due to sloppy kernel code, etc, etc.mE > While the critical data is serviced by a couple of ES40's with Rdb,rF > one of the plants still has 2 MicroVAX II's still chugging along forG > crying out loud!  We're down to 2 admins (1 is a contract player) andw8 > a trainee, with only part-time DBA assistance......... >PE > All the users care about is that they do what they require, but alliF > the "IT visionaries" care about is that they're not 'sexy' enough to" > justify large staffs and budget.    E Perhaps you should write a memo to your bosses and higher-ups in youroK organization (career-limiting though it may be) documenting all of this and L raising the question of why your organization is spending so much additionalK money and devoting so much time to fixing the Windows bug-of--the-hour when G a clearly superior business model exisits and is in use - though not ass widely as it should be.o  K This is where Sue & The Ambassadors (nice group name BTW) should be jumping.L in with what little is left of the so-called OpenVMS Marketing dept., and beK busy soliciting 'real-life' stories from the remaining VMS customers. These-J compiled stories from many differerent industries could be used to try andJ expand VMS usage within existing customer operations and used to dangle in front of prospective customers.h  D God forbid - it could even be adapted into an advertising campaign!!   ------------------------------    Date: 12 Feb 2004 08:06:10 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)a& Subject: Re: Other CVS on VMS problems3 Message-ID: <3$cV9FBRY5nP@eisner.encompasserve.org>n  \ In article <402B5FB4.7080300@hrem.stm.tudelft.nl>, JOUKJ <joukj@hrem.stm.tudelft.nl> writes:  G > Probably the VMS port is not correct. VMS makes a distiction between n > handling files and sockets.4  :    In most C code they are handled the same way under VMS.  B    Since the VMS port is working for some of us, I do not think it1    it is a VMS specific or port specific probelm.    ------------------------------    Date: 12 Feb 2004 08:21:21 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)7& Subject: Re: Other CVS on VMS problems3 Message-ID: <QLJq7D+IFo2V@eisner.encompasserve.org>O  b In article <200402101347.59517.kpederson@ewu.edu>, Kaleb Pederson <kpederson@mail.ewu.edu> writes:L > '-d' should definitely work as it specifies the directory (in this case a O > remote module) that should be pulled.  The documentation (in the info pages) . > on '-p' say the following: >  >  `-p'rG >      Pipe the files retrieved from the repository to standard output, I >      rather than writing them in the current directory.  Available with , >      the `checkout' and `update' commands. >   H    Oops, I got the castrated command flags mixed up again.  I meant I've#    only used it with pserver, as ink  !    cvs -d :pserver:otherhost:pathi  L > Bob, what version of CVS are you running?  I'm currently running the only ) > version that I was able to find online?l      cvs --version returns 1.9.27t   ------------------------------  % Date: Thu, 12 Feb 2004 08:01:19 -0800w- From: Kaleb Pederson <kpederson@mail.ewu.edu>e& Subject: Re: Other CVS on VMS problems2 Message-ID: <200402120801.19062.kpederson@ewu.edu>  N Bob thanks.  I'll try it again with a couple public pservers and see if I can  get it to work.o  M I'm running the same version as you, so hopefully I can at least get that to s work.i   --Kaleb   1 On Thursday 12 February 2004 06:21 am, you wrote: D > In article <200402101347.59517.kpederson@ewu.edu>, Kaleb Pederson   <kpederson@mail.ewu.edu> writes:M > > '-d' should definitely work as it specifies the directory (in this case a I > > remote module) that should be pulled.  The documentation (in the infot% > > pages) on '-p' say the following:o > > 	 > >  `-p'wI > >      Pipe the files retrieved from the repository to standard output, K > >      rather than writing them in the current directory.  Available with . > >      the `checkout' and `update' commands. >cJ >    Oops, I got the castrated command flags mixed up again.  I meant I've% >    only used it with pserver, as ina > # >    cvs -d :pserver:otherhost:pathg >hM > > Bob, what version of CVS are you running?  I'm currently running the only + > > version that I was able to find online?l >y! >    cvs --version returns 1.9.27i   ------------------------------    Date: 12 Feb 2004 10:49:30 -0800* From: denny.rich@swagelok.com (Denny Rich)J Subject: Re: page- and swap-files, autogen, modparams.dat, file-naming etc< Message-ID: <d28306e.0402121049.31d7d379@posting.google.com>  | helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) wrote in message news:<c0fgtj$dic$1@online.de>...> > In article <d28306e.0402110625.12b7dc94@posting.google.com>,/ > denny.rich@swagelok.com (Denny Rich) writes: f > F > > AUTOGEN doesn't really care about the pagefile names.  Remove themH > > from modparams.dat. YOu could name them "dog.hair", or "cat.fur", or7 > > "vmem_a.page" or "pagefile_1.sys" or anything else.  > F > If I want to size specific files, how does it now which ones I mean?  F I don't want AUTOGEN resizing the files for me, so what I have done isB to place these lines in the individual MODPARAMS.DAT files on each node:u  4    PAGEFILE=0 ! Tell AUTOGEN not to resize page file4    SWAPFILE=0 ! Tell AUTOGEN not to resize swap file4    Dumpfile=0 ! Tell AUTOGEN not to resize dump file  D Then, I look at the agen$params.report after autogen runs, and checkA out AUTOGEN's recommendations.  Remember, these files should onlyd8 change size if you add bunches of memory to your system.  ; If AUTOGEN recommends wild changes (more than 1 or 2% aftereA stabilization) there is something very wrong. In practice, I have'' found these sizes to be *quite* stable.e  D If you need to resize one or more of your files, here is the command you can use:       $  mcr sysgendA      SYSGEN> CREATE PAGE_ONE:[NODE1]PAGEFILE_1.SYS;1 /SIZE=300000h  E Two *very* important notes:  If you use the exact filespec, includingeC version number, and if you specify a size greater than the existing E size, SYSGEN will do its best to extend the existing file. Otherwise,.C if you leave off the version, it will create a new file.  In either C case, if there is insufficient contiguous space on the disk, SYSGENyA will do what it can, and then complain. So, if the disk is nearlyV4 full, you may have to defrag it to get this to work.  D If you do create a new file, be sure to purge away the old one afterA the next reboot as it will be occupying a good piece of your pageX disk.r   > J > > Then use SYSGEN to create the files you want where you want them. MostD > > systems do well with one large or maybe 2 medium sized files. ifE > > paging is heavy, you can spread them around on more than one diskuI > > (just don't make things too complicated. This was more important withx > > old, slow, RA devices.)h > >  > >   $ mcr sysgenB > >    SYSGEN>  CREATE PAGE_ONE:[NODE1]PAGEFILE_1.SYS /SIZE=200000 > > I > > then edit Sys$startup:sypagswpfiles.com: The file names and locations0E > > you use here *must* match what you created in sysgen (above). adddF > > lines to mount any disk(s) that will hold page files. for example: > > D > >   $  mount/system/noassist/NOREBUI $1$dua1710: page_one page_one > > 4 > >   add a line to "load" each of the pagefiles....? > >   $  mcr sysgen install page_one:[node1]pagefile_1.sys/paged > >  > > Then reboot the system.. >  > I've done all of that. > J > > All AUTOGEN cares about is the *total* pagefile space it finds when itE > > runs (on the running system).  IT then guesses at what you shouldk9 > > have, and either says its ok, or recommends a change.  > > I > > Also, the boot process *assumes* it knows where there is at least one-I > > page file. you don't have to have this one; but IF you DON'T HAVE IT,a9 > > you should have some (one or more) files installed by ' > > sypagswpfiles.com (see note above).. > ( > I have the default ones in SYS$SYSTEM.   ------------------------------  % Date: Wed, 11 Feb 2004 05:54:19 -0500a* From: JF Mezei <jfmezei.spamnot@istop.com># Subject: Re: PSION, another Digital1) Message-ID: <402A09AA.1F80D16B@istop.com>l   John Smith wrote:hE > > Seems that everytime I choose a product because it is technicallyg
 > > superior,^A > > the owner disagrees with me and works hard to get rid of thato > > product. It - > > happened with Digital/VMS and with PSION.t > N > I guess companies that want to survive will have to stop selling products to > you then.  ;-)    J Perhaps Sue or Mr Gorham should fund my purchase of a Sun workstation... I2 would jinx Sun and maybe give VMS a better chance.   ------------------------------  % Date: Wed, 11 Feb 2004 15:01:57 +0000lO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>l" Subject: Re: Rumours of (CPU) Wars0 Message-ID: <c0dg55$1uk$1@new-usenet.uk.sun.com>   Keith Parris wrote:  > Andrew Harrison SUNUK Consultancy <Andrew No.Harrison No@nospamn.sun.com> wrote in message news:<bvb1b6$mnq$1@new-usenet.uk.sun.com>...m > ) >>x86-64 is a full 64bit architecture, it : >>currently has a physical address space of 40 bits enough< >>to address 1 TB or RAM. Itanium has a 50 bit address space< >>which if you are using the "only" 40 bits argument against9 >>Opteron as a way of claiming that it isn't a 64 bit CPUe' >>also means that Itanium isn't either.t >  > . > Virtual address space, Andrew, not physical. >  > According to AMD's website atsT > http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_8826_8805,00.html- > Opteron has a 48-bit virtual address space.r  > This is from the AMD page, you will note that it confirms that? my point about the 40 bit physical address space is correct and- you point was well pointless.   B "64-bit wide key data and address paths that incorporate a 48-bit F virtual address space and a 40-bit physical address space 64-bit wide E key data and address paths that incorporate a 48-bit virtual address  * space and a 40-bit physical address space"   Regards  Andrew Harrisonc   ------------------------------  % Date: Thu, 12 Feb 2004 12:04:06 -0600M( From: brandon@dalsemi.com (John Brandon) Subject: SFTP/SCP on VMS1 Message-ID: <04021212040652@dscis6-0.dalsemi.com>W  . Just installed SSH on my VMS V7.2 server from:  . http://www.er6.eng.ohio-state.edu/~JONESD/ssh/    + Been looking around for SFTP/SCP downloads.v  @ Looking through openvms.org I find that there is none available.  D Only by upgrading to VMS 7.3 or using Multinet/TCPware can I get it.    / Now this is not an option for me at this point.r    0 Anyone have a copy or know if it is in the pike?   (or) Did I miss something?     TIAo     J*o*h*n B*r*a*n*d*o*na VMS Systems Administrator-* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  % Date: Thu, 12 Feb 2004 11:19:08 -0700_% From: Dan O'Reilly <dano@process.com>n Subject: Re: SFTP/SCP on VMS= Message-ID: <6.0.0.22.2.20040212111824.021b6410@192.168.0.11>.  D You can also purchase "SSH for OpenVMS" from Process Software if you? need to maintain your HP TCPIP Services (nee: UCX) environment.x  * At 11:04 AM 2/12/2004, John Brandon wrote:/ >Just installed SSH on my VMS V7.2 server from:h > / >http://www.er6.eng.ohio-state.edu/~JONESD/ssh/n >d >n, >Been looking around for SFTP/SCP downloads. > A >Looking through openvms.org I find that there is none available.  >tE >Only by upgrading to VMS 7.3 or using Multinet/TCPware can I get it.e >u >t0 >Now this is not an option for me at this point. >a >f1 >Anyone have a copy or know if it is in the pike?  >  >(or) Did I miss something?e >n >  >TIA >t >s >J*o*h*n B*r*a*n*d*o*n >VMS Systems Administrator+ >firstname.lastname.spam.me.not@dalsemi.comr   ------J +-------------------------------+----------------------------------------+J | Dan O'Reilly                  |  "There are 10 types of people in this |J | Principal Engineer            |   world: those who understand binary   |J | Process Software              |   and those who don't."                |J | http://www.process.com        |                                        |J +-------------------------------+----------------------------------------+   ------------------------------  + Date: Thu, 12 Feb 2004 16:22:25 +0000 (UTC)a, From: lewis@mazda.mitre.org (Keith A. Lewis)G Subject: Re: SYS$STARTUP:MMOV$STARTUP.COM -- lacks something (priority) . Message-ID: <c0g981$j9t$1@newslocal.mitre.org>  m sms@antinode.org writes in article <04021121470117@antinode.org> dated Wed, 11 Feb 2004 21:47:01 -0600 (CST):eH >   I'd like to know if anyone else has hit this, or if I'm the only oneH >foolish enough to put this into a batch job instead of mainlining it in >SYSTARTUP_VMS.COM.   F I had a related problem and solved it in a similar way.  I was gettingE choppy playback when I did things in user processes because they wereSJ competing with both the music playback application and MMOV$SERVER.  I setJ the /BASE_PRIORITY on the audio queue and the MMOV$SERVER process priority to 8, and it's much better.   F Actually the problem is recurring in a different way since I moved theD music library to a Linux disk and now play it over NFS.  Thinking ofI copying to a scratch directory on VMS before playing... if I can't figurenA out how to raise the priority of the NFS-serving Linux processes.i  L Do you get a popping sound between songs due to audio device resets?  I have a solution to that.r  0 --Keith Lewis              klewis {at} mitre.org> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Thu, 12 Feb 2004 16:23:00 -0000s* From: "Richard Brodie" <R.Brodie@rl.ac.uk> Subject: Re: VMS and Unicode, Message-ID: <c0g994$14qi@newton.cc.rl.ac.uk>  7 "Denny Rich" <denny.rich@swagelok.com> wrote in messagea5 news:d28306e.0402111018.7c89d68@posting.google.com...?  F > As I understand the Unicode issue, it means that any given characterG > may consist of a byte stream of from 1 to many bytes. I don't know ifr& > the byte count is fixed or variable.  9 Unicode has a number of encodings. One of the more usefult? and interesting encodings is UTF-8, where the characters in theW> range 0-127 (i.e. those corresponding to the ASCII characters)< are encoded using a single byte. This means that plain ASCII@ text is unchanged but the format can accomodate the full Unicode character set.  ? Since the character set for all HTML documents is Unicode, this ; kind of issue comes up all the time in HTML/XML processing.rA Pick your favourite language, and see what library support it has  for web plumbing.u  4 Something quick and dirty would be to encode all the7 characters not representable in ASCII as XML entities -t two line Python prototype:   $ python8 Python 2.3 (#0, Aug  4 2003, 08:46:25) [DECC] on OpenVMSF Type "help", "copyright", "credits" or "license" for more information. >>> temperature = u"37C"': >>> print temperature.encode("ascii", "xmlcharrefreplace")	 37&#176;C   A The application specific way of handling the extra characters may6E be more interesting. Specifying that is the hard part of the problem, G as I see it: everything else is, as you say, just using a lookup table.e   ------------------------------  # Date: Thu, 12 Feb 2004 16:46:42 GMT 6 From: "Craig A. Berry" <craigberry@mac.com.spamfooler> Subject: Re: VMS and Unicode@ Message-ID: <6881069ab32a6ead6489d52afc32764a@news.teranews.com>  ; In article <d28306e.0402111018.7c89d68@posting.google.com>,r,  denny.rich@swagelok.com (Denny Rich) wrote:  % > As I understand the Unicode issue, s  B I'm not sure anyone fully understands Unicode, but there is a lot - more information at <http://www.unicode.org>.   # > it means that any given characteriG > may consist of a byte stream of from 1 to many bytes. I don't know if & > the byte count is fixed or variable.  D It depends on what encoding has been chosen.  There are fixed-width E encodings (UCS-2 and UCS-4) but for data transfer purposes, UTF-8 is eH most common because, among other reasons, it is byte order independent, C and yes, it does have varying width characters.  XML documents are  G assumed to be encoded in UTF-8 unless specified otherwise.  Java class iD files are stored in UTF-8 (but Java string classes store strings in  UCS-2).8    B > Using this bytestream, it is possible to encode most symbols and% > characters in most major languages.e > ? > We need to map some of those characters to the ASCII that ouro" > applications know how to handle.  E "that our applications know how to handle" is a huge qualification.  aG Which ASCII?  All are pretty much in agreement about the 0-127 values, n9 but there are a large variety of so-called "upper ASCII"  D implementations defined by vendors and the ISO standards committees F that determine how the 8th bit is interpreted.  FWIW, a UTF-8-encoded E byte is also identical to an ASCII character up to and including the tH 7th bit.  If your software is a set of VMS applications, there's a good H chance you are talking about the DEC Multinational Character Set or one  of the DEC national sets.   G > So, there will be some bit pattern that identifies the "euro currency A > character" (I picked this because its probably not in the ASCIIaH > character set). When this is encountered, our ASCII-based software canG > make some internal 'notation' that the currency to follow is in Eurosr > rather than in yen or pesos. > D > Similar process for the little "degree mark" (small raised circle)F > that is  a common part of european street addresses, as well as partG > of temperature specifications. Our application could note that we are ? > talking about "degrees", or a floor in a particular building.s > E > We envision feeding this Unicode stream to VMS, where there will befG > some "transformation" done that will make Unicode understandable to a B > VMS application. at least, the transformation will translate theA > Unicode into some representation meaningful to our application.   F Yep, but you'll have to define what "representation meaningful to our H application" really means.  You may be talking about a simple character G conversion, where some Unicode character has an appropriate mapping to eE a character in the local version of ASCII.  But do you know that all  G the characters you'll be getting have an appropriate equivalent in one  A or another version of ASCII?  Remember there are as many Unicode oE characters as can be stored in a 32-bit integer, but each version of WH ASCII has only as many characters as can be stored in an 8-bit integer.   n  C Matters of language, font, and output device are separate from but tD overlap with character set issues.  If you are getting Unicode text C that may be either in French or Finnish, you may need to determine  F which it is and convert to a different version of ASCII accordingly.  @ Whether the resulting text will display properly depends on the H capabilities of your output device.  For example, someone has mentioned F that the euro symbol is now in DEC/hp's proprietary ASCII, and recent E versions of DECWindows have fonts that will display it properly, but  B that doesn't necessarily mean it will display on a VT terminal or  terminal emulator.    H > One way to do this, would be to build a "transform program" that has aE > big lookup table in it and provides Unicode-to-ASCII conversion fory? > characters of interest and based partly on the context of the H > character within the message.  This could be home-grown or commercial.F > You could even do this in hardware, using a couple of big EPROMS for > the translation. Very fast.   C Yikes.  Don't reinvent the wheel if what you're doing is character mF conversion.  If you need to expand certain characters into some other F form of representation (such as converting the degree symbol into the G English word "degrees") then you may have to build your own translator.l  A > I took a cursory look at the VMS doc CD but didn't come up witht > anything startling.n  G Read chapter 10 of the CRTL manual entitled, "Developing International cC Software".  I'd give you a URL but they keep changing them so it's  D hardly worth it.  As others have mentioned, you have to install the = optional  internationalization kit in order to get the UTF-8 d conversions.    G Since you have a recent OS version, I believe you have Java out of the e< box, which includes all sorts of character set manipulation . capabilities, IIRC in the java.text namespace.  B I have a soft spot for Perl.  Perl 5.8 and later includes Unicode 
 support.  Seee   $ perldoc perluniintro   or  6 http://www.perldoc.com/perl5.8.0/pod/perluniintro.html  > You can do conversions with the bundled Encode module like so:           use Encode 'from_to'; .         from_to($data, "iso-8859-1", "utf-8");   ------------------------------  % Date: Thu, 12 Feb 2004 15:28:06 +0100s* From: Paul Sture <nospam@sture.homeip.net>% Subject: Re: Why was VAX abandonned ?e0 Message-ID: <402B9B86.37D29226@sture.homeip.net>   John Laird wrote:o > L > On Wed, 11 Feb 2004 23:37:34 +0800, Paul Repacholi <prep@prep.synonet.com> > wrote: > < > >jones.computer.srv@worldnet.att.net (Daryl Jones) writes: > > I > >> I was told about this problem with VMS when I was managing a VAX 750pB > >> using VMS 2.5 (1982) by someone who ran a VAX/VMS timesharing > > C > >I think you may be confusing a few details. AIR, the 7xx supporte* > >didn't appear and work until 3.x or so. > L > Given that V1.0 only ran on a 780, I don't understand your last statement.4 > What do you think 1.x and 2.x supported, exactly ? > K > The 750 arrived around the same time as 2.0 (1980?)  The 730 and 3.0 alsol) > arrived at about the same time (1982?).i >   < From page 60 of the "OpenVMS at 20 Nothing Stops it book" at  ' http://h71000.www7.hp.com/openvms/20th/c  / V2 April 1980 contained support for the 11/750. ? V3 April 1982 contained support for the 11/730, 11/725, 11/782.   K > [Those were the days when smart cookies only ran .odd number releases and C > scheduled time off immediately after preventative maintenance...]  >   H But if you were a software house you got it pretty early on to see where; it broke your apps or previous assumptions about tuning :-)o   -- t
 Paul Sture   ------------------------------  % Date: Thu, 12 Feb 2004 15:15:58 +0000s From: Roy Omond <Roy@Omond.net>r6 Subject: [OT] Solaris crashes itself when /tmp is full4 Message-ID: <c0g5bi$cg0$1$8302bc10@news.demon.co.uk>  9 Gentle colleagues, forgive me for posting this in c.o.v.,I but that's where I live.  9 I'm currently with a small company which does support forh< VMS, Tru64 and (amongst others) Solaris.  One of our clients; asked us to investigate a crash they had recently, and thist1 what what was offered from Sun as an explanation:    Quote:  F Sun found the problem from just looking at the messages.0 log. Here is the explanation:  D 1) From "Feb 2 12:35:06" in the messages.0 log there were error msgs8 reporting that /tmp was full, which is a very bad error:  F xxxxx unix: WARNING: /tmp: File system full, swap space limit exceeded  F 2) The OS eventually crashed itself to resolve the problem (this would> have cleaned out /tmp) at 16.59 and then came back up at 17.07   unQuote.  C I have asked my colleagues who deal with Solaris if it is true that-B Solaris will crash itself if /tmp gets full (for non-Unix persons,A /tmp is usually a scratch directory where everyone can write to).E@ Astonishingly it is indeed so.  So any black-hat, non-privilegedA JoeBloggs user could fill /tmp and, *bang*, away goes the system.h) Or even a white-hatted user by accident ?   < I'm sure there are quite a few others here with more Solaris$ experience than I have (Andrew ? :-)   Any comments ?   A flabbergasted Roy Omondt Blue Bubble Ltd.   ------------------------------  % Date: Thu, 12 Feb 2004 11:40:21 -0500 * From: "Chris Moore" <moore_mc@hotmail.com>: Subject: Re: [OT] Solaris crashes itself when /tmp is full/ Message-ID: <Z%NWb.813$Ks6.9978@nnrp1.uunet.ca>j  K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>!; wrote in message news:c0g8os$1qs$1@new-usenet.uk.sun.com...     " > Why would you be flabbergasted ? >u  D Maybe he foolishly thought that something called "tmp" wasn't system* critical.  Silly non-eunuchs, I mean -UNIX   ------------------------------  + Date: Thu, 12 Feb 2004 16:45:47 +0000 (UTC)o From: david20@alpha2.mdx.ac.uk: Subject: Re: [OT] Solaris crashes itself when /tmp is full) Message-ID: <c0gajr$741$1@news.mdx.ac.uk>h  g In article <402BA1B8.18896617@blueyonder.co.uk>, Tim Llewellyn <tim.llewellyn@blueyonder.co.uk> writes:  >u >  >Roy Omond wrote:  >  >> Any comments ?e >>   >> A flabbergasted Roy Omond >> Blue Bubble Ltd.a >iT >Sure, it is a unix "weakness". Some syadmins have cron jobs to monitor and clean up >/tmp. >tP >VMS also will have problems if SYS$SYSDEVICE fills up. I have seen this happen 0 >with LPD printer logs at a site many years ago. >   O In my experience that has never crashed the system. I've had the system disk go N to zero blocks on a number of occasions over the years. It's not something youB want to happen but it's recoverable by just freeing up some space.  O Also although the default (at least with TCPIP services) is for the LPD printerkG logs to be placed on the system disk you can override this and put themh
 elsewhere.  
 David Webb VMS and Unix team leader CCSS Middlesex University   >regards >g >--  >tim.llewellyn@blueyonder.co.uk6   ------------------------------  % Date: Thu, 12 Feb 2004 16:57:33 +0000 O From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com>o: Subject: Re: [OT] Solaris crashes itself when /tmp is full0 Message-ID: <c0gb9t$2mc$2@new-usenet.uk.sun.com>   david20@alpha2.mdx.ac.uk wrote:ei > In article <402BA1B8.18896617@blueyonder.co.uk>, Tim Llewellyn <tim.llewellyn@blueyonder.co.uk> writes:h >  >> >>Roy Omond wrote: >> >> >>>Any comments ?t >>>a >>>A flabbergasted Roy Omond >>>Blue Bubble Ltd.t >>U >>Sure, it is a unix "weakness". Some syadmins have cron jobs to monitor and clean up  >>/tmp.I >>Q >>VMS also will have problems if SYS$SYSDEVICE fills up. I have seen this happen 21 >>with LPD printer logs at a site many years ago.  >> >  > Q > In my experience that has never crashed the system. I've had the system disk go P > to zero blocks on a number of occasions over the years. It's not something youD > want to happen but it's recoverable by just freeing up some space. > Q > Also although the default (at least with TCPIP services) is for the LPD printersI > logs to be placed on the system disk you can override this and put them  > elsewhere. >   B As you could for /tmp in fact you could set TMPDIR for each of the7 users to a "userhomedir"/tmp directoy if you wanted to.    regardsa Andrew Harrisons > David Webb > VMS and Unix team leader > CCSS > Middlesex University >  > 	 >>regards  >> >>-- '  >>tim.llewellyn@blueyonder.co.uk   ------------------------------  # Date: Thu, 12 Feb 2004 17:30:33 GMTa9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com>e: Subject: Re: [OT] Solaris crashes itself when /tmp is full/ Message-ID: <ZKOWb.281$fO7.94@news.cpqcorp.net>f  K "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com> ; wrote in message news:c0g8os$1qs$1@new-usenet.uk.sun.com...h >sA > It looks like you have a user/process problem. Does OpenVMS run ) > indefinitely if you fill its disks up ?-  F To some degree, yes.  You might end up in situations where some thingsH (applications) will hang or die as they fail to get space.  In addition,H there are not a lot of situations that would allow a unprivleged user to trivially fill the system disk.    ------------------------------   Date: 12 Feb 2004 17:56:44 GMT, From: bill@gw5.cs.uofs.edu (Bill Gunshannon): Subject: Re: [OT] Solaris crashes itself when /tmp is full: Message-ID: <c0geos$15r2cs$1@ID-135708.news.uni-berlin.de>  0 In article <402BA1B8.18896617@blueyonder.co.uk>,7 	Tim Llewellyn <tim.llewellyn@blueyonder.co.uk> writes:v >  >  > Roy Omond wrote: >  2 >> Any comments ?- >>   >> A flabbergasted Roy Omond >> Blue Bubble Ltd.m > U > Sure, it is a unix "weakness". Some syadmins have cron jobs to monitor and clean up0 > /tmp.    Here we go again.V  F No, it is not a Unix weakness.  None of the numerous servers I run nowG will crash if /tmp fills up and none that I remember in the past (which F goes back a couple of decades).  The worst that is likely to happen isC that some application (vi comes immediately to mind) might not work 	 properly.l  C I am curious enough about this that I plan to set up a machine withyD Solaris 9 and test this myself.  Even if it turns out to be true, itD is easily remedied and probably would have been, before the fact, by% any really experienced Unix Sysadmin.g   bill   -- iJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   0   ------------------------------  # Date: Thu, 12 Feb 2004 17:58:07 GMTs4 From: brad@.gateway.2wire.net (Bradford J. Hamilton): Subject: Re: [OT] Solaris crashes itself when /tmp is full0 Message-ID: <P8PWb.294494$xy6.1449900@attbi_s02>   In article <c0gb9t$2mc$2@new-usenet.uk.sun.com>, Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> writes:  !david20@alpha2.mdx.ac.uk wrote: !snip! !> 7R !> In my experience that has never crashed the system. I've had the system disk goQ !> to zero blocks on a number of occasions over the years. It's not something youiE !> want to happen but it's recoverable by just freeing up some space.w !> eR !> Also although the default (at least with TCPIP services) is for the LPD printerJ !> logs to be placed on the system disk you can override this and put them
 !> elsewhere.e !> i !tC !As you could for /tmp in fact you could set TMPDIR for each of theg8 !users to a "userhomedir"/tmp directoy if you wanted to. !   L I used to make sure that /tmp was on a different disk from / on my Linux and FreeBSD boxes at home.   !regards !Andrew Harrison
 !> David Webb  !> VMS and Unix team leaderr !> CCSS  !> Middlesex Universityv !> e !> e
 !>>regards !>>A !>>-- ! !>>tim.llewellyn@blueyonder.co.ukm !r   ------------------------------  % Date: Thu, 12 Feb 2004 17:40:42 +0000eO From: Andrew Harrison SUNUK Consultancy <Andrew_No.Harrison_No@nospamn.sun.com> : Subject: Re: [OT] Solaris crashes itself when /tmp is full0 Message-ID: <c0gdqq$3h5$2@new-usenet.uk.sun.com>   Fred Kleinsorge wrote:M > "Andrew Harrison SUNUK Consultancy" <Andrew_No.Harrison_No@nospamn.sun.com>s= > wrote in message news:c0g8os$1qs$1@new-usenet.uk.sun.com...i > A >>It looks like you have a user/process problem. Does OpenVMS runt) >>indefinitely if you fill its disks up ?0 >  > H > To some degree, yes.  You might end up in situations where some thingsJ > (applications) will hang or die as they fail to get space.  In addition,J > there are not a lot of situations that would allow a unprivleged user to! > trivially fill the system disk.e >  >   @ Solaris isn't allowing an unpriviledged user to fill up a system, disk /tmp isn't generally a disk its memory.   Regards  Andrew Harrisond   ------------------------------  + Date: Thu, 12 Feb 2004 13:04:15 -0500 (EST)D+ From: Lord Isildur <isildur@andrew.cmu.edu>4: Subject: Re: [OT] Solaris crashes itself when /tmp is fullI Message-ID: <Pine.LNX.4.58-035.0402121258140.10812@unix44.andrew.cmu.edu>X   yuck!3J just give the users quotas on a tmp volume or something! mucking with (andJ expecting lots of programs (and users!) to abide by) environment variablesL when there is no way to know it will even cause your desired behavior is not the way to approach this.hI nevermind that solaris' bright idea of putting swap on the same partition:L as whatever is mounted in /tmp is one of the most retarted of many extremelyL stupid things theyve done over the years, still, a saner solution is to just use quotas..L as an aside, on the solaris systems ive used, if more swap space was needed,L files in /tmp would just start disappearing, a full /tmp would not cause the) system to run out of swap space or crash."    W > >>Sure, it is a unix "weakness". Some syadmins have cron jobs to monitor and clean upe	 > >>/tmp.o  E (whoever wrote this, i didnt follow all the attributions) this is notrC a _unix_ thing, this issue is very much an idiosyncracy of solaris.e    = On Thu, 12 Feb 2004, Andrew Harrison SUNUK Consultancy wrote:gD > As you could for /tmp in fact you could set TMPDIR for each of the9 > users to a "userhomedir"/tmp directoy if you wanted to.        my .02,a isilduri   ------------------------------   End of INFO-VAX 2004.085 ************************