0 INFO-VAX	Fri, 10 Jan 2003	Volume 2003 : Issue 20      Contents:! Re: assembly/disassembly on vms ? ! Re: assembly/disassembly on vms ? ! Re: assembly/disassembly on vms ?  Re: Boot Contest change  RE: Boot Contest change  Re: Boot Contest change + Re: Cluster Alias used in Outgoing Messages + Re: Cluster Alias used in Outgoing Messages  DECnet Problem Re: DECnet Problem Re: DECnet Problem Re: Ethermon Re: Ethermon EVA and READL/WRITEL9 Re: Firmware Update and VMS upgrade chanded device names.  Freeware VDD64 Re: Freeware VDD64B Re: FW: OT (sadly) Opteron servers preparing to hit the real worldB RE: FW: OT (sadly) Opteron servers preparing to hit the real world7 Re: How can I read files from a directory(VMS) using C? 7 Re: How can I read files from a directory(VMS) using C? 7 Re: How can I read files from a directory(VMS) using C? 7 RE: How can I read files from a directory(VMS) using C?  Re: It's all K.O.'s fault ' Re: Looks like AMD has deep pockets now ' Re: Looks like AMD has deep pockets now ' Re: Looks like AMD has deep pockets now ' Re: Looks like AMD has deep pockets now ' Re: Looks like AMD has deep pockets now # Re: Memo:  RE:  Boot Contest change # RE: Memo:  RE:  Boot Contest change 
 OpenVMS Pearl > Re: OT (sadly) Opteron servers preparing to hit the real world; Re: Retrieve RMS Key information at runtime (using Fortran) ; Re: Retrieve RMS Key information at runtime (using Fortran) # TCPIP$HR_MIB uses a lot of the cpu. ' Re: TCPIP$HR_MIB uses a lot of the cpu. ' Re: TCPIP$HR_MIB uses a lot of the cpu.  The need for reliable desktops" Re: The need for reliable desktops" Re: The need for reliable desktops tn3270/key_definitions=file " Re: Traceback and installed images
 VAX Arch Hdbk  re: vdd64 and Perceptics Re: VMS troubles Re: VMS troubles0 Re: VMS731_ACRTL-V0100 Release notes [complaint] What does RWCLU mean? " Re: Why LOGINOUTs don't go away???  F ----------------------------------------------------------------------  % Date: Fri, 10 Jan 2003 08:41:35 -0500 ' From: Chris Olive <nospam@raytheon.com> * Subject: Re: assembly/disassembly on vms ?> Message-ID: <U4AT9.260$Z74.1131@dfw-service2.ext.raytheon.com>   VAXman- wrote:j > In article <bBlT9.257$Z74.1046@dfw-service2.ext.raytheon.com>, Chris Olive <nospam@raytheon.com> writes: >  >>Dan wrote: >>3 >>>On Thu, 9 Jan 2003 17:24:54 +0100, "Jesper Naur" $ >>><jesper.naur@post.tele.dk> wrote: >>>  >>> K >>>>If all the numbers displayed are zero, the program has been linked with = >>>>/NOTRACEBACK (this is not the case in the example above).  >>>  >>> " >>>yep, it's all zero. Lucky me... >>>  >>>  >>> - >>>>>Ok I get this when trying to run dism32-  >>>>* >>>>>-CLI-E-IMAGEFNF, image file not found/ >>>>>HVAX$DKA100:[SYS0.SYSCOMMON.][SYSLIB]FORRT  >>>> >>>> >>>>>whats wrong ? >>>>L >>>>Is this the complete error message? The name FORRT looks like a possibly >>>  >>> # >>>that is the whole error message.  >>>  >>>  >>> M >>>>unintended abbreviation of FORRTL, which would be the name of the FORTRAN H >>>>runtime library, except for the fact, that this is called DEC$FORRTLN >>>>nowadays (at least on the Alpha). Are you doing this on a VAX or an Alpha? >>>  >>> H >>>vax. dism32 wont run on my alpha, says its not an alpha binary image.% >>>maybe I only have the vax version.  >>B >>Right. DISM32 only runs on VAXes, not Alphas.  To try and truly K >>disassemble an Alpha image would leave you with RISC instructions, which  E >>it's at least fair to say you weren't seeing THAT under VMS 4.2 in  J >>1980-something (when you said you ran this mystery command on an 11/782  >>eons ago.) 8-) >>I >>The DISM32 disassembly was/is to a native VAX arch.  I doubt anyone is  G >>going to write a disassembler for Alphas (although I know one person  I >>crazy enough to try it and probably be able to succeed with it... he's  4 >>happened to have participated in this thread BTW.) > H > The Alpha instruction stream should be much easier to decode than VAX.H > Instructions all of the same fixed length and a reduced set of addres-I > sing modes would actually make things easier.  That being the case does H > not mean that after disassembly one will be able to discern the intentF > of the code with any ease.  I've actually had to walk thought actualH > machine code on the Alpha to implement certain "intercepts".  It's not > a difficult task.  >   B I'm sure all true (and now that you describe it, it makes perfect G sense.)  But very few, I'll bet, have even ventured far enough into it   to know all this.   G > For a moment there, I thought you might be hinting at myself but then I > you said crazy and I'm every bit of sane.  It's the rest of you who are  > crazy!  G Very interesting how you re-entered the thread right here though... ;-)    Chris  -----  Chris Olive  Systems Consultant' Raytheon Technical Services Corporation  Indianapolis, IN  * email: olivec AT indy DOT raytheon DOT com   ------------------------------  % Date: Fri, 10 Jan 2003 08:44:35 -0500 ' From: Chris Olive <nospam@raytheon.com> * Subject: Re: assembly/disassembly on vms ?> Message-ID: <I7AT9.261$Z74.1172@dfw-service2.ext.raytheon.com>  
 Dan wrote:G > On Thu, 09 Jan 2003 16:12:03 -0500, Chris Olive <nospam@raytheon.com>  > wrote: > B >>Right. DISM32 only runs on VAXes, not Alphas.  To try and truly K >>disassemble an Alpha image would leave you with RISC instructions, which  E >>it's at least fair to say you weren't seeing THAT under VMS 4.2 in  J >>1980-something (when you said you ran this mystery command on an 11/782  >>eons ago.) 8-) >   H > it definitely wasn't alpha stuff. and I have a printout of the commandD > I ran someplace. Well, ok, not the command, but the RESULTS of the
 > command. > E > I took an EXE file, ran what I remember (from 1982-4 or so VMS 4.2) G > what I think was dump/asm and got an assembly language listing out of @ > it, with full CALL LIB... etc it looked like native assembler. > G > I've been wracking my brain over this one. Unfortunately the printout G > does NOT have the command, just the output from it. I'll see if I can B > do something about scanning it or whatever as a jpeg or whatnot.  0 Please do.  Would be quite interested to see it.  
 >> [snip]   >> I >>Wish I could help more.  You're going to need a VAX (or a VAX emulator  H >>-- http://www.softresint.com/charon-vax/index.htm) to run DISM32.  If H >>you can get it to work (by obtaining access to the proper HW or HAL), 7 >>you'll likely enjoy the results...  Does a great job.  > G > I have 5-6 Vaxen thank you, and two Alpha's. But my main vax seems to  > be missing FORRTL... erg   That's always a bummer...    Chris  -----  Chris Olive  Systems Consultant' Raytheon Technical Services Corporation  Indianapolis, IN  * email: olivec AT indy DOT raytheon DOT com   ------------------------------  % Date: Fri, 10 Jan 2003 13:14:47 -0500  From: Dan <dan@vrx.net> * Subject: Re: assembly/disassembly on vms ?8 Message-ID: <p93u1v4347jta7cvdae5b4hc4fpdgj0l8j@4ax.com>  C On Fri, 10 Jan 2003 02:18:41 GMT, VAXman-  @SendSpamHere.ORG wrote: G >The Alpha instruction stream should be much easier to decode than VAX. G >Instructions all of the same fixed length and a reduced set of addres- H >sing modes would actually make things easier.  That being the case doesG >not mean that after disassembly one will be able to discern the intent E >of the code with any ease.  I've actually had to walk thought actual G >machine code on the Alpha to implement certain "intercepts".  It's not  >a difficult task.  ? well... I do have the same (er) EXE compiled on the alpha (with 5 /notraceback), so if it's easier, I'm all for that...   F >For a moment there, I thought you might be hinting at myself but thenH >you said crazy and I'm every bit of sane.  It's the rest of you who are >crazy!   E get to work ;) Could be very useful. esp since this seems so annoying 2 at the moment. I could use disassembly of this EXE  C now if only I could find someone with an old magtape drive (the big  reel type)... sigh.    Dan.   ------------------------------  % Date: Fri, 10 Jan 2003 08:01:28 -0700 6 From: "Michael D. Ober" <obermd.@.alum.mit.edu.nospam>  Subject: Re: Boot Contest change2 Message-ID: <dfBT9.2325$j%1.19481@news.uswest.net>  K Very true.  I was simply responding to the question of how could you infect & the contents of the console boot file.  
 Mike Ober.  H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>A wrote in message news:00A19B99.DC82D030@SSRL.SLAC.STANFORD.EDU... D > In article <afnT9.86$hU1.74293@news.uswest.net>, "Michael D. Ober"& <obermd.@.alum.mit.edu.nospam> writes:9 > >Via a bogus console update CD.  It's been done before.  > L > But if you've got the ability to put a bogus console update CD in, you canE > corrupt the firmware even on an Alpha -- there's not a lot of extra 8 > vulnerability from having a FAT partition on the disk. > 	 > -- Alan  >  > L ============================================================================ === 2 >  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUA >  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056G >  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA  94025  > L ============================================================================ ===  >    ------------------------------  % Date: Fri, 10 Jan 2003 10:34:45 -0500 1 From: "Farrell, Michael" <MFarrell@voltdelta.com>   Subject: RE: Boot Contest changeP Message-ID: <025766C9BBC5D511A4ED00B0D0F08C23163908@zny_exchange1.maintech1.com>   Sue,  J I just thought I'd throw this one into the hopper.  At a recent HP one day6 briefing held in one of the New York hotels last fall,J The attendees were told from the podium, that VMS would definitely boot onI IA64 on Dec 20th 2002.  Therefore the contest would bechanged to say what % hour of that day it would take place.   E Needless to say, I never saw anything corroborating that information.    Just thought I'd let you know.   Mike Farrell    -----Original Message----- H From: 	susan_skonetski@hotmail.com [mailto:susan_skonetski@hotmail.com] * Sent:	Wednesday, January 08, 2003 10:04 PM To:	Info-VAX@Mvb.Saic.Com   Subject:	Re: Boot Contest change  B Michel - The site were all the VMS information is an Alpha system,) using VMS that is not where the issue is.   D JF -  have you been watching spy movies lately.  Of course we do not? have a planned boot date. You are giving us way to much credit.   )  The best way for me to describe this is.   ? The engineers are like gifted artists and they are creating and C working on the code everyday but as you know with any true art form D you can not dictate when something happens but when they are done we will have a true masterpiece.   B Plus do you honestly think we would hold back on shouting from theB roof tops that we have a boot contest winner?  I think you will be6 able to hear us in Canada just by opening the door ;.)   Have a great night.  sue         D "stm" <stm@pt.lu> wrote in message news:<3e1c92e4$1_1@news.vo.lu>... > Try to use a Vax or Alpha  >  > Rgds,  > Michel Strainchamps  >  > B > "Sue Skonetski" <susan.skonetski@hp.nospam.com> wrote in message& > news:avi0di$mvo$1@web1.cup.hp.com...I > > problem with the email portion of the web site.  Warren is working on  it! D > > "Sue Skonetski" <susan.skonetski@hp.nospam.com> wrote in message( > > news:avhlvh$fp2$1@web1.cup.hp.com... > > > Dear Newsgroup,  > > > L > > > If you would like a second chance on the boot contest please visit the >  webI > > > site.  You will notice that the contest will only allow January and  >  February  > > > dates (hint).  > > > J > > > Also if you are outside of the US do it any way.  Legal requirements >  make  >  us G > > > limit the participation.  But we will take care of the winners no  matter > > > where they are from. > > > G > > > http://h18003.www1.hp.com/hps/ipf-enterprise/openvms_contest.html  > > >  > > > Warm regards as always,  > > > 	 > > > sue  > > >  > > >  > > >  > >  > >    ------------------------------  # Date: Fri, 10 Jan 2003 14:23:41 GMT # From: "John Smith" <a@nonymous.com>   Subject: Re: Boot Contest changeG Message-ID: <NHAT9.23579$pDv.1224@news04.bloor.is.net.cable.rogers.com>   C "David J. Dachtera" <djesys.nospam@earthlink.spamfree.net> wrote in 8 message news:3E1E406F.5C805277@earthlink.spamfree.net... > John Smith wrote:  > > C > > "Robert Deininger" <rdeininger@mindspring.com> wrote in message  > > F news:rdeininger-0801032152420001@user-2ive3sb.dialup.mindspring.com...> > > > In article <3E1C7890.6DDB2626@vl.videotron.ca>, JF Mezei. > > > <jfmezei.spamnot@vl.videotron.ca> wrote: > > > B > > > >Makes me wonder, as a good conspiracy theorist, whether the > > official boot ofE > > > >VMS on IA64 will be timed in relation to the EV7 announcements  (or  > > lack > > > thereof).  > > > A > > > JF, who told you that you are a _good_ conspiracy theorist?  > > F > > It was whispered to him by a gnome from Zurich, who in partnershipD > > with Eisenhower's military-industrial cabal orchestrated the man onB > > the grassy knoll, all of whom were backed by a flotilla of big black & > > helicopters controlled by the U.N. > > F > > If you believe any of the foregoing, I have some nice swampland in@ > > Florida and a bridge in Brooklyn you might be interesting in buying.  > > D > > OTOH, since there is no marketing per se for Alpha or VMS, there isn't 2 > > likely to be any official announcement anyway. > @ > I thought "the man on the grassy knoll" *WAS* VMS marketing...     That's plausibly deniable.   ------------------------------    Date: 10 Jan 2003 05:50:26 -0800( From: rrb35146@yahoo.com (Robbie Benton)4 Subject: Re: Cluster Alias used in Outgoing Messages= Message-ID: <dba64bc2.0301100550.6abf967a@posting.google.com>   b lewis@PROBE.mitre.org (Keith A. Lewis) wrote in message news:<avkt9r$du4$2@newslocal.mitre.org>...   N > As a sanity check, do a "UCX SHOW INTERFACE/CLUSTER" and see if that node isM > really .11 with an alias of .10 or if it thinks .10 is its main address.  I H > have had some nodes flip to using the alias as the main address for no > apparant reason. >   B I captured some information from two of my machines, shown below. E These particular machines have two interfaces each.  The interface in @ question is the xxx.xxx.xx.71 and xxx.xxx.xx.72 interfaces.  TheD yyy.yyy.yy.71 and yyy.yyy.yy.72 are a separate network, and I do not/ attempt to use cluster aliases on this network.     ********************************    From Node xxx.xxx.xx.72    $ tcpip show interface/clusterF Interface IP_Addr        Network mask        Receive        Send   MTU  F  LO0      127.0.0.1      255.0.0.0            209038      209038  4096F  WE0      xxx.xxx.xx.72  255.255.255.0       3395908      379109  15004   Cluster xxx.xxx.xx.70  255.255.255.0  Impersonator  F  WE1      yyy.yyy.yy.72  255.255.255.0        751997       62757  1500   $ telnet xxx.xxx.xx.71  & *************************************'  # Then once signed onto xxx.xxx.xx.71    $ show logical sys$rem_id   4 "SYS$REM_ID" = "TELNET_xxxxxx46" (LNM$JOB_811BF5C0)   $ $ write sys$output f$string ( %x46 ) 70    ? This seems to happen consistently.  I am not sure if this was a A problem in UCX V4.x or not; I have been a V5.x for quite a while.    Robbie   ------------------------------  + Date: Fri, 10 Jan 2003 16:43:31 +0000 (UTC) , From: lewis@PROBE.mitre.org (Keith A. Lewis)4 Subject: Re: Cluster Alias used in Outgoing Messages. Message-ID: <avmt7j$fvg$1@newslocal.mitre.org>   rrb35146@yahoo.com (Robbie Benton) writes in article <dba64bc2.0301100550.6abf967a@posting.google.com> dated 10 Jan 2003 05:50:26 -0800:C >I captured some information from two of my machines, shown below.  F >These particular machines have two interfaces each.  The interface inA >question is the xxx.xxx.xx.71 and xxx.xxx.xx.72 interfaces.  The E >yyy.yyy.yy.71 and yyy.yyy.yy.72 are a separate network, and I do not 0 >attempt to use cluster aliases on this network. > ! >********************************  >  >From Node xxx.xxx.xx.72 >  >$ tcpip show interface/cluster G >Interface IP_Addr        Network mask        Receive        Send   MTU  > G > LO0      127.0.0.1      255.0.0.0            209038      209038  4096 G > WE0      xxx.xxx.xx.72  255.255.255.0       3395908      379109  1500 5 >  Cluster xxx.xxx.xx.70  255.255.255.0  Impersonator  > G > WE1      yyy.yyy.yy.72  255.255.255.0        751997       62757  1500   ? Pretty much the same as my configuration so far, assuming that   yyy.yyy.yy != xxx.xxx.xx.      >$ telnet xxx.xxx.xx.71  > ' >*************************************'  > $ >Then once signed onto xxx.xxx.xx.71 >  >$ show logical sys$rem_id > 5 >"SYS$REM_ID" = "TELNET_xxxxxx46" (LNM$JOB_811BF5C0)   > % >$ write sys$output f$string ( %x46 )  >70    I get the opposite result.  L I searched SYS$SYSTEM:*TELNET*.EXE and saw numerous mentions of the logicalsJ [TCPIP,UCX]$INET_HOST[ADDR].  Those logicals should (automatically) be setK to the individual name and IP, not the cluster alias.  Aside from that, I'm  at a loss to explain this.  + --Keith Lewis              klewis$mitre.org > The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Fri, 10 Jan 2003 12:14:51 +0100 , From: "Ferry Bolhar" <bol@adv.magwien.gv.at> Subject: DECnet Problem 8 Message-ID: <1042197128.675688@mozart.adv.magwien.gv.at>  
 Hi to all,  G I have a problem on a system when running DECnet-Plus (DECnet/OSI) over E TCP/IP. I have correctly configured PWIP in UCX$CONFIG and RFC1006 in L NET$CONFIGURE (like I did many times on other systems where it works without@ problems). So all seems to be ok, but when starting, the processJ UCX$PWIP_ACP (which is responsible for those connections) does not bind toK IP ports 102 and 399 (which are used for DECnet over IP). There is no error F message in UCX$PWIPACP_MVIE63.LOG  (MVIE63 is the nodename) nor duringJ startup. The process remains in HIB state and does nothing. When trying to! connect from a remote system with    $ SET HOST DOMAIN:.MVIE63   E I get  %SYSTEM-F-UNREACHABLE, remote node is not currently reachable.   J The IP stack itself is setup correctly because I can connect to the system% via TELNET. Native DECnet also works.   J What's wrong here? As mentioned above, I have done this many times alreadyH and it worked always without any problems. Just on this single system it	 does not.    Can someone help me?   Hardware: MicroVAX 4000-105A= Software: OpenVMS V6.2, DECnet/OSI V6.3-ECO11, UCX V4.1 ECO 6   $ MTIA and kind greetings from Vienna,   Ferry    -- Ing. Ferry Bolhar % Municipality of Vienna, Department 14  A-1010 Vienna / AUSTRIA  E-mail: bol@adv.magwien.gv.at    ------------------------------  % Date: Fri, 10 Jan 2003 13:09:17 +0100 0 From: "labadie" <en_trajectant_a_mort@127.0.0.1> Subject: Re: DECnet Problem - Message-ID: <zKyT9.16$342.3@news.cpqcorp.net>   7 "Ferry Bolhar" <bol@adv.magwien.gv.at> wrote in message 2 news:1042197128.675688@mozart.adv.magwien.gv.at... > Hi to all, > I > I have a problem on a system when running DECnet-Plus (DECnet/OSI) over G > TCP/IP. I have correctly configured PWIP in UCX$CONFIG and RFC1006 in F > NET$CONFIGURE (like I did many times on other systems where it works without B > problems). So all seems to be ok, but when starting, the processL > UCX$PWIP_ACP (which is responsible for those connections) does not bind toG > IP ports 102 and 399 (which are used for DECnet over IP). There is no  error H > message in UCX$PWIPACP_MVIE63.LOG  (MVIE63 is the nodename) nor duringL > startup. The process remains in HIB state and does nothing. When trying to# > connect from a remote system with  >  > $ SET HOST DOMAIN:.MVIE63  > G > I get  %SYSTEM-F-UNREACHABLE, remote node is not currently reachable.    Hello   3 $ Mc ncl SHOW OSI TRANSPORT TEMPLATE OSIT$RFC* NAME   	 does show    Identifiers   9          Name                              = osit$rfc1006   3      Node 0 OSI Transport Template osit$rfc1006plus +      at 1997-02-20-10:54:23.502-07:00I0.909         Identifiers  =          Name                              = osit$rfc1006plus  or not ?     Does $ ucx sh dev show the ports 102 and 399    If MVIE63 has an IP @ of 1.2.3.4	 What does  $ telnet 1.2.3.4 102 $ telnet 1.2.3.4 399   show ?  )      %TELNET-I-TRYING, Trying ... 1.2.3.4 9      %TELNET-E-CONNFAIL, Failed to connect to remote host 9      -SYSTEM-F-REJECT, connect to network object rejected  or  )      %TELNET-I-TRYING, Trying ... 1.2.3.4 :      %TELNET-I-SESSION, Session 01, host 1.2.3.4, port 102      TELNET> EXIT    (Ctrl 5 or CTRL/]  to abort)  
 What gives $ set host ip$1.2.3.4   B Check if your node is configured to  allow DECnet/OSI to perform a/ BIND operation, with the following NCL command: , NCL> SHOW SESSION CONTROL NAMING SEARCH PATH   Regards    Grard   ------------------------------  % Date: Fri, 10 Jan 2003 15:05:52 +0100 , From: "Ferry Bolhar" <bol@adv.magwien.gv.at> Subject: Re: DECnet Problem 8 Message-ID: <1042207392.432833@mozart.adv.magwien.gv.at>  	 Hi folks,   ( here are the answers to Grards posting:  5 > $ Mc ncl SHOW OSI TRANSPORT TEMPLATE OSIT$RFC* NAME  > does show   
 > Identifiers  > Name = osit$rfc1006   0 > Node 0 OSI Transport Template osit$rfc1006plus( > at 1997-02-20-10:54:23.502-07:00I0.909 > 
 > Identifiers  >  > Name = osit$rfc1006plus 
 > or not ?   Yes, shows the above.    > Does > $ ucx sh dev > show the ports 102 and 399  H No, doesn't (at least not as local ports). I should mention that I _can_H connect to a remote node over RFC1006 _from_ MVIE63. But I can't connect _to_ MVIE63 this way.   " > If MVIE63 has an IP @ of 1.2.3.4 > What does  > $ telnet 1.2.3.4 102 > $ telnet 1.2.3.4 399 >  > show ? > & > %TELNET-I-TRYING, Trying ... 1.2.3.46 > %TELNET-E-CONNFAIL, Failed to connect to remote host6 > -SYSTEM-F-REJECT, connect to network object rejected > or > & > %TELNET-I-TRYING, Trying ... 1.2.3.47 > %TELNET-I-SESSION, Session 01, host 1.2.3.4, port 102  > TELNET> EXIT  # Connect to network object rejected.    > What gives > $ set host ip$1.2.3.4   = %SYSTEM-F-UNREACHABLE, remote node is not currently reachable   C > Check if your node is configured to allow DECnet/OSI to perform a 1 > BIND operation, with the following NCL command: . > NCL> SHOW SESSION CONTROL NAMING SEARCH PATH  - Yes, it is. Contains this naming search path:    Naming Search Path = {  [  Directory Service = Local ,  Template = "*" ] ,  [  Directory Service = Local ,  Template = "local:*" ] ,  [  Directory Service = Domain , Template = "*" ] ,  [  Directory Service = Domain ,  Template = "*.adv.magwien.gv.at" ] ,  [  Directory Service = Domain ,! Template = "*.host.magwien.gv.at"  ]  }   # and this backtranslation sear path:    Backtranslation Search Path =  {  [  Directory Service = Local , 
 Template = ""  ] ,  [  Directory Service = Domain ,
 Template = ""  ]  }   J As mentioned in my first posting, i have a _similar_ configuration on many- other systems where it runs without problems.   
 Any ideas?   MTIA and kind greetings,   Ferry  ---  Ing. Ferry Bolhar-Nordenkampf % Municipality of Vienna, Department 14  A-1010 Vienna / AUSTRIA  E-mail: bol@adv.magwien.gv.at : "Wenn hier einer schuld ist, dann immer nur der Computer."   ------------------------------  % Date: Fri, 10 Jan 2003 09:01:23 +0100 6 From: Horst Drechsel <ai05@sternwarte.uni-erlangen.de> Subject: Re: Ethermon < Message-ID: <00A19C0F.5000353C.4@sternwarte.uni-erlangen.de>  	 Dear all,   B    when building the PROBE images on a VMS 7.2-1 (XP1000) machine,+ execution of $probe fails with the message:   ,      %CLI-F-SYNTAX, error parsing 'PRB_ADAP'?      -CLI-E-ENTNF, specified entity not found in command tables   H    Same happens with the original probe.exe provided in Hunter Goatley's package. Any workaround?  
    Thanks,             Horst    >------------------------------ & >Date: Fri, 10 Jan 2003 01:56:17 +0100C >From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid>  >Subject: Re: Ethermon >  >Lee Y T Mah wrote:  >>  J >> I used to run Ethermon many years ago in a VAXcluster.  That ended whenE >> we migrated to Alpha's.  A recent posting said Ethermon was on the C >> Freeware CD.  I loaded the VMS 7.3-1 Freeware CD and can't find   >> anything on Ethermon.# >> Did I misunderstand the posting? = >> Is Ethermon no longer available on the recent Freeware CD? 6 >> Is Ethermon that useful in today's VMS environment? > ) >Get Probe from Hunter Goatleys archive : < > http://vms.process.com/scripts/fileserv/fileserv.com?PROBE >------------------------------    --M  **************************************************************************** )   Horst Drechsel                          L   Dr. Remeis Observatory                 drechsel@sternwarte.uni-erlangen.deL   Astronomical Institute                             Phone: +49-951-95222-15L   University Erlangen-Nuernberg                        Fax: +49-951-95222-22*   Sternwartstr.7, D-96049 Bamberg, GermanyM  ****************************************************************************    ------------------------------    Date: 10 Jan 2003 08:28:02 -0600; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Ethermon 3 Message-ID: <ltYUTNzAU$3d@eisner.encompasserve.org>   b In article <3E1E2C6B.95842A2C@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > Lee Y T Mah wrote: >>  J >> I used to run Ethermon many years ago in a VAXcluster.  That ended when >> we migrated to Alpha's.   > O > I have a version of Ethermon which came with the source. It is written mostly O > in fortran with some bits in vax macro. The macro seems to be command parsing  > (no fancy driver stuff). > M > Is it still usefull ? You bet it is. When I had problems with my ISP (their M > DHCP server would not respond to my DHCP requests) ETHERMON helped me prove 5 > the problem was not on my side but on the ISP side.     .    Multinet has a similar capability built in.   ------------------------------    Date: 10 Jan 2003 09:19:41 -0600+ From: young_r@encompasserve.org (Rob Young)  Subject: EVA and READL/WRITEL 3 Message-ID: <BXbgXq5csEI8@eisner.encompasserve.org>   4 	Does Enterprise Virtual Array support READL/WRITEL?  
 			Thanks,   				Rob    ------------------------------  % Date: Fri, 10 Jan 2003 18:17:39 +0200 - From: Tim Oakley <toakley@maury-imprimeur.fr> B Subject: Re: Firmware Update and VMS upgrade chanded device names.1 Message-ID: <3E1EF223.2030302@maury-imprimeur.fr>   C I think this might be related to the fact that prior to your fresh  D install your system had a SYSGEN parameter 'DEVICE_NAMING' set to 1 H which means all locally connected disks are seen as 'DKAx' and the file F SYS$SYSTEM:SYSDEVICES.DAT is used to change the device allocation for C each PKx device to enable the drives to be identified uniquely ex.   $1$DKA or $15$DKA etc.   Try...? 1. setting the SYSGEN param. 'DEVICE_NAMING' to 1 (use current) C 2. see if there was the file SYS$SYSTEM:SYSDEVICES.DAT on your old  * sysdisk, if so copy it to the new sysdisk.	 3. reboot   J if i'm not completely wrong, your disks will once again be seen as 'DKAx'.  G if this works don't forget to update the SYS$SYSTEM:MODPARAMS.DAT file  - to reflect the new value for 'DEVICE_NAMING'.    hope it works.   Vinit wrote: > Hi Everyone, > E > I had an existing AXP4100, with all disks named DKAn: connected to  G > SCSI controller SCSI PKD0: (disk served by HSZ70.) Now after firmware G > update  on AS4100 console, and an fresh install of VMS (new disk) all $ > disk devices have changed to DKDn: >  > Could you help!  > 	 > Regards  > Vinit Adya   ------------------------------  % Date: Fri, 10 Jan 2003 16:54:58 +0200 - From: Tim Oakley <toakley@maury-imprimeur.fr>  Subject: Freeware VDD64 1 Message-ID: <3E1EDEC2.8000109@maury-imprimeur.fr>    Hello,  F Have just updated to v7.3 and our optical disks which used to use the I PERCPETICS supplied 'WDD' drivers (OSMS i think) no longer work (in fact  1 the system crashes when we load the WDD drivers).    HP France told me that...  eitherI purchase new drivers from a company named USDESIGN who tookover the OSMS  I software from Compaq (this seems fair, but USDESIGN tell me that the new  D drivers will allow me to read data from my optical drives but *not* 4 write to them (sounds like a Microsoft enhancement)) orI try using the freeware VDD64 package which should allow me to access the  ! optical disks as i did with OSMS.   I Having downloaded the VDD package and read the help/user doc i don't see   how VDD is going to help me.  H Has anyone used the freeware 'VDD64' (virtual device drivers) for their E optical drives or has anyone got a different solution to my problem ?    best regards to all    ------------------------------  % Date: Fri, 10 Jan 2003 16:23:35 +0100 2 From: "Ren Schelbaum" <rene.schelbaum@datakom.at> Subject: Re: Freeware VDD64 G Message-ID: <3e1ee55b$0$27008$91cee783@newsreader02.highway.telekom.at>   @ "Tim Oakley" <toakley@maury-imprimeur.fr> schrieb im Newsbeitrag+ news:3E1EDEC2.8000109@maury-imprimeur.fr...  > Hello, > G > Have just updated to v7.3 and our optical disks which used to use the J > PERCPETICS supplied 'WDD' drivers (OSMS i think) no longer work (in fact3 > the system crashes when we load the WDD drivers).  >  > HP France told me that...  > eitherJ > purchase new drivers from a company named USDESIGN who tookover the OSMSJ > software from Compaq (this seems fair, but USDESIGN tell me that the newE > drivers will allow me to read data from my optical drives but *not* 6 > write to them (sounds like a Microsoft enhancement)) > orJ > try using the freeware VDD64 package which should allow me to access the# > optical disks as i did with OSMS.  > J > Having downloaded the VDD package and read the help/user doc i don't see > how VDD is going to help me. > I > Has anyone used the freeware 'VDD64' (virtual device drivers) for their G > optical drives or has anyone got a different solution to my problem ?  >  > best regards to all  >    Hello!  F Welcome to the club! I have the same problem here. I had to go back toK V7.2-2 (going to prior version support soon). hp didn't inform me about the F freeware solution. If you get any further information, can you keep me	 informed?    Thanks in advance!   Ren   ------------------------------  % Date: Fri, 10 Jan 2003 20:05:14 +0200 % From: "Mariuz" <mariuz@stop.spam.org> K Subject: Re: FW: OT (sadly) Opteron servers preparing to hit the real world : Message-ID: <pan.2003.01.10.18.05.13.683113@stop.spam.org>   why sadly :) ?? 9 whe have then cheap (t)itanics 2 for desktop and servers  $ that's good ...for vms (open or not) > Shane    ------------------------------  % Date: Fri, 10 Jan 2003 10:18:45 -0800 $ From: Shane Smith <ssmith@icius.com>K Subject: RE: FW: OT (sadly) Opteron servers preparing to hit the real world 0 Message-ID: <01C2B891.C424CCF0@sulfer.icius.com>  D I'm sad that it's off topic, not that the Opterons are coming. (Hey,H that sounds like the title of a bad science fiction movie!) I'm sure you? can all singa longa Shane by now: I want VMS on Hammer/Opteron.    Shane    -----Original Message-----* From: Mariuz [mailto:mariuz@stop.spam.org]' Sent: Friday, January 10, 2003 10:05 AM  To: Info-VAX@Mvb.Saic.Com E Subject: Re: FW: OT (sadly) Opteron servers preparing to hit the real  world      why sadly :) ?? 9 whe have then cheap (t)itanics 2 for desktop and servers  $ that's good ...for vms (open or not) > Shane    ------------------------------  % Date: Fri, 10 Jan 2003 02:02:41 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>@ Subject: Re: How can I read files from a directory(VMS) using C?/ Message-ID: <3E1E61F1.E4EC6FE5@vl.videotron.ca>    "E. Gibbons" wrote: 8 > But if you don't care about C, then why post to clc?    A and if you don't care about VMS specific calls, why post to cov ?   $ A little tolerance goes a long way.   N I feel that the original question was reasonable for both newsgroups: is thereD a standard way to get a directory fo files from a C program on VMS ?   ------------------------------  # Date: Fri, 10 Jan 2003 08:34:19 GMT . From: rlb@hoekstra-uitgeverij.nl (Richard Bos)@ Subject: Re: How can I read files from a directory(VMS) using C?, Message-ID: <3e1e855c.587955173@news.nl.net>  1 JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote:    > "E. Gibbons" wrote: : > > But if you don't care about C, then why post to clc?   > C > and if you don't care about VMS specific calls, why post to cov ?    We didn't start the cross-post.C  P > I feel that the original question was reasonable for both newsgroups: is thereF > a standard way to get a directory fo files from a C program on VMS ?  G The question was (and the answer is "no", at least in comp.lang.c); the/% answer "check out readdir()" was not.r   Richard    ------------------------------  % Date: Fri, 10 Jan 2003 08:50:10 -0500r( From: David Froble <davef@tsoft-inc.com>@ Subject: Re: How can I read files from a directory(VMS) using C?, Message-ID: <3E1ECF92.2050100@tsoft-inc.com>   JF Mezei wrote:    > "E. Gibbons" wrote:  > 8 >>But if you don't care about C, then why post to clc?   >> > C > and if you don't care about VMS specific calls, why post to cov ?C > & > A little tolerance goes a long way.  > P > I feel that the original question was reasonable for both newsgroups: is thereF > a standard way to get a directory fo files from a C program on VMS ? >   ) Bigots are like trolls.  Don't feed them.    ------------------------------  % Date: Fri, 10 Jan 2003 10:12:21 -0800e$ From: Shane Smith <ssmith@icius.com>@ Subject: RE: How can I read files from a directory(VMS) using C?0 Message-ID: <01C2B890.D5CCB7C0@sulfer.icius.com>  E Look on the bright side, at least Andrew Harrison hasn't chimed in onu/ this one. What /would/ clc think of cov then...    ShaneM   -----Original Message-----/ From: David Froble [mailto:davef@tsoft-inc.com]l& Sent: Friday, January 10, 2003 5:50 AM To: Info-VAX@Mvb.Saic.Comn@ Subject: Re: How can I read files from a directory(VMS) using C?     JF Mezei wrote:i   > "E. Gibbons" wrote:  > 8 >>But if you don't care about C, then why post to clc?   >> > C > and if you don't care about VMS specific calls, why post to cov ?- > & > A little tolerance goes a long way.  > J > I feel that the original question was reasonable for both newsgroups: is thereeF > a standard way to get a directory fo files from a C program on VMS ? >   ) Bigots are like trolls.  Don't feed them.A   ------------------------------  % Date: Fri, 10 Jan 2003 10:14:49 -0500m: From: Charlie McCutcheon <charlie.mccutcheonUNSPAM@hp.com>" Subject: Re: It's all K.O.'s fault& Message-ID: <3E1EE369.CA04C3B7@hp.com>   Bob Koehler wrote:  ' >    Found in Sunday's Washington Post.y >aI >    It seems the first known example of SPAM was an unsolicited email inhF >    the laste 70's from Digital Equipment Corporation to all users of. >    ARPANET announcing a new computer system. >rE >    I'll never be able to look at my beloved VAXen in the same light  >    again.1  4 The pointer I saw pointed down to TOPS-20 marketing.  5 I doubt K.O. himself had anything to do with it.  8-)    CharlieR   ------------------------------    Date: 10 Jan 2003 05:27:24 -0800( From: bob@instantwhip.com (Bob Ceculski)0 Subject: Re: Looks like AMD has deep pockets now= Message-ID: <d7791aa1.0301100527.77c6454d@posting.google.com>   e bill@cs.uofs.edu (Bill Gunshannon) wrote in message news:<avkndv$gp02b$1@ID-135708.news.dfncis.de>... , > In article <avkj4s$kco$6@web1.cup.hp.com>,+ > 	Rick Jones <foo@bar.baz.invalid> writes:I > > J > > From the press releases, it appears that the two are not the same. IBM? > > and AMD appear to be collaborating on manufacturing processw& > > technology, not chips themselves.  > D > Makes sense to me.  They both have chips already that stand a realB > good chance of kicking IA64's butt.  Why waste time and money onD > yet another contender when that time and money can be spent making2 > the existing chips kick IA64's butt even harder. >  > bill  C with intel having alpha and the alpha engineers, no one is going tol kick their $#!& ...w   ------------------------------  % Date: Fri, 10 Jan 2003 14:43:56 +0000 ' From: Andrew Harrison SUNUK Consultancym0 Subject: Re: Looks like AMD has deep pockets now. Message-ID: <3E1EDC2C.3060205@nospamn.sun.com>   Bob Ceculski wrote:ug > bill@cs.uofs.edu (Bill Gunshannon) wrote in message news:<avkndv$gp02b$1@ID-135708.news.dfncis.de>...  > , >>In article <avkj4s$kco$6@web1.cup.hp.com>,+ >>	Rick Jones <foo@bar.baz.invalid> writes:u >>I >>>From the press releases, it appears that the two are not the same. IBM > >>>and AMD appear to be collaborating on manufacturing process% >>>technology, not chips themselves. B >>D >>Makes sense to me.  They both have chips already that stand a realB >>good chance of kicking IA64's butt.  Why waste time and money onD >>yet another contender when that time and money can be spent making2 >>the existing chips kick IA64's butt even harder. >> >>bill >  > E > with intel having alpha and the alpha engineers, no one is going toy > kick their $#!& ...e  6 Oh no here we go again, the Alpha inside Itanium troll strikes again.   Regardst Andrew Harrison-   ------------------------------  # Date: Wed, 08 Jan 2003 21:13:25 GMTr8 From: "Jerome H. Fine" <jhfineb9rv@b9rvnospamcompsys.to>0 Subject: Re: Looks like AMD has deep pockets now4 Message-ID: <3E1C9471.D07DCB8F@b9rvnospamcompsys.to>   >John Smith wrote:  H > http://news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/2003 > 0108/tc_nm/tech_ibm_amd_dc >h) > IBM, AMD to Develop New Microprocessorsp >iA > SUNNYVALE, Calif./EAST FISHKILL, N.Y. (Reuters) - InternationalsF > Business Machines Corp. (NYSE:IBM - news) and Advanced Micro DevicesE > Inc. (NYSE:AMD - news) on Wednesday said they would jointly developoG > high-performance microprocessors that would be commercially availablef > within two years.  >eA > The companies said they will collaborate on 65 nanometer and 45.D > nanometer technologies to be implemented on 300 millimeter silicon	 > wafers.h >I( > A nanometer is a billionth of a meter. >aC > The chips, which serve as the brains of computers and electronicstD > devices, will be based on advanced processes and materials such asG > high-speed silicon-on-insulator transistors, copper interconnects and = > improved "low-k dielectric" insulation, the companies said.t >rA > IBM and AMD said they expect first products based on the new 65sC > nanometer technologies to appear in 2005. Companies are currentlyo7 > moving from 130 nanometer technology to 90 nanometer.i >c( > -------------------------------------- > 1 > Just another reason why killing Alpha was dumb.e   Jerome Fine replies:  - You may find that this link is easier to use:j` http://news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/20030108/tc_nm/tech_ibm_amd_dc   Sincerely yours,   Jerome Finem --4 To obtain the original e-mail address, please remove5 the ten characters which immediately follow the 'at'.s8 If you attempted to send a reply and the original e-mail7 address has been discontinued due a high volume of junk45 e-mail, then the semi-permanent e-mail address can bem7 obtained by replacing the four characters preceding thee. 'at' with the four digits of the current year.   ------------------------------  # Date: Wed, 08 Jan 2003 21:20:21 GMTs8 From: "Jerome H. Fine" <jhfineb9rv@b9rvnospamcompsys.to>0 Subject: Re: Looks like AMD has deep pockets now3 Message-ID: <3E1C9612.21E34FB@b9rvnospamcompsys.to>s   >John Smith wrote:  H > http://news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/2003 > 0108/tc_nm/tech_ibm_amd_dc > ) > IBM, AMD to Develop New Microprocessorst > A > SUNNYVALE, Calif./EAST FISHKILL, N.Y. (Reuters) - International'F > Business Machines Corp. (NYSE:IBM - news) and Advanced Micro DevicesE > Inc. (NYSE:AMD - news) on Wednesday said they would jointly develophG > high-performance microprocessors that would be commercially availableu > within two years.z >nA > The companies said they will collaborate on 65 nanometer and 45 D > nanometer technologies to be implemented on 300 millimeter silicon	 > wafers.m >.( > A nanometer is a billionth of a meter. >fC > The chips, which serve as the brains of computers and electronicstD > devices, will be based on advanced processes and materials such asG > high-speed silicon-on-insulator transistors, copper interconnects ande= > improved "low-k dielectric" insulation, the companies said.9 >2A > IBM and AMD said they expect first products based on the new 65 C > nanometer technologies to appear in 2005. Companies are currently 7 > moving from 130 nanometer technology to 90 nanometer.m > ( > -------------------------------------- > 1 > Just another reason why killing Alpha was dumb.D   Jerome Fine replies:  - You may find that this link is easier to use:O` http://news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/20030108/tc_nm/tech_ibm_amd_dc   Sincerely yours,   Jerome Fine  --4 To obtain the original e-mail address, please remove5 the ten characters which immediately follow the 'at'.t8 If you attempted to send a reply and the original e-mail7 address has been discontinued due a high volume of junk=5 e-mail, then the semi-permanent e-mail address can be 7 obtained by replacing the four characters preceding the . 'at' with the four digits of the current year.   ------------------------------  # Date: Wed, 08 Jan 2003 20:53:40 GMT28 From: "Jerome H. Fine" <jhfineb9rv@b9rvnospamcompsys.to>0 Subject: Re: Looks like AMD has deep pockets now4 Message-ID: <3E1C8FD0.64F7B984@b9rvnospamcompsys.to>   >John Smith wrote:  H > http://news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/2003 > 0108/tc_nm/tech_ibm_amd_dc >e) > IBM, AMD to Develop New Microprocessors8 >1A > SUNNYVALE, Calif./EAST FISHKILL, N.Y. (Reuters) - InternationalrF > Business Machines Corp. (NYSE:IBM - news) and Advanced Micro DevicesE > Inc. (NYSE:AMD - news) on Wednesday said they would jointly developpG > high-performance microprocessors that would be commercially availabler > within two years.e >nA > The companies said they will collaborate on 65 nanometer and 45sD > nanometer technologies to be implemented on 300 millimeter silicon	 > wafers.d >t( > A nanometer is a billionth of a meter. >MC > The chips, which serve as the brains of computers and electronicssD > devices, will be based on advanced processes and materials such asG > high-speed silicon-on-insulator transistors, copper interconnects and = > improved "low-k dielectric" insulation, the companies said.t > A > IBM and AMD said they expect first products based on the new 65 C > nanometer technologies to appear in 2005. Companies are currentlyg7 > moving from 130 nanometer technology to 90 nanometer.i >t( > -------------------------------------- >i1 > Just another reason why killing Alpha was dumb.    Jerome Fine replies:  ( You may have better luck with this link:` http://news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/20030108/tc_nm/tech_ibm_amd_dc   Sincerely yours,   Jerome Finen --4 To obtain the original e-mail address, please remove5 the ten characters which immediately follow the 'at'. 8 If you attempted to send a reply and the original e-mail7 address has been discontinued due a high volume of junke5 e-mail, then the semi-permanent e-mail address can be 7 obtained by replacing the four characters preceding thei. 'at' with the four digits of the current year.   ------------------------------  # Date: Thu, 09 Jan 2003 20:10:04 GMTr# From: "John Smith" <a@nonymous.com>i, Subject: Re: Memo:  RE:  Boot Contest changeG Message-ID: <wGkT9.14299$pDv.5365@news04.bloor.is.net.cable.rogers.com>o  = "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in messagee) news:3E1DC754.36D11BF6@vl.videotron.ca...t >e > Does not compute...YC > <images of the bad guy's  computer in Star Trek with smoke comingu
 out of itsF > vents as it self destructs due to Kirk having convinced the computer it was > not logical).s     M5??   ------------------------------  % Date: Fri, 10 Jan 2003 10:15:59 -0800e$ From: Shane Smith <ssmith@icius.com>, Subject: RE: Memo:  RE:  Boot Contest change0 Message-ID: <01C2B891.47860790@sulfer.icius.com>  9 Seems to be a blend of M5 and the androids from "I Mudd".    Shane    -----Original Message-----( From: John Smith [mailto:a@nonymous.com]) Sent: Thursday, January 09, 2003 12:10 PMy To: Info-VAX@Mvb.Saic.Como* Subject: Re: Memo: RE: Boot Contest change      = "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in message ) news:3E1DC754.36D11BF6@vl.videotron.ca...e >  > Does not compute....C > <images of the bad guy's  computer in Star Trek with smoke comingR
 out of itsF > vents as it self destructs due to Kirk having convinced the computer it was > not logical).i     M5??   ------------------------------  % Date: Fri, 10 Jan 2003 08:31:16 -0500 5 From: "Sue Skonetski" <susan.skonetski@hp.nospam.com>: Subject: OpenVMS Pearl* Message-ID: <avmhv8$a97$1@web1.cup.hp.com>   -----Original Message-----   From: Skonetski, Susan  & Sent: Friday, January 10, 2003 8:29 AM   To: Skonetski, Susan  * Subject: OpenVMS Pearl - Friday Jan 10th -  G Thanks to Paul Marshall and John Brodribb (Ambassadors) for forwarding.   
 Warm Regards,o   Sueh  > Australian auto dealers gear up to Mimer SQL on OpenVMS system  I International auto IT software developer Infomedia Ltd. from Australia isyL planning to utilize the Mimer SQL engine running on the HP OpenVMS operatingJ system for the new version of their dealer management system, Autoledgers.F Autoledgers is Infomedia's successful automotive dealership managementK system used today at more than 200 Australian auto dealers, supporting such J manufacturers as Lexus, BMW, Mercedes, Chrysler, and Jaguar. Infomedia wasJ looking for a high-performance, cost-effective solution, which Mimer's SQL  and the OpenVMS system provided.  C For more information, go to http://www.mimer.com/news.asp?secId=176e   ------------------------------  % Date: Thu, 09 Jan 2003 22:32:04 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>G Subject: Re: OT (sadly) Opteron servers preparing to hit the real worldd/ Message-ID: <3E1E30A2.C041150A@vl.videotron.ca>h   Paul Repacholi wrote:FD > The other factor, is it seems to take a LONG time to respin a IA64H > design. 10 years for the first one, 2-3 for the revision, then severalB > more years until there is any possibility of significant change.  J This is why I am not convinced there is a future for IA64.  Intel and HP'sG commitments on IA64 are just as believable as those of Compaq on Alpha.i  C Had Intel succeeded with IA64, it would be able to produce low cost7I workstation IA64 chips, and have those beat the pants off the 8086, InteluK would then had had the power to convince Microsoft to dump 8086 and go IA64NN all the way. That would have twarthed AMD's plans for a 64 bit 8086 and withinK 5 years, everyone would be on IA64 based machines.  The fact that Carly and0N Curly were somehow convinced/brainwashed into thinking IA64 would be "industryJ standard" leads credence that at one point in time, Intel did plan to make IA64 "industry standard"..  I But now, it is clear that IA64 is being relegated to a niche market.  SunxI focuses on developping its own niche chip, Sparc. But can intel afford to.N continue to develop both the 8086 and IA64 when IA64 won't make the volumes toB pay back the 10 years of work that were neeeded to achieve a truly non-impressive chip ?i   ------------------------------  % Date: Fri, 10 Jan 2003 01:44:26 -0400b0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>D Subject: Re: Retrieve RMS Key information at runtime (using Fortran)/ Message-ID: <3E1E5DAC.48CF796C@vl.videotron.ca>    Hein wrote:uQ > Use the XABs you find, add those you need, then $DISPLAY and save desired data.>L > When done you must remove any XABs from the xab chain that you have added.   Why would that be ?   N If you leave the "extended" XAB chain, will the FORTRAN portion of the programL have problems when it exits and tries to deallocate the additional XABs that the user added in his code ?   ------------------------------  % Date: Fri, 10 Jan 2003 09:57:46 -0500a9 From: Hein van den Heuvel <hein_netscape@eps.zko.dec.com>tD Subject: Re: Retrieve RMS Key information at runtime (using Fortran). Message-ID: <3E1EDF6A.35AA03E@eps.zko.dec.com>   JF Mezei wrote:e  
 > Hein wrote:IS > > Use the XABs you find, add those you need, then $DISPLAY and save desired data. N > > When done you must remove any XABs from the xab chain that you have added. >x > Why would that be ?  >3P > If you leave the "extended" XAB chain, will the FORTRAN portion of the programN > have problems when it exits and tries to deallocate the additional XABs that > the user added in his code ?  Q Yes. It is somewhat version dependend. But you are supposed to leave any useropenxP provided structures as you found them (albeit filled in with open/connect/option values).U The fortran RTL has the right to remember that a certain XAB is the N'th in the chainC  T and blindly use it (it will not). The fortran RTL has the right to walk the XAB list andrP blindly call free_vm or some such for it upon close (It use to, and may still do that).K The fortran RTL has the right to re-use the same XAB for an other operationa (unlikely).tP It's what your mother told you... leave the room as you found it or better! :-).   Cheers,  Hein.k   ------------------------------    Date: 10 Jan 2003 02:43:51 -0800' From: vms_student2002@yahoo.com (Jason)-, Subject: TCPIP$HR_MIB uses a lot of the cpu.; Message-ID: <77e1caeb.0301100243.191e91@posting.google.com>   < Hi there I would like to know if anyone can tell me why doesB TCPIP$HR_MIB uses so much cpu time on my machine and while this is# happening the machine is very slow.a   Cheers Jasoni   ------------------------------  % Date: Fri, 10 Jan 2003 13:17:16 +0100m0 From: "labadie" <en_trajectant_a_mort@127.0.0.1>0 Subject: Re: TCPIP$HR_MIB uses a lot of the cpu.- Message-ID: <2SyT9.17$C42.0@news.cpqcorp.net>r  4 "Jason" <vms_student2002@yahoo.com> wrote in message5 news:77e1caeb.0301100243.191e91@posting.google.com...o> > Hi there I would like to know if anyone can tell me why doesD > TCPIP$HR_MIB uses so much cpu time on my machine and while this is% > happening the machine is very slow.    Hellot  4 If you have Tcpip 5.0A Eco 3 this is a know problem.  G Ask your Csc for new images, or upgrade to Tcpip 5.1 Eco 4 or 5.3 Eco 1s   Regardse   Grard   ------------------------------  + Date: Fri, 10 Jan 2003 17:00:17 +0000 (UTC)w, From: lewis@PROBE.mitre.org (Keith A. Lewis)0 Subject: Re: TCPIP$HR_MIB uses a lot of the cpu.. Message-ID: <avmu71$g0v$1@newslocal.mitre.org>   vms_student2002@yahoo.com (Jason) writes in article <77e1caeb.0301100243.191e91@posting.google.com> dated 10 Jan 2003 02:43:51 -0800:a= >Hi there I would like to know if anyone can tell me why doesaC >TCPIP$HR_MIB uses so much cpu time on my machine and while this is $ >happening the machine is very slow.  L That's one of the SNMP server processes.  Somebody is probably doing lots of queries to your SNMP port. 2  K Ask your sysadmin to disable SNMP.  Or if somebody needs it on for academicpL reasons, ask him to change the priority of the TCPIP$SNMP user to 1 (low).    H SNMP on VMS was never quite finished, and the entire protocol has fallen: out of favor in the last 2 years due to its hackability.    + --Keith Lewis              klewis$mitre.orgC> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Fri, 10 Jan 2003 03:59:40 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>' Subject: The need for reliable desktopso/ Message-ID: <3E1E7D6B.2D05F449@vl.videotron.ca>c  N Just listened to some interesting conversatiosn between ground and Alpha space station crewmembers.  G Every minute they spend up there costs <carl sagan accent> billions ands billions </accent> of dollars.    K The crew spent considerable time describing conditions that result in theirYR laptops freezing up.  The stop at "blue screen" (the "of death" remains silent...)  L Seems that if they use one program, they can't have more than 4 applicationsM minimized at a time. As a result, whenever they need a 5th program, they needpL to go to one of the 4 opened programs, terkminate it and then start the 5th,L otherwise they need to reboot. And They said that it takes quite a number ofK seconds everytime they need to do that and that at the end of the day, theyI$ get to do less work because of that.  F They also mentioned that to get to one function, they have to start upI explorer, wait for the "home page" to appear, and then type in the url ofeN another page they need to access, again, wasting valuable time, and they askedJ whether it would be possible to have an icon on the desktop that would get1 them directly to that page, saving valuable time.r  I Also, they mentioned that their daily task report required their constantuH attention because the printing process would generate an alert for everyK bullet point because it seemed to be outside the printer's margins, so they F had to confirm this (probably a "continue anyways ?" type of prompt).     H Oh, and a few minutes later, they come on the intercom, complaining thatH printing had slowed down to a crawl. Seems ground staff were downloadingL pitcures they had taken back to earth and this was considerably slowing downL the file server, so they asked the ground folks to stop doing what they were# doing until the printing had ended.I  J Can you imagine the amount of productivity lost due to the decision to use= windows laptops for the "office" stuff on the space station ??    H Seems that even on the space station, rebooting is the "standard" fix toL computers freezing up. (thankfully, the life support and guidance compuytersP are not windows based, and the windows laptops cannot even connect to those :-).  L Now, the station has been occupied for over 2 years now. And after the firstK expedition came back, on one report, the time lost due to computer bugs was G highlighted by the commander of the mission and when he was asked for atB suggestion on how to fix the prlem he answered "get some macs" :-)  M If the world's top scientists can't get a windows laptop to operate reliably,.K imagine how much time is wasted worldwide by all those windows users :-( -(h  K If only they had selected VMS laptops for the space station , booted into a F cluster. (at the time those decisions were made, VMS wasn't dead yet).   ------------------------------  # Date: Fri, 10 Jan 2003 14:22:31 GMT # From: "John Smith" <a@nonymous.com>A+ Subject: Re: The need for reliable desktopssG Message-ID: <HGAT9.26990$u1K.2022@news02.bloor.is.net.cable.rogers.com>   = "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in messagee) news:3E1E7D6B.2D05F449@vl.videotron.ca... D > Just listened to some interesting conversatiosn between ground and Alpha space. > station crewmembers. >iE > Every minute they spend up there costs <carl sagan accent> billions  and   > billions </accent> of dollars. >a >rD > The crew spent considerable time describing conditions that result in theirA > laptops freezing up.  The stop at "blue screen" (the "of death"s remains silent...) >pA > Seems that if they use one program, they can't have more than 4r applicationsE > minimized at a time. As a result, whenever they need a 5th program, 	 they needyE > to go to one of the 4 opened programs, terkminate it and then starte the 5th,D > otherwise they need to reboot. And They said that it takes quite a	 number of C > seconds everytime they need to do that and that at the end of the 	 day, they2& > get to do less work because of that. >aE > They also mentioned that to get to one function, they have to start0 upD > explorer, wait for the "home page" to appear, and then type in the url ofE > another page they need to access, again, wasting valuable time, ande
 they askedB > whether it would be possible to have an icon on the desktop that	 would gett3 > them directly to that page, saving valuable time.i >tB > Also, they mentioned that their daily task report required their constantD > attention because the printing process would generate an alert for everyFE > bullet point because it seemed to be outside the printer's margins,t so theyd> > had to confirm this (probably a "continue anyways ?" type of prompt). >> >uE > Oh, and a few minutes later, they come on the intercom, complaining> that> > printing had slowed down to a crawl. Seems ground staff were downloadingDA > pitcures they had taken back to earth and this was considerably  slowing downD > the file server, so they asked the ground folks to stop doing what	 they weree% > doing until the printing had ended.  >fE > Can you imagine the amount of productivity lost due to the decisionh to use? > windows laptops for the "office" stuff on the space station ?- >- >-C > Seems that even on the space station, rebooting is the "standard"* fix toC > computers freezing up. (thankfully, the life support and guidance 
 compuytersD > are not windows based, and the windows laptops cannot even connect
 to those :-).I >iD > Now, the station has been occupied for over 2 years now. And after	 the firstuD > expedition came back, on one report, the time lost due to computer bugs wasC > highlighted by the commander of the mission and when he was asked* for a*D > suggestion on how to fix the prlem he answered "get some macs" :-) > E > If the world's top scientists can't get a windows laptop to operatel	 reliably,cF > imagine how much time is wasted worldwide by all those windows users :-( -( >eF > If only they had selected VMS laptops for the space station , booted into aB > cluster. (at the time those decisions were made, VMS wasn't dead yet).a    A The only problem with Alpha-based notebooks is the heat output. I C often thought of piping the heat from the one Alpha notebook I cametC across for use in snowmelt to keep my driveway clear in the winter.    ------------------------------  % Date: Fri, 10 Jan 2003 18:15:53 +0100l$ From: Michael Unger <unger@decus.de>+ Subject: Re: The need for reliable desktops + Message-ID: <00A19C5C.C6AAEE87.10@decus.de>m  3 "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote:S  P > Just listened to some interesting conversatiosn between ground and Alpha space > station crewmembers. >2 > [...]: >-J > Seems that even on the space station, rebooting is the "standard" fix toN > computers freezing up. (thankfully, the life support and guidance compuytersR > are not windows based, and the windows laptops cannot even connect to those :-).  > The powers that be at MS didn't manage to get WinCE ("The best2 real-time operating system") used for that job ???   > [...]a >aO > If the world's top scientists can't get a windows laptop to operate reliably,uM > imagine how much time is wasted worldwide by all those windows users :-( -(  >tM > If only they had selected VMS laptops for the space station , booted into alH > cluster. (at the time those decisions were made, VMS wasn't dead yet).  ? But has a sufficient number of (Tadpole's) AlphaBooks ever beend	 produced?a   Michaelv   ------------------------------    Date: 10 Jan 2003 04:07:35 -0800$ From: hot_pash@yahoo.com (astro man)$ Subject: tn3270/key_definitions=file= Message-ID: <49ff054b.0301100407.7aa5c938@posting.google.com>d   Hello,  C I am trying desperately to map my keyboard definition to TN5270 IBM, AS/400B keyboard mapping under OpenVMS. Does anyone have a key_definitions5 file I could use so that this could be made possible.e   Many Thankse   hot_pash@yahoo.com   ------------------------------  + Date: Fri, 10 Jan 2003 18:56:30 +0000 (UTC)03 From: "Richard Maher" <maher_rj@hotspamnotmail.com>c+ Subject: Re: Traceback and installed imagesN. Message-ID: <avn50t$fc$1@helle.btinternet.com>   Cheers then.  1 John Reagan <john.reagan@hp.com> wrote in messagen* news:v4iT9.118$If1.116@news.cpqcorp.net... > Jerome H. Fine wrote:  >-G > > The key point (IF  I remember correctly) is that there was NO extramG > > code generated within the EXE executable code for the program.  Thes? > > SYMBOL tables were able to let the "/TRACEBACK" switch knowj! > > where everything was located.  >kD > Correct.  /DEBUG=TRACEBACK (the default for most compilers) has noI > effect on generated code.  It just causes the generation of EOBJ$C_ETBTvF > records in the object file.  These records are just PC increment andI > line number pairs (for the most part).  The linker collects them up andsH > leaves them in a known place in the image.  Traceback and the debuggerJ > then find them and decode them.  You can read a little about in AppendixJ > B in the linker manual.  However, the exact layout of the debug info and6 > traceback info isn't documented (that I'm aware of). >SA > For full /DEBUG, traditionally on VAX, /DEBUG didn't change anyiD > generated code either.  However, on Alpha, /DEBUG might cause someJ > compilers to generate slightly different code to leave certain values inI > known locations for the debugger to use (the exact location is conveyed-B > between the compiler and the debugger inside the debug records). >r >  > --
 > John Reagane) > Compaq Pascal/{A|I}MACRO Project Leaderr > Hewlett-Packard Companye >$   ------------------------------  % Date: Fri, 10 Jan 2003 07:18:10 -0800@# From: "Tom Linden" <tom@kednos.com>i Subject: VAX Arch Hdbk9 Message-ID: <CIEJLCMNHNNDLLOOGNJICEELGGAA.tom@kednos.com>e  ? is there one available online?  Didn't find any on Waybackwhen.S If not, anybody have a spare?    Tomn ---g& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).A Version: 6.0.435 / Virus Database: 244 - Release Date: 12/30/2002N   ------------------------------  % Date: Fri, 10 Jan 2003 13:31:07 -0500G From: G Everhart <ge@gce.com>r! Subject: re: vdd64 and Percepticsy& Message-ID: <3E1F116B.7040305@gce.com>  W Vdd64 probably is not very helpful with perceptics. It might let you treat some area ofiN such a device as the start of a volume, but that's about all it could buy you.  T If the only issue you are having is blocksize on device not 512, try idezr.zip whichU I think is on recent sigtapes and I believe I sent Hunter Goatley a copy. It will use P io$_diagnose to talk to the underlying scsi device and will buffer blocks insideP zridehost (talking to zrdriver and the real device) so VMS sees a 512 byte block device.r  W This will not fix the filesystem differences on WORM opticals. Perceptics long long agobT gave DECUS some utilities that it claimed would read their volumes, but I have neverY tried them. Believe they still exist at ftp.decus.org if someone recalls the number. They  have been on old sigtapes too.  T If you use optical drives that do 512, just try with dkdriver. It might work...I putX in some fixes to enable it in 7.1 a few years back. If dkdriver won't mount your opticalV you can use idezr. That package demands very little of a device...basically only caresK if it can tell the device size and if it will allow r/w and generates dummy1 replies for everything else.  U I don't know what else might be needed, since I have little to no info about what the U volumes you want to read look like. Far as I know, Perceptics and its successors weretX the only ones who wrote the kind of ACP they used. US Designs had some different ways ofU treating opticals. (So for that matter did I.) The strategy of using a custom ACP wasoW unfortunately a resource intensive one...every VMS version needed updates. If you triedtV using the ACP, btw, one thing to try first would seem to be to disable all VMS cachingZ packages; they introduce i/o paths that Perceptics certainly never would have heard of. AsV far as I ever heard, tho, Perceptics' ACP only ever ran on Vax, not Alpha. Get thee to an emulator!   ;-)n   Glenn Everhart   ------------------------------  # Date: Wed, 08 Jan 2003 20:59:10 GMTz- From: "Rick Peters" <morexsupport@rogers.com>R Subject: Re: VMS troublesmF Message-ID: <yi0T9.6952$pDv.4163@news04.bloor.is.net.cable.rogers.com>  L Note that there were two different versions of TK50 diagnostic tapes for theL MicroVAX II. One was user diagnostics that would test some functions (basic)G of the system and identify defective hardware. The second was DEC fieldoF service diagnostics not sold to the public that included the formatterK utilities. By the way an unprepared (non RQDX3 format) drive would not show-
 up at all.   Rick (Ex DEC Field Service)r  = "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in messagen) news:3E15EDB4.BFD2ECEF@vl.videotron.ca...? > vmstroubles wrote: > >9I > > Another update, I installed the replacement RQDX3 controller card and  ran J > > the diagnostics software and the card passed apparently but it gave me an8 > > error after all of the tests were done.  Here it is. >tL > Do you have the Microvax II hardware manual ? It is a small orange binder. InJ > it, the RQDX3 jumpers are explained. YOu really need to do your homework onK > this and make a full inventiry of what boards are in your microvax II and  what3 > their settings are. You may have a Qbus conflict.d >(K > Also, are you sure that your QBUS cards are inserted correctly and in theaK > correct order ? (on the left of the Qbus, when looking from the back, you: willI > see the qubus layout sticket that shows the "serpentine" order in which0 thef > boards have to be inserted.    ------------------------------  % Date: Fri, 10 Jan 2003 12:35:57 -0400t0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca> Subject: Re: VMS troublest/ Message-ID: <3E1EF66C.117B40A8@vl.videotron.ca>w   Rick Peters wrote: > N > Note that there were two different versions of TK50 diagnostic tapes for theN > MicroVAX II. One was user diagnostics that would test some functions (basic)I > of the system and identify defective hardware. The second was DEC field1H > service diagnostics not sold to the public that included the formatter > utilities.  H I seem to have the customer diagnostics, and it does have the ability toK format RD5x drives. But there are some functions not available in the menu.c   ------------------------------  % Date: Fri, 10 Jan 2003 10:08:36 -0500 : From: Charlie McCutcheon <charlie.mccutcheonUNSPAM@hp.com>9 Subject: Re: VMS731_ACRTL-V0100 Release notes [complaint]o% Message-ID: <3E1EE1F4.A6D6B18@hp.com>H  J > How am I supposed to know which C RTL functions are covered; i.e., whichI > functions should I avoid using?  There are multiple C RTL functions for L > 'doing a read' as described in the release notes.  The release notes implyJ > that the functions that the JVM uses are covered by this ECO.  Searching, > DSNLINK does not point to anything useful. >sL > I would like to be able to determine that the C RTL functions I'm using inM > my code are not (potentially) subject to the same kind of 'random' ACCVIOs,-J > which are generally frowned upon in production environments.  Please and > thank-you.  B The CRTL change was for issues which we believe are Java specific.F We aren't expecting general users to see these issues, which is why we didn't document the change.   I The problems addressed aren't "new", and are not due to any recnet change P in the C Run-Time.  If you haven't seen these before, you're not likely to start   seeing them with this kit.  D At some point, we may expand the list of functions covered, and then document this feature.   Sorry for the confusion.   CRTL engineering   ------------------------------  % Date: Fri, 10 Jan 2003 18:26:46 +0800 & From: Saminda C F Lam <ccminda@ust.hk> Subject: What does RWCLU mean?# Message-ID: <3E1E9FE6.60809@ust.hk>)  B What does RWCLU mean?  The manual says "Resource Wait for Cluster H Transition".  I found processes in RWCLU state on an Alpha cluster.  Is ? it indicative of some resource problem?  If so, what resources?c   Thanks in advance, Samindas   ------------------------------  % Date: Fri, 10 Jan 2003 15:11:18 +0800 ) From: "Steven Xie" <r33300@email.mot.com>h+ Subject: Re: Why LOGINOUTs don't go away??? + Message-ID: <avlro8$b7g$1@newshost.mot.com>r  H This morning we have re-produced the phenomenon. We start a REXEC_GRAMMSE process manually (X11 application, remote call actually, the image itIJ running is TMS.EXE). Then we close the X session and then the REXEC_GRAMMSK process turn into "loginout" right after. And we stopped all the "loginout"n nobody got impacted.  = Do you think it caused by the R service or the system itself?g   Thanks,t Steven    H "Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message- news:Ikq2YcG$k$aD@eisner.encompasserve.org... 8 > In article <00A19ACC.C13F8B93@SSRL.SLAC.STANFORD.EDU>,F winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes:u< > > In article <avil11$sjr$1@newshost.mot.com>, "Steven Xie" <r33300@email.mot.com> writes: > >>Hello all, > >>K > >>We have found something interesting after we upgrade our system to V7.3oL > >>(ES40, 4GB, original OS was V7.2-1). When we look at our system we foundI > >>there are 200s of process with same name "REXEC_GRAMMS" and the imagec behindI > >>them are all sys$system:loginout.exe. As I understanding, when we usenF > >>loginout to shot a detach process, it will go away right after the processeJ > >>done. You won't get chance to see a process running loginout.exe (evenK > >>though it's running for a short time). Does anybody there can give me av	 > >>hint?n > > H > > What TCP/IP package are you running?  REXEC_GRAMMS are - I presume -I > > processes invoked on behalf of the user GRAMMS who is doing an rsh orn someI > > such from another machine.  I don't know wny they hang; maybe there's2A > > some unfortunate logic in sylogin.com or the user's login.comu >cG >    There doesn't happen to by an rsh in his login.com, does there?  IFG >    had something similar when someone put a DECnet reference to thiereH >    own node in their login.com.  The network process login, of course, >    ran login.com ... >o   ------------------------------   End of INFO-VAX 2003.020 ************************