1 INFO-VAX	Fri, 30 Nov 2001	Volume 2001 : Issue 665       Contents:( AEC-7720UW Ultra Wide SCSI-to-IDE BridgeO Bin Laden was Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org % comp.os.vms,gnu.emacs.vms,vmsnet.misc 9 Re: Compaqs VMS plans for IPF port ... any doubters left? ! Re: DECNET Phase IV saves the day ! Re: DECNET Phase IV saves the day ! Re: DECNET Phase IV saves the day  Re: DECnet timeout?  Re: Emacs-2[01] on VMS RE: ftp performance  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ? 4 Re: Gartner and IDC say HP will effectively kill DLT+ Re: Graphics cntrlr not recognized by 5.5-2 + Re: Graphics cntrlr not recognized by 5.5-2 5 How do you use Kermit within a VMS command procedure? 9 Re: How do you use Kermit within a VMS command procedure? 9 Re: How do you use Kermit within a VMS command procedure? 5 Re: How to use Kermit within a VMS command procedure? 
 IPF Debugged?  Re: IPF Debugged? & Just a reminder for tomorrow's webcast* Re: Just a reminder for tomorrow's webcast* Re: Just a reminder for tomorrow's webcast* Re: Just a reminder for tomorrow's webcast* Re: Just a reminder for tomorrow's webcast! Re: logical names novice question ! Re: logical names novice question F looking for HSC50, RA81, star coupler, CIPCA, various manuals & prints6 Re: New product allows VMS to become part of a PC Lan!6 Re: New product allows VMS to become part of a PC Lan! Re: new to VMS cxx question...D Re: Offtopic: cross platform portability tools - a study of autoconf. Re: OT: Andrew Harrison : Alive & Still At SUN. Re: OT: Andrew Harrison : Alive & Still At SUN2 Re: patch downloads - 3rd time lucky & compression& Re: Pawz software and Capacity Planner Re: PGP for OpenVMS  Rdb 7.0.6 and sql$070.exe  Re: RECALL does not work Re: RECALL does not work Re: RECALL does not work Re: RECALL does not work Re: RECALL does not work" Re: RECALL does not work (& XDMCP)E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org  TLZ09 E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) E RE: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer)) % Walter Hewlett's report on the merger 4 Re: why not a communityDeveloped[tm] version of VMS?4 Re: why not a communityDeveloped[tm] version of VMS?4 Re: why not a communityDeveloped[tm] version of VMS?	 Re: xdmcp 	 Re: xdmcp   F ----------------------------------------------------------------------  # Date: Fri, 30 Nov 2001 04:27:23 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>1 Subject: AEC-7720UW Ultra Wide SCSI-to-IDE Bridge @ Message-ID: <LUDN7.683348$Lg.26535246@sjcpnn01.usenetserver.com>  G Has anyone tried using an AEC-7720UW Ultra Wide SCSI-to-IDE Bridge on a L OpenVMS system?  I'm thinking this might be a nice cheap way to add a lot ofJ disk space to my PWS433au.  Information about the product can be found at:3 http://www.acard.com/eng/product/sp/aec-7720uw.html   L Basically it lets you use DMA66 & DMA100 drives as UW-SCSI drives.  It looksK to me like it should work, but I'd really like to hear that someone has had J it working before plunking down the $$$'s on one.  They list it as working" with Sun, Linux, Mac, and Windows.   			Zane    ------------------------------  % Date: Thu, 29 Nov 2001 14:15:15 -0800 $ From: Shane Smith <ssmith@icius.com>X Subject: Bin Laden was Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org0 Message-ID: <01C178E0.55CD7460@sulfer.icius.com>   > Shane Smith wrote:
 > > [snip]J > > > Ok, try to convince me that the founder and head of an internationalF >> terrorist group even deserves the courtesy of a trial.  Show me the> >> trial that condemned all the victums on September 11, 2001. >>  1 >To stop Bin Laden becoming a martyr he has to be 6 >discredited.  Over thousands of years one of the most6 >effective methods of doing this is a fair and public 7 >trial.  The judge listens to the evidence and what the  defendant says and decides.  ..etc - > Andrew Swallow (7605) 2225   Cowes site, UK  > andrew.swallow@baesystems.com   F I just wanted to point out this attribution's misleading. I didn't say/ that, I think it's from what I was replying to.    Shane    ------------------------------    Date: 29 Nov 2001 13:59:01 -0500R From: "Stefan Monnier <foo@acm.com>" <monnier+comp.os.vms/news/@flint.cs.yale.edu>. Subject: comp.os.vms,gnu.emacs.vms,vmsnet.misc, Message-ID: <5lwv099zey.fsf@rum.cs.yale.edu>  I > : It's not C that's the problem per se.  Can you say autoconfig?  Built H > : on C preprocessor dependancies that are little more than really uglyI > : unix hackery.  Everytime I rekindle my effort on this project, little F > : time is lost before my blood boils.  Targets are built in the same  @ Yes, we (Emacs maintainers) also suffer from it.  But nobody hasB had the courage (or knowledge) to do the switch to autoconf (which* would help on Unix, don't know about VMS).  I > : if the Stallman crowd had merged the VMS mods of 19.28 into the later F > : versions but, since VMS is not a unix, it might have tainted their > : precious unixy shit code.   D Seeing all the #ifdefs for MacOS, W32, MS-DOS, VMS, UnixFoo, UnixBarC etc etc ad nauseam, I doubt that "tainting" was an issue.  It might @ have been a simple oversight (or maybe lack of legal paperwork).  ) > So you have not gotten 20.x to compile?  > B > I have compiled it (eventually), but got problems with the dump.I > (Borrowing makefiles and other stuff from the most recent 19.28 on VMS. " > I think... it was some time ago)  + Did the executable work (without dumping) ? @ It would really be great to get VMS support back up and running.4 But we'd need someone who can maintain the VMS port.  . BTW, what format is this "emacs207.bck" file ?     	Stefan    ------------------------------  % Date: Thu, 29 Nov 2001 19:43:42 +0000 4 From: Andrew Swallow <andrew.swallow@baesystems.com>B Subject: Re: Compaqs VMS plans for IPF port ... any doubters left?. Message-ID: <3C068FEE.82D8BD2C@baesystems.com>  
 cjt wrote: >  > Carl Perkins wrote:  > > < > > Andrew Swallow <andrew.swallow@baesystems.com> writes... > > }John McLean wrote:  > > }> > > }> Bob Ceculski wrote: > > }[snip]  > > }> >K > > }> > Marketing also has matching funds as part of the agreement, and we K > > }> > have put a plan forward to leverage our H2 2001 marketing spending M > > }> > with Intel funds. We have a detailed communication plan rolling out, > > > }> > and are working a large number of go to market plans. > > }>I > > }> It sounds like Compaq plucking up the courage to make some kind of 4 > > }> commitment to VMS, albeit with Intel's money. > > }>; > > }Intel may be trying to escape from Microsoft, possibly  > > }as a contingency plan.  > > } : > > }Being paranoid, what instruction set does Microsoft's
 > > }Box use?  > > } 6 > > }Does it have a port that can be used to connect a7 > > }keyboard and printer?  Or are they waiting for the  > > }mark 2? > > }-- < > > }_______________________________________________________ > > }Andrew Swallow  > > ' > > The Xbox uses a 733MHz Pentium III.  > > C > > As far as I can tell (I havn't actually exampined one) the only K > > ports on the thing are the 4 game controller ports (it should be fairly K > > easy for them to make a keyboard and mouse that plugs into one of them) G > > and a 10/100 ethernet port. Yep, the Xbox comes with ethernet - not I > > that there is anything that will currently run on it that uses it for L > > anything, but the intended use is to plug it into a broadband connection > > to the internet. > >  > > --- Carl >   > Will it boot off the ethernet?  1 That specification is not a toy.  It is an office 1 desk top computer camouflaged as a games machine. / Microsoft will soon have both the manufacturing 0 under control and a world wide high street sales/ organization in place.   Ready to start selling  to business in say Easter.  . Any sign of Microsoft killing the PC market by' increasing the price of normal Windows?  --  7 _______________________________________________________  Andrew Swallow   ------------------------------  % Date: Thu, 29 Nov 2001 21:58:21 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>* Subject: Re: DECNET Phase IV saves the day& Message-ID: <3C06A16D.C9FDF9D3@gmx.ch>   Alan Greig wrote:  ../.. E > You guessed it DECNET connectivity remained up between Scotland and G > France (which still had IP connectivity) allowing us to rapidly setup F > captive TCPIP/DECNET relay logons on a VMS box in France to SET HOSTE > into our European MANMAN systems in Scotland. Additionally VMS mail A > over DECNET (once the corporate standard email) again became of  > critical importance.  J DECnet IV is like VMS or the DEC spirit: it will never die because so many" people prefer it to anything else.   D. --  G   --------------------------------------------------------------------- E MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.html E Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670 / 19, chemin de la Butte, 31400 Toulouse, France.   H Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseH On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------    Date: 29 Nov 2001 18:50:45 -0800( From: bob@instantwhip.com (Bob Ceculski)* Subject: Re: DECNET Phase IV saves the day= Message-ID: <d7791aa1.0111291850.783840a5@posting.google.com>   e Alan Greig <a.greig@virgin.net> wrote in message news:<sblc0u0a68km04olakm5j0vcfqioabpp8f@4ax.com>... H > On Tuesday evening an extremely well known organization who manage ourE > corporate WAN installed new routing equipment locally. On Wednesday D > morning the kit failed taking down all site external IP networking; > plus ISDN backup systems -  a should not happen scenario.  > E > During various planning sessions I have argued for the retention of G > DECNET Phase IV to certain key sites worldwide as opposed to shutting / > down or transition to DECNET Phase V over IP.  > E > You guessed it DECNET connectivity remained up between Scotland and G > France (which still had IP connectivity) allowing us to rapidly setup F > captive TCPIP/DECNET relay logons on a VMS box in France to SET HOSTE > into our European MANMAN systems in Scotland. Additionally VMS mail A > over DECNET (once the corporate standard email) again became of  > critical importance. > * > Glad I didn't cave in and drop Phase IV. > H > Yes I know there are serious issues we have to resolve with this "well  > known organization" as well...  F decnet phase V over IP is a nightmare to setup and manage ... TcpwaresL decnet phase IV over IP and it is bullet proof and alot easier to manage ...H it's like having a class B network over the internet ... also unlike theL pwip drivers decnet OSI and multinet use, tcpware phase IV over IP is "true"D decnet phase IV ... and decnet copies are bulletproof unlike ftp ...   ------------------------------  % Date: Fri, 30 Nov 2001 06:52:45 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>* Subject: Re: DECNET Phase IV saves the day& Message-ID: <3C071EAD.B1D9B154@gmx.ch>   Bob Ceculski wrote:  > H > decnet phase V over IP is a nightmare to setup and manage ... TcpwaresN > decnet phase IV over IP and it is bullet proof and alot easier to manage ...J > it's like having a class B network over the internet ... also unlike theN > pwip drivers decnet OSI and multinet use, tcpware phase IV over IP is "true"F > decnet phase IV ... and decnet copies are bulletproof unlike ftp ...  P As soon as my current mission is terminated (end of March :-) I'll start to workP on my new site www.vmsinstal.com. There I will post a summary of all what I have? learned on "hot" issues (and encourage you all to do the same):   	 TCP/IP V5  PCSI DECnet IV to Plus transition  DEnet Plus day to day management Advanced DCL programmingM and many other interesting stuff for the newbie (as I'm SURE VMS will be born  again soon)   H It will be much more easier for me to do WEB publishing than to continueO answering mail every day (as Sue :-) and it will also be convenient to the user I to have a kind of a VMS depository. Another resource, yeah, that will be.   @ Hoff will have to add to his signature "see the VMS FAQ and..."  Stay tuned.    D. --  G   --------------------------------------------------------------------- E MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.html E Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670 / 19, chemin de la Butte, 31400 Toulouse, France.   H Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseH On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------  % Date: Thu, 29 Nov 2001 22:59:22 +0000 1 From: Steve Reece <SYSTEM@ipl.demon.co.nospam.uk>  Subject: Re: DECnet timeout?6 Message-ID: <3C06BDCA.2FE5F7D9@ipl.demon.co.nospam.uk>  C I think the immediate response would be "Yes, somebody is in".  :-)   D My understanding on the DECnet timeout issue is that adding a DECnetC routing node (or a router capable of providing this function) would B provide what you want.  You're after a rapid response of "No, thatB node's gone away" which the routing mechanisms should provide IIRC4 (although someone like Colin Butcher would confirm).  E Bear in mind, since you mention the response from a Phase IV node was E immediate, that DECnet Plus will try the various transports in order, E then timeout and move on to the next.  If you have an address for the H node using the NSP transport and one using the OSI transport then DECnetD will try each, timeout and only when it's tried all of the availableC transports will it respond with the node is not currectly reachable 3 message.  Timeouts appear to go "through the roof".    Steve.     Didier Morandi wrote:  > 
 > ANYBODY IN?  >  > Didier Morandi wrote:  > > L > > I'm writing a hack you will like. For the moment, I need to decrease theI > > DECnet-PLus timeout when DECnet is not (or no more) reachable. In the J > > following example, 288 and 306 are DECnet-Plus systems, 285 is running > > normal DECnet :-) I > > DECnet has been shut on 288 (stop/network DECnet) and 285 (mc ncp set F > > exec state off, i.e. aborted). Now I want to test the connections. > > 
 > > 288> @a.a  > > $ set noon > > $ write sys$output f$time()  > > 23-NOV-2001 13:57:36.96 # > > $ open/read ch 285""::login.com ; > > %DCL-E-OPENIN, error opening 285""::LOGIN.COM; as input & > > -RMS-E-ACC, ACP file access failedA > > -SYSTEM-F-UNREACHABLE, remote node is not currently reachable  > > $ write sys$output f$time()  > > 23-NOV-2001 13:57:36.96  > > 6 > > The answer was immediate from the Phase IV system. > > 
 > > 288> @b.b  > > $ set noon > > $ write sys$output f$time()  > > 23-NOV-2001 13:55:32.60 # > > $ open/read ch 288""::login.com ; > > %DCL-E-OPENIN, error opening 288""::LOGIN.COM; as input & > > -RMS-E-ACC, ACP file access failed< > > -SYSTEM-F-SHUT, remote node no longer accepting connects > > $ write sys$output f$time()  > > 23-NOV-2001 13:55:32.61  > > / > > The answer was immediate (access on itself)  > > 
 > > 306> @b.b  > > $ set noon > > $ write sys$output f$time()  > > 23-NOV-2001 13:54:10.94 # > > $ open/read ch 288""::login.com ; > > %DCL-E-OPENIN, error opening 288""::LOGIN.COM; as input & > > -RMS-E-ACC, ACP file access failedA > > -SYSTEM-F-UNREACHABLE, remote node is not currently reachable  > > $ write sys$output f$time()  > > 23-NOV-2001 13:55:32.13  > > 306> > >  > > Timeout = 1:22 > > B > > This is what I need to change or bypass or detect differently. > > Any ideas? > >  > > Thanks,  > >  > > D. >  > --I >   ---------------------------------------------------------------------tG > MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmlnG > Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670c1 > 19, chemin de la Butte, 31400 Toulouse, France.o > K > Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseIJ > On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   -- cG "A shadow fell over her face; clear, as if the composure were rent like E a veil.  And her lips parted, but only with a short intake of breath. A Then she said, 'Well, then you are right.  Indeed, we are even.'" % 		Louis, "Interview with the Vampire"    ------------------------------    Date: 29 Nov 2001 14:14:28 -0500R From: "Stefan Monnier <foo@acm.com>" <monnier+comp.os.vms/news/@flint.cs.yale.edu> Subject: Re: Emacs-2[01] on VMS./ Message-ID: <5lsnax9yp7.fsf_-_@rum.cs.yale.edu>p  / [ Sorry about the botched subject line before ]c  I > : It's not C that's the problem per se.  Can you say autoconfig?  Built H > : on C preprocessor dependancies that are little more than really uglyI > : unix hackery.  Everytime I rekindle my effort on this project, littlenF > : time is lost before my blood boils.  Targets are built in the same  @ Yes, we (Emacs maintainers) also suffer from it.  But nobody hasB had the courage (or knowledge) to do the switch to autoconf (which* would help on Unix, don't know about VMS).  I > : if the Stallman crowd had merged the VMS mods of 19.28 into the laterSF > : versions but, since VMS is not a unix, it might have tainted their > : precious unixy shit code.x  D Seeing all the #ifdefs for MacOS, W32, MS-DOS, VMS, UnixFoo, UnixBarC etc etc ad nauseam, I doubt that "tainting" was an issue.  It mightn@ have been a simple oversight (or maybe lack of legal paperwork).  ) > So you have not gotten 20.x to compile?  > B > I have compiled it (eventually), but got problems with the dump.I > (Borrowing makefiles and other stuff from the most recent 19.28 on VMS.e" > I think... it was some time ago)  + Did the executable work (without dumping) ?)@ It would really be great to get VMS support back up and running.4 But we'd need someone who can maintain the VMS port.  . BTW, what format is this "emacs207.bck" file ?     	Stefano   ------------------------------  % Date: Thu, 29 Nov 2001 13:22:53 -0700n- From: "Rowell, Bradley" <browell@state.mt.us>n Subject: RE: ftp performance@ Message-ID: <1245D1C0C039D411933708002BB29C644B2D19@DOAISD02003>  J Make sure VMS sees the device at the speed you think.  If not show console	 variable nK ew*0_mode or ei*0_mode appropriately.  It/they should be probably be set toe fastFD.)   $ mcr lancpe LANCP> show dev /chare Device Characteristics EWA0:'                   Value  Characteristic '                   -----  --------------e+                    1500  Device buffer size (                  Normal  Controller mode/                External  Internal loopback mode--       xx-xx-xx-xx-xx-xx  Hardware LAN addressM/                          Multicast address list.-                 CSMA/CD  Communication mediumE,       FF-FF-FF-FF-FF-FF  Current LAN address0                      64  Minimum receive buffers0                     128  Maximum receive buffers+                     Yes  Full duplex enablet0                     Yes  Full duplex operational(             Unspecified  Line media typeF                    1000  Line speed (mbps)   <------------------------   > -----Original Message-----1 > From: emanuel stiebler [mailto:emu@ecubics.com] , > Sent: Thursday, November 29, 2001 10:46 AM > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: ftp performance >  >  > Chris Sharman wrote: > > = > > We've got a ds20e connected via both a 100M card & a 1Gb - > card & a Mac file- > > server (100M only).0	 > > [...] ! > > Suggestions anyone ? Hunter ?c > F > Because none of the transfer rates exceeds 800 KB/s, I guess, you're > just sitting 4< > on a 10Mb network, regardles of the cards you're using ... >    ------------------------------    Date: 29 Nov 2001 13:45:48 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)o Subject: Re: Future of VMS ?3 Message-ID: <Icosn97NYW9m@eisner.encompasserve.org>   i In article <3C06799B.E4B2085A@swissonline.delete.ch>, John McLean <mcleanj@swissonline.delete.ch> writes:O  J > I also want to point out that current porting is to IA64 and is _not_ toJ > the target IPF platform which is still 2, 3, 4 .. ? years away.  It mustF > be reasonable to assume that some degree of change would be requiredE > between IA64 and (whatever), but perhaps that change will be minor.t  / There were changes from 21064 to 21164 as well.h   ------------------------------  % Date: Thu, 29 Nov 2001 15:00:34 -0500-5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>m Subject: Re: Future of VMS ?3 Message-ID: <jwwN7.2126$RL6.63387@news.cpqcorp.net>j  I I don't think anything requires __me__ to publicly endorse, or comment insJ any way on the merger - I am not a officer of the company.  In fact, thereH are many restrictions on who is authorized to speak about merger related issues in public.n  I If I thought the merger was bad, I would say nothing, or be non-commital.e9 Instead, I choose to say that I think it is a good thing.a  : I also believe VMS will be fine regardless of the outcome.   _FRed   I John McLean wrote in message <3C06799B.E4B2085A@swissonline.delete.ch>...p >  >x >Fred Kleinsorge wrote:  >> >fK >> While I cannot say anything specific about the merger, I will say that Is9 >> support it 100%.  I think it will be good for OpenVMS.e >>I >> The only thing I will comment on in your post is the IPF reference.  I-F >> believe merger or not, the Alpha/IPF decision will not be revisted. > F >And I believe that the only truly encouraging sign to come out of allF >this deal with Intel is the fact that as the porting takes place, the0 >hardware dependencies in VMS are being reduced. >eI >This at least will permit a hasty "Plan-B" if things go to mush, becausenB >it means a port to yet another processor would be a simpler task. >w >oI >I also want to point out that current porting is to IA64 and is _not_ tonI >the target IPF platform which is still 2, 3, 4 .. ? years away.  It mustmE >be reasonable to assume that some degree of change would be required-I >between IA64 and (whatever), but perhaps that change will be minor.  (IfnI >this was all plain sailing than there seems no good reason why VMS could.; >not be released on IA64 prior to original scheduled date.)m >oH >Oh dear, so you cannot comment on the merger.  If you had read the fineH >print of the merger document that HP submitted to the SEC you would seeI >that Compaq's board and its employees are supposed to endorse the merger 9 >at every reasonable opportunity or HP may pull the plug.> >hH >Now maybe it is communication problem within Compaq that this has neverF >filtered down the tree.  Or maybe it is not meeting with overwhelmingD >approval in the corridors of Compaq.  Neither of these alternativesE >reflects well on Compaq's management.  Either they can't communicateiI >within their own organisation or management are making decisions that doI >not impress the workers.e >oI >I do realise that I may be putting you in an difficult position here.  IrF >really don't mind if you post something saying that the merger is theD >best thing since sliced bread (or whatever preceeded sliced bread).I >Alternatively I don't mind if you decide to say nothing, in which case I_4 >will say "Say no more. Nudge, nudge.  Wink, wink !" >A >e >John McLean   ------------------------------  % Date: Thu, 29 Nov 2001 15:03:03 -0500l5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>  Subject: Re: Future of VMS ?3 Message-ID: <EywN7.2128$RL6.63332@news.cpqcorp.net>e  J We do not forsee major changes to the IA64 code for future processors.  AtI least, as Larry says, anything more/worse than we've had on Alpha - which J mostly had to do with IO, performance, and system code - and didn't effect much user code.i      $ Larry Kilgallen wrote in message ...B >In article <3C06799B.E4B2085A@swissonline.delete.ch>, John McLean' <mcleanj@swissonline.delete.ch> writes:o > K >> I also want to point out that current porting is to IA64 and is _not_ tofK >> the target IPF platform which is still 2, 3, 4 .. ? years away.  It must G >> be reasonable to assume that some degree of change would be requiredsF >> between IA64 and (whatever), but perhaps that change will be minor. >i0 >There were changes from 21064 to 21164 as well.   ------------------------------  # Date: Thu, 29 Nov 2001 20:15:19 GMT-* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Future of VMS ?B Message-ID: <rHwN7.148303$qx2.9188510@bin5.nnrp.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:zwuN7.2115$RL6.63338@news.cpqcorp.net...i   ...m  J > I am optimistic about the future of VMS regardless of the outcome of the	 > merger.   H Ah, Fred:  I know you're not conventionally stupid, so you must have theE naivete of a 3-year-old who always believes completely everything hisyE parents tell him.  That makes for happiness now, but tends to lead toa disillusionment down the road.  L Leaving aside the perhaps less-understood aspects of the likely consequencesK of getting adopted by HP, the only possible reason you can believe that VMS-F will be better off if the merger falls through (assuming that it's notD because you believe Capellas & Co. will get the boot and thus almostC inevitably cause conditions to improve) is because you believe that1E customers will flock to VMS on Itanic as they have not for many yearsd flocked to VMS on Alpha.  D The first problem with that outlook is that customers won't have theJ opportunity to do that for 2+ years, and it'll be another year before theyI have the opportunity to choose an Itanic engine that actually performs astJ well as the then-stagnant Alpha does - and even if Itanic *would* help VMSJ waiting 3 years to recover from a major blow during the declining years of? an OS tends to be very hazardous to its potential for survival.k  G But the second, and more fundamental, problem is that there's no reasoniD whatsoever to assume that customers will view VMS on Itanic any moreK positively than they view VMS on Alpha:  most of the world will still thinkeH that VMS died some time in the previous decade, and that small part thatK actually knows it didn't will assume (as they do now) that it may die or atoC least become comatose at any time, given the attitude of its owner.o  L The porting effort may provide some interesting work for you guys, but don'tL mistake it as change in Compaq's level of development support for VMS:  it'sI just a dressing to stem the arterial bleeding that would otherwise result L from the Alphacide and doesn't even include the stitches that might give theK artery a chance to heal, let alone the significant increase in support (forIH both development and promotion) that would be required to promote actual growth.v   - bill   ------------------------------  % Date: Thu, 29 Nov 2001 15:50:49 -0500 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>n Subject: Re: Future of VMS ?3 Message-ID: <sfxN7.2132$RL6.63351@news.cpqcorp.net>    Bill Todd wrote in message ... >eA >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message . >news:zwuN7.2115$RL6.63338@news.cpqcorp.net... >  >... >eK >> I am optimistic about the future of VMS regardless of the outcome of the 
 >> merger. > I >Ah, Fred:  I know you're not conventionally stupid, so you must have thejF >naivete of a 3-year-old who always believes completely everything hisF >parents tell him.  That makes for happiness now, but tends to lead to >disillusionment down the road.r >      Bill you ignorant slut...t  F You have no idea what I know, or what I don't know.   Frankly, I'll beF "happy" regardless of the merger outcome, or even if VMS was cancelled! tommorrow.  Trust me on this one.   K I have no reason to believe that there will be any net change in how VMS isnK handled by either company.  But all things being equal, I would like VMS to I have access to things that a combined Compaq/HP might be able to provide.u  @ >Leaving aside the perhaps less-understood aspects of the likely consequencesL >of getting adopted by HP, the only possible reason you can believe that VMSG >will be better off if the merger falls through (assuming that it's notfE >because you believe Capellas & Co. will get the boot and thus almost ( >inevitably cause conditions to improve)   Not at all.o   is because you believe thatyF >customers will flock to VMS on Itanic as they have not for many years >flocked to VMS on Alpha.e >e    E I don't expect to use the word "flock".  But again, I thought we were E talking about the merger, not moving to Itanium.  If the merger falls-D through tommorrow, I do not expect that to change our porting plans.  J I believe that the port to Itanium takes VMS out of a narrow corner we hadL been painted into - that is, the handcuffs to a specific CPU architecture...F and one that had only a very small marketshare.  I believe it opens up; "possibilities" that were not available to VMS in the past.   E But honestly, if after we get through this economic slowdown, and theeK disruption caused by the various transitions (Alpha->Itanium, Compaq->HP) -sL we get back to where we *were* -- modest growth in target markets -- I'll be happy.  I If I'm allowed to be something other than the cynic-without-portfolio you-B appear to be - then I can be optimistic of this, and perhaps more.  E >The first problem with that outlook is that customers won't have thelK >opportunity to do that for 2+ years, and it'll be another year before theysJ >have the opportunity to choose an Itanic engine that actually performs asK >well as the then-stagnant Alpha does - and even if Itanic *would* help VMS K >waiting 3 years to recover from a major blow during the declining years ofv@ >an OS tends to be very hazardous to its potential for survival. >I    J Customers for the "next 2+ years" will be still have access to some of the. fastest servers on the planet running OpenVMS.  L Contrary to your assertion of decline, in many areas OpenVMS has been on theK upswing for the last few years.  Perhaps more narrowly focused.  Actual NEWh1 customers, not just sales into existing accounts.   J I've now had a chance to talk to several large customers about the OpenVMSL future, and the Itanium port - not one of them is leaving OpenVMS.  The mostI important aspects they wanted to know about was timing, interoperability,,- and that we actually had a plan to get there.n    H >But the second, and more fundamental, problem is that there's no reasonE >whatsoever to assume that customers will view VMS on Itanic any morenL >positively than they view VMS on Alpha:  most of the world will still thinkI >that VMS died some time in the previous decade, and that small part that"L >actually knows it didn't will assume (as they do now) that it may die or atD >least become comatose at any time, given the attitude of its owner. >o    L How do you somehow feel you have the right *or* the ability to speak for anyK or all of our customers???  Stop turning your *personal* feelings into some F generalization about how everyone feels.  Or are you assering that theL narrow cross section of people who read this newsgroup, and the even smallerA number who actually write in it - provide all the input you need?C  J How much Alpha hardware or OpenVMS software have you bought recently?  HowG much do you have invested in OpenVMS solutions?  How is *your* business 7 dependent on a highly reliable system based on OpenVMS?   D How can you possibly pretend to be able to speak for those who *do*?      G >The porting effort may provide some interesting work for you guys, but, don'toG >mistake it as change in Compaq's level of development support for VMS:d it'sJ >just a dressing to stem the arterial bleeding that would otherwise resultI >from the Alphacide and doesn't even include the stitches that might givee the L >artery a chance to heal, let alone the significant increase in support (forI >both development and promotion) that would be required to promote actual- >growth. >-    J I'd much prefer to NOT be doing a port to a new architecture - been there,L done that, don't need to do it again just for the excersize.  Yeah, there isI some amount of "fun" in the work, but it is also a distraction from otheruA areas I'd prefer to be able to work on.  On the other hand, it istK necessary - and the end result will put OpenVMS on a better footing for thea future.    ------------------------------  # Date: Thu, 29 Nov 2001 22:22:09 GMTm* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Future of VMS ?< Message-ID: <lyyN7.71993$YD.6118664@news2.aus1.giganews.com>  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:sfxN7.2132$RL6.63351@news.cpqcorp.net...v  > Bill Todd wrote in message ...   ...e  G > But honestly, if after we get through this economic slowdown, and the:? > disruption caused by the various transitions (Alpha->Itanium,e
 Compaq->HP) - K > we get back to where we *were* -- modest growth in target markets -- I'll  be > happy.  K I guess it's usually possible to make one's goals so modest that the chancemJ of meeting them is non-negligible (not that even getting back to where VMSI was before June 25th is likely to be at all easy).  A lot of participantsb8 here were hoping for considerably more, until that date.   ...i  G > >The first problem with that outlook is that customers won't have thecH > >opportunity to do that for 2+ years, and it'll be another year before theyL > >have the opportunity to choose an Itanic engine that actually performs asI > >well as the then-stagnant Alpha does - and even if Itanic *would* helpe VMS J > >waiting 3 years to recover from a major blow during the declining years ofB > >an OS tends to be very hazardous to its potential for survival. > >i >e >eL > Customers for the "next 2+ years" will be still have access to some of the0 > fastest servers on the planet running OpenVMS.  L That may help some existing customers, but getting new customers (which wereF required even before June25 to replace the annual 15% loss of existingF sales) to commit to a declared-dying platform, with the knowledge thatK they'll need to port not too long after they adopt that platform, will be aeL lot more difficult, and some existing customers who would have continued had8 Alpha's life not been limited will likely not do so now.   >5J > Contrary to your assertion of decline, in many areas OpenVMS has been on themI > upswing for the last few years.  Perhaps more narrowly focused.  Actuala NEWr3 > customers, not just sales into existing accounts.   L That's entirely characteristic of a system in its declining years, which was
 what I said..s   >eL > I've now had a chance to talk to several large customers about the OpenVMSI > future, and the Itanium port - not one of them is leaving OpenVMS.  The- mostK > important aspects they wanted to know about was timing, interoperability,C/ > and that we actually had a plan to get there.   K That's nice, but what's important is the percentage of business that *will* J be lost, not the fact that some of it won't be.  Numbers will doubtless beI difficult to wring out of Compaq's public financial statements, but there I certainly appears to have been a drastic down-turn in Alpha sales in Q3 - I far more than could have been attributable to the two September events or L the on-going slowdown (which Alpha had appeared relatively immune to through Q2).   >n >pJ > >But the second, and more fundamental, problem is that there's no reasonG > >whatsoever to assume that customers will view VMS on Itanic any morerH > >positively than they view VMS on Alpha:  most of the world will still think K > >that VMS died some time in the previous decade, and that small part thathK > >actually knows it didn't will assume (as they do now) that it may die or. atF > >least become comatose at any time, given the attitude of its owner. > >s >c >sJ > How do you somehow feel you have the right *or* the ability to speak for anyh > or all of our customers???  H I can certainly speak for those who have aired similar views here, whichJ appears to be a sizable fraction of the participants in this forum.  I canL also speak for VMS's general invisibility in the larger world, both based onH anecdotes reported frequently here and on countless industry articles byL people one would really expect to know better referring to VMS as 'defunct',J 'legacy', 'VAX/VMS', and various other ways (often in the past tense) thatG I'd have to dig out but have no difficulty remembering having seen (ouru; advocacy group last year was collecting them at one point).w  1   Stop turning your *personal* feelings into some1* > generalization about how everyone feels.  F Stop assuming the worst without having a clue about what I'm basing my statements on.     Or are you assering that theF > narrow cross section of people who read this newsgroup, and the even smallertC > number who actually write in it - provide all the input you need?t  L No - see above.  And next time, try asking before making a fool of yourself.   - bill   ------------------------------  # Date: Thu, 29 Nov 2001 20:27:47 GMTI4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Future of VMS ?7 Message-ID: <7TwN7.48$qI.80439@typhoon.ne.mediaone.net>b  0 "Dr. Dweeb." <Dweeb@nospam.com> wrote in message) news:HttN7.97$WK5.4649@news.get2net.dk...C >97 > "Bill Todd" <billtodd@metrocast.net> wrote in messagei8 > news:N5eN7.61962$YD.5501533@news2.aus1.giganews.com... > > B > > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message3 > > news:3C0526FA.7A739645@swissonline.delete.ch... 
 > > >Clip ...  > >uH > > To address Rob's comment about making the Itanic pig fly:  of course IntelnJ > > will.  An old aviation adage is that you can make a barn door fly withF > > enough power, and Itanic uses power like an electric furnace (thus making7 > > the adage apply both metaphorically and literally).e > >. >e% > I guess that was the F4-Phantom :-)l >B  D Indeed. A flying machine known to some as the "clear air converter."   ------------------------------  # Date: Thu, 29 Nov 2001 20:26:27 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Future of VMS ?7 Message-ID: <TRwN7.47$qI.79969@typhoon.ne.mediaone.net>t  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:oguN7.2114$RL6.63331@news.cpqcorp.net... H > No question.  And in fact, since Compaq bought DEC, VMS had managed to turnK > around inside the company, and had managed some growth.  That is, instead  ofJ > a prevailing attitude of "riding VMS down", things changed to a "how can we > sustain this business".  >tH > In the current case, I believe that HP brings to the table a number of: > things that VMS itself may be able to take advantage of. >m  K One thing HP *won't* be bringing to the table is competition for VMS in thea form of MPE. ;-}   ------------------------------  % Date: Thu, 29 Nov 2001 18:29:07 -0500p( From: David Froble <davef@tsoft-inc.com> Subject: Re: Future of VMS ?, Message-ID: <3C06C4C3.6060005@tsoft-inc.com>   Fred Kleinsorge wrote:    < > I also believe VMS will be fine regardless of the outcome. >  > _FRede  E Fred has stated this opinion multiple times now.  In pretty much the cF same manner each time.  I'm beginning to get a feeling that it may be ' more than it may appear on the surface.   H Note that there are most likely entities out there using VMS that could H buy Compaq AND HP many times over.  For some it may be cheaper to 'buy' F VMS than to convert to another OS.  It's possible that there are some F agreements, with one or more large customers, that would preclude VMS I not being available for them.  Such agreements could have various forms, sA from that department in Compaq/HP being funded by parties to the eD agreement, to such parties acquiring VMS should things go that awry.  F Not saying that this is my first choice for what may happen, but, the D way he said the same thing multiple times just caused me to go into  speculation mode.   G Such an agreement would be something nobody could acknowledge, but, in sI order to prevent a significant drain of VMS engineers should things look  G grim, at least some of them would have to have prior knowledge of such._   Dave   -- r4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Thu, 29 Nov 2001 18:30:05 -0500 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: Future of VMS ?, Message-ID: <3C06C4FD.7050407@tsoft-inc.com>   Terry C. Shannon wrote:8  B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message/ > news:oguN7.2114$RL6.63331@news.cpqcorp.net...L > H >>No question.  And in fact, since Compaq bought DEC, VMS had managed to >> > turn > K >>around inside the company, and had managed some growth.  That is, insteadl >> > of > J >>a prevailing attitude of "riding VMS down", things changed to a "how can >> > we >  >>sustain this business".e >>H >>In the current case, I believe that HP brings to the table a number of: >>things that VMS itself may be able to take advantage of. >> >> > M > One thing HP *won't* be bringing to the table is competition for VMS in theM > form of MPE. ;-}  J I'd much rather they did.  It would show a company committed to customers.     Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Fri, 30 Nov 2001 01:01:17 GMTe4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Future of VMS ?9 Message-ID: <xTAN7.113$qI.238180@typhoon.ne.mediaone.net>n  5 "David Froble" <davef@tsoft-inc.com> wrote in messagen& news:3C06C4FD.7050407@tsoft-inc.com... > Terry C. Shannon wrote:f >nD > > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message1 > > news:oguN7.2114$RL6.63331@news.cpqcorp.net...h > > J > >>No question.  And in fact, since Compaq bought DEC, VMS had managed to > >> > > turn > > E > >>around inside the company, and had managed some growth.  That is,d insteadt > >> > > of > > L > >>a prevailing attitude of "riding VMS down", things changed to a "how can > >> > > we > >a > >>sustain this business".m > >>J > >>In the current case, I believe that HP brings to the table a number of< > >>things that VMS itself may be able to take advantage of. > >> > >> > >pK > > One thing HP *won't* be bringing to the table is competition for VMS in  thei > > form of MPE. ;-} >hL > I'd much rather they did.  It would show a company committed to customers. >h  J I wasn't endorsing HP's decision. And the timing sure as hell leaves a lot to be desired!   ------------------------------    Date: 29 Nov 2001 18:14:01 -0800/ From: Brannon_Batson@yahoo.com (Brannon Batson)- Subject: Re: Future of VMS ?= Message-ID: <4495ef1f.0111291814.74e481a8@posting.google.com>c  h Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<Icosn97NYW9m@eisner.encompasserve.org>...k > In article <3C06799B.E4B2085A@swissonline.delete.ch>, John McLean <mcleanj@swissonline.delete.ch> writes:6 > L > > I also want to point out that current porting is to IA64 and is _not_ toL > > the target IPF platform which is still 2, 3, 4 .. ? years away.  It mustH > > be reasonable to assume that some degree of change would be requiredG > > between IA64 and (whatever), but perhaps that change will be minor.t > 1 > There were changes from 21064 to 21164 as well.u  E I'd like to point out (without passing judgement) that you seem to benD equating Alpha's philosophy on instruction set changes with Intel's.   Brannono not speaking for Intel   ------------------------------   Date: 30 Nov 2001 04:50:02 GMT- From: Joe Heimann <heimann@nog.ecs.umass.edu>y= Subject: Re: Gartner and IDC say HP will effectively kill DLT , Message-ID: <9u735q$r4v$2@odo.ecs.umass.edu>  4 In comp.os.vms Chris Petersen <havoc@apk.net> wrote:8 > In comp.sys.dec Alan Greig <a.greig@virgin.net> wrote:F > : On 28 Nov 2001 14:12:21 GMT, Chris Petersen <havoc@apk.net> wrote:	 (snipped)e  F > : Plus I can find no reference to SuperDLT products on HP's web site > : under tape storage.'  F > Last word I heard on this one was that Quantum (or whomever owns theI > mechanism rights now) was charging an arm & a leg for SuperDLT.  Last IeM > checked, none of the major system vendors were offering OEM-versions of the M > SuperDLT drives yet, and I believe it was for just such a reason.  If I can"J > find some reference to this for you I'll post it later, but that was the > word through the grapevine.l  K I don't know about HP, but IBM is selling SuperDLT drives already and listseJ them as "In Stock" on their website.  The following page has a list of theH various technology drives IBM is selling including DLT, the link for the% SuperDLT drive is about halfway down:e  8       http://www.pc.ibm.com/ww/eserver/xseries/tape.html  G Of course, at a list price of $5999, it is not on my shopping list yet.h    Joe   heimann@ecs.umass.edui (much snippage)y   ------------------------------  % Date: Thu, 29 Nov 2001 19:03:30 +0000e4 From: John Laird <john@laird-towers.freeserve.co.uk>4 Subject: Re: Graphics cntrlr not recognized by 5.5-28 Message-ID: <fk6c0usbql3t8f3kupu9o0rhvtra4cbe4o@4ax.com>  5 On Wed, 28 Nov 2001 10:26:22 -0500, "Fred Kleinsorge"r$ <kleinsorge@star.zko.dec.com> wrote:  M >The VS4000 had the LCG graphics engine built into the memory controller.  IthL >was a brilliant design for a system with a slow CPU.  The thing that lookedK >like a graphics card, was actually a board that contained the video memorycG >and RAMDAC - which allowed a number of configurations (for instance, atD >4-headed version was done, as well as one that could interface to a >multi-sync monitor).  > D >The SPX/GT was a add-on graphics card that plugged in where the LCGH >memory/RAMDAC card went, and overrode the LCG capabilities and added 3DH >capability.  The SPX became more-or-less standard on the VS4000-60 over >time.  H Today is one of those days where I *did* learn something new :-)  ThanksH for that.  Was the TC option obligatory for the 3D cards (I've never met one) ?     	Johno -- e
 John Laird Yezerski Roper Ltd   ------------------------------  % Date: Thu, 29 Nov 2001 15:04:39 -0500h5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 4 Subject: Re: Graphics cntrlr not recognized by 5.5-23 Message-ID: <8AwN7.2129$RL6.63409@news.cpqcorp.net>t  8 The SPX/GT hacked itself into the same paths as the LCG.  6 The TC hack was just for SCSI if I remember correctly.       John Laird wrote in message ...i6 >On Wed, 28 Nov 2001 10:26:22 -0500, "Fred Kleinsorge"% ><kleinsorge@star.zko.dec.com> wrote:  >wJ >>The VS4000 had the LCG graphics engine built into the memory controller. ItF >>was a brilliant design for a system with a slow CPU.  The thing that lookedL >>like a graphics card, was actually a board that contained the video memoryH >>and RAMDAC - which allowed a number of configurations (for instance, aE >>4-headed version was done, as well as one that could interface to as >>multi-sync monitor). >>E >>The SPX/GT was a add-on graphics card that plugged in where the LCGrI >>memory/RAMDAC card went, and overrode the LCG capabilities and added 3DrI >>capability.  The SPX became more-or-less standard on the VS4000-60 overt >>time.w > I >Today is one of those days where I *did* learn something new :-)  Thanks I >for that.  Was the TC option obligatory for the 3D cards (I've never met  >one) ?r >g >f > John >--d >John Lairds >Yezerski Roper Ltds   ------------------------------    Date: 29 Nov 2001 13:36:48 -0800, From: dframeli@aus.telusa.com (Dale Frameli)> Subject: How do you use Kermit within a VMS command procedure?= Message-ID: <de844d64.0111291336.76e6eb45@posting.google.com>v  ? We're using VMS Kermit-32 v3.2.077 on our DEC3000-300.  OpenVMSaE v1.5-1H1 is installed.  I believe UCX v3.x is also installed, but I'miE not sure about that.  There is little, or no chance of getting the OSn
 updated :(  ?   Can the version of Kermit that we have be used in VAX CommandaC Procedures?  Within a command procedure, I wish to call Kermit, andh/ pass it the name of the file I want it to send.   6 i.e. RUN DKA300:[UTILITIES.SYSTEM]KERMIT -SEND -BINARY [.ALFC]TESTFILE.ZIP   A   The C-Kermit website mentions using Kermit in Unix scripts, butu" nothing I could find mentions VMS.  E   If this is possible, can you tell me what the proper syntax / usagee would be to accomplish my task?   4   Please send your reply to: dframeli@aus.telusa.com   Thanks,o Dale   ------------------------------  % Date: Thu, 29 Nov 2001 21:45:49 +00007! From: Andy Burns <andy@burns.net>vB Subject: Re: How do you use Kermit within a VMS command procedure?8 Message-ID: <fuad0ugd02lbf5mk3gv9aoean7fu9te176@4ax.com>  E On 29 Nov 2001 13:36:48 -0800, dframeli@aus.telusa.com (Dale Frameli)  wrote:  O >OpenVMS v1.5-1H1 is installed. There is little, or no chance of getting the OS. >updated :(t  C Be careful, I remember several "issues" with C runtime libraries inmD version 1.5 which was really just a stopgap first release for alpha,A try to make sure the software is linked on the machine itself ...i     --  
 Andy Burns   ------------------------------  % Date: Fri, 30 Nov 2001 06:59:14 +0100m, From: Didier Morandi <Didier.Morandi@gmx.ch>B Subject: Re: How do you use Kermit within a VMS command procedure?& Message-ID: <3C072032.C7FF9F03@gmx.ch>   Dale Frameli wrote:  > 6 >   Please send your reply to: dframeli@aus.telusa.com     You see, Dale? It "works".   For your information:   L 1. You may ask to send answers via mail but you'll expect to see them posted9 here too as more than one person may be interested in it.i  T 2. Frank da Cruz is KERMIT's father. You found the right place and the right person.  K 3. ask any question here, statistifs demonstrate that there is at least onee6 reader who encountered the same problem as you before.   COV will save VMS?  M Maybe we could create a company all of us COVers and purchase VMS EngineeringrC from WYKBWNSNBS (Who You Know but Whose Name Should Not Be Said :-)t   D.   ------------------------------   Date: 29 Nov 2001 21:52:35 GMT0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz)> Subject: Re: How to use Kermit within a VMS command procedure?5 Message-ID: <9u6an3$egb$1@newsmaster.cc.columbia.edu>a  = In article <de844d64.0111291335.6c275174@posting.google.com>, - Dale Frameli <dframeli@aus.telusa.com> wrote: 8 : We're using VMS Kermit-32 v3.2.077 on our DEC3000-300. :s
 Kermit-32:  ?  (a) Was retired from service in 1987 and replaced by C-Kermit:s2        http://www.columbia.edu/kermit/ckermit.html  =  (b) Is only for the VAX, so you must be running it under VAX       emulation.   @  (c) Is really slow and primitive compared to C-Kermit, etc etc.  	 : OpenVMSuG : v1.5-1H1 is installed.  I believe UCX v3.x is also installed, but I'mtG : not sure about that.  There is little, or no chance of getting the OSs : updated :( : 8 Doesn't matter.  Do you have a C compiler on it?  If so:  A  . This would be very helpful to us because until now we have nott;    found a VMS 1.x build site for recent C-Kermit releases.c   If not:i  D  . You can download a prebuilt C-Kermit 6.0-for-VMS/Alpha-1.x binary     from the aforementioned site.  I C-Kermit is fully scriptable, but not the way you think.  C-Kermit itself D has its own script language, which it executes directly (e.g. from aD command file), as opposed to writing DCL command procedures to stuffG commands into its command processor.  See the examples in Section 2 of:h  /   ftp://kermit.columbia.edu/kermit/f/ckvbwr.txti   - Frankr   ------------------------------  # Date: Thu, 29 Nov 2001 20:20:44 GMTl4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: IPF Debugged?7 Message-ID: <wMwN7.44$qI.78095@typhoon.ne.mediaone.net>   : "Robert Harley" <harley@estephe.inria.fr> wrote in message( news:rz7adx5pm9c.fsf@estephe.inria.fr...  A > Then again, last I heard, Itanium is too buggy for Compaq to bes > willing ship it... >b  K Late word from the trade press is that the erratum, sighting, flaw, bug, orV" whatever has been found and fixed.   ------------------------------  # Date: Fri, 30 Nov 2001 05:05:24 GMTl. From: "Duane Sand" <duane.sand@mindspring.com> Subject: Re: IPF Debugged?? Message-ID: <osEN7.57752$RG1.31524918@news1.rdc1.sfba.home.com>r   > "Robert Harley"  wroteC > > Then again, last I heard, Itanium is too buggy for Compaq to ben > > willing ship it...   Terry Shannon wroteeM > Late word from the trade press is that the erratum, sighting, flaw, bug, or1$ > whatever has been found and fixed.  > Or perhaps the BIOS was patched to simply disable some machineE feature, perhaps at some performance cost.  Software work-arounds forr+ hardware bugs often involve some sacrifice.g   ------------------------------  % Date: Thu, 29 Nov 2001 14:02:59 -0500l2 From: "Sue Skonetski" <susan.skonetski@compaq.com>/ Subject: Just a reminder for tomorrow's webcast.3 Message-ID: <CCvN7.2119$RL6.63271@news.cpqcorp.net>   I Just so you know over 400 people have signed up for this.  If you want tonE attend you need to register.  I would not waste much time registeringp either.e  
 Warm Regards,D   Sueb      5 Open VMS Alpha-to-Itanium: Development Update WebCast9    Date - Friday, November 30, 2001  L Time - 11:00 a.m. to 12:30 p.m. (EST) (a 1-hour presentation with 30-minutes   of Q&A)g  K - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -m  + - - - - - - - - - - - - - - - - - - - - - -d  " Webinar presenter: Gaitan D'Antoni  E As announced in June 2001, the move to ItaniumT architecture providesn  F OpenVMS operating system customers with the most compelling roadmap to  J next-generation server technology. This technical session will provide you  H with a porting timeline to assist you in your planning efforts. You will  L learn about the current OpenVMS/Alpha operating system timelines, as well as  K our roadmap to the ItaniumT Processor Family. During this webinar, you will   G be given preliminary information about porting your applications to thea  K Itanium-based OpenVMS operating system. Please join us Friday, November 30,n  L 2001, 11:00 a.m. to 12:30 p.m. EST for this informative webinar. The webinar  7 will be a one-hour presentation with 30 minutes of Q&A.q   Please register here:n  < http://presentationselect.com/cpq-alpha-itanium/register.asp  @ For presentation audio dial 1-212-896-6079, reference #20034440.  ; We look forward to having you join us for the presentation.    ------------------------------  # Date: Thu, 29 Nov 2001 19:27:37 GMTl= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) 3 Subject: Re: Just a reminder for tomorrow's webcasth0 Message-ID: <00A05C6A.74DC5744@SendSpamHere.ORG>  h In article <CCvN7.2119$RL6.63271@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:J >Just so you know over 400 people have signed up for this.  If you want toF >attend you need to register.  I would not waste much time registering >either. >l >Warm Regards, >  >Sue  . Well, I failed the browser check.  Surprised?    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMm            nJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesl   ------------------------------  % Date: Thu, 29 Nov 2001 15:23:07 -0500 0 From: Paul Anderson <paul.r.anderson@compaq.com>3 Subject: Re: Just a reminder for tomorrow's webcastl; Message-ID: <291120011523077369%paul.r.anderson@compaq.com>   F In article <00A05C6A.74DC5744@SendSpamHere.ORG>, Brian Schenkenberger,( VAXman- <system@SendSpamHere.ORG> wrote:  / > Well, I failed the browser check.  Surprised?o  , Whatcha runnin' over there, Mosaic 1.0?  ;-)  @ I succeeded on my fourth browser.  OmniWeb 4.1, Netscape 6.2 and< Internet Explorer 5.1, all on the Mac, all failed.  Netscape? Communicator 4.79 on the Mac succeeded.  I didn't even try withc$ Netscape 3.03 or Mozilla on OpenVMS.   Paul   -- d  Paul Anderson   OpenVMS Engineeringk   Compaq Computer Corporation    ------------------------------  % Date: Thu, 29 Nov 2001 21:59:39 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>3 Subject: Re: Just a reminder for tomorrow's webcastl& Message-ID: <3C06A1BA.2F55A928@gmx.ch>   Sue Skonetski wrote: > K > Just so you know over 400 people have signed up for this.  If you want to-G > attend you need to register.  I would not waste much time registeringf	 > either.    Hi Sue,:  , Who is the author? Engineering or Marketing?   D. -- oG   ---------------------------------------------------------------------oE MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmltE Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670 / 19, chemin de la Butte, 31400 Toulouse, France.o  H Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseH On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------  % Date: Thu, 29 Nov 2001 16:49:49 -0500t2 From: "Sue Skonetski" <susan.skonetski@compaq.com>3 Subject: Re: Just a reminder for tomorrow's webcast>3 Message-ID: <13yN7.2135$RL6.63518@news.cpqcorp.net>   L engineering Gaitan D'Antoni to be exact, he is a technical director (really) and an excellent person.   Sued  9 "Didier Morandi" <Didier.Morandi@gmx.ch> wrote in message   news:3C06A1BA.2F55A928@gmx.ch... > Sue Skonetski wrote: > >xJ > > Just so you know over 400 people have signed up for this.  If you want toI > > attend you need to register.  I would not waste much time registering- > > either.  >a	 > Hi Sue,  > . > Who is the author? Engineering or Marketing? >s > D. > --I >   ---------------------------------------------------------------------pG > MORANDI Consulting.  WEB: http://Didier.Morandi.Free.fr/index_us.htmleG > Pflanzschulstrasse 53, 8004 Zurich, Switzerland. GSM: +41 79 705 4670f1 > 19, chemin de la Butte, 31400 Toulouse, France.c >mJ > Disaster Recovery Plans, Computer Security Audits, DEC OpenVMS ExpertiseJ > On parle franais, Man spricht Deutsch, Habla Castellano, English spoken   ------------------------------  % Date: Thu, 29 Nov 2001 19:03:30 +0000 4 From: John Laird <john@laird-towers.freeserve.co.uk>* Subject: Re: logical names novice question8 Message-ID: <957c0uov2k67u39r9fqohu5pknacei5042@4ax.com>  / On Thu, 29 Nov 2001 04:40:09 GMT, Tim Llewellyn,& <tim.llewellyn@cableinet.co.uk> wrote:  5 >Oh dear you reminded me of PLOT10 and Tek 4010's :-)e  F All those lovely arithmetic IF and computed GOTO statements.  At least@ it was compact, efficient, and worked !  And the source code was
 available.   -- e
 John Laird Yezerski Roper Ltd   ------------------------------   Date: 29 NOV 2001 19:10:24 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov>o* Subject: Re: logical names novice question2 Message-ID: <29NOV01.19102476@feda34.fed.ornl.gov>  L In a previous article, John Laird <john@laird-towers.freeserve.co.uk> wrote:1 > On Thu, 29 Nov 2001 04:40:09 GMT, Tim Llewellyn ( > <tim.llewellyn@cableinet.co.uk> wrote: >   7 > >Oh dear you reminded me of PLOT10 and Tek 4010's :-). >  nH > All those lovely arithmetic IF and computed GOTO statements.  At leastB > it was compact, efficient, and worked !  And the source code was > available.  G Hey - I've still got (a few) folks who still use PLOT10 on VMS and even2% Unix (we did a port).  Scary, really.e   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOV4H Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------    Date: 29 Nov 2001 12:48:14 -08003 From: Eric Smith <eric-no-spam-for-me@brouhaha.com>AO Subject: looking for HSC50, RA81, star coupler, CIPCA, various manuals & printsi0 Message-ID: <qhitbtl2wh.fsf@ruckus.brouhaha.com>  E I'm looking for HSC50s, RA81s, star couplers, and the CIPCA CI-to-PCIeG host adapter or CMD CPC-6610.  Anyone have some available?  Preferrablys on the US west coast.d  @ I'm also looking for manuals and print sets for the HSC50, RA81,H star coupler, UDA50, KDA50, CI780, and CI20.  (I already have the prints# for the CI20, but not the manuals.)   C As far as documentation and prints go, if anyone is willing to lendtB them to me or make copies (at my expense), I'll scan them and make PDF files available online.    Thanks!a Eric  F [To send a private reply, please remove the obvious spam-proofing from my email address.]   ------------------------------    Date: 29 Nov 2001 13:28:17 -0800( From: bob@instantwhip.com (Bob Ceculski)? Subject: Re: New product allows VMS to become part of a PC Lan!e= Message-ID: <d7791aa1.0111291328.23409821@posting.google.com>   e Alan Greig <a.greig@virgin.net> wrote in message news:<td1c0ugl6075tq6p0tqjp2hhm8g7b393ed@4ax.com>...tH > On 28 Nov 2001 08:36:22 -0600, koehler@encompasserve.org (Bob Koehler) > wrote: > k > >In article <d7791aa1.0111271509.4f1bf490@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:  > >tH > >> Just ran across this amazing product as we were looking to make our
 > >> AlphaD > >> VMS system part of our local PC Lan and ran across this amazing > >> product ...J > >> they also have a product that allows VMS pc disk access ... amazing!  > >> here is) > >> the link if anyone is interested ...  > >cK > >   Nothing like being 15 years behind the times, and 10 years behind theu > >   freeware.@ > H > I thought at first surely this is just Pathworks or Samba but actuallyH > the product Bob describes allows VMS systems to access NT print queuesB > and shares which is the reverse of the functionality provided byE > Pathworks and Samba. Although I have heard that Samba may have somes6 > ability to allow a user to access NT shares from VMS  G Compaq to my amazement recommended this over pathworks as pathworks hasaK limited printer support ... this will give us full range printer access ...oH they also have a product Lanutil that allows you to access and copy from! pc disks, NT 2000 or WIN95 98 ...    ------------------------------  # Date: Thu, 29 Nov 2001 23:39:42 GMTaL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")? Subject: Re: New product allows VMS to become part of a PC Lan!W8 Message-ID: <00A05C74.87391EAA@SSRL04.SLAC.STANFORD.EDU>  ` In article <td1c0ugl6075tq6p0tqjp2hhm8g7b393ed@4ax.com>, Alan Greig <a.greig@virgin.net> writes:G >On 28 Nov 2001 08:36:22 -0600, koehler@encompasserve.org (Bob Koehler)@ >wrote:d >cj >>In article <d7791aa1.0111271509.4f1bf490@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes: >>G >>> Just ran across this amazing product as we were looking to make ourc	 >>> AlphafC >>> VMS system part of our local PC Lan and ran across this amazing. >>> product ...oI >>> they also have a product that allows VMS pc disk access ... amazing! o >>> here ish( >>> the link if anyone is interested ... >>J >>   Nothing like being 15 years behind the times, and 10 years behind the >>   freeware. > G >I thought at first surely this is just Pathworks or Samba but actually G >the product Bob describes allows VMS systems to access NT print queues A >and shares which is the reverse of the functionality provided bycD >Pathworks and Samba. Although I have heard that Samba may have some6 >ability to allow a user to access NT shares from VMS.  H Last I looked, Samba included a utility called SMBCLIENT which could do I FTP-like things over SMB.  (You couldn't run a program on VMS that openediI a file on an NT share, but you could use SMBCLIENT to copy a program from J the NT share to VMS disk and then mess with it. (And vice versa, but sinceA Samba opens VMS disk to NT access, you usually wouldn't want to.)o   -- Alan (not Greig, Winston)  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056eM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-02105O ===============================================================================t   ------------------------------  % Date: Thu, 29 Nov 2001 16:37:56 -0600aC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>r' Subject: Re: new to VMS cxx question...oI Message-ID: <craig.berry-3FD246.16375629112001@newsrump.sjc.telocity.net>.  F Rather surprisingly, a VMS filespec does not appear to be a supported ! value for the /include qualifier:s   $ help cxx/include   CXXu  &   /INCLUDE_DIRECTORY=(pathname [,...])  >      /NOINCLUDE_DIRECTORY               D=/NOINCLUDE_DIRECTORY  D      Provides an additional level of search for user-defined includeE      files.  Each pathname argument can be either a logical name or a-4      legal UNIX-style directory, in a quoted string. <snip>  5 So, it looks like you either need to define a logicalt  ; $ define myincdir $1$DGA41:[EBUS.XML.XERCES-C-SRC1_3_0.SRC]a $ cxx/include=myincdir   or use UNIX filespec syntax,  7 $ cxx/include="$1$DGA41/EBUS/XML/XERCES-C-SRC1_3_0/SRC"S  F Note that it is not customary (and in some cases just wrong) to refer A to a disk by its physical device name.  There may be one or more i' logical names that would be preferable.e    = In article <70a82a12.0111290855.2f59ef57@posting.google.com>,s1  jeremy.lakey@ndchealth.com (jeremy lakey) wrote:-  : > I've got the compaq xml libraries loaded...   they're at > $1$dga41:[ebus.xml]0 > ( > how do i include that path as headers? > B > cxx /include_directory=$1$DGA41:[EBUS.XML.XERCES-C-SRC1_3_0.SRC]
 > testxml.cpp3 > ? > does not work... i've tried to define it as a system include:  > $show logical cxx*G >    "CXX$SYSTEM_INCLUDE" = "$1$DGA41:[EBUS.XML.XERCES-C-SRC1_3_0.SRC]"  > H > that doesn't work..  i'm new to cxx and vms (as in just this week new)E > but i've read all the documentation at www.openvms.compaq.com i cana= > find and other than using /include_directory i'm still loste > ( > any help would be greatly appreciated. >  > Thanks >  > Jeremy Lakey > Software Architect > NDC Health   ------------------------------  % Date: Thu, 29 Nov 2001 16:09:18 -0600cC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>WM Subject: Re: Offtopic: cross platform portability tools - a study of autoconf-I Message-ID: <craig.berry-E42D38.16091829112001@newsrump.sjc.telocity.net>c  3 In article <ljeN7.2072$RL6.63139@news.cpqcorp.net>, 4  hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote:  # >   AUTOCONF is somewhat of a crocka  G I prefer to call it MEINCONF since it has fantasies of taking over the a2 world and murdering anything that's different :-).  * In article <3C05CC77.1060906@qsl.network>,/  "John E. Malmberg" <wb8tyw@qsl.network> wrote:n   > Michael Joosten wrote:J >  > But, still, it should be possible to have VMS 'profiles' which simply; >  > detail which functionality is available and which not.n > J > It is an issue of maintaining the 'profiles'.  The problem is that we doK > not know in advance what small snippet of information that the configure t > script will be looking for.   E Perhaps it goes without saying that "functionality" consists of more tF than a list of functions, or in other words that list of functions -- H whether generated by autoconf or by rummaging through the C run-time or % headers -- is not the whole story.   t  E An example may illustrate.  In Perl, the configuration script checks yC for the presence of the flock() function, and if it's not present, uE attempts to emulate it using fcntl().  If fcntl() is not present, it ,H gives up the ghost and says it can't do it.  This worked fine for years G on VMS because neither function was present in the C RTL. Then one day .G a new OpenVMS C RTL appeared with an fcntl() function in it.  However, t= this fcntl() doesn't do locking, only the other file control  B operations, even though the locking operations are defined in the H fcntl.h header.  Things compiled fine but then blew up at run-time when C calling fcntl() with unsupported operations.  So we had to write a iG separate test to figure out whether fcntl() could do locking, set up a nE new macro FCNTL_CAN_LOCK, and jigger the code to test for this macro.   F And then there are those cases where you get impatient with the C RTL E and decide to roll your own function, such as if we decided to write -G our own flock() ( or steal the one from FRONTPORT ;-) ).  In this case S@ the configuration would have to be hard-wired to say we have it.  J >  > hand-crafted config.h.vms, it should be possible to solve most of theD >  > #define HAS_XXX_H or #define HAS_XXX by a static profile with aB >  > (perhaps DCL proc) that parses config.h.in, compares the used? >  > HAS_ XXX with the profiles and fills in the right answers., > I > The information is already in the Compac C header files.  However it isoE > not easy to detect if the feature is only available for a specific .D > version of OpenVMS with out actually writing a program to let the , > compiler determine if the option is there.  A It has occurred to me that a matrix of HAS_xxxx macros listed by eH compiler version, C RTL version, VMS version, and hardware architecture H would be nice to have, but then to generate such a matrix you'd have to G have a program that did all the tests, and then you might as well just g use the program.   > [make file generation]7 >  Any tool can be used, it is just that the resulting pG > makefile or mms script will not really have much relationship to the   > source template.  G Does anyone use MMS/GENERATE for such things?  At first blush, I don't gF see a way to make it work when the target is a library rather than an 4 executable based on a source file with "main" in it.   ------------------------------  % Date: Thu, 29 Nov 2001 22:06:05 +0000m% From: Alan Greig <a.greig@virgin.net> 7 Subject: Re: OT: Andrew Harrison : Alive & Still At SUNl* Message-ID: <3C06B14D.E5737AF4@virgin.net>   Bill Gunshannon wrote:  F > Actually, many offices prohibit the use of these facilities from theB > office LAN using social pressures rather than technical methods.B >   "Any non-company use of the corporate LAN will get you fired!" >c  ; Yes but surely not for an "Enterprise Archictect" with Sun!i --
 Alan Greig   ------------------------------  # Date: Thu, 29 Nov 2001 23:47:22 GMTnL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")7 Subject: Re: OT: Andrew Harrison : Alive & Still At SUNb8 Message-ID: <00A05C75.9966BDAC@SSRL04.SLAC.STANFORD.EDU>  ` In article <9u5puh$19so$2@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:9 >In article <81bc0u0h7ij31dqaolktm8dfct3gh33cle@4ax.com>,o) > Alan Greig <a.greig@virgin.net> writes:sD >|> On 28 Nov 2001 18:47:58 GMT, leslie@clio.rice.edu (Jerry Leslie)
 >|> wrote: >|> H >|> >I got a reply from Andrew from an email to Andrew.Harrison@Sun.COM.D >|> >He's switched offices and doesn't have access to a NNTP server. >|> I >|> And presumably email which somehow blocks info-vax and browsers whichS >|> somehow block deja/google. >|>  >iE >Actually, many offices prohibit the use of these facilities from theuA >office LAN using social pressures rather than technical methods.eA >  "Any non-company use of the corporate LAN will get you fired!"l >t. >My sister works in just such an organization.  K But Sun (at least in California) is not such an organization, or at least I J know a couple of people in Sun's docs group who post freely on Usenet, and1 have assured me that there's no problem doing so.i   -- Alan   O ===============================================================================00  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-30561M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210eO ===============================================================================    ------------------------------  # Date: Fri, 30 Nov 2001 03:50:24 GMTr1 From: "David J. Dachtera" <djesys.nospam@fsi.net>h; Subject: Re: patch downloads - 3rd time lucky & compression.' Message-ID: <3C070202.B049DC16@fsi.net>    Chris Sharman wrote: > % > > What does everyone use for this ?eM > > We've got an ISDN line, and I tried to fetch the dce 3.0 u1 eco yesterdaynL > > evening (via ie5.0 on my pc) - this morning it had given up at 4.9M. I'mN > > trying again now with copy/ftp/bin from vms (7.3, tcpip 5.1-3) -  it seemsM > > to have stalled at 8-8.5M (the file's not grown, and the process has doneA > noK > > I/O in half an hour), so I presume it's going to give up again. Perhapse > I'll; > > get lucky at my third attempt - a bargain at 25M total.s > M > Finally, on my 3rd attempt (7.3, tcpip 5.1-3, mgftp 2.6-5) I got it in juste > over 40 minutes.M > mgftp has a nice ^T response, but apart from that I don't know whether it's- > faster or better > or whether I was just lucky. > M > > The patch is 12.4M (with the dismal DCX compression). I've seen kits witheL > > SFX compression - much better and therefore much more likely to download; > > first time - why are Compaq not using it all the time ?e >  > Uncompressed: 42720 blocks > dcx_axpexe: 25501  > zip/gz: 16902  > / > Seems like a large & worthwhile saving to me.aL > It usually is. Indeed, this file seems to have compressed better than mostJ > with DCX, but it still doesn't compare with zip/gzip (which is I believe  > similar to the sfx algorithm).  E If by "sfx" you mean UNZIPSFX, this program is product of running therE LINK.COM procedure in the UNZIP distribution as available from HunteriG Goatley's freeware site (fka "FILESERV"). So, you could say it uses the " same "algorithm" as ZIP and UNZIP.  0 GZIP, however, is a slightly different creature.   --   David J. Dachterat dba DJE Systemsr http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------    Date: 29 Nov 2001 14:11:23 -0800/ From: prosullivan@hotmail.com (paul o'sullivan)-/ Subject: Re: Pawz software and Capacity Plannera= Message-ID: <5a24d880.0111291411.1b3676e3@posting.google.com>h  h koehler@encompasserve.org (Bob Koehler) wrote in message news:<rEHuSLDFez9c@eisner.encompasserve.org>...Z > In article <3C01AF00.1060403@Mediaone.net>, John Polcari <JPolcari@Mediaone.net> writes:L > > I am shopping around for some performance tools that might help make my K > > job a little easier, does anybody know and would recommend a goof peicerK > > of software that runs on a Alpha Openvms system, running 7.1 of VMS. I 9I > > was checking out Capacity Planner and also pawzs, are these products G. > > worth pursuing or should I look elsewhere? > @ >    I really like MONITOR.  Points to the source of most gross 0 >    performance problems and never costs extra.  F You have to be aware of what you really need: you can use CA DECps forF performance analysis but not for capacity planning (CA Unicenter above- 2.0-53 not supported under Capacity Planner).0  D If you want to do 'proper' capacity planning, then you will need theF PerfCap Performance Monitor for VMS and Capacity Planning. This offersC the extra collectors necessary for the Capacity Planner to read VMSf= data. I do not think the 'free' VMS ECP collector offers this 	 facility.   F For large numbers of systems (and for cross platform), I prefer to use PAWZ and Capacity Planner.   ------------------------------  # Date: Fri, 30 Nov 2001 03:42:27 GMT - From: goathunter@goatley.com (Hunter Goatley)e Subject: Re: PGP for OpenVMS0 Message-ID: <3c06ffe0.12606116@news.process.com>  N On Wed, 28 Nov 2001 23:37:31 GMT, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote:  } >In article <8af17fe1.0111281322.5d061777@posting.google.com>, alphaman-nixspam@hsv.sungardtrust.com (Aaron Sakovich) writes: G >:Yes, it does.  A Google groups search of comp.os.vms for gnupg should2H >:turn up some pointers from myself and Dave Mathog regarding his port. E >:This program is compatible with current revs of PGP and runs rathertF >:nicely on OpenVMS.  It is also many years newer than the 2.6 version >:of PGP for OpenVMS!p >sO >  And y'all were planning on submitting it to the OpenVMS Freeware _when_? :-)a >?K >  But rather more seriously, the US regulations around the exportation of iL >  encryption have changed in recent times, and I should be able to provide K >  versions of most open-source encryption packages -- those with less thanoG >  the military-grade encryption threshold -- via the OpenVMS Freeware.a >cK Since David doesn't do VMS these days, I picked up a copy of all his files, I but haven't had time to do anything with them yet.  David's port of GNUPGm can be found here:  * ftp://ftp.process.com/vms-freeware/mathog/   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/k9 goathunter@goatley.com     http://www.goatley.com/hunter/    ------------------------------  % Date: Fri, 30 Nov 2001 07:08:56 +0100 , From: Didier Morandi <Didier.Morandi@gmx.ch>" Subject: Rdb 7.0.6 and sql$070.exe& Message-ID: <3C072278.26C7DB0F@gmx.ch>  P I have copied yesterday from the ORACLE site a (public?) release of the previousP version of Rdb, 7.0.6. I installed it on a "destructive tests Alpha system". All# went fine, Rdb IVP, SQLNET IVP etc.o  N I tried sql$070 and immediately got "error 129021103" something (don't have it2 home) stuck to my cursor. ^Z terminates the image.   Why?  I Btw, The Rdb conference seems not to be very visited (by technicians)... . Thanks,    D.   ------------------------------  # Date: Thu, 29 Nov 2001 19:35:29 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)! Subject: Re: RECALL does not work 3 Message-ID: <56wN7.2123$RL6.63344@news.cpqcorp.net>a  g In article <1007025593.127337@mozart.adv.magwien.gv.at>, "Ferry Bolhar" <bol@adv.magwien.gv.at> writes:i  K :In a procedure, I do not want to save user input (requested by INQUIRE) ino :the DCL recall buffer.   F   INQUIRE is an incredibly powerful and perverse command, and one thatF   should be left only to DCL magicians -- I cannot and do not use thisI   DCL command myself, save for very specific and very rare circumstances. B   I use READ, and typically READ/PROMPT="text" SYS$COMMAND SYMBOL.  G :...However, [RECALL] does not work when invoked from the procedure. No-G :File X.X is created and user input is still in the recall buffer. WhenNA :entering these commands interactively, it behaves as expected...p  I   This is documented and intentional behaviour.  RECALL and SET HOST and AH   a few other DCL commands are intended (only) for interactive use only.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Thu, 29 Nov 2001 21:48:11 GMTt" From: "Hans Vlems" <hvlems@iae.nl>! Subject: Re: RECALL does not works0 Message-ID: <v2yN7.2467$Dp.7723@typhoon.bart.nl>  " $ help recall gives (VAX/VMS 7.2):   RECALL    E      Displays up to 254 previously entered commands on the screen for>      subsequent execution.        Formaty  "        RECALL  [command-specifier]  J "commands entered on the screen", well you can't get more interactive that that....   Hans  5 Ferry Bolhar <bol@adv.magwien.gv.at> wrote in messageP2 news:1007041623.962597@mozart.adv.magwien.gv.at... > > > In a procedure,y > > >o > > > $ RECALL/OUTPUT=X.Xs > > >ME > > > However, this does not work when invoked from the procedure. NouL > > > File X.X is created and user input is still in the recall buffer. WhenD > > > entering these commands interactively, it behaves as expected. > > >o* > > > Does someone know what happens here? > >tG > > It is documented that RECALL only works interactively, not in a DCLl > > procedure. >.K > Where? I didn't find this information, neither in the online help, nor in= > the DCL dictionary.= >=K > And this restriction isn't a useful one, IMHO. RECALL with /ERASE, /INPUTI orK > /OUTPUT should be allowed in DCL procedures (eg., the recall buffer couldt be" > pre-initialized from LOGIN.COM). >R > Greetings, Ferry > ---= >= > Ing. Ferry Bolhar=' > Municipality of Vienna, Department 14= > A-1010 Vienna / AUSTRIA- > E-mail: bol@adv.magwien.gv.at0 >1 >7 >  >0   ------------------------------  % Date: Thu, 29 Nov 2001 18:34:07 -0500u( From: David Froble <davef@tsoft-inc.com>! Subject: Re: RECALL does not work6, Message-ID: <3C06C5EF.6040301@tsoft-inc.com>   Hans Vlems wrote:f  $ > $ help recall gives (VAX/VMS 7.2): >  > RECALL >  > G >      Displays up to 254 previously entered commands on the screen fora >      subsequent execution. > 
 >      Format  > $ >        RECALL  [command-specifier] > L > "commands entered on the screen", well you can't get more interactive that
 > that.... >  > Hans > 7 > Ferry Bolhar <bol@adv.magwien.gv.at> wrote in messagei4 > news:1007041623.962597@mozart.adv.magwien.gv.at... >  >>>>In a procedure,i >>>> >>>>$ RECALL/OUTPUT=X.XA >>>>C >>>>However, this does not work when invoked from the procedure. No J >>>>File X.X is created and user input is still in the recall buffer. WhenB >>>>entering these commands interactively, it behaves as expected. >>>>( >>>>Does someone know what happens here? >>>>F >>>It is documented that RECALL only works interactively, not in a DCL
 >>>procedure.2 >>>2K >>Where? I didn't find this information, neither in the online help, nor ine >>the DCL dictionary.t >>K >>And this restriction isn't a useful one, IMHO. RECALL with /ERASE, /INPUTo >> > or > K >>/OUTPUT should be allowed in DCL procedures (eg., the recall buffer couldS >> > be > " >>pre-initialized from LOGIN.COM).  C Speculating.  I'd think that RECALL is implemented in the terminal xE driver, and such is not used in batch jobs, thus no capability there.R   Dave   -- t4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Fri, 30 Nov 2001 03:46:44 GMTe1 From: "David J. Dachtera" <djesys.nospam@fsi.net> ! Subject: Re: RECALL does not work0' Message-ID: <3C070126.E49584D5@fsi.net>@   Hoff Hoffman wrote:o > [snip]J >   This is documented and intentional behaviour.  RECALL and SET HOST andJ >   a few other DCL commands are intended (only) for interactive use only.  F ...even though their being useful in batch jobs could solve many, manyC problems, not the least of which is commanding HSx controllers from @ within, for example, BACKUP automation (splitting/reconstituting mirror-sets, etc.).o   --   David J. Dachterat dba DJE Systems- http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Fri, 30 Nov 2001 03:47:16 GMTV- From: goathunter@goatley.com (Hunter Goatley)u! Subject: Re: RECALL does not workn0 Message-ID: <3c0700e8.12870116@news.process.com>  M On Thu, 29 Nov 2001 18:34:07 -0500, David Froble <davef@tsoft-inc.com> wrote:n  D >Speculating.  I'd think that RECALL is implemented in the terminal F >driver, and such is not used in batch jobs, thus no capability there. >sH The terminal driver does support command-line recall, but only one line.H DCL's RECALL buffer is pure DCL code.  (I used to have (well, it's stillD there, but few people need it these days) a program that would patchD DCL to extend the command recall buffer from 20 commands to 63 (VAX) or more (Alpha).   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/t9 goathunter@goatley.com     http://www.goatley.com/hunter/o   ------------------------------  % Date: Thu, 29 Nov 2001 21:44:09 -0500R* From: "Stanley F. Quayle" <stan@stanq.com>+ Subject: Re: RECALL does not work (& XDMCP),. Message-ID: <3C06AC29.20894.9F75B89@localhost>  - On 29 Nov 2001, at 19:35, Hoff Hoffman wrote:oK >   This is documented and intentional behaviour.  RECALL and SET HOST and uJ >   a few other DCL commands are intended (only) for interactive use only.  7 Which is why XDMCP logins should be set as INTERACTIVE?t    
 --Stan Quayleo! President, Quayle Consulting Inc.T  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671s1 8572 North Spring Ct. NW, Pickerington, OH  43147i= Preferred address:  stan@stanq.com       http://www.stanq.com    ------------------------------  % Date: Thu, 29 Nov 2001 13:59:20 -0500h; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>.N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org$ Message-ID: <3c06858f$1@news.si.com>  D >As long as you're believing people who tell you things that are notE >believable, here's another one for you. In 6 years I will personallynD >invent a CPU that will outperform anything Intel makes at that timeE >by a factor of 17 times and it will use a quarter the power and costo# >less than half as much to produce.s  H And you'll be able to make it out of old US pennies in a vending machine: stamper, like the "flat penny" souvenirs found at arcades. --A Brian Tillman                   Internet: tillman_brian at si.comsA Smiths Aerospace                          tillman at swdev.si.com,= 3290 Patterson Ave. SE, MS      Addresses modified to preventr< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Thu, 29 Nov 2001 19:16:48 GMTl* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <AQvN7.83321$uB.13165011@bin3.nnrp.aus1.giganews.com>b  J I didn't bother responding to this the first time you posted it because itI contained so little new material.  But I guess there are one or two itemsr that merit comment:i   ...n  - > >   Even if Compaq changed its mind at this&H > > > point the tenuous credibility that Alpha had in the marketplace is gone.t > > D > > Your opinion, of course.  The predominant reaction here suggests > otherwise,L > > though in terms of *momentum* (as distinct from credibility) it would ofE > > course have been far better had Compaq not screwed up so royally.f >aL > Perception is reality and the perception of the ISV's is what drives theseJ > markets.  Few ISV's will bet major dollars on Alpha and Tru64 after what hasD > happened.i  J You missed the distinction I was making between Alpha's *credibility* (theL feeling that current Alphas, and new Alphas when they appear, will be worthyI platforms to run on) and its *momentum* (which wasn't that great to starthL with and took a fatal hit five months ago - but could pick up again if a newL corporate shoulder were solidly placed behind it).  If people had lost faith= in Alpha's *quality*, that might well truly be irrecoverable.a  H But let's assume you meant what I'm calling 'momentum'.  You should noteH that your comments apply at least as much to VMS as they do to Alpha andL Tru64.  Unlike Alpha and Tru64, the common perception is that VMS died yearsH ago, which is why few ISVs will bother porting their VMS applications toK Itanic (since there's no reason to believe that its customer base will evennI match the current one:  Compaq's corporate shoulder has never been behindiK VMS, and this shows absolutely no sign of changing).  Even before June 25thsD the VMS ISV base was dwindling, and the external perception of VMS'sH viability (among those few who still had any such perception at all) has' gone down-hill dramatically since then.o  H That's why nothing short of a corporate brain-transplant has any hope ofE even restoring VMS's perceived viability to its pre-June-25th levels:UK current management has a far too consistent track record in its handling of5J VMS for any change by them to be considered at all worthy of trust (which,I for that matter, applies to just about any other stance they might take).=   ...=  K > > I'll spell out the current problem once more, because you still seem to ; > > have no grasp of it (let alone the associated details):R > >tK > > It's the cancellation of Alpha.  Period.  This was an incredibly stupidfF > > move, because it  a) immediately turned one of the most profitable product H > > lines Compaq has into yet another struggling one,  b) in the process > likelyH > > cost more money than eliminating development will save over the same > periodJ > > (let alone the cost in future sales),   c) cut VMS's its nascent salesK > > up-turn off at the knees (thus putting yet another stake into the heart  ofL > > its already-fragile long-term viability)  d) did similar damage to Tru64H > > (though the merger now shows signs of turning that lingering illness into >y > aaF > > more precipitous demise), and  e) highlighted the fact that CompaqK > > management are incompetent weasels with whom at least many people wouldr > not ; > > choose to do business given any reasonable alternative.h >aL > "A" above is flat out not true.  I have seen the internal numbers and whatK > the Alpha servers have been contributing in profits over the last severalsK > years is significantly below two other groups.  Sorry but the information2 Il > saw I can't release.  J You don't have to, because it's pretty obvious:  service and storage, whenI viewed in the right light (i.e., as business units that don't owe a large K portion of their revenue to Alpha's existence), can appear that way.  Or if K you want to talk margins the Tandem division may qualify (though since they H were indicated as bringing in less than 1/3 the total revenue that AlphaK systems did as of a Compaq presentation last March they clearly don't matcho Alpha's total profits).e  L The problem with treating service and storage as separate from Alpha is thatL without Alpha they'd be far smaller than they are.  It is, however, possibleJ to compare Alpha-system-related profit to Tandem-system-related profit andF industry-standard-server-related profit (and we won't even bother withE PC-related profit, since it's effectively non-existent).  And in thateL apples-to-apples comparison, Alpha stands far above the others (for the lastG several years, which was *your* choice of time-scale; the only time ISS:? profits have threatened it was during the dot-com boom of Y2K).0   - bill   ------------------------------   Date: 29 Nov 2001 19:29:39 GMT* From: bdwheele@indiana.edu (Brian Wheeler)N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org3 Message-ID: <9u62b3$tlv$1@flotsam.uits.indiana.edu>a  $ In article <3c06858f$1@news.si.com>,> 	"Brian Tillman" <tillman_brian@notnoone.notnohow.com> writes:E >>As long as you're believing people who tell you things that are not F >>believable, here's another one for you. In 6 years I will personallyE >>invent a CPU that will outperform anything Intel makes at that timehF >>by a factor of 17 times and it will use a quarter the power and cost$ >>less than half as much to produce. > J > And you'll be able to make it out of old US pennies in a vending machine< > stamper, like the "flat penny" souvenirs found at arcades.  K There's a railroad that runs behind my house...could I make cheap clones byn placing pennies on the tracks?   Brian    ------------------------------  # Date: Thu, 29 Nov 2001 20:48:10 GMTi& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <eaxN7.1271$h24.111577@typhoon1.gnilink.net>  8 I having a problem with my ISP doubling posting stuff...  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagew; news:AQvN7.83321$uB.13165011@bin3.nnrp.aus1.giganews.com...dL > I didn't bother responding to this the first time you posted it because itK > contained so little new material.  But I guess there are one or two itemsa > that merit comment:, >  > ...A >o/ > > >   Even if Compaq changed its mind at this2J > > > > point the tenuous credibility that Alpha had in the marketplace is > gone.o > > > F > > > Your opinion, of course.  The predominant reaction here suggests > > otherwise,K > > > though in terms of *momentum* (as distinct from credibility) it wouldl ofG > > > course have been far better had Compaq not screwed up so royally.B > >tH > > Perception is reality and the perception of the ISV's is what drives these L > > markets.  Few ISV's will bet major dollars on Alpha and Tru64 after what > hasp
 > > happened.p >nL > You missed the distinction I was making between Alpha's *credibility* (theG > feeling that current Alphas, and new Alphas when they appear, will be, worthyK > platforms to run on) and its *momentum* (which wasn't that great to start J > with and took a fatal hit five months ago - but could pick up again if a neweH > corporate shoulder were solidly placed behind it).  If people had lost faithe? > in Alpha's *quality*, that might well truly be irrecoverable.r > J > But let's assume you meant what I'm calling 'momentum'.  You should noteJ > that your comments apply at least as much to VMS as they do to Alpha andH > Tru64.  Unlike Alpha and Tru64, the common perception is that VMS died yearsOJ > ago, which is why few ISVs will bother porting their VMS applications toH > Itanic (since there's no reason to believe that its customer base will evenK > match the current one:  Compaq's corporate shoulder has never been behind H > VMS, and this shows absolutely no sign of changing).  Even before June 25thF > the VMS ISV base was dwindling, and the external perception of VMS'sJ > viability (among those few who still had any such perception at all) has) > gone down-hill dramatically since then.c >sJ > That's why nothing short of a corporate brain-transplant has any hope ofG > even restoring VMS's perceived viability to its pre-June-25th levels:aJ > current management has a far too consistent track record in its handling ofL > VMS for any change by them to be considered at all worthy of trust (which,K > for that matter, applies to just about any other stance they might take).n >n > ...  >hJ > > > I'll spell out the current problem once more, because you still seem to= > > > have no grasp of it (let alone the associated details):  > > > F > > > It's the cancellation of Alpha.  Period.  This was an incredibly stupidH > > > move, because it  a) immediately turned one of the most profitable	 > product J > > > lines Compaq has into yet another struggling one,  b) in the process
 > > likelyJ > > > cost more money than eliminating development will save over the same
 > > periodL > > > (let alone the cost in future sales),   c) cut VMS's its nascent salesG > > > up-turn off at the knees (thus putting yet another stake into the- heart- > ofH > > > its already-fragile long-term viability)  d) did similar damage to Tru64 J > > > (though the merger now shows signs of turning that lingering illness > into > >f > > ahH > > > more precipitous demise), and  e) highlighted the fact that CompaqG > > > management are incompetent weasels with whom at least many peoplen would" > > noti= > > > choose to do business given any reasonable alternative.2 > >pI > > "A" above is flat out not true.  I have seen the internal numbers and  whatE > > the Alpha servers have been contributing in profits over the lasts several A > > years is significantly below two other groups.  Sorry but the  informatione > In > > saw I can't release. >gL > You don't have to, because it's pretty obvious:  service and storage, whenK > viewed in the right light (i.e., as business units that don't owe a large J > portion of their revenue to Alpha's existence), can appear that way.  Or ifH > you want to talk margins the Tandem division may qualify (though since theyJ > were indicated as bringing in less than 1/3 the total revenue that AlphaG > systems did as of a Compaq presentation last March they clearly don'to match  > Alpha's total profits).  >tI > The problem with treating service and storage as separate from Alpha isc thatE > without Alpha they'd be far smaller than they are.  It is, however,l possibleL > to compare Alpha-system-related profit to Tandem-system-related profit andH > industry-standard-server-related profit (and we won't even bother withG > PC-related profit, since it's effectively non-existent).  And in thatMI > apples-to-apples comparison, Alpha stands far above the others (for they lastI > several years, which was *your* choice of time-scale; the only time ISS.A > profits have threatened it was during the dot-com boom of Y2K).h >2 > - bill >: >0 >0   ------------------------------  # Date: Thu, 29 Nov 2001 20:59:32 GMTn& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <UkxN7.1413$s06.139773@typhoon2.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagec; news:AQvN7.83321$uB.13165011@bin3.nnrp.aus1.giganews.com...cJ > But let's assume you meant what I'm calling 'momentum'.  You should noteJ > that your comments apply at least as much to VMS as they do to Alpha andH > Tru64.  Unlike Alpha and Tru64, the common perception is that VMS died years J > ago, which is why few ISVs will bother porting their VMS applications toH > Itanic (since there's no reason to believe that its customer base will evenK > match the current one:  Compaq's corporate shoulder has never been behind H > VMS, and this shows absolutely no sign of changing).  Even before June 25thF > the VMS ISV base was dwindling, and the external perception of VMS'sJ > viability (among those few who still had any such perception at all) has) > gone down-hill dramatically since then.   J Compaq is going to need to find niches for OVMS that has applications thatL unquestionably benefit from OVMS.  Unless they do so I agree the spiral willE continue.  They need to find something like ZLE was to NSK.  "Me too"mG applications won't do it. Note I said "Compaq is going to need to find" K which means pro-active and not hoping something will drop into their lap...e  I > The problem with treating service and storage as separate from Alpha isa thatE > without Alpha they'd be far smaller than they are.  It is, however,  possibleL > to compare Alpha-system-related profit to Tandem-system-related profit andH > industry-standard-server-related profit (and we won't even bother withG > PC-related profit, since it's effectively non-existent).  And in thatCI > apples-to-apples comparison, Alpha stands far above the others (for then lastI > several years, which was *your* choice of time-scale; the only time ISS A > profits have threatened it was during the dot-com boom of Y2K).i  J Service likely but I don't know about storage - the long term hit might be less then you think...   ------------------------------  # Date: Thu, 29 Nov 2001 21:02:47 GMTo& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <XnxN7.1416$s06.142966@typhoon2.gnilink.net>  L By "spiral" I mean the _number_ of applications that make OVMS a platform of choice for a given application.1  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageu2 news:UkxN7.1413$s06.139773@typhoon2.gnilink.net...L > Compaq is going to need to find niches for OVMS that has applications thatI > unquestionably benefit from OVMS.  Unless they do so I agree the spiralA willG > continue.  They need to find something like ZLE was to NSK.  "Me too",I > applications won't do it. Note I said "Compaq is going to need to find"nF > which means pro-active and not hoping something will drop into their lap...   ------------------------------  % Date: Thu, 29 Nov 2001 22:47:55 -0500 ' From: Howard S Shubs <howard@shubs.net>n Subject: TLZ09< Message-ID: <howard-DCC8E8.22475529112001@enews.newsguy.com>  . What are the features of this 4mm tape device? -- s Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  # Date: Thu, 29 Nov 2001 21:40:55 GMTF  From: jlsue <jlsuexxxz@home.com>N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))8 Message-ID: <5nad0u49khkb4j542jhu7eplsmdnsi3rgg@4ax.com>  = On 28 Nov 2001 16:45:35 GMT, jfc@mit.edu (John F Carr) wrote:   = >In article <3C051224.4A2BB9CC@videotron.ca>, JF Mezei wrote:i >rO >>Why is someonone on Tru64 ? Well, some percentage are on Tru64 because it has P >>clustering that is better than other unixes.  Move that bit to HP-UX and HP-UXP >>has clustering that is better than other unixes. So where will those customers >>move ? to HP-UX. >4= >Moving clustering to HP-UX may take years of work by a largeo? >team of senior software engineers.  That's what it took to get:? >clustering working on Tru64.  (That's _after_ there was a codeh@ >base to start from, although I'm not sure starting with nothing >would have been slower.)s  F I would also add that, although I have no personal experience in HP-UXB matters, I have heard that HP-UX is fairly difficult/tricky to add drivers for.  B There's something in there as a way of explanation for the lack of< HP-UX SecurePath drivers for the StorageWorks SAN offerings.  F I have no personal knowledge of any of this, only a rumor I heard once upon a time.  1 Not speaking for anyone, certainly not DEC/Compaqi- (get rid of the xxxz in my address to e-mail)u   ------------------------------  % Date: Fri, 30 Nov 2001 07:25:45 +0100  From: zessin@decus.desN Subject: RE: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))* Message-ID: <00A05CF8.B08951AB.9@decus.de>   jlsue wrote:H > I would also add that, although I have no personal experience in HP-UXD > matters, I have heard that HP-UX is fairly difficult/tricky to add > drivers for. >6D > There's something in there as a way of explanation for the lack of> > HP-UX SecurePath drivers for the StorageWorks SAN offerings. >sH > I have no personal knowledge of any of this, only a rumor I heard once > upon a time.  G I haven't worked with HP-UX either, but Compaq has SecurePath Version 3 9 for it _now_ and the list of features doesn't look bad...rB     http://www.compaq.com/products/sanworks/secure-path/hp-ux.html   --  
 Uwe Zessin   ------------------------------  % Date: Thu, 29 Nov 2001 22:54:57 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch>h. Subject: Walter Hewlett's report on the merger5 Message-ID: <3C06AEB1.B6171257@swissonline.delete.ch>f  E My apologies if this has already appeared in this newsgroup.  I tried 5 searching for Hewlett in the subject and got no hits.S  D And sorry about the fragmented nature; it's not easy to summarise orB transcribe parts of a 5Mb document which refuses to cut-and-paste.      G Hewlett-Packard has submitted Walter B Hewlett's negative assessment oftE the merger to the SEC.  This is the document containing the report tor5 the Trustees of the William R Hewlett Revocable Trustt   It's a large document (5Mb) atJ http://www.sec.gov/Archives/edgar/data/47217/000089161801502286/f77263dfd=
 fan14a.htm   (Mind the possible wrap)  F For anyone who is not inclined to wait for it to download, here's some of the major points.    =46rom the Executive Summary =85  / The merger is unattractive to the Trust becausesB - Resulting business portfolio is worse than existing HP portfolio4 - Acquisition will not solve HP's strategic problems! - Integration risk is substantialr5 - Financial impact on HP shareholders is unattractive'  C In particular it notes the problems of increased exposure to the PCrF market, the lack of benfit it brings to HP's printing business and theG fact the the combined entity would be stuck between Dell at one end andM Sun & IBM at the other.     @ In regard to the Acquisition not solving HP's strategic problems@ - market dynamics (of PC market) are unattractive and trends are	 worseninghE - HP is challenged by lack of direct channel and inventory managementyF - Compaq has similar problems to HP (and its PC operating margins were lower than HP 98 to 2000)t3 - Dell's operating margins are significantly betterg    : The merger will harm HP's position in Imaging and Printing% - but margins in those areas are fineiF - increases in demand from Compaq's part of the business may be offset by PC losses    D The combined company does not provide HP with a significantly better Enterprise strategya9 - Both companies are losing their market share in serverspD - Compaq's strongest position is in the less-attractive entry server marketG - HP can address mid and high range by itself (and outsells Compaq by at factor of 4.5 in Unix) =  E - Compaq's storage is a strong but minor part of their total businessv  D (In this part of the document it points out that 2nd Q 2000 to 2nd QG 2001 Compaq's growth in the unix server market was -13.6% and Sun's waseA -24.2% while HP's was -14%.  In Windows, Compaq fell 24.0% and HPe= 24.5%.  In Linux Compaq fell 14.8% while IBM increased 40.7%)4   It also states in this sectionD - DEC and Tandem services are profitable but shrinking (quote from aA Bank of America report which forecast Compaq's "Business CriticalaH Server" revenue at $2.5 billion in 2001 to fall to $2.0 billion in 2002)F - "Professional services remain Compaq's Achilles heel, and the notionH of unfulfilled promises of Digital's Services is still haunting Compaq".    " 3. Integration risk is substantial  E "The main beneficiaries of mergers in the computer industry have beenoB competitors, because companies become so focused on organizationalE matters that they lose sight of their customers." - Ben ROSEN, Compaqa) (1991 statement about AT&T acquiring NCR)a  G - Report from SG Cowen estimates an 11% deterioration of revenue in the'- "Enterprise" sector if the merger goes ahead.   ? - Concern that the merger is bigger than either company has anyt experience with.  =  E - Points out that Compaq's purchase of Digital did not meet analysts'oH expectations.  (Average estimated share value was $1.93 when the reality was less than $0.65)    F All up I'd describe it as an interesting document, well researched and
 presented.  - (And I do like that quotation of Ben Rosen !)r     John McLeanm   ------------------------------    Date: 29 Nov 2001 13:58:34 -0800( From: bob@instantwhip.com (Bob Ceculski)= Subject: Re: why not a communityDeveloped[tm] version of VMS?e= Message-ID: <d7791aa1.0111291358.54eb6760@posting.google.com>o  | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KBA3YGVU7C90YLDV@sysdev.deutsche-boerse.com>...D > > Wouldn't the intervening period be good to either duplicate from > > scratch- > K > Calculate how many person-years have gone into VMS.  Do you really think eG > that you can muster those resources?  The comparison with Linux is a sH > no-go; that some students can throw something together in their spare E > time which rivals commercial unix says something about the lack of _K > quality of commercial unix, not about the ease of creating/duplicating a o > real OS from scratch.  > F > > Or, pigs flying now, maybe Compaq could kindly just throw open theI > > source code, and let companies of greater insight provide support for> > G > Why should they?  Having proprietary access to the source code makes t
 > them money.h > E > Personally, I would rather pay for good source code developed by a aE > small, tightly-knit team of professionals than go with open-source r6 > software, certainly for something the size of an OS.  I You call unix quality?  It's hack city!  Maybe you ought to check out all- the latest Cert advisories ...   ------------------------------  # Date: Thu, 29 Nov 2001 23:55:09 GMToL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")= Subject: Re: why not a communityDeveloped[tm] version of VMS? 8 Message-ID: <00A05C76.AFA9766C@SSRL04.SLAC.STANFORD.EDU>  w In article <01KBA3YGVU7C90YLDV@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes: C >> Wouldn't the intervening period be good to either duplicate froms
 >> scratch >eJ >Calculate how many person-years have gone into VMS.  Do you really think F >that you can muster those resources?  The comparison with Linux is a G >no-go; that some students can throw something together in their spare kD >time which rivals commercial unix says something about the lack of J >quality of commercial unix, not about the ease of creating/duplicating a  >real OS from scratch.  L Also, it's kind of unfair to suggest that Linux is something thrown togetherL by some students in their spare time.  I have a bunch of issues with Linux, L but must acknowledge, first, that there are a _lot_ of people working on it,I and that a significant  amount of the development on it has been done by tI people who were being paid to do it (usually in the employ of one of the hL distributors like Red Hat or TurboLinux).  The "clustering" options in Linux1 aren't developed by students in their spare time.t  D >Personally, I would rather pay for good source code developed by a D >small, tightly-knit team of professionals than go with open-source 5 >software, certainly for something the size of an OS.u  J A reasonable position.  However, don't take Linux as representative of theO quality of all open-source OSes.  The xBSD projects seem to have a very stable  J codebase of pretty high quality, good uptimes, and professional attitudes K toward development.  It's just that Linux got a charismatic personality outSM in front and got the press.  It's not that it's better, it's that it's known.a   -- Alane    O ===============================================================================o0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056wM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210wO ===============================================================================c   ------------------------------  # Date: Fri, 30 Nov 2001 03:29:57 GMTh1 From: "David J. Dachtera" <djesys.nospam@fsi.net>a= Subject: Re: why not a communityDeveloped[tm] version of VMS?a' Message-ID: <3C06FD37.FC682CC7@fsi.net>a   BERTRAND Jol wrote: > $ > Le Thu, 29 Nov 2001 16:56:02 +0100* > Dr. Dweeb. <Dweeb@nospam.com> crivait : > >Abso-fucking-lutely ! > >sI > >"Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in messagep8 > >news:01KBA3YGVU7C90YLDV@sysdev.deutsche-boerse.com...G > >> > Wouldn't the intervening period be good to either duplicate frome > >> > scratch > >>M > >> Calculate how many person-years have gone into VMS.  Do you really thinkeI > >> that you can muster those resources?  The comparison with Linux is atJ > >> no-go; that some students can throw something together in their spareG > >> time which rivals commercial unix says something about the lack of M > >> quality of commercial unix, not about the ease of creating/duplicating a  > >> real OS from scratch. > >>I > >> > Or, pigs flying now, maybe Compaq could kindly just throw open thelL > >> > source code, and let companies of greater insight provide support for > >>I > >> Why should they?  Having proprietary access to the source code makes  > >> them money. > >>G > >> Personally, I would rather pay for good source code developed by aeG > >> small, tightly-knit team of professionals than go with open-sourceo9 > >> software, certainly for something the size of an OS.  > L >         I have restarted the old FreeVMS project (http://freevms.free.fr).G > At this time, we have a kernel for i386 in prealpha stage, a SRM-likeeH > console which can boot this kernel or another operating system and I'mH > working on the DCL interpreter. We have a CVS tree and a mailing list.C > You can find all informations about this project on our web page.h > L >         We need some contributers to (re)write some libraries (STR$, RTL$,P > SMG$...) and the basic functions (COPY, PURGE, SET...) in the DCL interpreter.  G I had suggested exactly that a couple of years ago - get started on thedH command programs so that when the freeware libraries are available, we'd. have working code to compile and test against.  ) Maybe you'll have better luck than I did.   5 There's a command program list available at this URL:s. http://www.djesys.com/vms/freevms/proglist.txt  E It's from an extract from DCLTABLES circa V6.2; so, it might be a bita% dated. Still, you may find it useful.m  	 See also:e" http://www.djesys.com/vms/freevms/   -- l David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/m   ------------------------------  # Date: Thu, 29 Nov 2001 19:30:44 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: xdmcp3 Message-ID: <E1wN7.2122$RL6.63346@news.cpqcorp.net>)  \ In article <3C05ED60.BB120D2E@peoplepc.com>, Jack Patteeuw <jjpatteeuw@peoplepc.com> writes: :M :  :Hoff Hoffman wrote: :> II :>   XDM is supported on current TCP/IP Services versions.  Specifically,t< :>   on TCP/IP Services V5.1 and later.  (DHCP client, too.) :> . :>* :Yep, its there and it works ... mostly !! :iM :Right now there is a P*SSING contest going on between different parts of VMS M :Engineering on who will fix a couple of (submitted, documented and verified)uI :bugs related to XDMCP.  The biggest one is that logins done via an XDMCP F :connection are **NOT** registered as an "INTERACTIVE" login in SYSUAF
 :database. : N :It seems that no one can get the "children" to play nice together and resolve :this problem.  J   I haven't looked at the xdcmp source pool involved, so I have no way to 6   see how this works and what the problem(s) might be.  I   Feeling rather busy and rather jaded today, maybe no one has explained  K   to the children why (not) showing up as "interactive" is such a critical oL   problem?  No offense, but -- based solely on what was posted here -- this H   does look like a fairly minor bug in the grand scheme...  If this is aG   critical problem, then I'm surprised to see the discussions here in ahH   newsgroup and not via the customer support center and then via one of I   the folks that formally tracks problem reports and problem resolutions.a  F :Not a bug, but would sure be nice if we could put up a better splash ? :screen than "Username: Password:" with no graphic background !e  G   Splash screens and background graphics tend to get me and a few otherbJ   folks into trouble.  (I'll just leave it at that. :-)  It might be nice H   to add an enhancement that permits a user to customize the display if E   one does not already exist, but I digress -- that's an enhancement.d    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Thu, 29 Nov 2001 15:15:08 -0500-5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>2 Subject: Re: xdmcp3 Message-ID: <ZJwN7.2130$RL6.63379@news.cpqcorp.net>F  ! Hoff Hoffman wrote in message ... H >  Splash screens and background graphics tend to get me and a few other5 >  folks into trouble.  (I'll just leave it at that.)t  G Just make sure it doesn't consume the colormap, and don't ask anyone in" marketing for permission ;-)   ------------------------------   End of INFO-VAX 2001.665 ************************