1 INFO-VAX	Sat, 26 Feb 2005	Volume 2005 : Issue 114       Contents: Re: Backup /ALIAS question CDRECORD v. RMS defaults Re: CDRECORD v. RMS defaults' Re: Checking for "file open for write". ' Re: Checking for "file open for write". ' Re: Checking for "file open for write".  Re: IA64 unraveling... Re: IA64 unraveling... Re: IA64 unraveling... Re: IA64 unraveling... Re: IA64 unraveling... Re: IA64 unraveling... Re: IA64 unraveling...3 RE: London Stock Exchange slowing moving to Windows 3 RE: London Stock Exchange slowing moving to Windows 3 Re: London Stock Exchange slowing moving to Windows 3 Re: London Stock Exchange slowing moving to Windows 3 Re: London Stock Exchange slowing moving to Windows 8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points8 Re: OpenVMS Seminar in Toronto (2005-02-24) a few points RE: Ouch! a *MAJOR* bug in TPU.  Re: Ouch! a *MAJOR* bug in TPU.  RE: Ouch! a *MAJOR* bug in TPU.  RE: Ouch! a *MAJOR* bug in TPU.  Re: Sayonara Tukwilla   F ----------------------------------------------------------------------  % Date: Sat, 26 Feb 2005 10:17:22 +0100 1 From: Wilm Boerhout <wOLDboerhout@PAINTplanet.nl> # Subject: Re: Backup /ALIAS question 5 Message-ID: <42203ea2$0$8099$ba620dc5@nova.planet.nl>   2 Statler: What's with this new BACKUP /ALIAS thing?? Waldorf: Dunno, BACKUP /PHYSICAL was always good enuf for me...    Z wrote:   >  > Why are you asking this? > = > Don't you know that VMS commands like BACKUP are intuitive?  >  > <stirs the pot>    --  
 Wilm Boerhout  Zwolle, The Netherlands    wilmOLD@PAINTboerhout.nl2    (remove OLD PAINT from this address before use)   ------------------------------  + Date: Sat, 26 Feb 2005 08:35:22 -0600 (CST) * From: sms@antinode.org (Steven M. Schweda)! Subject: CDRECORD v. RMS defaults 2 Message-ID: <05022608352192_27800279@antinode.org>  F    Just for the record, as I may be the only person left on the planetF with a CD writer old enough to make a bad CD when its buffer runs dry,> CDRECORD can apparently be helped by non-default RMS settings.  C    I was having some trouble getting success at 8X on my AlpSta 200 E 4/233 (VMS V7.3-1, CDRECORD 1.8.1, "YAMAHA CRW8424S"), so I tried SET A RMS /BLOCK_COUNT = 127 /BUFFER_COUNT = 2, and it seemed to make a E significant difference.  MONITOR SYSTEM showed a Direct I/O Rate (for A the CDRECORD process) less than half what it was with the default F settings, and the failure to complete a CD disappeared (even after the> nightly BACKUP started, which seemed to be doing more I/O than
 CDRECORD).  G    After a bit of searching, I found the critical open() in CDRECORD.C, A added enough VMS-specific parameters to enable an access callback D function, and added my now-standard (for me, anyway) access callbackF function to the VMS.C file where I had previously put the exit handlerG to restore the base process priority and the LIB$INITIALIZE code to set  DECC$ARGV_PARSE_STYLE.  F    If anyone cares, let me know, and I can put the new stuff somewhere accessible.   H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-org     Saint Paul  MN  55105-2547    ------------------------------    Date: 26 Feb 2005 18:36:51 +0100C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann) % Subject: Re: CDRECORD v. RMS defaults 2 Message-ID: <4220b3b3$1@merkur.rz.uni-konstanz.de>  K In article <05022608352192_27800279@antinode.org>, sms@antinode.org (Steven  M. Schweda) writes: G >   Just for the record, as I may be the only person left on the planet G >with a CD writer old enough to make a bad CD when its buffer runs dry, ? >CDRECORD can apparently be helped by non-default RMS settings.  > D >   I was having some trouble getting success at 8X on my AlpSta 200F >4/233 (VMS V7.3-1, CDRECORD 1.8.1, "YAMAHA CRW8424S"), so I tried SETB >RMS /BLOCK_COUNT = 127 /BUFFER_COUNT = 2, and it seemed to make aF >significant difference.  MONITOR SYSTEM showed a Direct I/O Rate (forB >the CDRECORD process) less than half what it was with the defaultG >settings, and the failure to complete a CD disappeared (even after the ? >nightly BACKUP started, which seemed to be doing more I/O than  >CDRECORD).  > H >   After a bit of searching, I found the critical open() in CDRECORD.C,B >added enough VMS-specific parameters to enable an access callbackE >function, and added my now-standard (for me, anyway) access callback G >function to the VMS.C file where I had previously put the exit handler H >to restore the base process priority and the LIB$INITIALIZE code to set >DECC$ARGV_PARSE_STYLE.  > G >   If anyone cares, let me know, and I can put the new stuff somewhere  >accessible. >    Steven,       F I'm interested to get the modification. It`s a pity that the Author of  ? cdrecord, Joerg Schilling, is unwilling to add OS-specific code   % outside those parts he had defined...        eberhard   ------------------------------  + Date: Sat, 26 Feb 2005 07:35:16 +0000 (UTC) 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 0 Subject: Re: Checking for "file open for write".0 Message-ID: <cvp8rj$fcr$1@sparta.btinternet.com>   Hi,   K I'm happy to be proved wrong but, my understanding is that on a stand alone 1 node there is *no* DLM lock. OTY or Paul or Hein?    Cheers Richard.   4 "Dave Froble" <davef@tsoft-inc.com> wrote in message* news:112016rkp7i4e5f@corp.supernews.com... > prep@prep.synonet.com wrote:1 > > Karsten Nyblad <nospam@nospam.nospam> writes:  > >  > > H > >>You have to understand that the VMS file system is based on the file@ > >>system that existed before clusters.  Thus locks are used toI > >>synchronize access between nodes in a cluster, but synchronization of J > >>access on the single node is done by the file system without involving
 > >>locks. > >  > > G > > As of VMS 3.7, all file system sysncronisation has be done by locks 9 > > and the (D)LM. Both at the ACP/XQP level, and by RMS.  > >  > > C > Thanks for pointing this out.  I didn't want to get into a 1 on 1 & > shouting match over this issue.  :-)   ------------------------------  % Date: Sat, 26 Feb 2005 09:09:43 +0100 & From: Paul Sture <paul.sture@decus.ch>0 Subject: Re: Checking for "file open for write"., Message-ID: <38ap67F5jkc7mU1@individual.net>   Hein wrote:    > F > Odd, how this 30+ year old problem has not been solved properly huh?M > VMS had/has 'SPOOL' nee FTSV (1985-ish in Valbonne :-) to deal with most of J > these issues, including a 'trigger when done, post processing function'. >   < Thanks for that pointer, I'd never come across SPOOL before.  D But I must add that this problem comes up time and again, just like F reading/writing EBCDIC tapes did in the 1980s. That too could be done E and there were DECUS solutions around, but because it wasn't part of  A standard VMS, VMS suffered from the perception that it lacked an   important facility.    ------------------------------  % Date: Sat, 26 Feb 2005 10:06:30 -0500 ( From: "Hein" <hein.nomail@hp.nomail.com>0 Subject: Re: Checking for "file open for write"., Message-ID: <422090fc$1@usenet01.boi.hp.com>  > "Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message* news:cvp8rj$fcr$1@sparta.btinternet.com... > Hi,  > G > I'm happy to be proved wrong but, my understanding is that on a stand  alone 3 > node there is *no* DLM lock. OTY or Paul or Hein?   K There is still the LM (Lock Manager) just no need for the Distributed (DLM)  part of it.   * But it seems all largely irrelevant to me.  L I know that you know that RMS (and the XQP directly if you'd like to), knowsK how to do file access locking with the optional shared none, read, or write  flavors.F Whether the system used is in a cluster or not is not visible from the RMS/XQP API persepective. = That in itself is a major feature, but a transparant feature. G Why worry whether it is a DLM o LM or spinlock, WCB or FCB or whatever? ! The system will take care of it!?    fwiw,  Hein.    ------------------------------  % Date: Sat, 26 Feb 2005 03:56:36 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca> Subject: Re: IA64 unraveling... B Message-ID: <1109407432.937528b02742bce42fd903a00b921719@teranews>   icerq4a@spray.se wrote: E > This is old news, I think early 2004. Intel has not announced a new A > chipset, but atleast HP and SGI have new chipsets in the works.     ? But this was in conjunction with the announcement that IBM just G cancelled its IA64 chipset support.  So if IBM is to continue producing E noew IA64 servers, whose chipset will they use if Intel no longer has / state of the art chipset that applies to IA64 ?   B Note that Intel is continuing chipset development for the 8086. ItA widthdrew the IA64 bit only. So dual core 8086s will get a better ( chipset than dual core IA64s from Intel.  E Will Dell bother with new IA64 servers when montecito comes out if it G can't source competitive chipsets ? If HP develops its own chipset that G takes advantage of dual core features of IA64, is there a point of Dell @ continuing to try to sell servers based on Intel's old chipset ?   > Intel B > has more or less said that they focus on the common Xeon/Itanium > chipset instead.  < Was this Byashore ? That is the one Intel ditched last year.  I > Think about how many Proliants HP ship, when they in the future will be F > able to take IA64 chips... Prices will go down, and there is atleast! > much more potential for volume.   H Since "system" performance is as important as chip performance for largeH systems, IA64 will proabbly have 0 advantage over the 8086 when insertedH into the same system, except it will require far more memory to run. AndC IA64 will not have as much software as the 8086 and will cost more.   H There will not be any point for Intel to continue to develop 2 competingF architectures that fit into the same systems. From a shareholder point: of view, this is a waste of money and duplication of work.   ------------------------------  # Date: Sat, 26 Feb 2005 12:16:17 GMT 6 From: "Kenneth Farmer" <kfarmer@NOSPAM.spyderbyte.com> Subject: Re: IA64 unraveling... > Message-ID: <lMZTd.26128$Yf5.2402619@twister.southeast.rr.com>  ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  < news:1109382724.4273615e1a8dca69d83d56c8c5b058ce@teranews...d >> http://news.com.com/Sources+IBM+ditching+Itanium+altogether/2100-1006_3-5590780.html?tag=nefd.top > H > This one announces that IBM is not likely to produce new IA64 servers. > (Not official yet).     4 Anyone think this is as much political as technical?   Ken    OpenVMS.org % _____________________________________  Kenneth R. Farmer <>< & SpyderByte: http://www.SpyderByte.com    ------------------------------    Date: 26 Feb 2005 07:12:33 -0600+ From: young_r@encompasserve.org (Rob Young)  Subject: Re: IA64 unraveling... 3 Message-ID: <8hQNygcF1kuL@eisner.encompasserve.org>   w In article <lMZTd.26128$Yf5.2402619@twister.southeast.rr.com>, "Kenneth Farmer" <kfarmer@NOSPAM.spyderbyte.com> writes: = > "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  > > news:1109382724.4273615e1a8dca69d83d56c8c5b058ce@teranews...e >>> http://news.com.com/Sources+IBM+ditching+Itanium+altogether/2100-1006_3-5590780.html?tag=nefd.top  >>I >> This one announces that IBM is not likely to produce new IA64 servers.  >> (Not official yet). >  > 6 > Anyone think this is as much political as technical? >   @ 	Lucky you mention the word "political" here , that's allowable.  > 	Anyhow.... it is a good business decision on IBM's part.  The> 	common chipset shows up in 2007, until then they use existing? 	chipset.  But the fact is they have little concern for Itanium = 	as it is a direct competitor to Power.  HP and SGI and Bull  ; 	and Fujitsu and Dell and NEC, etc.  don't have an in-house + 	architecture they have to prop-up/support.    				Rob    ------------------------------  % Date: Sat, 26 Feb 2005 10:49:25 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca> Subject: Re: IA64 unraveling... B Message-ID: <1109432228.4461a445ebd73a65b4c09319fb329da3@teranews>   Rob Young wrote:G >         Anyhow.... it is a good business decision on IBM's part.  The G >         common chipset shows up in 2007, until then they use existing  >         chipset.    H Ok, so Intel is working on a new chipset that will apply to IA64 in 2007* ? What is the code name for this project ?   ------------------------------  % Date: Sat, 26 Feb 2005 10:43:29 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Re: IA64 unraveling... , Message-ID: <Efqdne8In9S_BL3fRVn-tA@igs.net>   JF Mezei wrote:  > icerq4a@spray.se wrote: F >> This is old news, I think early 2004. Intel has not announced a newB >> chipset, but atleast HP and SGI have new chipsets in the works. >  > A > But this was in conjunction with the announcement that IBM just ? > cancelled its IA64 chipset support.  So if IBM is to continue F > producing noew IA64 servers, whose chipset will they use if Intel no< > longer has state of the art chipset that applies to IA64 ? > D > Note that Intel is continuing chipset development for the 8086. ItC > widthdrew the IA64 bit only. So dual core 8086s will get a better * > chipset than dual core IA64s from Intel. > G > Will Dell bother with new IA64 servers when montecito comes out if it D > can't source competitive chipsets ? If HP develops its own chipsetF > that takes advantage of dual core features of IA64, is there a point@ > of Dell continuing to try to sell servers based on Intel's old > chipset ?  >  >> IntelC >> has more or less said that they focus on the common Xeon/Itanium  >> chipset instead.  > > > Was this Byashore ? That is the one Intel ditched last year. > G >> Think about how many Proliants HP ship, when they in the future will B >> be able to take IA64 chips... Prices will go down, and there is* >> atleast much more potential for volume. > D > Since "system" performance is as important as chip performance forG > large systems, IA64 will proabbly have 0 advantage over the 8086 when G > inserted into the same system, except it will require far more memory F > to run. And IA64 will not have as much software as the 8086 and will > cost more.    J Actually the IA64-based systems will provide significant advantages for HPI as they become more vertically integrated - buying electricity generating G assets to power the rooms full of Itanics. HP will also be reserving to K itself the rights to all the heat produced by the Itanics during the winter B months - for sale for snow-melting purposes in northern states and
 provinces.   --- OpenVMS - The classics never go out of style.    ------------------------------  # Date: Sat, 26 Feb 2005 17:31:01 GMT . From: "robert kas" <rkas60@nospam.verizon.net> Subject: Re: IA64 unraveling... , Message-ID: <pn2Ud.50746$sR5.34689@trndny05>  J > Ok, so Intel is working on a new chipset that will apply to IA64 in 2007, > ? What is the code name for this project ?  +                                    "Loser"     ------------------------------  % Date: Sat, 26 Feb 2005 13:56:43 -0500 ' From: Dave Froble <davef@tsoft-inc.com>  Subject: Re: IA64 unraveling... 0 Message-ID: <1121h2gs1ilcl06@corp.supernews.com>   icerq4a@spray.se wrote:  > JF Mezei wrote:  >  >>icerq4a@spray.se wrote:  >>F >>>This is old news, I think early 2004. Intel has not announced a newB >>>chipset, but atleast HP and SGI have new chipsets in the works. >> >>A >>But this was in conjunction with the announcement that IBM just ? >>cancelled its IA64 chipset support.  So if IBM is to continue  >  > producing  > G >>noew IA64 servers, whose chipset will they use if Intel no longer has 1 >>state of the art chipset that applies to IA64 ?  >  > A > There will be two different versions of Montecitos. One for old I > chipsets and one for new chipsets. IBM can choose to continue with it's @ > current chipset if they want to, but those who can use the newD > generation chipset have an advantage. But as has been stated IBM'sA > intent is to go the POWER route and I don't think they are much  > interested in Itanium. >  > D >>Note that Intel is continuing chipset development for the 8086. ItC >>widthdrew the IA64 bit only. So dual core 8086s will get a better * >>chipset than dual core IA64s from Intel. >  > , > Yes, except from HP, SGI, NEC and Fujitsu. >  > G >>Will Dell bother with new IA64 servers when montecito comes out if it D >>can't source competitive chipsets ? If HP develops its own chipset >  > that > D >>takes advantage of dual core features of IA64, is there a point of >  > Dell > B >>continuing to try to sell servers based on Intel's old chipset ? >  > E > Does it matter much? ;), Dell is not selling many IA64 boxes today.  >  >  >>>IntelC >>>has more or less said that they focus on the common Xeon/Itanium  >>>chipset instead.  >>> >>Was this Byashore ? That is the one Intel ditched last year. >  > I > No, Bayshore is the cancelled Itanium chipset which I said is old news.  >  > B >>>Think about how many Proliants HP ship, when they in the future > 	 > will be  > ? >>>able to take IA64 chips... Prices will go down, and there is  > 	 > atleast  > " >>>much more potential for volume. >>D >>Since "system" performance is as important as chip performance for >  > large  > A >>systems, IA64 will proabbly have 0 advantage over the 8086 when  > 
 > inserted > F >>into the same system, except it will require far more memory to run. >  > And  > E >>IA64 will not have as much software as the 8086 and will cost more.  >  > B > I don't know what you mean with far more memory, IA64 has largerF > instruction footprint, but I don't know why you need far more memoryB > for that. The size of execution binaries in memory is very smallA > compared to the allocated data memory. Whether IA64 will have 0 F > advantage remains to be seen, x86 still have strict memory ordering. > I > Prices will do down on the systems because HP and other companies which H > want to use Itanium don't need to design a whole new system. They justG > need to design one box for x86/IA64 and not two systems. Whether IA64 I > will cost more is a question for Intel to decide, Itanium and Xeon MP's   > currently have similar prices. >  > @ >>There will not be any point for Intel to continue to develop 2 >  > competing  > B >>architectures that fit into the same systems. From a shareholder >  > point  > < >>of view, this is a waste of money and duplication of work. >  > F > There is a big point there. As things have turned out, it would haveI > been much better if Intel had made a common chipset from the beginning! H > It will be very interesting to compare the performance of x86 and IA64: > when the common system infrastructure (CSI) is released. > H > Intel have many times said that they want another architecture besidesE > x86 to play with in their cards. That is an opportunity for them to E > grow their business. If IA64 takes off, then good, if not, then not = > much harm (for Intel) is done. They have the size, and most 6 > importantly, the _money_ to do these kind of things. >   " Is Rob posting under another name?   ------------------------------  % Date: Sat, 26 Feb 2005 19:05:26 +1100 6 From: "O'Brien Paddy" <Paddy.O'Brien@transgrid.com.au>< Subject: RE: London Stock Exchange slowing moving to WindowsX Message-ID: <8BAD914A0B8CA84C9E94187103A1AB9E05BDF5@EX-TG2-PR.corporate.transgrid.local>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C51BD9.EE254181 . Content-Type: text/plain; charset="iso-8859-1"+ Content-Transfer-Encoding: quoted-printable    John Smith wrote:   K > HP should have been in there clawing tooth and nail showing them why they L > are making a big mistake switching to Windows....or is it that HP saw dol= lar L > signs in selling them a truckload of Proliants using an o/s that HP makes=  no 
 > money from?   L Why would they?  Isn't HP just a small Micro$oft subsiduary -- until BG inv=	 ents ink?    Regards, Paddy    G ***********************************************************************   C "This electronic message and any attachments may contain privileged @ and confidential information intended only for the use of the=20D addressees named above.  If you are not the intended recipient of=20C this email, please delete the message and any attachment and advise D the sender.  You are hereby notified that any use, dissemination,=207 distribution, reproduction of this email is prohibited.   C If you have received the email in error, please notify TransGrid=20 C immediately.  Any views expressed in this email are those of the=20 ? individual sender except where the sender expressly and with=20 C authority states them to be the views of TransGrid.  TransGrid uses > virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************     ' ------_=_NextPart_001_01C51BD9.EE254181 - Content-Type: text/html; charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printable   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">  <HTML> <HEAD>L <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> K <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7226.0"> B <TITLE>RE: London Stock Exchange slowing moving to Windows</TITLE> </HEAD>  <BODY>) <!-- Converted from text/plain format -->   ' <P><FONT SIZE=3D2>John Smith wrote:<BR>  <BR>L &gt; HP should have been in there clawing tooth and nail showing them why t= hey<BR> L &gt; are making a big mistake switching to Windows....or is it that HP saw =
 dollar<BR>L &gt; signs in selling them a truckload of Proliants using an o/s that HP ma=
 kes no<BR> &gt; money from?<BR> <BR>L Why would they?&nbsp; Isn't HP just a small Micro$oft subsiduary -- until B= G invents ink?<BR> <BR> Regards, Paddy<BR> </FONT>  </P>   <FONT SIZE=3D3><BR>  <BR>K ***********************************************************************<BR>  <BR>G "This electronic message and any attachments may contain privileged<BR> B and confidential information intended only for the use of the <BR>F addressees named above.  If you are not the intended recipient of <BR>G this email, please delete the message and any attachment and advise<BR> F the sender.  You are hereby notified that any use, dissemination, <BR>; distribution, reproduction of this email is prohibited.<BR>  <BR>E If you have received the email in error, please notify TransGrid <BR> E immediately.  Any views expressed in this email are those of the <BR> A individual sender except where the sender expressly and with <BR> G authority states them to be the views of TransGrid.  TransGrid uses<BR> B virus-scanning software but excludes any liability for viruses<BR>  contained in any attachment.<BR> <BR>@ Please note the email address for TransGrid personnel is now<BR>( firstname.lastname@transgrid.com.au"<BR> <BR>K ***********************************************************************<BR>  </FONT>  </BODY>  </HTML> ) ------_=_NextPart_001_01C51BD9.EE254181--    ------------------------------  % Date: Sat, 26 Feb 2005 07:43:07 -0500 ' From: "Main, Kerry" <kerry.main@hp.com> < Subject: RE: London Stock Exchange slowing moving to WindowsR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB53F87B@tayexc19.americas.cpqcorp.net>    -----Original Message----- 9 > From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 ! > Sent: February 25, 2005 7:53 PM  > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: London Stock Exchange slowing moving to Windows >=20  	 [snip...]    >=20F > I am very surprised that you of all people would think that. I wouldB > have though you would have been fully aware of the influcence=20 > IBM sales A > rep and VP have on such customers. They establish real personal < > relationships with the key people in companies and make=20 > damned sure thatA > the relationship goes far beyond official vendor presentations.  >=20F > If HP thinks as you do, then it is no wonder they lost that account. >=20@ > > In many cases, it is often what the Dev Managers personal=20 > background is = > > that determines and/or at least greatly influences the=20  > direction taken. >=20> > When IBM encounters such a un-cooperative manager or even=20 > uncooperative @ > techy, they wkno where to go to bypass all of this. They go=20
 > to the CEO, A > CIO and discredit that uncooperative manager,s opinions (or the   > discredit the person himself). >=20  	 [snip...]   E That might work with some accounts, but with many others when the Dev H group finds out that you are trying to go over their heads, just try andH sell them anything in the future. Burning bridges in a company is a sure6 way to get yourself on an internal black list as well.  3 Again, I have no idea what the LSE situation is.=20   @ Generically speaking, if a Customer is determined to switch to aE particular platform (no matter what vendor says), then as long as the F Customer fully understands the issues and risks, I would rather HP getB that platform and services integration business than a competitor.E That's Business and Account Control 101 that I suspect most people on  the group would agree with.=20   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  $ "OpenVMS has always had integrity .. Now, Integrity has OpenVMS .."   ------------------------------  % Date: Sat, 26 Feb 2005 10:47:47 -0500 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>< Subject: Re: London Stock Exchange slowing moving to WindowsB Message-ID: <1109432130.6a96d7a3ff5ca0b31749119b96e6d438@teranews>   "Main, Kerry" wrote:B > Generically speaking, if a Customer is determined to switch to aG > particular platform (no matter what vendor says), then as long as the H > Customer fully understands the issues and risks, I would rather HP getD > that platform and services integration business than a competitor.  & Again, this is where HP gets it wrong.  @ IBM doesn't wait for the customer to come with an RFP. IBM staysG involved with the customer BEFORE the RFP is written, ensuring that the F IBM offerings are not shut out of the RFP. (or in some cases, ensuringB the RFP is done in such a way that only IBM systems fit the bill).  H When you have a customer, it costs far less to keep the customer than toH find/acquire a new customer. And Losing a enterprise custoemr to Wintel,F especially such a high profile one, should be considered a disaster of. biblical proportions at HP with heads rolling.  H Having a mentality of "well, as long a he buys HP wintels" is a TERRIBLEE attitude and should NOT be tolerated.  HP should not view itself as a G reseller of Microsoft/Intel. It has its own products which generate the C profits for the company, and it must protect its own turf. And that D means handholding such high profile cistomers and ensuring that HP's4 enterprise products are not price out of the market.  9 The LSE sent a strong message that tandem was overpriced.   F If you don't even view this as losing a customer, how the hell are youF supposed to see a red flag and take actions to prevent further loss of customers ????????   ------------------------------  % Date: Sat, 26 Feb 2005 10:52:40 -0500 # From: "John Smith" <a@nonymous.com> < Subject: Re: London Stock Exchange slowing moving to Windows, Message-ID: <RcydnWDuAYXVBr3fRVn-qw@igs.net>   JF Mezei wrote:  > "Main, Kerry" wrote:C >> Generically speaking, if a Customer is determined to switch to a H >> particular platform (no matter what vendor says), then as long as theE >> Customer fully understands the issues and risks, I would rather HP = >> get that platform and services integration business than a  >> competitor. > ( > Again, this is where HP gets it wrong. > B > IBM doesn't wait for the customer to come with an RFP. IBM staysE > involved with the customer BEFORE the RFP is written, ensuring that C > the IBM offerings are not shut out of the RFP. (or in some cases, F > ensuring the RFP is done in such a way that only IBM systems fit the > bill).    # I have seen this numerous time too.   L And situations where an IT dept. (or BoD) hires several teams of consultantsL (Accenture, CGEY level types) to write recommendations, only to toss all theJ reports that don't agree with the direction the IT dept. wants to go - allJ the while saying that they got input from the 'best minds' in the business6 and this is what the final recommendation looked like.   --- OpenVMS - The classics never go out of style.    ------------------------------  # Date: Sat, 26 Feb 2005 16:41:53 GMT " From:   VAXman-  @SendSpamHere.ORG< Subject: Re: London Stock Exchange slowing moving to Windows0 Message-ID: <00A3FF80.A1B789E9@SendSpamHere.ORG>  R In article <RcydnWDuAYXVBr3fRVn-qw@igs.net>, "John Smith" <a@nonymous.com> writes: >JF Mezei wrote: >> "Main, Kerry" wrote: D >>> Generically speaking, if a Customer is determined to switch to aI >>> particular platform (no matter what vendor says), then as long as the F >>> Customer fully understands the issues and risks, I would rather HP> >>> get that platform and services integration business than a >>> competitor.  >>) >> Again, this is where HP gets it wrong.  >>C >> IBM doesn't wait for the customer to come with an RFP. IBM stays F >> involved with the customer BEFORE the RFP is written, ensuring thatD >> the IBM offerings are not shut out of the RFP. (or in some cases,G >> ensuring the RFP is done in such a way that only IBM systems fit the 	 >> bill).  >  > $ >I have seen this numerous time too. > M >And situations where an IT dept. (or BoD) hires several teams of consultants M >(Accenture, CGEY level types) to write recommendations, only to toss all the K >reports that don't agree with the direction the IT dept. wants to go - all K >the while saying that they got input from the 'best minds' in the business 7 >and this is what the final recommendation looked like.     & http://www.despair.com/consulting.html   --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  % Date: Sat, 26 Feb 2005 09:13:20 -0500 ) From: "Neil Rieck" <n.rieck@sympatico.ca> A Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few points 9 Message-ID: <Cu%Td.33934$uO.935907@news20.bellglobal.com>   4 "Dave Froble" <davef@tsoft-inc.com> wrote in message* news:111vrg1aiknd7d9@corp.supernews.com... [...snip...] > K > I'm not sure what this statistic means.  If just looking at the number of F > new systems sold, then great, more systems are being sold.  Or is itK > dollars of new system business.  If based upon dollars, then the quantity L > may still be low, and that isn't really growth of usage of VMS. If most ofL > the sales are to existing accounts, then retention of existing accounts isF > also a big question.  Suppose that for every sale of a new system, 5D > existing customers are moving off VMS.  There goes the after sales
 > dollars. > J > I don't think one liners say much.  In an environment desperate for good > news they can be misleading. > 3 > I think the descending order goes something like:  > 	 > 1) Lies  > 2) Damn lies > 3) Statistics  > G > Tell me that the number of customers purchasing software and hardware 5 > support is rising, and I'll get a bit more excited.  >  > Dave  I I can't argue with any negative comments in this thread as a result of my J original post. I attended the lecture and therefore am only the messenger.I That said, here are a few more items I recalled while rereading my notes:   	 * * * * *   J Almost all OpenVMS presentations in Europe were standing room only. I findK this interesting since it is a fact that the OpenVMS business is growing in L Europe. Maybe this is were the 12% growth is coming from? (my comments: manyG people forget that English is taught as a second language in almost allVL European countries; Imagine finally working on an OS that has human-friendlyK commands and a friendly help system. Many American and Canadian people lookiF upon Europe as some-what backward when the truth of the matter is theyL should be considered an economic juggernaut known to us as the United States of Europe.)   G In comparing Alpha technology to other machines in the industry, it was L mentioned that almost 33% of the components of an Alpha system were involvedJ in error detection, error correction, and redundancy. (my comment: I stillI can't believe that most IA32 systems are delivered without parity memory)g  H The fastest database on the planet is a product you can't buy: namely, aL special benchmark version of DB2 running on R6000. According to the seminar,H the fastest database on the planet is Oracle RDB on Alpha. (my comments:G actual machine models were not given but I'm assuming they were talking  about the AS-GS1280)  K Oracle was thinking of dropping Oracle DB (not Oracle RDB) from OpenVMS butoI has recently changed its mind. (my comment: some people in the lunch lineeG stated that Oracle had decided to more aggressively pursue OpenVMS onlyu0 because of the availability of MySQL on OpenVMS)  F As I said previously, there were two seminars on porting from Alpha toI Itanium. One seminar was put on by an Oracle RDB employee while the other-I was put on by an OpenVMS Engineering employee. For me, these two seminars K justified the seminar admission fee (and also brought back fond memories oftA my porting efforts from VAX to Alpha which now seem amateurish bytF comparison). I picked up on an off-the-cuff comment from one of the HPF employees regarding the penalty incurred for unaligned variables: "TheJ Itanium is a really dumb chip; it works just like a vacuum cleaner suckingI up instructions so you had better format your programs and data in such aa" way to make up for this stupidity)  I The last day for ordering an Alpha system from HP will be 2006-09-30 with-F last ship day to be 2006-12-31. They admitted that Alpha systems stillK slightly out-perform Itanium systems put that will change before the summer0L of 2005. (sounds to me like the complier people still needed to do some more	 tweaking)   E There are currently 75 companies making computers based upon IA64 (my L comment: this could be someone at HP trying to justify killing Alpha since IG didn't think their were 75 computer companies out there (unless you are   counting 3 man operations etc.))  K Many customers are experiencing external pressures to add web-based support2< to green screen applications. The industry is split between:( 1) augmenting the apps with .NET support( 2) augmenting the apps with Java support 3) rewriting the apps.H One presenter from OpenVMS Engineering mentioned that a very cool fourthG solution was available from WRQ (www.wrq.com) but I forgot the name and F wasn't able to get close to the presenter after the seminar. (was like1 trying to get back stage at a Pink Floyd concert)   G One interesting fact was a new method of selling Alpha's and OpenVMS bysJ stealth; HP has teamed up with an email vendor to sell DS10s (and higher?)I with pre-installed email hosting software targeted at the SMB market. The I Alpha becomes the email host for small companies; scans email for virusespL and worms, etc.; the OS and email s/w is totally configurable by browser; noG client s/w is required since employees must use a browser to read their < emails. Apparently these systems are selling like hot cakes.  	 * * * * *   L Well that's all I can recall for now. I'll let you know when the presenter's& slides will be available for download.    
 Neil Rieck Kitchener/Waterloo/Cambridge,n Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  % Date: Sat, 26 Feb 2005 11:01:25 -0500s. From: JF Mezei <jfmezei.spamnot@vaxination.ca>A Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few pointseB Message-ID: <1109432950.a26641917fdcc5339d4be17f81ccc780@teranews>   Neil Rieck wrote:aM > commands and a friendly help system. Many American and Canadian people look H > upon Europe as some-what backward when the truth of the matter is they- > should be considered an economic juggernautR  G In this region of Canada, Europe has not been underestimated for a veryaG very very long time. Perhaps because we don't watch CTV which is just aRH rehash of US news. Digital had a big presence in France and Switzerland,H Alpha servers were manufactured in Scottland. ALL-IN-1 came from Reading: (England - but its leftovers are now outsourced to India).  F But even on a regional basis, VMS has never been strong in Qubec (dueF to bad sales people), but in a certain southwestern region of Ontario,E it seemed to sell like hotcakes and the sales people there were fully H comitted to custoemrs, and able to generate real presentatiosn with real@ people, something the DEC people in Montreal couldn't do. So theG strength of a DEC product seemed to depend on the local sales people in H individual regions. And when Palmer decimated the sales force, when that was it.e    K > The last day for ordering an Alpha system from HP will be 2006-09-30 with ! > last ship day to be 2006-12-31.p  D Will HP make a big splash and cast this in stone, or is this a trialH balloon ? If VMS sales are growing, this would mean that Alpha sales areD growing and there should be no reason to can the product that has noG more development costs to it. HP/Compaq hadv long and often stated thata6 they would sell alphas as long as demand warranted it.   ------------------------------  % Date: Sat, 26 Feb 2005 10:35:57 -0500c) From: "Neil Rieck" <n.rieck@sympatico.ca> A Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few points1; Message-ID: <QH0Ud.60308$Am3.1911187@news20.bellglobal.com>t  / <susan_skonetski@hotmail.com> wrote in message s= news:1109424649.985638.184010@z14g2000cwz.googlegroups.com...sG > Thanks for the feedback on my presentation I guess then there will belH > no need to post it, probably a good thing since it is 65M any way withF > loads of pictures.  Amazing since only Neil was actualy the only oneD > there to hear the details and there was so much information in the& > notes ;') (Neil -  Excutive Council) > Suek >   A Sue. I think it's safe to say that we all would like to see your  M presentation as well as all the others. I was hoping the set would be posted i to:t http://www.encompasscanada.com/-  K p.s. pictures from your 2003 presentation in Ottawa are still available at:S1 http://www.canacu.org/events-techsem-ottawa03.htmoI The last picture is of Terry Shannon with Digital Canada cofounder Denny e (Densel) Doyle    
 Neil Rieck Kitchener/Waterloo/Cambridge,b Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html   ------------------------------  # Date: Sat, 26 Feb 2005 16:37:45 GMTo5 From: rdeininger@mindspringdot.com (Robert Deininger)oA Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few pointshL Message-ID: <rdeininger-2602051137450001@user-105n8hu.dialup.mindspring.com>  E In article <1109379855.97a4f2b49f0d83d805ddfa8693b8fff0@teranews>, JFa+ Mezei <jfmezei.spamnot@teksavvy.com> wrote:a    I >> OpenVMS Itanium licensing will be simpler and cheaper. The three majory >> categories are: >> FOE - Foundationa >> EOE - Enterprise1 >> MCOE - Mission Critical0 >> (languages will still be licensed separately) >oG >Is there any "workstation" class licencing ? (Hoff has been so adament F >that VMS would remain available in workstation-configured servers, so >one must ask about licencing)..  M FOE is likely the license bundle most customers will want for "workstations".t   ------------------------------  % Date: Sat, 26 Feb 2005 11:39:59 -0500 # From: "John Smith" <a@nonymous.com>oA Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few pointsl, Message-ID: <4IadnW7fT-L9O73fRVn-tA@igs.net>   JF Mezei wrote:e > Neil Rieck wrote:dB >> commands and a friendly help system. Many American and CanadianF >> people look upon Europe as some-what backward when the truth of the= >> matter is they should be considered an economic juggernaut  >hD > In this region of Canada, Europe has not been underestimated for aG > very very very long time. Perhaps because we don't watch CTV which istD > just a rehash of US news. Digital had a big presence in France andE > Switzerland, Alpha servers were manufactured in Scottland. ALL-IN-1eF > came from Reading (England - but its leftovers are now outsourced to	 > India).3 >3H > But even on a regional basis, VMS has never been strong in Qubec (dueH > to bad sales people), but in a certain southwestern region of Ontario,G > it seemed to sell like hotcakes and the sales people there were fullysE > comitted to custoemrs, and able to generate real presentatiosn with G > real people, something the DEC people in Montreal couldn't do. So thevF > strength of a DEC product seemed to depend on the local sales peopleC > in individual regions. And when Palmer decimated the sales force,h > when that was it.     K The financial marketing people from the mid-80's onward sucked. There was a J guy whose who was so ineffectual, I think he single-handedly drove most ofJ the financial community at a faster rate into the hands of Sun (a few into HP/Apollo).s    G >> The last day for ordering an Alpha system from HP will be 2006-09-30r' >> with last ship day to be 2006-12-31.s > F > Will HP make a big splash and cast this in stone, or is this a trialF > balloon ? If VMS sales are growing, this would mean that Alpha salesG > are growing and there should be no reason to can the product that hasuG > no more development costs to it. HP/Compaq hadv long and often stated = > that they would sell alphas as long as demand warranted it.   L 1) Alpha performance only has one direction to go vs. Itanic at this point - down.pC 2) HP will ensure that new Alpha's remain more expensive than IA64.eH 3) The VMS world will stock up on Alpha's as long as they figure IA64 isH migration exercise they care to to undertake, and as they consider their other migration options.I 4) 'Demand' is in the eyes of the beholder - the customers want it but HPhK chooses not to see it that way. There were more Alpha cpu's being fabbed intI 2001 (annual run rate) than are being fabbed today for IA64, yet Alpha is-L the dead chip that still outperforms Itanic 4 years later with nothing other& than a small process shrink inbetween.   --- OpenVMS - The classics never go out of style.6   ------------------------------  # Date: Sat, 26 Feb 2005 16:47:39 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger)dA Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few pointsnL Message-ID: <rdeininger-2602051147380001@user-105n8hu.dialup.mindspring.com>  E In article <1109432950.a26641917fdcc5339d4be17f81ccc780@teranews>, JFa, Mezei <jfmezei.spamnot@vaxination.ca> wrote:    L >> The last day for ordering an Alpha system from HP will be 2006-09-30 with" >> last ship day to be 2006-12-31. > E >Will HP make a big splash and cast this in stone, or is this a trial6I >balloon ? If VMS sales are growing, this would mean that Alpha sales arejE >growing and there should be no reason to can the product that has nosH >more development costs to it. HP/Compaq hadv long and often stated that7 >they would sell alphas as long as demand warranted it.s  G Many alphaserver systems and components will not be sellable in certain1F parts of the world due to regulatory changes.  Evaluating hardware for@ compliance with the new regs is expensive; re-engineering to getF non-compliant stuff into compliance is exceedingly expensive.  The newF regulations will cause a lot of low-volume products to retire somewhat" earlier than they otherwise would.   ------------------------------  # Date: Sat, 26 Feb 2005 17:54:23 GMTo5 From: rdeininger@mindspringdot.com (Robert Deininger) A Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few points L Message-ID: <rdeininger-2602051254230001@user-105n937.dialup.mindspring.com>  J In article <4IadnW7fT-L9O73fRVn-tA@igs.net>, "John Smith" <a@nonymous.com> wrote:   ...E   >cH >>> The last day for ordering an Alpha system from HP will be 2006-09-30( >>> with last ship day to be 2006-12-31. >>G >> Will HP make a big splash and cast this in stone, or is this a trial@G >> balloon ? If VMS sales are growing, this would mean that Alpha sales.H >> are growing and there should be no reason to can the product that hasH >> no more development costs to it. HP/Compaq hadv long and often stated> >> that they would sell alphas as long as demand warranted it. > M >1) Alpha performance only has one direction to go vs. Itanic at this point -  >down.D >2) HP will ensure that new Alpha's remain more expensive than IA64.  @ Since Alpha servers are quite a lot more expensive to build thanF Integrity, that seems reasonable.  I suppose HP could cut the price ofE Alpha systems and sell them at a loss, and undercut IA64 that way.  Ie= can't think of a good reason to do so off the top of my head.t   ...c   ------------------------------    Date: 26 Feb 2005 19:04:37 +0100K From: pmoreau@ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.68.40)jA Subject: Re: OpenVMS Seminar in Toronto (2005-02-24) a few pointsu! Message-ID: <VWMXBp+BCH8E@sinead>w   In article <rdeininger-2602051137450001@user-105n8hu.dialup.mindspring.com>, rdeininger@mindspringdot.com (Robert Deininger) writes:G > In article <1109379855.97a4f2b49f0d83d805ddfa8693b8fff0@teranews>, JF - > Mezei <jfmezei.spamnot@teksavvy.com> wrote:h >  > J >>> OpenVMS Itanium licensing will be simpler and cheaper. The three major >>> categories are:i >>> FOE - Foundation >>> EOE - Enterprise >>> MCOE - Mission Critical 1 >>> (languages will still be licensed separately)4 >>H >>Is there any "workstation" class licencing ? (Hoff has been so adamentG >>that VMS would remain available in workstation-configured servers, soc  >>one must ask about licencing). > O > FOE is likely the license bundle most customers will want for "workstations"..  I And what about a dual core dual thread IA64 ? Will the licence be 2 or 4  O times higher than the actual ?  And will mono-processor servers be available ? m   Patrickt --O ===============================================================================nN pmoreau@ath.cena.fr  (CENA)      ______      ___   _          (Patrick MOREAU)4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================u   ------------------------------  % Date: Sat, 26 Feb 2005 19:23:16 +1100t6 From: "O'Brien Paddy" <Paddy.O'Brien@transgrid.com.au>( Subject: RE: Ouch! a *MAJOR* bug in TPU.X Message-ID: <8BAD914A0B8CA84C9E94187103A1AB9E05BDF7@EX-TG2-PR.corporate.transgrid.local>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C51BDC.6BCB2B6E . Content-Type: text/plain; charset="iso-8859-1"+ Content-Transfer-Encoding: quoted-printableo  ' From: John Santos [mailto:john@egh.com]   I >I'm not a TPU user (usually), but I think the issue here is not that TPU,E >doesn't automatically clear the "NO WRITE" setting when you manually H >change the "NO MODIFY" setting and modify the buffer, but that TPU letsE >you exit when you have modified buffers and no where to put them.  I@F >think the OP would be happy if it said "You've got a modified buffer,C >do you really want to exit", and you could say "No", then save thepH >modified file to a new version of the existing file or whatever.  As it? >is, it just exits and all your hard work is in the bit-bucket.f >M? >Maybe there is a bit of magic that can be done in the OP's TPUeE >initialization file that would do exactly this?  (Force confirmations< >before exiting with modified, unwritable buffers, that is.)   John,o  L I am of the opinion that the OP got exactly what he asked for but didn't wa=L nt.  TPU gives us fields that say write/read and un/modifiable.  As has bee=L n explained, we can modify a read only file to (e.g.) look at lines beyond =5 our normal screen width, but still not want to write.h  L We are supposed to be intelligent administrators/managers/programmers, but =L if we cannot comprehend these two fields as having this differentiable sign=$ ificance, what hope for the newbies?  : No offence to the OP, we all have bad days -- I have many.   Regards, Paddy    G ***********************************************************************t  C "This electronic message and any attachments may contain privilegeds@ and confidential information intended only for the use of the=20D addressees named above.  If you are not the intended recipient of=20C this email, please delete the message and any attachment and advise D the sender.  You are hereby notified that any use, dissemination,=207 distribution, reproduction of this email is prohibited.   C If you have received the email in error, please notify TransGrid=20hC immediately.  Any views expressed in this email are those of the=20 ? individual sender except where the sender expressly and with=20TC authority states them to be the views of TransGrid.  TransGrid uses > virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************a    ' ------_=_NextPart_001_01C51BDC.6BCB2B6E>- Content-Type: text/html; charset="iso-8859-1"r+ Content-Transfer-Encoding: quoted-printablew  1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">s <HTML> <HEAD>L <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> K <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7226.0">e. <TITLE>RE: Ouch! a *MAJOR* bug in TPU.</TITLE> </HEAD>d <BODY>) <!-- Converted from text/plain format -->v  L <P><FONT SIZE=3D2>From: John Santos [<A HREF=3D"mailto:john@egh.com">mailto= :john@egh.com</A>]<BR> <BR>L &gt;I'm not a TPU user (usually), but I think the issue here is not that TP= U<BR>eL &gt;doesn't automatically clear the &quot;NO WRITE&quot; setting when you m= anually<BR>mL &gt;change the &quot;NO MODIFY&quot; setting and modify the buffer, but tha= t TPU lets<BR>L &gt;you exit when you have modified buffers and no where to put them.&nbsp;=  I<BR>L &gt;think the OP would be happy if it said &quot;You've got a modified buff= er,<BR>eL &gt;do you really want to exit&quot;, and you could say &quot;No&quot;, the= n save the<BR>L &gt;modified file to a new version of the existing file or whatever.&nbsp; =	 As it<BR> F &gt;is, it just exits and all your hard work is in the bit-bucket.<BR> &gt;<BR>F &gt;Maybe there is a bit of magic that can be done in the OP's TPU<BR>L &gt;initialization file that would do exactly this?&nbsp; (Force confirmati= on<BR>C &gt;before exiting with modified, unwritable buffers, that is.)<BR>  <BR>	 John,<BR>  <BR>L I am of the opinion that the OP got exactly what he asked for but didn't wa=L nt.&nbsp; TPU gives us fields that say write/read and un/modifiable.&nbsp; =L As has been explained, we can modify a read only file to (e.g.) look at lin=C es beyond our normal screen width, but still not want to write.<BR>a <BR>L We are supposed to be intelligent administrators/managers/programmers, but =L if we cannot comprehend these two fields as having this differentiable sign=( ificance, what hope for the newbies?<BR> <BR>> No offence to the OP, we all have bad days -- I have many.<BR> <BR> Regards, Paddy<BR> </FONT>0 </P>   <FONT SIZE=3D3><BR>- <BR>K ***********************************************************************<BR>  <BR>G "This electronic message and any attachments may contain privileged<BR> B and confidential information intended only for the use of the <BR>F addressees named above.  If you are not the intended recipient of <BR>G this email, please delete the message and any attachment and advise<BR> F the sender.  You are hereby notified that any use, dissemination, <BR>; distribution, reproduction of this email is prohibited.<BR>* <BR>E If you have received the email in error, please notify TransGrid <BR>dE immediately.  Any views expressed in this email are those of the <BR>iA individual sender except where the sender expressly and with <BR> G authority states them to be the views of TransGrid.  TransGrid uses<BR>gB virus-scanning software but excludes any liability for viruses<BR>  contained in any attachment.<BR> <BR>@ Please note the email address for TransGrid personnel is now<BR>( firstname.lastname@transgrid.com.au"<BR> <BR>K ***********************************************************************<BR>2 </FONT>i </BODY>e </HTML>w) ------_=_NextPart_001_01C51BDC.6BCB2B6E--h   ------------------------------   Date: 26 Feb 2005 08:13:50 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>( Subject: Re: Ouch! a *MAJOR* bug in TPU.? Message-ID: <DTiotGxQ0bj6-pn2-Wu8VTc3E47yI@dave2_os2.home.ours>s  3 On Sat, 26 Feb 2005 03:03:41 UTC, David J Dachtera *" <djesys.nospam@comcast.net> wrote:   > Bob Koehler wrote: > > d > > In article <421E99A1.9ED7F273@comcast.net>, David J Dachtera <djesys.nospam@comcast.net> writes: > > >qJ > > > You just corrupted your file. The cursor line is now one byte longerI > > > than the line above it. TPU/EVE has space-padded the line up to the=L > > > cursor position before you added a space, and then added the space you > > > just typed.  > > F > >    You just edited your file, telling TPU to put a space where the4 > >    cursor is.  That's hardly the editor's fault. > G > Well, actually, yes it is. See, the editor failed to first repositionhH > the cursor to the end of the line, which (IMO) it should have done. ItI > then added data I did not intend before adding the data I *DID* intend.g > 5 > I believe that is *THE* definition of "corruption".o > J > >    Yes, I know oher editors can and do use the space bar as a movementA > >    command.  Tradiationaly DEC's editors didn't and TPU is no? > >    exception.,  C I'm with t'other Dave. It's a feature I dislike. I know SET CURSOR *D whatever gets around it but it isn't default for my users and every B now and again (two in the last two weeks) we fall foul of it. The D reaction in our app has been resolved, if they update the format of F their input files, but otherwise the rule is 'DO TRIM' before save and& exit.  Me, I use SEDT for most things.   -- n Cheers - Dave W.   ------------------------------  % Date: Sat, 26 Feb 2005 19:37:00 +1100n6 From: "O'Brien Paddy" <Paddy.O'Brien@transgrid.com.au>( Subject: RE: Ouch! a *MAJOR* bug in TPU.X Message-ID: <8BAD914A0B8CA84C9E94187103A1AB9E05BDF9@EX-TG2-PR.corporate.transgrid.local>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C51BDE.56AF4DD4h. Content-Type: text/plain; charset="iso-8859-1"+ Content-Transfer-Encoding: quoted-printablei  9 From: David J Dachtera [mailto:djesys.nospam@comcast.net]i >Bob Koehler wrote:. >>=20BL >> In article <421E99A1.9ED7F273@comcast.net>, David J Dachtera ><djesys.no= spam@comcast.net> writes:" >> >I >> > You just corrupted your file. The cursor line is now one byte longer*H >> > than the line above it. TPU/EVE has space-padded the line up to theK >> > cursor position before you added a space, and then added the space you0 >> > just typed. >>=20 E >>    You just edited your file, telling TPU to put a space where the 3 >>    cursor is.  That's hardly the editor's fault.A >5F >Well, actually, yes it is. See, the editor failed to first repositionG >the cursor to the end of the line, which (IMO) it should have done. ItyH >then added data I did not intend before adding the data I *DID* intend. > 4 >I believe that is *THE* definition of "corruption". > I >>    Yes, I know oher editors can and do use the space bar as a movementd@ >>    command.  Tradiationaly DEC's editors didn't and TPU is no >>    exception.  L I have to agree with Bob here (I don't often disagree with his comments any=L way), except that this may not be corruption.  It could be an intentional m=L ove to add that extra white space.  I tend to have my TPU editor remove whi=L te space on exit and write, but there *could* be reasons that someone could=	  want it.s  J The editor has done exactly what you asked and what it was designed to do.   Regards, Paddy' [You're having a bad spelling day :-) ]a    G ***********************************************************************   C "This electronic message and any attachments may contain privilegedh@ and confidential information intended only for the use of the=20D addressees named above.  If you are not the intended recipient of=20C this email, please delete the message and any attachment and advisesD the sender.  You are hereby notified that any use, dissemination,=207 distribution, reproduction of this email is prohibited.n  C If you have received the email in error, please notify TransGrid=20bC immediately.  Any views expressed in this email are those of the=20.? individual sender except where the sender expressly and with=20cC authority states them to be the views of TransGrid.  TransGrid usesg> virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************r    ' ------_=_NextPart_001_01C51BDE.56AF4DD4a- Content-Type: text/html; charset="iso-8859-1"r+ Content-Transfer-Encoding: quoted-printable=  1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">g <HTML> <HEAD>L <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1">rK <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7226.0">n. <TITLE>RE: Ouch! a *MAJOR* bug in TPU.</TITLE> </HEAD>6 <BODY>) <!-- Converted from text/plain format -->r  L <P><FONT SIZE=3D2>From: David J Dachtera [<A HREF=3D"mailto:djesys.nospam@c=5 omcast.net">mailto:djesys.nospam@comcast.net</A>]<BR>n &gt;Bob Koehler wrote:<BR> &gt;&gt;<BR>L &gt;&gt; In article &lt;421E99A1.9ED7F273@comcast.net&gt;, David J Dachtera=2  &gt;&lt;djesys.nospam@comcast.net&gt; writes:<BR> &gt;&gt; &gt;<BR>sL &gt;&gt; &gt; You just corrupted your file. The cursor line is now one byte=  longer<BR>tL &gt;&gt; &gt; than the line above it. TPU/EVE has space-padded the line up =
 to the<BR>L &gt;&gt; &gt; cursor position before you added a space, and then added the =
 space you<BR>m &gt;&gt; &gt; just typed.<BR>v &gt;&gt;<BR>L &gt;&gt;&nbsp;&nbsp;&nbsp; You just edited your file, telling TPU to put a = space where the<BR>eL &gt;&gt;&nbsp;&nbsp;&nbsp; cursor is.&nbsp; That's hardly the editor's faul= t.<BR> &gt;<BR>L &gt;Well, actually, yes it is. See, the editor failed to first reposition<B= R>L &gt;the cursor to the end of the line, which (IMO) it should have done. It<= BR>hL &gt;then added data I did not intend before adding the data I *DID* intend.= <BR> &gt;<BR>E &gt;I believe that is *THE* definition of &quot;corruption&quot;.<BR>t &gt;<BR>L &gt;&gt;&nbsp;&nbsp;&nbsp; Yes, I know oher editors can and do use the spac= e bar as a movement<BR> L &gt;&gt;&nbsp;&nbsp;&nbsp; command.&nbsp; Tradiationaly DEC's editors didn'= t and TPU is no<BR>i) &gt;&gt;&nbsp;&nbsp;&nbsp; exception.<BR>a <BR>L I have to agree with Bob here (I don't often disagree with his comments any=L way), except that this may not be corruption.&nbsp; It could be an intentio=L nal move to add that extra white space.&nbsp; I tend to have my TPU editor =L remove white space on exit and write, but there *could* be reasons that som= eone could want it.<BR>  <BR>L The editor has done exactly what you asked and what it was designed to do.<= BR>  <BR> Regards, Paddy<BR>. [You're having a bad spelling day :-) ]</FONT> </P>   <FONT SIZE=3D3><BR>d <BR>K ***********************************************************************<BR>r <BR>G "This electronic message and any attachments may contain privileged<BR>rB and confidential information intended only for the use of the <BR>F addressees named above.  If you are not the intended recipient of <BR>G this email, please delete the message and any attachment and advise<BR>sF the sender.  You are hereby notified that any use, dissemination, <BR>; distribution, reproduction of this email is prohibited.<BR>n <BR>E If you have received the email in error, please notify TransGrid <BR>AE immediately.  Any views expressed in this email are those of the <BR>tA individual sender except where the sender expressly and with <BR>tG authority states them to be the views of TransGrid.  TransGrid uses<BR> B virus-scanning software but excludes any liability for viruses<BR>  contained in any attachment.<BR> <BR>@ Please note the email address for TransGrid personnel is now<BR>( firstname.lastname@transgrid.com.au"<BR> <BR>K ***********************************************************************<BR>s </FONT>0 </BODY>1 </HTML>n) ------_=_NextPart_001_01C51BDE.56AF4DD4--r   ------------------------------  % Date: Sat, 26 Feb 2005 19:40:44 +1100 6 From: "O'Brien Paddy" <Paddy.O'Brien@transgrid.com.au>( Subject: RE: Ouch! a *MAJOR* bug in TPU.X Message-ID: <8BAD914A0B8CA84C9E94187103A1AB9E05BDFA@EX-TG2-PR.corporate.transgrid.local>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C51BDF.7DADF85Fi. Content-Type: text/plain; charset="iso-8859-1"+ Content-Transfer-Encoding: quoted-printable   ; From: O'Brien Paddy [mailto:Paddy.O'Brien@transgrid.com.au]BL >I am of the opinion that the OP got exactly what he asked for but didn't w=L ant.  >TPU gives us fields that say write/read and un/modifiable.  As has b=L een >explained, we can modify a read only file to (e.g.) look at lines beyo=9 nd our >normal screen width, but still not want to write.s  L Sorry to reply to myself, but I meant to add that I use this feature of the=L  editor extensively when I am looking at files in CMS reference libraries. =L  I sometimes even want to see how revised code looks without the danger of =L overwriting the reference copy.  And without the necessity of fetching the = code.s   Regards, Paddy    G ***********************************************************************   C "This electronic message and any attachments may contain privilegedo@ and confidential information intended only for the use of the=20D addressees named above.  If you are not the intended recipient of=20C this email, please delete the message and any attachment and advise:D the sender.  You are hereby notified that any use, dissemination,=207 distribution, reproduction of this email is prohibited.   C If you have received the email in error, please notify TransGrid=20rC immediately.  Any views expressed in this email are those of the=20t? individual sender except where the sender expressly and with=20 C authority states them to be the views of TransGrid.  TransGrid usess> virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************a    ' ------_=_NextPart_001_01C51BDF.7DADF85Fn- Content-Type: text/html; charset="iso-8859-1"r+ Content-Transfer-Encoding: quoted-printable   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">  <HTML> <HEAD>L <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> K <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7226.0"> . <TITLE>RE: Ouch! a *MAJOR* bug in TPU.</TITLE> </HEAD>  <BODY>) <!-- Converted from text/plain format -->i  L <P><FONT SIZE=3D2>From: O'Brien Paddy [<A HREF=3D"mailto:Paddy.O'Brien@tran=< sgrid.com.au">mailto:Paddy.O'Brien@transgrid.com.au</A>]<BR>L &gt;I am of the opinion that the OP got exactly what he asked for but didn'=L t want.&nbsp; &gt;TPU gives us fields that say write/read and un/modifiable=K &nbsp; As has been &gt;explained, we can modify a read only file to (e.g.)=gL  look at lines beyond our &gt;normal screen width, but still not want to wr= ite.<BR> <BR>L Sorry to reply to myself, but I meant to add that I use this feature of the=L  editor extensively when I am looking at files in CMS reference libraries.&=L nbsp; I sometimes even want to see how revised code looks without the dange=L r of overwriting the reference copy.&nbsp; And without the necessity of fet= ching the code.<BR>u <BR> Regards, Paddy<BR> </FONT>  </P>   <FONT SIZE=3D3><BR>A <BR>K ***********************************************************************<BR>3 <BR>G "This electronic message and any attachments may contain privileged<BR> B and confidential information intended only for the use of the <BR>F addressees named above.  If you are not the intended recipient of <BR>G this email, please delete the message and any attachment and advise<BR>cF the sender.  You are hereby notified that any use, dissemination, <BR>; distribution, reproduction of this email is prohibited.<BR>e <BR>E If you have received the email in error, please notify TransGrid <BR> E immediately.  Any views expressed in this email are those of the <BR>tA individual sender except where the sender expressly and with <BR>cG authority states them to be the views of TransGrid.  TransGrid uses<BR> B virus-scanning software but excludes any liability for viruses<BR>  contained in any attachment.<BR> <BR>@ Please note the email address for TransGrid personnel is now<BR>( firstname.lastname@transgrid.com.au"<BR> <BR>K ***********************************************************************<BR>e </FONT>n </BODY>t </HTML> ) ------_=_NextPart_001_01C51BDF.7DADF85F--k   ------------------------------  # Date: Sat, 26 Feb 2005 16:34:24 GMTm5 From: rdeininger@mindspringdot.com (Robert Deininger)f Subject: Re: Sayonara TukwillaL Message-ID: <rdeininger-2602051134240001@user-105n8hu.dialup.mindspring.com>  3 In article <BuWrbJYQTxAM@eisner.encompasserve.org>,n, young_r@encompasserve.org (Rob Young) wrote:   ...y  K >> Yeah.  Either this is going to be about as momentous as NEC's 'embrace' tJ >> of Itanic for the past few years, or (if Fujitsu does as good a job as I >> they have with SPARC64) it'll be good news for Intel but bad news for t >> Integrity & Superdome.t >aE >        Superdome is long in the tooth.  Surely something new in theiE >        wings, but of course not much chatter or it freezes existingl >        sales.k  ( Yes, there's something new in the wings.   ------------------------------   End of INFO-VAX 2005.114 ************************