1 INFO-VAX	Fri, 17 May 2002	Volume 2002 : Issue 272       Contents: 7.3 for VAX  Re: 7.3 for VAX  ABC - America, get on VMS now before it's too late! 1 Re: America, get on VMS now before it's too late! $ Any UK-based Bacway users out there?3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 3 Re: Capellas: Linux, Windows Will 'Eviscerate' Unix 8 Re: Comments on ITUG/DECUS joint Euro conference in Lyon8 Re: Comments on ITUG/DECUS joint Euro conference in Lyon8 Re: Comments on ITUG/DECUS joint Euro conference in Lyon8 Re: Comments on ITUG/DECUS joint Euro conference in Lyon DEC Alumni Association& DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)* Re: DECUS Lyon: Another VMS summary (long)- Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning - Re: Forced migration to HPHUX - Storm Warning  Re: FTP queue ? / Re: HP is like Q ... just doesn't get it proof!  Re: ICC question Re: ICC question Re: ICC question Re: ICC question Re: ICC question IFDL Re: ISE just spammed me... Re: ISE just spammed me... Re: ISE just spammed me...P Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX -  Storm WarniM Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm Warning P Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm WarninP Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm WarninP Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm Warnin Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales Re: No new Alpha sales% Re: Non-interactive TECO? (of course) % Re: Non-interactive TECO? (of course) % Re: Non-interactive TECO? (of course) % Re: Non-interactive TECO? (of course) $ Re: Non-interactive TECO? (solution)- NY NYC VMS Senior Systems Manager job opening  PLUG: txt2pdf 5.7 0 Re: Problem with the internal clock of an XP1000 Re: TCP/IP for VMS...HELP!5 Traditional VMS NFS names vs. Extended Filename Parse 9 Re: Traditional VMS NFS names vs. Extended Filename Parse 9 Re: Traditional VMS NFS names vs. Extended Filename Parse 4 Re: vax/alpha print to hp laser printers help needed4 Re: vax/alpha print to hp laser printers help needed? Re: VMS 7.3 upgrade problems - a bad workman blaming his tools? ? Re: VMS 7.3 upgrade problems - a bad workman blaming his tools? ? Re: VMS 7.3 upgrade problems - a bad workman blaming his tools? ? Re: VMS 7.3 upgrade problems - a bad workman blaming his tools? ? Re: VMS 7.3 upgrade problems - a bad workman blaming his tools? ? Re: VMS 7.3 upgrade problems - a bad workman blaming his tools? 1 VMS GKS Manuals for giveaway in Richmond, VA area  Re: Who cares about marketing! Re: Worth a read Re: Worth a readP Re: [Q] How do you set the SQO bit in the FAB (FAB, RAB, which field has this biP Re: [Q] How do you set the SQO bit in the FAB (FAB, RAB, which field has this biP Re: [Q] How do you set the SQO bit in the FAB (FAB, RAB, which field has this bi  F ----------------------------------------------------------------------  % Date: Fri, 17 May 2002 07:10:45 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: 7.3 for VAX9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEBGFAAA.tom@kednos.com>   : The kits from CSA cull the VAX OpenVMS CD, and there is noA CSA discount.  Did anybody else get one as part of their CSA kit?   A I know we have had this discussion before, but I don't understand D why HPQ doesn't provide for downloads of various versions of the OS.  B I downloaded Solaris last weekend, took less than an hour on a T1.3 This not about money, it is about customer service.    Anybody at HPQ listening?   - I have customers still upgrading their VAXes!  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).? Version: 6.0.360 / Virus Database: 199 - Release Date: 5/7/2002    ------------------------------    Date: 17 May 2002 10:04:58 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: 7.3 for VAX3 Message-ID: <XUlHoxTLc5RV@eisner.encompasserve.org>   _ In article <CIEJLCMNHNNDLLOOGNJIKEBGFAAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes: < > The kits from CSA cull the VAX OpenVMS CD, and there is noC > CSA discount.  Did anybody else get one as part of their CSA kit?  > C > I know we have had this discussion before, but I don't understand F > why HPQ doesn't provide for downloads of various versions of the OS.  D When CSA was founded they saw their mission as promoting only Alpha.G They do not report to VMS Development, who might have a different view.    > Anybody at HPQ listening?   4 At least one CSA person sometimes reads comp.os.vms.  ( > Outgoing mail is certified Virus Free.< > Checked by AVG anti-virus system (http://www.grisoft.com).A > Version: 6.0.360 / Virus Database: 199 - Release Date: 5/7/2002   4 Please remove this, so we can get people off PCs :-)   ------------------------------  % Date: Fri, 17 May 2002 12:27:22 -0500 4 From: "Lucas, Edward A (SAIC)" <Edward.Lucas@bp.com> Subject: ABC? Message-ID: <EF1DC894691AD5118AF000508BB85FDE034CC62A@AMCLVX11>    Hello everyone  E The company I work for would like to change our backup system over to 	 SSSI/ABC.   7 Can anyone send me the thoughts/experience's using ABS.   I Currently I am using Tapesys. Tapesys uses VMSBU.EXE, ABC part of Tivoli. F The backup server is a TSM server (replace ADSM).  ABC runs on the VMS	 platform.   K I am a little confused.  ABC runs on the VMS platform and communicates with 5 a TSM server.  The TSM Server does the actual backup. L On the TSM server the team needs to set us up with an account.  Hmmmmmm,  NoF IO or anytype of processing on my end.  Its like something is missing.   Edward A. Lucas   Sr. VAX/VMS System Administrator SAIC Phone:  (216) 525-7492 Email:   Lucaea@bp.com   ------------------------------    Date: 17 May 2002 05:49:32 -0700( From: bob@instantwhip.com (Bob Ceculski)6 Subject: America, get on VMS now before it's too late!= Message-ID: <d7791aa1.0205170449.7a40f4ba@posting.google.com>   4 I think this sums it up why you better be on vms ...  L http://story.news.yahoo.com/news?tmpl=story&cid=75&ncid=738&e=8&u=/nf/200205 16/tc_nf/17784  , Fanatics with Laptops: The Coming Cyber War  Thu May 16, 1:46 PM ET  ! Tim McDonald, www.NewsFactor.com    > The blossoming of the Internet and its universal adoption haveC reinforced a trend toward interdependence of the world's political,  economic and social systems.     2  U.S.: Cyber Strike Could Earn Military Response +  Cyber Security Key to New U.S Initiative  -  Both Sides Using Internet in Terrorism War     F That increasing interdependence, however, becomes frightening when one@ considers that a next-generation cyber terrorist will likely not$ represent an aggressive world power.  D In terms of present-day vulnerability, such a terrorist could simply< be a lone fanatic wielding a laptop. And the damage could be staggering.    'Asymmetric Warfare'    D A study by the Rand Corporation in the mid-1990s found that it would3 be absurdly inexpensive to embark upon a cyber war.   ? The military call it "asymmetric warfare," which means that the > disadvantaged side must use unconventional weapons against the6 wealthier side if it is to have any chance of winning.  C Any country that can scrape together the price of a computer manual 9 and that has a basic understanding of information systems < infrastructure can train and motivate a misguided "patriot."   Anonymous Warfare   C Due to recent advances in "attack technology," cyber warfare can be @ waged remotely and anonymously. This approach would make it muchB harder to find an attacker than it is, for example, to root out AlE Qaeda forces along the border of Pakistan and Afghanistan (news - web  sites).   D "Because of the advances in attack technology, a single attacker canA relatively easily employ a large number of distributed systems to C launch devastating attacks against a single victim," according to a E report by the Computer Emergency Response Team (CERT), a major center 4 for Internet security at Carnegie Mellon University.  F "As the automation of deployment and the sophistication of attack toolB management both increase, the asymmetric nature of the threat will# continue to grow," the report said.   " New Tactics: Poison and Hijacking   > CERT pointed out that the number of newly discovered flaws andE vulnerabilities in computer software and Internet infrastructure more  than doubles each year.   F Attackers are finding more ways to bypass firewalls and other security? roadblocks. Some of the newer -- and nastier -- tactics involve A attacks on the Internet domain name system (DNS), including cache  poisoning and domain hijacking.   D Hackers are increasingly able to disguise the nature of attacks with> anti-forensic tools and "polymorphic" attack tools that evolve5 rapidly, even while they are in the act of attacking.   D "In the last six months, I would say that we've seen their firepower? increase -- we've seen them knock whole ISPs off the Net," SANS 5 Institute director Stephen Northcutt told NewsFactor.   @ "It's pretty hard to know what they're doing at the nation-state? level, but I'd say there's very little doubt they have the same  capability," Northcutt said.   Continuing Consequences   D Businesses, especially large corporations, are becoming targets withC increasing frequency. In the right hands, cyber attacks could wreak  untold damage.  > According to a CERT report, "[Such attacks] would likely cross9 boundaries between government and private sectors and, if C sophisticated and coordinated, would have both immediate impact and  delayed consequences.   @ "Ultimately, an unrestricted cyber attack would likely result inE significant loss of life as well as economic and social degradation,"  the report added.    War Could Spill Over    A As the Arab-Israeli conflict continues to escalate, the odds of a F full-scale cyber war grow. The first Arab-Israeli cyber war erupted inD 2000, when Israeli hackers attacked the site of a Hezbollah group inF London. Arabs retaliated by attacking the main Israeli government site( and the Israeli Foreign Ministry's site.  C Israel, like the United States, is a prime target. The tiny country D has roughly 1.1 million Internet connections -- more than the numberF of connections in all 22 Arab countries combined -- and its economy is  increasingly Internet-dependent.  D Arab terrorists also have made it clear that they are aware of whichC U.S. corporations do business with Israel. One such company, Lucent E (news - web sites) Technologies (NYSE: LU - news), found itself under / attack in the last Israeli-Arab cyber skirmish.    U.S. Defenses Improving   C How prepared is the United States? Not very, according to analysts. E There has been some improvement, such as the Clinton Administration's C 10-step National Plan for Critical Infrastructure, drafted in 1999.   @ Only in the past year has action been taken, however, by openingA serious discussions about creating separate networks for critical C federal agencies; granting computer security scholarships in return F for national service; and increasing the budget for computer security.  = Using students from U.S. military academies as attackers, the ? Department of Defense (news - web sites) has been running cyber E security exercises against the National Security Agency, the U.S. Air C Force's 92nd Information Warfare Aggressor Squadron, and the Army's " Land Information Warfare Activity.  F What they have learned is that the "install-and-patch" system does notB work, especially against a concentrated attack. Operating systems,? they have concluded, need to be designed more securely from the  outset.    Special Response Teams    C Federal agencies have been required for two years to report hacking C incidents or cyber attacks to the General Services Administration's  (GSA) FedCIRC.  F The GSA, for its part, has been pushing for government agencies to setC up special response teams so that incidents can be reported quickly E and completely, allowing for detection of trends and establishment of  effective counterstrategies.  D NASA (news - web sites) set up such teams in 1993, while the Federal@ Aviation Administration (news - web sites) established a team inF March, and the Veterans Affairs agency has taken steps to follow suit.  B "September 11th raised awareness," said Sallie McDonald, assistantA commissioner for the Office of Information Assurance and Critical  Infrastructure Protection.  F "When agencies started dusting off their disaster recovery plans, theyC realized they need to have cyber-disaster recovery plans, too," she  said.   ? As events in Israel recently have shown, one person with a bomb A strapped to his or her body can take a large economic toll, at an  incalculable human cost.  C An equally fanatical individual, with a little more knowledge and a D much lighter load, can, if we do not defend against it, use a laptop9 to do unimaginable damage at no personal cost whatsoever.    ------------------------------    Date: 17 May 2002 10:19:00 -0700( From: bob@instantwhip.com (Bob Ceculski): Subject: Re: America, get on VMS now before it's too late!< Message-ID: <d7791aa1.0205170918.4657ff6@posting.google.com>  > notice this quote from the above article ... doesn't this mean& OpenVMS is the only alternative?  Yes!    G "What they have learned is that the "install-and-patch" system does not B work, especially against a concentrated attack. Operating systems,? they have concluded, need to be designed more securely from the  outset."   ------------------------------  % Date: Fri, 17 May 2002 16:37:04 +0000   From: Steve.Spires@yellgroup.com- Subject: Any UK-based Bacway users out there? : Message-ID: <OF70EEFCC8.1B95F59A-ON00256BBC.005B1C55@btyp>  . Just been handed this as nobody else wants it.  J Really just want to chat to any other users, as soon as I was handed this,G Microgen told me I need to upgrade it, but I need to chat to some other G users about this. as they seem a bit vague about WHY I need to upgrade.    TIA    Steve Si      F ______________________________________________________________________     [Information] -- PostMaster:D This transmission is intended solely for the addressee(s) and may beG confidential. If you are not the named addressee, or if the message hasnG been addressed to you in error, you must not read, disclose, reproduce,t$ distribute or use this transmission.  H Delivery of this message to any person other than the named addressee isG not intended in any way to waive confidentiality.  If you have receivediK this transmission in error please contact the sender or delete the message.c  
 Thank you.  D Yell Limited, Queens Walk, Oxford Road, Reading, Berkshire, RG1 7PT.; Registered in England and Wales, registered number 4205228.o  I Yellow Pages Sales Limited, Queens Walk, Oxford Road, Reading, Berkshire,iD RG1 7PT. Registered in England and Wales, registered number 1403041.   ------------------------------  % Date: Fri, 17 May 2002 10:40:20 +0200 E From: Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> < Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix+ Message-ID: <3CE4C1F4.A369939E@mediasec.de>r  I > of the HSC... etc, of XPs with FC, or multi initiator SCSI... what everl> > then I guess it's upto the DLM to decide where best to cache  H The DLM provides the mechanisms for coordination, but doesn't coordinateI things itself. THe XQP does coordination for the file system-level stuff,MA RMS does it for records in files, and XFC (once it actually worksEJ proporly) for the (distributed) block cache. You (or Oracle or...) can use. it to coordinate activity in your application.   	Jan   ------------------------------  % Date: Fri, 17 May 2002 10:24:04 +0100l& From: Ken Green <Ken.Green@kgcc.co.uk>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix* Message-ID: <3CE4CC34.EDF57A9A@kgcc.co.uk>   "Jan C. Vorbrggen" wrote:  K > > of the HSC... etc, of XPs with FC, or multi initiator SCSI... what everu@ > > then I guess it's upto the DLM to decide where best to cache >cJ > The DLM provides the mechanisms for coordination, but doesn't coordinateK > things itself. THe XQP does coordination for the file system-level stuff,iC > RMS does it for records in files, and XFC (once it actually worksaL > proporly) for the (distributed) block cache. You (or Oracle or...) can use0 > it to coordinate activity in your application. >U
 >         Jann  I It's the block level cache'ing that had intriugued me, it's that bit thatP lookstG difficult. From your comments I'm not the only one who thinks thats thep
 hard part.  & Now I just need to find a glossary :-)   Cheers   Kenu   ------------------------------  % Date: Fri, 17 May 2002 11:10:44 +0100aU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>m< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix0 Message-ID: <ac2ldm$4sp$1@new-usenet.uk.sun.com>   Bill Todd wrote:  : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:L3s$ecziuKOu@eisner.encompasserve.org...m >  > ...  >  > 
 >>the 390s' >>support 16 - CPUs 64 GByte of memory.  >> > N > Have you checked to see what the newer 64-bit z-Series supports?  I haven't,M > but 4 GB/CPU seems suspiciously like a 32-bit size limit that might well noo > longer apply.  >     > The z900's do support 16 CPU's and 64 GB of RAM, quite how IBM> think you could virtualise 1000's of indevidual Linux sessions> on a system this memory limitted is a bit of a tricky question< to answer but then this is after all a mainframe so anything is possible :):):)  5 http://www-1.ibm.com/servers/eserver/zseries/900.html    Regardsa Andrew Harrisonw   ------------------------------  % Date: Fri, 17 May 2002 11:32:16 +0100pU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> < Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix0 Message-ID: <ac2mm2$57s$1@new-usenet.uk.sun.com>   Bob Ceculski wrote:o   > Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<ac0dt9$f3a$2@new-usenet.uk.sun.com>...F >  >>Bob Ceculski wrote:m >> >>d >>>JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3CDC104D.938DB683@videotron.ca>... >>>l >>>  >>>>Bob Ceculski wrote:n >>>> >>>>K >>>>>it already has survived, and I would say that jstars, miltary, DOD, US L >>>>>gov use, Cerner, Pitts. Super Computing and the list goes on and on areN >>>>>the reason vms will survive ... MPE was 16 bit, neglected, no clustering, >>>>>b >>>>>mL >>>>Consider some recent "super computing" deal that HP signed, promising toP >>>>deliver a super machine with over 1000 CPus based on IA64. Sounds to me thatM >>>>HP isn't even interested in selling Alphas NOW, they prefer to delay casho' >>>>input until IA64 is actually ready.  >>>>N >>>>Secondly, jstarts, military etc are just like existing MPE customers: theyP >>>>will continue to receive support. They do not mean that VMS will continue to >>>>be developped. >>>> >>>>D >>>the only tools vms needs are in place ... "C" and Java and ApacheD >>>(html,xml) are in place ... anything can now be ported w/relativeB >>>ease from unix/linux ... 3rd party vendors/shareware will take G >>>over from here ... ports have already begun, esp. java (BEA,Ericom)!  >>>g >>> # >>No BEA is actually a bad example.n >>E >>WLS is available but OpenVMS support lags other platforms and other C >>BEA ecommerce products do not run on OpenVMS meaning that you arenH >>unlikely to pick up any platform business if you are in an environment8 >>where other BEA products are required appart from WLS. >>	 >>Regardsd >>Andrew Harrisonn >> > C > we are talking web platform here ... other services can be found r > elsewhere or written ... >     E A portal server is a web platform, BEA portal server is not supportedm on OpenVMS.i  F BEA WLS is one major release back, even Tuxedo is 2 major releases out on OpenVMS etc etc etc.s       Regards- Andrew Harrison7   ------------------------------  % Date: Fri, 17 May 2002 12:01:47 +01000& From: Ken Green <Ken.Green@kgcc.co.uk>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix* Message-ID: <3CE4E31B.B27CFEAB@kgcc.co.uk>  C Thanks for your replies Bill, sorry for not responding straight waymE but I wanted to think a little first (I realise this is not somethingo) that is normally incouraged on Usenet :-)      Bill Todd wrote:  5 > "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messaget& > news:3CE22A9C.D4CC9952@kgcc.co.uk... > > Bill Todd wrote: >v > ...v >iJ > > > So how do multiple systems access any shared data at all (whether on > shared6 > > > disk or not) without using some sort of network? > > >r > >iK > > Sorry this was what I was talking about, some apps need shared and somed- > > don't, non shared is quicker than shared.V >sC > Not unless  1) the data you need happens to be local to where the I > application is running (in which case, there's no need for that data toeK > reside on a distributed file system at all:  just use a local one for it)-M > and  2) the OS is not smart enough to optimize out sharing overhead when nod" > sharing in fact is taking place. >g  >  Even if you can eliminate anyN > > overhead in having the shred capability in place when it is not being used> > > you can still find it is being used when it is not needed. > K > I suppose in some systems that could be true.  But it's not in VMS:  on aeL > per-file basis, if on file open it is noted that no one else is interestedG > in the file, the opening host obtains complete control over it and no M > distributed activity is required thereafter unless some other host developsrK > a concurrent interest in it (and if that host is found to be accessing itiG > more intensely than the original one, then the DLM moves coordinating  > responsibility over there).d >d  C The problem here I was alluding to was one we saw a number of times4E in DUX clusters. When any one system has the file open, then there is7C no problem. When multiple systems have the file open read only thenuE again there is no problem. But if the file was then opened read/write1J control needs to pass to one system, and the others then no longer locally cache.  J When this is required there is little option, however we found cases whereJ files were being open'd  rw but then only ever read, but still managing to2 hit the performance for everyone sharing the file.       >r > >  > > > N > > > With non-shared disks, if you want to share data among systems they need > toF > > > cooperate, just as they need to using shared disks.  The primary > differenceK > > > due to the sharing of the disk is that when desired data isn't cached K > > > somewhere the system that wants it can, after obtaining any necessarys > locks,L > > > get it directly from (or send it directly to) the disk rather than ask > some, > > > other system to get it and send it on. > >vG > > The problem comes when someone else is caching the data. How do you J > > cope. Do you manage cache coherency on a per IO basis or on a per file
 > > basis. >  > Per-I/O basis, for VMS.  >d > >tL > > If you try to do it on a per IO basis, then every read or write needs to > check, > N > Only if inter-host sharing actually occurs (see above).  And, as I explainedM > later, even when it is necessary this does not increase the network messagee/ > traffic over that required for 'served' data.  >    OK   >t > >s0 > > so you loose the advantage of local caching. >hN > No.  Once you have the data, you can cache it until some other host wants toH > modify it, and reuse it without additional interactions for that time. >a" >  You could minimise this to onlyM > > impacting writes I guess but that would require all systems to maintain ah* > > cache directory for the whole cluster. >aN > Nope.  I recommend the 1987 Digital Technical Journal explanation of how theG > VMS DLM works (it used to be on line at Compaq, anyway).  Or the moreaG > extensive explanations in the VMS Internals and Data Structures book.t >s > >sN > > If you do it on a per file basis, it's much easier. At open time you checkG > > whether you are the only node accessing the file, or that all nodesn > accessingtL > > are only open for reading, in this case there is no problem with caching > atJ > > both ends. However once a node opens a shared file for writes then theH > > caching needs to be done in just one place, or as above checking forJ > > conflicts needs to be performed on a per IO basis, or write only basis! > > with a local cache directory.  >tM > Nope.  You seem to be sufficiently interested in this that you would likelyrE > find understanding the VMS DLM to be a worthwhile use of your time.  >e  F I'm currently updating the HP-UX Kernel Support class, I guess the VMS< internals & data structure book will be required reading :-)   >j > >gK > > Sorry I don't know how VMS tackles these issues, it has been more yearsnI > > than I care to remember since I used a VMS cluster, and back then had C > > no idea how an OS worked. I'm sure VMS clusters have moved on aI > > long way since then anyway.f >pK > The basic design/operation of the VMS DLM was there in the first clusterst< > release in 1983/4.  Since then most improvements have been > performance-related. >e > >g > > >  > > >sL > > > In large systems, this means that  1) there's no need to partition the > dataI > > > among the various systems that 'serve' it (because all systems havec > directN > > > access to all data),  2) there's no problem after partitioning said dataL > > > with a server getting overloaded due to hot spots (because, again, all > dataL > > > is directly accessible to all who need it), and  3) the storage can beN > > > scaled independently of the processing capacity (and without the need to > > > repartition).t > > >  > >tL > > Not sure about 2), if they are sharing data unnessessarily then the data > canm
 > > hot spot.e >dN > Whether it's 'necessary' to share data is an application decision.  It's theH > OS's job to make that sharing as efficient as possible, and VMS does -H > including balancing access across multiple copies (when the VMS volumeK > shadowing approach is used) to minimize the impact of any such hot spots.  > E >  If local copies of the data were being maintained then it would be  > > quicker. >eM > VMS certainly allows you to do that as well when you choose to export localnM > disks to the cluster rather than use true shared storage:  it biases accessrJ > to the local copy unless the local disk is far more loaded than a remote > copy.t >lE >  This is of course dependant on whether you think you need to shareoK > > the data. My whole point was that some times you do, and some times youg
 > > don't. > >e > > >uM > > > And eliminating the need for 'server'-style operation does not increasen > therK > > > network traffic (thus does not increase access latency).  Obtaining a  > lockN > > > from whoever is in a position to grant it (which is usually known by theG > > > requestor - but I'm not going to reprise the VMS distributed lockt	 > managercH > > > algorithms here) takes one exchange, after which the requestor can > obtainK > > > the data from disk, which is the same number of operations that wouldp > occurrN > > > if instead the requestor asked a 'server' to obtain the data and forward > it.dN > > > (Actually, it can be less, because the VMS DLM algorithms make it likelyM > > > that most lock requests are local, hence the disk access can take place  > > > directly.) > > >  > > N > > If the data is not clean in the cache of the system that is "in a position > to
 > > grant it"tN > > then either the data needs to be exchanged across the network, or it needs > to > > beL > > written back to the disk, before the requestor can ask for the upto date > copy.iF > > A different app design where the data didn't need sharing could be
 > quicker. >hL > And would be quicker on VMS as well:  as described previously, if the dataN > doesn't need sharing, such overheads are avoided (and by definition no data,< > dirty or not, will be sitting in some other host's cache). >r > >s > >m > > >aN > > > With a good distributed cache (such as the one Oracle recently developed > foraH > > > its 'cache fusion' architecture) you can do even better due to the	 > abilitysM > > > to combine cache-management messages with lock-management messages (and) > onceN > > > you have such a distributed cache, shared storage becomes a definite win > > > over served storage).s > >aI > > I guess my main issue is how you get a good distributed cache withoutf > addingM > > significantly to the latency of a cache access. I'll need to looking intos > thef
 > > Oracle > > cache fusion architecture. >t > I think you'll appreciate it.e >eK > First, a distributed cache (rather than a server-local cache that clientspM > take advantage of) is *always* preferable as long as the (very low latency) L > benefit you obtain from being able to cache your own hot data locally (andI > access it without any distributed interactions) exceeds the overhead ofiK > having to coordinate access to data across the cluster (which only reallyrN > applies to data that at least someone is updating frequently and others needJ > frequently).  Note that even in many interchange-intensive applications,M > while a 'served' copy of the data *may* be somewhat more efficient than the>J > distributed cache approach, it may well be even better to centralize theJ > operation entirely (i.e., ship the access *functions* to a central pointJ > rather than keep bouncing the data back and forth between the server and > those who need it)., >hL > So even with the slow links of a decade ago distributed caching could make( > sense for many common access patterns. > J > Second, even when the data you need is not cached locally, it costs veryJ > little more to obtain it from some other node that *does* have it cachedM > than from a central server:  a 3-cornered message (requestor to coordinator F > to actual cacher, and response to requestor) rather than a 2-messageM > request/response.  This is I believe what Oracle now does and what XFC willhN > eventually do.  Since with optimized protocol stacks one-way message latencyJ > can be reduced to under 100 us. (and under 10 us. with hardware-enhancedM > mechanisms such as VI), and since sending even just a 4 KB 'block' across aeJ > 100 Mbit link takes about 400 us., the difference in that environment atL > worst nearly negligible (and with something like VI nearly negligible evenM > using a gigabit link, though in that case the additional interrupt requireds7 > in the 3-corned case may start to become noticeable).  >e > >i: > > >  VMS unfortunately dropped the ball on this for manyL > > > years, but is finally getting there with XFC (when they get it workingN > > > right).  Meanwhile, there is the legitimate knock that a node that wantsN > > > access to data that another node has cached must still go to disk for it > >lJ > > HP-UX used to use double caching here, but only where there was either% > > no sharing, or read only sharing.m > I > VMS allows double-caching as well, even for write-shared files (it just2N > invalidates any cached copies at other nodes when a write operation overlaps > them). >: > >l > > >nJ > > > (whereas if it was cached at a 'server' then no disk access would beN > > > required) - but this is an anomaly of the VMS implementation rather than > an4 > > > inherent problem with concurrent disk-sharing. > > >  > > > - bill > >tK > > There are other problems with disk sharing, such as sharing the IO rateP > ando > > connection bandwidth too.l >lI > If you need to get to the data on a disk, the I/O rate will be the sameEH > whether a bunch of hosts access it directly or the same bunch of hostsK > access it through a server (modulo the inefficiences introduced by served-M > access).  The only exceptions being isochronous access where the server canGM > decide whom to screw if the total rate exceeds the disk's capacity to serve  > it.- > K > Similar observations apply to sharing connection bandwidth:  the disk canCN > supply only as much bandwidth as whatever pipe it's connected to can manage,J > regardless, so while a switched back-end storage network used for sharedL > disks must be able to distribute that bandwidth to whatever combination ofK > hosts require it this doesn't differ much from the need for the front-enddH > network that served storage uses to distribute the load (again, unless" > isochronous access is at issue). >) > >u > > K > > Please don't think I am against all sharing and clustering, that is note > thel > > caseI > > as I have written in another posting, the origenal issue was that VMSo > > ClusteringN > > is not the only type of clustering, the term is horribly overloaded and it > is
 > > doubtfullsD > > that anyone solution will be right for all the uses of the term. >0K > And as I wrote elsewhere, VMS comes damn close to supporting all of them,e > and supporting them well.: >: > >lK > > It just like some application work best on a large SMP or ccNUMA servernM > > such as a SuperDome or GS (and I think these are very different from what N > > I can see) and some applications work best on a rack full of small systems > or$ > > blades. It's horses for courses. > >oN > > BTW, as I said it is many years since I last used a VMS cluster, back then > weH > > had our 11/785s linked by a series of cables a good couple of inches > thick,K > > for the CI bus. Since the clustering technology IS going to be added too > HP-UXiL > > I want to learn all I can about it, can you recommend any good places to > start, >sG > Greg Pfister's "In Search of Clusters" (2nd edition) has already beensE > mentioned, and is the best starting point I know of.  See above foriF > recommendations specific to VMS clusters.  The Oracle 'cache fusion'N > approach is similar to an IBM research project for the 'Calypso' file systemN > back in the mid-'90s (there used to be papers available on line, but findingL > them starting at ibm.com was a challenge - starting at almaden.ibm.com may
 > be better).e >s > >uN > > I know I have a lot to learn, in my own case it's going to need to be from > themK > > high level overview down to VMS distributed lock manager algorithms, ift > they; > > are going to show up in the HP-UX kernel in the future.m >i) > A pity HP isn't using the Tru64 kernel.s >C  / I guess it's natural to want what we know best.oF I hope that more co-operation happens than simply taking the Tru64 AFSJ and cluster stuff and bolting these onto the HP-UX kernel. Hopefully thereO will be a review of both kernels and the best parts will be choosen to live on.w  M I'm not in a position to comment on the Tru64 kernel, but there are some veryu good features in the HP-UX one.d   >m > - bill  > I guess it's time to go and find some of the reading material.     Cheers   Ken>   ------------------------------  % Date: Fri, 17 May 2002 12:32:16 +0100 & From: Ken Green <Ken.Green@kgcc.co.uk>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix* Message-ID: <3CE4EA40.491CFA26@kgcc.co.uk>   Bill Todd wrote:  5 > "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messagep& > news:3CE216FD.65DA2AB1@kgcc.co.uk... >d > ...n >aN > > For HP-UX  there has been at least three totally different non overlapping > > uses of the word cluster.r > >iN > > Diskless clusters (although that doesn't mean systems couldn't have disks)L > > This made a group of workstations act like a large single system, it wasG > > nothing like NFS diskless. All the systems had a single common rootl > directorytN > > and filesystem. 99.9% of admin was just the same as it would have been for  > > a single stand alone system.L > > I suspect if you asked most workstation or PC users what they would like2 > > a network to look like, it would be like this. > > " > > Computer clusters/snake farms.K > > A bunch of workstations (or any other box) with a distributed schedulert > >r > > HA clusters/ Service GuardG > > A group of systems that watch each others backs, and lend a helpingb) > > hand if one system gets into trouble.n > >V" > > These are all called clusters. >wK > I suspect that the point you are missing is that VMS clustering (from the4M > very beginning) completely covered the first and third kinds of 'different' M > clusters you describe above, and to at least some degree the second as wellhN > (though the distributed scheduler would have to have been an add-on).  SinceN > the second may be the easiest to create outside the base OS (see Beowulf), I) > don't consider that a significant lack.: >   J The third option can also be created with very little kernel intervention.G HP's service only has one Kernel service to make it work, a safety timeu to handle unhangs.   >  >r > - bill   Cheers   Ken    ------------------------------  # Date: Fri, 17 May 2002 11:41:36 GMT ) From: "Erikson Fsck" <erikson@nospam.com> < Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' UnixG Message-ID: <Q%5F8.33708$t8_.3864@news01.bloor.is.net.cable.rogers.com>t  3 "Peter da Silva" <peter@abbnm.com> wrote in messagew' news:aav4i0$ana@web.eng.baileynm.com...t: > In article <aaudu1$58b$1@fizban.fizban.pprd.abbott.com>,2 > Dave Gudewicz <david.gudewicz@abbott.com> wrote:H > > I guess I need some help.  Could someone please explain how LINUX is really
 > > NOT UNIX?  >yF > Linux *is* UNIX. It's an independent implementation of the same API,G > environment, security model, network interfaces and protocols, and sonL > on. "Linux is not UNIX" is as meaningless as "McDonalds is not hamburger",: > "a Schwinn isn't a bicycle", or "a Hyundai isn't a car".  L Hyundai isn't a car.  Its more of a four wheeled bike with a steering wheel.   > --K > I've seen things you people can't imagine. Chimneysweeps on fire over thee roofs L > of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. AlleF > these things will be lost in time, like chalk-paintings in the rain. `-_-'dF > Time for your nap.  | Peter da Silva | Har du kramat din varg, idag? 'U`n   ------------------------------  % Date: Fri, 17 May 2002 12:28:21 +0100mU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>n< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix0 Message-ID: <ac2pva$677$1@new-usenet.uk.sun.com>   Bill Todd wrote:  ; > "Paul Repacholi" <prep@prep.synonet.com> wrote in messagee, > news:87offgrprl.fsf@k9.prep.synonet.com... >  > ...i >  > 9 >>Although VMS clusters are described as a shared storagenE >>system, really they are a shared nothing system. They do not share, D >>they co-ordinate. So, all the drives on a HSC or HSJ on the CI are" >>*local* disks for ALL the hosts. >> > K > I'm afraid the description above is what most of the industry (IME) calls M > 'shared storage', since each host has direct physical access to the storagehF > (analogous to the shared memory in an SMP) and shares it essentiallyG > concurrently.  'Shared-nothing' usually refers to a system where eachhL > storage unit (and each unit of everything else, like memory) is private toL > some host and accessible only through that host (even though that host mayK > export it for shared use as VMS exports MSCP devices - which is sometimes   > called pseudo-shared storage). >     B It is, Oracle Parallel Server for example uses this mechanism with4 a DLM coordinating the access to the shared storage.  > Failover clusters do the same thing, with the failover manager* coordinating access to the shared storage.   Regardsg Andrew Harrisonr        ------------------------------  # Date: Fri, 17 May 2002 16:18:29 GMTa* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' UnixA Message-ID: <p3aF8.26089$e66.2294269@bin6.nnrp.aus1.giganews.com>   # "Andrew Harrison SUNUK Consultancy"h> <andrew_nospam.harrison_remove_this@sun#.com> wrote in message* news:ac2ldm$4sp$1@new-usenet.uk.sun.com...   ...   @ > The z900's do support 16 CPU's and 64 GB of RAM, quite how IBM@ > think you could virtualise 1000's of indevidual Linux sessions@ > on a system this memory limitted is a bit of a tricky question> > to answer but then this is after all a mainframe so anything > is possible :):):)  I Thanks.  I did note that the maximum *central* memory supported is 64 GB.hF This *might* mean that additional 'extended' memory (something I dimlyL recall from S/390 times past) was supported, but I didn't notice any mention of it in a quick look.  H But even 64 GB might be able to support several thousand sessions if  a)I each had relatively modest dynamic storage requirements and  b) there was > some ability to share a single common copy of code among them.   - bill   ------------------------------  # Date: Fri, 17 May 2002 16:09:35 GMTh* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' UnixA Message-ID: <3X9F8.54708$fU2.4916517@bin8.nnrp.aus1.giganews.com>n  # "Andrew Harrison SUNUK Consultancy"e> <andrew_nospam.harrison_remove_this@sun#.com> wrote in message* news:ac2pva$677$1@new-usenet.uk.sun.com... >  >h > Bill Todd wrote:   ...   G > > I'm afraid the description above is what most of the industry (IME)  callsSG > > 'shared storage', since each host has direct physical access to thea storagenH > > (analogous to the shared memory in an SMP) and shares it essentiallyI > > concurrently.  'Shared-nothing' usually refers to a system where each K > > storage unit (and each unit of everything else, like memory) is privaten toJ > > some host and accessible only through that host (even though that host mayeC > > export it for shared use as VMS exports MSCP devices - which isn	 sometimesf" > > called pseudo-shared storage). > >s >e >eD > It is, Oracle Parallel Server for example uses this mechanism with6 > a DLM coordinating the access to the shared storage. >r@ > Failover clusters do the same thing, with the failover manager, > coordinating access to the shared storage.  E No.  Truly shared storage allows concurrent access by multiple hosts.aF Fail-over-style shared storage serves the storage from one host to theK others:  while at least one more host is *connected* to the storage so thataI it can take over coordination for it if the current coordinator fails, itcL does not access the storage concurrently with the host currently responsible for it.m  I Intermediate environments to exist where there is a fail-over coordinatorrK for metadata but all the hosts can to at least some extent access user datasK on the storage directly and concurrently.  I believe that Tru64 V5.1 offerstJ such facilities, as well as several third-party products (well, IBM and HPH bought a couple of them so perhaps they're not exactly 'third-party' any more).   - bill   ------------------------------  # Date: Fri, 17 May 2002 16:31:27 GMTo* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix? Message-ID: <zfaF8.7399$yl.1098683@bin3.nnrp.aus1.giganews.com>   3 "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messaget$ news:3CE4E31B.B27CFEAB@kgcc.co.uk...E > Thanks for your replies Bill, sorry for not responding straight way G > but I wanted to think a little first (I realise this is not something + > that is normally incouraged on Usenet :-)e >a >, > Bill Todd wrote: >t7 > > "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messages( > > news:3CE22A9C.D4CC9952@kgcc.co.uk... > > > Bill Todd wrote:   ...e  " > >  Even if you can eliminate anyK > > > overhead in having the shred capability in place when it is not beinga used@ > > > you can still find it is being used when it is not needed. > >dK > > I suppose in some systems that could be true.  But it's not in VMS:  ons atC > > per-file basis, if on file open it is noted that no one else isr
 interestedI > > in the file, the opening host obtains complete control over it and nosF > > distributed activity is required thereafter unless some other host developsJ > > a concurrent interest in it (and if that host is found to be accessing itI > > more intensely than the original one, then the DLM moves coordinatings > > responsibility over there).  > >' >eE > The problem here I was alluding to was one we saw a number of timesiG > in DUX clusters. When any one system has the file open, then there is E > no problem. When multiple systems have the file open read only theneG > again there is no problem. But if the file was then opened read/write L > control needs to pass to one system, and the others then no longer locally > cache.  1 Perhaps in your implementation, but not in VMS's.c   ...t  K > > > I know I have a lot to learn, in my own case it's going to need to be) from > > the J > > > high level overview down to VMS distributed lock manager algorithms, if > > they= > > > are going to show up in the HP-UX kernel in the future.i > > + > > A pity HP isn't using the Tru64 kernel.t > >  > 1 > I guess it's natural to want what we know best.sH > I hope that more co-operation happens than simply taking the Tru64 AFSL > and cluster stuff and bolting these onto the HP-UX kernel. Hopefully thereH > will be a review of both kernels and the best parts will be choosen to live on. >uJ > I'm not in a position to comment on the Tru64 kernel, but there are some very! > good features in the HP-UX one.h  I I'm not really in a position to comment on the internal implementation oftB either.  But I do suspect that if you could come up with a list ofJ significant HP-UX kernel features not present in Tru64 (and perhaps not inJ other Unix variants) it might make a lot of the Tru64 people somewhat lessE inclined to consider taking their business elsewhere - and also mightcK encourage them to reciprocate to give you a better idea of what they see as < HP-UX's deficiencies w.r.t. Tru64 that need to be addressed.   - bill   ------------------------------  # Date: Fri, 17 May 2002 16:13:59 GMTs* From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' UnixA Message-ID: <b%9F8.54730$fU2.4918903@bin8.nnrp.aus1.giganews.com>s  3 "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messager$ news:3CE4EA40.491CFA26@kgcc.co.uk... > Bill Todd wrote: > 7 > > "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messageu( > > news:3CE216FD.65DA2AB1@kgcc.co.uk... > >w > > ...  > >XD > > > For HP-UX  there has been at least three totally different non overlappingt > > > uses of the word cluster.0 > > >aI > > > Diskless clusters (although that doesn't mean systems couldn't have  disks)J > > > This made a group of workstations act like a large single system, it waseI > > > nothing like NFS diskless. All the systems had a single common root 
 > > directorynL > > > and filesystem. 99.9% of admin was just the same as it would have been fort" > > > a single stand alone system.I > > > I suspect if you asked most workstation or PC users what they wouldd like4 > > > a network to look like, it would be like this. > > >r$ > > > Computer clusters/snake farms.C > > > A bunch of workstations (or any other box) with a distributedh	 scheduler  > > >e  > > > HA clusters/ Service GuardI > > > A group of systems that watch each others backs, and lend a helpingi+ > > > hand if one system gets into trouble.  > > >i$ > > > These are all called clusters.   ...d  L > The third option can also be created with very little kernel intervention.I > HP's service only has one Kernel service to make it work, a safety time  > to handle unhangs.  K Hmmm.  I find the moniker 'high-availability cluster' somewhat difficult torE justify for a system that leaves it to applications to handle storagenF redundancy (which your description above suggests it might).  Once theL system takes responsibility for storage redundancy, considerably more kernel support is required.   - bill   ------------------------------    Date: 17 May 2002 11:40:52 -0600+ From: young_r@encompasserve.org (Rob Young)c< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix3 Message-ID: <2lAGfpj1PZVk@eisner.encompasserve.org>t  n In article <p3aF8.26089$e66.2294269@bin6.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > % > "Andrew Harrison SUNUK Consultancy"'@ > <andrew_nospam.harrison_remove_this@sun#.com> wrote in message, > news:ac2ldm$4sp$1@new-usenet.uk.sun.com... >  > ...l > A >> The z900's do support 16 CPU's and 64 GB of RAM, quite how IBMeA >> think you could virtualise 1000's of indevidual Linux sessionsrA >> on a system this memory limitted is a bit of a tricky questiono? >> to answer but then this is after all a mainframe so anythinge >> is possible :):):)d > K > Thanks.  I did note that the maximum *central* memory supported is 64 GB.cH > This *might* mean that additional 'extended' memory (something I dimlyN > recall from S/390 times past) was supported, but I didn't notice any mention > of it in a quick look. >   A 	While individual boxes support 64 GBytes, DB2 on OS/390 Parallel 6 	Sysplex can do a 256 GByte buffer cache, see page 12:  @ http://www.databaseassociates.com/pdf/IBMos390%20Version%202.pdf   				Robe   ------------------------------  % Date: Fri, 17 May 2002 18:36:34 +0100p/ From: "Adam Price" <adam+usenet@pappnase.co.uk>:< Subject: Re: Capellas: Linux, Windows Will 'Eviscerate' Unix5 Message-ID: <ac3f33$lmcmu$1@ID-138239.news.dfncis.de>G  q "Bill Todd" <billtodd@metrocast.net> wrote in message news:b%9F8.54730$fU2.4918903@bin8.nnrp.aus1.giganews.com...s  M > Hmmm.  I find the moniker 'high-availability cluster' somewhat difficult todG > justify for a system that leaves it to applications to handle storageaH > redundancy (which your description above suggests it might).  Once theN > system takes responsibility for storage redundancy, considerably more kernel > support is required.  = Nah, storage redundancy should be done by the storage system. F Let the san manage it, just plug the nodes into the fibre switches and let it run.s
 Adam Price   ------------------------------  # Date: Fri, 17 May 2002 10:34:15 GMTa+ From: "Kenneth Farmer" <kfarmer@farmer.org>cA Subject: Re: Comments on ITUG/DECUS joint Euro conference in Lyont@ Message-ID: <H05F8.110670$gd5.36631843@typhoon.southeast.rr.com>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CE465D0.96ACB542@videotron.ca... > Robert Deininger wrote:)K > > Now folks like Scott Stallard and Ann Livermore and the people who worknG > > with them will form their own opinions of the merits of the variouso partsgK > > of Compaq they inherited.  It appears to me that both of them, and manyhJ > > others, will try to promote and grow anything that seems to be working5 > > well for HP.  Give them some time to sort it out.e >-L > They have had 8 months to sort it out. They published their famous productI > roadmap on week 1. It had whatever statements they wanted for VMS. Now,k theyL > want to revise that roadmap without telling anyone to hide the evidence of > their original gaffe.l  J As soon as I started reading the previous message I knew you were going toH say something about "8 months" again.  Do you know who was in the "cleanI room" during this process?  Having a list of who was invloved will give a2G better idea of what issues were covered.  Until you know who was in the:: clean room, stating they had 8 months is a bit misleading.  J I agree with Robert.  Give them some time to sort it out.  After attendingL the UNIX Symposium last week it became clear they are still working out someL details.  It wasn't until last week that the majority of HP/Compaq employeesI (management and engineers included) got to hear what decisions were made.h   [snip]   --   Kenneth Farmer http://www.Tru64.org http://www.OpenVMS.org http://www.LinuxHPTC.com   ------------------------------  % Date: Fri, 17 May 2002 10:09:08 -0500l1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>9A Subject: Re: Comments on ITUG/DECUS joint Euro conference in Lyong0 Message-ID: <ac36jr$ji$1@fizban.pprd.abbott.com>  G Thanks Ken.  May the force be with you.  And all of us.  What the heck.i   -- Dave...   ) Adam and Eve had many advantages, but the - principle one was that they escaped teething.e -----Mark Twaint  6 "Kenneth Farmer" <kfarmer@farmer.org> wrote in message: news:H05F8.110670$gd5.36631843@typhoon.southeast.rr.com...< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3CE465D0.96ACB542@videotron.ca... > > Robert Deininger wrote:uH > > > Now folks like Scott Stallard and Ann Livermore and the people who workI > > > with them will form their own opinions of the merits of the variousv > parts H > > > of Compaq they inherited.  It appears to me that both of them, and manyL > > > others, will try to promote and grow anything that seems to be working7 > > > well for HP.  Give them some time to sort it out.d > >aF > > They have had 8 months to sort it out. They published their famous productlK > > roadmap on week 1. It had whatever statements they wanted for VMS. Now,o > theyK > > want to revise that roadmap without telling anyone to hide the evidence- of > > their original gaffe.e >rL > As soon as I started reading the previous message I knew you were going toJ > say something about "8 months" again.  Do you know who was in the "cleanK > room" during this process?  Having a list of who was invloved will give aeI > better idea of what issues were covered.  Until you know who was in the < > clean room, stating they had 8 months is a bit misleading. >eL > I agree with Robert.  Give them some time to sort it out.  After attendingI > the UNIX Symposium last week it became clear they are still working outu someD > details.  It wasn't until last week that the majority of HP/Compaq	 employeestK > (management and engineers included) got to hear what decisions were made.  >a > [snip] >  > -- >a > Kenneth Farmer > http://www.Tru64.org > http://www.OpenVMS.org > http://www.LinuxHPTC.com >  >a >  >  >e   ------------------------------  % Date: Fri, 17 May 2002 12:41:27 -0400y- From: JF Mezei <jfmezei.spamnot@videotron.ca>oA Subject: Re: Comments on ITUG/DECUS joint Euro conference in Lyon , Message-ID: <3CE532B4.ED390385@videotron.ca>   Kenneth Farmer wrote:lI > better idea of what issues were covered.  Until you know who was in theS< > clean room, stating they had 8 months is a bit misleading. > ; > I agree with Robert.  Give them some time to sort it out.n  L I go by what Carly stated publicly many many times prior to the merger beingG signed. She repeatedly said that her integration team had gone over all J product lines and long ago hgad decided on the product line which would be; unveiled a few days after the transaction is made official.r  8 What they published on week 1 was their true intentions.  J Now, Stallard may have been told that his statements were too damaging andL that they needed to be toned down.  But util there is a clear statement FROMH CARLY that they are fine tuning the product roadmap, no amount of covertU changes to existing documents will convince me that the true intentions have changed.s  K Had Carly mentioned that it was only an initial roadmap that would get someaL fine tuning over the next few months, perhaps I would recieve Stallard coverL changes less negatively. But Carly was very authoritative and said that theyP had consulted partners and customers etc etc in designing that official roadmap.   ------------------------------  % Date: Fri, 17 May 2002 11:51:22 -0500 C From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>dA Subject: Re: Comments on ITUG/DECUS joint Euro conference in Lyon H Message-ID: <craig.berry-7F74BC.11512217052002@news.directvinternet.com>   In article  > <rdeininger-1605022026270001@1cust2.tnt1.nashua.nh.da.uu.net>,4  rdeininger@mindspring.com (Robert Deininger) wrote:   [lots of snippage]  & >VMS is NOT a big piece of the new HP.   [and more snippage]:  D I saw somewhere that HP-UX has 1.6 million installed systems, which E would make the size of the customer base about 4 times the oft-cited eF 400K VMS systems in use.  (I have no idea what the comparative profit E or revenue per system would be.)  This surprised me as I thought the eF difference would have been much greater.  In other words, VMS may not G be as tiny a part of the new HP as folks beaten down by years of abuse a& and neglect might tend to think it is.   ------------------------------  % Date: Fri, 17 May 2002 18:52:02 +0200s- From: Didier Morandi <Didier.Morandi@Free.fr>n Subject: DEC Alumni Associationh' Message-ID: <3CE53533.72E2DA45@Free.fr>a  * (ADSL up and running in Toulouse, Paul :-)  O I forgot to mention that the US DIGITAL Alumni Association had a booth in Lyon,aN mine. I had three visitors. Two of them, former DECcies, took the address, the= third one is already a member of the UK association, DEXODUS.   3 The US Alumni assoc is at http://www.decalumni.com/i  3 I will post my pictures as soon as my server is up.g   D. -- o2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  % Date: Fri, 17 May 2002 09:41:20 +0200 - From: Didier Morandi <Didier.Morandi@Free.fr> / Subject: DECUS Lyon: Another VMS summary (long)t' Message-ID: <3CE4B41F.3CCFC1D8@Free.fr>i  G I have no particular comments on John Smith's recent post, so I start ay new one.  B As said, Rich Marcello and Mark Gorham have been amazing (are they former DECcies?)  @ All questions asked to Mark were carefully listened to. He has aD particular way of freezing his head when he is listening to you, andG this is very pleasant. There are so many people who look here and theretG during you talk to them, Mark _does_ show that what you are saying _is_xG interesting. He also rephrases the questions so that the assistance canaF hear it when there is no microphone available (technical sessions) butH also to be sure that he got it well. Then he gives an answer or asks forF the inquirer's business card so that he will be able to send mail backH when he has the answer from the appropriate folks. I liked all this very much. Thank you Mark.b  G Rich was too very pleasant to meet and listen to because, first of all,oG he is a kind of funny person. Mark was perl-grey suit dressed, americanhC tie and all this. Rich was more Steve Jobs' looking. Black Lacoste,nG black trousers, black shoes, black eyes, well...  Man in black but withhF a large smile and lots of good news. He has often a "good word" to sayF and the assistance many times burst out laughing when listening to hisE answers during the HPq talks to the Customers closing session. But hecH also has something that I apperciated very much. When receiving a touchyG question (and there were) he did not "turn around the pot" as we say inlF French, or "sink the fish", which means to answer outside the scope ofB the question. This was particularly courageous as what he said wasF obviously official and became a kind of commitment from the new HP. AsH he is HP since less that one week, it should have been difficult for himD to say this or that without his new boss' approval (do you have one, Richard? :-)  H For example, I asked Mark the following question: "In case a non-HP UNIXH user would decide to move to VMS, will HPq help this customer to migrateG to VMS and how?" The answer (that I remember) was: "Of course, we will, H we wish to have more customers, and more customers happy. If they decideH to migrate from another UNIX to VMS, it means that they think that it isF the best choice for them, and we think that it is also the best choiceA for them to move to HP, so we will help them". But he did not say D whether there will be "tools" to help migrating from UNIX to VMS :-)1 (Any volunteers among ISV readers around here???)c  G Then I asked the following question to Rich: "Mark Gorham said this andeH that (my previous question). Will HP communicate on these big news?" TheH answer was first: "Mark Gorham, the one who works for me? I need to talkD to that guy". (laughs). Then he explained that HP does not intend toD "declare any war" against SUN (or others) and that, for this reason,H will prevent HP to aggressively communicate on migrating from other UNIXD OS to HP OpenVMS. But he stated that as soon as a potential Customer? would show their interest to migrate to VMS, HP will show theirrE professionalism and help this Customer to get the best from HP Global ? Services. This is to me something VERY important that should be H broadcasted. There is real will to help anyone moving from (non HP) UNIXG to VMS (which is to me the normal way, the other one is counter-nature,aE but I do not want to get out of my thread, I just do not like non-DEC = UNIX which "boringly" does less that 50% of what VMS does...)n  D I also asked: "About the French FreeVMS open source project, will HPE support, fight or just not care about it?" Unfortunately, I have beenpD disturbed during Rich's short answer, so I cannot reproduce it here. John Smith, please?   G As far as VMS on Itanium is concerned, from all the stuff what we heardoG (thanks to Hoff and Christian Moser) the assembly had a clear vision oftA HP's commitment to have VMS run on ia64 in a few years time (somelF underground rumors stated that "it" has _already booted_ in an obscure lab in ZK).'  A Cristian Moser gave an update to the "migrating applications fromeE VMS/Alpha to IA64" with an interesting slide showing conditional codeiE produced by compilers: ifdef alpha then a couple of lines, ifdef ia64pH then five pages of code :-) The most interesting information is that theH IA64-ready distribution kit will be the same for Alpha and Itanium. Just slide the CD in and boot.   H I asked Christian about no more MOP boot on Itanium. He said "you shouldB not care about the way your Itanium satellite will remote boot, itE will!" But he also stated that "yes, no PAL code means no more ^P and  console actions..." :-(l  F I will not summarize Hoff's presentations as you will find all of themG in a web site (which one, btw?), what I will say is first a souvenir: IxG attended my first DECUS Europe show in 1982 or so, when some folks fromnF VMS Engineering came to talk about their first experience of booting aH two nodes 780 cluster. The speaker said that after a few minutes, one ofE the systems crashed. They analyzed the crash and found some user mode1E data in the VMS code in memory... After a while, they discovered thateD the folk who programmed the paging and swapping stuff just forgot to@ record somewhere which of the two nodes did swap, so the swapperF actually swapped some pages back to the wrong system... :-) (does thisC gentleman recognize himself?). These sessions had overcrowded aula,oE people sit in the stairs, or standing up everywhere for lack of sits, H etc. Today, during these recent days in Lyon, we were an average of lessE that 50-60 persons during the VMS technical sessions. This is a pity.c# Sorry for that, Hoff and Christian.   H Something new about the future of the Alpha servers and VMS: There was aB question to Mark about the cancellation of the Alpha chip. He saidE (afaIr): "we did a survey a few years ago among our Alpha chip folks. B The question was: "to you, when will Intel produce a as good as orH better chip that ours?" The answer was: "in two or three years", this isH why we decided to stop the research and development of the Alpha chip toG start focusing on the VMS and Tru64 to Itanium port" (even if that nameo was not yet known).   F Then, there was a question about the future of Alpha servers according7 to the roadmap. Rich's answer has been _very_ precise: t  E "As long as there will be Customers asking for Alpha servers, we willa( continue to manufacture Alpha servers".   3 This sentence deserves to me a worldwide broadcast.   F Next question was about the future of VMS (whatever platform) and RichG gave the _same_ answer. So, if those-who-will-recognize-themselves-hereaG could stop complaining about "there are all liers", "you are all naive"g= and "VMS is dead, I tell you", that would be nice. Thank you.x  C There were no questions on TRU64 nor layered products nor compilers3C during the closing session. There were many on VMS, and some on NSKt (what is NSK? The Tandem OS?)   
 Conclusion
 ----------  H We VMS folks have a lot to do with current VMS users and the new ones to> come. What will we do to find them? (if HP does not want to be aggressive against SUN :-)   Cherry on the cake ------------------  \ There was a booth with some folks from this company: http://www.digitalindiasw.com/index.asp= Did someone around here know about their (current) existence?h   Regards,   D. -- r2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19, chemin de la Butte, 31400 Toulouse, France2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  % Date: Fri, 17 May 2002 04:47:28 -0400x- From: JF Mezei <jfmezei.spamnot@videotron.ca> 3 Subject: Re: DECUS Lyon: Another VMS summary (long)r, Message-ID: <3CE4C3A0.F8CC7A23@videotron.ca>   Didier Morandi wrote:,G > "As long as there will be Customers asking for Alpha servers, we will.) > continue to manufacture Alpha servers".   N This does not address the long term decline of VMS that is due to many factorsL and which requires active marketing to fix. If you wait for customers to begN for VMS at a time where the messages sent out by other parts of HP clearly sayQ that VMS isn't strategic, you will wait a very long time for those new customers.p  J Were there any questions about Stallard's stupid text about HP wanting VMS users to migrate to HP-UX ?y   ------------------------------  + Date: Fri, 17 May 2002 10:44:17 +0100 (MET)p9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>b3 Subject: Re: DECUS Lyon: Another VMS summary (long)l; Message-ID: <01KHTXOPFQJC96VU4K@sysdev.deutsche-boerse.com>P  & All in all a nice post; thanks Didier.  D > As said, Rich Marcello and Mark Gorham have been amazing (are they > former DECcies?)  G I think Gorham comes from Compaq, i.e. was there before DEC was bought.5  B > All questions asked to Mark were carefully listened to. He has aF > particular way of freezing his head when he is listening to you, andI > this is very pleasant. There are so many people who look here and there I > during you talk to them, Mark _does_ show that what you are saying _is_pI > interesting. He also rephrases the questions so that the assistance can H > hear it when there is no microphone available (technical sessions) butJ > also to be sure that he got it well. Then he gives an answer or asks forH > the inquirer's business card so that he will be able to send mail backJ > when he has the answer from the appropriate folks. I liked all this very > much. Thank you Mark.   G I experienced Mark at the DECUS Symposium in Bonn in April and had the iI chance to chat with him privately afterwards.  Yes, I agree; he seems to g be a good guy.  F > I also asked: "About the French FreeVMS open source project, will HPG > support, fight or just not care about it?" Unfortunately, I have been F > disturbed during Rich's short answer, so I cannot reproduce it here. > John Smith, please?w  C Let me say it again.  If you look at the web page and see how much  F remains to be done, it is absolutely impossible that this will become I anything close to a replacement for VMS at any time.  I think it reduces uH the credibility of folks here to point to this project at all, since it G then appears that the complexity of VMS has been VASTLY underestimated.s  F Thus, it is no threat to HP.  :-)  At the same time, if we want to be E taken seriously, we shouldn't even suggest that this project has any -G relevance at all to HP and VMS---not because of political reasons, but dG simply because it has no relevance and we thus become rather difficult oF to take seriously in other contexts.  (After all, why should we worry G about "the death of VMS" if a few guys can write a free replacement in i their spare time?)  J > I asked Christian about no more MOP boot on Itanium. He said "you shouldD > not care about the way your Itanium satellite will remote boot, itG > will!" But he also stated that "yes, no PAL code means no more ^P ando > console actions..." :-(   I Does this mean that booting will require DECnet?  Currently, one can use .C MOP instead of DECnet to boot satellites.  Yes, I know that DECnet  I (Phase IV as well) is being ported to Itanium.  Still, it is possible to  I run a cluster with no DECnet and it would be overkill to install it just i? to enable satellites to boot.  OK, perhaps there will be a new tG mechanism, but we need some way to boot VAX satellites from an Itanium   boot server.  :-)e   ------------------------------  % Date: Fri, 17 May 2002 11:27:26 +0200i- From: Didier Morandi <Didier.Morandi@Free.fr> 3 Subject: Re: DECUS Lyon: Another VMS summary (long)w' Message-ID: <3CE4CCFE.D68501EA@Free.fr>    JF Mezei wrote:   L > Were there any questions about Stallard's stupid text about HP wanting VMS > users to migrate to HP-UX ?g  ? Yes, there has been one. The answer was "It is better for theseuF customers to move to HP-UX rather than moving to another vendor" which is not so stupid an answer.f  	 (erratum)oG sentence "and we think that it is also the best choice for them to movenD to HP" should read "and we also think that it is the best choice for them to move to HP"g   D. -- b2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19, chemin de la Butte, 31400 Toulouse, France2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  % Date: Fri, 17 May 2002 11:31:09 +0200O- From: Didier Morandi <Didier.Morandi@Free.fr> 3 Subject: Re: DECUS Lyon: Another VMS summary (long) ' Message-ID: <3CE4CDDD.339F41D1@Free.fr>F   Phillip Helbig wrote:i ../... > J > Does this mean that booting will require DECnet?  Currently, one can use+ > MOP instead of DECnet to boot satellites.n  E Not at all. It means that Ethernet remote boot will be available, but E without MOP. With something else that is currently being implemented,m< but what's the heck, What we want is remote boot, itsn't it?   D.  E (Pleasant PS: DECnet IV-ia46 is _already_ up and running as the folkshG use it for their work, this is why in the roadmap, DECnet-Minus will be  implemented "later" :-)i   --  2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19, chemin de la Butte, 31400 Toulouse, France2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  + Date: Fri, 17 May 2002 11:47:43 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>c3 Subject: Re: DECUS Lyon: Another VMS summary (long)a; Message-ID: <01KHU08N2JRC96VU4K@sysdev.deutsche-boerse.com>g  L > > Does this mean that booting will require DECnet?  Currently, one can use- > > MOP instead of DECnet to boot satellites.v > G > Not at all. It means that Ethernet remote boot will be available, butcG > without MOP. With something else that is currently being implemented,-> > but what's the heck, What we want is remote boot, itsn't it?  9 OK, but will this new ethernet boot be available for VAX?:  E I believe the plans are to have at least one version of VMS for VAX, g ALPHA and Itanium.   ------------------------------    Date: 17 May 2002 04:58:02 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)r3 Subject: Re: DECUS Lyon: Another VMS summary (long) 3 Message-ID: <NjGCrb$V13$M@eisner.encompasserve.org>n  W In article <3CE4B41F.3CCFC1D8@Free.fr>, Didier Morandi <Didier.Morandi@Free.fr> writes:e  J > For example, I asked Mark the following question: "In case a non-HP UNIXJ > user would decide to move to VMS, will HPq help this customer to migrateI > to VMS and how?" The answer (that I remember) was: "Of course, we will,iJ > we wish to have more customers, and more customers happy. If they decideJ > to migrate from another UNIX to VMS, it means that they think that it isH > the best choice for them, and we think that it is also the best choiceC > for them to move to HP, so we will help them". But he did not sayiF > whether there will be "tools" to help migrating from UNIX to VMS :-)  D But readers of comp.os.vms all know there will be tools, as this hasD been discussed many times as an outgrowth of the DII-COE work.  WhenC someone consults HP for assistance, the technical person responding B should know what tools are available.  For that matter, if someoneC consults any reader of comp.os.vms for assistance, they should know C what tools are available.  (By "tools" in many cases, one means new-B features in the VMS operating system to more readily accept source code that is Unix-centric.)   H > Then, there was a question about the future of Alpha servers according9 > to the roadmap. Rich's answer has been _very_ precise: , > G > "As long as there will be Customers asking for Alpha servers, we will-* > continue to manufacture Alpha servers".  > 5 > This sentence deserves to me a worldwide broadcast.i  C Compaq said that in the initial announcement.  I don't see why theyDG should waste money on advertising to combat FUD from certain "analysts"mF and their allies in comp.os.vms.  What really counts is what customersF believe, and there would be no current VAX->Alpha conversions going on if everybody believed the FUD.   ------------------------------  % Date: Fri, 17 May 2002 11:58:41 +0200e) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>e3 Subject: Re: DECUS Lyon: Another VMS summary (long)g/ Message-ID: <3CE4D451.5090100@xs4all.nospam.nl>    Didier Morandi wrote:t > Phillip Helbig wrote:e > ../..s > J >>Does this mean that booting will require DECnet?  Currently, one can use+ >>MOP instead of DECnet to boot satellites.  >  > G > Not at all. It means that Ethernet remote boot will be available, but G > without MOP. With something else that is currently being implemented,p> > but what's the heck, What we want is remote boot, itsn't it? >  > D. > G > (Pleasant PS: DECnet IV-ia46 is _already_ up and running as the folksdI > use it for their work, this is why in the roadmap, DECnet-Minus will beh > implemented "later" :-)s >   F There was never a DECnet remote boot. That has always been MOP. It is H unlikely that a minimal DECnet stack could be done in console firmware. 7 Plus, it would need an address before it could be used.   D The new network boot will be bootp/tftp, without a shadow of doubt, " simply because they already exist.  	 Bart Zornt   ------------------------------    Date: 17 May 2002 05:00:02 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)"3 Subject: Re: DECUS Lyon: Another VMS summary (long)n3 Message-ID: <NXLZzOVtAXTD@eisner.encompasserve.org>w  w In article <01KHTXOPFQJC96VU4K@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:i( > All in all a nice post; thanks Didier. > E >> As said, Rich Marcello and Mark Gorham have been amazing (are theyv >> former DECcies?)  > I > I think Gorham comes from Compaq, i.e. was there before DEC was bought.n  E No, well before Compaq got involved Mark was at a US DECUS conferenceoF going around the Trade Show floor giving all the vendors copies of theE latest VMS Field Test version.  I certainly would have noticed if hisf= DECUS badge had not said "Digital Equipment Corporation" :-).t   ------------------------------  % Date: Fri, 17 May 2002 11:18:01 +0100l* From: "Richard Brodie" <R.Brodie@rl.ac.uk>3 Subject: Re: DECUS Lyon: Another VMS summary (long)h, Message-ID: <ac2lc9$10c6@newton.cc.rl.ac.uk>  ` "Bart Zorn" <B.Zorn@xs4all.nospam.nl> wrote in message news:3CE4D451.5090100@xs4all.nospam.nl...  E > The new network boot will be bootp/tftp, without a shadow of doubt,l$ > simply because they already exist.  I It's public knowledge that it will be based on Intel's PXE specification. = ftp://download.intel.com/labs/manage/wfm/download/pxespec.pdfn   ------------------------------  # Date: Fri, 17 May 2002 14:17:35 GMT,( From: "Mark E. Levy" <mlevy70@attbi.com>3 Subject: Re: DECUS Lyon: Another VMS summary (long)u, Message-ID: <3i8F8.24211$AU.34997@sccrnsc02>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KHU08N2JRC96VU4K@sysdev.deutsche-boerse.com... J > > > Does this mean that booting will require DECnet?  Currently, one can usea/ > > > MOP instead of DECnet to boot satellites.  > >(I > > Not at all. It means that Ethernet remote boot will be available, buteI > > without MOP. With something else that is currently being implemented,o@ > > but what's the heck, What we want is remote boot, itsn't it? >n; > OK, but will this new ethernet boot be available for VAX?c  E I would seriously doubt it. I can't fathom any way that it would makeaI economic sense for HP to expend engineering $$$ (best spent elsewhere) tor> retrofit discontinued hardware that's not been sold for years.  	 Mark Levyh SMAf   ------------------------------  % Date: Fri, 17 May 2002 10:06:38 -0500l1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>i3 Subject: Re: DECUS Lyon: Another VMS summary (long)a0 Message-ID: <ac36f6$j9$1@fizban.pprd.abbott.com>  6 I say we let the VAX sleep.  Its time.  Its past time.   -- Dave...o  ) Adam and Eve had many advantages, but thei- principle one was that they escaped teething.  -----Mark Twaina  : "Didier Morandi" <Didier.Morandi@Free.fr> wrote in message! news:3CE51A56.D6A95D9E@Free.fr...a > Phillip Helbig wrote:a > >s= > > OK, but will this new ethernet boot be available for VAX?d >hE > I do not know, but I do know that they said " we will support mixeduC > Alpha/Itanium clusters. As long as Vax/Alpha Clusters are working I > together pretty well, VMS Engineerig does not see why VAX/Alpha/ItaniumsG > should not work, but we do not commit to make it work". As far as VAX J > satellites are concerned, noone asked the question because the answer isF > obvious: you cannot remote boot a VAX from an Alpha system disk, can
 > you? :-) >rH > > I believe the plans are to have at least one version of VMS for VAX, > > ALPHA and Itanium. >wI > No. Remember that the VAX version is 32 bits. There will be the current B > supported version of OpenVMS for VAX (isn't it 5.5-2H4?) and theJ > Alpha/ia64 version (after 7.3), which will have the same binaries. If anG > intermediate version for Alpha only will be available, I do not know.s > But do we care?h >w > D. > --4 >   ------------------------------------------------4 > MORANDI Consultants  http://Didier.Morandi.Free.fr2 >   19, chemin de la Butte, 31400 Toulouse, France4 > Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19284 > OpenVMS, APPLE, Computer Security, Migration plans4 > --------------------------------------------------   ------------------------------  % Date: Fri, 17 May 2002 16:57:26 +0200 - From: Didier Morandi <Didier.Morandi@Free.fr> 3 Subject: Re: DECUS Lyon: Another VMS summary (long)s' Message-ID: <3CE51A56.D6A95D9E@Free.fr>e   Phillip Helbig wrote:a > ; > OK, but will this new ethernet boot be available for VAX?   C I do not know, but I do know that they said " we will support mixedeA Alpha/Itanium clusters. As long as Vax/Alpha Clusters are working G together pretty well, VMS Engineerig does not see why VAX/Alpha/Itanium E should not work, but we do not commit to make it work". As far as VAXnH satellites are concerned, noone asked the question because the answer isD obvious: you cannot remote boot a VAX from an Alpha system disk, can you? :-)  F > I believe the plans are to have at least one version of VMS for VAX, > ALPHA and Itanium.  G No. Remember that the VAX version is 32 bits. There will be the currenta@ supported version of OpenVMS for VAX (isn't it 5.5-2H4?) and theH Alpha/ia64 version (after 7.3), which will have the same binaries. If anE intermediate version for Alpha only will be available, I do not know.a But do we care?n   D. -- e2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19, chemin de la Butte, 31400 Toulouse, France2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------    Date: 17 May 2002 10:08:05 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)o3 Subject: Re: DECUS Lyon: Another VMS summary (long)i3 Message-ID: <q6o$7Ivxkeij@eisner.encompasserve.org>d  W In article <3CE51A56.D6A95D9E@Free.fr>, Didier Morandi <Didier.Morandi@Free.fr> writes:d > Phillip Helbig wrote:- >> -< >> OK, but will this new ethernet boot be available for VAX? > E > I do not know, but I do know that they said " we will support mixed C > Alpha/Itanium clusters. As long as Vax/Alpha Clusters are workingoI > together pretty well, VMS Engineerig does not see why VAX/Alpha/Itanium-G > should not work, but we do not commit to make it work". As far as VAX7J > satellites are concerned, noone asked the question because the answer isF > obvious: you cannot remote boot a VAX from an Alpha system disk, can
 > you? :-)  D No, but you can remote boot a VAX from a VAX system disk which is on	 an Alpha.r  G >> I believe the plans are to have at least one version of VMS for VAX,  >> ALPHA and Itanium.e > I > No. Remember that the VAX version is 32 bits. There will be the currentoB > supported version of OpenVMS for VAX (isn't it 5.5-2H4?) and the  5 The current latest supported version for VAX is V7.3.V  J > Alpha/ia64 version (after 7.3), which will have the same binaries. If an  5 No, Alpha and IA64 will _NOT_ have the same binaries.b6 They will have common source, and equivalent binaries.   ------------------------------  % Date: Fri, 17 May 2002 12:33:24 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>o3 Subject: Re: DECUS Lyon: Another VMS summary (long)a, Message-ID: <3CE530D2.A54ABC5F@videotron.ca>   Phillip Helbig wrote:PF > I believe the plans are to have at least one version of VMS for VAX, > ALPHA and Itanium.  K Has HP said *ANYTHING* about VAX ? I don't recall seeing anything about it..G For all we know, VAX-VMS has been declared mature with no new versions.e   ------------------------------  % Date: Fri, 17 May 2002 18:48:30 +0200n- From: Didier Morandi <Didier.Morandi@Free.fr>e3 Subject: Re: DECUS Lyon: Another VMS summary (long)r& Message-ID: <3CE5345F.DE9FF50@Free.fr>   Larry Kilgallen wrote: ../.._L > > Alpha/ia64 version (after 7.3), which will have the same binaries. If an > 7 > No, Alpha and IA64 will _NOT_ have the same binaries.l8 > They will have common source, and equivalent binaries.  + Ok, I misunderstood Christian Moser's talk.r
 Thank you.   D. -- t2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans2 --------------------------------------------------   ------------------------------  % Date: Fri, 17 May 2002 18:58:32 +0200p- From: Didier Morandi <Didier.Morandi@Free.fr>a3 Subject: Re: DECUS Lyon: Another VMS summary (long)n' Message-ID: <3CE536B9.728E0946@Free.fr>o   JF Mezei wrote:  > M > Has HP said *ANYTHING* about VAX ? I don't recall seeing anything about it.bI > For all we know, VAX-VMS has been declared mature with no new versions.t  = About VAX no, but Mark did say that HP still supports PDPs...r   D. -- f2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans1 Visit: http://www.softresint.com/AlphaMigrate.htmn2 --------------------------------------------------   ------------------------------  % Date: Fri, 17 May 2002 11:41:51 +0100uU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> 6 Subject: Re: Forced migration to HPHUX - Storm Warning0 Message-ID: <ac2n81$5cg$1@new-usenet.uk.sun.com>  ! Steve.Spires@yellgroup.com wrote:   K > Then why upgrade at all? Supposedly to move to GS320 boxes running VMS...t >     D The customer is expecting to have to increase their transaction rateB by a factor of 4. The current GS140's which are either 8 or 10 CPUD systems did not have the capacity to accomodate this, hence the plan7 proposed by Compaq to swap out the GS140's for GS320's.t  B Now even if you accept that a 32 CPU GS320 will be 4 x faster thanB a 10 CPU GS140 (something we all know to be questionable bordering@ on the highly unlikely) the requirment to be running 7.3 was not' helpfull as it turned out in this case.I   Regardso Andrew Harrison     	 > Steve S- >  >  >  > C > JF Mezei <jfmezei.spamnot@videotron.ca> on 05/15/2002 06:57:53 PMi > " > To:        Info-VAX@Mvb.Saic.Com > cc:AL > From:      JF Mezei <jfmezei.spamnot@videotron.ca>, 15 May 2002, 6:57 p.m. > / > Re: Forced migration to HPHUX - Storm Warningr >  >  > Bill Sticker wrote:g > G >>A decision to scrap all of their Alphas because of an upgrade failurea >> > showse > $ >>incompetency at the highest level. >> > L > It is possible that the customer already had plans to migrate off VMS, and2 > used probems with 7.3 to accelerate the process. >  >  >  >  > H > ______________________________________________________________________ >  >  > [Information] -- PostMaster:F > This transmission is intended solely for the addressee(s) and may beI > confidential. If you are not the named addressee, or if the message has I > been addressed to you in error, you must not read, disclose, reproduce,r& > distribute or use this transmission. > J > Delivery of this message to any person other than the named addressee isI > not intended in any way to waive confidentiality.  If you have receivedeM > this transmission in error please contact the sender or delete the message.C >  > Thank you. > F > Yell Limited, Queens Walk, Oxford Road, Reading, Berkshire, RG1 7PT.= > Registered in England and Wales, registered number 4205228.C > K > Yellow Pages Sales Limited, Queens Walk, Oxford Road, Reading, Berkshire,eF > RG1 7PT. Registered in England and Wales, registered number 1403041. >  >  >    ------------------------------  % Date: Fri, 17 May 2002 11:37:15 +0100 U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>r6 Subject: Re: Forced migration to HPHUX - Storm Warning0 Message-ID: <ac2mvd$57s$2@new-usenet.uk.sun.com>   Bob Ceculski wrote:-   > Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<ac0ekd$f3a$4@new-usenet.uk.sun.com>...  >  >>Dave Gudewicz wrote: >> >>O >>>Good catch Bill.  And *if* the XFC was their problem, then shame on them for-* >>>not turning it off like most here know. >>>r >>>  >>" >>XFC was not one of the problems. >>	 >>RegardsE >>Andrew Harrisonh >> >> > / > no, in this case it sounds like stupidity ...( >     3 If you had read the snagging list for 7.3 you woulde1 know that XFC isn't the only problem. You clearlyi1 havn't otherwise you could not have jumped to the 0 conclusion that the only other possibility after& XFC had been eliminated was stupidity.   Regardse Andrew Harrison   3 P.S Reading the snagging list before replying woulde have been a good idea.   ------------------------------  % Date: Fri, 17 May 2002 09:08:42 -0400e( From: Bill Gunshannon <bill@cs.uofs.edu>6 Subject: Re: Forced migration to HPHUX - Storm WarningB Message-ID: <20020517085833.Y14008-100000@server2.cs.scranton.edu>  + On Tue, 14 May 2002, Fred Kleinsorge wrote:@   > Your results sound atypical.  I Maybe, but I doubt it.  The reality is seldom the same as the perception,@( especially when there are strong biases.  L >                               It would be interesting to know exactly what > your VMS system does,r  H Oracle, Banner, whatever other applications a University might use to do	 business.i  < >                        and a post mortem on your downtime.  F Sorry, I'm pretty much the last person here they are likely to provide
 that info to.o  K >                                                            Of course, thee1 > same information for your UNIX systems as well.o  H The Unix servers run anything the Professors or students want or need. IF run an open shop.  If it is not obviously dangerous or damaging to theI system, I will put it on and let everyone run it.  And then there are allsI the programs the students write themselves in the course of the semester. F Some being really bad.  The worst thing I have had to deal with in theJ past few years has been students not freeing shared memory segements afterF their client/server assignments crash.  That was solved with educationE (and a threat of lost points on their assignments if they didn't stopyI doing it! :-)  Since the hole used by crashme.c was closed I have not hady, any student program actually crash a system.  J Oh yeah, and I use mostly OpenSource.  Main servers are all FreeBSD.  OnlyA one server is running Linux, and I hope to dump that this summer.    bill   -- iJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  % Date: Fri, 17 May 2002 08:50:49 -0400l( From: Bill Gunshannon <bill@cs.uofs.edu>6 Subject: Re: Forced migration to HPHUX - Storm WarningB Message-ID: <20020517084726.L14008-100000@server2.cs.scranton.edu>  + On Tue, 14 May 2002, Fred Kleinsorge wrote:   N > Two guys in suits, sitting in the hospital emergency entrance.  An ambulanceH > pulls up, and as the staff rushes the dying patient into the hospital, > everyone falls to the floor. >w > Guy one:  What just happened.  > Guy two:   It just crashed.t) > Guy one:  They all went down at once???,) > Guy two:   It happens.  But just watch.o >aG > Eight fat sweaty guys show up in blue tee shirts that say "Backup and - > Recovery".  The staff returns to it's feet.n >l > Guy one:  That's amazing.p: > Guy two:  Yeah, but the patient died while we were down. > 9 > Bet your business?  Bet your life?  Don't bet on Linux. , > VMS, when it really *is* mission critical. >f  E That's why I called for a reality check.  The last major un-scheduledmC period of downtime on the VMS system here was right at the time thehC professors needed to input final grades and the box stayed down fordI nearly a week.  If it had been some mission critical hospital applicationu@ the patient would have died with VMS just as much as with Linux.? No computer system is 100% reliable.  Systems much less complexrB than computers have been unable to attain 100% reliability, we are# a long way frm seeing it computers.r   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  # Date: Fri, 17 May 2002 13:32:33 GMTk# From: "John Smith" <a@nonymous.com> 6 Subject: Re: Forced migration to HPHUX - Storm WarningG Message-ID: <RD7F8.34763$t8_.5300@news01.bloor.is.net.cable.rogers.com>t  I Just because it isn't true hasn't stopped Sun, IBM, et al from seeming tooK promote unix and Linux as the all-encompassing panacea for all applicationst for all organizations.  F Okay, we'll have it your way....VMS kills fewer patients than unix perK 100,000 critical cases, with a margin of error of +/ 4%, 19 times out of 20r$ (to paraphrase the pollsters).  :-))    5 "Bill Gunshannon" <bill@cs.uofs.edu> wrote in messagee< news:20020517084726.L14008-100000@server2.cs.scranton.edu...- > On Tue, 14 May 2002, Fred Kleinsorge wrote:4 >1F > > Two guys in suits, sitting in the hospital emergency entrance.  An	 ambulanceaJ > > pulls up, and as the staff rushes the dying patient into the hospital,  > > everyone falls to the floor. > >P! > > Guy one:  What just happened.i > > Guy two:   It just crashed./+ > > Guy one:  They all went down at once???-+ > > Guy two:   It happens.  But just watch.m > >rI > > Eight fat sweaty guys show up in blue tee shirts that say "Backup andy/ > > Recovery".  The staff returns to it's feet.s > >  > > Guy one:  That's amazing.d< > > Guy two:  Yeah, but the patient died while we were down. > >y; > > Bet your business?  Bet your life?  Don't bet on Linux.n. > > VMS, when it really *is* mission critical. > >  >OG > That's why I called for a reality check.  The last major un-scheduledtE > period of downtime on the VMS system here was right at the time the E > professors needed to input final grades and the box stayed down foreK > nearly a week.  If it had been some mission critical hospital applicationtB > the patient would have died with VMS just as much as with Linux.A > No computer system is 100% reliable.  Systems much less complexeD > than computers have been unable to attain 100% reliability, we are% > a long way frm seeing it computers.r >  > bill >h > --L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h> >t   ------------------------------  + Date: Fri, 17 May 2002 16:07:33 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>e6 Subject: Re: Forced migration to HPHUX - Storm Warning; Message-ID: <01KHU936FAAO96VU4K@sysdev.deutsche-boerse.com>.  G > That's why I called for a reality check.  The last major un-scheduledbE > period of downtime on the VMS system here was right at the time theyE > professors needed to input final grades and the box stayed down forxK > nearly a week.  If it had been some mission critical hospital application B > the patient would have died with VMS just as much as with Linux.A > No computer system is 100% reliable.  Systems much less complex D > than computers have been unable to attain 100% reliability, we are% > a long way frm seeing it computers.c  I But with VMS, you can build a cluster, have some nodes at one site, have oA others a few kilometers away, enough machines at a third site to  C maintain cluster quorum in case one of the main sites is completelyoE destroyed, have all disks be shadow sets distributed across more than(E one site, upgrade the machines one at a time, slowly at first to makerD sure there are no problems, have external applications use a clusterC alias or use the load broker to distribute the load dynamically (in-C either case so that only one "virtual machine" exists as far as theh@ applications are concerned) and you are pretty well prepared forG anything---be it internal or external.  I doubt any other platform can i8 do this so easily, reliably, robustly and transparently.   ------------------------------  % Date: Fri, 17 May 2002 09:53:32 -04000( From: Bill Gunshannon <bill@cs.uofs.edu>6 Subject: Re: Forced migration to HPHUX - Storm WarningB Message-ID: <20020517094131.T14008-100000@server2.cs.scranton.edu>    On 14 May 2002, Rob Young wrote:   >eG > 	Maybe the scranton.edu VMS crashes/outages are directly attributabley/ > 	to human causes, neglect or misuse or abuse.s  J One should be sure of their facts before casting stones.  The head VMS guyL here is one that many would recognize by name.  He has had numerous articlesK published (back in the days when there actually were rags that printed tech G articles) and is at least as knowledgeable about VMS as I am with Unix. H This is a strictly administrative machine with no students to imisuse or	 abuse it.t? Unless your now admitting that maybe it isn't unhackable??  :-)r   > C > 	You being a skilled professional should point that out to seniorsF > 	management in a professional manner.  If you are highly valued, youD > 	should be compensated accordingly (please .... I'm not suggestingE > 	everyone in the world is being paid what they are worth but I alson9 > 	know that if you don't ask , you often won't receive).-  L My boss is aware of the disparity and does all he can to make things better.H But, the only thing that will make a significant difference in my salaryK would be finding a new job, an idea that has crossed my mind lately.  There-H are, however, some perks that still make up the difference to me anyway.J I have my own research lab and a bos who likes to buy me toys to play withI to keep my interest.  Plus providing me with the space and electricity tok run my PDP's and VAXen.  :-)   >n > >cR > > |>                                 Choose the operating system that "let's you. > > |> sleep nights and stay calm" - OpenVMS." > >wF > > Considering that most people who are running Unix on their systemsJ > > are perfectly happy and none of what you had above compares to realityK > > how do you think statements like that make you look to management typese > > making decisions?? > >u > % > 	Ummmm.. like a VMS traditionalist?   G I was thinking that to the un-initiated you end up looking like someonehF who is out of touch with the current realities of the industry. And weI have at least two people here, that I know of, that can verify that fact.      bill   -- sJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------    Date: 17 May 2002 09:40:05 -0600+ From: young_r@encompasserve.org (Rob Young)a6 Subject: Re: Forced migration to HPHUX - Storm Warning3 Message-ID: <UtC35xlFWcew@eisner.encompasserve.org>m  m In article <20020517094131.T14008-100000@server2.cs.scranton.edu>, Bill Gunshannon <bill@cs.uofs.edu> writes:r" > On 14 May 2002, Rob Young wrote: >  >>H >> 	Maybe the scranton.edu VMS crashes/outages are directly attributable0 >> 	to human causes, neglect or misuse or abuse. > L > One should be sure of their facts before casting stones.  The head VMS guyN > here is one that many would recognize by name.  He has had numerous articlesM > published (back in the days when there actually were rags that printed techbI > articles) and is at least as knowledgeable about VMS as I am with Unix.-J > This is a strictly administrative machine with no students to imisuse or > abuse it.eA > Unless your now admitting that maybe it isn't unhackable??  :-)  >   B 	Note there is a maybe in there.  Along these lines , as mentioned@ 	before , I have been involved in running 3 very stable clustersE 	in the last 5 or so years.  One , not so stable but as it turned outlD 	the problem was tracked down and it became stable.  In no manner do2 	I intend to disparge anyone, just an observation.  D 	But the cylce is to send crash dumps off to the appropriate people.E 	If it is 3rd party software crashing your box (and I have seen that)FE 	you may have to crank up the volume to get them to fix it and I haveP 	been involved in that.g  B 	If things "still" aren't better, you have to work your way up the@ 	food chain.  To have an unstable box more than a few months (itE 	may take that long, not suggesting it happens overnight) is uncalledS 	for.A  G 	If you then make it stable and turn around again and make it unstable,ME 	shame on you.  That is why it is important to track a few variables.eB 	Stable versions of application software and stable versions of OS 	they are riding on.   > A > Unless your now admitting that maybe it isn't unhackable??  :-). >   C 	Of course not.  It is unhackable and if socially engineered, maybe > 	you get lucky and the account that has been "hacked" into is E 	unprivved (like 99.97% of the accounts I am working with , i.e. less6  	than a dozen out of thousands).   >>D >> 	You being a skilled professional should point that out to seniorG >> 	management in a professional manner.  If you are highly valued, you-E >> 	should be compensated accordingly (please .... I'm not suggestingHF >> 	everyone in the world is being paid what they are worth but I also: >> 	know that if you don't ask , you often won't receive). > N > My boss is aware of the disparity and does all he can to make things better.J > But, the only thing that will make a significant difference in my salaryM > would be finding a new job, an idea that has crossed my mind lately.  ThereaJ > are, however, some perks that still make up the difference to me anyway.L > I have my own research lab and a bos who likes to buy me toys to play withK > to keep my interest.  Plus providing me with the space and electricity to  > run my PDP's and VAXen.  :-) >  >> >> >S >> > |>                                 Choose the operating system that "let's youh/ >> > |> sleep nights and stay calm" - OpenVMS."a >> >G >> > Considering that most people who are running Unix on their systems K >> > are perfectly happy and none of what you had above compares to reality3L >> > how do you think statements like that make you look to management types >> > making decisions??c >> > >>& >> 	Ummmm.. like a VMS traditionalist? > I > I was thinking that to the un-initiated you end up looking like someonenH > who is out of touch with the current realities of the industry. And weK > have at least two people here, that I know of, that can verify that fact.  >   = 	Maybe a quick exchange off line would clear up that fallacy.t   	Check your in box.    				Rob    >  > bill >  > -- _L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h> >    ------------------------------  + Date: Fri, 17 May 2002 16:56:34 +0000 (UTC) 5 From: "Bill Sticker" <NOSPAMPLEASE@SPAMSTOPPER.CO.UK> 6 Subject: Re: Forced migration to HPHUX - Storm Warning/ Message-ID: <ac3co2$6id$1@paris.btinternet.com>t  5 > If you had read the snagging list for 7.3 you wouldr3 > know that XFC isn't the only problem. You clearly 3 > havn't otherwise you could not have jumped to thef2 > conclusion that the only other possibility after( > XFC had been eliminated was stupidity. >2	 > Regards  > Andrew HarrisonL >t5 > P.S Reading the snagging list before replying wouldG > have been a good idea.  I Have it your way Andrew, If someone had read the snagging list before the-H upgrade AND UNDERSTOOD IT, the failures probably wouldn't have happened. QED.   ------------------------------  + Date: Fri, 17 May 2002 17:05:39 +0000 (UTC)i5 From: "Bill Sticker" <NOSPAMPLEASE@SPAMSTOPPER.CO.UK>76 Subject: Re: Forced migration to HPHUX - Storm Warning/ Message-ID: <ac3d93$oge$1@helle.btinternet.com>h   > Andrew Harrison wrote:  D > Now even if you accept that a 32 CPU GS320 will be 4 x faster thanD > a 10 CPU GS140 (something we all know to be questionable bordering > on the highly unlikely)    What a silly thing to accept!!!   L > the requirment to be running 7.3 was not helpfull as it turned out in this case.E  A How is the first part of the sentence related to the second part?t  L Have you told your client that they will not get the same performance from a1 Sun system, even if you could get 600 CPUs in it?n   ------------------------------  # Date: Fri, 17 May 2002 16:47:14 GMTo* From: "Bill Todd" <billtodd@metrocast.net>6 Subject: Re: Forced migration to HPHUX - Storm WarningA Message-ID: <muaF8.54963$fU2.4942504@bin8.nnrp.aus1.giganews.com>i  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KHU936FAAO96VU4K@sysdev.deutsche-boerse.com...cI > > That's why I called for a reality check.  The last major un-scheduled3G > > period of downtime on the VMS system here was right at the time theiG > > professors needed to input final grades and the box stayed down for.A > > nearly a week.  If it had been some mission critical hospitale applicationtD > > the patient would have died with VMS just as much as with Linux.C > > No computer system is 100% reliable.  Systems much less complexhF > > than computers have been unable to attain 100% reliability, we are' > > a long way frm seeing it computers.o >oJ > But with VMS, you can build a cluster, have some nodes at one site, haveB > others a few kilometers away, enough machines at a third site toE > maintain cluster quorum in case one of the main sites is completelyXG > destroyed, have all disks be shadow sets distributed across more thandG > one site, upgrade the machines one at a time, slowly at first to make F > sure there are no problems, have external applications use a clusterE > alias or use the load broker to distribute the load dynamically (inhE > either case so that only one "virtual machine" exists as far as theaB > applications are concerned) and you are pretty well prepared forH > anything---be it internal or external.  I doubt any other platform can: > do this so easily, reliably, robustly and transparently.  J Hmmm.  Several other fail-over cluster implementations can certainly do itK as reliably, robustly, and transparently.  It is debatable whether they canhG do it as easily, since one must at a minimum create cascading fail-over L scripts (or equivalents) to orchestrate resource inheritance and may requireH dual networks to provide both cluster communications and remote storage.  H And being 'prepared for anything' (to return to Bill G.'s point that youF responded to) really does include tolerating application (or, far lessL likely, hardware) screw-ups that corrupt the shared data - which VMS doesn't? handle any better or worse than anyone else (save in some casess% Tandem/Stratus-style approaches) can.o   - bill   ------------------------------  % Date: Fri, 17 May 2002 10:57:36 -0400n! From: Jim Agnew <jpagnew@vcu.edu>e Subject: Re: FTP queue ?' Message-ID: <3CE51A60.E881A892@vcu.edu>l  G i agree...  RSX was a nice thing, but I do get more work done with vms, H nt, linux, etc...  but I still look back on RSX as a fast, flexible, ...	 ah well..t  F progress, i guess. I used to drive a '53 Chevy, but I *do* like my '85> Ford F-150 that has a working defroster, heater, and automaticE transmission and air conditioning...  and it's PAID FOR.. so are many  RSX systems, i suppose ;-)   Jimn   Dirk Munk wrote: >  > Paul Repacholi wrote:p > Q > >winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes:  > >oM > >>But couldn't you just create an ordinary batch queue and submit jobs likef > >> > >w > >c2 > >>$! COMMAND PROCEDURE TO FTP FROM HITHER TO YON/ > >>$ COPY/FTP HITHER:[...]*.*;* YON.DOMAIN.TLDa > >> > >t > >m4 > >>and have all the queue manager goodies you want? > >> > >d
 > >::cought::r > >wD > >RSX, FTS. (File Transfer Spooler) Are we enjoying the 70s yet? :) > >n > I > My idea too !! There were more things in RSX that I would have liked to0  > have seen in VMS at that time. >  > >h   ------------------------------    Date: 17 May 2002 07:58:44 -0600- From: koehler@encompasserve.org (Bob Koehler) 8 Subject: Re: HP is like Q ... just doesn't get it proof!3 Message-ID: <bVFLbsumCsJN@eisner.encompasserve.org>   h In article <d7791aa1.0205161149.736f2b79@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:  $ > "Therefore, HP and IBM now are the< > only two companies with a complete portfolio of products."  '    Must bum out Scott McNealy somewhat.F   ------------------------------  % Date: Fri, 17 May 2002 13:03:18 +0400@4 From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> Subject: Re: ICC questione/ Message-ID: <3CE4C756.B35F369@SMTP.DeltaTel.RU>a   Hi All! + 	IS there someone who know something about:i ICC SIMPLE CLUSTERWIDE REGISTRYk > C >           Provides method to register association names under a,; >            single logical name, allowing multiple servers          "Ruslan R. Laishev" wrote: >  > Hello All! > \ >         I wrote test programs ("client" and "server") with ICC-interface, if I ommit (justL > passing zero) the remote_node parameter in the sys$icc_connect calls I gotW > "%SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node", according the docs Ip > may not use explicite node:y% > -----------------------------------r
 > remote_nodeh >  >      OpenVMS usage:: >                   char_stringw >      type:/ >                   character-coded text stringe >      access: >                   read onlyh >      mechanism: : >                   by 32-bit or 64-bit descriptor (Alpha) >      mechanism:.. >                   by 32-bit descriptor (VAX) > W >     The name of the node where the target association resides. A null or blank string  > can be used toP >     indicate the local node. If omitted (by passing zero by value), the simple > clusterwide associationsW >     registry is to be used. Each node name is a one-to-six character SCS node name. A  > comma-delimited T >     list of nodes may be specified, indicating that one is to be chosen at random.% > -----------------------------------a > > >         Is there what I'm need to check on a "server" side ? >         OVMS 7.2-1/Alpha.s >  >         TIA.   -- c Cheers,yF +OpenVMS [Sys|Net] HardWorker .......................................+E  Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222nE  191119,St.Petersburg,Transportny per. 3                     116-3222eF +http://starlet.deltatel.ru ................. SysMan rides HailStorm +   ------------------------------  # Date: Fri, 17 May 2002 10:16:25 GMT|? From: Jim.Johnson@software-exploration.nospam.com (Jim Johnson)> Subject: Re: ICC question-0 Message-ID: <3ce4d640.15810143@news.demon.co.uk>   Ruslan,r  F We've been doing some work here with the ICC services.  We've also not; been able to make things work without entering a node name.F  > In one case we use a set of locks to advertise the clusterwideC services.  We can look up a server using the resource name, get theeC lock's owning EPID, and from there the SCSNODE string to use.  ThiseF mechanism lets us place a pool of servers across a cluster and connect to any 'free' one successfully.c  E If you're interested in more details, send me mail offline.  Drop them .nospam. from the name.c   Jim.    7 On Fri, 17 May 2002 13:03:18 +0400, "Ruslan R. Laishev"c! <Laishev@SMTP.DeltaTel.RU> wrote:    >Hi All!, >	IS there someone who know something about:  >ICC SIMPLE CLUSTERWIDE REGISTRY >>  D >>           Provides method to register association names under a< >>            single logical name, allowing multiple servers >u >n >s >n >"Ruslan R. Laishev" wrote:t >>  
 >> Hello All!  >> i] >>         I wrote test programs ("client" and "server") with ICC-interface, if I ommit (just M >> passing zero) the remote_node parameter in the sys$icc_connect calls I gotsX >> "%SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node", according the docs I >> may not use explicite node:& >> ----------------------------------- >> remote_node >>   >>      OpenVMS usage:  >>                   char_string
 >>      type:a0 >>                   character-coded text string >>      access:r >>                   read only >>      mechanism:; >>                   by 32-bit or 64-bit descriptor (Alpha)l >>      mechanism:/ >>                   by 32-bit descriptor (VAX)X >> oX >>     The name of the node where the target association resides. A null or blank string >> can be used torQ >>     indicate the local node. If omitted (by passing zero by value), the simpley >> clusterwide associationX >>     registry is to be used. Each node name is a one-to-six character SCS node name. A >> comma-delimitedU >>     list of nodes may be specified, indicating that one is to be chosen at random.n& >> ----------------------------------- >> p? >>         Is there what I'm need to check on a "server" side ?S >>         OVMS 7.2-1/Alpha. >> i >>         TIA.v >a >--  >Cheers,G >+OpenVMS [Sys|Net] HardWorker .......................................+ F > Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222F > 191119,St.Petersburg,Transportny per. 3                     116-3222G >+http://starlet.deltatel.ru ................. SysMan rides HailStorm +e     Jim Johnsong Software Exploration, Ltd.) (remove '.nospam' from the reply address)I   ------------------------------  % Date: Fri, 17 May 2002 14:34:25 +0400s4 From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> Subject: Re: ICC questiono0 Message-ID: <3CE4DCB1.912A6916@SMTP.DeltaTel.RU>   Hi Jim,y   Jim Johnson wrote: > 	 > Ruslan,  > H > We've been doing some work here with the ICC services.  We've also not= > been able to make things work without entering a node name.b9 	it looks like a bug in ICC service or docs inconsistencyy    @ > In one case we use a set of locks to advertise the clusterwideE > services.  We can look up a server using the resource name, get the E > lock's owning EPID, and from there the SCSNODE string to use.  ThisnH > mechanism lets us place a pool of servers across a cluster and connect! > to any 'free' one successfully.r1 	Cool! :-) I have kept in my head the same way...m    5 	Thanks for the answeer Jim. hpDECpaq is sleeping :-(      > G > If you're interested in more details, send me mail offline.  Drop thel > .nospam. from the name.  >  > Jim. > 9 > On Fri, 17 May 2002 13:03:18 +0400, "Ruslan R. Laishev" # > <Laishev@SMTP.DeltaTel.RU> wrote:r > 
 > >Hi All!4 > >       IS there someone who know something about:" > >ICC SIMPLE CLUSTERWIDE REGISTRY > >>F > >>           Provides method to register association names under a> > >>            single logical name, allowing multiple servers > >  > >s > >d > >. > >"Ruslan R. Laishev" wrote:c > >> > >> Hello All!| > >>_ > >>         I wrote test programs ("client" and "server") with ICC-interface, if I ommit (just6O > >> passing zero) the remote_node parameter in the sys$icc_connect calls I gotoZ > >> "%SYSTEM-F-NOSUCHOBJ, network object is unknown at remote node", according the docs I  > >> may not use explicite node:( > >> ----------------------------------- > >> remote_node > >> > >>      OpenVMS usage:" > >>                   char_string > >>      type:h2 > >>                   character-coded text string > >>      access:i  > >>                   read only > >>      mechanism:= > >>                   by 32-bit or 64-bit descriptor (Alpha)n > >>      mechanism:1 > >>                   by 32-bit descriptor (VAX)c > >>Z > >>     The name of the node where the target association resides. A null or blank string > >> can be used toaS > >>     indicate the local node. If omitted (by passing zero by value), the simplem > >> clusterwide associationZ > >>     registry is to be used. Each node name is a one-to-six character SCS node name. A > >> comma-delimitedW > >>     list of nodes may be specified, indicating that one is to be chosen at random.i( > >> ----------------------------------- > >>A > >>         Is there what I'm need to check on a "server" side ?t > >>         OVMS 7.2-1/Alpha. > >> > >>         TIA.t > >b > >--o
 > >Cheers,I > >+OpenVMS [Sys|Net] HardWorker .......................................+rH > > Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222H > > 191119,St.Petersburg,Transportny per. 3                     116-3222I > >+http://starlet.deltatel.ru ................. SysMan rides HailStorm +t > 
 > Jim Johnsono > Software Exploration, Ltd.+ > (remove '.nospam' from the reply address)s   -- n Cheers,eF +OpenVMS [Sys|Net] HardWorker .......................................+E  Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222iE  191119,St.Petersburg,Transportny per. 3                     116-3222 F +http://starlet.deltatel.ru ................. SysMan rides HailStorm +   ------------------------------  % Date: Fri, 17 May 2002 14:28:52 +0200eE From: Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de>c Subject: Re: ICC question + Message-ID: <3CE4F784.3B12EAA6@mediasec.de>7  @ > In one case we use a set of locks to advertise the clusterwideE > services.  We can look up a server using the resource name, get the E > lock's owning EPID, and from there the SCSNODE string to use.  ThiseH > mechanism lets us place a pool of servers across a cluster and connect! > to any 'free' one successfully.   F You could also use a lock value block for this purpose, or a door-bell lock.t   	Jan   ------------------------------  # Date: Fri, 17 May 2002 15:12:16 GMTs? From: Jim.Johnson@software-exploration.nospam.com (Jim Johnson)l Subject: Re: ICC questione0 Message-ID: <3ce51c6d.33775546@news.demon.co.uk>  A Yes, the SCSNODE name could be in the VALBLK for the lock.  In mypE case, I was already walking the list of locks using $GETLKI because ae@ simple doorbell wouldn't work (I need to support multiple activeE servers and doorbells are really best geared towards chosing a single F active system per resource).  Given that I could already get the EPID,5 picking up the nodename locally was, well, trivial...o   Fwiw,| Jim.  * On Fri, 17 May 2002 14:28:52 +0200, Jan C.? =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> wrote:t  A >> In one case we use a set of locks to advertise the clusterwidesF >> services.  We can look up a server using the resource name, get theF >> lock's owning EPID, and from there the SCSNODE string to use.  ThisI >> mechanism lets us place a pool of servers across a cluster and connectn" >> to any 'free' one successfully. >tG >You could also use a lock value block for this purpose, or a door-belle >lock. >p >	Jan,   Jim Johnson, Software Exploration, Ltd.) (remove '.nospam' from the reply address)u   ------------------------------  % Date: Fri, 17 May 2002 11:22:51 +0200l- From: "Dariusz Dudek" <ddudek@elka.pw.edu.pl>m
 Subject: IFDLk& Message-ID: <ac2i1t$p6l$1@news.tpi.pl>  
 I looking for ( DECForms IFDL Reference Manual ver. 3.2.- How can I get it, or if you have it, send me.y   Regards,  
 Dariusz Dudeks   ------------------------------  # Date: Fri, 17 May 2002 09:34:06 GMTa From: system@SendSpamHere.ORGr# Subject: Re: ISE just spammed me...S0 Message-ID: <00A0E0EC.E0F59C29@SendSpamHere.ORG>  c In article <FB2mT5m4+IJ7@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:gy >In article <5LjU9KSbUiwM@eisner.encompasserve.org>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:dN >> Has anyone else just got spammed by ISE offering some kind of VMS product ? >a< >> They have just made sure that I don't ever buy from them. > ! >What are the ISE product names ?p >n >-- O >==============================================================================sJ >The Boulder Pledge: "Under no circumstances will I ever purchase anythingK >     offered to me as the result of an unsolicited email message. Nor will1J >     I forward chain letters, petitions, mass mailings, or virus warningsI >     to large numbers of others. This is my contribution to the survivalg >     of the online community."nO >==============================================================================3  : http://www.i-s-e.com/Platforms/OpenVMS_Software/index.html   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?" i   ------------------------------    Date: 17 May 2002 07:15:11 -0600B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)# Subject: Re: ISE just spammed me...m3 Message-ID: <1Prp+w4Pjsgk@eisner.encompasserve.org>n  c In article <FB2mT5m4+IJ7@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:@z > In article <5LjU9KSbUiwM@eisner.encompasserve.org>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:N >> Has anyone else just got spammed by ISE offering some kind of VMS product ? > < >> They have just made sure that I don't ever buy from them. > " > What are the ISE product names ? >    Main products:$ 	EnterpriseSCHEDULE, a job scheduler. 	EnterpriseBACKUP, a centralised backup system  = Secondary products include LANutil, QControl and DeviceShare.d   Simon.   -- rB Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       + Microsoft: The Lada of the computing world.S   ------------------------------    Date: 17 May 2002 07:53:10 -0600- From: koehler@encompasserve.org (Bob Koehler)s# Subject: Re: ISE just spammed me...a3 Message-ID: <$VY3abiPT5CA@eisner.encompasserve.org>s  a In article <ac1ega127nf@enews2.newsguy.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:lE > Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:oN >> Has anyone else just got spammed by ISE offering some kind of VMS product ? > J > I get spammed by them on roughly a monthly basis.  I have been for ages.G > It's a bit irritating, especially since it basically comes through aseJ > garbage on my Mac.  They're obviously using something like MS Lookout to
 > sent it.  C    It comes through as garbage on my PC, too.  It use to come to myiH    Alpha and I just had Mulinet toss it.  Unfortunatley a network rework6    here has left us with no direct SMTP to my servers.   ------------------------------  % Date: Fri, 17 May 2002 08:13:54 -0500 1 From: "Dave Gudewicz" <david.gudewicz@abbott.com>uY Subject: Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX -  Storm Warnid1 Message-ID: <ac2vrp$spk$1@fizban.pprd.abbott.com>o  L Once again, write Mr. Stallard and ask him the question mentioned below.  It" will not get answered by him here.  D     first.last@hp.com     <----  I know this works in his case, I've actually used it.    -- Dave...   ) Adam and Eve had many advantages, but theh- principle one was that they escaped teething.a -----Mark Twain(  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CE4C491.305C657B@videotron.ca... > "Bradford J. Hamilton" wrote: D > > I've asked my manager to see if Scott Stallard is attending that meeting, andL > > if Scott is there, then my manager will ask him for clarification of his remarkswF > > on OVMS, and to impress upon Mr. Stallard the importance that OVMS	 customers & > > place upon HP's continued support. >t  > I would ask that Stallard guy: >,B > -what was your intention in saying that HP expected VMS users to
 eventually > migrate to HP-UX ? >o > depending on answer: >dL > -in deciding the fate of a multi-billion dollar product, how come you wereJ > unaware that such a statement would trigger extremely negative reactions fromE > customers, considering you had 8 months to prepare such statement ?o   ------------------------------  # Date: Wed, 15 May 2002 21:17:12 GMTm3 From: sy18889@rabbit.fmr.com (Bradford J. Hamilton)rV Subject: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm Warning. Message-ID: <sfAE8.1$xB2.85@news-srv1.fmr.com>  M Here's an alternative - for those of you whose managers will be attending them> OVMS Executive Council meeting in Palm Beach later this month:  M I've asked my manager to see if Scott Stallard is attending that meeting, andiP if Scott is there, then my manager will ask him for clarification of his remarksL on OVMS, and to impress upon Mr. Stallard the importance that OVMS customers" place upon HP's continued support.  O I suspect that high-level contacts such as this, as well as grass-roots effortsiE by people like Dave may begin to make an impression on HP management,tP especially as they look for new ways to increase their revenue (did folks noticeP the hit that HP stock took today? - Wall Street was not impressed by the revenueI decline).  If folks from here wish to "tailor" their message, step on theh "revenue" pedal.  -e In article <abudbo$3po$1@fizban.pprd.abbott.com>, "Dave Gudewicz" <david.gudewicz@abbott.com> writes:tK >OK all those that have written to Mr. Stallard this past week about thingsa8 >VMS related, please signify by entering ^VMS in a post. >oF >Those that have received a reply from Mr. Stallard, please signify by >entering ^VMS^. >t >Here's mine:   ^VMS^  > L >All those that cannot truly enter the above symbols ----- give it a try and >see what happens. > H >If not interested in doing this or you think it won't do any good, then* >please suggest constructive alternatives. >h >--o >Dave... >e* >Adam and Eve had many advantages, but the. >principle one was that they escaped teething. >-----Mark Twain >i; >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message-' >news:3CE2A7D3.B3B11EF2@videotron.ca...  >> David Harrold wrote::L >> > So, they listing to you (and others) and change the message to one that >ise& >> > better.  Now they're unethical??? >>L >> The didn't change the message. That is the problem. They just removed/hid >aI >> portion that was highly offensive to VMS customers, and did so withoutt >> explanation or notice.e >>K >> I see absolutely no indication whatsoever that they policy to expect VMS K >> customers to migrate to HP-UX has changed in any way. Only that now theyu >noh. >> longer want to admit to it in the document. >>H >> If the policy has changed, then let HP state categorically that afterL >> listening to customers, they have re-evaluated the positioning of VMS and >will L >> no longer expect customers to migrate to HP-UX and see a bright long termI >> future for VMS, including long term development commitment on whateverp- >> hardware platform is current at that time.e >>J >> If Stallard was able to device that policy in a vaccumm without getting >fulloI >> approval, then he should be fired on the spot. How would you handle anrI >> employee whose memo will cost your company millions of dollars in lost 
 >profits ? >>M >> And if Stallard remains at HP, without any statement from HP to the effectaK >> that Stallard's original memo did not represent HP policy, then it meansJ >that># >> HP supports the original policy.- >  >e Bradford J. Hamilton& braMdhamAilPtoSn@aMtAtPbi.cSom		(home)& sMy1A88P89S@rabMbit.fAmPr.coSm		(work)  ; "All opinions that I express are my own, not my employer's"g "Lose the MAPS"    ------------------------------    Date: 17 May 2002 06:32:34 -0700- From: jodonnell@hrblock.com (Jason O'Donnell) Y Subject: Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm Warninn= Message-ID: <9059bf6b.0205170532.3a1da1a9@posting.google.com>t  i sy18889@rabbit.fmr.com (Bradford J. Hamilton) wrote in message news:<sfAE8.1$xB2.85@news-srv1.fmr.com>... O > Here's an alternative - for those of you whose managers will be attending the @ > OVMS Executive Council meeting in Palm Beach later this month:  D Having my nose to the keyboard, what is this coucil meeting?  Who is3 invited?  Who from the NEW HP is going to be there?a   ------------------------------  # Date: Fri, 17 May 2002 13:57:27 GMTt3 From: sy18889@rabbit.fmr.com (Bradford J. Hamilton)oY Subject: Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm Warninw. Message-ID: <b%7F8.2$xB2.45@news-srv1.fmr.com>  N Typically, "large" VMS customers, by invitation from COMPAQ (the new HP).  TheH council provides access to high-level COMPAQ (part of the new HP) execs.  L Don't know who will be there; I just asked my manager to keep an eye out forP Mr. Stallard, if he attends.  Typically, execs at the Gorham/Marcello level have attended in the past.   O I understand that Mr. Stallard did not attend the recent symposium in Lyon, buty sent a video message.>  m In article <9059bf6b.0205170532.3a1da1a9@posting.google.com>, jodonnell@hrblock.com (Jason O'Donnell) writes:sj >sy18889@rabbit.fmr.com (Bradford J. Hamilton) wrote in message news:<sfAE8.1$xB2.85@news-srv1.fmr.com>...P >> Here's an alternative - for those of you whose managers will be attending theA >> OVMS Executive Council meeting in Palm Beach later this month:r >sE >Having my nose to the keyboard, what is this coucil meeting?  Who is 4 >invited?  Who from the NEW HP is going to be there?   Bradford J. Hamilton& braMdhamAilPtoSn@aMtAtPbi.cSom		(home)& sMy1A88P89S@rabMbit.fAmPr.coSm		(work)  ; "All opinions that I express are my own, not my employer's"> "Lose the MAPS"-   ------------------------------  % Date: Fri, 17 May 2002 04:51:30 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>.Y Subject: Re: Message to Scott Stallard (Was: Re: Forced migration to HPHUX - Storm Warnine, Message-ID: <3CE4C491.305C657B@videotron.ca>   "Bradford J. Hamilton" wrote:eO > I've asked my manager to see if Scott Stallard is attending that meeting, andoR > if Scott is there, then my manager will ask him for clarification of his remarksN > on OVMS, and to impress upon Mr. Stallard the importance that OVMS customers$ > place upon HP's continued support.   I would ask that Stallard guy:  K -what was your intention in saying that HP expected VMS users to eventually  migrate to HP-UX ?   depending on answer:  J -in deciding the fate of a multi-billion dollar product, how come you wereM unaware that such a statement would trigger extremely negative reactions from C customers, considering you had 8 months to prepare such statement ?    ------------------------------  + Date: Fri, 17 May 2002 10:00:22 +0100 (MET)o9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>n Subject: Re: No new Alpha salesl; Message-ID: <01KHTWG2DOUA984WQP@sysdev.deutsche-boerse.com>   ? > Wrong.  They say, clearly, that they will push *all* new RISC 0                                             ^^^^N > I suspect you're right:  if you go to HP, ask them to sell you a VMS system,H > and make it clear that you'll go to another vendor if they won't, then+ > you'll probably be able to buy one.  BFD.L  J > Or perhaps you just want to split hairs:  I agreed above that a customerF > probably can get HP to sell them VMS if they're persistent enough.    C So we agree.  I was disagreeing with the statement that there will >- CATEGORICALLY be ABSOLUTELY NO new VMS sales.p  J > The problem the people you're disagreeing with have is that this will beJ > the *only* way VMS gets sold (save possibly to the existing base, thoughH > I wouldn't bet that they won't be 'encouraged' to 'migrate' as well).   G In the last, say, 5--10 years, how many VMS sales came from the vendor ,G pushing VMS and how many from the customer saying that that is what he y wants?   ------------------------------  + Date: Fri, 17 May 2002 10:05:23 +0100 (MET)>9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>i Subject: Re: No new Alpha sales ; Message-ID: <01KHTWKYEQNC984WQP@sysdev.deutsche-boerse.com>   F Thanks for setting the record straight, Fred.  I'll make an exception C from my usual rule and quote your entire post since it needs to be >	 repeated.   D ---------------8<---------------------------------------------------   Bill Todd wrote in message ... >  >u   snip   >>- >> Let's face it.  The wording was confusing.h >oH >You're the only one who seems confused:  perhaps you just don't want to >understand it.  >>  K No Bill, he's not.  I'd suspect you were confused, but I know you are not -n for you it is intentional.  H The messages you are trying to spin, are really focused on Tru64, not onG OpenVMS.  For Tru64, it is clear that we would prefer to move customers K as-soon-as-possible to HP-UX instead delaying their migration.  Where Alpha.I or Tru64 features are a requirement for Tru64 customers - then we will by K all means sell it to them.  But where the price/performance and applicationlL availability meet the customer needs on PA RISC or IA64 and HP-UX -- that isL our clear preference.  That would seem to make sense, and be consistant with" the long term plan for UNIX in HP.  D If a customer walks in the door, and provides no preference, and theG applications are available on HP-UX -- then that is what they will most|I likely be steered towards.  Which doesn't offend me, or seem confusing...e HP-UX is what, the #2 UNIX?e  L If a customer walks in the door, and wants VMS, we'll sell them VMS.  If theL application set only runs on VMS, we'll sell them that.  I eventually expectI that once VMS has integrated into HP, and is available on IA64, sales may5F even suggest VMS where and when the situation suggests it is the rightA solution - even when the customer isn't an existing VMS customer.6  I In the mean time, we still maintain our VMS ambassadors in the field, whorK continue to sell VMS into new and old accounts.  This is where a lot of our C "new" business comes from today.  They will continue to sell VMS one7 everything we sell it on.  Alpha today, IA64 tommorrow.u  J There are no orders or policy here to actively *not* sell VMS.  The ordersI are to sell everything we have, and as much of it as we can.  Letting the-H customer decide what is right for them, and with guidelines for when theK customer has no preference (all 3 of them that don't have a general idea oft! what we have and what they want).6  F You'll have to excuse a few people with extensive HP-UX background andH enthusiasm, for not being sensitive to the VMS customer base.  I believeI that the cards and letters they are getting are bringing them up to speediD very quickly.  The change to the Q&A is just one indication of that.   > I >Or perhaps you just want to split hairs:  I agreed above that a customerkH >probably can get HP to sell them VMS if they're persistent enough.  TheI >problem the people you're disagreeing with have is that this will be thebG >*only* way VMS gets sold (save possibly to the existing base, though IdD >wouldn't bet that they won't be 'encouraged' to 'migrate' as well). >   L Let me repeat.  VMS has maintained it's own small army of specialists in theH field - the Ambassadors - who we use to find and sell VMS solutions.  InK fact, they are here in NH next week for their 6 month briefing/training and K feedback to VMS engineering.  Its not likely that a new customer walking iniH the Compaq sales office 18 months ago - expressing no preference - wouldF have been "steered" to VMS - unless an Ambassador had worked with, and> helped them to understand when to recognize a VMS opportunity.   ------------------------------  + Date: Fri, 17 May 2002 10:13:24 +0100 (MET)I9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>  Subject: Re: No new Alpha sales ; Message-ID: <01KHTWTXT12M984WQP@sysdev.deutsche-boerse.com>,  I > Did the "and high performance technical computing" secretly added laterjE > on ? I don't recall reading this when the documents were unveiled.    D Where's the problem?  It's better than not changing it at all.  The H people who care will notice it (after all, the consensus in this thread E seems to be that people make purchasing decisions based on carefully rG reading these documents) and for the mainstream it's more trouble than V% it's worth to trumpet out the change.e  B > How many more changes can we expect to see on what has become anC > untrustable/volatile document before we get to know what the real=( > intentions/policies are going to be ?   G EITHER whatever happened to be the current state of the documents when eI the merger was finalised is cast in stone, OR HP responds to criticism.    I prefer the latter option.o  I People here have been complaining for a long time that the vendor of VMS iI doesn't listen.  Now that they do, it is UNETHICAL to criticise them for = changing the white papers.  G > And more importantly, will HP admit publicly that it is refining in afI > week or two a document it spent more than 8 months preparing because itu> > has realised how poorly it has been received by customers ?   H Why?  "Customers" is a very, very small fraction of the total number of I customers.  Most HP customers don't know what VMS is.  And I'm sure that rG all people who don't just contribute to the newsgroup but actually buy mH VMS hardware don't base their purchasing decisions on what's in today's  version of a web page.   ------------------------------  + Date: Fri, 17 May 2002 10:30:14 +0100 (MET)K9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>d Subject: Re: No new Alpha sales); Message-ID: <01KHTXASOKBM96VU4K@sysdev.deutsche-boerse.com>    Bill wrote:S  K > No, they are not.  They appear (still do - just checked again now) in the . > 'hp white paper HP Product Roadmaps' page at > 6 > http://www.hp.com/hpinfo/newsroom/press/07may02b.htm   I just checked again, too.  G > Under the heading "Itanium Servers" there's no mention of OSs at all, F > just the statement "AlphaServer systems will be focused on the AlphaF > installed base, high performance technical computing and other areas< > like Oracle 9i RAC where unique value-add is provided.").   H OK, no surprise here.  By the way, "focused on" does not mean "we won't  sell them for anything else".i  H > Under the heading "RISC-based Servers" (another hardware-oriented, notJ > OS-oriented, section) it states "The PA-RISC servers will be targeted at@ > the PA-RISC installed base and all new business opportunities.F > AlphaServer systems will be primarily focused on the Alpha installed1 > base and high-performance technical computing" v  I To be honest, I think that the author of this page suffers from the same sG sort of mentality that some folks have when they say "VAX/VMS" to mean eD the VMS operating system.  In other words, "unix runs on servers".  G Thus, as Fred pointed out, even though it's not stated explicitly, all nD the stuff about "new customers will not be encouraged to buy ALPHA"  refers to unix.   F Is this bad writing?  Sure.  Is it proof that HP is dropping VMS?  No.  ( I now prove that Bill is Chicken Little.  H At the bottom of THE SAME WEB PAGE BILL REFERS TO ABOVE, it says, and I H quote exactly, "HP will also deliver on the previously announced Compaq 0 OpenVMS roadmap, including the port to Itanium".  A OK, Bill might not believe this, but since he otherwise has been  F pointing to this web page as proof of HP's direction, why not in this C case as well?  Also, this is under the "OpenVMS heading", which is  6 presumably where VMS folks would look for information.   ------------------------------  % Date: Fri, 17 May 2002 05:01:22 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: No new Alpha sales , Message-ID: <3CE4C6E0.93FB62B4@videotron.ca>   Phillip Helbig wrote:tJ > customers.  Most HP customers don't know what VMS is.  And I'm sure thatH > all people who don't just contribute to the newsgroup but actually buyI > VMS hardware don't base their purchasing decisions on what's in today's  > version of a web page.  M VMS's death has been predicted by many, including Palmer et all, and Gartner,v for a long long time.H  @ Compaq neglected VMS. Compaq lied about its commitment to Alpha.  K Now, VMS is under new ownership, a company that kept silent about VMS for 8nQ months and whose policy on VMS doesn't seem to be very clear and changes at will.d  M Anyone wishing to invest into a new VMS installation will want to get a clear L picture from HP before they seriously consider VMS as a viable platform. TheA DS10 was cancelled. What else will go at the lower end of Alpha ?o  J HP did not need to make the "new customers to PA-RISC" statement. It couldL have just said that it woudl sell the solution best suited to the customer'sK needs. The lack of marketing for Tru64 and VMS, and knowledge that alpha isdN dead would restrict sales on those platform to only those who really want/need it.   J When HP made the statement, it must have known that it would further erode sales of alpha based solutions.   I So, what did Curly tell Carly about the Digital products ? Did Curly warncI Carly about the sensitivies of Digital customers  and that they shoudl beyN handled with care ? Or did he tell her not to mind thm, they'll be angry for a, while but won't have the guts to leave VMS ?   ------------------------------  + Date: Fri, 17 May 2002 11:09:12 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>h Subject: Re: No new Alpha saleso; Message-ID: <01KHTYMF74KK96VU4K@sysdev.deutsche-boerse.com>.  O > VMS's death has been predicted by many, including Palmer et all, and Gartner,s > for a long long time..  D And it's still going strong!  Which allows me not to worry too much F about the doom-criers.  Could things be better?  Yes.  Is VMS dying?  A No.  Has HP said VMS will die?  No.  Has HP issued some unclear,  H confusing statements?  Yes.  Do these affect serious, big VMS customers D (old or new)?  No.  Do they affect others who might have bought VMS  otherwise?  Perhaps.  G > Now, VMS is under new ownership, a company that kept silent about VMS H > for 8 months and whose policy on VMS doesn't seem to be very clear and > changes at will. t  I I think the quotes from Marcello and Gorham in Didier's post make things o7 clear enough.  Give it time to show up on the web site.   I > Anyone wishing to invest into a new VMS installation will want to get aeF > clear picture from HP before they seriously consider VMS as a viable > platform.   I I think people seriously wishing to invest in a new VMS installation get rH their information neither from this newsgroup nor from the HP web pages.G Also, anyone seriously considering VMS probably doesn't really have an tG alternative.  After all, VMS is the best and some people need the best.g  G This is probably the real reason for the lack of VMS marketing and why tF this has not led to the death of VMS.  People who need VMS can always F get it from the vendor and don't rely on advertisements to base their 6 decisions on and these people bring in enough revenue.  G Different issue: Could VMS be promoted more to get more new customers, iI even those who COULD run something else but could run it better on VMS?  m% Sure.  But this is a different issue.t  H Formula 1.  Most car companies participate because of the advertising.  H I believe a few years ago, Mercedes stopped racing in the Formula 1 for E a while---they didn't NEED the advertising.  In a sense, the same is l true of VMS.  E I think a series of "put your money where your mouth is" public bets oH would be in order here.  If you are REALLY sure that VMS is dying, then ) bet a large some of money on it publicly.e  ? > The DS10 was cancelled. What else will go at the lower end ofa
 > Alpha ?   : How is this relevant?  The DEC 3000 300LX was cancelled.    F > When HP made the statement, it must have known that it would further( > erode sales of alpha based solutions.   @ There is no reason to blame something on stupidity which can be  explained by incompetence.   ------------------------------  # Date: Fri, 17 May 2002 09:17:53 GMTg* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: No new Alpha salesr> Message-ID: <5V3F8.4683$yl.806369@bin3.nnrp.aus1.giganews.com>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KHTWG2DOUA984WQP@sysdev.deutsche-boerse.com...c   ...i  H > In the last, say, 5--10 years, how many VMS sales came from the vendorH > pushing VMS and how many from the customer saying that that is what he > wants?  J Unfortunately, the situation is no longer anything like it was in the past; 5 - 10 years:  11 months ago VMS got shot in both kneecaps.R   - bill   ------------------------------  # Date: Fri, 17 May 2002 09:40:16 GMTe* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: No new Alpha saleseB Message-ID: <4e4F8.163996$M7.16451941@bin7.nnrp.aus1.giganews.com>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KHTXASOKBM96VU4K@sysdev.deutsche-boerse.com...t
 > Bill wrote:a > I > > No, they are not.  They appear (still do - just checked again now) ind theh0 > > 'hp white paper HP Product Roadmaps' page at > >n8 > > http://www.hp.com/hpinfo/newsroom/press/07may02b.htm >  > I just checked again, too. >.I > > Under the heading "Itanium Servers" there's no mention of OSs at all,sH > > just the statement "AlphaServer systems will be focused on the AlphaH > > installed base, high performance technical computing and other areas= > > like Oracle 9i RAC where unique value-add is provided.").  >nI > OK, no surprise here.  By the way, "focused on" does not mean "we won'ty > sell them for anything else".g  I It does when that statement appears shortly after it (as it indeed does).J   >iJ > > Under the heading "RISC-based Servers" (another hardware-oriented, notL > > OS-oriented, section) it states "The PA-RISC servers will be targeted atB > > the PA-RISC installed base and all new business opportunities.H > > AlphaServer systems will be primarily focused on the Alpha installed2 > > base and high-performance technical computing" >rJ > To be honest, I think that the author of this page suffers from the sameH > sort of mentality that some folks have when they say "VAX/VMS" to mean > the VMS operating system.m  L Oh, really?  Are you claiming to be psychic now?  Just what, other than yourD own inclination to hope this is the case, leads you to 'think' that?  )   In other words, "unix runs on servers". H > Thus, as Fred pointed out, even though it's not stated explicitly, allE > the stuff about "new customers will not be encouraged to buy ALPHA"H > refers to unix.   L Wrong.  The proof is that the 'rationale' listed for the statement lists twoJ bases, only *one* of which is that HP-UX is the Unix future at HP.  If theE statement applied only to Unix, then that would be the *sole* reason.t   >nH > Is this bad writing?  Sure.  Is it proof that HP is dropping VMS?  No. >0* > I now prove that Bill is Chicken Little.  K Your standard for 'proof' is rather low, I'm afraid.  But it seems to matchG your analytical ability.  G Or perhaps your problem is that you just can't read.  Would you care towI point out *any* statement I've made in this discussion suggesting that HPe was dropping VMS?t  L What I've been pointing out are the clear statements in HP's roadmap that noK Alpha sales to new customers are planned (save possibly in HPTC areas whereDJ VMS is not normally the OS choice on Alpha), and that these statements are: in no way Tru64-specific as you and others keep asserting.  G Assertions that statements do not mean what they clearly say are called G 'spin' (at least if one is charitable in characterizing them).  If HP'sbF statements are taken at face value, they indicate that VMS will not beF actively sold to new customers until VMS is salable on Itanic hardwareI (though, as I said, if a new customer is sufficiently persistent they cann0 probably get their hands on a VMS Alpha system).   - bill   ------------------------------  # Date: Fri, 17 May 2002 09:45:22 GMTs* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: No new Alpha sales2> Message-ID: <Si4F8.4407$pa.607937@bin4.nnrp.aus1.giganews.com>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KHTYMF74KK96VU4K@sysdev.deutsche-boerse.com...s   ...t  J > I think the quotes from Marcello and Gorham in Didier's post make things > clear enough.s  J Hmmm.  Guess you weren't listening a couple of years ago when Marcello wasK describing the follow-on ad campaigns that would give real legs to the 'VMSnK renaissance' that was just getting started.  Or perhaps your memory is justy short and/or selective.   J Marcello is clearly not a significant force in HP, any more than he was inF Compaq.  Gorham even less so.  They say what we want to hear, and have( absolutely no ability to make it happen.   - bill   ------------------------------  + Date: Fri, 17 May 2002 11:52:15 +0100 (MET)d9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>s Subject: Re: No new Alpha salesh; Message-ID: <01KHU0C2ITQM96VU4K@sysdev.deutsche-boerse.com>t  I > Oh, really?  Are you claiming to be psychic now?  Just what, other thanfE > your own inclination to hope this is the case, leads you to 'think'S > that?   G Observation.  Actions speak louder than words.  Folks are still buying   VMS systems.  I > Or perhaps your problem is that you just can't read.  Would you care tooH > point out *any* statement I've made in this discussion suggesting that > HP was dropping VMS? e  I This thread was concerned with the claim that "no new customers on ALPHA nH means no new VMS sales" which would imply that VMS is dying.  You might I not have said so, directly, in this thread, but it is clear that that is nI your intended meaning (and no, psychic ability is not required to detect t this).   ------------------------------  % Date: Fri, 17 May 2002 12:05:37 +0100hU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>n Subject: Re: No new Alpha salesi0 Message-ID: <ac2okj$5qs$1@new-usenet.uk.sun.com>   JF Mezei wrote:e   > Fred Kleinsorge wrote: > J >>The messages you are trying to spin, are really focused on Tru64, not on >>OpenVMS. e >> > M > What is more important: how you, the insiders read the official HP text, or D > how customers and potential customers in the field read the text ? >     1 Ahh someone has finally hit the nail on the head.e  ? If a bunch of insiders having a discussion about OpenVMS cannoti> reach a conclusion about HP's intentions for OpenVMS guess how; confused the people with the check books being asked to buyn+ OpenVMS boxes (by these same insiders) are.t  ? And if you think that Sun, IBM, Fujitsu and even the other bitsv? of HP are going to sit quietly and not help the people with thes? check books get a bit more confused about OpenVMS's future thenT! you don't live in the real world.d  ; Why do you think that Sun has an program to migrate OpenVMSs( customers to Solaris as IBM does to AIX.  : Who do you think thought up the idea in HP to help OpenVMS: customers move to HP-UX, hint it wasn't the OpenVMS group.   Regardsl Andrew Harrison    ------------------------------  % Date: Fri, 17 May 2002 12:20:41 +0100 U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>a Subject: Re: No new Alpha saleso0 Message-ID: <ac2pgr$61p$1@new-usenet.uk.sun.com>   Bill Todd wrote:  B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message5 > news:gvTE8.41$Mz3.642147@cacnews.cac.cpqcorp.net...e > ? >>JF Mezei wrote in message <3CE3FA77.B161C845@videotron.ca>...l >> >>>Phillip Helbig wrote: >>>gK >>>>As far as targetting VMS to new customers, well, probably not, but this 7 >>>>is the same things have been for the last 10 years.n >>>> >>>No it isn't.  >>>-K >>>Since June 25, VMS has been running on a dying platform.  Those who needr >>>h >>thee >>G >>>Alpha high performance generally go Tru64. What Alpha does to VMS is  >>>g	 >>counterT >>L >>>some of the extra overhead that VMS's security and data integrity offers. >>>  >>>t/ >>Sigh.  VMS isn't running on a dying platform.  >> > J > Hmmm.  Given the 33% drop in BCSG revenue in Q1, the dominant portion ofK > which drop seems to be attributable to an even greater percentage fall inlN > Alpha sales, I'd say that assertion is at best highly questionable (and moreM > than likely to continue to be at least as questionable in future quarters).mK > While you may be living in a pleasant little closed world where VMS seems * > healthy, Fred, most of the world is not. >     I The UK market numbers support your view. Alpha revenues are according to eG the latest report down to their lowest share of the market for 3 years cB at 4.6% with unit volumes at an all time low as well. Prior to theE HP Compaq initial announcments Alpha had a 11.3% share of the market.n    E The whole market is depresed at the moment so its all about retainingVB or gaining market share so that you as a vendor are well placed to> do well when the market recovers. Alpha isn't doing well here.  B The number also includes Tru64 and that may have dragged the whole= number down, but at the moment OpenVMS needs Tru64 to co-funda/ the development and support of Alpha platforms.t  @ The only good news is that Alpha is still 4th in the Market :):)  	 Out of 4.o   Regardsr Andrew Harrisonm     > ...n >  > H >>>What HP just did is raise the bar even higher. Even fewer will now be >>>r > able >  >>to >>K >>>convince their management that going VMS even for 3-5 years is worth it.e >>>  >>>wI >>HP has done nothing of the sort.  Only the spin being put on it by some1D >>unhappy people in this conference looking for anything that can be >> > construed: > * >>as confirmation that the sky has fallen. >> > N > I'm afraid the only spin involved here is the spin you're attempting to give% > to some pretty clear HP statements.h >  > B >>>Like it or not, HP made certain statements. Live with it. Those >>>o > statements >  >>noth >>I >>>only send a clear message to customers, but especially to ISVs: No new' >>>m >>Alpha sales. >>L >>No we didn't.  This is a spin to try and apply something intended for UNIXI >>to VMS.  And in response to confusion in some things that were said, HPe >> > hasR >  >>even modified the statements.. >> > L > Not in the public HP roadmap, as of a couple of hours ago.  Perhaps you'reF > confused by the waffling in VMS-specific publications, but since theN > statements to the already-converted never have matched corporate-wide policy' > very well this is not too surprising.  >  > - bill >  >  >  >    ------------------------------    Date: 17 May 2002 05:42:28 -0700( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: No new Alpha sales = Message-ID: <d7791aa1.0205170442.5eca9ba9@posting.google.com>o  a JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message news:<3CE48240.D2C615B2@videotron.ca>...t > "David J. Dachtera" wrote:L > > DEC are in "maintenance" mode themselves: "Don't rock the boat, just letA > > us live out the last days of our VMS careers so we can retirecJ > > comfortably, and the hell with the next generation(s) who would follow > > in our footsteps". >  > N > I am affraid that I learned the hard way that you don't get ahead by rockingN > the boat and causing trouble, unless you were hired specifically to rock the' > boat and get a company back in shape.  > M > I understand Marcello and below for being quiet little sheep who do as they,F > are told and don't cause trouble. Unless they get support from their= > superiors, they won't achieve anything by rocking the boat.s > O > But this means that we cannot count on them to fight hard enough for VMS. ThenF > fact that that fella Stallard was allowed to release such disgustingM > statements with regards to VMS is a good indication that Marcello and below ! > are totally powerless to fight.C > O > In my opinion, the only hope is for DECUS to get its act together and get all , > worldwide chapters to organise a campaign. > N > DECUS should have its last opus by at least saving VMS. If VMS goes, so doesO > DECUS since all other Digital products will be gone. And if DECUS succeeds inbM > forcing HP to turn VMS into a succesful OS, then at least DECUS will play aG > role inside of Interex.i  A I think your barking up the wrong tree ... just got a letter fromhD my contact in Marcellos office, and the Open VMS Times page has beenC corrected ... he stated that many in HP equate Alpha with Tru64 andc@ don't understand VMS, but that the response has changed that ...D VMS is already a successful OS, as the last 22 years have proven and the future will prove ...    ------------------------------  % Date: Fri, 17 May 2002 08:06:13 -0400e2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: No new Alpha salestJ Message-ID: <rdeininger-1705020806130001@1cust81.tnt1.nashua.nh.da.uu.net>  5 In article <3CE4C6E0.93FB62B4@videotron.ca>, JF Mezei % <jfmezei.spamnot@videotron.ca> wrote:d     >TheB >DS10 was cancelled. What else will go at the lower end of Alpha ?  F The DS10 has not been cancelled.  It was still on the alphaservers webG page the last time I checked, 2 or 3 days ago.  As I am on a slow modem ; connection at the moment, I'm not going to check again now.t  B This DS10 cancellation garbage appears to have been started by theH enquirer, a proven purveyor of lies about VMS.  Why do you keep trottingA it out in this NG? Have you any credible evidence to back it up? -  H I expect DS10 will EOL eventually, since it is getting a bit long in the? tooth. Sooner or later, some third-party components will becomeoE unobtainable if they aren't already.  At that point, a major hardware'B re-design would be needed, and I don't see any sign of that on the roadmap.  J I do think the lack of more low-cost VMS options is a serious problem, but1 they aren't asking for my opinions on the matter.n  D Low-end options for VMS on alpha, post DS-10 (whenever that is) willJ include the 2P Marvel systems previous discussed here, and the DS20 family and its successor.   >and knowledge that alpha is >dead   J While I'm pointing out your inaccuracies, I might as well mention this oneJ as well.  Alpha development continues and is expected to continue for someJ time to come.  New Alpha EV7-based systems will be offered more or less atG the end of this year.  Working prototypes have been shown.  And HP (who I you only believe when they say something you don't like) has stated theiro+ intention to deliver the EV7-based systems.i  H VMS development on IPF continues, and appears poised to get a boost fromE the integration with HP.  HP has far more IPF expertise in-house than 2 Compaq did. VMS now has access to those resources.   ------------------------------  + Date: Fri, 17 May 2002 15:05:58 +0100 (MET)s9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>n Subject: Re: No new Alpha salest; Message-ID: <01KHU762DDDS96VU4K@sysdev.deutsche-boerse.com>   I > just got a letter from my contact in Marcellos office, and the Open VMS   > Times page has been corrected   ) Can you post a URL of the corrected page?    ------------------------------  % Date: Fri, 17 May 2002 12:16:09 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>r Subject: Re: No new Alpha salesm, Message-ID: <3CE52CC8.105419DD@videotron.ca>   Phillip Helbig wrote: I > quote exactly, "HP will also deliver on the previously announced Compaqc2 > OpenVMS roadmap, including the port to Itanium".  J Yeah. Which one ? The roadmap prior to June 25 that promised a great AlphaH future, or the roadmap psot June 25 that made a "commitment" to exsiting customers ?h  M This is where I have a problem.  For the systems that are stretegic to HP (orrL any company for that matter), the focus is not on telling exsiting customersM not to worry, but rather on saying as loud as possible that they intend to dolN what it takes to grow that business. They don't need to make public statementsM about "commitments to exsisting customers" because exsiting customers are notr0 worried about the vendors' commitment to the OS.  J So, ask yourself, why is it that Compaq and HP are so intent on mentioningN "commitment to existing customers" so often when they refer to VMS ? Why don'tE they stand up and proclaim that they intend to grow VMS, leverage itslN scalability from desktop to datacentre, and continue to lead the industry withP the best quality, best security, best reliability and best clustering there is ?  M If HP had come out with clear statements about its intentions to grow VMS, weeL wouldn't have to worry about HP letting go of VMS. But it is exactly becauseL HP comes out with "existing customers will be protected" types of statements9 that we see HP's intentions of gradually phasing out VMS.y   ------------------------------  % Date: Fri, 17 May 2002 12:29:35 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>0 Subject: Re: No new Alpha salesb, Message-ID: <3CE52FED.E4B21CA3@videotron.ca>   Phillip Helbig wrote:4J > I think the quotes from Marcello and Gorham in Didier's post make things9 > clear enough.  Give it time to show up on the web site.K  K Sorry. But Marcello and Gorham are not high enough in the HP hiearchy to beyL speaking on authority, and certaintly do not appear to have any influence onI setting policy. Stallard's original memo being a good indication of that.o  D They can say all the good things they want, but if HP comes out withL statements a week later than continue to say that MS is expected to run only+ on existing customers, who do you believe ?   J > I think people seriously wishing to invest in a new VMS installation getJ > their information neither from this newsgroup nor from the HP web pages.  H Sorry, but if HP has 2 versions of its roadmap, I choose the one that is public and on the web site.tM If Carly is unwilling to make a statement about VMS on TV, then it means thate: her "commitment" to VMS is not real and not to be trusted.  H > Also, anyone seriously considering VMS probably doesn't really have anI > alternative.  After all, VMS is the best and some people need the best.n  E The best at what ? For reliability, Tandem is the best.  For softwareuH availability, HP-UX is the best. VMS is a great balance between the two.N Problem is that its owner sees it differently (not good enough to beat tandem," and not good enough to beat Unix).    H > Formula 1.  Most car companies participate because of the advertising.I > I believe a few years ago, Mercedes stopped racing in the Formula 1 for F > a while---they didn't NEED the advertising.  In a sense, the same is > true of VMS.  M Define "need for advertising". Prior to the "renaissance", at the time CompaqtL seriously considered killing VMS, it had a negative growth. Marcello's shortN lived renaissance managed to turn this around and make VMS grow and give hopesK to many. As the effects of that effort fade away, you'll see VMS enter into K negative growth again,  especially when you consider the bad effects of thelL murder of Alpha, lack of a viable replacement platform and turmoil due to HP buying Compaq.  M There is a big unwanted bump ahead (forced migration to IA64). There needs topG be serious marketing to give VMS, its customers and especially ISVs the D incentive to go over the bump, Otherwise VMS will stall at the bump.  A > > The DS10 was cancelled. What else will go at the lower end ofn > > Alpha ?h > : > How is this relevant?  The DEC 3000 300LX was cancelled.  N It is relevant because VMS's potential target niches are further being reduced6 with its "low end" threshold raised without the DS-10.   ------------------------------  % Date: Fri, 17 May 2002 12:50:40 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>s Subject: Re: No new Alpha salese+ Message-ID: <3CE534DD.F7647BD@videotron.ca>(   Robert Deininger wrote:lJ > VMS development on IPF continues, and appears poised to get a boost fromG > the integration with HP.  HP has far more IPF expertise in-house thanS4 > Compaq did. VMS now has access to those resources.  V I have only seen statements from HP that development of vMS on Alphaservers continues.? I have seen separate statement that the port to IA64 continues.   K I have no seen any statement that clearly states HP's intentions to developj& VMS on IA64 once the port is complete.  N The wording in both cases was specific enough to make one wonder why they were so specific with that wording.   ------------------------------  % Date: Fri, 17 May 2002 12:54:58 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>a Subject: Re: No new Alpha sales , Message-ID: <3CE535DE.A4AA8F33@videotron.ca>   Bob Ceculski wrote:sC > I think your barking up the wrong tree ... just got a letter fromuF > my contact in Marcellos office, and the Open VMS Times page has beenE > corrected ... he stated that many in HP equate Alpha with Tru64 andlB > don't understand VMS, but that the response has changed that ...F > VMS is already a successful OS, as the last 22 years have proven and > the future will prove ...k  K I don't want to hear some underling under MArcello say that. I want to hear0M Carly Fiorina say it publicly and send a memo to all HP employees to kill thecK misconception that VMS users would be porting to HP-UX. Until that is done,vE that little island in Marcello's "legacy" group will have very little G influence on what the rest of the HP monster says, does and advertises.c  K In my opinion, the only reason the most offending statements from Stallards M letter were changed was that Marcello was able to go to Stallard and tell himtM that he went too far with the truth and that the attrition rate would be muchmM higher than anticipated if they continued with that rethoric. Carly said that 2 they expect 9% attrition rate on certain products.   ------------------------------  # Date: Fri, 17 May 2002 17:11:04 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>  Subject: Re: No new Alpha saleso9 Message-ID: <IQaF8.25$P54.579637@cacnews.cac.cpqcorp.net>d  A David J. Dachtera wrote in message <3CE47C6A.666577CB@fsi.net>...1   > H >Remember: certain senior VMS management, certain senior VMS Engr. staffH >and certain of the others who came over from an already long stint withI >DEC are in "maintenance" mode themselves: "Don't rock the boat, just letK> >us live out the last days of our VMS careers so we can retireG >comfortably, and the hell with the next generation(s) who would followp >in our footstepse  3 Can you point me to them, because I don't know any.r   ------------------------------  # Date: Fri, 17 May 2002 17:06:23 GMTn* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: No new Alpha salesiB Message-ID: <jMaF8.165556$M7.16726310@bin7.nnrp.aus1.giganews.com>  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagesD news:rdeininger-1705020806130001@1cust81.tnt1.nashua.nh.da.uu.net...7 > In article <3CE4C6E0.93FB62B4@videotron.ca>, JF Mezeir' > <jfmezei.spamnot@videotron.ca> wrote:d >t >l > >TheD > >DS10 was cancelled. What else will go at the lower end of Alpha ? >eH > The DS10 has not been cancelled.  It was still on the alphaservers webI > page the last time I checked, 2 or 3 days ago.  As I am on a slow modem = > connection at the moment, I'm not going to check again now.u >mD > This DS10 cancellation garbage appears to have been started by the0 > enquirer, a proven purveyor of lies about VMS.  L Really?  Care to be more specific?  Generalized mud-slinging doesn't exactly enhance your own credibility.t     Why do you keep trottingB > it out in this NG? Have you any credible evidence to back it up?  K I haven't seen any solid evidence, but I have seen at least two separate HP J .ppt slides recently that show the supposed 2002 - 2004 roadmap:  on both,I Itanic evolution through 2004 is indicated, EV7 evolution through 2004 ispJ indicated for the GS and ES series, and the DS series is blank after 2002.  J Let's say that at the very least some public clarification is needed here.   - bill   ------------------------------  % Date: Fri, 17 May 2002 19:03:34 +0200l- From: Didier Morandi <Didier.Morandi@Free.fr>A Subject: Re: No new Alpha saleso' Message-ID: <3CE537E6.B1D736FE@Free.fr>    JF Mezei wrote:s > M > I don't want to hear some underling under MArcello say that. I want to heartO > Carly Fiorina say it publicly and send a memo to all HP employees to kill the%M > misconception that VMS users would be porting to HP-UX. Until that is done,aG > that little island in Marcello's "legacy" group will have very littleyI > influence on what the rest of the HP monster says, does and advertises.c > M > In my opinion, the only reason the most offending statements from StallardsvO > letter were changed was that Marcello was able to go to Stallard and tell himtO > that he went too far with the truth and that the attrition rate would be much O > higher than anticipated if they continued with that rethoric. Carly said thatr4 > they expect 9% attrition rate on certain products.  3 To me, you are wrong. The truth seems more obvious:s  G COMPAQ did NOT care about VMS, but VMS continued to live because of theaP excellence of the product(s), the number of currently running systems (470'000?) and the $$ it brings back.  N HP, as they seem to be better managers (not difficult compared to COMPAQ) have+ understood that and have reversed the flow.w  P There is a second reason. I am sure that there are _a lot_ of former DECcies who" went to HP in 1998. This may help.   My 2    D. -- i2   ------------------------------------------------2 MORANDI Consultants  http://Didier.Morandi.Free.fr0   19 chemin de la Butte, 31400 Toulouse, France.2 Tel.: +33 (0)6 7983 6418 - Fax: +33 (0)5 6154 19282 OpenVMS, APPLE, Computer Security, Migration plans1 Visit: http://www.softresint.com/AlphaMigrate.htms2 --------------------------------------------------   ------------------------------  # Date: Fri, 17 May 2002 17:11:03 GMTt5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>t Subject: Re: No new Alpha sales'9 Message-ID: <HQaF8.24$P54.579637@cacnews.cac.cpqcorp.net>e  = JF Mezei wrote in message <3CE40B7C.66F5B618@videotron.ca>...>    " >It doesn't matter what you think.    @ Well, I don't need to read any farther, or make any other reply.   ------------------------------  # Date: Fri, 17 May 2002 17:07:21 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: No new Alpha salesg@ Message-ID: <dNaF8.12677$th.1134889@bin2.nnrp.aus1.giganews.com>  F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KHU0C2ITQM96VU4K@sysdev.deutsche-boerse.com...oK > > Oh, really?  Are you claiming to be psychic now?  Just what, other thancG > > your own inclination to hope this is the case, leads you to 'think' 	 > > that?d >rH > Observation.  Actions speak louder than words.  Folks are still buying > VMS systems.  C Well, since 'folks' could be as few as two customers, you're almost I certainly correct.  But check out the Q1 financial statement from Compaq: L people are buying Alpha systems in such dramatically smaller quantities thatK even a drop in Tru64 sales to zero would be hard-pressed to account for allnL the shrinkage (i.e., VMS sales are shrinking, significantly - and there's atK least some indication that this has been going on for about a year now, notV just last quarter).r   >cK > > Or perhaps your problem is that you just can't read.  Would you care to J > > point out *any* statement I've made in this discussion suggesting that > > HP was dropping VMS? >cJ > This thread was concerned with the claim that "no new customers on ALPHAI > means no new VMS sales" which would imply that VMS is dying.  You mighteJ > not have said so, directly, in this thread, but it is clear that that isJ > your intended meaning (and no, psychic ability is not required to detect > this).  F HP doesn't have to drop VMS for VMS to die:   people just have to stopA buying it (as they appear to be doing).  Of course, if sales dropaL sufficiently (a criterion that could even already have been met, consideringG the kinds of comments coming out of Carly's level), there's no questionsK whatsoever that HP (especially under its current management) will choose tot finish the job.l  K The concept of a 'death spiral' is hardly a new one.  VMS is unquestionablyaG in such a spiral - the only issue being just how fast a one and exactlytL where the cliff is located.  And the *only* entity in any position to change this is VMS's owner.   - bill   ------------------------------  # Date: Fri, 17 May 2002 17:21:40 GMTr5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>  Subject: Re: No new Alpha salesn9 Message-ID: <E_aF8.26$B64.607367@cacnews.cac.cpqcorp.net>   6 Andrew Harrison SUNUK Consultancy wrote in message ...   >V2 >Ahh someone has finally hit the nail on the head. >a  7 You are mistaking the point on your head for a nail ;-)d  @ >If a bunch of insiders having a discussion about OpenVMS cannot? >reach a conclusion about HP's intentions for OpenVMS guess how.< >confused the people with the check books being asked to buy, >OpenVMS boxes (by these same insiders) are. >.  L Who are these "insiders" who cannot reach a "conclusion"?  As far as I know,J the "insiders" do have the same story.  It is disputed by some others, whoK have their own agendas, and by you - who have no interest in VMS other than  to try and spread FUD.   >e< >Why do you think that Sun has an program to migrate OpenVMS >customers to Solarisn  K Because they have so much excess equipment from the dot.bomb (you *are* theiH dot in dot.com aren't you?).  Or maybe because the Sun slide in sales isG pretty dramatic in itself, and you aren't finding many non-Solaris UNIXo types that want to trade down.   ------------------------------  % Date: Fri, 17 May 2002 09:26:13 +0200n) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>d. Subject: Re: Non-interactive TECO? (of course)/ Message-ID: <3CE4B095.1080709@xs4all.nospam.nl>w   Larry Kilgallen wrote:   	[Snip]I  # > In general terms, something like:d >  > 	$ mung = "$teco32 mung"& > 	$ define/user sys$command sys$input > 	$ teco <filename> > 	ex$$f > E > "EX" does not count unless it is followed by two escape characters.-  G I agree with respect to TECO, but why would you need the $ define/user d sys$command sys$input ?y  	 Bart Zornc   ------------------------------  % Date: Fri, 17 May 2002 10:09:05 +0200u) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>s. Subject: Re: Non-interactive TECO? (of course)- Message-ID: <3CE4BAA1.40709@xs4all.nospam.nl>    Phillip Helbig wrote:e% >>$ define/user sys$command sys$input  >  > & > $  DEFINE/USER SYS$INPUT SYS$COMMAND >  > might be better.  :-|y  H Why all this FUD? By default SYS$INPUT points to the job's input stream E at it's current location and SYS$COMMAND points to the job's primary sH input device (the keyboard). In interactive mode they both point to the C keyboard and in the context of a batch job, they both point to the sI current command file, at it's current location. Almost all programs read  ( from SYS$INPUT and TECO is no exception.  3 Therefore, either form of the DEFINE/USER is wrong:R  # $ DEFINE/USER SYS$INPUT SYS$COMMANDK  G This will have no effect when running in batch and will have the wrong  E effect when running interactively. In this case, TECO will read it's oC commands from the terminal and ignore anything in the command file.-  # $ DEFINE/USER SYS$COMMAND SYS$INPUT   @ This also will have no effect when running in batch mode and is G redundant when running interactively, because nobody is trying to read r something from SYS$COMMAND.e  	 Bart Zornx   ------------------------------    Date: 17 May 2002 08:28:41 -0600- From: koehler@encompasserve.org (Bob Koehler) . Subject: Re: Non-interactive TECO? (of course)3 Message-ID: <vzSmTxYv11Au@eisner.encompasserve.org>p  [ In article <3CE4B095.1080709@xs4all.nospam.nl>, Bart Zorn <B.Zorn@xs4all.nospam.nl> writes:m > Larry Kilgallen wrote: > 	 > 	[Snip]H > $ >> In general terms, something like: >>   >> 	$ mung = "$teco32 mung"s' >> 	$ define/user sys$command sys$inputg >> 	$ teco <filename>a >> 	ex$$ >> oF >> "EX" does not count unless it is followed by two escape characters. > I > I agree with respect to TECO, but why would you need the $ define/user m > sys$command sys$input ?   <    You don't.  In fact that's probably the original problem.   ------------------------------  % Date: Fri, 17 May 2002 16:29:37 +0100u' From: Elliott Roper <elliott@yrl.co.uk>?. Subject: Re: Non-interactive TECO? (of course)2 Message-ID: <170520021629376996%elliott@yrl.co.uk>  ? In article <vzSmTxYv11Au@eisner.encompasserve.org>, Bob Koehler " <koehler@encompasserve.org> wrote:  ; > In article <3CE4B095.1080709@xs4all.nospam.nl>, Bart Zornw# > <B.Zorn@xs4all.nospam.nl> writes:i > > Larry Kilgallen wrote: > >  > >   [Snip] > > & > >> In general terms, something like: > >> P > >>  $ mung = "$teco32 mung"m) > >>  $ define/user sys$command sys$input  > >>  $ teco <filename>n
 > >>  ex$$ > >> iH > >> "EX" does not count unless it is followed by two escape characters. > > K > > I agree with respect to TECO, but why would you need the $ define/user   > > sys$command sys$input ?E > > >    You don't.  In fact that's probably the original problem.  E Had me confused too. But since defines always confuse me I kept mousyn quiet.  F My trick for stopping DCL eating Teco's escapes in batch was to have a@ small teco macro do the work. It has the advantage of processing wildcard filespecs.o   Command file looks like  $mung = "$teco32 mung" $mung fix_crlf.tec,'p1'o  5 Teco macro (the contents of fix_crlf.tec) looks like e# hxahken^eqa$<:en$;:eb^eq*$;ec$>ex$$e  F In detail it works like this (I'll get some of you young'uns into teco if it kills me)n  C It takes advantage of mung being able to accept command line stringyG into its text buffer. Here 'P1' is what the command file passes in e.g.tA *.MEM (It's usually runoff output that needs this teco treatment)   E hxa means read the whole buffer into a scratch q register. I chose A. F hk (we don't need the command string fragment any more. h is short for5 0,z which is short for everything in the text buffer)r  B en^eqa$ means load the contents of q register a into the 'wildcardC buffer' Actually I could have made that shorter with en.,zhk AlwayshB more than one way to do anything in teco. The hxahken^qa is an oldF habit of mine. You get so your fingers know teco, they sometimes referB to the teco  cache in your spinal chord, and only rarely interrupt brain.  3 <....> is one of teco's loop contructs. Inside is:- F :en$; which selects the next matching wildcard filespec and exit if noD more. Teco has a 'feature' here. It fails on the first attempt after6 the first failure to pick up another matching filespec  ? :eb^q*$; Open the file for read and write and exit if you can'toF ec means read all the input to the output and close both. The $ is not- needed really. My teco is needlessly verbose.V  F finally ex$$ tells teco to stop mucking about and hand control back to the DCL.  @ Even teco finds it hard to insert two escapes, since two escapesC terminate the teco command. If you are struggling to finish off the B macro interactively in teco try 27i$27i$  (ni$ inserts a characterF whose decimal ascii value is n If your current radix is 10, you get an escape.m  D OK, for you complete beginners who want the batch trick, here is theD exact sequence of characters to create your teco macro file starting0 from DCL and assuming teco32 is on your machine.   $EDIT/TECO FIX_CRLF.TECt (teco will say '*') . @i/hxahken^eqa`<:en`;:eb^eq*`;ec`>ex`/27i`ex``G You will be back at DCL and the file fix_crlf.tec will be ready in your ? current directory. (` is a surrogate escape character that tecoi> recognises natively) Cut it from this post. I did. It works OK  5 Just in case you missed it. There is a teco manual at & http://www.yrl.co.uk/~elliott/teco.doc   Here endeth the first lesson.@   ;-)o   Elliottj   ------------------------------  % Date: Fri, 17 May 2002 10:15:04 +0200 ) From: Bart Zorn <B.Zorn@xs4all.nospam.nl>n- Subject: Re: Non-interactive TECO? (solution) / Message-ID: <3CE4BC08.2040009@xs4all.nospam.nl>r   Paul Sture wrote:n\ > In article <01KHOI0PPCB88XANNL@dairyland.ca>, Ingemar Olson <IOLSON@dairyland.com> writes: >  >>Bingo!  Thanks Paul. >>6 >>So the solution is to NOT redefine the input device.B >>This strikes me as counter-intuitive (and apparently a couple of5 >>other guys too!), but it works and I'm happy again.M >>	 >>Ingemart >  > D > (Huh? Don't know what happend to my reply there. Let's try again.) > < > Great. To clarify the subject, here's an example where you! > _would_ want to use a redefine:r > & > $ define /user sys$input sys$command& > $ edit /edt 'data' /command=edit.edt > : > This is telling EDT to execute the commands in EDIT.EDT,> > then provided EDIT.EDT doesn't contain an EXIT, pass control; > to the terminal. Without the DEFINE, EDT would simply seec; > the next line in the procedure as a $ and perform a QUIT.e > = > This is handy where for example, EDIT.EDT contains commands'= > to perform global replacements, but you wish to stay in the > > editor to perform visual checking or other operations before > confirming the changes.v > 2 > I suppose I ought to write this stuff up now :-) >  > __ > Paul Sture
 > Switzerlandi  A You are right, but the initial question of this thread was about c exeuting a TECO macro in batch!u  J See my other post for an elaboration about de input redefinition commands.  	 Bart Zornu   ------------------------------    Date: 17 May 2002 06:53:38 -0700) From: google@mccready.com (Gary McCready)o6 Subject: NY NYC VMS Senior Systems Manager job opening< Message-ID: <6e64ea70.0205170553.a1310aa@posting.google.com>  F The below is for the division of SIAC that provides the technology forB the American Stock Exchange. You'll be part of a team that managesC over 100 (mainly) Alpha and VAX systems that handle real-time stockn? trades for the Exchange. Please note this is a senior, hands-onaD position - typically, to be considered you must have been THE personC involved with all aspects of managing a VMS system in a past job orI jobs.$  D The position is located in the Metrotech Center in Brooklyn, an easyC commute from almost anywhere in the NYC Metro area (just two subwayM stops from downtown Manhattan).E  A Email resumes to SIAC@McCready.com and we'll make sure the hiringlF manger gets it; or, if you don't care to deal with an employee handing@ your resume to the hiring manager, you can also find this job atB Monster.com, and most VMS-Centric headhunters in the NYC area willC also know about it. Relocation has been done in the past, but it ismC unknown if it will be done for this job. If you are concerned abouteD sponsorship, etc., your best bet is to go through Monster.com, which will go through HR.N     Lead Systems ProgrammerD  C Candidate must have at least 5 years of experience within a DEC/VMSn environmenti   Duties and Responsibilities:F Responsible for ongoing systems support and maintenance of all DEC/VMSB environments within AMEX Services. Significant experience with theC installation, configuration and maintenance of Open VMS (VMS 6.2 orcB higher preferred), DECnet Phase V, DECnet over TCP/IP, LAT, TCP/IPC (UCX 4.2 or higher preferred) and layered product suites on VAX ande? ALPHA platforms in both clustered and single node environments.e= Familiarity with Storageworks disk arrays, and DECservers, isw
 necessary.  
 Requirements:iF Proven ability to work independently as well as supervise (and in someA cases manage) diverse projects. Experience conducting performancee@ analysis using DECps and/or ViewPoint and the ability to analyzeE performance data, conduct trend analysis and make recommendations fordF systems tuning. Ability to independently perform problem determinationC and isolation using system monitoring and fault determination toolstD including DECevent, DECamds, PATROL. Candidate must be able to writeA and troubleshoot DCL command procedures, dealing with backups and E operational utilities. Experience with any of the following is also ahE desirable: DECnet over TCP/IP, X.25, Windows NT, SYBASE. Must possesslD outstanding organizational, administrative and interpersonal skills.B Must be able to write documentation related to release management,@ planning, and status. Ability to use PC based software includingB MSWord, MS Excel, Internet Explorer, X-term, and VT emulation. AnyC experience with web based information distribution would be a plus. A Ability to work on any of three shifts. Ability to work a dynamicV number of weekends.t .   0 Salary: USD 80,000.00 to USD 100,000.00 per year plus annual bonus " Position Type: Full Time, Employee   ------------------------------  + Date: Fri, 17 May 2002 10:56:08 +0000 (UTC)n. From: "Sanface Software" <sanface@sanface.com> Subject: PLUG: txt2pdf 5.7H Message-ID: <f7f8cd050d45490e2a4f708b835675af.93245@mygate.mailgate.org>  / We would like to announce txt2pdf 5.7 version. h# http://www.sanface.com/txt2pdf.html E txt2pdf is shareware; it is a very flexible and powerful PERL5 scriptaH that converts text files to PDF format files, so you can use it in everyF operating systems supported by PERL5, including MPE/iX and OpenVMS. IfF you prefer we also distribute executables for Windows, Linux, Solaris,G AIX, HP-UX, and Mac OS X. Inside the Windows version is Visual txt2pdf, 	 a VB GUI..   What's new in this version  A Corrected a little bug into PDF date info (thanks David Norman).  D txt2pdf.vim 2.0 inside contributed directory: VIM plugin to save and1 convert the edited text to PDF clicking a button!    Test txt2pdf 5.7!h6 You can find it at http://www.sanface.com/txt2pdf.html     -- -8 Posted via Mailgate.ORG Server - http://www.Mailgate.ORG   ------------------------------  # Date: Fri, 17 May 2002 17:32:07 GMT75 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>p9 Subject: Re: Problem with the internal clock of an XP1000t9 Message-ID: <r8bF8.28$H64.613441@cacnews.cac.cpqcorp.net>-  H It took us quite a while to finally figure out what was happening.  SomeH type of oddball "bug" in the device that didn't cause any failures, justJ excessive bus retries.  In fact the identical code was running on the VX1, and we never saw it on the VX1.     A Jeff Goodwin wrote in message <3CE42219.EE72F916@maine.rr.com>...a! >If memory serves me correctly...d > I >We had this problem on our XP900s on OpenVMS V7.2-1.  After swapping out-H >about every part on my system and after many months, Compaq rewarded me >with the following new image: >h- >          SYS$LIBRARY:DECW$SERVER_DDX_P2.EXEi >n >Here's the image ident: >i1 >                image name: "DECW$SERVER_DDX_P2"r< >                image file identification: "DW V7.1-010817"A >                image file build identification: "X6TF-PLU-0000"t8 >                link date/time: 16-NOV-2001 14:07:11.480 >                linker identification: "A11-39" > F >I don't believe the image has been release in any kit, but I could beG >wrong.  You can also muck with DECW$DEVICE_CONFIG_P2.COM to bypass theoE >problem image and avoid the problem.  We were seeing a loss of aboute9 >five minutes a day with systems with heavy graphics use.r >t >-Jeff >l9 >Our motto: If programmers can write it, we can break it.d >  >Rudolf Wingert wrote: > 	 >> Hello,h >>F >> an user reports, that the clock of an XP1000 with OpenVMS 7.1-2 AXPD >> slows down if the CPU is heave loaded. Does anybody see the same?0 >> Is there any patch out to solve this problem? >>! >> TIA and regards Rudolf Wingert  >l   ------------------------------    Date: 17 May 2002 08:17:28 -0600- From: koehler@encompasserve.org (Bob Koehler) # Subject: Re: TCP/IP for VMS...HELP!t3 Message-ID: <ZjgMVfElPIr8@eisner.encompasserve.org>n  n In article <hxXE8.14534$ah_.10547@news01.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes: > L > "I'll bite", he said, knowing that he really wanted to hear about the 'get > three envelopes' story.. >   E    New manager moves into his new office and finds three envelopes inuE    his desk.  There's a note on top, "Open one of these when you findcC    yourself in real trouble."  They appear to have been left by theg    former manager.  C    He jumps into the leadership of a new project.  Despite his best G    efforts the project is eventually behind schedule and over budget.  jE    The customer is unhappy.  Higher management starts leaning hard onq    him to find a solution.  D    Sitting at his desk, worrying over his problems, he remembers the1    three envelopes.  He opens the first envelope:i         Retrain.  D    He goes to higher management and sells this idea.  His people areE    using new technology and working issues they have never dealt withzE    before.  Higher management buys this and sells it to the customer.6%    All their problems will be solved.n  A    A few months go by.  The entire staff is intensively trained. oG    There's a new optimism.  For a while things get better.  Then thingsnN    go bad again.  The project is eventually behind schedule and over budget.  E    The customer is unhappy.  Higher management starts leaning hard onM    him to find a solution.  H    Sitting at his desk, worrying over his new problems, he remembers theI    three envelopes.  The first one seemed to help.  Maybe the second one s0    would offer valuable wisdom.  He opens it up:         Reorgainize.  =    He goes to higher management and sells this new idea.  The-?    organization is wrong, it isn't addressing his issues.  With C    the new technology and new training, he needs a new arganizationcH    to implement new ideas.  Higher management buys this and sells it to     the customer.  >    A few weeks go by.  The entire staff is reorganized.  Again<    there's a new optimism.  For a while things get better.    ?    Then things go bad again.  The project is eventually behind -E    schedule and over budget again.  The customer is unhappy.  Higher rI    management calls him to a meeting and warns him he must find a better ?    solution.  H    He goes back to his office and opens his desk. He takes out the third!    envelope and eagerly reads it:o         Get three envolopes.   ------------------------------    Date: 17 May 2002 09:13:35 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)n> Subject: Traditional VMS NFS names vs. Extended Filename Parse3 Message-ID: <zY1JKr1kL36x@eisner.encompasserve.org>s  = Looking at the documentation for Compaq TCP/IP Services V5.1,-A I cannot find anything about getting rid of the name uglificationZ  % 	DNFS2:[$R$EALLY_$U$GLY]$F$ILE.$N$AMER  ? even though I would expect it to be mostly unnecessary on Alphas with Extended Filename Parsing.g  % 	1. Is there something I am missing ?$. 	2. If not, do MultiNet or TCPware do better ?   ------------------------------   Date: 17 May 2002 16:08:57 GMT4 From: "Jim Strehlow" <JimStrehlowNoSpam@data911.com>B Subject: Re: Traditional VMS NFS names vs. Extended Filename Parse0 Message-ID: <ac39up$qps@dispatch.concentric.net>  1 Is the NFS directory on a Windows server or on anbD OpenVMS Alpha with ODS-2 formatted disks (only UPPERCASE file-specs)L or OpenVMS Alpha with ODS-5 formatted disks that allow lowercase file-specs?  > You get the dollar signs "$" for files specified in UPPERCASE.8 When we write files in our programs using all lowercase, we do not get the dollar signs.l> But, you have to be using a NFS directory whose disk structure" allows lowercase in the file-spec.  < With a NFS directory on OpenVMS v7.2-1 or higher with a disk: formatted ODS-5, we specifically use lowercase file-names.. With a NFS directory on a Windows 2000 server,8 we specifically use lowercase filenames in our programs.  E What I remember was that the "$" is for the first UPPERCASE character-C and the next "$" says the next characters in the file-spec are alson
 UPPERCASE.   Jim Strehlow, Data911c Alameda, CA, USA    : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:zY1JKr1kL36x@eisner.encompasserve.org...4? > Looking at the documentation for Compaq TCP/IP Services V5.1,aC > I cannot find anything about getting rid of the name uglificationi >l& > DNFS2:[$R$EALLY_$U$GLY]$F$ILE.$N$AME >>A > even though I would expect it to be mostly unnecessary on Alpha	! > with Extended Filename Parsing.u >s& > 1. Is there something I am missing ?/ > 2. If not, do MultiNet or TCPware do better ?o   ------------------------------    Date: 17 May 2002 11:12:45 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)rB Subject: Re: Traditional VMS NFS names vs. Extended Filename Parse3 Message-ID: <Wm65Z7hcWrFq@eisner.encompasserve.org>k  g In article <ac39up$qps@dispatch.concentric.net>, "Jim Strehlow" <JimStrehlowNoSpam@data911.com> writes:n  @ > You get the dollar signs "$" for files specified in UPPERCASE.: > When we write files in our programs using all lowercase,! > we do not get the dollar signs. @ > But, you have to be using a NFS directory whose disk structure$ > allows lowercase in the file-spec.  D I should have been more clear.  This is an environment where the NFSC server is a Unix machine and I am trying to use the files from VMS.>A To date the best solution I have found is to transfer a TAR file,w which I consider suboptimal.  0 > With a NFS directory on a Windows 2000 server,: > we specifically use lowercase filenames in our programs.  @ This is existing code, so I do not have that option, but thanks.   ------------------------------   Date: 17 May 2002 15:52:01 GMT4 From: "Jim Strehlow" <JimStrehlowNoSpam@data911.com>= Subject: Re: vax/alpha print to hp laser printers help neededs0 Message-ID: <ac38v1$qpn@dispatch.concentric.net>  , This is a multi-part message in MIME format.  + ------=_NextPart_000_0009_01C1FD80.1B323140h Content-Type: text/plain;  	charset="iso-8859-1"q+ Content-Transfer-Encoding: quoted-printabler   $ show queue/all/device/full ...uE Terminal queue LTA999, idle, on NODENM::LTA999:, mounted form DEFAULTa7  /BASE_PRIORITY=3D4 /DEFAULT=3D(FEED,FORM=3DDEFAULT)=20 -  /LIBRARY=3DPWRK$DEVCTL_HP_LASERJET Lowercaseg#  /OWNER=3D[1,4] /PROCESSOR=3DLATSYM 0  /PROTECTION=3D(S:M,O:D,G:R,W:S) /RETAIN=3DERROR   $ show queue/forms/fullr9 Form name                            Number   Description 9 ---------                            ------   -----------tD DEFAULT                                   0   System-defined defaultD     /LENGTH=3D66 /MARGIN=3D(BOTTOM=3D6) /STOCK=3DDEFAULT /TRUNCATE = /WIDTH=3D132   $ show device/full lta999t> Terminal LTA999:, device type unknown, is online, allocated, = record-orientedgI     device, carriage control, device is spooled through an intermediate =o device.   J     Error count                    0    Operations completed             =    242J     Owner process       "SYMBIONT_4"    Owner UIC                        =  [1,4]?     Owner process ID        20A00499    Dev Prot              =t S:RWPL,O:RWPL,G,WrJ     Reference count                1    Default buffer size              =     80   Jim Strehlow, Data911c  :   "Barry Treahy, Jr." <Treahy@mmaz.com> wrote in message =! news:3CE454A5.6030704@mmaz.com...eH How about showing your full queue settings, so that we can see how you =  are defaulting the library?Barry2 "John E. Malmberg" <wb8tyw@qsl.network> wrote in =+ messagenews:3CE46054.7020300@qsl.network...uD Jim Strehlow wrote: > We have a problem converting one site from a =E MicroVAX 3100 OpenVMS > v5.5-2H4 to OpenVMS Alpha DS20 OpenVMS v7.2 =rI regarding printing. > > Print queues print properly to HP laserjet 4000 =sJ and 4050 on the VAX > using the next library. When I copied that library =H to the Alpha and > initialized print queues similar to what was on the =H VAX, the printed > jobs begin in the middle of the page, 1/4 way down, = 3/4 of the way >H ; down the page, all over the place. When two different people print > =I to the same printer, their print jobs commingle and print within > each =tH other. It is a mess.Comingling of print jobs usually means a handshake =E problem on a seriallink, or a firmware problem on the printer for a =.I network connection.The other thing to verify is that the print queue is = J actually beingused, and that programs that are supposed to be writing to = the spooled<D br>device are not writing directly to the printer.Is this LAT to a =E parallel port or a serial port?As far as jobs starting in the wrong =wI place, it could be the above also.One thing that was found is that some =OC HP Laserjets print from the bottomof the page to the top.  If the =lG document has the wrong page size, thenall sorts of interesting things =iA happen.  But that is something that getsnoticed when you change =r= printers, not hosts.If the VAX can still print correctly, the I n I would suspect thatsomething did not get set up as you expected with =rF the print queues onthe Alpha.-Johnwb8tyw@qsl.networkPersonal Opinion = Only       --=20e  B Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO=20  A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028     + ------=_NextPart_000_0009_01C1FD80.1B323140a Content-Type: text/html; 	charset="iso-8859-1",+ Content-Transfer-Encoding: quoted-printablee  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =n charset=3Diso-8859-1">9 <META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>a <STYLE></STYLE>o </HEAD>t <BODY bgColor=3D#ffffff>) <DIV><FONT face=3DArial size=3D2>$ show = + queue/all/device/full<BR>...<BR>Terminal=20 7 queue LTA999, idle, on NODENM::LTA999:, mounted form=20oF DEFAULT<BR>&nbsp;/BASE_PRIORITY=3D4 /DEFAULT=3D(FEED,FORM=3DDEFAULT) =
 </FONT></DIV>  <DIV><FONT face=3DArial =.4 size=3D2>&nbsp;/LIBRARY=3DPWRK$DEVCTL_HP_LASERJET=20 Lowercase</FONT></DIV>7 <DIV><FONT face=3DArial size=3D2>&nbsp;/OWNER=3D[1,4] =c  /PROCESSOR=3DLATSYM</FONT></DIV>I <DIV><FONT face=3DArial size=3D2>&nbsp;/PROTECTION=3D(S:M,O:D,G:R,W:S)=20> /RETAIN=3DERROR</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>C <DIV><FONT face=3DArial size=3D2>$ show queue/forms/full<BR>Form=20(J name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=J sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs= p;&nbsp;&nbsp;&nbsp;=20e Number&nbsp;&nbsp;=20vJ Description<BR>---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=J nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=+ bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20u ------&nbsp;&nbsp;=20rJ -----------<BR>DEFAULT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=J sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=J p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
 ;&nbsp;=20J 0&nbsp;&nbsp; System-defined default<BR>&nbsp;&nbsp;&nbsp; /LENGTH=3D66=203 /MARGIN=3D(BOTTOM=3D6) /STOCK=3DDEFAULT /TRUNCATE =m /WIDTH=3D132</FONT></DIV>e4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>G <DIV><FONT face=3DArial size=3D2>$ show device/full lta999</FONT></DIV>gI <DIV><FONT face=3DArial size=3D2>Terminal LTA999:, device type unknown, =s
 is online,=20wC allocated, record-oriented<BR>&nbsp;&nbsp;&nbsp; device, carriage =n control,=20o> device is spooled through an intermediate device.</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>< <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Error=20J count&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=1 bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 ! 0&nbsp;&nbsp;&nbsp; Operations=20 J completed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs= p;&nbsp;&nbsp;&nbsp;&nbsp;=20,! 242<BR>&nbsp;&nbsp;&nbsp; Owner = . process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20' "SYMBIONT_4"&nbsp;&nbsp;&nbsp; Owner=20eJ UIC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=J p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;=20, [1,4]<BR>&nbsp;&nbsp;&nbsp; Owner process=20I ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20A00499&nbsp;&nbsp;&nbsp; =  Dev=20J Prot&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;=204 S:RWPL,O:RWPL,G,W<BR>&nbsp;&nbsp;&nbsp; Reference=20J count&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;&nbsp;&nbsp;&nbsp;=20 % 1&nbsp;&nbsp;&nbsp; Default buffer=20,J size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=$ sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 80<BR></FONT></DIV>tC <DIV><FONT face=3DArial size=3D2>Jim Strehlow, Data911</FONT></DIV>o4 <DIV><FONT face=3DArial size=3D2>&nbsp;</DIV></FONT> <BLOCKQUOTE=20C style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = 3 BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">y$   <DIV>"Barry Treahy, Jr." &lt;<A=20D   href=3D"mailto:Treahy@mmaz.com">Treahy@mmaz.com</A>&gt; wrote in =
 message <A=20    =aJ href=3D"news:3CE454A5.6030704@mmaz.com">news:3CE454A5.6030704@mmaz.com</A=
 >...</DIV>=   <BLOCKQUOTE cite=3Dmid:ac1heb$jcs@dispatch.concentric.net =wJ type=3D"cite"><PRE wrap=3D"">How about showing your full queue settings, =/ so that we can see how you are defaulting the =r0 library?<BR><BR>Barry<BR><BR></PRE></BLOCKQUOTE>=   <BLOCKQUOTE cite=3Dmid:ac1heb$jcs@dispatch.concentric.net =e4 type=3D"cite"><PRE wrap=3D"">"John E. Malmberg" <A = class=3Dmoz-txt-link-rfc2396E =mI href=3D"mailto:wb8tyw@qsl.network">&lt;wb8tyw@qsl.network&gt;</A> wrote = 0 in message<BR><A class=3Dmoz-txt-link-freetext =J href=3D"news:3CE46054.7020300@qsl.network">news:3CE46054.7020300@qsl.netw= ork</A>...<BR></PRE>F     <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Jim Strehlow wrote:<BR> =A &gt; We have a problem converting one site from a MicroVAX 3100 =.H OpenVMS<BR> &gt; v5.5-2H4 to OpenVMS Alpha DS20 OpenVMS v7.2 regarding =H printing.<BR> &gt;<BR> &gt; Print queues print properly to HP laserjet =I 4000 and 4050 on the VAX<BR> &gt; using the next library. When I copied =aI that library to the Alpha and<BR> &gt; initialized print queues similar =-J to what was on the VAX, the printed<BR> &gt; jobs begin in the middle of =/ the page, 1/4 way down, 3/4 of the way<BR> &gt;tJ ; down the page, all over the place. When two different people print<BR> =@ &gt; to the same printer, their print jobs commingle and print =F within<BR> &gt; each other. It is a mess.<BR><BR>Comingling of print =B jobs usually means a handshake problem on a serial<BR>link, or a =F firmware problem on the printer for a network connection.<BR><BR>The =J other thing to verify is that the print queue is actually being<BR>used, =D and that programs that are supposed to be writing to the spooled&lt;J br&gt;device are not writing directly to the printer.<BR><BR>Is this LAT =H to a parallel port or a serial port?<BR><BR>As far as jobs starting in =H the wrong place, it could be the above also.<BR><BR>One thing that was =I found is that some HP Laserjets print from the bottom<BR>of the page to = I the top.  If the document has the wrong page size, then<BR>all sorts of =lH interesting things happen.  But that is something that gets<BR>noticed =H when you change printers, not hosts.<BR><BR>If the VAX can still print = correctly, theH n I would suspect that<BR>something did not get set up as you expected =; with the print queues on<BR>the Alpha.<BR><BR>-John<BR><A = " class=3Dmoz-txt-link-abbreviated =G href=3D"mailto:wb8tyw@qsl.network">wb8tyw@qsl.network</A><BR>Personal = - Opinion Only<BR><BR></PRE></BLOCKQUOTE><PRE =o: wrap=3D""><!----><BR><BR><BR></PRE></BLOCKQUOTE><BR><PRE =1 class=3Dmoz-signature cols=3D"$mailwrapcol">--=20p  F Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO=20  - E-mail: <A class=3Dmoz-txt-link-abbreviated =m> href=3D"mailto:Treahy@mmaz.com">Treahy@mmaz.com</A> * Phone: =A 480/314-1320 * FAX: 480/661-7028</PRE></BLOCKQUOTE></BODY></HTML>   - ------=_NextPart_000_0009_01C1FD80.1B323140--@   ------------------------------  % Date: Fri, 17 May 2002 10:04:22 -0700s+ From: "Barry Treahy, Jr." <Treahy@mmaz.com>g= Subject: Re: vax/alpha print to hp laser printers help neededl' Message-ID: <3CE53816.7000905@mmaz.com>o  & --------------0801080201030709040100099 Content-Type: text/plain; charset=us-ascii; format=flowed  Content-Transfer-Encoding: 7bitm  F   For starters, with any type of laser printer that can accept binary H input, I would set the default to NOFEED to prevent the automatic FF in I the middle of a data stream.  Additionally, since you are connected to a .I terminal server, I'm assuming it is a serial port.  We had problems with  C buffer overruns on serial graphic devices and queues so we set our jF queues to /NORECORD so that individual records were not buffered into ; larger blocks which often overflowed the printer buffers...i   Perhaps that might help...   Barry   & ps. Jim, your e-mail address is hosed:  A    ----- The following addresses had permanent fatal errors -----l <JimStrehlow@data911.com>e;     (reason: 550 <JimStrehlow@data911.com>... User unknown)d         Jim Strehlow wrote:r   > $ show queue/all/device/full > ... G > Terminal queue LTA999, idle, on NODENM::LTA999:, mounted form DEFAULTb0 >  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) >e- >  /LIBRARY=PWRK$DEVCTL_HP_LASERJET Lowercaset >.! >  /OWNER=[1,4] /PROCESSOR=LATSYMh >r. >  /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR >. >    >e > $ show queue/forms/fulle; > Form name                            Number   Descriptiono; > ---------                            ------   ----------- F > DEFAULT                                   0   System-defined defaultG >     /LENGTH=66 /MARGIN=(BOTTOM=6) /STOCK=DEFAULT /TRUNCATE /WIDTH=132  >  >  r >n > $ show device/full lta999m >g? > Terminal LTA999:, device type unknown, is online, allocated, t > record-orientedi= >     device, carriage control, device is spooled through an e > intermediate device. >t >  l >n5 >     Error count                    0    Operations t > completed                2420 >     Owner process       "SYMBIONT_4"    Owner # > UIC                         [1,4] @ >     Owner process ID        20A00499    Dev Prot               > S:RWPL,O:RWPL,G,W 9 >     Reference count                1    Default buffer i > size                  80 >m > Jim Strehlow, Data911g >d >  s >mE >     "Barry Treahy, Jr." <Treahy@mmaz.com <mailto:Treahy@mmaz.com> > 9 >     wrote in message news:3CE454A5.6030704@mmaz.com ...  >ed >>How about showing your full queue settings, so that we can see how you are defaulting the library? >> >>Barry  >>: >>"John E. Malmberg" <wb8tyw@qsl.network> wrote in message& >>news:3CE46054.7020300@qsl.network... >> >>>Jim Strehlow wrote:H >>> > We have a problem converting one site from a MicroVAX 3100 OpenVMSE >>> > v5.5-2H4 to OpenVMS Alpha DS20 OpenVMS v7.2 regarding printing.h >>> >uI >>> > Print queues print properly to HP laserjet 4000 and 4050 on the VAXlI >>> > using the next library. When I copied that library to the Alpha andiJ >>> > initialized print queues similar to what was on the VAX, the printedH >>> > jobs begin in the middle of the page, 1/4 way down, 3/4 of the way >>> >7G >>>; down the page, all over the place. When two different people printTF >>> > to the same printer, their print jobs commingle and print within >>> > each other. It is a mess.  >>>eI >>>Comingling of print jobs usually means a handshake problem on a serialaG >>>link, or a firmware problem on the printer for a network connection.t >>>iF >>>The other thing to verify is that the print queue is actually beingA >>>used, and that programs that are supposed to be writing to the  >>> spooled<5 >>>br>device are not writing directly to the printer.  >>> 3 >>>Is this LAT to a parallel port or a serial port?w >>>eJ >>>As far as jobs starting in the wrong place, it could be the above also. >>>kK >>>One thing that was found is that some HP Laserjets print from the bottomcI >>>of the page to the top.  If the document has the wrong page size, thenoK >>>all sorts of interesting things happen.  But that is something that getsh/ >>>noticed when you change printers, not hosts.r >>>t, >>>If the VAX can still print correctly, the >>>n I would suspect that,H >>>something did not get set up as you expected with the print queues on
 >>>the Alpha.i >>>e >>>-John >>>wb8tyw@qsl.networkt >>>Personal Opinion Only >>>C >> >> >> >5 >--  > A >Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO l > B >E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028 >i >oI >------------------------------------------------------------------------  >I4 >----------------------------------------- (on MML2) >t/ >[AZ] email-body was scanned and no virus found-/ >[AZ] email-body was scanned and no virus foundm: >--------------------------------------------------------- >i   -- S  @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028c        & --------------080108020103070904010009) Content-Type: text/html; charset=us-asciis Content-Transfer-Encoding: 7bitC   <html> <head> </head>  <body>N    For starters, with any type of laser printer that can accept binary input, K I would set the default to NOFEED to prevent the automatic FF in the middle S of a data stream. &nbsp;Additionally, since you are connected to a terminal server,eO I'm assuming it is a serial port. &nbsp;We had problems with buffer overruns oneK serial graphic devices and queues so we set our queues to /NORECORD so thatiN individual records were not buffered into larger blocks which often overflowed the printer buffers...<br> <br>  Perhaps that might help...<br>  <br>
  Barry<br> <br>* ps. Jim, your e-mail address is hosed:<br> <br>N <pre wrap="">   ----- The following addresses had permanent fatal errors -----j <a class="moz-txt-link-rfc2396E" href="mailto:JimStrehlow@data911.com">&lt;JimStrehlow@data911.com&gt;</a>     (reason: 550 <a class="moz-txt-link-rfc2396E" href="mailto:JimStrehlow@data911.com">&lt;JimStrehlow@data911.com&gt;</a>... User unknown)   </pre> <br> <br>  Jim Strehlow wrote:<br>F <blockquote type="cite" cite="mid:ac38v1$qpn@dispatch.concentric.net">9   <meta content="MSHTML 6.00.2716.2200" name="GENERATOR">E   <style></style>UC   <div><font face="Arial" size="2">$ show queue/all/device/full<br>o  ...<br>L  Terminal  queue LTA999, idle, on NODENM::LTA999:, mounted form  DEFAULT<br>B  &nbsp;/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) </font></div>a   <div><font face="Arial" size="2">&nbsp;/LIBRARY=PWRK$DEVCTL_HP_LASERJET  Lowercase</font></div> T   <div><font face="Arial" size="2">&nbsp;/OWNER=[1,4] /PROCESSOR=LATSYM</font></div>b   <div><font face="Arial" size="2">&nbsp;/PROTECTION=(S:M,O:D,G:R,W:S)  /RETAIN=ERROR</font></div>   <div>&nbsp;</div>n>   <div><font face="Arial" size="2">$ show queue/forms/full<br>  Form  name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  Number&nbsp;&nbsp;  Description<br>  ---------&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  ------&nbsp;&nbsp;  -----------<br>w  DEFAULT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  0&nbsp;&nbsp; System-defined default<br>c  &nbsp;&nbsp;&nbsp; /LENGTH=66  /MARGIN=(BOTTOM=6) /STOCK=DEFAULT /TRUNCATE /WIDTH=132</font></div>o   <div>&nbsp;</div>mI   <div><font face="Arial" size="2">$ show device/full lta999</font></div>rJ   <div><font face="Arial" size="2">Terminal LTA999:, device type unknown, * is online,  allocated, record-oriented<br>Y  &nbsp;&nbsp;&nbsp; device, carriage control,  device is spooled through an intermediate a device.</font></div>   <div>&nbsp;</div>i   <div><font face="Arial" size="2">&nbsp;&nbsp;&nbsp; Error  count&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  0&nbsp;&nbsp;&nbsp; x Operations  completed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  242<br> &nbsp;&nbsp;&nbsp; Owner process&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  "SYMBIONT_4"&nbsp;&nbsp;&nbsp; Owner  UIC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A
  [1,4]<br>  &nbsp;&nbsp;&nbsp; Owner process  ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 20A00499&nbsp;&nbsp;&nbsp; Dev  Prot&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  S:RWPL,O:RWPL,G,W<br>u &nbsp;&nbsp;&nbsp; Reference  count&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  1&nbsp;&nbsp;&nbsp; Default buffer  size&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;    80<br>r   </font></div>AE   <div><font face="Arial" size="2">Jim Strehlow, Data911</font></div>a6   <div><font face="Arial" size="2">&nbsp;</font></div>   <blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0,0,0); margin-right: 0px; ">U     <div>"Barry Treahy, Jr." &lt;<a href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a>.b  &gt; wrote in message <a href="news:3CE454A5.6030704@mmaz.com">news:3CE454A5.6030704@mmaz.com</a>
  ...</div>J     <blockquote cite="mid:ac1heb$jcs@dispatch.concentric.net" type="cite">       <pre wrap="">How about showing your full queue settings, so that we can see how you are defaulting the library?<br><br>Barry<br><br></pre>       </blockquote>AL       <blockquote cite="mid:ac1heb$jcs@dispatch.concentric.net" type="cite">        <pre wrap="">"John E. Malmberg" <a class="moz-txt-link-rfc2396E" href="mailto:wb8tyw@qsl.network">&lt;wb8tyw@qsl.network&gt;</a> wrote in message<br><a class="moz-txt-link-freetext" href="news:3CE46054.7020300@qsl.network">news:3CE46054.7020300@qsl.network</a>...<br></pre>3          <blockquote type="cite">           <pre wrap="">Jim Strehlow wrote:<br> &gt; We have a problem converting one site from a MicroVAX 3100 OpenVMS<br> &gt; v5.5-2H4 to OpenVMS Alpha DS20 OpenVMS v7.2 regarding printing.<br> &gt;<br> &gt; Print queues print properly to HP laserjet 4000 and 4050 on the VAX<br> &gt; using the next library. When I copied that library to the Alpha and<br> &gt; initialized print queues similar to what was on the VAX, the printed<br> &gt; jobs begin in the middle of the page, 1/4 way down, 3/4 of the way<br> &gt;<br>; down the page, all over the place. When two different people print<br> &gt; to the same printer, their print jobs commingle and print within<br> &gt; each other. It is a mess.<br><br>Comingling of print jobs usually means a handshake problem on a serial<br>link, or a firmware problem on the printer for a network connection.<br><br>The other thing to verify is that the print queue is actually being<br>used, and that programs that are supposed to be writing to thee    spooled&lt;<br>br&gt;device are not writing directly to the printer.<br><br>Is this LAT to a parallel port or a serial port?<br><br>As far as jobs starting in the wrong place, it could be the above also.<br><br>One thing that was found is that some HP Laserjets print from the bottom<br>of the page to the top.  If the document has the wrong page size, then<br>all sorts of interesting things happen.  But that is something that gets<br>noticed when you change printers, not hosts.<br><br>If the VAX can still print correctly, the<br>n I would suspect that<br>something did not get set up as you expected with the print queues on<br>the Alpha.<br><br>-John<br><a class="moz-txt-link-abbreviated" href="mailto:wb8tyw@qsl.network">wb8tyw@qsl.network</a><br>Personal Opinion Only<br><br></pre>b           </blockquote>"0           <pre wrap=""><!----><br><br><br></pre>           </blockquote>&           <br>          <pre class="moz-signature" cols="$mailwrapcol">-- <br><br>Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO <br><br>E-mail: <a class="moz-txt-link-abbreviated" href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a> * Phone: 480/314-1320 * FAX: 480/661-7028</pre>s           </blockquote>0          <pre wrap=""><br><hr width="90%" size="4"><br>----------------------------------------- (on MML2)<br><br>[AZ] email-body was scanned and no virus found<br>[AZ] email-body was scanned and no virus found<br>---------------------------------------------------------<br></pre>           </blockquote>=           <br><           <pre class="moz-signature" cols="$mailwrapcol">--   D Barry Treahy, Jr  *  Midwest Microwave  *  Vice President &amp; CIO    E-mail: <a class="moz-txt-link-abbreviated" href="mailto:Treahy@mmaz.com">Treahy@mmaz.com</a> * Phone: 480/314-1320 * FAX: 480/661-7028</pre>V           <br>           <br>           </body>e           </html>y  ( --------------080108020103070904010009--   ------------------------------  % Date: Fri, 17 May 2002 10:54:01 +0100cU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>eH Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?0 Message-ID: <ac2kea$4l0$1@new-usenet.uk.sun.com>   Bill Sticker wrote:<  % > "Andrew Harrison SUNUK Consultancy"e@ > <andrew_nospam.harrison_remove_this@sun#.com> wrote in message, > news:ac0dmn$f3a$1@new-usenet.uk.sun.com... >  >># >>Steve.Spires@yellgroup.com wrote:s >> >>H >>>I don't know what the truth of this is, but why would an organisation >>>n > whoe > E >>>don't have OpenVMS in their future plans invest the time and moneynI >>>upgrading the OS and buying in some larger machines, only to be movingm >>>h > offt > E >>>the platform? With apparent 'stupidity' like that, any wonder they. >>>n	 > screwed; > F >>>the upgrade? And why have they upgraded their nodes without testing >>>& > first? > E >>>And if your staff screw up, why do you then ditch the hardware ands >>>software? >>>y >>>n >>C >>The plan to upgrade to 7.3 was put in place because Compaq wantede= >>to upgrade the GS320's to GS140's. Blaming the customer forbA >>initiating an upgrade in this circumstance seems to be pointingB! >>the finger at the wrong person.  >>D >>The problems that they ran into were not with the process of doingB >>the upgrade but with bugs that they found once they had done it. >> > K > When you upgrade a Sun, do you test it beforehand? Do you let someone whoo > doesntL > know the operating system, or read the release notes do it? Have you never	 > in your B > career, been assited by the vendor in a critical system upgrade?L > You are talking rubbish. It is clearly the fault of the person who did the > upgrade for nottI > doing it properly, and his/her management for not implementing suitableo > change control.>
 > Cowboys!N > On a critical system this could constitute a crime under the data protection > act. >     C The upgrade worked fine, however under load they had a crash causedt by bugs in 7.3.f  = They do have a test system but its much much smaller than then production cluster.e  C In case you hadn't noticed not all bugs appear during or imediatelye@ after the installation or upgrade to a new OS, XFC issue where I< think more evident under load and there are lots of examples of load or useage related bugs.e       Regardsh Andrew HarrisonR   ------------------------------  % Date: Fri, 17 May 2002 11:03:05 +0100rU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>oH Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?0 Message-ID: <ac2kvb$4pa$1@new-usenet.uk.sun.com>   Roy Omond wrote:  * > Andrew Harrison SUNUK Consultancy wrote: >  > # >>Steve.Spires@yellgroup.com wrote:m >> >>L >>>I don't know what the truth of this is, but why would an organisation whoE >>>don't have OpenVMS in their future plans invest the time and money0M >>>upgrading the OS and buying in some larger machines, only to be moving off M >>>the platform? With apparent 'stupidity' like that, any wonder they screwed:M >>>the upgrade? And why have they upgraded their nodes without testing first?0E >>>And if your staff screw up, why do you then ditch the hardware ande >>>software? >>>s >>>iC >>The plan to upgrade to 7.3 was put in place because Compaq wanted = >>to upgrade the GS320's to GS140's. Blaming the customer forIA >>initiating an upgrade in this circumstance seems to be pointingh! >>the finger at the wrong person.n >>D >>The problems that they ran into were not with the process of doingB >>the upgrade but with bugs that they found once they had done it. >>B >>Sure people should test their systems but in this case they were? >>doing tests for their vendor. Again finger pointing mostly ine >>the wrong direction. >> > & > OK, I'll bite (I can smell the rat). > H > You'd not be breaking any confidentiality if you'd reveal to all of us > what these "bugs" were.r >     < I don't get the call reports but the manager responsible for> the GS140's told me that one of them was an OpenVMS HBA driver issue.    E > I simply do not believe you, and I'm not sure I'd believe that evenTC > a bank could display such gross incompetence and sheer stupidity.= >     A This discussion is a perfect illustration of the double standards=. that seems afflict many posters to this group.  @ On one hand posters are only to happy to trumpet the latest UNIXA issue they have heard about second hand, no though of complaining E that it isn't so much a UNIX bug as stupidity on the admin/management 1 side to put the buggy code on in the first place.d  A On the other hand OpenVMS 7.3 has a snagging list as long as your/D arm but anyone afflicted by the snags (as in this case) is according; to the posters here a dolt for installing 7.3 without fullyo testing it.   ? You cannot have it both ways, either Solaris bugs are not Sun'sn= fault but the fault of the people who install them as in your < argument in favour of OpenVMS or they are Sun's fault as you are only to happy to claim.N  @ I am for Sun accepting responsibility for buggy SW as you should@ be with Compaq, so less of the BS about users not doing adequate> tests if you know anything about testing you will realise that: it is almost impossible for most users to fully test their) system before putting it into production.T   Regardsc Andrew Harrison@    B > C'mon Andrew, spill some more beans, or else admit that you made > this cock-and-bull story up. >  >  >>>Glad I don't work there...h >>>u >>>d@ >>Probably a good call on your part, unless you have UNIX skills0 >>because they are trying to get rid of OpenVMS. >> > = > Glad I don't work there too, and I have plenty UNIX skills.r >  > Roy Omondo > Blue Bubble Ltd. >  >  >    ------------------------------  % Date: Fri, 17 May 2002 13:13:06 +0200h= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> H Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?) Message-ID: <3CE4E5C2.6581B165@gtech.com>r  ( Andrew Harrison SUNUK Consultancy wrote:C > The plan to upgrade to 7.3 was put in place because Compaq wanted $ > to upgrade the GS320's to GS140's.   ????   Upgrade from GS320 to GS140 ?e  : That sound like upgrading from a SUN 10000 to a SUN 4500 !   :-)l   Arne   ------------------------------  % Date: Fri, 17 May 2002 12:22:51 +0100jU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>hH Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?0 Message-ID: <ac2pkt$61p$2@new-usenet.uk.sun.com>   Arne Vajhj wrote:  * > Andrew Harrison SUNUK Consultancy wrote: > C >>The plan to upgrade to 7.3 was put in place because Compaq wanted $ >>to upgrade the GS320's to GS140's. >> >  > ???? >  > Upgrade from GS320 to GS140 ?n > < > That sound like upgrading from a SUN 10000 to a SUN 4500 ! >  > :-)a    3 It was a typo although as you know some people havee. found GS140's to be faster than GS320's :):):)     Regards  Andrew Harrisonn   ------------------------------  # Date: Fri, 17 May 2002 17:23:37 GMTe5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> H Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?9 Message-ID: <t0bF8.27$C54.574552@cacnews.cac.cpqcorp.net>   ! Bill Sticker wrote in message ...8 >@ >.J >When you upgrade a Sun, do you test it beforehand? Do you let someone who >doesnt < >know the operating system, or read the release notes do it?  I Uh, you can't "upgrade" to a Sun... there isn't an "up" in that movement.-   ------------------------------  + Date: Fri, 17 May 2002 17:29:14 +0000 (UTC)-5 From: "Bill Sticker" <NOSPAMPLEASE@SPAMSTOPPER.CO.UK>iH Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?1 Message-ID: <ac3ela$g9i$1@knossos.btinternet.com>-  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message3 news:t0bF8.27$C54.574552@cacnews.cac.cpqcorp.net...m# > Bill Sticker wrote in message ...4 > >1 > >cL > >When you upgrade a Sun, do you test it beforehand? Do you let someone who	 > >doesnti> > >know the operating system, or read the release notes do it? >bK > Uh, you can't "upgrade" to a Sun... there isn't an "up" in that movement.i >t   You cant read.   >a >  >N >E >o   ------------------------------  % Date: Fri, 17 May 2002 11:01:05 -0400l! From: Jim Agnew <jpagnew@vcu.edu>r: Subject: VMS GKS Manuals for giveaway in Richmond, VA area' Message-ID: <3CE51B31.64C3A505@vcu.edu>i  0 I have the CD's now, and need the shelf space...  E I didn't give up my manuals 'til I had 2 - 3 systems all capabable ofo reading the cd's...  ;-)  G Is there a PC version of the bookreader or mgbook ??  Or, HTML versions  of the v5.5-2 manuals?   Jim    ------------------------------  % Date: Fri, 17 May 2002 18:16:04 +0100rU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>i' Subject: Re: Who cares about marketing!t0 Message-ID: <ac3eb5$ccj$1@new-usenet.uk.sun.com>   John Smith wrote:f  7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageo> > news:6QfE8.178251$q8.18022723@bin3.nnrp.aus1.giganews.com... >  >>L >>*After* DEC fell from grace, *then* the kinds of things you describe aboveJ >>*did* become problems, and marketing could have helped (though not saved >> > DECo > K >>unless the other, more basic, internal problems had been solved as well).q >> >> > N > Wrong. These were exactly the things that CAUSED the 'fall from grace'.  TheK > crap Sun was selling at the time couldn't hold a technical candle to what&K > DEC could and was delivering technically. But Sun ate DEC's lunch becausefK > they did ALL the things that constitute marketing well - and in my books,vL > marketing starts with the CEO and the Board of Directors and permeates the > whole organization >     7 Depends what you mean by holding a technical candle to.o  D Sun was a workstation company, Sun Workstations did hold a technicalD candle to Digital ones. They were faster, smaller cheaper and better> made, I know this may be difficult to accept but I have taken B DECstations and  obviously things like SPARCstation 1s apart. The C DECstation was a mess loads of cables, soldered jumpers on the main;H PCB etc the SS1 was a much better design from an engineering standpoint.  E If you want an example closer to home I remember taking a DEC RainbowsC appart, it was a beautifull peice of engineering when compared withnF the boxes that IBM and the other Intel systems vendors were producing,3 same comparison between the SS1 and the DECstation.t  D Sun didn't really have much of a server range until the SPARCcenter D 2000/1000s came out and later the Sun E3500-E10000 but that was when- we re-invented ourselves as a server company.9  ? By the time the E3500-E10000 came out Sun was designing Servers,A that were also more capable technically than the equivalent Alpha  server.b  # Faster, smaller, more RAS, cheaper.v   Regardsl Andrew Harrisone   ------------------------------  % Date: Fri, 17 May 2002 13:11:13 +0200A= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>; Subject: Re: Worth a reads) Message-ID: <3CE4E551.BE17430D@gtech.com>;  
 Jon wrote:> > "Brian Tillman" <tillman_brian@notnoone.notnohow.com> wrote:" > >>I just came across this today. > >b6 > >They should have outsourced it to Process Software. >  > I agree !!  ( There are technical capable of doing it.  . But IPR issues could have become rather messy.  6 (IPR = "Intellectual Property Rights" in this context)   Arne   ------------------------------  % Date: Fri, 17 May 2002 07:52:51 -0400 5 From: David Beatty <David.Beatty@qwertysasasdfgh.com>& Subject: Re: Worth a readp2 Message-ID: <2+7kPM8TCR76I9pTB96D8Ul0kd2=@4ax.com>  0 In the V4.0 and V4.1 days of UCX, didn't Digital* partner with Process on the development of that IP stack?   David R. Beattyt  3 On Thu, 16 May 2002 11:11:11 -0400, "Brian Tillman"n, <tillman_brian@notnoone.notnohow.com> wrote:    >>I just came across this today. >s4 >They should have outsourced it to Process Software.   ------------------------------  % Date: Fri, 17 May 2002 02:16:27 -0400v  From: John Santos <JOHN@egh.com>Y Subject: Re: [Q] How do you set the SQO bit in the FAB (FAB, RAB, which field has this bib4 Message-ID: <1020517021026.352A-100000@Ives.egh.com>  & On 16 May 2002, Alan E. Feldman wrote:  O > mckinneyj@cpva.saic.com wrote in message news:<zFiI6sOlMClM@cpva.saic.com>... A > > In article <343f30ae.0205160637.696685b4@posting.google.com>,a5 > >  SPAMSINK2001@YAHOO.COM (Alan E. Feldman) writes:3 > > > Hello, > > > % > > > My question is after the quote.  > > > : > > > (Jim.Johnson@software-exploration.nospam.com) wrote: > > >  > > > [begin quote]e > > > Alan,a > > > F > > > You've just encountered the SQO optimization for DAP/FAL in RMS. > > > K > > > SQO (Sequential-only) is a bit set in the FAB on open when the callereJ > > > knows that it will never randomly read a record.  TYPE knows that isK > > > the case, and '@' knows it isn't (e.g. handling of GOSUBs and GOTOs).n > > > J > > > For the network access, SQO is used to initiate a bulk data transferL > > > protocol that doesn't send back any ACK messages until the eof is hit.E > > > This means that the server can pack in as many data messages ase< > > > possible, and just keep sending them until it is done. > > > J > > > If SQO isn't used, then a much slower protocol that is essentially a/ > > > request-response pair per record is used.  > > > * > > > That's the difference you're seeing. > > > [end quote]  > > >  > > > L > > > OK, how do you do that? I found an example, UFO_CONTIG.FOR, in SectionL > > > 8.6.1.3 of the VMS v6.2 Programming Concepts Manual, which is fine forL > > > setting the file to be contiguous. And I showed this to our developer.L > > > He asked on how to find the mnemonic, which field, what symbolic name,0 > > > from where, etc., has this SQO bit to set. > > > 
 > > > Thanks.e > > >  > > > Disclaimer: JMHO > > > Alan E. Feldmany( > > > afeldman atski gfigroup dotski com > >  > > C > > Using that particular example code you should be able to insertt > > 4 > > FAB.FAB$L_FOP = IBSET (FAB.FAB$L_FOP, FAB$V_SQO) > > F > > You can examine the values of the symbols by looking in FORSYSDEF. > > F > > $ pipe libr/extr=$fabdef/out=sys$output: sys$share:forsysdef.tlb - > >   | sear sys$pipe sqoa >  > F > Thanks. But I forgot to mention that we are using Pascal and that we= > don't have Fortran. Also, we are running VMS v6.1 and v6.2.s >  > Also,  > & > $ sl sys$share  ! sl := show logicalD >    "SYS$SHARE" = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)$ sh def >   SYS$SYSROOT:[SYSLIB] >   =   SYS$SYSROOT:[SYSLIB] >   =   SYS$COMMON:[SYSLIB]s
 > $ d .tlb >  b > Directory SYS$COMMON:[SYSLIB]r >  y? > EPC$FACILITY.TLB;3         12/18      17-OCT-1991 13:39:48.18s? > ERFLIB.TLB;2              102/108      6-MAR-1996 00:05:37.17<? > STARLETSD.TLB;2          4560/4563     6-MAR-1996 00:05:40.01t >  >% > Total of 3 files, 4674/4689 blocks.i> > $  libr/extr=$fabdef/out=sys$output: sys$share:starletsd.tlb2 > %LIBRAR-E-LOOKUPERR, error looking up $FABDEF in$ > SYS$COMMON:[SYSLIB]STARLETSD.TLB;2! > -LBR-E-KEYNOTFND, key not foundl; > $  libr/extr=$fabdef/out=sys$output: sys$share:erflib.tlb 2 > %LIBRAR-E-LOOKUPERR, error looking up $FABDEF in! > SYS$COMMON:[SYSLIB]ERFLIB.TLB;2l! > -LBR-E-KEYNOTFND, key not found<> > $  libr/extr=$fabdef/out=sys$output: sys$share:starletsd.tlb2 > %LIBRAR-E-LOOKUPERR, error looking up $FABDEF in$ > SYS$COMMON:[SYSLIB]STARLETSD.TLB;2! > -LBR-E-KEYNOTFND, key not foundr > C > Where else might this $fabdef be? Any furter guidance is welcome.s	 > Thanks.d  ? For MACRO, it's in SYS$LIBRARY:STARLET.MLB.  For BASIC, it's in-@ BASIC$STARLET.TLB.  I don't know about Pascal, but if installingC it makes a system definitions library (this is optional for BASIC),a it should be there.c  = If you have a sample Pascal program that sets RMS options, it- should show you where to look.  @ Our you could write a trivial little macro routine that sets the@ bit, and pass it the FAB.  (BASIC has a "useropen" clause on itsA file open and create statements that allows for this.  Don't know ! if Pascal has something similar.)    > Disclaimer: JMHO > Alan E. Feldmanr$ > afeldman atski gfigroup dotski com   -- _ John Santoso Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 17 May 02 06:37:56 PST From: mckinneyj@cpva.saic.com Y Subject: Re: [Q] How do you set the SQO bit in the FAB (FAB, RAB, which field has this bi_( Message-ID: <$ufktgHfrHID@cpva.saic.com>  4 In article <1020517021026.352A-100000@Ives.egh.com>,#  John Santos <JOHN@egh.com> writes: ( > On 16 May 2002, Alan E. Feldman wrote: > P >> mckinneyj@cpva.saic.com wrote in message news:<zFiI6sOlMClM@cpva.saic.com>...B >> > In article <343f30ae.0205160637.696685b4@posting.google.com>,6 >> >  SPAMSINK2001@YAHOO.COM (Alan E. Feldman) writes:
 >> > > Hello,e >> > > ?& >> > > My question is after the quote. >> > > t; >> > > (Jim.Johnson@software-exploration.nospam.com) wrote:  >> > > t >> > > [begin quote] >> > > Alan, >> > >  G >> > > You've just encountered the SQO optimization for DAP/FAL in RMS.  >> > > rL >> > > SQO (Sequential-only) is a bit set in the FAB on open when the callerK >> > > knows that it will never randomly read a record.  TYPE knows that is>L >> > > the case, and '@' knows it isn't (e.g. handling of GOSUBs and GOTOs). >> > > rK >> > > For the network access, SQO is used to initiate a bulk data transfer M >> > > protocol that doesn't send back any ACK messages until the eof is hit.>F >> > > This means that the server can pack in as many data messages as= >> > > possible, and just keep sending them until it is done.r >> > > tK >> > > If SQO isn't used, then a much slower protocol that is essentially a 0 >> > > request-response pair per record is used. >> > > s+ >> > > That's the difference you're seeing.  >> > > [end quote] >> > > t >> > > ,M >> > > OK, how do you do that? I found an example, UFO_CONTIG.FOR, in SectionoM >> > > 8.6.1.3 of the VMS v6.2 Programming Concepts Manual, which is fine fortM >> > > setting the file to be contiguous. And I showed this to our developer.cM >> > > He asked on how to find the mnemonic, which field, what symbolic name,s1 >> > > from where, etc., has this SQO bit to set.o >> > > n >> > > Thanks. >> > > r >> > > Disclaimer: JMHOf >> > > Alan E. Feldman) >> > > afeldman atski gfigroup dotski comn >> > e >> > uD >> > Using that particular example code you should be able to insert >> >  5 >> > FAB.FAB$L_FOP = IBSET (FAB.FAB$L_FOP, FAB$V_SQO)- >> > -G >> > You can examine the values of the symbols by looking in FORSYSDEF.o >> > cG >> > $ pipe libr/extr=$fabdef/out=sys$output: sys$share:forsysdef.tlb -g >> >   | sear sys$pipe sqo >> m >> iG >> Thanks. But I forgot to mention that we are using Pascal and that wer> >> don't have Fortran. Also, we are running VMS v6.1 and v6.2. >> p	 >> Also, o >> m' >> $ sl sys$share  ! sl := show logicaleE >>    "SYS$SHARE" = "SYS$SYSROOT:[SYSLIB]" (LNM$SYSTEM_TABLE)$ sh defn >>   SYS$SYSROOT:[SYSLIB]n >>   =   SYS$SYSROOT:[SYSLIB]g >>   =   SYS$COMMON:[SYSLIB] >> $ d .tlbh >>    >> Directory SYS$COMMON:[SYSLIB] >>  @ >> EPC$FACILITY.TLB;3         12/18      17-OCT-1991 13:39:48.18@ >> ERFLIB.TLB;2              102/108      6-MAR-1996 00:05:37.17@ >> STARLETSD.TLB;2          4560/4563     6-MAR-1996 00:05:40.01 >>  & >> Total of 3 files, 4674/4689 blocks.? >> $  libr/extr=$fabdef/out=sys$output: sys$share:starletsd.tlb 3 >> %LIBRAR-E-LOOKUPERR, error looking up $FABDEF ins% >> SYS$COMMON:[SYSLIB]STARLETSD.TLB;2t" >> -LBR-E-KEYNOTFND, key not found< >> $  libr/extr=$fabdef/out=sys$output: sys$share:erflib.tlb3 >> %LIBRAR-E-LOOKUPERR, error looking up $FABDEF in>" >> SYS$COMMON:[SYSLIB]ERFLIB.TLB;2" >> -LBR-E-KEYNOTFND, key not found? >> $  libr/extr=$fabdef/out=sys$output: sys$share:starletsd.tlb 3 >> %LIBRAR-E-LOOKUPERR, error looking up $FABDEF in % >> SYS$COMMON:[SYSLIB]STARLETSD.TLB;2 " >> -LBR-E-KEYNOTFND, key not found >> .D >> Where else might this $fabdef be? Any furter guidance is welcome.
 >> Thanks. > A > For MACRO, it's in SYS$LIBRARY:STARLET.MLB.  For BASIC, it's inmB > BASIC$STARLET.TLB.  I don't know about Pascal, but if installingE > it makes a system definitions library (this is optional for BASIC),n > it should be there.t > ? > If you have a sample Pascal program that sets RMS options, iti  > should show you where to look. > B > Our you could write a trivial little macro routine that sets theB > bit, and pass it the FAB.  (BASIC has a "useropen" clause on itsC > file open and create statements that allows for this.  Don't know # > if Pascal has something similar.)  >  >> Disclaimer: JMHOp >> Alan E. Feldman% >> afeldman atski gfigroup dotski como >  > -- r
 > John Santosn > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 >   C 	Check out SYS$LIBRARY:STARLET.PAS; you'll find the FAB definitionsiA 	there. Ned Freed's old mail DELIVER program and DECUS SPELL weree@ 	both written in Pascal and make use of FABs when opening files.@ 	You might use them as examples. Looks like Brian is kind enough. 	to still have the old freeware distro online.  7 	http://www.tmesis.com/freeware/V2/DELIVER/DELIVER.PAS;    -- S - Jimp   ------------------------------  % Date: Fri, 17 May 2002 15:54:05 +0200t9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>tY Subject: Re: [Q] How do you set the SQO bit in the FAB (FAB, RAB, which field has this bie' Message-ID: <3CE50B7D.3C3AFB12@aaa.com>r  3 The complete DELIVER package can also be found at :n  < http://vms.process.com/scripts/fileserv/fileserv.com?DELIVER It's version : "17-NOV-1994"  7 The version on the link below seems to be "11-Feb-1993"a Don't know what the diffs are.  A I use DELIVER to process a couple of thousands of mails each day.. Works like a charm...t   Jan-Erik Sderholm.h     mckinneyj@cpva.saic.com wrote: > L >         Check out SYS$LIBRARY:STARLET.PAS; you'll find the FAB definitionsJ >         there. Ned Freed's old mail DELIVER program and DECUS SPELL wereI >         both written in Pascal and make use of FABs when opening files. I >         You might use them as examples. Looks like Brian is kind enoughr7 >         to still have the old freeware distro online.7 > @ >         http://www.tmesis.com/freeware/V2/DELIVER/DELIVER.PAS;   ------------------------------   End of INFO-VAX 2002.272 ************************UN 10000 to a SUN 4500 !   :-)l   Arne   ------------------------------  % Date: Fri, 17 May 2002 12:22:51 +0100jU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>hH Subject: Re: VMS 7.3 upgrade problems - a bad workman blaming his tools?0 Message-ID: <ac2pkt$61p$2@new-usenet.uk.sun.com>   Arne Vajhj wrote:  * > Andrew Harrison SUNUK Consultancy wrote: > C >>The plan t I    I    I    I    I    I    I    I    I    	I    
I    I    I    
I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I     I    !I    "I    #I    $I    %I    &I    'I    (I    )I    *I    +I    ,I    -I    .I    /I    0I    1I    2I    3I    4I    5I    6I    7I    8I    9I    :I    ;I    <I    =I    >I    ?I    @I    AI    BI    CI    DI    EI    FI    GI    HI    II    JI    KI    LI    MI    NI    OI    PI    QI    RI    SI    TI    UI    VI    WI    XI    YI    ZI    [I    \I    ]I    ^I    _I    `I    aI    bI    cI    dI    eI    fI    gI    hI    iI    jI    kI    lI    mI    nI    oI    pI    qI    rI    sI    tI    uI    vI    wI    xI    yI    zI    {I    |I    }I    ~I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    I    