1 INFO-VAX	Thu, 20 Nov 2003	Volume 2003 : Issue 644       Contents:= Re: 2010: a VAX end of Space Odissey, but what about VAX/VMS? + Re: argentic vs digital pictures technology P Re: argentic vs digital pictures technology (was: VMS 2003 bootcampsummary) boot) Re: DCL Enhancement: PUSH/POP Environment 8 Re: DCL Enhancements: Error messages for OPEN and DEFINE8 Re: DCL Enhancements: Error messages for OPEN and DEFINE8 Re: DCL Enhancements: Error messages for OPEN and DEFINE Re: EV79 CANCELED !!!!!!!!! ) Re: Hobbyist license and layered products ) Re: Hobbyist license and layered products ) Re: Hobbyist license and layered products ) Re: Hobbyist license and layered products  Re: IA64 TPC results Re: lat for linux problem  Re: lat for linux problem  Re: lat for linux problem  need GUNZIP urgently Re: need GUNZIP urgently Re: need GUNZIP urgently& Re: Only hope for Intel is alpha chip?& Re: Only hope for Intel is alpha chip?! Peoplesoft Financials and OpenVMS 8 Problem with performance while running FTP in batch mode< Re: Problem with performance while running FTP in batch mode( Reverse nslookup gives different results, Re: Reverse nslookup gives different results SQLSRV V7.1-5 Problem 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday 9 Re: Sun to use AMD Opteron - announcement expected Monday  Re: TELNET/PORT  Re: TELNET/PORT P The Alpha Chip Engineering Group Revival (aka: today's HP/Intel presentation in 8 VAX/VMS to Itanium Newsletter statistics as of yesterday Re: VMS 2003 bootcamp summary % Re: What is port 557 openvms/ipc ???? * Re: [OT] Mac OS X: system folder not found  F ----------------------------------------------------------------------  % Date: Thu, 20 Nov 2003 12:59:43 +0100 " From: Didier Morandi <no@spam.com>F Subject: Re: 2010: a VAX end of Space Odissey, but what about VAX/VMS?2 Message-ID: <3fbcacce$0$235$636a55ce@news.free.fr>   Didier Morandi wrote:   ? > The FutureVAX is a piece of HP hardware running XP and SRI's  ! > CHARON-VAX/XL Plus for Windows.    ERRATA: XM.    D.   ------------------------------  % Date: Thu, 20 Nov 2003 11:40:57 +0100 " From: Didier Morandi <no@spam.com>4 Subject: Re: argentic vs digital pictures technology2 Message-ID: <3fbc9a58$0$254$636a55ce@news.free.fr>   Atlant G. Schmidt wrote:  ; > The Nikon CoolPix 5700 is also such a camera. It contains 9 > an electronic viewfinder as well as a separate, larger, ! > tilt-and-swivel LCD view panel.    Nice to see you back, Atlant.    D. --  ;           Read the latest VAX/VMS to Itanium Migration News F   www.openvms.org/dmorandi/vaxvms2itanium_200311en.pdf (en USA mirror)A www.didiermorandi.com/vms/vaxvms2itanium_200311en.pdf (en Europe) A www.didiermorandi.com/vms/vaxvms2itanium_200311fr.pdf (fr Europe)   7               Discover the FutureVAX: www.futurevax.com   F didier morandi  ~ sarl au capital de 8 000 euros ~  Revendeur agr HPC      Expertise en environnement DIGITAL ~ Formation ~ Programmation F Offshore ~ 5 av. A. Durand 31700 Blagnac France. Tl: 33(0)5 6131 6287D    SIRET 448 694 851 00016 RCS Toulouse http://www.didiermorandi.com   ------------------------------  % Date: Thu, 20 Nov 2003 12:03:00 +0000 * From: Nic Clews <sendspamhere@[127.0.0.1]>Y Subject: Re: argentic vs digital pictures technology (was: VMS 2003 bootcampsummary) boot ' Message-ID: <bpiagf$7cc$1@lore.csc.com>    JF Mezei wrote:  >  > "Martin P.J. Zinser" wrote: K > > As for Digital SLRs. Yupp, I know they do exist, but either you have to J > > earn much more money than I or to be at least a semi-pro to invest the2 > > money needed to buy one of these right now ;-) > P > If you have already invested in good quality lenses or zooms for your analogueN > SLR, then buying a digital SLR from the same company can make a lot of sense' > since the lenses can be quite costly.   F Agreed with that. For better or worse I have the Pentax SLR system, myG only reservation is that it has a 1.5 focal length multiplier (making a 3 50mm 'film' lens like a 75mm lens in digital mode).   ? Costwise, it is three times more for a 5 (IIRC) megapixel as my  "compact" 4 megapixel.  F The colour issues I take as read, however there are quite a few placesH that do prints to photographic paper, and they are streets ahead of what I can do on my printer.  --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------    Date: 20 Nov 2003 12:01:43 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) 2 Subject: Re: DCL Enhancement: PUSH/POP Environment3 Message-ID: <+XBK1lr7YFYQ@eisner.encompasserve.org>   e In article <3FBBBEC1.AE19D599@applied-synergy.com>, Chris Scheers <chris@applied-synergy.com> writes: H > There has been some recent discussion of having the capability to saveC > and restore the entire DCL/Terminal/etc. environment in one shot.  > J > A mechanism that I have seen elsewhere is a CLI PUSH/POP capability thatC > does this.  PUSH saves the current environment, POP restores it.  3 > Obviously, the environments are saved as a stack.  > ? > The environment that is saved should include at least the DCL B > environment, RMS environment, terminal characteristics (if any),B > symbols, and PPF logicals (possibly all supervisor process table
 > logicals?).   " We have this.  It is called SPAWN.   ------------------------------  % Date: Thu, 20 Nov 2003 01:41:00 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE ) Message-ID: <3FBC61D1.AC2D4143@istop.com>    "David J. Dachtera" wrote:G > Remember to make the distinction between opening a file and OPENing a $ > channel to a (file, device, etc.).  G And remember that when you use $OPEN a second time on the same file, it M doesn't do anything and preserves the status of the previous RAB, FAB etc. It L will not rewind the file and the next read will continue to where the record% pointer was prior to the second open.    ------------------------------  % Date: Thu, 20 Nov 2003 11:45:28 +0100 " From: Didier Morandi <no@spam.com>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE 2 Message-ID: <3fbc9b67$0$248$636a55ce@news.free.fr>   Paul Repacholi wrote:   E > But you are NOT reopening the file! You are superceding the logical D > from the first open, but that is just a coincedence, it could well > be any logical.   N I repeat. You are NOT superceding anything. Just nothing happens. This is the 2 issue. Try with two files on two different disks :   DTL02> open/read ch A.A  DTL02> sh log ch,     "CH" = "_DTL02$DKA0" (LNM$PROCESS_TABLE)
 DTL02> sh def     SYS$SYSROOT:[SYSMGR]     =   SYS$SYSROOT:[SYSMGR]     =   SYS$COMMON:[SYSMGR] DTL02> mora 
 DTL02> sh def     DKA100:[MORANDI]  DTL02> open/read ch A.A  DTL02> sh log ch,     "CH" = "_DTL02$DKA0" (LNM$PROCESS_TABLE) DTL02>  * Logical name did NOT change (fortunately).   D.   ------------------------------  % Date: Thu, 20 Nov 2003 11:49:36 +0100 " From: Didier Morandi <no@spam.com>A Subject: Re: DCL Enhancements: Error messages for OPEN and DEFINE 2 Message-ID: <3fbc9c5f$0$248$636a55ce@news.free.fr>   Paul Sture wrote:   8 > It _has_ to be compatible with current behaviour IMHO. >  > Let's look at HELP OPEN/ERROR  > % >      If the /ERROR qualifier is not ; >      specified, the current ON condition action is taken.  > J > Oh dear, currently working procedures could suddenly do a silent jump inH > the code if the default were changed. There's simply too much code out
 > there...  O This is not the point, Paul, if you permit. There IS an error, as the OPEN did  P not occur, for whatever reason. The point is to let the user know that the OPEN D did not occur. See also my reply to JLSUE on 19-nov-2003 09:00 GMT+1   D.   ------------------------------  # Date: Thu, 20 Nov 2003 14:19:58 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>$ Subject: Re: EV79 CANCELED !!!!!!!!!8 Message-ID: <poiprvot89nt2lgt65k7h0kgrukrjd8uq0@4ax.com>  H On Wed, 19 Nov 2003 14:38:29 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:  
 >jlsue wrote: H >> I know of absolutely no - that's ZERO - customers who's business willJ >> suffer due to the switch from EV79's planned architecture, and the EV7z >> architecture. > L >Because of Alpha's last iterations are slower than had been anticipated andO >because the EV79 turns out to be a dud that is essentially the same as an EV7, J >customers will abandon Alpha sooner rather than later. Problem is that in. >doing so, they also are likely to abandon HP.  J There is always a risk.  I expect that powers-that-be to weigh those risksI against the costs of the alternatives to get some balance in the decision  making process.    > L >One has to consider long term trends and long term strategic decisions. YouR >don't see sales impact the day after Carly makes an announcement for such things. >   I Well, it really doesn't make total sense to expect some huge drop anyway. I From the business' perspective, unless they were already on the very edge I of performance needs with EV68 and the current EV7 - so much so that they D could't wait for EV7x - they don't really need to change their plansK because the systems are still shipping and are supported according to plan.    > H >> Hogwash.  HP is still delivering on the commitments for CPU upgrades. > M >Technically, the lawyers probably will agree with you. But in spirit, HP has M >NOT delivered on promises. It has not made EV7 as fast as it could have been * >and will not produce the shrink for EV79.  H "Technically" speaking is the only realm where the cpu difference reallyI matters much for most businesses.  If the business is already invested in I Alpha technology, this doesn't really mean much in their plans to migrate J (again, unless a particular business is one that's on the ragged edge, and% I know that a few of those do exist).    > + >What this does is affect HP's credibility.  >   I HP is still delivering on the commitments for support and availability of J AlphaServer systems that should provide plenty of performance to not upset most business plans.  K >And considering that IA64 is still just a promise of something nice in the O >future, credibility is important. That is a good reason why many don't believe I >IA64 will pan out, simply because we don't believe anything HP says with  >regards to VMS.  F There's nothing in the EV7z announcement that changes the timeline forJ delivering OpenVMS for the Intel 64-bit processor systems.  Some will takeH a more cynical view, I'm sure, and say that this is just another nail inF the coffin, but they are really somewhat independent issues.  They are5 interrelated, I grant you, but not totally dependent.   I If a customer is a current AlphaServer-based business, with OpenVMS even, I then the new AlphaServer systems will take them quite a long way into the K future.  Remember, we still have PDP-11 and VAX customer who are happy with K their solutions, even though there have been *no* system updates in quite a H long time.  The ability to take the newer Alpha CPUs and put them into aK 64-CPU system, and even put these into VMScluster systems, provides quite a > lot of power and growth capability until well past 2007, imho.   ------------------------------  % Date: Thu, 20 Nov 2003 11:55:07 +0100 " From: Didier Morandi <no@spam.com>2 Subject: Re: Hobbyist license and layered products2 Message-ID: <3fbc9daa$0$241$636a55ce@news.free.fr>   sms@antinode.org wrote:   G >    So, now, as soon as I become a Software Products Library customer,  > I'll be all set?    Q What do you wish me to say, sms? I filled in the form, I got the newsletter with  O my username and my password and I did successfully download the stuff I needed.   
 My 2 euros- (sorry for the $/euro rate these days, folks)    D.   ------------------------------  % Date: Thu, 20 Nov 2003 11:55:36 +0100 " From: Didier Morandi <no@spam.com>2 Subject: Re: Hobbyist license and layered products2 Message-ID: <3fbc9dc6$0$241$636a55ce@news.free.fr>   Phillip D. Williams wrote:  M > You can ftp 5.5 BASIC/COBOL/FORTRAN/VAXC and others from my site. Right now  > its straight ftp from E > 68.35.167.136 username VAXVMS password VAXVMS. The system is a 7.3.  > Hope this helps    No :-)  
 DTL02> ftp FTP> open 68.35.167.136 0 %TCPIP-E-FTP_NETERR, I/O error on network device! -SYSTEM-F-TIMEOUT, device timeout    D.   ------------------------------  % Date: Thu, 20 Nov 2003 08:03:36 -0700 6 From: "Phillip D. Williams" <dwilliams296@comcast.net>2 Subject: Re: Hobbyist license and layered products0 Message-ID: <QfqdneTP6aDERSGi4p2dnA@comcast.com>  6 Try it now!! Had the ftp pointing to the wrong system. Phillip / "Didier Morandi" <no@spam.com> wrote in message , news:3fbc9dc6$0$241$636a55ce@news.free.fr... > Phillip D. Williams wrote: > K > > You can ftp 5.5 BASIC/COBOL/FORTRAN/VAXC and others from my site. Right  now  > > its straight ftp from G > > 68.35.167.136 username VAXVMS password VAXVMS. The system is a 7.3.  > > Hope this helps  >  > No :-) >  > DTL02> ftp > FTP> open 68.35.167.136 2 > %TCPIP-E-FTP_NETERR, I/O error on network device# > -SYSTEM-F-TIMEOUT, device timeout  >  > D. >    ------------------------------  % Date: Thu, 20 Nov 2003 09:42:10 -0700 6 From: "Phillip D. Williams" <dwilliams296@comcast.net>2 Subject: Re: Hobbyist license and layered products0 Message-ID: <V_adndXaEtnsciGiRVn-jg@comcast.com>  8 If there is a need I can make the entire Septermber 1992 csd available..  phillip / "Didier Morandi" <no@spam.com> wrote in message , news:3fbc9daa$0$241$636a55ce@news.free.fr... > sms@antinode.org wrote:  > I > >    So, now, as soon as I become a Software Products Library customer,  > > I'll be all set? > B > What do you wish me to say, sms? I filled in the form, I got the newsletter with I > my username and my password and I did successfully download the stuff I  needed.  >  > My 2 euros/ > (sorry for the $/euro rate these days, folks)  >  > D. >    ------------------------------  # Date: Thu, 20 Nov 2003 14:23:17 GMT & From: jlsue <jefflsxxxz@sbcglobal.net> Subject: Re: IA64 TPC results 8 Message-ID: <bhjprvofulahcrctpuv8omib2h6rged691@4ax.com>  7 On Wed, 19 Nov 2003 20:10:10 -0600, "David J. Dachtera"  <djesys.nospam@fsi.net> wrote:  
 >jlsue wrote:  >>     >>  N >> So what you're saying is that the CEO and BOD of your organization actually) >> care whether it's an EV79 or and EV7z?  > C >I'm saying, in the broader context, that CEOs and BODs will not do @ >business with companies that have proven untrustworthy. Period.  I To the extent, that they view this "technical" change as backing out of a A commitment that their business relied upon, then you are correct.   I I haven't known too many IT management types (say 2nd level on up) who've G cared all that much about the esoteric details of chip design.  Service > levels to the business is where most of them spend their time.   ------------------------------    Date: 20 Nov 2003 02:25:52 -0800% From: Bart.Zorn@xs4all.nl (Bart Zorn) " Subject: Re: lat for linux problem= Message-ID: <a98cd882.0311200225.61defcbc@posting.google.com>   D LAT has nothing to do with DECnet (and vice versa). If the Linux boxF is not running DECnet, there is no need to change it's MAC address. If: the Linux box does have a DECnet implementation, then that@ implementation will take care of the proper MAC address setting.  C This does not explain your problem, however, and I am afraid that I  cannot help you there.  	 Bart Zorn   j "H Vlems" <hvlems.nieuw@zonnet.nl> wrote in message news:<bpgiq2$1na8g6$1@ID-143435.news.uni-berlin.de>... > John,  > N > not sure whether it is the cause for your problem but is aa-00-04-00-0a-03 a > valid DECnet address? H > IIRC one takes tha last two bytes and reverse them. The leading 6 bits5 > designate area, the trailing 10 designate the node. ) > 0a-03 -> 03-0A -> 0000 00 11 0000 10 10 5 >                                --------- ========== ( > That's 0.778 which is invalid, right ? > J > BTW I use LAT for linux (RedHat 9) without any problems, like Roland the" > server is started with defaults. >  > Hans > ? > "John Forkosh" <john@SeeSigForAddress.com> schreef in bericht ( > news:bpg37f$md8$1@reader2.panix.com...L > > Not sure if this is the right group, but anybody here use Lat for Linux,: > >           http://linux-decnet.sourceforge.net/lat.htmlA > > I have a small 10base2 lan with some Linux PC's, some genuine D > > VMS VAXstations, and a DECserver 90L+.  The wires are okay sinceD > > I can ping/telnet/ftp between the VS's and PC's, and can connect > > to the VS's from the 90L+. > > G > > I also found out about the MAC address problem with the 90L+, i.e., D > > it barfs on packets from non-Digital addresses, and have applied > > the linux fix 1 > >           ifconfig hw ether AA:00:04:00:0A:03 B > > so the PC looks like a Digital address.  And I'm also applying$ > > the extra lat-for-linux commands > >           latcp -j( > >           latcp -x 100 -s -a psistarF > > (where psistar is the name of the PC), though I'm not sure whether! > > either is helpful in any way.  > > F > > And all this kind of works -- I can sometimes  c psistar  from the@ > > 90L+ and log on to the PC.  Works fine when it works at all. > > > > > Problem is it always takes a _long_ time (90L+ prints lotsC > > of ...'s before I ever get a prompt) before connecting, and the = > > 90L+ frequently just gives up with "service unavailable". C > > But if I do manage to connect and then later logout/exit, I can : > > always establish a new PC connection almost instantly.- > > The VS's always connect almost instantly.  > > ? > > What might be wrong, and what can I do to fix it or tune it  > > or whatever?  Thanks,  > > --  B > > John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )   ------------------------------  % Date: Thu, 20 Nov 2003 13:59:27 +0100 ) From: Roland Barmettler <itsme@127.0.0.1> " Subject: Re: lat for linux problem5 Message-ID: <20031120135927.12cd3170.itsme@127.0.0.1>   < John Forkosh wrote on Wed, 19 Nov 2003 17:03:59 +0000 (UTC): >  > Isn't "-c 80" the default?  E Ah, yes. You're right. I just had to play with it on earlier versions 8 that's the reason its still there in the startup file...    > Anyway, here's the output from: > my  latcp -d  with all defaults except for the -j and -x > > > How does this compare with what you're doing?  Thanks again,  G Hmmm... my "latcp -d" reads exactly the same as yours except I'm having = a rating of "12 D" instead of "100". But that should make the  difference, should it ?    Cheers, Roland   -- 3rd Law of Computing:          Anything that can go wr   Segmentation fault (core dumped)   ------------------------------  % Date: Thu, 20 Nov 2003 18:38:55 +0100 ( From: "H Vlems" <hvlems.nieuw@zonnet.nl>" Subject: Re: lat for linux problem: Message-ID: <bpiucn$1p1g10$1@ID-143435.news.uni-berlin.de>   Bart,   K LAT is indeed completely different from DECnet. Now IIRC the LAT and DECnet H implementations for linux are in someway related. An invalid MAC address? fror DECnet could perhaps affect LAT behaviour. Hence the post.    Hans  4 "Bart Zorn" <Bart.Zorn@xs4all.nl> schreef in bericht7 news:a98cd882.0311200225.61defcbc@posting.google.com... F > LAT has nothing to do with DECnet (and vice versa). If the Linux boxH > is not running DECnet, there is no need to change it's MAC address. If< > the Linux box does have a DECnet implementation, then thatB > implementation will take care of the proper MAC address setting. > E > This does not explain your problem, however, and I am afraid that I  > cannot help you there. >  > Bart Zorn  > 5 > "H Vlems" <hvlems.nieuw@zonnet.nl> wrote in message 6 news:<bpgiq2$1na8g6$1@ID-143435.news.uni-berlin.de>...	 > > John,  > > < > > not sure whether it is the cause for your problem but is aa-00-04-00-0a-03 a  > > valid DECnet address? J > > IIRC one takes tha last two bytes and reverse them. The leading 6 bits7 > > designate area, the trailing 10 designate the node. + > > 0a-03 -> 03-0A -> 0000 00 11 0000 10 10 7 > >                                --------- ========== * > > That's 0.778 which is invalid, right ? > > L > > BTW I use LAT for linux (RedHat 9) without any problems, like Roland the$ > > server is started with defaults. > >  > > Hans > > A > > "John Forkosh" <john@SeeSigForAddress.com> schreef in bericht * > > news:bpg37f$md8$1@reader2.panix.com...G > > > Not sure if this is the right group, but anybody here use Lat for  Linux,< > > >           http://linux-decnet.sourceforge.net/lat.htmlC > > > I have a small 10base2 lan with some Linux PC's, some genuine F > > > VMS VAXstations, and a DECserver 90L+.  The wires are okay sinceF > > > I can ping/telnet/ftp between the VS's and PC's, and can connect  > > > to the VS's from the 90L+. > > > I > > > I also found out about the MAC address problem with the 90L+, i.e., F > > > it barfs on packets from non-Digital addresses, and have applied > > > the linux fix 3 > > >           ifconfig hw ether AA:00:04:00:0A:03 D > > > so the PC looks like a Digital address.  And I'm also applying& > > > the extra lat-for-linux commands > > >           latcp -j* > > >           latcp -x 100 -s -a psistarH > > > (where psistar is the name of the PC), though I'm not sure whether# > > > either is helpful in any way.  > > > H > > > And all this kind of works -- I can sometimes  c psistar  from theB > > > 90L+ and log on to the PC.  Works fine when it works at all. > > > @ > > > Problem is it always takes a _long_ time (90L+ prints lotsE > > > of ...'s before I ever get a prompt) before connecting, and the ? > > > 90L+ frequently just gives up with "service unavailable". E > > > But if I do manage to connect and then later logout/exit, I can < > > > always establish a new PC connection almost instantly./ > > > The VS's always connect almost instantly.  > > > A > > > What might be wrong, and what can I do to fix it or tune it  > > > or whatever?  Thanks, 	 > > > --  D > > > John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )   ------------------------------  % Date: Thu, 20 Nov 2003 12:33:18 +0100 " From: Didier Morandi <no@spam.com> Subject: need GUNZIP urgently 2 Message-ID: <3fbca69d$0$245$636a55ce@news.free.fr>  O I thought UNZIP was able to UNZIP .GZ files. This is not the case (even if you  I do transfer the files in FTP IMAGE mode). The GZIP repository for VMS is   unreachable.  7 Could someone give me a pointer to a VMS/Alpha version?    Urgent.    Thanks,    D.   ------------------------------  % Date: Thu, 20 Nov 2003 13:02:29 +0100 " From: Didier Morandi <no@spam.com>! Subject: Re: need GUNZIP urgently 2 Message-ID: <3fbcad74$0$235$636a55ce@news.free.fr>   Michal von Grotthuss wrote:   1 > "Didier Morandi" <no@spam.com> wrote in message . > news:3fbca69d$0$245$636a55ce@news.free.fr... >  > 9 >>Could someone give me a pointer to a VMS/Alpha version?  >  > % > Use GZIP.EXE from OpenVMS freeware: : > http://h71000.www7.hp.com/openvms/freeware/freeware.html > # > For unzipping (ungzipping?) type:  > $ gzip == "$gzip.exe"  > $ gzip -d    :-( 	 Merci :-)    D.   ------------------------------  % Date: Thu, 20 Nov 2003 12:42:18 +0100 / From: "Michal von Grotthuss" <nospam@nospam.pl> ! Subject: Re: need GUNZIP urgently - Message-ID: <bpi9bo$d6v$1@SunSITE.icm.edu.pl>   / "Didier Morandi" <no@spam.com> wrote in message , news:3fbca69d$0$245$636a55ce@news.free.fr...  9 > Could someone give me a pointer to a VMS/Alpha version?   # Use GZIP.EXE from OpenVMS freeware: 8 http://h71000.www7.hp.com/openvms/freeware/freeware.html  ! For unzipping (ungzipping?) type:  $ gzip == "$gzip.exe" 	 $ gzip -d    Michal   ------------------------------   Date: 20 Nov 2003 07:37:54 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>/ Subject: Re: Only hope for Intel is alpha chip? 5 Message-ID: <DTiotGxQ0bj6-pn2-FxDNETL5ceyz@localhost>   C On Mon, 17 Nov 2003 16:34:47 UTC, jlsue <jefflsxxxz@sbcglobal.net>   wrote:  J > On Thu, 13 Nov 2003 15:57:50 -0500, JF Mezei <jfmezei.spamnot@istop.com> > wrote: >  > > O > >Now, look at Intel: if it is forced to announce that its IA64 is a financial F > >flop and all investments will have to be written off, because thoseQ > >investments were not trivial, such a move would very nagitevly affect Intel on M > >the stock market. On the heels of AMD's 64 bit 8086, if Intel has to admit J > >that not only was IA64 not a wise investment, but its focus on IA64 hasM > >resulted in Intel not having a 64 bit 8086 to compete against AMD would be ) > >very bad news for intel's stock price.  >  > IF, IF, IF, IF.  > F > Your supposed hypothetical *assumes* the conclusion:  That IA64 is a/ > mistake.  That's called begging the question.  > F > There's every indication that IA64 can certainly be a good processorJ > contender, and maybe one of the best.  It's not as mature as many othersM > (e.g., Power), but it's certainly not any less proven than other new-comers  > (i.e., AMD).  A True, in the same sense as Alpha, PA-RISC and/or SPARC(64), i.e.  F proprietary. However, to achieve 'Industry-Standard' processor status,F it must replace all three at least, and preferably, get IBM using 'em @ too, where MS OS platforms don't count unless _replacing_ x86's.  D On the other hand, Intel/HP could just redefine 'Industry-Standard'.   --   Cheers - Dave.   ------------------------------  # Date: Thu, 20 Nov 2003 14:28:20 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>/ Subject: Re: Only hope for Intel is alpha chip? 8 Message-ID: <0ojprv813n41mah47s24cvg0mq5ssch0n2@4ax.com>  I On 20 Nov 2003 07:37:54 GMT, "Dave Weatherall" <djw-nothere@nospam.nohow>  wrote:  D >On Mon, 17 Nov 2003 16:34:47 UTC, jlsue <jefflsxxxz@sbcglobal.net>  >wrote:  >    >>  G >> There's every indication that IA64 can certainly be a good processor K >> contender, and maybe one of the best.  It's not as mature as many others N >> (e.g., Power), but it's certainly not any less proven than other new-comers >> (i.e., AMD).  > B >True, in the same sense as Alpha, PA-RISC and/or SPARC(64), i.e. G >proprietary. However, to achieve 'Industry-Standard' processor status, G >it must replace all three at least, and preferably, get IBM using 'em  A >too, where MS OS platforms don't count unless _replacing_ x86's.   I All CPUs are proprietary.  Even the current Intel 32-bit processor.  Even G the AMD 32-bit processor.  It's the interfaces/APIs/etc. that make them ? open enough for other vendors to step in and provide compatible   peripherals, system boards, etc.   > E >On the other hand, Intel/HP could just redefine 'Industry-Standard'.   I Well, it's not as if this hasn't been redefined at least a thousand times G in the past few years by all vendors anyway.  I doubt it's actually had I much of a hard-and-fast definition, other than it usually included Wintel J (and sometimes Win/AMD, though not normally in mid- and high-end servers).   ------------------------------    Date: 20 Nov 2003 07:42:49 -0800 From: ter@bwsc.org (renato) * Subject: Peoplesoft Financials and OpenVMS= Message-ID: <39894c1a.0311200742.10669bea@posting.google.com>   ! Is anyone else in this situation?   D I work for a small public agency and we are on Peoplesoft FinancialsE 7.5 SP2 (E&G) with our Oracle database server running on OpenVMS.  We E are in internal discussions of which version of Peoplesoft to upgrade E to.  We would like to go the latest version (FM 8.4) but this version F is not OpenVMS certified and will not be supported.  Currently we have< no plans on moving away from OpenVMS since it will be a hugeB undertaking for us.  We have even written a letter to Craig ConwayF pleading our case.  How much of a change is there between 8.0 and 8.4?  B We believe our two options are to 1) upgrade to 8.0 which is stillB OpenVMS supported, or 2) just go ahead with the 8.4 (8.8?) upgradeE since for us OpenVMS is only the Oracle database server and have been / told that there probably won't be any problems.   6 Any advise on this matter will be greatly appreciated.   Thank you...   ------------------------------  % Date: Thu, 20 Nov 2003 11:56:26 +0100 / From: "Michal von Grotthuss" <nospam@nospam.pl> A Subject: Problem with performance while running FTP in batch mode - Message-ID: <bpi6ln$3ga$1@SunSITE.icm.edu.pl>    Hi all, 9 I have already observed strage behaviour of FTP transfer. L Session is established on VMS machine to Win2K server running MS ftp server.   Comand I run is very simple:  : $ ftp 10.1.1.1 /input=BACKUP_UTILS:get_exchange_backup.ftp0 /username=anonymous /password="nospam@nospam.pl"  ; Mentioned above get_exchange_backup.ftp file is as follows:    lcd back_temp_dir: binary mget exchange.bkf  lcd sys$login: bye   L Strange is that if I run this command in interactive session, the throughputE is OK i.e. about 6MB/second (it's OK for fastethetnet LAN connection)  see result: C 1320342528 bytes received in 00:03:27.69 seconds (6208.25 Kbytes/s)   K But when I run this in batch mode, transfer is terrible: about 40KB/sec!!!!  see result: A 1315099648 bytes received in 08:35:47.32 seconds (41.50 Kbytes/s)   K In both of above situations FTP command was run from the same user account. 0 Does anybody have any suggestions what to check? Michal   ------------------------------    Date: 20 Nov 2003 06:09:55 -0800. From: al5vf03p02@sneakemail.com (William Webb)E Subject: Re: Problem with performance while running FTP in batch mode = Message-ID: <d5ce4b06.0311200609.4e6ae98f@posting.google.com>   d "Michal von Grotthuss" <nospam@nospam.pl> wrote in message news:<bpi6ln$3ga$1@SunSITE.icm.edu.pl>...	 > Hi all, ; > I have already observed strage behaviour of FTP transfer. N > Session is established on VMS machine to Win2K server running MS ftp server. >  > Comand I run is very simple: > < > $ ftp 10.1.1.1 /input=BACKUP_UTILS:get_exchange_backup.ftp2 > /username=anonymous /password="nospam@nospam.pl" > = > Mentioned above get_exchange_backup.ftp file is as follows:  >  > lcd back_temp_dir: > binary > mget exchange.bkf  > lcd sys$login: > bye  > N > Strange is that if I run this command in interactive session, the throughputG > is OK i.e. about 6MB/second (it's OK for fastethetnet LAN connection) 
 > see result: E > 1320342528 bytes received in 00:03:27.69 seconds (6208.25 Kbytes/s)  > M > But when I run this in batch mode, transfer is terrible: about 40KB/sec!!!! 
 > see result: C > 1315099648 bytes received in 08:35:47.32 seconds (41.50 Kbytes/s)  > M > In both of above situations FTP command was run from the same user account. 2 > Does anybody have any suggestions what to check? > Michal   The XP machine.       
 Seriously.  ! Take the field engineer approach:   @ Try doing similar batch vs. interactive FTPs from the VMS box toF another VMS box or a UNIX box and compare the results with what you're" seeing in your VMS to XP scenario.   WWWebb   ========================! William W. Webb- EMS Operations,   OpenVMS Systems Support % USPS DSSC Annex - 4730 Hargrove Road  ( Raleigh, NC 27616-2874 919.325.7500x4186E * * * -      email is first initial last name at email stop usps stop  gov    ------------------------------  % Date: Thu, 20 Nov 2003 02:00:20 -0500 * From: JF Mezei <jfmezei.spamnot@istop.com>1 Subject: Reverse nslookup gives different results ) Message-ID: <3FBC6659.679C5CD7@istop.com>    $ nslookup   200.182.136.4  6 *** No address (A) records available for 200.182.136.4   -----    $ nslookup   200.182.136.2  D *** <server name> can't find 200.182.136.2: Non-existent host/domain   ---------------------   I can anyone explain to me the significance in the diffferent response when 7 making an inquiry for 200.182.136.2 and 200.182.136.4 ?     VAX VMS 7.2 , TCPIP Services 5.3  M (note, the .2 address appears in the headers of a certain message, appears to J be owned by a south american network, and a traceroute seems to lead it to Brasil. (Fabio, is that you :-):    K I realise that in a SMTP message, the only reliable piece of information is H the last Received: line (trusted server gets a message from a trusted IPI address). However, in an NNTP message, are there any portions that can bem	 trusted ?C   ------------------------------  % Date: Thu, 20 Nov 2003 11:39:36 +0100r" From: Didier Morandi <no@spam.com>5 Subject: Re: Reverse nslookup gives different results 2 Message-ID: <3fbc9a07$0$254$636a55ce@news.free.fr>   JF Mezei wrote:    > $ nslookup   200.182.136.4 > 8 > *** No address (A) records available for 200.182.136.4 >  > -----n >  > $ nslookup   200.182.136.2 > F > *** <server name> can't find 200.182.136.2: Non-existent host/domain >  > ---------------------N > K > can anyone explain to me the significance in the diffferent response wheno9 > making an inquiry for 200.182.136.2 and 200.182.136.4 ?i   I have no difference:    DTL02> nslookup 200.182.136.2m Server:  ns3.wanadoo.fr  Address:  193.252.19.3  E *** ns3.wanadoo.fr can't find 200.182.136.2: Non-existent host/domaind   DTL02> nslookup 200.182.136.4o Server:  ns3.wanadoo.frl Address:  193.252.19.3  E *** ns3.wanadoo.fr can't find 200.182.136.4: Non-existent host/domaino   DTL02> sh symb nslookupm$    NSLOOKUP == "$tcpip$nslookup.exe"  K (the last two lines for those (like me) who do not know about the nslookup cT command. Thanks to Bruden Corp and their TCP/IP Services for OpenVMS Student Guide).   D.   ------------------------------    Date: 20 Nov 2003 01:35:32 -08003 From: paul.j.whapshott@lineone.net (Paul Whapshott)u Subject: SQLSRV V7.1-5 Problem= Message-ID: <51f54c31.0311200135.63f168c0@posting.google.com>t   Hi,a  E Looking for help. I have an ES45 running VMS 7.3-1 and SQL V7.1-5 ando RDB V7.1-10.  C Since upgrading I am getting a large SQS_PROD03_SQLSRV_DIS00371.LOGc, and am having to stop and start SQL services@ (@sys$manager:sqlsrv$shutdown71) and restart to close this large logfile.  A Every event seems to be logged into the file. The question is, IsaA there a setting that can limit what gets logged into the logfile?      Thanks for any help,     Paul   ------------------------------  % Date: Thu, 20 Nov 2003 01:47:49 -0500u* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <LqOdncFurfQP_iGiRVn-jA@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in messageA, news:NlOub.9336$6O6.2590@news.cpqcorp.net...+ > Bill Todd <billtodd@metrocast.net> wrote:hG > > Of course not.  OTOH, Sun would have a legitimate excuse for havingXE > > taken this action (their actual inability to compete with SPARC --C > > this still being the hypothetical situation which you posited),i >oF > So you don't think there would be SPARCophiles asserting that if SunE > had only put the resources into making/keeping SPARC competitive it:) > would have been able to rule the roost?   L Not to anything like the degree (or with anything like the justification) as was the case with Alpha.  J 1.  SPARC would not be offering current performance leadership; Alpha did.  I 2.  SPARC would not have a well-defined future product well on the way totG completion that offered even greater performance leadership; Alpha did.i  9 You keep trying to draw parallels where they don't exist.s   - bill   ------------------------------   Date: 20 Nov 2003 07:37:50 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday5 Message-ID: <DTiotGxQ0bj6-pn2-C4judythGdzh@localhost>a  A On Wed, 19 Nov 2003 18:24:26 UTC, young_r@encompasserve.org (Rob 8
 Young) wrote:R  # > 	Twisty little passage, isn't it?m > A > 	What is the rational for offering 2-way and 4-way Opterons and0B > 	later higher CPU counts?  'Cause SPARC is going away.  If SPARCC > 	really was price and performance superior (or to return there inoC > 	a year or so), it would make little sense to devote resources to ? > 	Opteron.  Who would want an Opteron when Solaris on next-genk > 	SPARC is so fantastic.e  B Uh can an Opteron do big-endian Solaris then ? At least when Fred E reckons that Sun will use IA64, one can assume he's talking about it )D running in Big-Endian mode, as for HP-UX . He could even argue that F IA64 would address both (Little and Big-Endian). What the Opteron doesA give Sun is the ability to run little-endian Solaris on a 64-bit  D machine. That gives 'em another weapon to  address the Alpha 64-bit . customers (Tru-64 and VMS). Interesting times.   -- m Cheers - Dave.   ------------------------------   Date: 20 Nov 2003 07:37:53 GMT2 From: "Dave Weatherall" <djw-nothere@nospam.nohow>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday5 Message-ID: <DTiotGxQ0bj6-pn2-KG9HevQ5jkd6@localhost>   C On Wed, 19 Nov 2003 14:45:35 UTC, jlsue <jefflsxxxz@sbcglobal.net> p wrote:  H > On Wed, 19 Nov 2003 01:29:08 -0500, David Froble <davef@tsoft-inc.com> > wrote: >  > >John Smith wrote: > >- > >> jlsue wrote:e > >> v > >  > >:W > >You're real encouraging.  It's my fear also.  Just didn't need my nose rubbed in it.U > >P > L > I hope you noticed who wrote what in this stream and don't attribute those > negative comments to me.  A It's the fact that it came from "John" that makes it depressing!!r   -- e Cheers - Dave.   ------------------------------  % Date: Thu, 20 Nov 2003 02:34:38 -0500r* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <js-dnQc38acW8yGiRVn-iw@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:Q+cRO12fRb3Y@eisner.encompasserve.org... ? > In article <NlOub.9336$6O6.2590@news.cpqcorp.net>, Rick Jonesn <foo@bar.baz.invalid> writes:(- > > Bill Todd <billtodd@metrocast.net> wrote: H > >> Of course not.  OTOH, Sun would have a legitimate excuse for havingF > >> taken this action (their actual inability to compete with SPARC -D > >> this still being the hypothetical situation which you posited), > >EH > > So you don't think there would be SPARCophiles asserting that if SunG > > had only put the resources into making/keeping SPARC competitive itdJ > > would have been able to rule the roost?  Their favorite processor, oneF > > they had stuck with for knuth knows how many years would be gone -D > > they are all going to simply accept it as a rational and logical > > course of events?  > >l >t" > Twisty little passage, isn't it?  8 Nope.  Just an attempt to twist by those with an agenda.   > @ > What is the rational for offering 2-way and 4-way Opterons and7 > later higher CPU counts?  'Cause SPARC is going away.j  L Nope.  It's because while SPARC performance satisfies a goodly percentage ofK Sun's customers (and SPARC64 will satisfy even more), it does not offer the ? leading-edge performance that *some* Sun customers may require.t  H Opteron does offer that performance leadership, and extends (with binaryL compatibility) a hardware line (x86) that Sun already sells, and is the mostI cost/effective general-purpose processor on the planet, and (not entirely/L coincidentally) gives Sun a chance to poke Intel in the eye with a big stickH (the embrace of Opteron by both IBM and Sun removes the last obstacle toC penetrating business customers that Intel fanboys kept harping on).R  L But SPARC *can't* go away, if only because there's no way that customers canK migrate painlessly to Opteron (it's not even the same endianness as SPARC). K Opteron is simply a very attractive adjunct to Sun's existing product line,rF and might well become the platform of preference for high-performance,D low-thread-count applications (Niagara may offer at least equivalentJ performance for high-thread-count use), and hopefully will acquire a largeL percentage of SPARC Solaris applications, and might even eventually be builtK into large MP systems (if Sun were the first to do this, they might be ablekK to built a decent hardware sideline selling it for use by other OS vendors,j  even - gasp! - Windows vendors).  K Over time, SPARC might become to Sun something like what the z-series is tooI IBM:  a cornerstone of the corporation whose performance is surpassed (atfG least in smaller systems) by newer products but which still brings in a L large chunk of revenue and anchors the enterprise customer base.  But in any event it will be there.-  
   If SPARCB > really was price and performance superior (or to return there inB > a year or so), it would make little sense to devote resources to> > Opteron.  Who would want an Opteron when Solaris on next-gen > SPARC is so fantastic.  I You don't seem to grasp something that even Intel apparently has:  in theEK large-system space, single-thread performance is plateauing (or, to look atlH it another way, CPU power has gotten so far ahead of memory latency thatL increasing it farther makes little sense) and the future is throughput (likeE Tanglewood and Niagara - or EV8 with many-way SMT).  Niagara is Sun'seI large-system throughput solution, but in the 8-processor-and-under serversH space it could use the help of a high-performance engine like Opteron toL handle situations where raw performance or cost/performance is more critical than SPARC compatibility.t   >cC > So really, where is the bad management in all this?  SPARC wasn't G > properly nourished and fell substantially behind Power in performancef+ > and of course we see the results of that.g  K Actually, we're still mostly seeing the results of Sun's dramatic expansionwK during the dot-com and resulting contraction during the dot-bomb.  The mostgL recent figures on the server market show that most of the current rebound isG in 1- and 2-processor boxes, so the recovery that's starting hasn't yeteE helped Sun much (especially with the Ethernet NIC problem that haltedn3 shipment of their new low-end servers for a while).c  H By all accounts, SPARC *was* properly nourished (unlike Alpha), but fellL short in execution (also unlike Alpha).  Sun is in the fortunate position ofG being able to partner with another SPARC manufacturer with a compatiblefB higher-performance chip (SPARC64), and to have purchased the (alsoJ SPARC-compatible) Niagara technology from yet another company (Afara) - soE while its own development group may have faltered, there are feasiblee fall-backs.i   > A > For anyone to suggest Sun has a good plan or has been on courseeC > for the last 2 years, would have a tough time substantiating thate > claimc  L Indeed they would (at least if you ignore the Afara purchase).  The same wasI true of DEC in the late 1980s.  But Sun appears finally to have found theeI sense of direction that has recently been so visibly lacking:  it has itsi' recent software wins with China and AOLiJ  http://www.theregister.co.uk/content/54/34068.html ), its new partnershipL with Fujitsu to bolster the current SPARC line-up, the Niagara technology toG compete with Tanglewood in two years, and now an opportunity to open upt: significant new markets with Solaris and Linux on Opteron.  J That's not to say that it doesn't still have an uphill climb ahead if it'sH to regain its earlier position, but it now seems much better prepared to start moving that way.   - bill   ------------------------------  % Date: Thu, 20 Nov 2003 02:32:16 -0500e* From: JF Mezei <jfmezei.spamnot@istop.com>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday) Message-ID: <3FBC6DD3.CAE02EBD@istop.com>e   Dave Weatherall wrote:H > IA64 would address both (Little and Big-Endian). What the Opteron doesB > give Sun is the ability to run little-endian Solaris on a 64-bitE > machine. That gives 'em another weapon to  address the Alpha 64-bitu0 > customers (Tru-64 and VMS). Interesting times.  L Are there announced plans to give AMD's 64 bit 8086 functionality that wouldD enable that chip to be used to build wildfire/marvel class systems ?  M I can understand the 64 bit 8086 being almost right away something that couldeT displace DS and possibly ES class Alphas, but I doubt it could do GS class machines.  J Does the current incarnation of IA64 have what it takes to be the buildingG block of a wildfire/marvel class machine or must we wait for one or twot+ generations before it has the right stuff ?s  J (Let me reword the last question: do current IA64 based Superdomes from HPN have the hardware features that would enable VMS to run galaxies etc on them ?   ------------------------------  % Date: Thu, 20 Nov 2003 02:51:05 -0500.* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <SeOdnUrXo-H77yGiRVn-sw@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:jAS22C8TCe3l@eisner.encompasserve.org...e@ > In article <sYSdnaUwDrD5jyaiRVn-tA@metrocast.net>, "Bill Todd"  <billtodd@metrocast.net> writes:< > > "Rob Young" <young_r@encompasserve.org> wrote in message1 > > news:ii3JhXdjhYsG@eisner.encompasserve.org...- >- >- > >>B > >> Actually, no.  As we both know , Itanium is doing pretty good > >> from a sales standpoint > >cG > > I certainly don't know, or even suspect, that, Rob.  Please provide  salesTL > > figures so we can compare them against the competition.  The only figureJ > > I've seen recently is that sales are up 63% from the first half of theF > > year - and a 63% increase of an extremely small number is still an	 extremelya > > small number.O > >T >/= > Little teasers about.  As we can see from realworldtech.comp > Paul brings this forth:s >aC > http://www.fortune.com/fortune/fastforward/0,15704,545432,00.html  > 4 > "At Intel, spokesman Howard High says that Itanium4 > is actually doing better than most people realize.2 > The company will announce at its analyst meeting1 > later this week that analysts' estimates of its . > sales "are off by an order of magnitude," he2 > says. "This year and next are very big years for6 > Itanium," says High, "because people will see it has- > strong interest and that real companies ared! > implementing it for real work."9 >  > G > Again, as we both know Itanium is doing good from a sales standpoint.   L No, Rob:  *if* Intel announces actual sales figures this week, and *if* theyD actually are a full order of magnitude higher than had been reportedL (because it *would* take that much of a differenct to make them impressive),C *then* we'll know.  Until then, it's just more typical Itanic hype.n   - bill   ------------------------------  % Date: Thu, 20 Nov 2003 03:10:39 -0500t* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday2 Message-ID: <IPadnZiszKBh6yGiRVn-jA@metrocast.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messagec# news:3FBC6DD3.CAE02EBD@istop.com...d > Dave Weatherall wrote:J > > IA64 would address both (Little and Big-Endian). What the Opteron doesD > > give Sun is the ability to run little-endian Solaris on a 64-bitG > > machine. That gives 'em another weapon to  address the Alpha 64-bitI2 > > customers (Tru-64 and VMS). Interesting times. >iH > Are there announced plans to give AMD's 64 bit 8086 functionality that wouldoF > enable that chip to be used to build wildfire/marvel class systems ?  I It already has all the features required to build something better than aeE Wildfire-class system - perhaps along the lines of IBM's large POWERxaK systems.  But this would require using external cache-coherence mechanisms,sH since the cache-coherence mechanism built into the chip can't scale wellF beyond 4 or 8 processors (whether the chip could still use its on-chipK memory controller or whether that would have to be external as well I don't8J know:  my guess is that a way could be found to keep the memory local, butL that access to the memory on *other* CPUs would be significantly slower thanL it is in today's small Opteron systems - i.e., latency would become markedlyH less uniform, though it's possible that 4-processor modules with today'sJ intra-module cross-CPU latency could be used to make high-latency accesses
 less common).   B And a Marvel-class sysem is out of the question unless the on-chip> cache-coherence mechanism becomes directory-based as EV7's is.   >oI > I can understand the 64 bit 8086 being almost right away something that0 could-L > displace DS and possibly ES class Alphas, but I doubt it could do GS class	 machines.  >dL > Does the current incarnation of IA64 have what it takes to be the buildingI > block of a wildfire/marvel class machine or must we wait for one or two-- > generations before it has the right stuff ?r  H Superdome already is a Wildfire-class sysem:  that's why it scales up soG poorly compared with HP's zx1 system (just as Wildfire scaled up poorlyoJ compared with the ES Alpha systems).  A Marvel-class system will be beyondL Itanic's reach until it acquires EV7-style on-chip glue, which is rumored to& be arriving with Tanglewood in 2006-7.   >nL > (Let me reword the last question: do current IA64 based Superdomes from HPI > have the hardware features that would enable VMS to run galaxies etc oni them ?  D That's a completely different question.  My vague impression is thatL Superdome doesn't support the kind of fine-grained dynamic redistribution ofI CPU and memory resources that Galaxy was designed to support, but Fred orn  Hoff should really address that.   - bill   ------------------------------  # Date: Thu, 20 Nov 2003 13:45:35 GMTt# From: "John Smith" <a@nonymous.com>AB Subject: Re: Sun to use AMD Opteron - announcement expected MondayH Message-ID: <3A3vb.2127$H8X1.60@twister01.bloor.is.net.cable.rogers.com>   Dave Weatherall wrote:D > On Wed, 19 Nov 2003 14:45:35 UTC, jlsue <jefflsxxxz@sbcglobal.net> > wrote: > 3 >> On Wed, 19 Nov 2003 01:29:08 -0500, David Froblem >> <davef@tsoft-inc.com> wrote:P >> >>> John Smith wrote:s >>>l >>>> jlsue wrote:e >>>> >>>a >>>kE >>> You're real encouraging.  It's my fear also.  Just didn't need myo >>> nose rubbed in it. >>>h >>G >> I hope you noticed who wrote what in this stream and don't attributef! >> those negative comments to me.t >lC > It's the fact that it came from "John" that makes it depressing!!n    ? I don't know whether to thank you for that remark or apologize.h  I I know that I continue to dwell on advertising/marketing issues, and from I where I sit I just don't see the takeup of VMS systems with new customersfF occuring  in numbers sufficient to even just offset the decline in theK number of VMS systems being used by customers. So to use a swimming analog,fF one can be swimming ahead, treading water, or drowning with respect toE system sales. Without hard accurate numbers at my disposal I can only K comment anecdotally based on my observations within the VMS customer base Ii$ know about, and I see only drowning.   ------------------------------  # Date: Thu, 20 Nov 2003 14:29:45 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday8 Message-ID: <nvjprvg15rl0djqdqb8vdh90e17uesq8o6@4ax.com>  H On Thu, 20 Nov 2003 01:47:49 -0500, "Bill Todd" <billtodd@metrocast.net> wrote:     >hK >1.  SPARC would not be offering current performance leadership; Alpha did.C  F This one made me chuckle.  Our own local Sun bigot has argued just theI opposite many, many times over the years; particularly in Alpha's heyday.0   ------------------------------  # Date: Thu, 20 Nov 2003 14:37:36 GMTx& From: jlsue <jefflsxxxz@sbcglobal.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday8 Message-ID: <l2kprvcm3bajsrijfccd773gk820aol13a@4ax.com>  H On Thu, 20 Nov 2003 02:34:38 -0500, "Bill Todd" <billtodd@metrocast.net> wrote:     >pM >Nope.  It's because while SPARC performance satisfies a goodly percentage oflL >Sun's customers (and SPARC64 will satisfy even more), it does not offer the@ >leading-edge performance that *some* Sun customers may require.  E I'm curious, why was it OKAY for Sun to allow SPARC to drop behind inaH performance because it "satisfies a goodly percentage of" customers, but8 somehow it's not valid for HP to do the same with Alpha?  E Alpha may have been in a leadership position, but that really doesn'taE negate that the same business principles can apply to the decision to ! forego more long-term investment.e   > I >Opteron does offer that performance leadership, and extends (with binary M >compatibility) a hardware line (x86) that Sun already sells, and is the most J >cost/effective general-purpose processor on the planet, and (not entirelyM >coincidentally) gives Sun a chance to poke Intel in the eye with a big stickhI >(the embrace of Opteron by both IBM and Sun removes the last obstacle to D >penetrating business customers that Intel fanboys kept harping on).  B One problem, though, is that to date there are no mid- to high-endK AMD-based systems.  There is no track record for these systems to determinesI how they perform in the real world.  There's nothing to really compare to 9 except workstation and hypothetical server-class systems.i   >sJ >You don't seem to grasp something that even Intel apparently has:  in theL >large-system space, single-thread performance is plateauing (or, to look atI >it another way, CPU power has gotten so far ahead of memory latency thatrM >increasing it farther makes little sense) and the future is throughput (likeaF >Tanglewood and Niagara - or EV8 with many-way SMT).  Niagara is Sun'sJ >large-system throughput solution, but in the 8-processor-and-under serverI >space it could use the help of a high-performance engine like Opteron tohM >handle situations where raw performance or cost/performance is more criticale >than SPARC compatibility.  H And, to date, it's not clear how well Opteron will be able to perform inH the multi-processor space that competes with other server class systems.H I'm not saying that it will fail, but there's no way to discuss relativeH capabilities because they don't much exist today.  They may have to makeG trade-offs in the system design that inhibit it's competing well in thek8 over-4-processor market.  We just really don't know yet.   ------------------------------  # Date: Thu, 20 Nov 2003 14:54:43 GMTr& From: jlsue <jefflsxxxz@sbcglobal.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday8 Message-ID: <5skprvg37bok5c0u68bsvp4tddtp090dua@4ax.com>  H On Wed, 19 Nov 2003 14:50:41 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:   >Rob Young wrote:cP >>         Again, as we both know Itanium is doing good from a sales standpoint.; >>         The Itanic moniker is getting funnier every day.  >oE >Has IA64 surpassed combined sales of Alpha and PA-Risc systems yet ?-N >If not, wake me up when it does. Until this happens, IA64 is just a prototypeQ >baby chip that exists only because a 2 million pound gorilla says it must exist.3  J I welcome competition in industry - including Power and AMD in competitionF with Intel (is there anything else worth watching?).  Two chip vendorsK isn't enough in my opinion, and 5 would be too many (too much confusion ande< incompatibility in the market for today's business climate).  J 3, and perhaps 4 is a good number for my liking.  Personally, I like AMD -H I build my own computers at home and tend to use AMD over Intel.  I likeJ that they have the ability to pressure Intel to work harder to excel.  And3 likewise, Intel pushes AMD to work harder to excel.    ------------------------------  # Date: Thu, 20 Nov 2003 15:57:13 GMTi& From: jlsue <jefflsxxxz@sbcglobal.net>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday8 Message-ID: <rfoprvkkesvvv1m1ei5gi4974re17du1j8@4ax.com>  H On Wed, 19 Nov 2003 17:43:08 -0500, JF Mezei <jfmezei.spamnot@istop.com> wrote:   >Rob Young wrote:-I >> > Has IA64 surpassed combined sales of Alpha and PA-Risc systems yet ?  >> rL >>         Why should it?  Those CPUs are still being manufactured and sold. >iK >Then,  until IA64 surpasses "legacy, proprietary" chips such as PARisc ands[ >Alpha, it has absolutely no business making claims about industry standard or "commodity".V  D Oh puhlease.  Marketing speak will always say whatever, and redefineI whatever it wants.  This is true of pretty much every vendor (put the "." J in ".com" my arse).  IT managers have, unfortunately, bought into the ideaJ that Intel spells "industry standard".  I've never liked it, but I stopped0 letting it get my blood boiling a long time ago.   >iO >Such claims can only be made once the status has been taken from someone else. K >And right now, the status belongs to the 8086 architecture and Intel isn'tT >about to let go its 8086. > M >>         Here's a gurarantee - In 4 years time, Itanium will be selling 100:K >>         times more in numbers than PA-RISC and Alpha will be - combined.n >tL >I am not convinced. It may very well happen. On the other hand, IA64 may beO >stillborn and replaced by Intel's 64 bit 8086, at which point, remaining AlphahL >and PA-Risc stockpiles will still sell more than IA64 due to installed base >being bigger.  J It "may very well", but it's highly unlikely.  Intel has not put this muchI resource into a chip (including marketing) in a very long time (maybe noti since Pentium I).    ------------------------------  # Date: Thu, 20 Nov 2003 18:05:48 GMTt& From: Rick Jones <foo@bar.baz.invalid>B Subject: Re: Sun to use AMD Opteron - announcement expected Monday1 Message-ID: <0o7vb.9422$z8.5159@news.cpqcorp.net>e  ) Bill Todd <billtodd@metrocast.net> wrote: K > 2.  SPARC would not have a well-defined future product well on the way towI > completion that offered even greater performance leadership; Alpha did.r  ; So long before SPARC was terminated, Sun would have stoppedS) development of future SPARC CPUs/systems?   ; > You keep trying to draw parallels where they don't exist.e  F I'm not as certain of that as you - we will I suspect find out one way or the other a few years hence.   
 rick jones -- .. a wide gulf separates "what if" from "if only"F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  % Date: Thu, 20 Nov 2003 11:28:08 +01003" From: Didier Morandi <no@spam.com> Subject: Re: TELNET/PORT2 Message-ID: <3fbc9757$0$254$636a55ce@news.free.fr>   JF Mezei wrote:l  1 > Phillip Helbig---remove CLOTHES to reply wrote:t > I >>There is a menu where one can forward incoming connections to port X tof? >>a specific port and a specific IP address behind the router.   >  > L > Which router allows you to remap a port to another port ? I'd like to have4 > that. I have a Netgear RT314 and it won't do that.  O It's called NAT (as you know). You don't have a NAT submenu in your router WEB  
 interface?   D.   ------------------------------  # Date: Thu, 20 Nov 2003 11:52:37 GMTO" From:   VAXman-  @SendSpamHere.ORG Subject: Re: TELNET/PORT0 Message-ID: <00A292BB.5D44C34E@SendSpamHere.ORG>  X In article <1031119200814.3301B-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:% >On Wed, 19 Nov 2003, JF Mezei wrote:n >d2 >> Phillip Helbig---remove CLOTHES to reply wrote:L >> > There is a menu where one can forward incoming connections to port X toB >> > a specific port and a specific IP address behind the router.  >>  M >> Which router allows you to remap a port to another port ? I'd like to have 5 >> that. I have a Netgear RT314 and it won't do that.a > A >We have a bunch of Netopias at work which do this.  It is calledd >Port Mapping. >eH >I have a Linksys at home, which I think may be capable of this as well, >but I don't remember for sure.u  D I have a Netopia for T1 routing.  I *had* a Linksys for cable modem C routing -- a piece of junk IMO (Linksys and the cable modem).  Just C recently I replaced the Linksys with a Netopia ethernet router.  ItaA does allow NAT and PAT assignments whereas the Linksys would not.S --  L VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)COM            e5   "Well my son, life is like a beanstalk, isn't it?" s   ------------------------------  % Date: Thu, 20 Nov 2003 19:26:46 +0100a" From: Didier Morandi <no@spam.com>Y Subject: The Alpha Chip Engineering Group Revival (aka: today's HP/Intel presentation in a3 Message-ID: <3fbd0786$0$2773$626a54ce@news.free.fr>   Q I just attended an (excellent) HP/Intel co-presentation on the following subject:p   "HP integrity Servers Strategy"d  $ Good news. Hear (I signed *no* NDA):   [start of Intel speaker quote]Q 1. "The Intel Engineering Group is fully busy on the Itanium2 chip, so Intel has  P given to the former Compaq Alpha Engineering Group that was purchased two years * ago the mission to produce the Montecito."  E Good news. If this is true, we may see a *really good* Itanium3 chip.c  O 2. "We have invented with the Itanium family a revolutionary new technology. A gP CPU has three functions: load/compute/store. The Itanium chip can load the next 4 instruction while it is computing the previous one."   no comment.   M 3. "There are 75'000 employees at Intel today, among them 10'000 are working A( only on software, and 700 on compilers".  & 10'000 on software? Nice to hear that.   [start of HP speaker quote]eL 4. "When we had to merge HP and COMPAQ, there were 215'000 workstations and  227'000 mailboxes to federate".a  + %DCL-W-MBXDUP, duplicate mailboxes detectede   Now, the best one :t  L 5. "The HP-UX/11 PA-RISC to Itanium migration is a non-destructive upgrade".  5 ??? HP Engineering has (had?) "destructive" upgrades?( :-)2   D.   ------------------------------  % Date: Thu, 20 Nov 2003 13:10:20 +0100K" From: Didier Morandi <no@spam.com>A Subject: VAX/VMS to Itanium Newsletter statistics as of yesterday 2 Message-ID: <3fbcaf4b$0$257$636a55ce@news.free.fr>    October stats for download were:   English version: 332 French version: 21  8 As of yesterday, stats for November (.pdf and .doc) are:   English October version: 26i French October version: 66 English November version: 1166 French November version: 250    OpenVMS.org mirror not included.I The www.didiermorandi.com/vms/ directory is open for browsing (archives).   M Please send stuff for the next one. Looks like it may be interesting to some.aN Focus of next letter is: "Obsolete VAX/VMS software and/or not ported to i64".  ( Thanks for helping the VAX/VMS Community   D.+ firstnamelastname a t n e r i m d o t n e t  -- 0;           Read the latest VAX/VMS to Itanium Migration NewsmF   www.openvms.org/dmorandi/vaxvms2itanium_200311en.pdf (en USA mirror)A www.didiermorandi.com/vms/vaxvms2itanium_200311en.pdf (en Europe)iA www.didiermorandi.com/vms/vaxvms2itanium_200311fr.pdf (fr Europe)   7               Discover the FutureVAX: www.futurevax.comh  F didier morandi  ~ sarl au capital de 8 000 euros ~  Revendeur agr HPC      Expertise en environnement DIGITAL ~ Formation ~ ProgrammationsF Offshore ~ 5 av. A. Durand 31700 Blagnac France. Tl: 33(0)5 6131 6287D    SIRET 448 694 851 00016 RCS Toulouse http://www.didiermorandi.com   ------------------------------    Date: 20 Nov 2003 06:59:34 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)e& Subject: Re: VMS 2003 bootcamp summary3 Message-ID: <7AociaATKXQX@eisner.encompasserve.org>m  z In article <LKLub.9319$Ak6.877@news.cpqcorp.net>, lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman) writes:  ; > Doing the "Bootcamp" anywhere but Nashua or very close byi= > is a serious problem, due to the cost of having to have the = > Engineers travel.  There is both the cost of the travel andp< > housing itself, and the cost of having them away from work > for extended periods of time.7   And the cost of slow answers.i  6 On Tuesday I heard something technical I did not like.6 When I asked the technical person, I was told to raise3 the issue with the manager who was giving a related.9 session.  When I asked the manager in that later session,e7 the manager had already been prepped about the issue by27 the technical person, and the answer had changed to "We29 are having a meeting Friday morning from 9-11 am with the 7 relevant people back at the office".  By the end of the/7 week their meeting was complete, and as a result within 3 a week I heard (from a third person with whom I had 3 discussed the issue) a possible approach they might 6 be taking that would solve the issue I raised and also fulfill their original purpose.   7 The above would not have happened if the event had beenn even as far away as Boston.e   ------------------------------  % Date: Thu, 20 Nov 2003 11:25:15 +0100 " From: Didier Morandi <no@spam.com>. Subject: Re: What is port 557 openvms/ipc ????2 Message-ID: <3fbc96aa$0$237$636a55ce@news.free.fr>   JF Mezei wrote:n  C > The official port number list has well known port 557 assigned to-I > "openvms/ipc" and it was some guy at digital who is responsible for it.i > M > Considering it has the dreaded "open" in it, it means it was created during  > the dying years of Digital.a > I > Does anyone know what this is actually used for and by which software ?*   Inter Process Communicationb@ https://lists.tunes.org:1443/archives/moose/1993-May/000379.html   D.   ------------------------------  % Date: Thu, 20 Nov 2003 09:26:21 +0100 ) From: Roland Barmettler <itsme@127.0.0.1>e3 Subject: Re: [OT] Mac OS X: system folder not foundp5 Message-ID: <20031120092621.333221f0.itsme@127.0.0.1>0  
 Hello Paul  6 > Hi Roland, can you tell me where you got it, please?4 > I haven't managed to locate a copy here in CH yet.  0 Believe it or not, in Mediamarkt (Dietikon) :-))F I got it on the 25th of October where most Mac shops were already sold8 out, but Mediamarkt had still a whole shelf of Panthers.   Gr=FCessli, Roland   -- 3rd Law of Computing:          Anything that can go wrO  Segmentation fault (core dumped)   ------------------------------   End of INFO-VAX 2003.644 ************************