1 INFO-VAX	Sun, 06 Jun 2004	Volume 2004 : Issue 313       Contents:: Re: Make Long URLs short (Was: Re: Scripting SET PASSWORD) Merci 1 Re: New IA64 binaries run on Old IA64 computers ? ! Re: Oracle statement of direction . Re: Q: DECWindows V1.2 Bindings & Translations  F ----------------------------------------------------------------------  % Date: Sun, 06 Jun 2004 10:39:29 +0200 0 From: Keith Cayemberg <keith.cayemberg@arcor.de>C Subject: Re: Make Long URLs short (Was: Re: Scripting SET PASSWORD) B Message-ID: <40c2d842$0$26348$9b4e6d93@newsread4.arcor-online.net>   Rob Young wrote:r > In article <Nt2wc.2538$jK6.2353@newssvr23.news.prodigy.com>, Michael Austin <maustin@firstdbasource.com> writes: >  >>Michael Austin wrote:  >  > ' >>And by far this simplest way is from:  >><<  = >>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=  > 2 > 62q69m%249qt%40topgun.es.dupont.com&rnum=7&prev=8 > /groups%3Fq%3Dgroup:comp.os.vms%2Bdcl%2Bset%2Bpassword2 > %2Bcaptive%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm8 > %3D62q69m%25249qt%2540topgun.es.dupont.com%26rnum%3D7  >  > > > 	The 2 or three minutes to cut and paste that URL is brutal. > 	Here's a tip... > @ > 	The article you are referring to, you can click on "view this@ > 	article only" then click on original format and the URL looks
 > 	like this:  > X > http://groups.google.com/groups?selm=62q69m%249qt%40topgun.es.dupont.com&output=gplain >   = You can make the Google URL a little shorter by removing the  7 "&output=gplain" at the end of the original format URL.   H http://groups.google.com/groups?selm=62q69m%249qt%40topgun.es.dupont.com  E Then you also get the thread link and a pretty format with the short  G URL. I saw this technique described in a COV discussion some years ago.    Cheers!    Keith C.   ------------------------------  % Date: Sun, 06 Jun 2004 18:37:01 +0200 " From: Didier Morandi <no@spam.com> Subject: Merci. Message-ID: <c9vh7e$1shv$1@biggoron.nerim.net>   6-JUN-1944 ~ 6-JUN-2004    Merci.   D. French   ------------------------------  * Date: Sun, 6 Jun 2004 15:44:46 +0000 (UTC) From: david20@alpha2.mdx.ac.uk: Subject: Re: New IA64 binaries run on Old IA64 computers ?) Message-ID: <c9ve5e$8bg$1@news.mdx.ac.uk>   U In article <40C0C524.4070805@MMaz.com>, "Barry Treahy, Jr." <Treahy@MMaz.com> writes:  >JF Mezei wrote: > ; >>(Lets assume for the moment that IA64 survives 13 years).  >> >>P >>I can run the latest version of VAX-VMS on my teenage allmighty Microvax II. IP >>think that it is simply because only a couple of support files specific to theL >>MVII are needed early in the boot, and after that, VMS runs transparently.
 >>(Correct ?)  >>P >>However, with compilers so tighly tied to the IA64 CPU to take advatage of CPUE >>changes/imrprovemenst for performance, will a version of VMS OS and N >>applications compiled for Itanium 4  with Itanium 4 compilers be able to runL >>on Merced boxes ? (eg: in the future, will binaries for recent IA64s still >>work on much older IA64s ?)  >>L >>Won't IA64 compilers in the future generate code that assumes that certainI >>tricks are possible on IA64 ? What happens when that code executes on a M >>generation of IA64 that precedes the addition of those performance tricks ?  >>O >>Or is IA64 now a "stable" architectire with no more changes coming in the way I >>compilers generate code to provide about half the performance of IA64 ?  >>   >>C >I'm not a Itanic fan, in fact I think it is the 21st centuries IT  D >disaster just wanting to happen.  None the less, the same problems C >impacted VAX & Alpha too, but this was dealt with at the hardware  H >abstraction layer, so if Intel/HP use a HAL for IA64 to protect the OS B >from odd differences in chipsets that basically perform the same A >function, it shouldn't be an issue...  If they don't then prior  E >discussions of binary portability may come into play, but the other  E >factor is that over 13 years, when considering how much VMS changes  H >during the past decades, we've 'lost' binary portability several times = >with new hardware but also at major dot releases when major  , >functionality was integrated into the OS... > G Apart from the VAX -> Alpha transition I'm not aware of any lost binary / portability of VMS due to changes in the chips. M There has of course always been the potential for lost binary portability for = user programs utilising kernel structures when upgrading VMS.   L The possibility of tying VMS to the chip version has always been there sinceN the compilers such as C include /archicture qualifiers. However as far as I amL aware VMS has never been complied with anything other than the /ARCH=GENERIC option.   O Some thirdparty applications do utilise these architecture compiler options for 6 instance Oracle recently stopped supporting EV5 chips.  N Given that Itanium is much more dependent for performance on the optimisationsJ performed by its compilers than Alpha I would suspect that both thirdpartyM applications and the base VMS operating system will probably need to make use L of such architecture qualifiers in the future in order to boost performance.M Since as Oracle has demonstrated thirdparty suppliers do not like supporting  N multiple versions compiled with different compiler options it is probable thatJ the lifcycle of a VMS itanium system will be much shorter than that for anF Alpha system if the users wish to use the latest versions of software.  
 David Webb VMS and Unix team leader CCSS Middlesex University         >  >Barry >  >--  > ? >Barry Treahy, Jr                       E-mail: Treahy@MMaz.com ? >Midwest Microwave                          Phone: 480/314-1320 ? >Vice President & CIO                         FAX: 480/661-7028  >                        >  >    ------------------------------  % Date: Sun, 06 Jun 2004 09:15:21 -0600 4 From: Norman Lastovica <norman.lastovica@oracle.com>* Subject: Re: Oracle statement of direction* Message-ID: <40C33509.F13B10E6@oracle.com>  < On-disk format remains the same.  So you'll be able to share= an Rdb 72 database between Alpha and IPF in a cluster as well > as be able to 'quickly' (matter of seconds) convert a database: to Rdb 72 format (and, of course, still be able to roll it1 back to the prior level if you feel the need to).    Richard Maher wrote: > ? > C'mon Norm, do I really have to raise a TAR to find this out?  > E > Yes, I am pretty sure that even your Row-Cache fuelled pathological H > indifference to all things Clusters could not drive you to force loyalN > Rdb/VMS customers into a Big-Bang conversion approach. And there's obviously> > no need for me to tell everyone here about the benefits of aD > mix-architecture clusters and the convenience (more often than notG > necessity) of porting one application, or part there of, at a time to M > itanium while still being able to access the same data from their tried and L > test bank of Alpha/VAX applications. But my paranoia has me hearing voicesN > that sound a lot like Bill Gettys saying some bullshit like "Rdb engineeringJ > has taken this opportunity to reorganize the internal page format in theG > database to exploit fully the performance features of the new itanium L > architecture and to convert some word and longword constructs to quadwordsK > to solve VLDB issues." _or_ "Having consulted extensively with our client M > base(1) we've realized that most customers will be deploying strictly "new" J > applications on there itanium hardware and will be gradually phasing outM > their existing Alpha hardware. While we at Rdb engineering will continue to D > support Alpha/Rdb for many years to come we will not be supportingI > mix-architecture clusters at this time due to lack of demand. This will K > allow us to concentrate our resources on exploiting fully the features of . > the itanium architecture such as Row-Cache." > L > If you let 'em get their hands on clusters at this stage you may never getN > them back to Row-Cache. You must do whatever it takes to stop this from thisK > from happening!! Save these stupid cluster worshippers from themselves!!!  >  > Regards Richard Maher  > K > (1) "Client Base" - The same sycophantic ring-kissers you always speak to  > get the answers you want.  > > > Richard Maher <maher_rj@hotspamnotmail.com> wrote in message, > news:c7igko$7n4$1@sparta.btinternet.com... > > Hi Norm, > > K > > > With these releases, both database and applications will run entirely  > > > on Itanium.  > > N > > I just re-read your note and wanted to check on something. I'm pretty sureL > > that your comment above was just refering to the time when an rdb$remoteI > > attachment to an Alpha would no longer be a *requirement* but can you K > > confirm that the on-disk structure of Rdb databases on Itanium will not K > > differ from those on VMS and mixed-architecture cluster support will be  > > there from year dot? > >  > > Regards Richard Maher  > > I > > PS. Does anyone know the final outcome of VMS engineering support for  > VAXes L > > in a mixed-architecture cluster with Itanium? Last I heard (I think fromL > > Hoff) was something like "We're not doing anything to break it but won't > be > > certifying it will work".  > > C > > Norman Lastovica <norman.lastovica@oracle.com> wrote in message ( > > news:40925215.7DF1FB34@oracle.com...C > > > It would be proper and correct to read into the document that D > > > Oracle Rdb and Oracle Database on OpenVMS are developed by twoD > > > different groups at Oracle who do not necessarily include eachG > > > other in their public statements about their respective products.  > > > C > > > In fact, the port of Rdb to Itanium is well underway.  We are C > > > soliciting volunteers who will bring application code and Rdb F > > > databases to the OpenVMS Boot Camp in Nashua.  We will work withB > > > them to port their code to Itanium processors at that event. > > > H > > > We expect to release an ADK this quarter that will allow customersG > > > to compile their applications on Itanium while using Rdb's remote G > > > access capabilities to read and write data on an Alpha processor. J > > > We expect to release two beta test versions of Rdb on Itanium beforeD > > > a final production release in the second quarter of next year.K > > > With these releases, both database and applications will run entirely G > > > on Itanium.  Of course, we continue to support Rdb on VAX & Alpha F > > > processors as well (though active, 'new feature' work on the VAX > > > is declining). > > >  > > > - - - - - 6 > > >  opinions expressed here are mine and mine alone3 > > >  and certainly are not intended in any way to 6 > > >  express or represent any opinions or commitment > > >  of oracle corporation.  > > > 0 > > >  norman lastovica / oracle rdb engineering > >  > >    --  	 - - - - - 0  opinions expressed here are mine and mine alone.  and certainly are not intended in any way to 0  express or represent any opinions or commitment  of oracle corporation.   *  norman lastovica / oracle rdb engineering   ------------------------------  # Date: Sun, 06 Jun 2004 05:53:42 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: Q: DECWindows V1.2 Bindings & Translations @ Message-ID: <025fd002bad44d2aa23557a1c0bf4e1f@news.teranews.com>  # spam-me-not@invalid.hostname wrote: E > I'd like to understand what a VMS host is doing to my X server when I > I trigger the appearance of the VMS host's traditional DECWindows Motif  > V1.2 login box widget.  + This runs under the SYSTEM account on VMS.     You can control this with K DECW$SYSTEM_DEFAULTS:DECW$LOGIN.DAT which contains the resources applied to 6 the login screen, including key transaltion overrides.   ------------------------------   End of INFO-VAX 2004.313 ************************