1 INFO-VAX	Thu, 15 Sep 2005	Volume 2005 : Issue 516       Contents: Re: DELL dumped Itanic DELL dumped Itanic?  Re: DELL dumped Itanic?  Re: DELL dumped Itanic?  Re: DELL dumped Itanic? , Re: Does going to VMS 8.? require recompiles, Re: Does going to VMS 8.? require recompiles, Re: Does going to VMS 8.? require recompiles/ Re: Finding directory file of current directory / Re: Finding directory file of current directory / RE: Finding directory file of current directory / Re: Finding directory file of current directory $ Re: HP SWB V1.7.8 consistent crasher$ Re: HP SWB V1.7.8 consistent crasher$ Re: HP SWB V1.7.8 consistent crasher* Re: HP to dump itanium - bring back alpha?* Re: HP to dump itanium - bring back alpha?* Re: HP to dump itanium - bring back alpha?) Re: HP to lay off 5,000 in France/Europe?   Re: Keeping OpenVMS in-the-house  Re: Keeping OpenVMS in-the-house3 Re: MPEG player with sound for "depth 24" graphics? 3 Re: MPEG player with sound for "depth 24" graphics? 3 Re: MPEG player with sound for "depth 24" graphics? 3 Re: MPEG player with sound for "depth 24" graphics? 3 Re: MPEG player with sound for "depth 24" graphics? , Re: OpenVMS FTP server with these features ?, Re: OpenVMS FTP server with these features ?, RE: OpenVMS FTP server with these features ?, Re: OpenVMS FTP server with these features ? Re: OT: WLAN is not a LAN  Re: OT: WLAN is not a LAN  Re: OT: WLAN is not a LAN  Re: OT: WLAN is not a LAN  Pathworks32 in Citrix  poor SCSI performance  Re: poor SCSI performance  RE: poor SCSI performance  Release of TAPESYS V6.2.0  Re: Sun using the "I" word Re: Sun using the "I" word Re: Sun using the "I" word Re: Sun using the "I" word Re: Sun using the "I" word Re: Sun using the "I" word Re: Sun using the "I" word Re: Sun using the "I" word  F ----------------------------------------------------------------------  # Date: Thu, 15 Sep 2005 14:48:22 GMT ( From: Alan Greig <greigaln@netscape.net> Subject: Re: DELL dumped Itanic = Message-ID: <WQfWe.69504$2n6.65700@fe3.news.blueyonder.co.uk>    JF Mezei wrote:    > E > It could also be a situation where HP's competitors are starting to I > smear that IA64 thing as much as they can, knowing that the press tends H > to like stories about Itanic's impending sinking. The more press about8 > IA64's sinking, the better HP's competitors are doing.  H Well I guess Dell will add their considerable weight to Itanium bashing E now they've dropped it. I think we can probably take that "?" of the  G "Subject:" now given that MSN/NBC/Wall Street Journal/The Inquirer and   others are all reporting it.  J http://moneycentral.msn.com/content/CNBCTV/Articles/Dispatches/P129579.asp  F "And Dell (DELL, news, msgs) will phase out it last computer based on K Intel's (INTC, news, msgs) Itanium chip, The Wall Street Journal reported."    --  
 Alan Greig   ------------------------------  % Date: Thu, 15 Sep 2005 06:53:23 -0400 ? From: "David Turner, Island Computers US Corp" <david@hpaq.net>  Subject: DELL dumped Itanic?0 Message-ID: <11iikh9kvnt7763@corp.supernews.com>   Wow talk about bad press...   J Within the same week, DELL dumps their Itanium server pages and SUN starts* slamming the chip they refer to as Itanic.  J I think the consensus of opinion now is the Itanium is dead; if not, it is1 in intensive care on a lung machine, with chronic  'HPatic failure".   J AND I know, I know, I know, I keep hunching on this one, but I would bet aI small toes that someone within HP is trying to get the Alpha chip back on  the product line.   . After all, 1,000,000 customers can't be wrong.  K You know, the only Itanium users I have talked to so far, are ones that got 2 one for $2000 whilst on a $2000 VMS training camp. i.e. they were free.I And sadly, that is only about 5 customers - note I say customers, becuase & they are STILL buying Alpha systems!!!  J The old cliche, "they can't even give them away" seems to hold true, n'est	 ce pas???     K I could also rant on about the fact that we can't get an HP rep to call us, K nor can we get ANY part numbers for Itaniums just in case we were asked for  one (tee hee tee hee)    --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402    ------------------------------  % Date: Thu, 15 Sep 2005 08:06:58 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>   Subject: Re: DELL dumped Itanic?, Message-ID: <432963B0.E082F7BC@teksavvy.com>  / "David Turner, Island Computers US Corp" wrote: L > Within the same week, DELL dumps their Itanium server pages and SUN starts, > slamming the chip they refer to as Itanic. > L > I think the consensus of opinion now is the Itanium is dead; if not, it is3 > in intensive care on a lung machine, with chronic  > 'HPatic failure"  0 far be it for me to be an HP apologist... but...  C It could also be a situation where HP's competitors are starting to G smear that IA64 thing as much as they can, knowing that the press tends F to like stories about Itanic's impending sinking. The more press about6 IA64's sinking, the better HP's competitors are doing.  C But fact remains that the bad image/publicity surrounding that IA64  thing is doing damage.   ------------------------------   Date: 15 Sep 2005 13:41:50 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)  Subject: Re: DELL dumped Itanic?+ Message-ID: <3otc0uF7o73hU2@individual.net>   0 In article <11iikh9kvnt7763@corp.supernews.com>,B 	"David Turner, Island Computers US Corp" <david@hpaq.net> writes: > L > The old cliche, "they can't even give them away" seems to hold true, n'est > ce pas???   F I've only seen one and it was not purchased but provided gratis by HP.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Thu, 15 Sep 2005 09:52:30 -0400 ? From: "David Turner, Island Computers US Corp" <david@hpaq.net>   Subject: Re: DELL dumped Itanic?0 Message-ID: <11iiv12h5u3a59c@corp.supernews.com>   Well there ya go !  ;0)    DT   --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   5 "Bill Gunshannon" <bill@cs.uofs.edu> wrote in message % news:3otc0uF7o73hU2@individual.net... 2 > In article <11iikh9kvnt7763@corp.supernews.com>,C > "David Turner, Island Computers US Corp" <david@hpaq.net> writes:  > > H > > The old cliche, "they can't even give them away" seems to hold true, n'est 
 > > ce pas???  > H > I've only seen one and it was not purchased but provided gratis by HP. >  > bill >  > --  L > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------    Date: 15 Sep 2005 04:55:07 -0700' From: "tadamsmar" <tadamsmar@yahoo.com> 5 Subject: Re: Does going to VMS 8.? require recompiles C Message-ID: <1126785307.848302.130380@g47g2000cwa.googlegroups.com>    Hoff Hoffman wrote: ^ > In article <wnZVe.12629$bA4.8009@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes: > :tadamsmar wrote: @ > :> I wondering how an upgrade from 7.3-2 to 8.something on our= > :> Alphas would impact the third party software we use.  Do 5 > :> the executable still run on 8 without recompile?  > :>? > :Non-privileged applications should be fine.  Device drivers, G > :applications with knowledge of system internal data structures, etc. D > :will need to be recompiled.  Depends on the third party software. >  >   Try it.  > B >   I'm not certain that Inner-mode code must be rebuilt.  Yes, itE >   might well need to be rebuilt -- but we've been making compatible C >   kernel-mode changes for a while now through the V7.* range, and E >   updating the appropriate kernel subsystem version masks as we go. B >   Your inner-mode code might well run unmodified, and unrebuilt. > 5 >   User-mode code is expected to run without change.  > F >   OpenVMS Alpha V8.2 wasn't a classic major upgrade; the most recent: >   one of those for OpenVMS Alpha was OpenVMS Alpha V7.0. > A >   Off-hand, I am aware of very little that won't work -- one of C >   the few pieces I've seen blow up was software that was assuming @ >   that the disk maximum block value DVI$_MAXBLOCK was also theB >   disk volume size.  Very little does that, of course -- it just? >   happended to be some of my own code, however.  This $getdvi B >   assumption can fail even on V7.3-2, with the advent of dynamic> >   volume expansion.  (See DVI$_VOLSIZE for the volume size.) > B >   As for the kernel-mode major upgrade code, you'll usually know= >   right quick if you need to rebuild, usually via the error C >   messages I'd expect to see reported by the kernel version masks A >   when you try to load or run an incompatible inner-mode image.  >  >  > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq P >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com   D OK, thanks guys.  I thought it might be major because of the Itanium support.  F I guess the message is that it might work.  I will contact the vendorsC and see if they have any info on 8.2.   Some of the vendors may not F formally test VMS upgrades these days, but they sometime have feedback6 from client who have upgraded their operating systems.  E I remember 7.0, the only upgrade that I had to back out of!  That one  probably should haveB never been released to everybody.  Proved the adage the one should avoid the .0 versions of	 software.    ------------------------------    Date: 15 Sep 2005 10:25:21 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 5 Subject: Re: Does going to VMS 8.? require recompiles 3 Message-ID: <Lxr4q7hf$tfb@eisner.encompasserve.org>   m In article <1126716946.769157.269990@g14g2000cwa.googlegroups.com>, "tadamsmar" <tadamsmar@yahoo.com> writes: = > I wondering how an upgrade from 7.3-2 to 8.something on our : > Alphas would impact the third party software we use.  Do2 > the executable still run on 8 without recompile?  F Make sure your third party vendor support covers 8.2, since regardlessE of the reason if you get a failure on 8.2 down the road and they will # not support it you are out of luck.    ------------------------------    Date: 15 Sep 2005 10:27:11 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) 5 Subject: Re: Does going to VMS 8.? require recompiles 3 Message-ID: <ByHlPqApZO7$@eisner.encompasserve.org>   m In article <1126785307.848302.130380@g47g2000cwa.googlegroups.com>, "tadamsmar" <tadamsmar@yahoo.com> writes:   G > I remember 7.0, the only upgrade that I had to back out of!  That one  > probably should haveD > never been released to everybody.  Proved the adage the one should > avoid the .0 versions of > software.   C My recollection is that 7.0 was announced as being for leading edge E tinkerers only, with those crucially interested in production quality * advised to stick with 6.x or wait for 7.1.   ------------------------------    Date: 15 Sep 2005 09:16:51 +0200. From: huber@NOBODY-mppmu.mpg.de (Joseph Huber)8 Subject: Re: Finding directory file of current directory+ Message-ID: <$q4vvVlats+e@vms.mppmu.mpg.de>   \ In article <4328BCC2.21BEBD42@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Joseph Huber wrote: G >> But to what purpose should a procedure want to do that ? If it wants H >> to write in a write-protected directory, then probably redirecting to+ >> sys$scratch: would be a cleaner solution  > H > Unpack a zip file into a directory such as dev:[chocolate]. In it is aB > command procedure to complete installation, and it needs to set F > ownership and protection on the chocolate.dir file sitting above the > current directory.  C But this situation should not be handled by an automatic procedure, A but by the human/administrator doing the installation beforehand  @ (after exiting the procedure with an appropriate error message),@ it is his/her fault anyhow to try it, and probably not indended.    --  @    Joseph Huber , Muenchen,Germany:  http://www.huber-joseph.de/   ------------------------------  % Date: Thu, 15 Sep 2005 03:44:31 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 8 Subject: Re: Finding directory file of current directory, Message-ID: <4329263D.59448E1D@teksavvy.com>   Joseph Huber wrote: E > But this situation should not be handled by an automatic procedure, B > but by the human/administrator doing the installation beforehandB > (after exiting the procedure with an appropriate error message),B > it is his/her fault anyhow to try it, and probably not indended.    ? Logically yes. But it is still more professional looking if the @ installation procedure can take care of everything in one smoothH sequential uninterrupted operation with the fewest possible manual tasks. required before or worse, during installation.  F In some cases, it is easier to implement DCL code to do something thanF to document what needs to be manually done and hope the system manager' actually reads the installation manual.    ------------------------------  % Date: Thu, 15 Sep 2005 19:31:45 +1000 6 From: "O'Brien Paddy" <Paddy.O'Brien@transgrid.com.au>8 Subject: RE: Finding directory file of current directoryX Message-ID: <8BAD914A0B8CA84C9E94187103A1AB9E05BEA7@EX-TG2-PR.corporate.transgrid.local>  , This is a multi-part message in MIME format.  ' ------_=_NextPart_001_01C5B9D8.49CE1444 . Content-Type: text/plain; charset="iso-8859-1"+ Content-Transfer-Encoding: quoted-printable      [snips]    -----Original Message-----. From: Dave Froble [mailto:davef@tsoft-inc.com] Sent: Thu 9/15/2005 1:42 PM  To: Info-VAX@Mvb.Saic.Com 8 Subject: Re: Finding directory file of current directory =20 G Ok, my DCL is a bit rusty, and I have no ODS-5 experience, never yet=20 K found a reason to use ODS-5, but the following is a short proof of concept:    *****   L This is OT to JF's original question, but I have never initialised any disk=L s to ODS-5. I don't think I could cope with all the user's questions, and w=L hy VMS had to imitate that stupidity, I shall never understand.  With 39/39=L /5 as a file descriptor, we have more file names available to us than we co=
 uld ever use.   L Along with other contributors, any attempt I made at this (and I have writt=L en similar, but not quite what JF wanted) would never cope with ODS-5 oddit= ies.   Regards, Paddy  L (And I do apologise for this crap and advertising that is now inflicted on = us.)    G ***********************************************************************   C "This electronic message and any attachments may contain privileged @ and confidential information intended only for the use of the=20D addressees named above.  If you are not the intended recipient of=20C this email, please delete the message and any attachment and advise D the sender.  You are hereby notified that any use, dissemination,=207 distribution, reproduction of this email is prohibited.   C If you have received the email in error, please notify TransGrid=20 C immediately.  Any views expressed in this email are those of the=20 ? individual sender except where the sender expressly and with=20 C authority states them to be the views of TransGrid.  TransGrid uses > virus-scanning software but excludes any liability for viruses contained in any attachment.  < Please note the email address for TransGrid personnel is now$ firstname.lastname@transgrid.com.au"  G ***********************************************************************     ' ------_=_NextPart_001_01C5B9D8.49CE1444 - Content-Type: text/html; charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printable   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">  <HTML> <HEAD>L <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-= 1"> K <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7226.0"> > <TITLE>RE: Finding directory file of current directory</TITLE> </HEAD>  <BODY>) <!-- Converted from text/plain format -->  <BR>   <P><FONT SIZE=3D2>[snips]<BR>  <BR> -----Original Message-----<BR>L From: Dave Froble [<A HREF=3D"mailto:davef@tsoft-inc.com">mailto:davef@tsof= t-inc.com</A>]<BR> Sent: Thu 9/15/2005 1:42 PM<BR>  To: Info-VAX@Mvb.Saic.Com<BR> < Subject: Re: Finding directory file of current directory<BR> <BR>H Ok, my DCL is a bit rusty, and I have no ODS-5 experience, never yet<BR>L found a reason to use ODS-5, but the following is a short proof of concept:= <BR> <BR>	 *****<BR>  <BR>L This is OT to JF's original question, but I have never initialised any disk=L s to ODS-5. I don't think I could cope with all the user's questions, and w=L hy VMS had to imitate that stupidity, I shall never understand.&nbsp; With =L 39/39/5 as a file descriptor, we have more file names available to us than = we could ever use.<BR> <BR>L Along with other contributors, any attempt I made at this (and I have writt=L en similar, but not quite what JF wanted) would never cope with ODS-5 oddit= ies.<BR> <BR> Regards, Paddy<BR> <BR>L (And I do apologise for this crap and advertising that is now inflicted on = us.)<BR> </FONT>  </P>   <FONT SIZE=3D3><BR>  <BR>K ***********************************************************************<BR>  <BR>G "This electronic message and any attachments may contain privileged<BR> B and confidential information intended only for the use of the <BR>F addressees named above.  If you are not the intended recipient of <BR>G this email, please delete the message and any attachment and advise<BR> F the sender.  You are hereby notified that any use, dissemination, <BR>; distribution, reproduction of this email is prohibited.<BR>  <BR>E If you have received the email in error, please notify TransGrid <BR> E immediately.  Any views expressed in this email are those of the <BR> A individual sender except where the sender expressly and with <BR> G authority states them to be the views of TransGrid.  TransGrid uses<BR> B virus-scanning software but excludes any liability for viruses<BR>  contained in any attachment.<BR> <BR>@ Please note the email address for TransGrid personnel is now<BR>( firstname.lastname@transgrid.com.au"<BR> <BR>K ***********************************************************************<BR>  </FONT>  </BODY>  </HTML> ) ------_=_NextPart_001_01C5B9D8.49CE1444--    ------------------------------  + Date: Thu, 15 Sep 2005 12:57:08 +0000 (UTC) ? From: Graham Burley <burley.not-this@encompasserve-or-this.org> 8 Subject: Re: Finding directory file of current directory9 Message-ID: <43296FDE.63646FAF@encompasserve-or-this.org>    JF Mezei wrote:  >   G > I was hoping there was a simple magic incantation that would solve my  > problem. But I guess not.   % In simple magic incantation notation:   F $ dir_fn = f$parse("[-]"+("*"+(f$parse("[]",,,"DIRECTORY")+"*"-"]*") -D          -(f$parse("[-]",,,"DIRECTORY")+"*"-"]*")-"*."-"*[")+".DIR")  D dir_fn might be "" for a current directory of [000000] or some other reason.    :-)    ------------------------------  # Date: Thu, 15 Sep 2005 15:53:54 GMT # From: hoff@hp.nospam (Hoff Hoffman) - Subject: Re: HP SWB V1.7.8 consistent crasher 4 Message-ID: <mOgWe.12714$L65.11427@news.cpqcorp.net>  Y In article <JqSdnbZHq90aR7XeRVn-iA@megapath.net>, JORDAN <rjordan@mindspring.com> writes: E :I'm posting here because I don't have a graphics-capable alpha under , :support so I could submit through channels.  C   I am reading into your statement here, and particularly inferring B   that you do have systems under contract.  Just not workstations.  A   If you have an OpenVMS system under contract, do please contact B   the support center.  (I would personally expect that there wouldB   be support for running SWB with an X Windows remote display, andC   I would expect that you would be able to replicate the failure(s) A   here through this means from a system with a support contract.)     B :SWB V1.7.8 will crash 100% reliably by visiting either of the two :following commercial sites,    -   What are the URLs of the failing web sites?   J :                             then trying to go to another site or click aF :link on the displayed page.  I've tried using a bookmark or a historyF :item to move to another page I know works (www.earthlink.com, google,# :etc) and the browser crashes hard.   *   Did you try Mozilla on another platform?  D   If this is specifically Flash, it would also be obvious to see if -   disabling the Flash plug-in resolves this.    @   All of this is to try to isolate this to Mozilla itself, or to:   the OpenVMS SWB implementation, or to the Flash plug-in.  E   My (very) initial suspicion here would be the Flash plug-in itself, ;   or something errant within the Mozilla plug-in mechanism.     N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------    Date: 15 Sep 2005 09:43:06 -0700 From: jordan@ccs4vms.com- Subject: Re: HP SWB V1.7.8 consistent crasher B Message-ID: <1126802586.560303.80080@g43g2000cwa.googlegroups.com>   Hoff Hoffman wrote: [ > In article <JqSdnbZHq90aR7XeRVn-iA@megapath.net>, JORDAN <rjordan@mindspring.com> writes: G > :I'm posting here because I don't have a graphics-capable alpha under . > :support so I could submit through channels. > E >   I am reading into your statement here, and particularly inferring D >   that you do have systems under contract.  Just not workstations. > C >   If you have an OpenVMS system under contract, do please contact D >   the support center.  (I would personally expect that there wouldD >   be support for running SWB with an X Windows remote display, andE >   I would expect that you would be able to replicate the failure(s) C >   here through this means from a system with a support contract.)  >  >    Hoff, G      thanks for responding.  Yes, we do have an Alpha under contract at E work.  I guess I can see about trying it here but we'll have to get a < remote display up to try it.  Not going to happen this week.  D      If it does turn out to be the flash plugin, I wonder if supportA will do anything; the question will be if CSWB should allow for a C plugin failure to crash the browser itself, or should it handle the  error.  D > :SWB V1.7.8 will crash 100% reliably by visiting either of the two > :following commercial sites, > / >   What are the URLs of the failing web sites?  >   B I don't know how they got left out unless google is blocking them:        http://www.crucial.com         http://www.coldsteel.com     L > :                             then trying to go to another site or click aH > :link on the displayed page.  I've tried using a bookmark or a historyH > :item to move to another page I know works (www.earthlink.com, google,% > :etc) and the browser crashes hard.  > , >   Did you try Mozilla on another platform? >   G I don't currently have Mozilla on another box.  Current Firefox on a G5 E Mac or my work PC (win-nt, antique) had no trouble; they also had far " more current flash players though.  E >   If this is specifically Flash, it would also be obvious to see if . >   disabling the Flash plug-in resolves this. > B >   All of this is to try to isolate this to Mozilla itself, or to< >   the OpenVMS SWB implementation, or to the Flash plug-in. > G >   My (very) initial suspicion here would be the Flash plug-in itself, = >   or something errant within the Mozilla plug-in mechanism.  >   D Certainly sounds logical, and I hope to try that tonight.  I'll justA move the plugin out of the directory, and disable it within CSWB.   D I don't really know the level of connection between a plugin and theE browser, the type of error trapping or 'sandboxing' that is expected. A It would be interesting to know if a "hard" plugin failure really ! should crash the browser as well.   * I'll provide results on the test tomorrow.   Thanks again for responding!   Rich Jordan    ------------------------------  # Date: Thu, 15 Sep 2005 17:42:37 GMT # From: hoff@hp.nospam (Hoff Hoffman) - Subject: Re: HP SWB V1.7.8 consistent crasher 3 Message-ID: <hoiWe.12721$ea5.7752@news.cpqcorp.net>   ] In article <1126802586.560303.80080@g43g2000cwa.googlegroups.com>, jordan@ccs4vms.com writes: C :I don't know how they got left out unless google is blocking them:  :  :     http://www.crucial.com  :   Yes, there does appear to be broken code here somewhere.  1   Internal report PTR 75-109-617 has been logged.   ?   It is not clear if this is a Mozilla 1.7-vintage error within >   the Mozilla code, a plug-in or GTK or related error, or some<   other problem specific to the OpenVMS port of Mozilla/SWB.  ?   I would (still) encourage contact with the support center, as >   your report (citing this PTR) will get you in direct contact@   with the folks that will looking at this.  (That will probably   not likely be me, FWIW.)  N  ---------------------------- #include <rtfaq.h> -----------------------------K     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq N  --------------------------- pure personal opinion ---------------------------E         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  # Date: Thu, 15 Sep 2005 11:12:54 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) 3 Subject: Re: HP to dump itanium - bring back alpha? L Message-ID: <rdeininger-1509050712580001@user-105n84j.dialup.mindspring.com>  5 In article <432800AA.A02F7A81@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:    >Robert Deininger wrote:I >> Generally they have several bins for speed, cache size, etc.  The best L >> chips sell for significantly more money than the slowest.  They appear toL >> price the lower-end chips so they can sell pretty much all their yield of >> functioning chips.  > - >But for IA64, are there "lower end" chips ?   > H >I was under the impression that the current crop of IA64 chips were allE >the same. Or are there IA64 chips being produced today by Intel that C >have different speeds when sold and integrated into machines being  >assembled NOW ?  D There are somewhere in the range of 6 to 10 different Itanium-2 CPUs offered right now.   ------------------------------  # Date: Thu, 15 Sep 2005 11:17:34 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) 3 Subject: Re: HP to dump itanium - bring back alpha? L Message-ID: <rdeininger-1509050717390001@user-105n84j.dialup.mindspring.com>  5 In article <4328C5EF.42EC57A8@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:    >"Paul A. Jacobi" wrote:L >> The official Intel price list has 14 different variation of the Itanium 2
 >> processor.  >>  0 >> http://www.intel.com/intel/finance/pricelist/ >  >Thanks for pointer. > I >Would the slower variations with much lesser cache be current production 7 >models, or leftover stock of previously fabbed chips ?  > F >If they are current production models, would the 1 Ghz with 1.5meg ofA >cache be of the same mask as the 9meg 1.66ghz chip ? (eg: due to F >defects, they disable most of the cache and slow down the clock until >the chip works).   < They are current, and are evidently all from the same masks.  B Besides clock speed and cache size, there are differences in powerI envelope, front side bus speed, and maximum number of CPUs supported on a  bus.  3 I believe the data sheets are available from Intel.    ------------------------------  % Date: Thu, 15 Sep 2005 07:20:56 -0700 # From: "Tom Linden" <tom@kednos.com> 3 Subject: Re: HP to dump itanium - bring back alpha? ( Message-ID: <opsw5d46e1zgicya@hyrrokkin>  B On Thu, 15 Sep 2005 05:34:25 +0800, <prep@prep.synonet.com> wrote:  1 > JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  > > >> Read an article about Intel having managed to keep its 8086- >> manufacturing costs to about $40 per chip.  > C > I wonder if that includes test and package? If not, it means they ? > get about 100 good chips per wafer. Assuming a $4K wafer cost 0 > rather than the quoted industry number of $3K. > 7 > Anyone got the chip dimentions to calulate the yeild?  > A An article in EEtimes a couple of days ago quoted Intel as saying I that their average cost per die was $40, I believe that was for all chips  that they produce.   ------------------------------    Date: 15 Sep 2005 10:35:21 -0700 From: mark_hpq@yahoo.com2 Subject: Re: HP to lay off 5,000 in France/Europe?B Message-ID: <1126805721.529527.40550@g43g2000cwa.googlegroups.com>  B HP France will be on strike tomorrow while the French Director was	 requested C to meet the French delegate ministry of work to explain the layoffs  done despite  the profits made by the Company.   ------------------------------  % Date: Thu, 15 Sep 2005 01:44:20 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> ) Subject: Re: Keeping OpenVMS in-the-house , Message-ID: <43290A1A.11BED7D7@teksavvy.com>   Dave Froble wrote:I > They paid the hugh bucks, and seem to feel that they got good value for I > their money.  They want another project done.  The money spends just as  > well as any other.    F Funny how some companies seem to be so stingy for some items, yet haveC no problems keeping Windows projects on life support with continued P budget extensions because they don't want to be seen as having a failed project.  H One way I managed to keep a VMS box at a bank (DESPITE the local DigitalG office I must say) was quite simple: the applications department busily F spent $300,000 on a STUDY to replace the VAX with a Tandem machine forG SWIFT transfers. But instead of buying the whole Tandem software suite, D they insisted on just the bare bones SWIFT stuff on Tandem (of whichI they know zilch) and put the rest on AS400 (they had in-house expertise).   H Meanwhile, I was given a $200k budget to do a disaster recovery project,F most of which went to the telecom folks. IBM pooh poohed my project toG the VPs, saying that  volume shadowing can't be done. Thankfully, I had H just returned from a DECUS function where I had met with John Covert whoE had garanteed me that it is exactly why the HBVS had been written and H that it would work even on a 10mbps link. (this was at VMS 5.2 timeframeD when HVBS had just come out). Telling the senior VP of IT that I hadD just met one of the senior VMS engineers who confirmed that it wouldE work gave the project a lot of credibility and greatly deflated IBM's H balloon. I ended up getting 2 fibre strands on a big cable they had laidH between 2 data centres which remained little used because IBM mainframesD couldn't make intelligent use of the fibres (it needed 2 strands per% disk, and banks have a lot of disks).     A The project went thourgh, the $300k study to get rid of the VAXes G continued while I was implementing disaster recovery. And once I proved D that it worked, it put sticks in their study since now, the end userA demanded that the replacement system had equal or better disaster F tolerance than when they now had.  And the systems folks then rejected@ their proposals on the ground that having both Tandem and AS400sH replacing the VAX machines was ludicrous and add too much complexity and risks of downtime.  C The VMS machines stayed there for another 10 years. And they HAD to A leave VMS because SWIFT no longer supported VMS, thanks to Palmer H telling Swift in the mid 1990s to get off VMS which had become a primary) platform for the SWIFT terminal software.     F Their SUN based disaster recovery isn't as good, but it is acceptable. Besides, they had no choice.  D Oh, and during that time, the local Digital office was nowhere to beD seen, of course, except once when the virtual sales rep showed up toC complain to me that *I* was jeoperdizing their installed systems by G playing politics in the company - when I deflated IBM's balloon, it had G quite an impact because a few VPs had taken IBM's message to the bank's D president/CEO and got egg on their face when some insignificant geekG (me) proved them wrong when we went live with shadowed systems on time,  without a hitch).     D In this case, having a unique disaster recovery capability, combinedG with ability to run official SWIFT software was what forced the bank to E keep those unwanted VMS systems for about a decade after it had begun G efforts to get rid of them. Had it not been for Palmer telling Swift to H abandon VMS, those machines would still be there, although the margin ofF VMS' advantage for DR has diminished since competitors are closing in.   ------------------------------   Date: 15 Sep 2005 13:00:34 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)) Subject: Re: Keeping OpenVMS in-the-house + Message-ID: <3ot9jiF7k00tU2@individual.net>   0 In article <11ihj0skt0qvofa@corp.supernews.com>,* 	Dave Froble <davef@tsoft-inc.com> writes: > I > After being rather convincing, with lots of supporting evidence, I had  I > nothing to say after the chief decision maker said "I just don't trust  F > Compaq".  Precise quote, for those who might think I embelished any.  J Quite a change from the days when I personally heard someone say, "I don't; care who wins the RFP as long as it says VAX on the front."    bill      --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Thu, 15 Sep 2005 12:31:01 GMT * From: "FredK" <fred.nospam@nospam.dec.com>< Subject: Re: MPEG player with sound for "depth 24" graphics?3 Message-ID: <9QdWe.12705$QB4.9003@news.cpqcorp.net>   7 "Steven M. Schweda" <sms@antinode.org> wrote in message , news:05091423263393_202003A2@antinode.org...  C >    I did find an MPEG_PLAY (circa 1996, version 2.3?) which (with F > "-dither color") seems to do well enough with the pictures, but whenI > confronted with a full A/V experience, it (accurately) reports "This is J > an MPEG System Layer Stream.  Audio is not played.", and remains silent. > I >    I looked around for a while but could find no suitable audio-capable  > MPEG player. >   >    Is such a player available? >   , Let us know if you find one.  But I haven't.  H >    If the MMOV package is as frozen as it seems to be (18-APR-2000 forI > MMOV$ALPHAVCR.EXE), is there any chance of breaking the source loose so 8 > that some clever soul could fix a few of its problems? >   C I am a little pessimistic because of various legal issues regarding < image compression/decompression logic (despite the fact that3 such code can be found in many "freeware" sources).   J >    Would one of the PowerStorm 300 (PBXGD-AD) or 350 (-AE) cards restoreI > the multiple-color-depth capability missing from the fancy new card?  I G > gather that the Radeon 7500 (PBXGG-AB) has the same limitation.  What + > about the ELSA GLoria Synergy (PBXGK-BB)?  >   C Nope.  Unfortunately, the graphics market is driven by the needs of > Windows.  The RAMDAC designs on cards in the Windows market isF generally very flexible -- but does not in general contain things likeD multiple simultanious pixel formats or overlay planes (when they do,E it is often buried in extra HW for things like video source overlay - ? so in theory on some of these widgets you could simulate 8-bits  using a YUV overlay ;-).  C If I had endless free time, I would write some generic server logic J to simulate an 8-bit format on a 24-bit display.  It would suffer a littleF on the performance side for a number of operations, but it is possibleD to do.  In essence you would maintain a software colormap that wouldB be used to lookup the color value for the background/foreground GCB values, you would need to implement logic to convert image/pixmaps? into the screen format (and the other way around), and logic to D repaint the virtual 8-bit windows when colormap indexes are changed.   ------------------------------  % Date: Thu, 15 Sep 2005 08:10:02 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> < Subject: Re: MPEG player with sound for "depth 24" graphics?, Message-ID: <43296467.A0696BD9@teksavvy.com>   FredK wrote:E > If I had endless free time, I would write some generic server logic 3 > to simulate an 8-bit format on a 24-bit display.    @ Shorten your trip to Orlando to have only busines time at the HPH conference. Forego golfing, days at Disney, Universal, NASA etc. :-) :-)' :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)    ------------------------------    Date: 15 Sep 2005 15:16:32 +0200C From: vaxinf@chclu.chemie.uni-konstanz.de (Eberhard Heuser-Hofmann) < Subject: Re: MPEG player with sound for "depth 24" graphics?2 Message-ID: <43297430$1@merkur.rz.uni-konstanz.de>  K In article <05091423263393_202003A2@antinode.org>, sms@antinode.org (Steven  M. Schweda) writes: I >   I've finally moved up from my venerable AlpSta 200 4/233 to an XP1000 D >(only 500MHz), which is sufficiently perky to cope with the currentF >deluge of junk e-mail bounce messages caused by some folks forging myG >domain name in what must have been a very large batch of solicitations G >for some pharmceutical products being offered through some Web servers / >in Korea.  But enough about my other problems.  > D >   While the AlpSta 200 had an old but versatile PBXGA-BA (ZXLp-E2)C >graphics card, the XP1000 has a 3Dlabs OXYGEN VX1 (PBXGF-AB), with F >DECwindows set to a DECW$SERVER_PIXEL_DEPTH of 24.  This is generallyA >more satisfactory that the default depth of 8, but it does cause 0 >MMOV$ALPHAVCR.EXE to die, rendering it useless. > B >   I did find an MPEG_PLAY (circa 1996, version 2.3?) which (withE >"-dither color") seems to do well enough with the pictures, but when H >confronted with a full A/V experience, it (accurately) reports "This isI >an MPEG System Layer Stream.  Audio is not played.", and remains silent.  > H >   I looked around for a while but could find no suitable audio-capable
 >MPEG player.  >  >   Is such a player available?  > G >   If the MMOV package is as frozen as it seems to be (18-APR-2000 for H >MMOV$ALPHAVCR.EXE), is there any chance of breaking the source loose so7 >that some clever soul could fix a few of its problems?  > I >   Would one of the PowerStorm 300 (PBXGD-AD) or 350 (-AE) cards restore H >the multiple-color-depth capability missing from the fancy new card?  IF >gather that the Radeon 7500 (PBXGG-AB) has the same limitation.  What* >about the ELSA GLoria Synergy (PBXGK-BB)? >  >   Any other clever ideas?  > I >------------------------------------------------------------------------  > 5 >   Steven M. Schweda               (+1) 651-699-9818 4 >   382 South Warwick Street        sms@antinode-org >   Saint Paul  MN  55105-2547 >    How about the mplayer:  - ftp://mvb.saic.com/extra/mplayer-vms-pre5.zip   H Never managed to generate the executable from the source, but I'm pretty sure you are more skilful.    eberhard   ------------------------------  # Date: Thu, 15 Sep 2005 13:52:47 GMT * From: "FredK" <fred.nospam@nospam.dec.com>< Subject: Re: MPEG player with sound for "depth 24" graphics?3 Message-ID: <P0fWe.12708$P65.9962@news.cpqcorp.net>   : "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message& news:43296467.A0696BD9@teksavvy.com... > FredK wrote:G > > If I had endless free time, I would write some generic server logic 4 > > to simulate an 8-bit format on a 24-bit display. > B > Shorten your trip to Orlando to have only busines time at the HPJ > conference. Forego golfing, days at Disney, Universal, NASA etc. :-) :-)) > :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)   ) My trip to Orlando is about a 1 hr drive.    ------------------------------    Date: 15 Sep 2005 18:38:21 +01006 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)< Subject: Re: MPEG player with sound for "depth 24" graphics?, Message-ID: <4329bf9d$1@news.langstoeger.at>  _ In article <05091423263393_202003A2@antinode.org>, sms@antinode.org (Steven M. Schweda) writes: G >   If the MMOV package is as frozen as it seems to be (18-APR-2000 for H >MMOV$ALPHAVCR.EXE), is there any chance of breaking the source loose so7 >that some clever soul could fix a few of its problems?   M My MMOV$ALPHAVCR.EXE is from 31-MAR-2005 so you should upgrade to MMOV V2.2-1 1 but I don't know if this solves your problem ;-)     --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------    Date: 15 Sep 2005 08:41:19 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 5 Subject: Re: OpenVMS FTP server with these features ? 3 Message-ID: <dYZjQiidfkgc@eisner.encompasserve.org>   J In article <dg6bk7$jbh$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:  "M > The restart procedure is defined only for the block and compressed modes of N > data transfer. It requires the sender of the data to insert a special markerN > code in the data stream with some marker information. The marker informationQ > has meaning ONLY TO THE SENDER, but must consist of printable characters in the M > default or negotiated language of the control connection (ASCII or EBCDIC).   H   OK, so how does the receiver know that this is a "special marker code";   and not legitimate data.  (I don't have the RFC at hand).    ------------------------------    Date: 15 Sep 2005 09:14:24 -0500 From: briggs@encompasserve.org5 Subject: Re: OpenVMS FTP server with these features ? 3 Message-ID: <30K4hr0$Zmq+@eisner.encompasserve.org>   q In article <dYZjQiidfkgc@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: L > In article <dg6bk7$jbh$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes: >  "N >> The restart procedure is defined only for the block and compressed modes ofO >> data transfer. It requires the sender of the data to insert a special marker O >> code in the data stream with some marker information. The marker information R >> has meaning ONLY TO THE SENDER, but must consist of printable characters in theN >> default or negotiated language of the control connection (ASCII or EBCDIC). > J >   OK, so how does the receiver know that this is a "special marker code"= >   and not legitimate data.  (I don't have the RFC at hand).   @ In block transfer mode, there is a bit map of codes that is sentK to characterize the contents of each block.  Code 16 indicates the presence  of a restart marker.  G (This is based on memory from glancing through the RFC several days ago % and I may have some details mangled).   E By contrast, in stream mode, the data stream is nothing more than the G file contents.  There is no escape mechanism.  No way to embed metadata  in the data stream.    	John Briggs   ------------------------------  % Date: Thu, 15 Sep 2005 10:51:20 -0400 # From: "Dan Allen" <dallen@nist.gov> 5 Subject: RE: OpenVMS FTP server with these features ? : Message-ID: <JFEPKAPBPMDFDBOIANGDGEPOGMAA.dallen@nist.gov>   > -----Original Message-----D > From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org], > Sent: Thursday, September 15, 2005 9:41 AM > To: Info-VAX@Mvb.Saic.Com 7 > Subject: Re: OpenVMS FTP server with these features ?  >  > L > In article <dg6bk7$jbh$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes: >  "O > > The restart procedure is defined only for the block and compressed modes of P > > data transfer. It requires the sender of the data to insert a special markerP > > code in the data stream with some marker information. The marker informationA > > has meaning ONLY TO THE SENDER, but must consist of printable  > characters in the O > > default or negotiated language of the control connection (ASCII or EBCDIC).  > J >   OK, so how does the receiver know that this is a "special marker code"= >   and not legitimate data.  (I don't have the RFC at hand).  >  >    From RFC 959P ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++        3.4.2.  BLOCK MODE  G          The file is transmitted as a series of data blocks preceded by D          one or more header bytes.  The header bytes contain a countC          field, and descriptor code.  The count field indicates the B          total length of the data block in bytes, thus marking theE          beginning of the next data block (there are no filler bits). H          The descriptor code defines:  last block in the file (EOF) lastF          block in the record (EOR), restart marker (see the Section onD          Error Recovery and Restart) or suspect data (i.e., the dataG          being transferred is suspected of errors and is not reliable). E          This last code is NOT intended for error control within FTP. H          It is motivated by the desire of sites exchanging certain typesH          of data (e.g., seismic or weather data) to send and receive allC          the data despite local errors (such as "magnetic tape read C          errors"), but to indicate in the transmission that certain F          portions are suspect).  Record structures are allowed in this7          mode, and any representation type may be used.   C          The header consists of the three bytes.  Of the 24 bits of G          header information, the 16 low order bits shall represent byte D          count, and the 8 high order bits shall represent descriptor          codes as shown below.  H RFC 959                                                     October 1985 File Transfer Protocol            Block Header   @             +----------------+----------------+----------------+@             | Descriptor     |    Byte Count                   |@             |         8 bits |                      16 bits    |@             +----------------+----------------+----------------+  ?          The descriptor codes are indicated by bit flags in the D          descriptor byte.  Four codes have been assigned, where eachE          code number is the decimal value of the corresponding bit in           the byte.               Code     Meaning  -              128     End of data block is EOR -               64     End of data block is EOF 3               32     Suspected errors in data block 3               16     Data block is a restart marker   E          With this encoding, more than one descriptor coded condition E          may exist for a particular block.  As many bits as necessary           may be flagged.  @          The restart marker is embedded in the data stream as an>          integral number of 8-bit bytes representing printable?          characters in the language being used over the control D          connection (e.g., default--NVT-ASCII).  <SP> (Space, in theH          appropriate language) must not be used WITHIN a restart marker.  G          For example, to transmit a six-character marker, the following           would be sent:   (             +--------+--------+--------+(             |Descrptr|  Byte count     |(             |code= 16|             = 6 |(             +--------+--------+--------+  (             +--------+--------+--------+(             | Marker | Marker | Marker |(             | 8 bits | 8 bits | 8 bits |(             +--------+--------+--------+  (             +--------+--------+--------+(             | Marker | Marker | Marker |(             | 8 bits | 8 bits | 8 bits |(             +--------+--------+--------+   ------------------------------  + Date: Thu, 15 Sep 2005 17:38:25 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk5 Subject: Re: OpenVMS FTP server with these features ? ) Message-ID: <dgcbih$kod$1@news.mdx.ac.uk>   q In article <dYZjQiidfkgc@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: K >In article <dg6bk7$jbh$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:  > " N >> The restart procedure is defined only for the block and compressed modes ofO >> data transfer. It requires the sender of the data to insert a special marker O >> code in the data stream with some marker information. The marker information R >> has meaning ONLY TO THE SENDER, but must consist of printable characters in theN >> default or negotiated language of the control connection (ASCII or EBCDIC). > I >  OK, so how does the receiver know that this is a "special marker code" < >  and not legitimate data.  (I don't have the RFC at hand). >   L Well for block mode the block header consists of a descriptor code and blockJ length. The descriptor code describes what the block contains. One of the ' codes specifies a restart-marker block.   L In compressed mode escape sequences consisting of an escape byte (all zeros)? followed by the same descriptor codes as in blockmode are sent.       
 David Webb Security team leader CCSS Middlesex University   ------------------------------    Date: 15 Sep 2005 09:33:10 +0200. From: huber@NOBODY-mppmu.mpg.de (Joseph Huber)" Subject: Re: OT: WLAN is not a LAN+ Message-ID: <0BeVS1+xuR2l@vms.mppmu.mpg.de>   e In article <43289d39$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:  > Because I just got burned:> > Don't think a WLAN (Wireless LAN with WLAN-Bridge) is a LAN.E > AMDS, DECnet, LAT, MOP and SCS do NOT work across a WLAN. Silly me. F > It seems, only IP is (transparently) forwarded over a "WLAN-Bridge". >   < Therefore competent companies call it "Wireless LAN Router", not ...Bridge.      --  @    Joseph Huber , Muenchen,Germany:  http://www.huber-joseph.de/   ------------------------------    Date: 15 Sep 2005 00:54:12 -0700# From: "H Vlems" <hvlems@freenet.de> " Subject: Re: OT: WLAN is not a LANC Message-ID: <1126770852.826147.175070@g14g2000cwa.googlegroups.com>   F Peter, what kind of setup do you have? Two WLAN accesspoints connected> or one or more clients connected to a single WLAN accesspoint? Hans   ------------------------------   Date: 15 Sep 2005 13:38:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)" Subject: Re: OT: WLAN is not a LAN+ Message-ID: <3otbq2F7o73hU1@individual.net>   + In article <0BeVS1+xuR2l@vms.mppmu.mpg.de>, 1 	huber@NOBODY-mppmu.mpg.de (Joseph Huber) writes: g > In article <43289d39$1@news.langstoeger.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes:  >> Because I just got burned: ? >> Don't think a WLAN (Wireless LAN with WLAN-Bridge) is a LAN. F >> AMDS, DECnet, LAT, MOP and SCS do NOT work across a WLAN. Silly me.G >> It seems, only IP is (transparently) forwarded over a "WLAN-Bridge".  >>   > > > Therefore competent companies call it "Wireless LAN Router", > not ...Bridge.   >     B Not sure I understand the configuration or the desired result, butE the one I am working with on my desk right now has four modes; Access E Point, AP Client, Wireless Repeater and Wireless Bridge.  I know that F in Access Point mode it passes the MAC Address correctly because if itE didn't DHCP would not work through it and all of our wireless clients B get their addresses via DHCP.  If you are truly trying to run someE kind of cluster over somekind of Wireless Bridging I would expect the D bigger problem would be latency.  Wireless seems to have much higherE latency than the wired equivalents.  We have found in real world app- C lication here that a single hop become painfully slow (to users who D are used to 100BaseT) and at 2 or more hops even something as simple as DHCP times out.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Thu, 15 Sep 2005 10:21:08 -0500 & From: Thomas Wirt <twnews@kittles.com>" Subject: Re: OT: WLAN is not a LAN* Message-ID: <43299164.7050403@kittles.com>    Peter 'EPLAN' LANGSTOEGER wrote:   > Because I just got burned: > > > Don't think a WLAN (Wireless LAN with WLAN-Bridge) is a LAN.E > AMDS, DECnet, LAT, MOP and SCS do NOT work across a WLAN. Silly me. F > It seems, only IP is (transparently) forwarded over a "WLAN-Bridge". >  <Snip>  I We have a 3Com wireless bridge (802.11b, 2 units bridging a gap of about  G 1/2 mile) on our LAN, and we do LAT or it.  Before we went to 802.11b,  E we had a proprietary wireless bridge that also bridged correctly.  A  D wireless bridge (with 2 pieces of wireless equipment) should always B bridge all traffic whether it is IP or not.  The IP config on our : bridges is independent of the IP network they are serving.  B I have another set of bridges that I can not remotely administer, G because they do not have IP # that are valid on their WAN segments (it  D is left over from a previous scheme and owner).  They still fine as  bridges.  G I think that you need to check your config.  This should work with any  ( equipment that calls it's self a bridge.   --     Thomas Wirt  Operations Manager, IS Dept. Kittle's Home Furnishings  Indianapolis, IN   ------------------------------  % Date: Thu, 15 Sep 2005 17:37:05 +0100 % From: David Gray <police@spamcop.net>  Subject: Pathworks32 in Citrix8 Message-ID: <4b8ji1tp4fltm3dgnua5sn4rq0lefg4b2m@4ax.com>   Hi all,   A Anyone using Pathworks32 (Powerterm etc) in a Citrix environment?  Does it work ok, any pitfalls?     Dave.    ------------------------------  % Date: Thu, 15 Sep 2005 16:14:51 +0200 6 From: Horst Drechsel <ai05@sternwarte.uni-erlangen.de> Subject: poor SCSI performance= Message-ID: <00A49D99.10AD69D4.77@sternwarte.uni-erlangen.de>       Dear all,  D    we are running a VMS 7.2 cluster with an XP1000 (EV67) 667MHz/1GB@ server and experience very poor IO performance on all SCSI HDDs,; i.e. orders of magnitude below a standard Linux system with 
 IDE disks.  "    The XP1000 has 3 SCSI adapters:  <  -   PKA0 onboard SCSI Controller QLogic ISP1040 (Ultrawide)8  -   PKB0 PCI SCSI Controller QLogic ISP1020 (Ultrawide)?  -   PKC0 PCI SCSI Controller Symbios 53C895 LVD (Wide Ultra-2)     %    PKB0 is only used for tape drives; 6    PKA0 hosts the system disk (9GB Ultra2 LVD) plus an,         old ultrawide DEC RZ2CC-KA 4GB disk;,    PKC0 holds three 18GB Ultra160 LVD disks.  @    There are two other cluster members (Alphastation 400/233 and@ an AlphaPC164/500 MHz) with a couple of old 4GB disks. All disks> are mounted clusterwide. Data transfer rates are far below the8 maximum value of 20 MB/s of the slowest SCSI controller.  =    We wonder where the main reason of this bad IO performance F could be hidden: is it the SCSI controllers, HDDs or their combinationD on a bus, or cluster communication on IO traffic between the 3 nodesC such that the slowest component brings down the overall performance + to the level of the slowest component?        D    Various attempts to tune the relevant SYSGEN IO/packet and buffer' size parameters brought no improvement.   ?    If another SCSI PCI adapter is suggested I would be happy if @ someone could recommend a part compatible with our XP1000 (to be# upgraded to VMS 7.3-2 or 8.2 soon).   $    Thanks for any input and regards,        Horst Drechsel      --C ******************************************************************* C  Horst Drechsel      drechsel_at_sternwarte_dot_uni-erlangen_dot_de   Dr. Remeis Observatory     C  Astronomical Institute                     Phone: +49-951-95222-15 C  University Erlangen-Nuernberg                Fax: +49-951-95222-22 *  Sternwartstr. 7, D-96049 Bamberg, GermanyC *******************************************************************    ------------------------------  % Date: Thu, 15 Sep 2005 11:04:38 -0400 ? From: "David Turner, Island Computers US Corp" <david@hpaq.net> " Subject: Re: poor SCSI performance0 Message-ID: <11ij389ses2u2e0@corp.supernews.com>  * The IC-KZPEA-DB is supported on the XP1000  This is a 64 Bit U160 controllerJ Assuming your disks are at least U2 then you should get a good increase in disk performanceK You'll also need an U160 cable and terminator (the standard witht he XP1000 " was a UW scsi terminator and cable  
 Our prices   IC-KZPEA-DB $279 U160 7 Way $65   Regards    David    --     David B Turner Island Computers US Corp 2700 Gregory St, Suite 180 Savannah GA 31404  Tel: 912 447 6622 X201 Cell: 912 447 6622 X252  Fax: 912 201 0402  Email: dbturner@icusc.com  Web: http://www.islandco.com% ===================================== < All orders are subject to the following terms and conditions. of sale. These should be read before ordering.% http://www.islandco.com/warranty.html   C "Horst Drechsel" <ai05@sternwarte.uni-erlangen.de> wrote in message 7 news:00A49D99.10AD69D4.77@sternwarte.uni-erlangen.de...  >  >    Dear all, > F >    we are running a VMS 7.2 cluster with an XP1000 (EV67) 667MHz/1GBB > server and experience very poor IO performance on all SCSI HDDs,= > i.e. orders of magnitude below a standard Linux system with  > IDE disks. > $ >    The XP1000 has 3 SCSI adapters: > > >  -   PKA0 onboard SCSI Controller QLogic ISP1040 (Ultrawide): >  -   PKB0 PCI SCSI Controller QLogic ISP1020 (Ultrawide)A >  -   PKC0 PCI SCSI Controller Symbios 53C895 LVD (Wide Ultra-2)  >  > ' >    PKB0 is only used for tape drives; 8 >    PKA0 hosts the system disk (9GB Ultra2 LVD) plus an. >         old ultrawide DEC RZ2CC-KA 4GB disk;. >    PKC0 holds three 18GB Ultra160 LVD disks. > B >    There are two other cluster members (Alphastation 400/233 andB > an AlphaPC164/500 MHz) with a couple of old 4GB disks. All disks@ > are mounted clusterwide. Data transfer rates are far below the: > maximum value of 20 MB/s of the slowest SCSI controller. > ? >    We wonder where the main reason of this bad IO performance H > could be hidden: is it the SCSI controllers, HDDs or their combinationF > on a bus, or cluster communication on IO traffic between the 3 nodesE > such that the slowest component brings down the overall performance ( > to the level of the slowest component? > F >    Various attempts to tune the relevant SYSGEN IO/packet and buffer) > size parameters brought no improvement.  > A >    If another SCSI PCI adapter is suggested I would be happy if B > someone could recommend a part compatible with our XP1000 (to be% > upgraded to VMS 7.3-2 or 8.2 soon).  > & >    Thanks for any input and regards, >  >      Horst Drechsel  >  >  > --E > ******************************************************************* E >  Horst Drechsel      drechsel_at_sternwarte_dot_uni-erlangen_dot_de  >  Dr. Remeis Observatory E >  Astronomical Institute                     Phone: +49-951-95222-15 E >  University Erlangen-Nuernberg                Fax: +49-951-95222-22 , >  Sternwartstr. 7, D-96049 Bamberg, GermanyE > *******************************************************************    ------------------------------  % Date: Thu, 15 Sep 2005 12:52:48 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> " Subject: RE: poor SCSI performanceR Message-ID: <FD827B33AB0D9C4E92EACEEFEE2BA2FB6B28E8@tayexc19.americas.cpqcorp.net>   > -----Original Message-----B > From: Horst Drechsel [mailto:ai05@sternwarte.uni-erlangen.de]=20# > Sent: September 15, 2005 10:15 AM  > To: Info-VAX@Mvb.Saic.Com   > Subject: poor SCSI performance >=20 >=20 >    Dear all, >=20F >    we are running a VMS 7.2 cluster with an XP1000 (EV67) 667MHz/1GBB > server and experience very poor IO performance on all SCSI HDDs,= > i.e. orders of magnitude below a standard Linux system with  > IDE disks. >=20$ >    The XP1000 has 3 SCSI adapters: >=20> >  -   PKA0 onboard SCSI Controller QLogic ISP1040 (Ultrawide): >  -   PKB0 PCI SCSI Controller QLogic ISP1020 (Ultrawide)A >  -   PKC0 PCI SCSI Controller Symbios 53C895 LVD (Wide Ultra-2)  >=20 >=20' >    PKB0 is only used for tape drives; 8 >    PKA0 hosts the system disk (9GB Ultra2 LVD) plus an. >         old ultrawide DEC RZ2CC-KA 4GB disk;. >    PKC0 holds three 18GB Ultra160 LVD disks. >=20B >    There are two other cluster members (Alphastation 400/233 andB > an AlphaPC164/500 MHz) with a couple of old 4GB disks. All disks@ > are mounted clusterwide. Data transfer rates are far below the: > maximum value of 20 MB/s of the slowest SCSI controller. >=20? >    We wonder where the main reason of this bad IO performance H > could be hidden: is it the SCSI controllers, HDDs or their combinationF > on a bus, or cluster communication on IO traffic between the 3 nodesE > such that the slowest component brings down the overall performance / > to the level of the slowest component?    =20  >=20F >    Various attempts to tune the relevant SYSGEN IO/packet and buffer) > size parameters brought no improvement.  >=20A >    If another SCSI PCI adapter is suggested I would be happy if B > someone could recommend a part compatible with our XP1000 (to be% > upgraded to VMS 7.3-2 or 8.2 soon).  >=20& >    Thanks for any input and regards, >=20 >      Horst Drechsel  >=20 >=20 > --E > ******************************************************************* E >  Horst Drechsel      drechsel_at_sternwarte_dot_uni-erlangen_dot_de  >  Dr. Remeis Observatory   =20 E >  Astronomical Institute                     Phone: +49-951-95222-15 E >  University Erlangen-Nuernberg                Fax: +49-951-95222-22 , >  Sternwartstr. 7, D-96049 Bamberg, GermanyE > *******************************************************************  >=20   Horst,  $ A few suggestions for consideration:  C - OpenVMS V7.2 is approximately 6 years old (FRS early 1999), so an D upgrade is highly recommended. There has been a very large number ofE performance features added since this old release. Comparing a 6 year A old system to one that is only 1-2 years old is not really a fair  comparison. Reference:A http://h71000.www7.hp.com/openvms/os/openvms-release-history.html   F - ensure the disk drives are not fragmented. This can really slow downA disk drives and is the type of problem that slowly creeps in over F extended periods of time. Image backup-restores is one good way to fix this.   C - keep in mind that the 20MB transfer rates are typically best case D theoretical and the norm is much lower in reality - likely 10-14MB /& second is best case for 20MB/sec disk.  = - are any errors being logged while transfer is being tested?   @ - ensure no highwater marking feature is turned on (assumes this+ specific security feature not required).=20 " $ Set volume $1$dkaX: /nohighwater  * - check disk rates and queue lengths with: $ Mon disk and $ mon disk/item=3Dqueue    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Thu, 15 Sep 2005 11:24:48 -0400 4 From: "Doug Kimball" <dougkimball@spammydavisjr.net>" Subject: Release of TAPESYS V6.2.00 Message-ID: <11ij4id19o4ib73@corp.supernews.com>  K We have released V6.2.0 of TAPESYS. It works with VMS V8.2 on both Itanium  J and Alpha. Interested parties can contact me at 1-877-TAPESYS or dougk AT L softwarepartners dot com. Kits are downloadable and I can supply a demo key I via e-mail. (Current customers already have valid keys or qualify to get   them.) For more details, see  \ http://www.softwarepartners.com/service/tapesys_vms/doc/releasenotes/tapesys_notes_620.htm. 
 Thank you.   Doug Kimball Manager, Sales and Support Software Partners, Inc.    ------------------------------  % Date: Thu, 15 Sep 2005 02:43:18 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: Sun using the "I" word , Message-ID: <432917E8.294CCAF5@teksavvy.com>   Dave Froble wrote:D > I'm more current on the Athlon64 CPUs than the Opterons, so may beH > wrong.  I think the Opteron 275 is 90 nm, while itanic is still at .13G > micron.  So comparing apples and apples, the Opteron buyer is getting  > more current tech.     This is an invalid argument.  H That IA64 is 130nm while the 8086 is at 90 is irrelevant. What counts isC what I can buy TODAY.  HP offers proprietary IA64 things, while sun C offers industry standard commodity 8086 based systems at apparently # lower price for better performance.   C Yes, HP apologists have always pointed to the future when IA64 will F improve. Yes, IA64 will eventually go 90nm. Yes, it will go dual core.C And it may even one day have a coherent single cache for both cores   (which IBM's Power already has).    6 But since Merced, IA64 has continued to pay catch up.     G At least Alpha was a leader and wasn't needing to play catch up all the G time. And had Alpha been given the same amount of  resources that IA64, Q EV7 would have been released on time and made very difficult for its competitors.        E So Intel needs to decide whether its money/resources are better spent H improving the 8086, or splitting effort between the two, allowing AMD to@ retain its lead in the 8086 market (the one that really counts).  F The fact that there have been news recently of engineers being shiftedH from IA64 to 8086 is an indication that Intel understands what is reallyF important. But if this results in IA64 projects taking a little longerD to complete, it will result in a chip that is even less competitive.   ------------------------------  # Date: Thu, 15 Sep 2005 11:25:01 GMT 5 From: rdeininger@mindspringdot.com (Robert Deininger) # Subject: Re: Sun using the "I" word L Message-ID: <rdeininger-1509050725060001@user-105n84j.dialup.mindspring.com>  5 In article <432917E8.294CCAF5@teksavvy.com>, JF Mezei % <jfmezei.spamnot@teksavvy.com> wrote:    ...   H >At least Alpha was a leader and wasn't needing to play catch up all theH >time. And had Alpha been given the same amount of  resources that IA64,E >EV7 would have been released on time and made very difficult for its  competitors.  G That is nonsense.  The Alpha EV7 schedule was driven by the need to fix E critical bugs, and that is an area where more funding and more people J really don't help much.  How would you have deployed additional resourecesH to speed up the debug process?  How would you have cut the time requiredI for the needed designed changes to propagate through the factory and turn  into real silicon?  F >So Intel needs to decide whether its money/resources are better spentI >improving the 8086, or splitting effort between the two, allowing AMD to A >retain its lead in the 8086 market (the one that really counts).  > G >The fact that there have been news recently of engineers being shifted I >from IA64 to 8086 is an indication that Intel understands what is really G >important. But if this results in IA64 projects taking a little longer E >to complete, it will result in a chip that is even less competitive.   A Nobody outside Intel really knows what those engineers are doing.    ------------------------------   Date: 15 Sep 2005 12:54:59 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)# Subject: Re: Sun using the "I" word + Message-ID: <3ot993F7k00tU1@individual.net>   5 In article <slrndihl3f.2q1.usenet@zappy.catbert.org>, ( 	Dan Foster <usenet@evilphb.org> writes: > D > Though, HP has the one crown jewel that Sun doesn't have: OpenVMS.  G Yes, but their target for this ad is HP-UX users.  How many HP-UX users H do you think would choose to migrate to VMS rather than Solaris (or some other Unix variant)?     bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 15 Sep 2005 05:34:20 -0700 From: bob@instantwhip.com # Subject: Re: Sun using the "I" word B Message-ID: <1126787660.871584.21650@z14g2000cwz.googlegroups.com>  G vms will be ported or a lot of unhappy customers will leave HP forever!    ------------------------------  % Date: Thu, 15 Sep 2005 09:01:59 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> # Subject: Re: Sun using the "I" word , Message-ID: <43297091.DB04009F@teksavvy.com>   bob@instantwhip.com wrote: > I > vms will be ported or a lot of unhappy customers will leave HP forever!     @ I bet that was said of MPE users as well. And HP had no problems# abandonning Tru64 customers either.   G And look at VMS under Palmer. He decided that the future was Wintel and @ that VMS was just a necessary evil to pay the bills while he was' building a wintel side of the business.   H Contrary to Digital and to a large extent Compaq, HP doesn't need VMS toE survive, it has the very profitable ink business which subsidizes its  strategic endeavours.   > If HP judges that Tru64, VMS etc are of no long term strategicG significance and are too small to warrant serious efforts, then it will H let VMS live as long as it generates positive cash flow but won't expand much effort into it.    F I would very much like HP to prove to me and everyone else that VMS isE truly strategic to its business. Marketing VMS openly would go a long H way towards proving this. Announcing a port of VMS to 64 bit 8086s wouldG go a hell of a long way towards proving HP really wants VMS to succeed.     H Consistent lack of markleting only supports  the FUD about VMS' future. F And when you combine this with the media FUD about that IA64 thing, it does not help VMS's fortunes.     E FUD or not, VMS would have a much brighter future if it ran on 8086s. H MUCH brighter.  MUCH MUCH brighter, even if that IA64 thing continues toB be developped for decades, VMS would be better off on the industry standard platform.   ------------------------------    Date: 15 Sep 2005 10:32:00 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) # Subject: Re: Sun using the "I" word 3 Message-ID: <B4KUO$dGhjwF@eisner.encompasserve.org>   ^ In article <1126787660.871584.21650@z14g2000cwz.googlegroups.com>, bob@instantwhip.com writes:I > vms will be ported or a lot of unhappy customers will leave HP forever!   E I am not sure about "a lot", but the rest of have hope it will happen % soon and they will stop posting here.   G I apologize to the rest of you for my outburst -- a data circuit glitch I caused my killfile to go away and now I have to reconstruct it, one piece 
 at a time.   ------------------------------  % Date: Thu, 15 Sep 2005 12:25:30 -0400 ' From: Dave Froble <davef@tsoft-inc.com> # Subject: Re: Sun using the "I" word 0 Message-ID: <11ij7r5965mdh18@corp.supernews.com>   JF Mezei wrote:  > Dave Froble wrote: > D >>I'm more current on the Athlon64 CPUs than the Opterons, so may beH >>wrong.  I think the Opteron 275 is 90 nm, while itanic is still at .13G >>micron.  So comparing apples and apples, the Opteron buyer is getting  >>more current tech. >  >  >  > This is an invalid argument.  / It's not an argument, it's a statement of fact.   J > That IA64 is 130nm while the 8086 is at 90 is irrelevant. What counts isE > what I can buy TODAY.  HP offers proprietary IA64 things, while sun E > offers industry standard commodity 8086 based systems at apparently % > lower price for better performance.  > E > Yes, HP apologists have always pointed to the future when IA64 will H > improve. Yes, IA64 will eventually go 90nm. Yes, it will go dual core.E > And it may even one day have a coherent single cache for both cores " > (which IBM's Power already has). >  > 8 > But since Merced, IA64 has continued to pay catch up.   5 Yeah, I 'pay' for it every time you mangle something.   I The itanic is NOT playing 'catch up'.  It's just trailing behind.  If it  E was trying to 'catch up', that would be better than what's happening.   I > At least Alpha was a leader and wasn't needing to play catch up all the I > time. And had Alpha been given the same amount of  resources that IA64, S > EV7 would have been released on time and made very difficult for its competitors.   I What's this have to do with anything?  Alpha is dead.  Murdered, if that  H pleases you.  The topic was/is Sun is selling newer technology than the 0 itanic, for less, with better price/performance.  G > So Intel needs to decide whether its money/resources are better spent J > improving the 8086, or splitting effort between the two, allowing AMD toB > retain its lead in the 8086 market (the one that really counts).  E No, Intel doesn't need to make a decision.  They've already made the  I decision.  Engineers being moved to x86 work.  x86 already at 90 nm, and  H soon to be at 65 nm.  Intel is vigorously attempting to defend it's x86 / dominance, and all else is second rate at best.   H > The fact that there have been news recently of engineers being shiftedJ > from IA64 to 8086 is an indication that Intel understands what is reallyH > important. But if this results in IA64 projects taking a little longerF > to complete, it will result in a chip that is even less competitive.     --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Thu, 15 Sep 2005 13:23:50 -0400 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: Sun using the "I" word = Message-ID: <urudnfZSj7q7M7TeRVn-1w@metrocastcablevision.com>    Robert Deininger wrote: 7 > In article <432917E8.294CCAF5@teksavvy.com>, JF Mezei ' > <jfmezei.spamnot@teksavvy.com> wrote:  >  > ...  >  > I >>At least Alpha was a leader and wasn't needing to play catch up all the I >>time. And had Alpha been given the same amount of  resources that IA64, F >>EV7 would have been released on time and made very difficult for its >  > competitors. > I > That is nonsense.  The Alpha EV7 schedule was driven by the need to fix  > critical bugs   H According to the chip architects themselves (rather than kibitzers like H you who seem to believe any trash that the party line may dish out) the F EV7 schedule was frequently disrupted during the post-Pfeiffer era by D diversion of critical resources (including people) to work on other  activities.   G This does not mean that EV7 would have shipped in late Y2K/early 2001,  A as the schedule originally planned.  But it does indicate a) the  G relative priority with which Compaq viewed Alpha development (which is  I entirely consistent with the rest of the evidence at the CEO level, from  H the cancellation of AlphaNT development to the statement that the first I thing Curly discussed with Robison when the latter came on board was why  F continued Alpha development was not justifiable) and b) that this had ! *some* effect upon EV7 schedules.   F (Though it still doesn't explain why a chip that had been running VMS I and Tru64 for over 6 months in January, 2002, was at that time, when any  G flaws should already have been discovered, scheduled to ship in 2002Q3  F but then quietly slipped into 2003Q1:  that seems more likely to have D been pure stall time to avoid overshadowing the McKinley release in 
 mid-2002.)   - bill   ------------------------------   End of INFO-VAX 2005.516 ************************