1 INFO-VAX	Mon, 14 Nov 2005	Volume 2005 : Issue 635       Contents:! Re: A question about autocomplete ! Re: Are X-terminals sold anymore? . RE: FW: OT: Microsoft drop more Itanic support. Re: FW: OT: Microsoft drop more Itanic support. Re: FW: OT: Microsoft drop more Itanic support. RE: FW: OT: Microsoft drop more Itanic support. Re: FW: OT: Microsoft drop more Itanic supportG Re: Will Rich Marcello either come clean or do some proper marketingand G Re: Will Rich Marcello either come clean or do some proper marketingand G RE: Will Rich Marcello either come clean or do some proper marketingand G Re: Will Rich Marcello either come clean or do some proper marketingand G Re: Will Rich Marcello either come clean or do some proper marketingand G RE: Will Rich Marcello either come clean or do some proper marketingand P Re: Will Rich Marcello either come clean or do some proper marketingand   PR   P  [AVAILMAN V2.4-1] Can't start it  F ----------------------------------------------------------------------  % Date: Sun, 13 Nov 2005 21:47:37 -0500 4 From: "Peter Weaver" <newsgroup@weaverconsulting.ca>* Subject: Re: A question about autocomplete7 Message-ID: <eVSdf.390$KP5.67349@news20.bellglobal.com>   0 "issinoho" <issinoho@gmail.com> wrote in message. news:dl77lh$30c$1$830fa7a5@news.demon.co.uk... > Peter Weaver wrote: 4 > > "issinoho" <issinoho@gmail.com> wrote in message2 > > news:dl4n4r$cgj$1$8300dec7@news.demon.co.uk...L > >> I've always felt that one of the biggest failings with DCL was the lackL > >> of a Unix-style autocompletion of filepaths when TAB is hit. This wouldD > >> be a fantastic addition, however if I remember rightly an olderK > >> discussion around this offered some fundamental reasons why this would  > >> never work under DCL. > >> ... > > K > > Does nobody here keep an eye things coming out of the OpenOffice group?  > > ' > > http://www.oooovms.dyndns.org/auto/  > >  > >  > % > Not *really* the same though is it?   K I hate to come across sounding like Larry on this, but why? Keeping in mind ? that I'm not a Unix person so I have no idea what "a Unix-style B autocompletion of filepaths" looks like. But based on that limitedK description and the description at http://www.oooovms.dyndns.org/auto/ they J sound like the same thing (except the VMS one does commands too). The onlyI problem is that it is still a work in progress and still has many bugs to * work out, but it looks interesting so far.   ------------------------------  % Date: Mon, 14 Nov 2005 03:31:12 +0100 2 From: martin@radiogaga.harz.de (Martin Vorlaender)* Subject: Re: Are X-terminals sold anymore?; Message-ID: <4377f6f0.524144494f47414741@radiogaga.harz.de>   : "Yehavi Bourvine (58-4279)" <yehavi@vms.huji.ac.il> wrote:I > Any thin client which is Linux based should do the work, as long as you ? > have the right fonts (DECwindows is very sensitive to fonts).   D DECwindows on Alpha comes with a font server, so this shouldn't be a problem.   cu,    Martin --  A  Your mouse has moved.     | Martin Vorlaender  |  OpenVMS rules! 4  Windows must be restarted | work: mv@pdv-systeme.deG  for the change to take    |   http://www.pdv-systeme.de/users/martinv/ ;  effect. Reboot now? [OK]  | home: martin@radiogaga.harz.de    ------------------------------  % Date: Sun, 13 Nov 2005 13:53:31 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> 7 Subject: RE: FW: OT: Microsoft drop more Itanic support R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB70CC48@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 ! > Sent: November 10, 2005 8:45 PM  > To: Info-VAX@Mvb.Saic.Com 9 > Subject: Re: FW: OT: Microsoft drop more Itanic support  >=20 > "Main, Kerry" wrote:? > > Intel knows x86 will not soon have much influence on the=20  > market served  > > by Power5 and SPARC. >=20 > soon ? >=20F > By 2007, the 8086 will sport a very powerful system chipset that wasH > originally slated to help IA64 scale even bigger, but which IA64 won't4 > use now until 2008 becayuse IA64 has been delayed. >=20B > Right now, the 8086 may not scale to "galaxy class" machines.=20 > But it is  > coming real soon now.=20 >=20  D Gee, I seem to remember some folks in the newsgroup getting hammered4 with the coming "real soon now" type discussions.=20  H The x86 crowd has been saying "why do we need big servers - we can do it5 all with our solutions!" since the PC was first born.    :-)     < > The writing is on the wall. And I am sure people at the=20 > Hurd/Gates/Dell H > have NDAs with Intel that tell them the real plan with regards to 8086? > vs that IA64 thing. Not sure how far down each company the=20  > NDA is spread. >=20F > I realise that you must still spout the official HP PR line.  But atE > this point in time, Alpha-VMS is still more attractive since it has E > larger software availability and its future is not in question. (no 
 > future).=20  >=20  E Huh? No one tells me what I can say or not say in a newsgroup. Or any  other HP employee either.=20  9 Granted, one needs to maintain the right professionalism, G confidentiality and respect for all of the products HP offers, but that B is a far cry from anyone dictating what we can say in a newsgroup.  G > What is important TODAY is that IA64 only fills a small market niche. 8 > VMS on 8086 would have far greater sales potential.=20 > Preventing the port E > of VMS to 8086  actively limits VMS' potential for success, growth.  >=20 >=20  0 Ok, ok - here is a theoretical question for you:  F Which of the following options would you pick if you were in charge of OpenVMS:  E Option A: build in more UNIX compatibility, new file system, build in @ new performance features, virtualization and workload management1 features, get new ISV's on current platform or...   D Option B. Port to a new x86 platform and put option A on hold for 2+ years.   >=204 > > X86 and x86-64 sweet spot is still very much 2-4; > > cpu systems. That is also limited by applications on=20  > Windows and Linux $ > > to scale reliably above 5+ cpu's >=20H > And this is where VMS can really succeed since its superior clusteringF > abilities allows multiple smaller machines to act as a large system. >=20B > Why won't you admit that VMS on the 8086 would have a greater=20 > potential  > for sales and success ?  >=20  F Because I do not believe the HW platform is a big a deal as it used toF be. Customers at the level that sign on the bottom line are interested1 in supported solutions, not Mhz speeds and feeds.    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Sun, 13 Nov 2005 15:24:08 -0500 ( From: Bill Todd <billtodd@metrocast.net>7 Subject: Re: FW: OT: Microsoft drop more Itanic support G Message-ID: <uNidnehhyLV3PerenZ2dnUVZ_t2dnZ2d@metrocastcablevision.com>    Main, Kerry wrote: >>-----Original Message-----7 >>From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]  ! >>Sent: November 10, 2005 8:45 PM  >>To: Info-VAX@Mvb.Saic.Com 9 >>Subject: Re: FW: OT: Microsoft drop more Itanic support  >> >>"Main, Kerry" wrote: >>< >>>Intel knows x86 will not soon have much influence on the  >> >>market served  >> >>>by Power5 and SPARC.  >> >>soon ? >>F >>By 2007, the 8086 will sport a very powerful system chipset that wasH >>originally slated to help IA64 scale even bigger, but which IA64 won't4 >>use now until 2008 becayuse IA64 has been delayed. >>@ >>Right now, the 8086 may not scale to "galaxy class" machines.  >>But it is  >>coming real soon now.  >> >  > F > Gee, I seem to remember some folks in the newsgroup getting hammered4 > with the coming "real soon now" type discussions.   B Well, there is the not-so-minor difference that those discussions F related to Itanic's *becoming* competitive - whereas x86 already *is* H competitive (and JF's comment merely indicated that it would overshadow   Itanic even more in the future).   > J > The x86 crowd has been saying "why do we need big servers - we can do it7 > all with our solutions!" since the PC was first born.   H But now they *have* big servers (or don't you consider the 64-core Xeon H servers that IBM offers to constitute 'big'?  if not, I guess you don't B consider the Itanic servers available from HP to be 'big' either).  I And, as I've mentioned before, at the 32-socket (single-core) level that  E server already out-performs the best that Itanic can offer in SAP SD  I 2-tier (give them time and they'll get some other benchmarks out as well  C - but since they also out-perform Itanic's best TPC-C score at the  H 8-processor system size I wouldn't hold out too much hope for much good  news for Itanic there, either).    ...   )   here is a theoretical question for you:  > H > Which of the following options would you pick if you were in charge of
 > OpenVMS: > G > Option A: build in more UNIX compatibility, new file system, build in B > new performance features, virtualization and workload management3 > features, get new ISV's on current platform or...  > F > Option B. Port to a new x86 platform and put option A on hold for 2+ > years.  G Gee - substitute "Itanic" for "x86" above and you have almost the same  E situation which obtained on June 24, 2001, the main difference being  D that this time around the port destination is actually perceived by E customers as being desirable rather than a grossly-mistaken betrayal.    >  > 3 >>>X86 and x86-64 sweet spot is still very much 2-4  >>>cpu systems.   H I'm afraid that your perceptions in this area have become significantly I out of date, and are about to become even more obsolete with the release  E of the large (up to 32 sockets/64 cores, just like IBM's Xeon boxes)  : Horus Opteron systems and Sun's 8-socket/16-core Opterons.  )   That is also limited by applications on  >> >>Windows and Linux  >># >>>to scale reliably above 5+ cpu's   G I've addressed that horseshit already by noting that such applications  H can run just fine in their own partition on a large IBM Xeon box, while I those Windows/Linux applications that *do* scale up (such as SQL Server)  8 can now do so - though it's worth adding that for other C (non-Windows/Linux) applications that need to scale higher Solaris  H x86-64 provides at the very least as attractive an environment as HP-UX  does.    - bill   ------------------------------  % Date: Sun, 13 Nov 2005 19:04:15 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 7 Subject: Re: FW: OT: Microsoft drop more Itanic support , Message-ID: <4377D476.F2B9431E@teksavvy.com>   "Main, Kerry" wrote:F > Gee, I seem to remember some folks in the newsgroup getting hammered3 > with the coming "real soon now" type discussions.   9 That is a fair point.  There is however a big difference.   G The 8086 is the key strategic product for Intel. It has competition and G Intel MUST move the 8086 or die. If Intel is seen by Wall Street Casino F analysts as lagging behind AMD without an clear plan to catch up, WallE Street will hammer Intel. Intel MUST deliver better 8086s and compete  against AMD.  E Another difference betwen the "real soon now" for IA64 and 8086:  For D IA64, the "real soon now" was about having a chip catching up to the 8086.   F For the 8086, the "real soon now" is about expanding its reach towards higher end.   J > The x86 crowd has been saying "why do we need big servers - we can do it7 > all with our solutions!" since the PC was first born.   E That is the Windows weenies crowd. You need to separate the 8086 from E Windows.  They used to be equal. But with the advent of Linux and Sun B using 8086 on AMD, and soon Apple using Intel 8086s, Windows is no) longer the only visible user of the 8086.   G Sun is building its own servers based on the AMD chip. Apple will build G its own proprietary systems using the 8086. Not all 8086 based machines A need to be "commodity that runs Windows" even though they all use  commodity chips.  G > Huh? No one tells me what I can say or not say in a newsgroup. Or any  > other HP employee either.   C You know full well that because you are seen as an HP employee, you D cannot publically oppose what your employer is saying. I don't blame  you. I understand the situation.  G > Option A: build in more UNIX compatibility, new file system, build in B > new performance features, virtualization and workload management3 > features, get new ISV's on current platform or...  > F > Option B. Port to a new x86 platform and put option A on hold for 2+ > years.  H Option A will never work if you stay on a platform that isn't growing inF reach, remains a small niche market not bog enough to really allow VMSC to grow, and especially a still born platform that may never become ( acceptable/popular in the markletplace.   E IF you admit that porting VMS to IA64 was a big mistake, you then see A that porting to a winning platform (8086) ASAP is the best way to H correct that mistake and for every month HP delays the announcement that5 VMS is to be ported to the 8086,  VMS loses strength.   H > Because I do not believe the HW platform is a big a deal as it used toH > be. Customers at the level that sign on the bottom line are interested3 > in supported solutions, not Mhz speeds and feeds.   H They are interested in a platform that will survive. The platform is theN foundation. If the foundation melts away, anything you built on top collapses.  F That IA64 thing is like a foundation built on the edge of a precipice.G At first rainfall, it risks falling down the precipice. And the fear is G that it will bring VMS with it because HP refuses to commit to port VMS  beyond IA64.    C You have avoided so far answering my question: do you deny that VMS H would have greater growth potential on the 8086 versus a IA64 thing that$ is limited to a small market niche ?   ------------------------------  % Date: Sun, 13 Nov 2005 20:56:42 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> 7 Subject: RE: FW: OT: Microsoft drop more Itanic support R Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB70CC50@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 ! > Sent: November 13, 2005 7:04 PM  > To: Info-VAX@Mvb.Saic.Com 9 > Subject: Re: FW: OT: Microsoft drop more Itanic support  >=20  
 [snip ...]   >=20 >=20E > You have avoided so far answering my question: do you deny that VMS B > would have greater growth potential on the 8086 versus a IA64=20 > thing that& > is limited to a small market niche ? >=20  * JF - why do we not just agree to disagree?   :-)   E You seem to think the low level HW is what makes high level Customers C make decisions, while I prefer to think they look more at supported H solutions that will reduce their overall costs and improve their serviceB levels.  The HW costs are only a very small part of the overall IT solution today.   H As I have stated a number of times in the past, if the fastest, greatestF and most popular HW was the only thing that determined a OS's success,6 then Solaris would likely not even be around today.=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  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Mon, 14 Nov 2005 01:06:54 -0500 ' From: Dave Froble <davef@tsoft-inc.com> 7 Subject: Re: FW: OT: Microsoft drop more Itanic support 0 Message-ID: <11ngabmip23qj65@corp.supernews.com>   Main, Kerry wrote: >>-----Original Message-----7 >>From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]  ! >>Sent: November 10, 2005 8:45 PM  >>To: Info-VAX@Mvb.Saic.Com 9 >>Subject: Re: FW: OT: Microsoft drop more Itanic support  >> >>"Main, Kerry" wrote: >>< >>>Intel knows x86 will not soon have much influence on the  >> >>market served  >> >>>by Power5 and SPARC.  >> >>soon ? >>F >>By 2007, the 8086 will sport a very powerful system chipset that wasH >>originally slated to help IA64 scale even bigger, but which IA64 won't4 >>use now until 2008 becayuse IA64 has been delayed. >>@ >>Right now, the 8086 may not scale to "galaxy class" machines.  >>But it is  >>coming real soon now.  >> >  > F > Gee, I seem to remember some folks in the newsgroup getting hammered4 > with the coming "real soon now" type discussions.   E In some cases, movement can be seen, in others, not.  Basically, I'm  H with you in concept, but, HORUS seems immanent, and the IBM solution is 
 already here.   J > The x86 crowd has been saying "why do we need big servers - we can do it7 > all with our solutions!" since the PC was first born.   = Well, once again, I'm with you on this.  The 'one server per  F application' concept goes against most everything I've learned in the = last 35 years.  I just don't accept it, even on windoz boxes.    > :-)  >  >  > : >>The writing is on the wall. And I am sure people at the  >>Hurd/Gates/Dell H >>have NDAs with Intel that tell them the real plan with regards to 8086= >>vs that IA64 thing. Not sure how far down each company the   >>NDA is spread. >>F >>I realise that you must still spout the official HP PR line.  But atE >>this point in time, Alpha-VMS is still more attractive since it has E >>larger software availability and its future is not in question. (no  >>future).   >> >  > G > Huh? No one tells me what I can say or not say in a newsgroup. Or any  > other HP employee either.   D Well, while you may not receive directions, I'd feel that some real 3 anti-HP statements may not be good for your career.   F At this time, when itanic is the issue, I'm thinking that everyone is I just hoping that Intel has enough ego and bucks to keep it going in some  ' form regardless of just about anything.   E Face it, Intel just won't affect IBM, and what else is there besides  I Power.  Yeah, the SPARC from Fujitsu, but Sun has also adopted AMD.  IBM  I is the one they won't manage to kill.  So if the itanic has done as much  H damage to the competition as can be reasonably expected, and Opteron is D bashing Intel rather hard, ego is about all the itanic has left for  support.  Sad state of affairs.   ; > Granted, one needs to maintain the right professionalism, I > confidentiality and respect for all of the products HP offers, but that D > is a far cry from anyone dictating what we can say in a newsgroup. >  > G >>What is important TODAY is that IA64 only fills a small market niche. 6 >>VMS on 8086 would have far greater sales potential.  >>Preventing the port E >>of VMS to 8086  actively limits VMS' potential for success, growth.  >> >> >  > 2 > Ok, ok - here is a theoretical question for you: > H > Which of the following options would you pick if you were in charge of
 > OpenVMS: > G > Option A: build in more UNIX compatibility, new file system, build in B > new performance features, virtualization and workload management3 > features, get new ISV's on current platform or...  > F > Option B. Port to a new x86 platform and put option A on hold for 2+ > years.  H Obviously option B.  But that supposes that the itanic will continue to D be manufactured.  There seem to be plenty of people, with no vested 9 interest either way, that are rather doubtful about that.   3 >>>X86 and x86-64 sweet spot is still very much 2-4 8 >>>cpu systems. That is also limited by applications on  >> >>Windows and Linux  >># >>>to scale reliably above 5+ cpu's  >>H >>And this is where VMS can really succeed since its superior clusteringF >>abilities allows multiple smaller machines to act as a large system. >>@ >>Why won't you admit that VMS on the 8086 would have a greater  >>potential  >>for sales and success ?  >> >  > H > Because I do not believe the HW platform is a big a deal as it used toH > be. Customers at the level that sign on the bottom line are interested3 > in supported solutions, not Mhz speeds and feeds.   I But it has to at least exist.  You fail to consider the possibility that  C it might go away.  Yeah, I know that it's not something you can do  E anything about.  When you refuse to consider a very real possibility   then your credibility slips.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 13 Nov 2005 13:42:48 -0500 ( From: Bill Todd <billtodd@metrocast.net>P Subject: Re: Will Rich Marcello either come clean or do some proper marketingandG Message-ID: <3c6dnQNKL6S0FOrenZ2dnUVZ_tGdnZ2d@metrocastcablevision.com>    Karsten Nyblad wrote:  > Bill Todd wrote: > G >> The only one I know of involves software comparisons at every point  < >> where the persistent state of the system changes *or any F >> externally-visible result is returned* (persistent or not, because J >> once any information escapes from the system into the larger world, if J >> it's incorrect a visible fault has occurred).  This is a) considerably J >> slower than a comparable hardware solution and b) not much of any less C >> expensive (that is, if the hardware already supports a hardware  J >> solution, as previous and previously-planned future NSK platforms did). >  > - > Even software comparison may not be enough.   D Yes, they are:  they are just much slower than hardware comparisons.  C The situation you describe is solved by conventional transactional  8 mechanisms - it has nothing to do with hardware failure.   - bill   ------------------------------  % Date: Sun, 13 Nov 2005 13:58:37 -0500 ' From: Dave Froble <davef@tsoft-inc.com> P Subject: Re: Will Rich Marcello either come clean or do some proper marketingand0 Message-ID: <11nf36ejj71o5d5@corp.supernews.com>   JF Mezei wrote:  > "Main, Kerry" wrote: > G >>The NSK folks have already stated they will be using standard Itanium E >>systems in a triplicated configuration that is essentially software ' >>based to achieve its fault tolerance.  >  >  > % > When was this announced ? In 2004 ?  > @ > At the time of the merger completion when the state of VMS wasJ > announced'  I was explicitely told that the NSK group woudl have its ownJ > dedicated specialised IA64 hardware that was not related to the hardware= > that VMS would be used (the later being shared with HP-UX).  > G > Or do you just mean that they will be using standard chipsets and CPU D > boards, used in system chassis with all the specialised redundancy > features ?  F Considering it's HP, they probably said one thing when needed to calm I those with vested interests, then quietly changed the plans to something  @ much less at a later time.  Sort of like EV79 turning into EV7z.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Sun, 13 Nov 2005 17:49:08 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> P Subject: RE: Will Rich Marcello either come clean or do some proper marketingandR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB70CC4F@tayexc19.americas.cpqcorp.net>   > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 " > Sent: November 13, 2005 12:55 AM > To: Info-VAX@Mvb.Saic.Com A > Subject: Re: Will Rich Marcello either come clean or do some=20  > proper marketingand  >=20 > "Main, Kerry" wrote:; > > The NSK folks have already stated they will be using=20  > standard ItaniumG > > systems in a triplicated configuration that is essentially software ) > > based to achieve its fault tolerance.  >=20 >=20% > When was this announced ? In 2004 ?  >=20@ > At the time of the merger completion when the state of VMS was@ > announced'  I was explicitely told that the NSK group woudl=20 > have its own@ > dedicated specialised IA64 hardware that was not related to=20 > the hardware= > that VMS would be used (the later being shared with HP-UX).  >=20  G Well, I guess it depends on how you define "IA64 hardware". From what I F understand (and should clarify what I mentioned earlier), they will beH using standard IA64 CPU technology, but the boards etc will be differentD than other OS platforms. However, it is not the CPU technology which@ defines how they plan to achieve their fault tolerance features.  G > Or do you just mean that they will be using standard chipsets and CPU D > boards, used in system chassis with all the specialised redundancy > features ? >=20  F Std IA64 CPU technology wrapped with some additional HW + OS interface. calls that will handle the redundancy aspects.  G What I just stated may not be 100% correct, so I would encourage you to 3 read the official stuff at the following locations: E http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html H http://h20223.www2.hp.com/NonStopComputing/downloads/NSAA_FAQs_052505.pd f : http://h71028.www7.hp.com/ERC/downloads/NSAABusinessWP.pdf   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Sun, 13 Nov 2005 18:02:34 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> P Subject: Re: Will Rich Marcello either come clean or do some proper marketingand, Message-ID: <4377C605.28543859@teksavvy.com>   "Main, Kerry" wrote:B > Wow, I am sure all of the worlds banks will need to hear how theD > transaction models they have been using for the last 20+ years has > actually not been a good one.     B The banks have actually been very centralised in the database. And> because IBM mainframe disaster recovery doesn't really involveH "clusters", there is not a problem of multiple instances of MVS (or what8 ever the name is this week) accessing the same database.  E What the banks have is a star/tiered approach. The Tandem handles the H POS/ATM transactions, but then formats the transaction to be sent to theG IBM mainframe. When the IBM mainframe is unavailable, the Tandem stores F those transactions in a queue which is released to go to the mainframe once it returns to service.   @ Banks have totally separate products for different services. ForF instance, a mortgage won't be in the same database or even on the sameG mainframe as your savings account. Banks in the last 20 years have gone E through great lengths to create a unique customer profile database to D which is linked all the applications on different machines. But eachE database for each product central. But different databases are not in H the same machine or even same transactions monitor. You can have part of) your stuff on IMS, part on DB2 etc etc.     D banks didn't start up in the .COM era. They started computers in theB 1960s with punched cards. They have built around that without ever rebuilding from scratch.    O So there isn't really a problem of multiple concurrent transations not working.   A During nightly batch processing, they process all deposits before 
 widthdrawals.    ------------------------------  % Date: Mon, 14 Nov 2005 10:09:59 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> P Subject: Re: Will Rich Marcello either come clean or do some proper marketingand1 Message-ID: <dl8ro2$i0s$1@news-02.connect.com.au>   	 Hi Kerry,   D > RTR has the ability to find alternate network routes to complete aC > transaction. Hence, if one link or router went down, it will find  > another path.   L OK. If that was the analogy you were making to Tandem's fault tolerance then I misunderstood.  ! > And if they are using true 2PC,   J And *IF* they are using "true 2PC" then they are using DECdtm! Even if RTRL sits on top of it. Let me make something clear the diffence between productsF such as RTR and true transaction managers such as (MTS/DTC, hotTIP andK DECdtm) is that the later speak directly to the resource managers (Rdb, SQL I Server,10g etc) whereas RTR speaks to your specific application code. via K SYS$VOTEX (or whatever the name is. It's been a long time since I looked at J it too :-) So for RTR to "work" correctly one must apply the convention ofJ *only* modifying the data source with RTR-aware applications. (Once again, unless it's using DECdtm)   J No one's told Rdb that RTR will be replaying this txn until its receipt isH acknowledged, so Rdb is quite happy to let every bloke and his dog rape,# pilage and plunder the target data.   2  > . . .and the application error handler kicks in  J Or, the way I personally like to see it, a combination of Resource ManagerE and Transaction Manager error handling kicks in to guarantee the ACID C properties of a true two-phase commit, and preserve data integrity.   8 > Keep in mind that many stock exchanges use this today,  C Whoopdidoo! And so bloody what? I'll have you know that the top 500 K companies in the world all use Post-it notes! Are you suggesting that their H backup strategies involve transcribing the overnight run to those littleG yellow bits of paper? They probably have a lot of Excel spreadsheets as I well, is that also supposed to impress me or have me shaking in my boots?   H These types of "Amazon does millions of web transactions a day! and thenJ there's Ebay!" arguments are beneath you Kerry but, sadly, that's about asH much science as we get out of Rdb and VMS conferences these days when it comes to web transactions :-(   J I've never worked at a Stock Exchange but I have worked at a few banks andF other prestigious financial institutions in London, and I think I knowF enough about the finance industry in general, to not hold it up as theE bastion of best-IT-practice, any more than any other industry. As you K alluded to in another note, it all seems to hang together betwen twelve and E two and if anything goes wrong it's just tough-titties! "Tell 'em the K figures are a day old and not to quote anything without checking systems a, J b and c.". But then, the banks have managed expectations to such an extentH that I can xfer GBP in one account to AUD in aother at the same bank andK have it take 3 days to get there. And I just take it :-( Where else can you  get away with shit like that?    > so are you are- > stating that you know something they don't?   I Maybe. You tell me what *exactly* they're doing with RTR and I'll be very K happy to cast a critical eye over it. I for one would be *very* interested. K If they have a store-and-forward or guranteed-delivery requirement then I'm G sure that RTR hits the spot nicely. Or maybe BMQ, Tibco or MQSeries for ( portability. The right tool for the job.  G > Keep in mind that in many critical cases, you are talking about using F > RTR in conjunction with a multi-site OpenVMS cluster with host basedH > volume shadowing, so the data will always be consistent between sites.  K So why do you keep singling out RTR and banging on about how wonderful *it* F is. RTR ("when used in conjunction with regular exercise and a healthyH calorie controlled diet") will make you look bloody marvellous! Still OML Gruppen must of been grateful when you decided to give it away to customers.L Smart move! Up until then, according to you, it must have been bringing in a* tidy sum to VMS's coffers in license fees.  B > Wow, I am sure all of the worlds banks will need to hear how theD > transaction models they have been using for the last 20+ years has > actually not been a good one.    I'm not sure if : -   L a) You're agreeing with me that the attempted relagation of ACID 2PC is pure folly H b) Banks have worked with something else for 20+ years so who needs 2PC?B c) You thought I was serious in slagging off the need for ACID 2PCD d) You haven't had the pleasure of looking through the available Web  Services Transactions literature  J Although, pre distributed-databases, there was less of a need for 2PC theyH certainly had transaction semantics to encompass all updates to multiple> tables in a single database. (Or does that not matter either?)  G > Heck, ACID stuff is (and never was) designed to be the right base for J > every application. There are always going to be cost-benefit trade-off'sE > between complexity, availability and data consistency requirements.   L I agree. Lots of applications seem to be able to live with nightly transfersI of Org Unit or Customer information, and the restriction is placed on one G system to own the data and the others to receive read-only copies. To a J large extent, the KISS priciple works! (I personally find it inconveivableL that someone with a net worth to a bank in millions can't get to see (or getK one of his/her people to see) his new account details on the internet until G it trickles down from system to system sometime the following evening!)   E But what's the alternative? Up until recently, if you wanted the ACID L umbrella of a true 2PC then your database usually had to talk XA and you hadK to put your code under an XA compatible Transaction Monitor like Tuxedo, or K Encina (or ACMSxp?) and this made it almost impossible, and very expensive, E to retro-fit this functionality to any existing systems. What if your I databases, that spanned UNIX and VMS, didn't talk XA, like say RMS or Rdb 9 (did on TRU64 and is/soon on VMS) what could you do then?   J So Kerry, we are in agreement that 2PC has historically been a luxury thatE many development teams could ill afford even if the functionality was J available on a particular combination of platforms in the first place. So,I driven by the mother of all invention, cludges and work-arounds have been L put in place. Tying things up with fencing-wire and insulating-tape seems toL have had a lot going for it. But with the advent of the Transaction Internet- Protocol (TIP) the playing field has changed!   H The seperation of the Application and Transaction functionality into twoI seperate pipes means that every development team can choose the tools and G middleware that best suite their requirements but they can still encase I their critical distributed database updates with the ACID properties of a K true 2PC. Windows .NET and SQL Server on the front end and COBOL and Rdb at H the other. Linked to gether with whatever middleware you like. I say the idea's got a lot going for it.  J But I'm sure you'd much prefer the HP's Compansating-Transaction model. ToI persist with the previous Fred/Jack example: - Because Jack has scarpered I with his million bucks we must create 1000 "Compensating Transactions" to 4 take $1000 from random accounts. Yep, job well done!   Cheers Richard Maher  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:FD827B33AB0D9C4E92EACEEFEE2BA2FB70CC41@tayexc19.americas.cpqcorp.net...   > -----Original Message-----: > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]" > Sent: November 12, 2005 11:38 PM > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: Will Rich Marcello either come clean or do some > proper marketingand  >  > Hi Kerry,  > ? > It doesn't appear that you're listening to me anymore but for  > the benefit ofH > myself (if no one else) I can't let the following complete bollocks go > unchallenged: -  > A > >  In OpenVMS terms, that would include using technologies such D > > as RTR which, similar to HW fault tolerance, ensures a committed > > transaction is never lost. > / > Did you mis-type RTR and were meaning DECdtm?  > : > If not were you talking about RTR's store-and-forward or > guaranteed-delivery = > functionality when you were talking about a "transaction is  > never lost"? If 9 > it's the latter then could you please answer me this: -  > ? > What happens if the first part of the RTR transaction is give  > Fred 1 million< > dollars and the second part is take 1 million dollars from > Jack. Now when: > the transaction was started Jack had a million bucks but > since the network < > link to the remote database holding Jack's account-details > has been down,: > he's transferred that 1M squid to his bookie. So RTR can > stamp up and down : > as much as it wants with its "I want a million dollars!" > (don't we all :-) ; > but it's just not gonna get it. Excellent stuff about the  > transaction not G > being lost though! The ability to replay stale info is quite a trick.  >    Richard,  $ I am certainly no guru on RTR, but -  B RTR has the ability to find alternate network routes to complete aA transaction. Hence, if one link or router went down, it will find E another path. And if they are using true 2PC, as you know, either the C transaction completes at both sites or neither of them i.e. it gets 7 rolled back and the application error handler kicks in.   E Keep in mind that in many critical cases, you are talking about using D RTR in conjunction with a multi-site OpenVMS cluster with host basedF volume shadowing, so the data will always be consistent between sites.  E Keep in mind that many stock exchanges use this today, so are you are + stating that you know something they don't?   . Here is a pointer to some additional RTR info:* http://www.hp.com/products1/rtr/index.html) http://www.hp.com/products1/rtr/faqs.html       = > Look into my eyes, ACID is just-like-sooo-yesterday. It's a  > hangover from B > mainframe legacy days that simply cannot model today's web based? > requirements. . . You are getting sleepy . . . OMX Click uses  > it so it must E > work for everyone else. . .You eyelids are getting heavy. . .if web > > transactions didn't work then how does Amazon function? Hey? > Hey? . . .You : > are in your happy place. . .no one can hurt you anymore. >  > WAKEUP!!!   @ Wow, I am sure all of the worlds banks will need to hear how theB transaction models they have been using for the last 20+ years has actually not been a good one.   @ As to Amazon, I would have to think that losing a number of $100B transactions for books and some CD's is a whole lot different than/ losing a number of $10M to $100M+ transactions.   E Heck, ACID stuff is (and never was) designed to be the right base for H every application. There are always going to be cost-benefit trade-off'sC between complexity, availability and data consistency requirements.    [snip..]   Regards,  
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)   4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Mon, 14 Nov 2005 00:08:30 -0500 ' From: "Main, Kerry" <Kerry.Main@hp.com> P Subject: RE: Will Rich Marcello either come clean or do some proper marketingandR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB70CC54@tayexc19.americas.cpqcorp.net>   > -----Original Message-----= > From: Richard Maher [mailto:maher_rj@hotspamnotmail.com]=20 ! > Sent: November 13, 2005 9:10 PM  > To: Info-VAX@Mvb.Saic.Com A > Subject: Re: Will Rich Marcello either come clean or do some=20  > proper marketingand  >=20 > Hi Kerry,  >=20F > > RTR has the ability to find alternate network routes to complete aE > > transaction. Hence, if one link or router went down, it will find  > > another path.  >=20B > OK. If that was the analogy you were making to Tandem's fault=20 > tolerance then > I misunderstood. >=20# > > And if they are using true 2PC,  >=20; > And *IF* they are using "true 2PC" then they are using=20  > DECdtm! Even if RTR @ > sits on top of it. Let me make something clear the diffence=20 > between productsH > such as RTR and true transaction managers such as (MTS/DTC, hotTIP and= > DECdtm) is that the later speak directly to the resource=20  > managers (Rdb, SQL8 > Server,10g etc) whereas RTR speaks to your specific=20 > application code. via > > SYS$VOTEX (or whatever the name is. It's been a long time=20 > since I looked at A > it too :-) So for RTR to "work" correctly one must apply the=20  > convention of B > *only* modifying the data source with RTR-aware applications.=20 > (Once again, > unless it's using DECdtm)  >=20@ > No one's told Rdb that RTR will be replaying this txn until=20 > its receipt is? > acknowledged, so Rdb is quite happy to let every bloke and=20  > his dog rape, % > pilage and plunder the target data.  >=204 >  > . . .and the application error handler kicks in >=20> > Or, the way I personally like to see it, a combination of=20 > Resource ManagerG > and Transaction Manager error handling kicks in to guarantee the ACID E > properties of a true two-phase commit, and preserve data integrity.  >=20: > > Keep in mind that many stock exchanges use this today, >=20E > Whoopdidoo! And so bloody what? I'll have you know that the top 500 : > companies in the world all use Post-it notes! Are you=20 > suggesting that their @ > backup strategies involve transcribing the overnight run to=20 > those little< > yellow bits of paper? They probably have a lot of Excel=20 > spreadsheets as A > well, is that also supposed to impress me or have me shaking=20  > in my boots? >=20? > These types of "Amazon does millions of web transactions a=20  > day! and then ? > there's Ebay!" arguments are beneath you Kerry but, sadly,=20  > that's about as @ > much science as we get out of Rdb and VMS conferences these=20 > days when it > comes to web transactions :-(  >=20   Richard -=20  F I have seen and heard all the Web Services religion discussions. GreatG stuff. It will solve world hunger if only the application developers of C the world would just drop what they are doing and get on board with  either .Net or J2EE.  G In some respects, this Web Services religion is not unlike the "Windows F and Linux are going to take over the world" religion. Lots of passion,+ lots of religion, lots of heated arguments.   E While there certainly is a place for Web Services, the problems I see " with the technology is as follows:  A 1. Regardless of whether you choose .Net or J2EE, both are object F oriented programming languages which means a huge, huge learning curveD for all of those Fortran, Cobol, C, Basic and yes, even Visual BasicB programmers out there. I am sure you know that VB.Net is a totally8 different and totally incompatible language than VB6.=20  E Yes, tools help, but only to a small degree as a Web Services program E implemented poorly is no different than any other program implemented & poorly - there will be major problems.  F 2. Security with Web Services is only now becoming acceptable for mostH large corporations. The common joke around Web Services is the guy  withH the label "security" on his back chasing the train that has already left the station.  B 3. The benefits of Web Services sharing re-useable code is at bestG theoretical as most large corporations do not work like this. There are D typically many different App development groups and the sad truth isF that they just do not talk to each other - let alone develop long termD application sharing strategies and web services code using UDDI type technologies.=20  H Quick question from the past - ever try and get a common data dictionary" implemented in a large company?=20  E That is the challenge facing web services with all of its benefits of H shared library code. Great in theory and it would be wonderful if it wasF done, but we both know what a pain a common data dictionary was to getF established in any company. The issues are not technical but political and cultural ones.  B 4. Last, but not least, it is possible, but extremely difficult toB integrate web services code with existing code that is running theG business. This is especially true if the existing code does any type of  terminal or screen based IO.=20   @ By the way, I love the typical answer I have heard about the VB6E developer complaining about the fact that VB.Net is incompatible with G the tons of VB6 code they have in their company - "VB.Net is so easy to D use and has so much more flexibility that you would be better off to- simply re-write all that VB6 code in VB.Net."   7 Now, think about that and consider the previous points.   H Again, I am not saying Web Services does not have a place, but there areG some real challenges facing any company embarking on this new road. One F just needs to fully understand what it is they are getting into before+ they simply drink the kool-aid and jump in.   A > I've never worked at a Stock Exchange but I have worked at a=20  > few banks and H > other prestigious financial institutions in London, and I think I knowH > enough about the finance industry in general, to not hold it up as theG > bastion of best-IT-practice, any more than any other industry. As you > > alluded to in another note, it all seems to hang together=20 > betwen twelve and G > two and if anything goes wrong it's just tough-titties! "Tell 'em the < > figures are a day old and not to quote anything without=20 > checking systems a, @ > b and c.". But then, the banks have managed expectations to=20 > such an extent? > that I can xfer GBP in one account to AUD in aother at the=20  > same bank and = > have it take 3 days to get there. And I just take it :-(=20  > Where else can you > get away with shit like that?  >=20 > > so are you are/ > > stating that you know something they don't?  >=20A > Maybe. You tell me what *exactly* they're doing with RTR and=20  > I'll be very= > happy to cast a critical eye over it. I for one would be=20  > *very* interested.; > If they have a store-and-forward or guranteed-delivery=20  > requirement then I'm? > sure that RTR hits the spot nicely. Or maybe BMQ, Tibco or=20  > MQSeries for* > portability. The right tool for the job. >=20  B Here is a pointer to some additional RTR info that you can review:/ http://www.hp.com/products1/rtr/literature.html   @ > > Keep in mind that in many critical cases, you are talking=20
 > about using H > > RTR in conjunction with a multi-site OpenVMS cluster with host based> > > volume shadowing, so the data will always be consistent=20 > between sites. >=20A > So why do you keep singling out RTR and banging on about how=20  > wonderful *it* > is.=20  G RTR is a good solution that raises OpenVMS cluster very HA capabilities B to software fault tolerant levels. Hence, even if a cpu dies and aG system crashes, the RTR middleware ensures the committed transaction is : re-tried on another system to ensure it gets completed.=20  	 [snip...]     
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Sun, 13 Nov 2005 13:51:00 -0500 ' From: Dave Froble <davef@tsoft-inc.com> Y Subject: Re: Will Rich Marcello either come clean or do some proper marketingand   PR   P 0 Message-ID: <11nf2o5t66lnlfe@corp.supernews.com>   JF Mezei wrote:   J > So, yes, perhaps you are right and HP would have no qualms about killingJ > it.  If VMS management aren't courageous enough to tell HP that the portE > of VMS to the 8086 would greatly increase revenus, then perhaps the I > customers could do so, very publically. This way, HP would be forced to ( > respond to the media and shareholders.  I The various owners of VMS sure have demonstrated a tremendous capability  3 to ignore customers, and the rest.  Consider Alpha.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------    Date: 13 Nov 2005 21:15:20 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)) Subject: [AVAILMAN V2.4-1] Can't start it , Message-ID: <4377ace8$1@news.langstoeger.at>  M I've 2 systems (one V7.3-2 and one V8.2) where I can't start AVAILMAN V2.4-1. 
 Message is- 		Cannot find the AvailMan configuration file  		AvailMan.ini  % 		Would you like to create a new one?   3 		Note: Pressing "Cancel" will exit the application    And   . 		Unable to create AvailMan configuration file 		AvailMan.ini  , 		There may be a protection or space problem  H While I've no space problem (a 36GB disk, almost empty) and I should notE have a protection problem (I'm running with BYPASS privilege enabled) F I have no idea what the problem could be (I now supect a JAVA problem)  @ I did a SET WATCH FILE/CLASS=ALL and I saw umpteen hundreds lineG (like fiddling with SYSUAF.DAT - why ? - and fiddling with MET timezone D file - why not using the logicals or letting VMS doing that ?) but I( haven't seen an AvailMan.ini file there.  G Does anyone have an idea what the problem is or what I can check next ?    TIA    --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   End of INFO-VAX 2005.635 ************************