1 INFO-VAX	Wed, 27 Jul 2005	Volume 2005 : Issue 416       Contents: Re: another CXX question) Re: Another VMS system bites the dust :-( ) Re: Another VMS system bites the dust :-( ) Re: Another VMS system bites the dust :-( ) Re: Another VMS system bites the dust :-( ) Re: Another VMS system bites the dust :-( ) RE: Another VMS system bites the dust :-( ) Re: Another VMS system bites the dust :-( " decw$font to PCF format converter?& Re: decw$font to PCF format converter?& Re: decw$font to PCF format converter?  Re: event occurred in BASEstar ?  Re: event occurred in BASEstar ? Re: IA64 .CALL_LINKAGE problem Re: IA64 .CALL_LINKAGE problem Re: IA64 .CALL_LINKAGE problem$ Looking for Oracle RAC on VMS Advice Re: Mozilla and ODS5 Re: Mozilla and ODS5 nsswitch equivalent  Re: nsswitch equivalent  Re: nsswitch equivalent ) Re: Performance issue after 7.3-2 upgrade 0 Re: Printing while defaulted to remote directory0 Re: Printing while defaulted to remote directory0 Re: Printing while defaulted to remote directoryP Re: Two New Itanium 2s Feature Faster Front-Side Bus - Is this new Montecito inf= Re: [OT] Rounding v Truncation, was: Re: Platform Support vs. = Re: [OT] Rounding v Truncation, was: Re: Platform Support vs.   F ----------------------------------------------------------------------    Date: 27 Jul 2005 07:54:37 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ! Subject: Re: another CXX question 3 Message-ID: <UhoyKRVN$dEQ@eisner.encompasserve.org>   i In article <wgrFe.9250$T%5.8015@news.cpqcorp.net>, "Ed Vogel" <edward.vogel_stop_the_spam@hp.com> writes:  > F >     A bug is a bug.  If a hobbyist reports it, a paying customer may- >     still encounter it.  We want to fix it.   B    Yeah, but we still appreciate it because we also deal with yourE    competition.  As in the following response when a paying customer  >    reported a Fortran compiler bug to a Microsoft support lineA    and offered to email a sample program that reproduced the bug:   G       "Sir, if we took problem reports from all our customers we'd have *        to spend all our time fixing them."   ------------------------------  % Date: Wed, 27 Jul 2005 16:17:55 +0200 3 From: "Dr. Dweeb" <NOSPAM_5msg0h202@sneakemail.com> 2 Subject: Re: Another VMS system bites the dust :-(= Message-ID: <42e79796$0$67264$157c6196@dreader2.cybercity.dk>    William Webb wrote: 4 > On 7/26/05, DeanW <dean.woodward@gmail.com> wrote:8 >> On 7/26/05, Stanley F. Quayle <stan@stanq.com> wrote:G >>>> But, that sounds like you were replacing hardware- not solving the E >>>> stated issue, "Integration"- or was there more to your proposal?  >>> F >>> "Integration" is a frequent excuse for eliminating VMS.  There areG >>> gobs of integration options for VMS, but that's not the real issue.  >>D >> In law enforcement, "Integration" between 911, police (incident &D >> investigation) records, corrections, supervision (probation), theH >> courts- is the hot topic. In many places, that's at least four and as! >> many as six different systems.  >>F >> We're currently working an interface for a customer to pull 911/CADE >> data to start the officer's incident reports, which (if someone is F >> arrested) can also pre-populates the the jail's booking data... TheE >> police and jail systems are already "integrated" (They're both our E >> product, and really, it's only one product), and interfaces to the ! >> courts have existed for years.  >>F >> I suspect the issue is that the Miami/Dade system was "home grown",A >> and nobody wanted to do the work to straighten it out. (Having F >> encountered "home grown" before, I know how ugly the design can be,G >> but the memories are locked away and only accessible by handing me a  >> beer... ;-) >>H >> You're probably right that hardware (VAX) maintenance costs were alsoG >> an issue. In any case, they saw VMS as part of the problem- too many 7 >> people associate "VMS" directly with "VAX". Too bad.  >> > = > Where's Jim Strehlow? the E-911 guy-- and his take on this?  >   M I guess the bottom line is that VMS is not going to revive any time soon.  I  I am a ware of an F500 company where billions of dollars worth of business  M runs through their Alpha/VMS systems.  2 guys running the lot.  They are not  H only forgotten, they are being replaced.  The HP people have pissed the L customer off so badly (and some software is not going to make it to Itanic) % that the decision is anything but HP.   E One less customer.  It will take a few years to get off the systems.  ) Service already terminated.  Bye Bye VMS.   M Sad, but that's not an atypical story these days.  VMS is on life support at  L all but the few critical places that have to have it - it is not a platform J of choice for the general computing world any more, no matter how much we  would like that to be the case.   ; I hope I retire before the last system gets the plug pulled     	 Dr. Dweeb   	 > WWWebb     ------------------------------  % Date: Wed, 27 Jul 2005 07:18:18 -0700 # From: "Tom Linden" <tom@kednos.com> 2 Subject: Re: Another VMS system bites the dust :-(( Message-ID: <opsuksosvzzgicya@hyrrokkin>  / On Wed, 27 Jul 2005 16:17:55 +0200, Dr. Dweeb   ( <NOSPAM_5msg0h202@sneakemail.com> wrote:  G > I guess the bottom line is that VMS is not going to revive any time   
 > soon.  IJ > am a ware of an F500 company where billions of dollars worth of businessL > runs through their Alpha/VMS systems.  2 guys running the lot.  They are   > not I > only forgotten, they are being replaced.  The HP people have pissed the G > customer off so badly (and some software is not going to make it to   	 > Itanic)    Which Software?   ' > that the decision is anything but HP. F > One less customer.  It will take a few years to get off the systems.+ > Service already terminated.  Bye Bye VMS. E > Sad, but that's not an atypical story these days.  VMS is on life    > support atF > all but the few critical places that have to have it - it is not a  
 > platformK > of choice for the general computing world any more, no matter how much we ! > would like that to be the case. = > I hope I retire before the last system gets the plug pulled    ------------------------------  % Date: Wed, 27 Jul 2005 08:26:10 -0700 ' From: David Mathog <mathog@caltech.edu> 2 Subject: Re: Another VMS system bites the dust :-(+ Message-ID: <dc892i$e6s$1@naig.caltech.edu>    Dr. Dweeb wrote:O > I guess the bottom line is that VMS is not going to revive any time soon.  I  K > am a ware of an F500 company where billions of dollars worth of business  ( > runs through their Alpha/VMS systems.    SNIP  3 > It will take a few years to get off the systems.  + > Service already terminated.  Bye Bye VMS.   E Let me get this straight: they're STILL running billions through this F equipment yet they have ALREADY terminated service on it?  Sounds like6 an episode of hardware or software failure is going to& be _really_ expensive for these folks.   Regards,   David Mathog   ------------------------------   Date: 27 Jul 2005 16:47:38 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)2 Subject: Re: Another VMS system bites the dust :-(+ Message-ID: <3kps5aFvmm7lU1@individual.net>   + In article <dc892i$e6s$1@naig.caltech.edu>, * 	David Mathog <mathog@caltech.edu> writes: > Dr. Dweeb wrote:P >> I guess the bottom line is that VMS is not going to revive any time soon.  I L >> am a ware of an F500 company where billions of dollars worth of business ) >> runs through their Alpha/VMS systems.   >  > SNIP > 4 >> It will take a few years to get off the systems. , >> Service already terminated.  Bye Bye VMS. > G > Let me get this straight: they're STILL running billions through this H > equipment yet they have ALREADY terminated service on it?  Sounds like8 > an episode of hardware or software failure is going to( > be _really_ expensive for these folks. >   B It's VMS. It's been up for 20 years with probably one service callB and that was 15 years ago.  They can see that the risk is minimal,> unfortunately they can't see the value in continuing with VMS.   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: Wed, 27 Jul 2005 13:39:51 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Another VMS system bites the dust :-(, Message-ID: <42E7C6E6.D65BE66D@teksavvy.com>   "Dr. Dweeb" wrote:F > One less customer.  It will take a few years to get off the systems.+ > Service already terminated.  Bye Bye VMS.   M The big question is whether VMS management have a realistic view of VMS' lack M of future (but can't say so publically), or whether they truly see a blue sky N without a single cloud on it because they only hear about individual sales andL never hear about lost customers, or sales where VMS could have won if it had been pitched and advertised.   ------------------------------  % Date: Wed, 27 Jul 2005 12:45:21 -0500 / From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> 2 Subject: RE: Another VMS system bites the dust :-(T Message-ID: <DA4AD590CAF06845B671C398333A89C60BF71592@ohms.electric.ci.austin.tx.us>  ? Yea, 15 years ago it was probably the 4.7 to 5.X upgrade. ;-)      EdE **Please apply a generous amount of all the usual disclaimers here.**      > -----Original Message-----" > From: bill@triangle.cs.uofs.edu B > [mailto:bill@triangle.cs.uofs.edu] On Behalf Of bill@cs.uofs.edu) > Sent: Wednesday, July 27, 2005 11:48 AM  > To: Info-VAX@Mvb.Saic.Com 4 > Subject: Re: Another VMS system bites the dust :-( > - > In article <dc892i$e6s$1@naig.caltech.edu>, , > 	David Mathog <mathog@caltech.edu> writes: > > Dr. Dweeb wrote:@ > >> I guess the bottom line is that VMS is not going to revive  > any time  = > >> soon.  I am a ware of an F500 company where billions of   > dollars worth 6 > >> of business runs through their Alpha/VMS systems. > >  > > SNIP > > 6 > >> It will take a few years to get off the systems. . > >> Service already terminated.  Bye Bye VMS. > > = > > Let me get this straight: they're STILL running billions   > through this  ? > > equipment yet they have ALREADY terminated service on it?    > Sounds like G > > an episode of hardware or software failure is going to be _really_   > > expensive for these folks. > >  > @ > It's VMS. It's been up for 20 years with probably one service > > call and that was 15 years ago.  They can see that the risk 8 > is minimal, unfortunately they can't see the value in  > continuing with VMS. >  > bill >  > --  @ > 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   |C > Scranton, Pennsylvania   |         #include <std.disclaimer.h>     >    ------------------------------  % Date: Wed, 27 Jul 2005 13:42:31 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 2 Subject: Re: Another VMS system bites the dust :-(, Message-ID: <42E7C786.486798CD@teksavvy.com>   Bill Gunshannon wrote:D > It's VMS. It's been up for 20 years with probably one service callD > and that was 15 years ago.  They can see that the risk is minimal,@ > unfortunately they can't see the value in continuing with VMS.  J If their software isn't going to be availble on that IA64 thing, then theyM don't have much choice. The minute HP announced end of sale for Alphas, those < customers have to start migration process to something else.  N And for those who software is available on that IA64 thing, they must considerM if it is worth moving to IA64 for just a few years intil VMS is either killed  or moved to the 8086.   A HP is making a huge mistake by ending Alpha system sales so soon.    ------------------------------   Date: 27 Jul 2005 09:54:55 GMT7 From: yehavi@vms.huji.ac.il (Yehavi Bourvine (58-4279)) + Subject: decw$font to PCF format converter? % Message-ID: <2005Jul27.095455@hujicc>    Hello,  O   I am using DECwindows over an NCD Xterminal up to now. The Xterminal read the O decw$font file and DECterminal windows are happy. Now I have to replace it with N a Linux based server (the Xterminal is almost dead...) and I have problem withJ the fonts (it doesn't find the correct fonts, thus I get a terminal window which is useable but ugly).   K   Is there a way to convert decw$font files to PCF? If not, any tips to the N parameters to use ni the  create/term command so teh terminal window will oook better?   4                                    Thanks, __Yehavi:   ------------------------------  # Date: Wed, 27 Jul 2005 11:03:31 GMT * From: "FredK" <fred.nospam@nospam.dec.com>/ Subject: Re: decw$font to PCF format converter? 2 Message-ID: <7SJFe.9307$EM6.3192@news.cpqcorp.net>  L Find an Alpha.  Alpha ships the fonts in PCF. There is no backward converter/ from compiled VAX format to BDF that I know of.   D "Yehavi Bourvine (58-4279)" <yehavi@vms.huji.ac.il> wrote in message news:2005Jul27.095455@hujicc...  > Hello, > H >   I am using DECwindows over an NCD Xterminal up to now. The Xterminal read theL > decw$font file and DECterminal windows are happy. Now I have to replace it withK > a Linux based server (the Xterminal is almost dead...) and I have problem  withL > the fonts (it doesn't find the correct fonts, thus I get a terminal window > which is useable but ugly).  > I >   Is there a way to convert decw$font files to PCF? If not, any tips to  the K > parameters to use ni the  create/term command so teh terminal window will  oook	 > better?  > 6 >                                    Thanks, __Yehavi:   ------------------------------   Date: 27 Jul 2005 14:53:01 GMT7 From: yehavi@vms.huji.ac.il (Yehavi Bourvine (58-4279)) / Subject: Re: decw$font to PCF format converter? % Message-ID: <2005Jul27.145301@hujicc>   N > Find an Alpha.  Alpha ships the fonts in PCF. There is no backward converter1 > from compiled VAX format to BDF that I know of.    Thanks! That's made the trick.  L I wasn't aware that Alpha has PCF fonts so I did not bother looking there...  3                                   Thanks! __Yehavi:    ------------------------------    Date: 27 Jul 2005 06:06:19 -0600/ From: John Eisenbraun <John.Eisenbraun@.hp.com> ) Subject: Re: event occurred in BASEstar ? = Message-ID: <Xns96A05272551F1JohnEisenbraunhpcom@15.8.40.106>    BG,    I forgot to ask...  F What version of BASEstar and what version of the AB DAS are you using?   John   ------------------------------    Date: 27 Jul 2005 06:03:17 -06002 From: John Eisenbraun <John.Eisenbraun@nospam.com>) Subject: Re: event occurred in BASEstar ? = Message-ID: <Xns96A051EEE6234JohnEisenbraunhpcom@15.8.40.106>    BG,   I I don't normally follow this newsgroup, but this entry was brought to my  
 attention.  9 > I'd pleased if anyone could tell me what this means ...  > = > our BASEstar on VMS system occurred some Events repeatedly.  > I > =======================================================================  > ======= BS> show history > ............. 3 > Event 21.25.6 occurred at 17-JUN-2005 18:00:31.21 % > Error occurred on VAX port LTA781:. 5 > Possible DLE ACK or DLE NAK embedded in packet - 5.   I This message means that the DAS encountered a DLE ENQ in what it thought  I was the middle of a packet.  (The "5" is the character it found which is  J an ENQ, not an ACK (6) or NAK (21), but a DLE ENQ should NEVER be part of 
 a packet.)  F The AB protocol supports a feature called "embedded response".  It is H enabled by a switch setting on the KE/KF card.  Your version of the DAS J doesn't support this feature - the latest does, but you aren't getting an F embedded response, so I don't think the card has this feature enabled.  3 > Event 21.25.6 occurred at 17-JUN-2005 18:00:32.18 % > Error occurred on VAX port LTA781:. 0 > Discarded garbage data on line - message lost.  H This means the DAS couldn't figure out the message, so it threw it away.  3 > Event 21.25.4 occurred at 17-JUN-2005 18:00:28.83 % > Error occurred on VAX port LTA781:.  > Bad QIO read status, > data overrun  I This message is pretty self-explanatory.  Is your typeahead buffer large  I enough and do you have alternate typeahead enabled?  show term lta783 to   see if Altypeahd is set.  
 mcr sysgen@ SYSGEN> sho/tty   ! to see typeahead size - should be 512 for AB  3 > Event 21.25.6 occurred at 17-JUN-2005 18:00:32.18 % > Error occurred on VAX port LTA781:. / > Did not find DLE STX at the start of message.   F Again the DAS is confused about what is being sent.  A DLE STX should H start every message, the DAS thinks it is at the start of a message and  there isn't a DLE STX there.   3 > Event 21.25.6 occurred at 17-JUN-2005 18:00:33.22 % > Error occurred on VAX port LTA781:.  > 1005.   G Not sure what this means.  A 1005 is a DLE ENQ which is a request from   the KE/KF to do a resend.   3 > Event 21.25.6 occurred at 19-JUN-2005 10:00:26.66 % > Error occurred on VAX port LTA783:.  > Unexpected ACK received.  4 The DAS received a DLE ACK when it didn't expect it.  @ > Does it mean that there is something wrong with the DECserver?  D I don't think it's a problem with the terminal server.  What is the F circuit timer set to?  It should be as low as possible.  The problems H look to me like it is very likely network related or your system may be J overloaded.  In either case it looks to me that the KE/KF isn't receiving G replies in a timely manner so that it is sending DLE ENQs (request for  D resend) when the reply has already been sent (as far as the host is J concerned).  Noise on the line is also a possibility, but it doesn't look  like that to me in this case.   F > It's not a very big problem as it works, but I'd love to understand.D > is there any way I could change any setting so it would not occure > error event?    C It works probably because there are retries going on, but there is  G definitely a problem happening.  The problems seem to happen (at least  H from this log) at about the same time of day.  Is there unusual load on . the network/and/or system at this time of day?  G If you want to contact BASEstar Engineering directly in the future you  H can send e-mail to basestar-support@nospam.hp.com (remove the nospam!).    John Eisenbraun  BASEstar Engineering   ------------------------------  # Date: Wed, 27 Jul 2005 14:44:11 GMT & From: John Reagan <john.reagan@hp.com>' Subject: Re: IA64 .CALL_LINKAGE problem 2 Message-ID: <%4NFe.9320$sW6.6964@news.cpqcorp.net>    VAXman- @SendSpamHere.ORG wrote:M > %ILINK-W-LNKGERR, linkage to routine STR$GET1_DX_R4 is not compatible with   > linkage of caller  >         calling module: ; >                 file: DISK:[PRODUCT]PRODUCT_ROUTINE.OBJ;1   >         target  module: LIBRTL7 >                 file: SYS$COMMON:[SYSLIB]LIBRTL.EXE;1 F >         IA64 register R4 (Alpha R4) -- call=PRESERVE, target=SCRATCH >  > ) > .CALL_LINKAGE RTN_NAME=STR$GET1_DX_R4 - 3 >                    LANGUAGE=OTHER INPUT=<R0,R1> - " >                    OUTPUT=<R0> -- >                    PRESERVE=<R8,R9,R10,R11>  > K > I believe the definition is wrong for this linkage.  Do I need to define  I > this .CALL_LINKAGE with SCRATCH=<R4> ???  Or is there some other issue?  >   C Yep, the definition for STR$GET1_DX_R4 (and many of the other STR$  F linkages) are missing SCRATCH=<...> sections.  You can declare you ownI linkage for STR$GET1_DX_R4, but you'll get a warning message from IMACRO  B saying you are replacing an existing linkage with a different one.  H I was going to suggest to use .DEFINE_LINKAGE and .USE_LINKAGE to define you own linkage as follows:             $ia64_linkages ;          .DEFINE_LINKAGE MY_STR$GET1_DX_R4 LANGUAGE=OTHER -                    INPUT=<R0,R1> -                  OUTPUT=<R0> -(                  SCRATCH=<R1,R2,R3,R4> -)                  PRESERVE=<R8,R9,R10,R11>    a::     .call_entry '          .USE_LINKAGE MY_STR$GET1_DX_R4           jsb str$get1_dx_r4           ret
          .end   I but guess what?  The compiler dies.  I swear I tested with overriding an  2 existing linkage.  That is one of the uses for it.  I So I had to move the address of STR$GET1_DX_R4 into another register and   JSB indirect though that.             $ia64_linkages ;          .DEFINE_LINKAGE MY_STR$GET1_DX_R4 LANGUAGE=OTHER -                    INPUT=<R0,R1> -                  OUTPUT=<R0> -(                  SCRATCH=<R1,R2,R3,R4> -)                  PRESERVE=<R8,R9,R10,R11>    a::     .call_entry            movab str$get1_dx_r4,r2'          .USE_LINKAGE MY_STR$GET1_DX_R4           jsb (r2)           ret
          .end   D You could modify IA64_LINKAGES in STARLET.MLB but the code won't be  portable anymore.   - - I'll fix the STR$ linkages in IA64_LINKAGES C - I'll fix the compiler not to barf with a .USE_LINKAGE to override     another linkage   Sigh...    --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  # Date: Wed, 27 Jul 2005 14:57:12 GMT " From:   VAXman-  @SendSpamHere.ORG' Subject: Re: IA64 .CALL_LINKAGE problem 0 Message-ID: <00A47622.67E391E1@SendSpamHere.ORG>  [ In article <%4NFe.9320$sW6.6964@news.cpqcorp.net>, John Reagan <john.reagan@hp.com> writes: ! >VAXman- @SendSpamHere.ORG wrote: N >> %ILINK-W-LNKGERR, linkage to routine STR$GET1_DX_R4 is not compatible with  >> linkage of caller >>         calling module:  < >>                 file: DISK:[PRODUCT]PRODUCT_ROUTINE.OBJ;1! >>         target  module: LIBRTL 8 >>                 file: SYS$COMMON:[SYSLIB]LIBRTL.EXE;1G >>         IA64 register R4 (Alpha R4) -- call=PRESERVE, target=SCRATCH  >>   >>  * >> .CALL_LINKAGE RTN_NAME=STR$GET1_DX_R4 -4 >>                    LANGUAGE=OTHER INPUT=<R0,R1> -# >>                    OUTPUT=<R0> - . >>                    PRESERVE=<R8,R9,R10,R11> >>  L >> I believe the definition is wrong for this linkage.  Do I need to define J >> this .CALL_LINKAGE with SCRATCH=<R4> ???  Or is there some other issue? >>   > D >Yep, the definition for STR$GET1_DX_R4 (and many of the other STR$ G >linkages) are missing SCRATCH=<...> sections.  You can declare you own J >linkage for STR$GET1_DX_R4, but you'll get a warning message from IMACRO C >saying you are replacing an existing linkage with a different one.  > I >I was going to suggest to use .DEFINE_LINKAGE and .USE_LINKAGE to define  >you own linkage as follows: >  >         $ia64_linkages< >         .DEFINE_LINKAGE MY_STR$GET1_DX_R4 LANGUAGE=OTHER -! >                 INPUT=<R0,R1> -  >                 OUTPUT=<R0> - ) >                 SCRATCH=<R1,R2,R3,R4> - * >                 PRESERVE=<R8,R9,R10,R11> >  >a::     .call_entry( >         .USE_LINKAGE MY_STR$GET1_DX_R4 >         jsb str$get1_dx_r4
 >         ret  >         .end > J >but guess what?  The compiler dies.  I swear I tested with overriding an 3 >existing linkage.  That is one of the uses for it.  > J >So I had to move the address of STR$GET1_DX_R4 into another register and  >JSB indirect though that. >  >         $ia64_linkages< >         .DEFINE_LINKAGE MY_STR$GET1_DX_R4 LANGUAGE=OTHER -! >                 INPUT=<R0,R1> -  >                 OUTPUT=<R0> - ) >                 SCRATCH=<R1,R2,R3,R4> - * >                 PRESERVE=<R8,R9,R10,R11> >  >a::     .call_entry! >         movab str$get1_dx_r4,r2 ( >         .USE_LINKAGE MY_STR$GET1_DX_R4 >         jsb (r2)
 >         ret  >         .end  I If it were an informational instead of a warning, I could like with that.       E >You could modify IA64_LINKAGES in STARLET.MLB but the code won't be   >portable anymore.  G It's not going to be compiled anywhere but on my machine(s) so I might   fix the $IA64_LINKAGE macro.      . >- I'll fix the STR$ linkages in IA64_LINKAGESD >- I'll fix the compiler not to barf with a .USE_LINKAGE to override >   another linkage   H Can you forward these to me?  I assume they'll be in the next release asH corrected linkage defs so I don't see to much issue with fixing my macro	 defs now.        >Sigh...  / Hey, somebody has to keep you on your toes!  :P    --  K VAXman- A Bored Certified VMS Kernel Mode Hacker   VAXman(at)TMESIS(dot)COM              5   "Well my son, life is like a beanstalk, isn't it?"     ------------------------------  # Date: Wed, 27 Jul 2005 17:42:12 GMT & From: John Reagan <john.reagan@hp.com>' Subject: Re: IA64 .CALL_LINKAGE problem 2 Message-ID: <UHPFe.9342$cl6.2433@news.cpqcorp.net>    VAXman- @SendSpamHere.ORG wrote:   >  > K > If it were an informational instead of a warning, I could like with that.  >  >  >   C Yep, I'm also changing them from -W- to -I-.  I'm also considering  B making them silent by default unless you say /FLAG=LINKAGES.  The F current /FLAG=LINKAGES is there to control the GEM linkage informationG but I think I want to also use them to suppress these linkage messages  G as well.  I might tie them to /FLAG=LINKAGES but change the default to   ON.  Not sure yet.     > J > Can you forward these to me?  I assume they'll be in the next release asJ > corrected linkage defs so I don't see to much issue with fixing my macro > defs now.  >   6 Yep, I'll send them to you and post them here as well.  H I missed the cut off date for what should be the V8.2-1 release, but it $ will go into the release after that.     --   John Reagan / HP Pascal/{A|I}MACRO for OpenVMS Project Leader  Hewlett-Packard Company    ------------------------------  % Date: Wed, 27 Jul 2005 08:16:04 -0500 / From: "Stuart, Ed" <Ed.Stuart@austinenergy.com> - Subject: Looking for Oracle RAC on VMS Advice T Message-ID: <DA4AD590CAF06845B671C398333A89C60BF71290@ohms.electric.ci.austin.tx.us>  L Hello; we run Oracle databases in our VMS Cluster and are considering a moveI to RAC to increase the availability of the databases.  If you are running L RAC on VMS today and are willing to discuss your configuration please let me know.    EdE **Please apply a generous amount of all the usual disclaimers here.**    ------------------------------    Date: 27 Jul 2005 08:14:13 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Mozilla and ODS5 3 Message-ID: <ZUct3tRd48iP@eisner.encompasserve.org>   c In article <VR3$AvjpKXBO@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: s > In article <sfCPv911$lJl@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:  >>  7 >>   No, its in the jackets code.  Mozilla has no idea.  > G > For what purpose was that written ?  What (besides Mozilla) uses it ?   E    Anybody porting code from UNIX to VMS can use it (it's been freely H    downloadable for years).  It was written to deal with UNIX-isms that H    native VMS routines didn't implement, like making all the filesystemsE    appear to start at "/", or the C RTL implemented in a manner which L    distinctly varies from the NUIX behaviour.  It's basically a predecessor J    and alternative to GNV and both more recent and still upcoming VMS and     C RTL enhancements.   ------------------------------    Date: 27 Jul 2005 11:54:04 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Mozilla and ODS5 3 Message-ID: <fqAQ3a$mBEpp@eisner.encompasserve.org>   q In article <ZUct3tRd48iP@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: e > In article <VR3$AvjpKXBO@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: t >> In article <sfCPv911$lJl@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>> 8 >>>   No, its in the jackets code.  Mozilla has no idea. >>  H >> For what purpose was that written ?  What (besides Mozilla) uses it ? > G >    Anybody porting code from UNIX to VMS can use it (it's been freely J >    downloadable for years).  It was written to deal with UNIX-isms that J >    native VMS routines didn't implement, like making all the filesystemsG >    appear to start at "/", or the C RTL implemented in a manner which N >    distinctly varies from the NUIX behaviour.  It's basically a predecessor L >    and alternative to GNV and both more recent and still upcoming VMS and  >    C RTL enhancements.  B So the experienced VMS person porting Mozilla adopted this without" bothering to consider its quality.   ------------------------------    Date: 27 Jul 2005 04:05:52 -0700 From: bhushann@gmail.com Subject: nsswitch equivalentA Message-ID: <1122462352.314734.3800@g43g2000cwa.googlegroups.com>    Hi All,   5    I would like to know what is the equivalent of the - nsswitch.conf(unix) in UCX stack for OpenVMS.    Rgds,  Bhushan    ------------------------------    Date: 27 Jul 2005 11:57:04 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)   Subject: Re: nsswitch equivalent3 Message-ID: <qFSQtaqq9$KY@eisner.encompasserve.org>   \ In article <1122462352.314734.3800@g43g2000cwa.googlegroups.com>, bhushann@gmail.com writes:  7 >    I would like to know what is the equivalent of the / > nsswitch.conf(unix) in UCX stack for OpenVMS.   = For best results you should describe what you are looking for - rather than just giving the Unix name for it.    ------------------------------    Date: 27 Jul 2005 12:10:37 -0500 From: briggs@encompasserve.org  Subject: Re: nsswitch equivalent3 Message-ID: <1UK6n4ZJOGJM@eisner.encompasserve.org>   c In article <qFSQtaqq9$KY@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: ^ > In article <1122462352.314734.3800@g43g2000cwa.googlegroups.com>, bhushann@gmail.com writes: > 8 >>    I would like to know what is the equivalent of the0 >> nsswitch.conf(unix) in UCX stack for OpenVMS. > ? > For best results you should describe what you are looking for / > rather than just giving the Unix name for it.   J nssswitch.conf controls the way in which name service queries are handled.  A For instance, it would control the way in which IP host names are  converted to IP addresses.  	 The line:    	hosts:      files dns  B Would indicate that host names are to be resolved by first looking9 in the local "hosts" file and then by looking in the DNS.   C Additional naming services such as NIS (yellow pages) could also be  included on the list.   C In the Unix environment, nsswitch.conf also controls such things as @ where to look for the user authorization file or the Unix groupsA database.  Since the OP was asking about UCX, one assumes that he B is primarily interested in ways to control the search order for IP host name lookups.  F The default order is, as I recall, UCX locally defined host names thenC DNS.  I don't know how to change that or whether it can be changed.    	John Briggs   ------------------------------    Date: 27 Jul 2005 08:39:24 -0700+ From: "Jeff Anicker" <anickerj@comcast.net> 2 Subject: Re: Performance issue after 7.3-2 upgradeB Message-ID: <1122478764.835614.68960@f14g2000cwb.googlegroups.com>  E The results of the trace from today's incident show just for cpu 0 by  module:   D 3731 Process_Management (3641 of which were schedule$calc_cpu_load_c	 routines)  2145 Sys$xfcacheB 1170 Sys$cpu_routines (1086 of which were exe$timedwait_complete_c	 routines) @ 287   System_synchronization_min (259 of which were some form of smp$acquire) 228   IO_Routines  189   Sys$pcadriver  121   System_primitives_min   E Everything else was under 100.  There is nothing fast pathed to cpu0. G HP had me set sch_ctl_flags to 3 so that no processes will be scheduled < on cpu 0.  I did not see any difference after that change.     Jeff   ------------------------------    Date: 27 Jul 2005 08:04:19 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 9 Subject: Re: Printing while defaulted to remote directory 3 Message-ID: <1EjAZgUOPeA6@eisner.encompasserve.org>   i In article <1122392995.558027.261060@z14g2000cwz.googlegroups.com>, "Bobby" <colemanr7@yahoo.com> writes: 	 > Hi all,  > H > I have a print device and queue configured on machine A (both point to9 > a TCP printer).  I then do a "set default machineB"user I > pass"::drive:[dir]" to machine B.  If I then proceed to print a file in E > this remote directory by any means, i.e. print xxx.txt or otherwise @ > direct it to the device (LRA0:) or queue (sys$print) I get the > following error: > D > "%PRINT-E-REMOINSF,node name specification or /REMOTE missing from > command line"   C    The print queue tracks the file to print by volume name and FID, E    which doesn't give it any space to store a remote node name.  When E    it trips over a the resulting error it figures out a usefull error     message (you could ;       print/remote machineB"user pass"::drive:[dir]xxx.txt  +    if there was an appropriate queue on B).   G    The only work around if B can't have such a queue is to make a local #    copy on A and then print/delete.   @    There are lots of commands that are not documented as workingC    explicitly over DECnet, or as working when you set default to a  H    remote directory and use DECnet implicitly.  Sometimes those commandsG    can work anyhow, sometimes they can't.  PRINT/REMOTE is a workaround     for one that can't.            ------------------------------    Date: 27 Jul 2005 08:14:46 -0500 From: briggs@encompasserve.org9 Subject: Re: Printing while defaulted to remote directory 3 Message-ID: <dgSOpKoQALsW@eisner.encompasserve.org>   q In article <1EjAZgUOPeA6@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: k > In article <1122392995.558027.261060@z14g2000cwz.googlegroups.com>, "Bobby" <colemanr7@yahoo.com> writes: 
 >> Hi all, >>  I >> I have a print device and queue configured on machine A (both point to : >> a TCP printer).  I then do a "set default machineB"userJ >> pass"::drive:[dir]" to machine B.  If I then proceed to print a file inF >> this remote directory by any means, i.e. print xxx.txt or otherwiseA >> direct it to the device (LRA0:) or queue (sys$print) I get the  >> following error:  >>  E >> "%PRINT-E-REMOINSF,node name specification or /REMOTE missing from  >> command line" > E >    The print queue tracks the file to print by volume name and FID, G >    which doesn't give it any space to store a remote node name.  When G >    it trips over a the resulting error it figures out a usefull error  >    message (you could = >       print/remote machineB"user pass"::drive:[dir]xxx.txt  - >    if there was an appropriate queue on B).   B "Appropriate queue" is pretty restrictive.  $ PRINT /REMOTE always% prints to the remote SYS$PRINT queue.   8 The way $ PRINT /REMOTE is implemented is rather simple.  4 	1. The PRINT command opens the remote file by name.? 	2. The PRINT command closes the remote file with DISPOSE=PRINT   ? If you are able to manipulate the SYS$PRINT logical name in the ? context of the FAL server process on the remote node you can do = some useful magic.  But if not, you are stuck with SYS$PRINT.    	John Briggs   ------------------------------    Date: 27 Jul 2005 12:29:46 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) 9 Subject: Re: Printing while defaulted to remote directory 3 Message-ID: <nE4NHw79V6iT@eisner.encompasserve.org>   T In article <dgSOpKoQALsW@eisner.encompasserve.org>, briggs@encompasserve.org writes: > A > If you are able to manipulate the SYS$PRINT logical name in the A > context of the FAL server process on the remote node you can do ? > some useful magic.  But if not, you are stuck with SYS$PRINT.   C    IIRC FAL runs login.com (or whatever your UAF record points to).    ------------------------------  % Date: Wed, 27 Jul 2005 05:15:37 -0400 ( From: Bill Todd <billtodd@metrocast.net>Y Subject: Re: Two New Itanium 2s Feature Faster Front-Side Bus - Is this new Montecito inf = Message-ID: <RdadnZL3VawnzXrfRVn-hQ@metrocastcablevision.com>    icerq4a@spray.se wrote:  > Bill Todd wrote:   ...   F >>Intel is also being outright mendacious in other performance claims.& >>For example, this Inquirer article (E >>http://www.theinquirer.net/?article=24459 ) uncritically parrots an F >>Intel press release touting Montecito as offering 60% higher LINPACKI >>performance than POWER5, without noting the fact that they're comparing I >>the performance of a quad-chip, 8-core Montecito system against that of I >>a dual-chip, quad-core POWER5 system (IBM does sell a quad-chip, 8-core H >>POWER5 system, of course, and it handily beats the LINPACK performance0 >>reported for the comparable Montecito system). >># >>Just to keep the record straight.  >> >>- bill >  > 9 > That Intel press release was indeed a really sorry one.  > @ > But you are also wrong, Montecito does beat Power5 in LINPACK.  E I am not wrong, because I never claimed that Montecito couldn't beat  I POWER5 in *some other* LINPACK test (though I certainly haven't seen any  > in which it does:  perhaps you'd care to provide a citation?).  
   There isI > this confusion about which LINPACK benchmark Intel and IBM use and most * > people don't understand the differences.  F Unless the Intel people themselves don't understand the difference, I H don't see your point:  it was *Intel* which claimed they were comparing F apples to apples ('comparable' systems) in their press release, which C very specifically referred to the IBM HPC LINPACK result (and thus  I presumably was using an Intel HPC LINPACK result to compare against it).  E   The only thing they got wrong was the minor matter of comparing an  7 8-core Montecito system against a 4-core POWER5 system.   E IIRC there was some discussion at Ace's about this a while ago where  F Paul DeMone opined that Intel was boasting a TPP (not an HPC) LINPACK H result of 45 GFLOPs, in which case it would indeed have beaten the 34.6 G GFLOP 8-core POWER5 TPP score.  But the press release, by specifically  I comparing against the POWER5 HPC score, seems to be stating clearly that  F they Intel score they're talking about is also HPC - and when Charlie I Demerjian (of The Inquirer) asked them specifically about this they gave  I no indication that they were talking TPP scores for Montecito but merely  H huffed and puffed about Intel's decision to count chips as 'processors' D while IBM counts cores, thus suggesting that comparing a dual-chip, C 4-core IBM '4-processor' (in IBM's terminology) configuration to a  ? quad-chip, 8-core Intel '4-processor' (in Intel's terminology)  I configuration and stating that the latter beat the former by 60% without  E noting the rather significant configuration difference was just fine.    - bill   ------------------------------    Date: 27 Jul 2005 07:01:57 -0500B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)F Subject: Re: [OT] Rounding v Truncation, was: Re: Platform Support vs.3 Message-ID: <V4rQSZ1gJSiV@eisner.encompasserve.org>   t In article <DTiotGxQ0bj6-pn2-drQtoWMC6L8i@dave2_os2.home.ours>, "Dave Weatherall" <djw-nothere@nospam.nohow> writes: > G > Is the difference here not down to explicit (casted) versus implicit  
 > conversion?  >   J I can't speak for PL/I, but in the case of Ada/C, I don't think so, as GCCI is following the language specifications. I've already quoted the Ada one @ and now I've dug up the C99 language specification, available at  5 	http://www.open-std.org/JTC1/SC22/WG14/www/standards   + and it says (section 6.3.1.4, paragraph 1):   E 	When a finite value of real floating type is converted to an integer C 	type other than _Bool, the fractional part is discarded (i.e., the C 	value is truncated toward zero). If the value of the integral part F 	cannot be represented by the integer type, the behavior is undefined.  H BTW, the original comment by Dave Froble was that he could not find a VBI language specification. Neither could I with a brief look, but I did find K the VB.Net specification/manuals which he might find interesting. Location:   f 	http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vboriVBLangRefTopNode.asp  6 I found the following discussion on the CInt function:  = 	-2,147,483,648 through 2,147,483,647; fractions are rounded.    ...   D 	When the fractional part is exactly 0.5, CInt and CLng always roundD 	it to the nearest even number. For example, 0.5 rounds to 0 and 1.5B 	rounds to 2. CInt and CLng differ from the Fix and Int functions,D 	which truncate, rather than round, the fractional part of a number.F 	Also, Fix and Int always return a value of the same type as is passed 	in.  F A quick look didn't reveal anything about type conversions done during assignment.    Simon.   --  B Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       7 Microsoft: The Standard Oil Company of the 21st century    ------------------------------  % Date: Wed, 27 Jul 2005 06:18:19 -0700 # From: "Tom Linden" <tom@kednos.com> F Subject: Re: [OT] Rounding v Truncation, was: Re: Platform Support vs.( Message-ID: <opsukpwtolzgicya@hyrrokkin>  I On 27 Jul 2005 05:19:19 GMT, Dave Weatherall <djw-nothere@nospam.nohow>    wrote:  H > On Mon, 25 Jul 2005 13:26:27 UTC, "Tom Linden" <tom@kednos.com> wrote: > / >> On 25 Jul 2005 07:52:36 -0500, Simon Clubley  >  > <Snip> > ' >> >         Target := Integer(Source); B >> >         Put_Line("Source = " & Source'Img & ", Target = " &   >> Target'Img);  >  > <Snip> >  >> > int main()  >> >         { >> >         int target; >> >         float source; >> > >> >         source = 3.4; >> >         target = source;  > D >  Every programming language has it's own set of rules for implicit >> conversion.@ >> some more consistent than others.  PL/I for example truncates >> FREJA> create rnd_trnc.pli  >> test: proc options(main); >> dcl f fixed dec(3,1); >> dcl i fixed bin(15);  >> do f = 3.4 to 3.6 by .1; 
 >>     i = f;  >>     put skip list(i); >>     end;  >> end test;	 >> *EXIT*  >> FREJA> pli rnd_trnc	 >> FREJA>  >> FREJA> link rnd_trnc  >> FREJA> run rnd_trnc >>
 >>          3 
 >>          3 
 >>          3  >> >> > F > Is the difference here not down to explicit (casted) versus implicit
 > conversion?  > L Indeed, that is why I said IMPLICIT conversion.  Each language has its own   set of rulesG If you don't exploit EXPLICIT conversion then you had better know the    rules.   ------------------------------   End of INFO-VAX 2005.416 ************************