1 INFO-VAX	Fri, 25 Apr 2003	Volume 2003 : Issue 227       Contents:- Re: accessing consoles remotely via decserver - Re: accessing consoles remotely via decserver - Re: accessing consoles remotely via decserver - Re: accessing consoles remotely via decserver D Re: AlphaServers (and AlphaStations) readded to german HPQ pricelist& Re: Day Light Savings for VMS and UNIX Re: ES40 memory_test9 How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! = Re: How Alpha will save Itanium - must reading for Bill Todd! ' Re: how can you do this with SMG$ calls ' Re: how can you do this with SMG$ calls  Re: HTML favourite editor? Re: HTML favourite editor?H Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyH Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham!6 Re: OpenVMS Itanium port progressing well says Gorham! Re: Oracle & OpenVMS) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE ) Re: Question on logical name PSM$ANNOUNCE  Re: TCPIP_SSH EAK  Thread Scheduling  Re: Thread Scheduling  Unwanted Broadcast messages 8 VAX & ALPHA hobbyist hardware wanted in or near Belgium.- Re: VMS SECURITY: Adding Privileges to a USER - Re: VMS SECURITY: Adding Privileges to a USER - Re: VMS SECURITY: Adding Privileges to a USER - Re: VMS SECURITY: Adding Privileges to a USER   F ----------------------------------------------------------------------  % Date: Thu, 24 Apr 2003 18:24:09 +0200 , From: Albrecht Schlosser <ajs856@tiscali.de>6 Subject: Re: accessing consoles remotely via decserver, Message-ID: <73398b.01t.ln@news.hus-soft.de>  
 Manser wrote:  > L > i switched off remote modification, and i have done the following settings > F > Local> set port 2 flow xon stop dynamic break remote remote disabled  G You must do all changes with "define port" (or "change port") to modify D the permanent settings. Then "log out port <n>" to get the permanent settings active.  & > Local> set port 2 input flow enabled' > Local> set port 2 output flow enabled    Don't do this (see below).  7 > Port  2:                               Server: DS90_1  > H > Character Size:            8           Input Speed:               9600H > Flow Control:            XON           Output Speed:              9600H > Parity:                 None           Signal Control:        Disabled > Stop Bits:           Dynamic > H > Access:               Remote           Local Switch:              NoneH > Backwards Switch:       None           Name:                    PORT_2H > Break:                Remote           Session Limit:                1H > Forwards Switch:        None           Type:                      Ansi > Default Protocol:        LAT >  > Dedicated Service: VMAL01  >  > Authorized Groups:   0 > (Current)  Groups:   0 >  > Enabled Characteristics:J > Autoconnect,  Failover,  Input Flow Control,  Lock,  Output Flow Control >  > Local> connect vmal01 < > Local -010- Session 1 to VMAL01 on node DS90_1 established   You also renamed the services ?    > i hit 2 times return >  > i hit init > B     BhcB~ > >             CFB~8   BFfcQ=Q"D3#DDq)#D= > (   ; This may be because you didn't make the permanent settings.   1 > i then tried to set port 2 to differents speeds  > Local> connect al01 : > Local -010- Session 1 to AL01 on node DS90_1 established >  > then it hangs.  E May be because of the (still) wrong speed and/or flow control. One of < the bytes with the wrong speed might have been seen as XOFF.  " > the console speed is set at 9600  . That's okay. Now do this on the local> prompt:  & Local> def port 2 flow none speed 9600% Local> def port 2 input flow disabled & Local> set port 2 output flow disabled Local> logout port 2   and have another try ...  D My experience is that it is better to do the flow control (XON/XOFF)G between your terminal (emulation) and the connected console rather than G between the terminal server port and the console. You risk some loss of E bytes, but the connection never "hangs". At least you should use this  setup for testing.  E It's also useful to disable flow control on the terminal server port, H because it might otherwise block the console while booting or outputtingH console messages, if there is no terminal actually connected. I had thisB experience once, and someone had to go a long way to get it fixed.   Albrecht Schloer    ------------------------------    Date: 24 Apr 2003 14:55:03 -0700  From: nmanser@progis.de (Manser)6 Subject: Re: accessing consoles remotely via decserver= Message-ID: <2178d61f.0304241355.2702afe1@posting.google.com>   ` Albrecht Schlosser <ajs856@tiscali.de> wrote in message news:<73398b.01t.ln@news.hus-soft.de>... > Manser wrote:  > > N > > i switched off remote modification, and i have done the following settings > > H > > Local> set port 2 flow xon stop dynamic break remote remote disabled > I > You must do all changes with "define port" (or "change port") to modify F > the permanent settings. Then "log out port <n>" to get the permanent > settings active. > ( > > Local> set port 2 input flow enabled) > > Local> set port 2 output flow enabled  >  > Don't do this (see below). > 9 > > Port  2:                               Server: DS90_1  > > J > > Character Size:            8           Input Speed:               9600J > > Flow Control:            XON           Output Speed:              9600J > > Parity:                 None           Signal Control:        Disabled  > > Stop Bits:           Dynamic > > J > > Access:               Remote           Local Switch:              NoneJ > > Backwards Switch:       None           Name:                    PORT_2J > > Break:                Remote           Session Limit:                1J > > Forwards Switch:        None           Type:                      Ansi  > > Default Protocol:        LAT > >  > > Dedicated Service: VMAL01  > >  > > Authorized Groups:   0 > > (Current)  Groups:   0 > >  > > Enabled Characteristics:L > > Autoconnect,  Failover,  Input Flow Control,  Lock,  Output Flow Control > >  > > Local> connect vmal01 > > > Local -010- Session 1 to VMAL01 on node DS90_1 established > ! > You also renamed the services ?  >  > > i hit 2 times return > >  > > i hit init > > B     BhcB~ @ > >             CFB~8   BFfcQ=Q"D3#DDq)#D= > > (  > = > This may be because you didn't make the permanent settings.  > 3 > > i then tried to set port 2 to differents speeds  > > Local> connect al01 < > > Local -010- Session 1 to AL01 on node DS90_1 established > >  > > then it hangs. > G > May be because of the (still) wrong speed and/or flow control. One of > > the bytes with the wrong speed might have been seen as XOFF. > $ > > the console speed is set at 9600 > 0 > That's okay. Now do this on the local> prompt: > ( > Local> def port 2 flow none speed 9600' > Local> def port 2 input flow disabled ( > Local> set port 2 output flow disabled > Local> logout port 2 >    I try   - Local> define port 2 flow disabled speed 9600 % Local> def port 2 input flow disabled & Local> set port 2 output flow disabled Local> logout port 2     > and have another try ...   local>show port 2   5 Port  2:                               Server: DS90_1   F Character Size:            8           Input Speed:               9600F Flow Control:           None <<<       Output Speed:              9600F Parity:                 None           Signal Control:        Disabled Stop Bits:                 1  F Access:               Remote           Local Switch:              NoneF Backwards Switch:       None           Name:                    PORT_2F Break:              Disabled           Session Limit:                1F Forwards Switch:        None           Type:                      Ansi Default Protocol:        LAT   Dedicated Service: VMAL01    Authorized Groups:   0 (Current)  Groups:   0   Enabled Characteristics: Autoconnect,  Failover,  Lock    Local> connect vmal01 : Local -010- Session 1 to VMAL01 on node DS90_1 established     the same result.   > F > My experience is that it is better to do the flow control (XON/XOFF)I > between your terminal (emulation) and the connected console rather than I > between the terminal server port and the console. You risk some loss of G > bytes, but the connection never "hangs". At least you should use this  > setup for testing. > G > It's also useful to disable flow control on the terminal server port, J > because it might otherwise block the console while booting or outputtingJ > console messages, if there is no terminal actually connected. I had thisD > experience once, and someone had to go a long way to get it fixed. >  > Albrecht Schloer    Nazim Manser   ------------------------------  # Date: Thu, 24 Apr 2003 22:24:13 GMT   From: Rob Brown <brown@gmcl.com>6 Subject: Re: accessing consoles remotely via decserverL Message-ID: <Pine.LNX.4.44.0304241618320.24932-100000@localhost.localdomain>   On 24 Apr 2003, Manser wrote:    > Local> connect vmal01 < > Local -010- Session 1 to VMAL01 on node DS90_1 established >  >   E Still looks like a speed problem.  You confirmed the correct speed.   * Looks like you have done everything right.  A Get a terminal or emulator, configure it as you have the terminal D server port, ie 9600 8 n 1 no flow control.  Plug it in to the cableE coming from the console port.  Do you get a response when you type on 
 the terminal?   A Plug the terminal in to the cable coming from the terminal server F port.  Do a TEST PORT.  Did it work?  Connect to the service.  Can you get data going both ways?   . Maybe we can learn something from these tests.     --    / Rob Brown                        brown@gmcl.com A G. Michaels Consulting Ltd.      (866)438-2101 (voice) toll free! 6 Edmonton                         (780)438-9343 (voice)4                                  (780)437-3367 (FAX)1                                  http://gmcl.com/    ------------------------------  % Date: Thu, 24 Apr 2003 18:59:42 -0400 3 From: "Homer J. Simpson" <hsimpson@burnsenergy.com> 6 Subject: Re: accessing consoles remotely via decserver: Message-ID: <tRZpa.32525$sa.13622@fe02.atl2.webusenet.com>  I I think I remember you said you had one server console connection working K properly and another not working properly.  Could you swap the plugs at the L DECserver to see if the problem moves or stays with VMAL01?  That would tellI you a lot right there.  If the problem is now with the other server, then I you have a DECserver or configuration problem.  If the problem stays with L the same server, then you possibly have a cable problem.  Is the cable lying on top of a motor somewhere?  - "Rob Brown" <brown@gmcl.com> wrote in message F news:Pine.LNX.4.44.0304241618320.24932-100000@localhost.localdomain... > On 24 Apr 2003, Manser wrote:  >  > > Local> connect vmal01 > > > Local -010- Session 1 to VMAL01 on node DS90_1 established > > 
 > >  > E > Still looks like a speed problem.  You confirmed the correct speed. , > Looks like you have done everything right. > C > Get a terminal or emulator, configure it as you have the terminal F > server port, ie 9600 8 n 1 no flow control.  Plug it in to the cableG > coming from the console port.  Do you get a response when you type on  > the terminal?  > C > Plug the terminal in to the cable coming from the terminal server H > port.  Do a TEST PORT.  Did it work?  Connect to the service.  Can you > get data going both ways?  > 0 > Maybe we can learn something from these tests. >  >  > --   > 1 > Rob Brown                        brown@gmcl.com C > G. Michaels Consulting Ltd.      (866)438-2101 (voice) toll free! 8 > Edmonton                         (780)438-9343 (voice)6 >                                  (780)437-3367 (FAX)3 >                                  http://gmcl.com/  >  >    ------------------------------  # Date: Thu, 24 Apr 2003 23:33:21 GMT 6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)M Subject: Re: AlphaServers (and AlphaStations) readded to german HPQ pricelist 4 Message-ID: <5v_pa.231542$UR.2247400@news.chello.at>  k In article <4b_ma.52900$UR.449584@news.chello.at>, peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER) writes: M >You might remember my posting <VPmga.210290$8L1.1935460@news.chello.at> from O >last March where I ranted about the removal of Alphaservers from the pricelist L >at the german HPQ webserver http://www1.compaq.de/preisliste/pricelist.aspx > N >I just noticed very happily that (after some weeks) they are now back again ! > O >So far I haven't found out what happened (maybe the DECUS event last week...), = >but I'd like to thank the persons who did the "right thing".    And now they are gone again :-O   " The list is now (again reduced to)   		Handhelds  		Notebooks 
 		Desktops
 		Monitore 		Industriestandardserver 	 		Storage  		Netzwerkprodukte  F It seems, somebody (or something) doesn't like Alphas at HP Germany...   --   Peter "EPLAN" LANGSTOEGER % Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------   Date: 24 Apr 2003 19:40 CDT ' From: carl@gerg.tamu.edu (Carl Perkins) / Subject: Re: Day Light Savings for VMS and UNIX - Message-ID: <24APR200319404377@gerg.tamu.edu>    <arne@vajhoej.dk> writes...  }Patrick Spinler wrote: C }> Unix(s) store the clock internally in GMT or Universal time and  G }> translate it on output to the local timezone.  The translation code  G }> takes care of the necessary daylight savings adjustments, and since  I }> internal times are in a format that does not suffer from the need for  H }> large adjustments you need not worry about problems like overlapping  }> file or database timestamps.  } > H }> In short, daylight savings time stuff is one of the things Unix does 	 }> right.  } $ }But VMS is doing it the same way !? } 4 }(since VMS 6.x 10 years ago or something like that) }  }Arne   E I think you are incorrect. I'm pretty sure that the internal clock on E a VMS system is local time. There is no conversion for most purposes. E The conversion stuff, like the timezone differential logical name, is F used to convert from the local time that the clock uses to UTC not theD other way around. (So the SYS$BINTIM routine's returned value is theE value used by the internal clock and it has no conversion done to it. ! This is the local time, not UTC.)   H At least, I'm pretty certain that is how it is working up to V7.2-1 (andG probably -2), but V7.3 may have changed this (although I don't think it  did).   K I seem to recall someone, maybe Hoff, indicating that they may make it work % in the above way sometime after V8.0.    --- Carl   ------------------------------  # Date: Fri, 25 Apr 2003 02:44:44 GMT = From: Michael Austin <maustin@n-o-s-p-a-m-firstdbasource.com>  Subject: Re: ES40 memory_test > Message-ID: <3EA8A0D8.A6FEF550@n-o-s-p-a-m-firstdbasource.com>   Galen wrote: > A > A copy of the ES40 manual from several years back says that the D > MEMORY_TEST console parameter must be set to FULL for VMS systems. >  > Is this still the case?  > D > I ask because setting it to PARTIAL appears to cause problems justD > doing an INIT for us. And yes, we have the latest firmware release > (firmware update V6.3).  > 	 > Thanks,  >  > Galen Tackett C > (remove the "spam" from my e-mail address to actually reach me by 	 > e-mail)     F  I have a few ES40's and have seen some interesting things happen when@ set to partial -- even with 6.4 firmware. Bugcheck on first (andF sometimes 2nd and 3rd) boot after init.  Setting it to full appears toG correct this situation, and yes, even with 8GB of memory takes a while.  --   Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163    ------------------------------    Date: 24 Apr 2003 17:33:03 -0700( From: bob@instantwhip.com (Bob Ceculski)B Subject: How Alpha will save Itanium - must reading for Bill Todd!= Message-ID: <d7791aa1.0304241633.5f5d516e@posting.google.com>   0 here is how Alpha will save Itanium Bill ... you1 can click link and read, but I especially cut out . the paragraph for Bill how Alpha EV8-9 designs  will fit nicely with Itanium ...    ( http://www.theinquirer.net/?article=9127    ' excerpt for Bill from above article ...   B While Alpha and Itanium architectures are as opposite as white andB black, there still is a lot of Alpha stuff that could find its wayB into the IA-64 barn. Distributed memory controllers of EV7 and itsE cancelled follow-ons are obvious candidate (with Rambus maybe changed B to DDR2) as Itanium's bus architecture is the most urgent issue to fix.  A Another possibility is one that most of The Inquirer readers, and C Intel Itanium guys too, were aware of from over a year ago: use EV8 C 8-way superscalar core design as a model, but instead of eight RISC D instructions, the thing could handle 4 or 8 128-bit EPIC bundles per= cycle, each with 3 instructions - possible with newer semicon D processes for wider, more parallel ALUs, register sets and datapatchF to handle the increased load. And what would be the final trick? Well,B let the compiler schedule ops within each EPIC bundle, but let the? out-of-order CPU execution schedule whole bundles out-of-order.   < So, in-order execution within each bundle just like now, butA out-of-order bundle scheduling! Hah, just add the EV9-like vector $ unit, and this could be a monster...   ------------------------------  % Date: Thu, 24 Apr 2003 23:12:18 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!. Message-ID: <3EA8A764.779C9DB@vl.videotron.ca>   Bob Ceculski wrote: D > into the IA-64 barn. Distributed memory controllers of EV7 and itsG > cancelled follow-ons are obvious candidate (with Rambus maybe changed D > to DDR2) as Itanium's bus architecture is the most urgent issue to > fix.  M "after the purchase of Chrysler, Daimler Benz intends to use the concept used 6 by Chrysler to allow its vehicles to move: the wheel."    M Ask yourself: of all of the alpha trademarks that were given to Intel to use, D what percentage are applicable to the IA64 only, what percentage areN applicable to both Alpha and 8086 and what percentage are so incompatible that& they are applicable to only the 8086 ?  N I suspect that more Alpha technology and ideas will make their way to the 8086J simply because they are more compatible. Of the ones that apply to both, IK suspect that they are "ideas" that are not so tightly patented and could be R implemented by others (such as the wheel implemented by Ford and GM for instance).    J Where Intel has won, assuming it will retain the engineers, are the slavesL that Compaq gave to Intel. If the people who were smart enough to make AlphaN work as diligently on Intel products, then they will bring Intel products realL values. But I suspect that in the case of IA64, it won't be so much re-usingN Alpha technology, but rather put those brains to work to solve all the hidious- EPIC architecture bloatware and make it work.   J If those brains leave and go work for Sun and AMD or IBM, then Intel won'tK have gained that  much from Alpha with regards to IA64. Remember that Intel G gained a LOT from Alpha when it "inspired" itself and implemented Alpha  concepts in its 8086.    ------------------------------  % Date: Fri, 25 Apr 2003 01:04:03 -0400 * From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: How Alpha will save Itanium - must reading for Bill Todd!2 Message-ID: <7uCcnbVJT-JYXDWjXTWcpw@metrocast.net>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in message 7 news:d7791aa1.0304241633.5f5d516e@posting.google.com... * > here is how Alpha will save Itanium Bill  G By George, Bob, you've finally come around to the conclusions I reached K nearly two years ago when people like you, Kerry, and Mark Gorham (the last F as reported by Alphaman) were spewing nonsense about an Alpha-enhancedJ 'IA64-2' or 'combined Alpha/IA64' (that would be *required* for VMS to runF on) appearing by the time the VMS port was completed (i.e., clearly byH 2004), thus avoiding the need for an EV7 shrink to 130 nm.  See a c.o.v.L post of 7/14/01 of mine for some specific references to that nonsense (CathyI Stockwell was still spewing the same crap at a Diamond Forum over a month $ later - see c.o.v. post of 8/24/01).  L In August, 2001, I predicted that the first possible appearance of any AlphaI technology in Itanic would be in 2005:  still the same old McKinley-style F core, but perhaps getting EV7-style on-chip glue to help it out (firstC expressed in a private note on 8/19/01, then in multiple c.o.v. and J comp.arch posts on 8/24/01).  This turned out to be over-optimistic, sinceJ the target procuct for 2005 is now Montecito, in a package compatible withL McKinley/Madison and therefore clearly not containing any EV7-style goodies.  K I also predicted that the first possible appearance of any Alpha technology L such as OoO and SMT in the Itanic *core* would be in 2006 -7 (mentioned in aE c.o.v. post of 7/20/01, and in multiple c.o.v. and comp.arch posts on I 8/24/01).  These are indeed the dates now starting to be talked about for ? 'Tanglewood', the first product of the transplanted Alpha team.   B So, Bob, the only thing that's changed is *your* perception of theG situation.  If you'd paid attention two years ago, you'd have seemed at / least somewhat less of an idiot in the interim.    - bill   ------------------------------    Date: 24 Apr 2003 16:56:51 -0700& From: chessmaster1010@hotmail.com (JG)0 Subject: Re: how can you do this with SMG$ calls= Message-ID: <dd3f0cb7.0304241556.286de275@posting.google.com>   [ hoff@hp.nospam (Hoff Hoffman) wrote in message news:<xdEpa.298$Ys4.202@news.cpqcorp.net>... h > In article <dd3f0cb7.0304231354.67818227@posting.google.com>, chessmaster1010@hotmail.com (JG) writes: >  > I > :My question is: Is there a way to tell SMG$ to do this "highlight only F > :the changed areas" itself?  If I change the default rendition afterG > :the first pass it repaints the entire SMG$PUT_LINE output in the new 
 > :rendition.  > , >   How would SMG know what is changed?  ...  F Because SMG is obviously keeping track of what has changed in order to do its minimal updates!   E I just want to have SMG$ change the rendition of all new data that it C would write to the screen with minimal update mode.  The problem is F that if I tell SMG to change rendition SMG thinks all data has changed6 *because* has changed so minimal update doesn't apply.   ------------------------------  % Date: Thu, 24 Apr 2003 21:36:48 -0400   From: John Santos <JOHN@egh.com>0 Subject: Re: how can you do this with SMG$ calls5 Message-ID: <1030424212437.2426A-100000@Ives.egh.com>    On 24 Apr 2003, JG wrote:   ] > hoff@hp.nospam (Hoff Hoffman) wrote in message news:<xdEpa.298$Ys4.202@news.cpqcorp.net>... j > > In article <dd3f0cb7.0304231354.67818227@posting.google.com>, chessmaster1010@hotmail.com (JG) writes: > >  > > K > > :My question is: Is there a way to tell SMG$ to do this "highlight only H > > :the changed areas" itself?  If I change the default rendition afterI > > :the first pass it repaints the entire SMG$PUT_LINE output in the new  > > :rendition.  > > . > >   How would SMG know what is changed?  ... > H > Because SMG is obviously keeping track of what has changed in order to > do its minimal updates!  > G > I just want to have SMG$ change the rendition of all new data that it E > would write to the screen with minimal update mode.  The problem is H > that if I tell SMG to change rendition SMG thinks all data has changed8 > *because* has changed so minimal update doesn't apply.  A I think you need to rethink this.  What does "changed" mean?  For @ minimal updating, suppose you are displaying a counter.  Say theB value changes from "14905" to "14925".  Minimal update would be toC cursor postion to the 4th character, and overpaint a "2".  However, ? what you probably want to do is highlight the entire field, not B just the set of characters within it that have changed.  (The sameF applies to a text field: e.g.  changing "ON" to "OFF" should highlight# the whole word, not just the "FF".)   A So I don't think that depending on minimal updating would do what / you want, even if it had the appropriate hooks.   B I think you need to keep track of each displayed field, and change the renditions.   F If you are using SMG$PUT_LINE, and your data elements are not actuallyC lines of text (i.e. you are constructing the lines by concatenating > multiple separate items), then I think you are using the wrongF mechanism here.   (Are you trying to make minimal changes to a programB that previously just printed its status periodically to a hardcopyG terminal or dumb CRT?  If so, I understand that doing it right is a lot D more work, and you have to delve much deeper into the innards of theF program, but I think it's the only way to get the results you desire.)  @ I usually say "HTH", but I don't think this will help very much. Sorry.  :-(    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 24 Apr 2003 20:36 CDT ' From: carl@gerg.tamu.edu (Carl Perkins) # Subject: Re: HTML favourite editor? - Message-ID: <24APR200320361365@gerg.tamu.edu>   4 JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes... }Dirk Munk wrote: 7 }> A friendly word of advise: start using stylesheets !  } K }I disabled style sheet processing on my browser because too many site have M }misused style sheets to code font sizes, making fonts on browsers other than L }microsoft ones totally unreadable because too small. Don't use relative fonI }sizes because you don't know what the default font size is on the user's O }browser. By using a fixed point font size, you enuse the "small print" remains 7 }readable no matter what the browser's default font it.   K This is exactly backwards. Never use absolute font sizes. Only use relative I font sizes. To do otherwise means that somewhere between some and most of H the potential viewers of your site whon't be able to read it because you1 have set the font to a size that they can't read.   H If I set my browser to use the Large size font, it is because I want theJ bulk of the text to be the Large size. If you adjust it -1 size then I getI one size smaller. If you set it to the Small size then it is not one size B smaller, it is two sizes smaller and I may not be able to read it.  F Who are you to tell me what size the font should be on my screen? WhatJ makes you think I can read it at the size you are trying to make everybodyG use? How do you know what size monitor I am using? How do you know what & resolution I am using on that monitor?  J You have made the standard "moron web designer" error of assuming that theK size and resolution of your monitor (and your visual acuity) is the same as K that of all the people looking at your website. This is stupid. This is why K you should never, ever, use absolute font sizes (well, not for anything you 5 want to be certain people can actually read, anyway).   I Only use relative. Absolute is bad. (You should also only adjust the size  slightly if at all possible.)    --- Carl   ------------------------------  % Date: Fri, 25 Apr 2003 01:32:06 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca># Subject: Re: HTML favourite editor? / Message-ID: <3EA8C854.BA5325CA@vl.videotron.ca>    Carl Perkins wrote: J > If I set my browser to use the Large size font, it is because I want theL > bulk of the text to be the Large size. If you adjust it -1 size then I get > one size smaller.    Smaller than what ?   L The problem is that the mocrosoft software comes, by default, with a sandardL font size that is way too big. So many web designers code "normal" text with@ -1 or 02 as font for regular text, and -3 for even smaller text.  L They should code normal text with +0 , small text with -1. And let MicrosoftK users go to their preferences and set the default vfont size to be smaller.   M If I specify I want text in 12 point sans-serif, it will come out as 12 point ( no matter what the default font size is.  H Remember, those who specify a font size do so because they want specific layouts on a screen.N I have no objection to positive font size increments. But I object to negative9 ones because all too often, it makes the page unreadable.   D www.microsoft.com is a perfect example. went there today to downloadN powerpoint viewer for my nephew on his mac. He was susprised at the text and II explained that microsoft doesn't follow standards and its web site is all L screwed up. Went to netscape to disable style sheets and javascript and javaW (to be sure microsoft would attempt anything bad) and the site was then fully readable.   C > Who are you to tell me what size the font should be on my screen?   K Those who want specific page/text layouts on a screen are the ones who want K specific text sizes. Not me. The problem is that those who don't test their K pages on other non-microsoft browsers don't realise that the way they coded L their pages makes them unreadable because they assumed that everyone has the$ same default font size as microsoft.    L > makes you think I can read it at the size you are trying to make everybody > use?  J And what makes you think that "-1" makes text that is readable to everyone8 because you feel that +0 is way too big on your screen ?  D > How do you know what size monitor I am using? How do you know what( > resolution I am using on that monitor?  P And how do you know that +1 or -1 will render a font properly on your platform ?  N If they truly want to make their text readable, they simply won't specify fontN sizes, this way, they know that the text will be readable on every browser andL won't override user preferences. But the fact is that too many web designersJ insist on overriding those preferences and setting different font sizes to make their pages look cool.    ------------------------------  % Date: Thu, 24 Apr 2003 14:33:41 -0400 & From: "Bob  Lail" <robert.lail@hp.com>Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly , Message-ID: <3ea830fc$1@usenet01.boi.hp.com>  K Before this degrades into another bash HP for not providing a way to report L security issues, check out the following url:, and note the email address onI that web page. This email goes to the HP SSRT (Software Security Response J Team) which includes the same folks who have been doing it for OpenVMS andK Tru64 UNIX since the days when these fine OSs where the property of Digital H Equipment Corp. SSRT now covers ALL of HP's in house developed software.  5 http://www.hp.com/country/us/eng/sftware_security.htm   A For those that want immediate gratification the email address is:    security-alert@hp.com   	 \Bob Lail      --   Robert Lail  Solution Architect  Network & Service Provider Sales0 EMail: SRobert.Lail@hp.com   Phone: 603.884.71613 ( S added for Spammers remove before sending email)     8 "David Webb" <david20@alpha1.mdx.ac.uk> wrote in message% news:b86fm6$f9j$1@aquila.mdx.ac.uk... K > In article <jLKH9blNIshA@eisner.encompasserve.org>, Kilgallen@SpamCop.netu (Larry Kilgallen) writes: G > >In article <b860e1$dls$2@aquila.mdx.ac.uk>, david20@alpha2.mdx.ac.ukl (David Webb) writes:8 > >> In article <IOeaQf5StnCw@eisner.encompasserve.org>,/ Kilgallen@SpamCop.net (Larry Kilgallen) writes:sJ > >>>In article <b85qca$l34$3@bob.news.rcn.net>, jmfbahciv@aol.com writes: > >>> C > >>>> AFAICT, the current reporting mechanisms are a shambles witha > >>>> high security problems. > >>>lG > >>>That is not my impression.  Security bulletins still come from thenF > >>>same fellow in Colorado who has been designated in the past to be> > >>>sent incoming problem reports from non-support customers. > >>G > >> In these days of hobbyist systems that needs to be publicised morec fullyM) > >> ie Exact contact details rather thand > >>K > >> "the same fellow in Colorado who has been designated in the past to ber> > >> sent incoming problem reports from non-support customers" > >nE > >In these days of spam, I think it unwise to post the email addresso- > >of an individual without their permission.t > > B > >But if you would trust my word for the email address, you couldC > >always email me when you found a problem and I would provide thesF > >address.  (If you emailed me now, I would have to find the address,8 > >which would waste my time if you had no problem now.) > >tE > >Trusting me, however, might not be a good idea, so you could emailrG > >one of the various folk from VMS Development who post here from timeG. > >to time (again, when you have the problem). >aL > I don't personally have any problem to raise (and since my machines are onI > support contract I'd use the official channels). Others without supportr? > contracts do need a simple method of reporting such problems.lL > JF Mezei wrote that he had such a problem with XDM (no auditing of invalid* > attempts, no breakin detection/evasion). >MH > Although the informal approach of posting to VMS development folks who postI > here is a reasonable solution for veterans of this newsgroup. Newcomersn will bea. > left trying to work out who to send mail to.L > It would be much better to have a formal reporting email address (or otherK > method) not associated with any particular person but open to anyone withd or > without a support contract.s >e >  > David Webb > VMS and Unix team leader > CCSS > Middlesex University   ------------------------------  # Date: Thu, 24 Apr 2003 19:26:45 GMTU) From: Charles Richmond <richmond@ev1.net>oQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly-' Message-ID: <3EA85608.AF0159B9@ev1.net>-   jmfbahciv@aol.com wrote: > 4 > In article <8781.244T81T1063202@kltpzyxm.invalid>,5 >    "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote:c > <snip story> > / > Beautiful.  That's two that have made my day.  > A > Those poor operators...if I had been one of them, I would beginnA > to believe in devils and machines turning on their creators ando > stuff. > ? > It is certainly is a golden rule that thou shalt not piss offr0 > a bit god after he's been reasonable with you. > > > When a duo of bit gods decide to do mischief, not only is it= > hilarious..well, after the bits settle down...but their bitb > hosing is thorough.s > < For those who really liked this story, you might like a bookD (that has this story and many others) titled _The Devouring Fungus_.C It comes from circa 1990, and is full of computer folklore stories. D One I particularly liked was about John Backus (of FORTRAN fame) andA what he found to be the reason that employees were showing up so   early for work every morning.L   --B +----------------------------------------------------------------+B |   Charles and Francis Richmond     richmond at plano dot net   |B +----------------------------------------------------------------+   ------------------------------  # Date: Fri, 25 Apr 2003 00:08:20 GMTT* From: genew@mail.ocis.net (Gene Wirchenko)Q Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopolyu- Message-ID: <3ea848d0.11258991@news.ocis.net>k  , david20@alpha2.mdx.ac.uk (David Webb) wrote:   [snip]  K >You tell them that there is a serious problem with xxxx and that they musteN >apply this fix but you do NOT go into the exact details of the problem and inG >particular you DO NOT (as many of the security lists unfortunately do)  >publicise an example exploit. t  A      Great.  I (and other I expect) have been receiving so-calledfC security fixes purportedly from Microsoft.  They do not go into the0B details of the vulnerabilities.  On this basis, I should run them?        NO!  0      "Run this program, because I tell you to."?        NO!  
 Sincerely,   Gene Wirchenko  ' Computerese Irregular Verb Conjugation:       I have preferences.      You have biases.o      He/She has prejudices.w   ------------------------------  # Date: Fri, 25 Apr 2003 03:21:11 GMT ' From: CBFalconer <cbfalconer@yahoo.com>tQ Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM monopoly ) Message-ID: <3EA8A7D5.BFB7DA2E@yahoo.com>e   Charles Richmond wrote:  >  ... snip ... > >e> > For those who really liked this story, you might like a bookF > (that has this story and many others) titled _The Devouring Fungus_.E > It comes from circa 1990, and is full of computer folklore stories.oF > One I particularly liked was about John Backus (of FORTRAN fame) andB > what he found to be the reason that employees were showing up so > early for work every morning.h  A That sounds vaguely familiar, but the associative memory seems to.7 have dropped some bits or expired.  So I'll bite - why?    --  < Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net);    Available for consulting/temporary embedded and systems.g:    <http://cbfalconer.home.att.net>  USE worldnet address!   ------------------------------  % Date: Thu, 24 Apr 2003 11:25:45 -0700@+ From: "Barry Treahy, Jr." <Treahy@MMaz.com> ? Subject: Re: OpenVMS Itanium port progressing well says Gorham!w' Message-ID: <3EA82C29.9020502@MMaz.com>    Phillip Helbig wrote:a  E >>>One of the improvements that customers have wanted/needed most and"I >>>asked for persistently for many years is the ability for VMS to run ontI >>>industry-standard hardware.  Having that capability will be well worthn! >>>some short-term inconvenience.r	 >>>      f >>>nJ >>Just because it looks and smells like VMS running on a PC, doesn't mean G >>that HP is going to make it so.  Past experience with Compaq/DEC has  H >>been that VMS will only dance well (or at all) with the hardware that G >>HP/Compaq/DEC choose to code VMS to support.  Additionally, there is  I >>nothing to stop them from coding requirements for custom BIOS's in the  H >>various hardware components that require you to use the HP variant of , >>that Adaptec controller, or ATI adapter... >>     >> > I >Obviously, HP will not SUPPORT VMS on bargain-basement hardware.  On themH >other hand, Hoff has stated here quite unequivocally that there will beC >no intentional goodies to tie VMS to HP hardware, prevent VMS fromeF >running on specific hardware (even from HP) etc---though these things5 >have happened in the past (the "NT only" machines).   >oH I respect Hoff's opinion as well as his technical contributions, but is I he the official mouth piece of HP on this matter?  Can his statements be S; taken to the bank and HP held on that point?  Probably not.     B Additionally, even IF there are no intentional bindings of VMS to 9 specific chipsets, controllers, adapters, for VMS to run F 'industry-standard' hardware as in the quote I original commented on, I they have a giant laundry list of devices to write drivers for.  So this  A still returns us full-circle in that VMS may run on the specific SF hardware HP dictates and not that hardware which I choose (even if it ( isn't bargain-basement gear as you say).   {major snip}  E As for the days gone by of Digital, I generally have no disagreement lG with you on that matter but they too botched it with the Pro, Rainbow, pE VAXmate, TU58's, BI and the NT only Alphas for recent just to name a nF couple...  At the time, except perhaps BI, everything was going to be   part of the 'industry standard.'     Barryo   -- o  @ Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028a   ------------------------------  + Date: Thu, 24 Apr 2003 20:37:05 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>I? Subject: Re: OpenVMS Itanium port progressing well says Gorham! ; Message-ID: <01KV4A8YPDY4A9SJ2F@sysdev.deutsche-boerse.com>   I > I respect Hoff's opinion as well as his technical contributions, but is J > he the official mouth piece of HP on this matter?  Can his statements be> > taken to the bank and HP held on that point?  Probably not.   @ I agree.  On the other hand, I don't think he would make such a F statement if he weren't pretty sure it is true, even if he is not the I official spokesman and even if it is not legally binding.  Of course, in hG the past, official statements have NOT turned out to be true, so being u/ non-official is not necessarily a disadvantage.a  C > Additionally, even IF there are no intentional bindings of VMS to: > specific chipsets, controllers, adapters, for VMS to runG > 'industry-standard' hardware as in the quote I original commented on,aJ > they have a giant laundry list of devices to write drivers for.  So thisB > still returns us full-circle in that VMS may run on the specificG > hardware HP dictates and not that hardware which I choose (even if it + > isn't bargain-basement gear as you say). l  H That might be true.  On the other hand, what is the goal?  HP obviously I can't support every possible configuration.  I'm sure that it's a lot of  F work to support all the possible combinations of hardware and softwareH (multiply that a few times when mixed-architecture and/or mixed-version H clusters are considered) they support now.  The alternative, I suppose, E is to have some sort of open standard for various widgets etc, which y; might lead to a least-common-denominator type of situation.2   ------------------------------  # Date: Thu, 24 Apr 2003 19:32:47 GMTa& From: Rick Jones <foo@bar.baz.invalid>? Subject: Re: OpenVMS Itanium port progressing well says Gorham! / Message-ID: <zZWpa.372$fr5.69@news.cpqcorp.net>r  1 JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote:iD > I don't recall the exact name, but it was discussed in some of theE > benchmarks comparing IA64 with others since the benchmarks had beenb; > made on HP hardware which ahs a proprietary HP developped C > "accelerator" chip added to the motherboard, and that it was withi< > compilers who made use of that chip that they achieved theD > results. (meaning that a vanilla IA64 from Dell wouldn't have that+ > chip and thus woudl not perform as fast)..  E I suspect there is some confusion there.  If I were to guess, someonelE has taken the statments about the benefits of the HP zx1 chipset over F other possible IPF chipsets and how it is better/stronger/faster/leapsE taller buildings in fewer bounds/etc and mistakenly morphed that intomD its being an "accelerator chip" like it was some sort of coprocessor
 or something.   
 rick jones -- <G oxymoron n, commuter in a gas-guzzling luxury SUV with an American flagdF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...o   ------------------------------  % Date: Thu, 24 Apr 2003 13:43:32 -0400s( From: David Froble <davef@tsoft-inc.com>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!r, Message-ID: <3EA82244.1020008@tsoft-inc.com>   John Gemignani, Jr. wrote:  ? > "JF Mezei" <jfmezei.spamnot@vl.videotron.ca> wrote in messager+ > news:3EA79EBD.32D22406@vl.videotron.ca...  >  >>Bob Ceculski wrote:o >>0 >>>sounds like things are progressing nicely ... >>>i< >>>http://www.openvms.org/stories.php?story=03/04/23/7476808 >>>.L >>Meanwhile, the much needed changes, improvements, fixes to the TCPIP stackF >>have to be postponed by how many months/years because resources were >> > allocated  > + >>to the unwanted port to that IA64 thing ?m >>F >>If their attention had not been diverted to that IA64 port, how much >>	 > quickero > E >>woudl VMS have obtained the improvements that customers want/need ?8 >> > $ > Where do you get your information? > * > In the words of Muhammed Saeed al-Sahaf: > ; >     "I now inform you that you are too far from reality."i >  > L >>I don't think that anyone ever doubted that VMS engineer's ability to port >> > VMSn > L >>to that IA64 thing. But there are still doubts oin whether that IA64 thingH >>will be commercially viable or whether it will become a chore Intel is >> > forced > 2 >>to continue doing because of its promises to HP. >> > K > Consider this:  Vaxes are gone, Alpha will eventually be gone.  When were)F > YOU planning to move from your VAX with VMS to ~something else~ with > Windows or Unix?    J Planning on doing so, well, I have no such plans.  Doesn't mean I'm being O reasonable.  However, if 147 respondents to a poll mean anything, then I'm not j@ alone.  Somehow I doubt that HP cares much about their own poll.  	 <from HP>sN With the continued development of the Alpha processor to EV79 technology from " the current EV7 and EV68 will you:  N purchase new AlphaServer systems through 2005 and beyond before transition to  IA64? -  76, 51.7%I purchase new AlphaServer systems until you have re-evaluated your server h strategy? -  37, 25.2%I switch new server purchases to another HP platform not listed? -  6, 4.1%s; switch new server purchases to another vendor? -  19, 12.9%k7 switch new server purchases to HP-UX on IA64 -  5, 3.4% L switch new server purchases to other HP platforms running Linux? -  4,  2.7%	 Total 147o
 </from HP>  N So, 75% are staying with Alpha as long as they can do so.  Not everyone needs N the latest hardware, so some of these people may still be using Alpha VMS for J many years.  Still, software vendors will not be there, nor other support O services.  Unless something unforseen happens, their ultimate choices are dump eL VMS or VMS on something else (IA-64 for now).  But, only 10% indicated they I would stay with HP short term.  75% will stick with Alpha, until another -O decision is made.  51% say that direction will be VMS on IA-64, but there's no lJ IA-64 revenue for years, and things could change for those people over an  extended number of years.e  L If this poll means anything to HP, then HP should be rather worried.  If it ? doesn't mean anything to HP, then why did they spam me with it?e   Dave   -- o4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Thu, 24 Apr 2003 14:16:14 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!t/ Message-ID: <3EA829EC.9353DB7F@vl.videotron.ca>o   Keith Parris wrote:)G > Today, it is very likely that Intel has the clout to make Itanium then > next CPU ISA standard.  L If Intel slows down 8086 development to allow IA64 to become Intel's fastestW processor, then Intel gets beaten up by the true industry standard 8086 Opteron/Hammer.h  J IA64 has nothing of the "industry standard" attributes. It isn't cheap. ItK isn't widely available. And to fill some of HP's performance goals, HP muste$ add soem PROPRIETARY hardware to it.  N the owners of VMS would have done much better to listen to their own engineersK who kept telling customers how flawed the IA64 architecture was and how itsiN core design would make it very difficult for intel to keep pace with Alpha andM others.  Had they kept Alpha until IA64 had proven its worth, then opposition-% to moving to IA64 woudln't be so bad.p   ------------------------------  % Date: Thu, 24 Apr 2003 14:07:57 -0400r0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!r/ Message-ID: <3EA827FB.F69D2C22@vl.videotron.ca>l   "John Gemignani, Jr." wrote:K > Consider this:  Vaxes are gone, Alpha will eventually be gone.  When wereiF > YOU planning to move from your VAX with VMS to ~something else~ with > Windows or Unix?  J Consider this: Had they not killed Alpha, how much further ahead would VMSN have been today, and how much further ahead VMS would have bveen 1 and 2 yearsN down the road with the resources allocated to improvements instead of a port ?  N The port should be viewed as a necessary evil caused by a mistaken decision toG kill alpha. It should not be viewed as something good for VMS. There iseJ nothing outstanding about IA64, nothing that will give VMS a technologicalK edge over competitors such as HP-UX or Tandem, something it had with Alpha.   M The killing of alpha also killed confidence levels in any commitments made by H the owner. HP, as a corporation, has yet to show real commitment to VMS,M starting with the months between announcement and consumation of merger whereaJ the letters "VMS" were avoided like the plague, with Scott Stallard's memoD stating that HP expects VMS customers to migrate to HP-UX over time,N statements that HP will not market VMS under the excuse that no specific OS isD to be marketed, but we see marketing for those other OS etc etc etc.  M The only "hope" is that things might truly change once/if VMS is commercially M available on tbat IA64 thing since Intel may start to force HP to mention VMSeK in its ads and press releases since Intel supposedly paid for the port. But.H until this happens, if it happens, there is no way one can consider HP'sL commitment to be credible, and HP's management of VMS continues to be judged" by its actions since June 25 2001.   ------------------------------  % Date: Thu, 24 Apr 2003 14:19:21 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>? Subject: Re: OpenVMS Itanium port progressing well says Gorham! / Message-ID: <3EA82AA7.C377BF63@vl.videotron.ca>o   Phillip Helbig wrote: J > Obviously, HP will not SUPPORT VMS on bargain-basement hardware.  On theI > other hand, Hoff has stated here quite unequivocally that there will be D > no intentional goodies to tie VMS to HP hardware, prevent VMS from2 > running on specific hardware (even from HP) etc-  M Is that still the case ? I was under the impression that he admitted that VMS L is being built/compiled on the assumption that the HP additional proprietary hardware was present.,   ------------------------------  % Date: Thu, 24 Apr 2003 11:26:44 -0700-9 From: "gregc at gregcagle.com" <"gregc at gregcagle.com">1? Subject: Re: OpenVMS Itanium port progressing well says Gorham!c/ Message-ID: <vagb3gi0o2pk63@corp.supernews.com>    JF Mezei wrote:s > Phillip Helbig wrote:@ > J >>Obviously, HP will not SUPPORT VMS on bargain-basement hardware.  On theI >>other hand, Hoff has stated here quite unequivocally that there will beeD >>no intentional goodies to tie VMS to HP hardware, prevent VMS from2 >>running on specific hardware (even from HP) etc- >  > O > Is that still the case ? I was under the impression that he admitted that VMSiN > is being built/compiled on the assumption that the HP additional proprietary > hardware was present.e  ? What "proprietary hardware" are you specifically talking about?e -- a
 Greg Cagle gregc at gregcagle dot com   ------------------------------  % Date: Thu, 24 Apr 2003 14:48:40 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!r/ Message-ID: <3EA83183.4A0E8077@vl.videotron.ca>,   "gregc at gregcagle.com" wrote:hA > What "proprietary hardware" are you specifically talking about?   M I don't recall the exact name, but it was discussed in some of the benchmarks L comparing IA64 with others since the benchmarks had been made on HP hardwareE which ahs a proprietary HP developped "accelerator" chip added to theiJ motherboard, and that it was with compilers who made use of that chip thatJ they achieved the results. (meaning that a vanilla IA64 from Dell wouldn't3 have that chip and thus woudl not perform as fast).l   ------------------------------  % Date: Thu, 24 Apr 2003 22:32:41 +0200o6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!A) Message-ID: <3EA849E9.3050106@vajhoej.dk>    JF Mezei wrote:iL > IA64 has nothing of the "industry standard" attributes. It isn't cheap. ItM > isn't widely available. And to fill some of HP's performance goals, HP mustl& > add soem PROPRIETARY hardware to it. > P > the owners of VMS would have done much better to listen to their own engineersM > who kept telling customers how flawed the IA64 architecture was and how itseP > core design would make it very difficult for intel to keep pace with Alpha andO > others.  Had they kept Alpha until IA64 had proven its worth, then opposition ' > to moving to IA64 woudln't be so bad.p  6 Whther that is true or not, then I am pretty sure that< it would not be possible to restart Alpha again (for various$ market, legal and financial reaons).  5 So if we accept that, then the most relevant issue ise9 how soon will VMS on Itanium be available, how compatiblet7 will it be, how fast will Itanium be and how cheap will  it be.  6 I think that we all agree that Bob Palmer made som big2 mistakes 10 years ago. But they can not be undone.1 And as such they are irrelevant for VMS's future.  It is history.   Arne   ------------------------------  % Date: Thu, 24 Apr 2003 14:39:45 -0700a9 From: "gregc at gregcagle.com" <"gregc at gregcagle.com"> ? Subject: Re: OpenVMS Itanium port progressing well says Gorham!c/ Message-ID: <vagmded16unsf9@corp.supernews.com>i   Rick Jones wrote: 3 > JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote:/ > D >>I don't recall the exact name, but it was discussed in some of theE >>benchmarks comparing IA64 with others since the benchmarks had beena; >>made on HP hardware which ahs a proprietary HP developped C >>"accelerator" chip added to the motherboard, and that it was withn< >>compilers who made use of that chip that they achieved theD >>results. (meaning that a vanilla IA64 from Dell wouldn't have that+ >>chip and thus woudl not perform as fast).e >  > G > I suspect there is some confusion there.  If I were to guess, someonerG > has taken the statments about the benefits of the HP zx1 chipset overcH > other possible IPF chipsets and how it is better/stronger/faster/leapsG > taller buildings in fewer bounds/etc and mistakenly morphed that intoeF > its being an "accelerator chip" like it was some sort of coprocessor > or something.0  C Could be - I've never heard of such a thing as JF describes and I'mh@ pretty well versed in Itanium system architecture. Certainly the> chipset is going to have an effect on performance, but I don't& think that's what JF is talking about.   --  
 Greg Cagle gregc at gregcagle dot com   ------------------------------  % Date: Thu, 24 Apr 2003 19:53:45 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!n. Message-ID: <3EA878EC.DCA5D14@vl.videotron.ca>  M Here is a snippet from a VMS engineer from Google (Initials are F D and isn't " Fire Dumpster) (november 22 2002).  K "[Note: There *may* be some issues short term.  For instance, Alpha drivers H often assume that that map registers are available.  The Intel referenceH platform, for example, doesn't have map registers.  So 32-bit devices onI systems with more than 4Gb are problematic - as are drivers that *always* J use map registers.  At minimum, those drivers need to change, and that mayJ take a while to happen -- since the HP platforms *do* have map registers -2 it isn't a high priority for the early releases.]"    K Yes, this was in a context where the above not-mentioned engineer said thatmL they had no intentions of tying VMS to HP systems and making it generic. ButH teh above paragraph does show that the VMS will, at least initially, use HP-specific hardware.7   ------------------------------  # Date: Fri, 25 Apr 2003 00:19:02 GMT & From: Rick Jones <foo@bar.baz.invalid>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!t0 Message-ID: <W9%pa.393$0I5.282@news.cpqcorp.net>  1 JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote: E > Here is a snippet from a VMS engineer from Google (Initials are F Da. > and isn't Fire Dumpster) (november 22 2002).  E > "[Note: There *may* be some issues short term.  For instance, AlphasB > drivers often assume that that map registers are available.  TheD > Intel reference platform, for example, doesn't have map registers.F > So 32-bit devices on systems with more than 4Gb are problematic - asA > are drivers that *always* use map registers.  At minimum, those F > drivers need to change, and that may take a while to happen -- sinceE > the HP platforms *do* have map registers - it isn't a high priority  > for the early releases.]"   B Sounds like I/O TLB support. Map the 64-bit processor address to aF 32-bit I/O address so the 32-bit addressing device can access the data? without having to copy it into <= 32-bit space. Indeed, that is A something in the zx1 chipset that might not be in other chipsets.aF However, that isn't any sort of "accelerator chip" or coprocessor, but" a bit of functionality in the CEC.  C > Yes, this was in a context where the above not-mentioned engineeroA > said that they had no intentions of tying VMS to HP systems andfC > making it generic. But teh above paragraph does show that the VMSa5 > will, at least initially, use HP-specific hardware.i  E Features that are known to be in the HP chipsets, but not necessarilyt' precluded from being in other chipsets.g  
 rick jones --  G oxymoron n, commuter in a gas-guzzling luxury SUV with an American flagtF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...u   ------------------------------    Date: 24 Apr 2003 19:21:45 -0700( From: bob@instantwhip.com (Bob Ceculski)? Subject: Re: OpenVMS Itanium port progressing well says Gorham!l< Message-ID: <d7791aa1.0304241821.b17c807@posting.google.com>  T Arne Vajhj <arne@vajhoej.dk> wrote in message news:<3EA849E9.3050106@vajhoej.dk>... > JF Mezei wrote:rN > > IA64 has nothing of the "industry standard" attributes. It isn't cheap. ItO > > isn't widely available. And to fill some of HP's performance goals, HP musto( > > add soem PROPRIETARY hardware to it. > > R > > the owners of VMS would have done much better to listen to their own engineersO > > who kept telling customers how flawed the IA64 architecture was and how itstR > > core design would make it very difficult for intel to keep pace with Alpha andQ > > others.  Had they kept Alpha until IA64 had proven its worth, then oppositionu) > > to moving to IA64 woudln't be so bad.y > 8 > Whther that is true or not, then I am pretty sure that> > it would not be possible to restart Alpha again (for various& > market, legal and financial reaons). > 7 > So if we accept that, then the most relevant issue ist; > how soon will VMS on Itanium be available, how compatibleo9 > will it be, how fast will Itanium be and how cheap willu > it be. > 8 > I think that we all agree that Bob Palmer made som big4 > mistakes 10 years ago. But they can not be undone.3 > And as such they are irrelevant for VMS's future.o > It is history. >  > Arne  3 I say the mistakes Palmer made were intentional ...n   ------------------------------  % Date: Fri, 25 Apr 2003 01:02:02 -0400e  From: John Santos <JOHN@egh.com>? Subject: Re: OpenVMS Itanium port progressing well says Gorham!h5 Message-ID: <1030425004813.2426A-100000@Ives.egh.com>e  & On Fri, 25 Apr 2003, Rick Jones wrote:  3 > JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote: G > > Here is a snippet from a VMS engineer from Google (Initials are F D 0 > > and isn't Fire Dumpster) (november 22 2002). > G > > "[Note: There *may* be some issues short term.  For instance, AlphaeD > > drivers often assume that that map registers are available.  TheF > > Intel reference platform, for example, doesn't have map registers.H > > So 32-bit devices on systems with more than 4Gb are problematic - asC > > are drivers that *always* use map registers.  At minimum, thoselH > > drivers need to change, and that may take a while to happen -- sinceG > > the HP platforms *do* have map registers - it isn't a high priorityc > > for the early releases.]"  > D > Sounds like I/O TLB support. Map the 64-bit processor address to aH > 32-bit I/O address so the 32-bit addressing device can access the dataA > without having to copy it into <= 32-bit space. Indeed, that isiC > something in the zx1 chipset that might not be in other chipsets. H > However, that isn't any sort of "accelerator chip" or coprocessor, but$ > a bit of functionality in the CEC. > E > > Yes, this was in a context where the above not-mentioned engineerxC > > said that they had no intentions of tying VMS to HP systems and E > > making it generic. But teh above paragraph does show that the VMSe7 > > will, at least initially, use HP-specific hardware.s > G > Features that are known to be in the HP chipsets, but not necessarilym) > precluded from being in other chipsets.e >  > rick jones > --  I > oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag H > these opinions are mine, all mine; HP might not want them anyway... :)C > feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...f  @ I am certainly not an expert in this are, but I believe this hasA to do with 32-bit vs. 64-bit PCI devices.  64-bit PCI devices canIA do DMA to/from the full 64-bit address space.  32-bit PCI deviceseB need to either use buffers in the low part of the address space orB need some kind of mapping assistance to map the 32-bit PCI address@ space into the full 64-bit IPF (or Alpha) address space.  The HP@ chipset supports this, and VMS (at least in the initial version)@ only supports the HP chipset's way of doing this.  So you need aA motherboard with the HP chipset.  But this only applies to 32-bithB PCI cards.  64-bit PCI cards address all of memory without special assistance.    So the restrictions are either:   E 1) Use only 64-bit PCI cards.  (I think lots of these are available.)r  9 2) Use an HP motherboard with the HP chipset.  (From HP.)r  ? 3) Use a third-party motherboard with the HP chipset.  (I don't / know if any of these are or will be available.)a  ? 4) Use a third-party motherboard with a third-part chipset thatu" emulates the HP chipset.  (Ditto.)   or ...  A 5) Use 4GB of memory or less, so no 32->64 bit mapping is needed.u  C By keeping to restrictions 1 or 5, you should be able to use a Dellf or other non-HP Itanium.   Is this correct?   -- m John Santosc Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 24 Apr 2003 13:27:09 -0400t( From: David Froble <davef@tsoft-inc.com> Subject: Re: Oracle & OpenVMSe, Message-ID: <3EA81E6D.8070108@tsoft-inc.com>   David M Smith wrote:  G > On Thu, 24 Apr 2003 06:41:10 GMT, peter@langstoeger.at (Peter 'EPLAN'  > LANGSTOEGER) wrote:b >  > n >>In article <eb8f4d7b.0304231315.113e2282@posting.google.com>, vinit.adya@mizuhocbus.com (Vinit Adya) writes: >>B >>>We are running 8.1.7.4.0 on 7.2-1 and TCP/IP 5.0A ECO2. We haveG >>>problems with BGn: devices. Tcpip fails to deallocate the BG devicesiF >>>and finally we run out out the BGn: devices (VMS 7.2 has a limit ofG >>>10000).Oracle *pmon process seem to own thousands of them. Only wasy ! >>>to recover is shutdown Oracle.e >>>aD >>>There is a fix for the problem in TCPIP V5.1 ECO4. VMS upgared to >>>7.2-2 is recomemded.p >>>T >>Can you elaborate on this ?eP >>The 10k BG device limit is said to fall with TCPIP V5.4 (Q4/2003 with V7.3-2).P >>How can TCPIP V5.1 ECO 4 on VMS V7.2-2 help here. Does it also fix the limit ? >> > R > I looked in the ECO summary for TCP/IP V5.1 ECO 4, and found an item that sounds" > like what Vinit is referring to: >  > ECO 2 updates1 > --------------' > ECO L   2-APR-2001      Alpha and VAX  >  >         Images:@ > : >         TCPIP$INETACP.EXE                       V5.1-15L >  >         Problem: > B >         When a Server process created for a Listen service exitsC >         we fail to detect the process termination.  This can leaddF >         to undeleteable BG devices hanging around as well as hanging >         client processes.g    O I have to wonder whether this always happens, or only when a programmer counts oQ on process rundown to delete the socket.  If closing the socket works correctly, r5 then this is an effect of poor programming practices.i  N Even so, even exit handlers cannot withstand the 'big hammer' of STOP/ID=, so ' the fix is both approariate and needed.o     >         Solution:i > E >         In the routine PROCESS_CREATE_LISTEN, we were not using themD >         proper termination mailbox in most cases.  A simple fix to, >         this routine resolves the problem. >  >         Reference: > 7 >         PTR 70-5-1632 / CFS.82526 / Req Id: MGO67116An > K > Is this it? If so, Peter, it doesn't lift the restriction on number of BG L > devices but corrects a problem leading to a superfluity of BG devices on a > system for "old" processes.iK > -------------------------------------------------------------------------,K > David M. Smith 302.391.8533                       dsmit115 at csc dot comhK > Computer Sciences Corporation     (Opinions are those of the writer only) K > -------------------------------------------------------------------------  >    Dave   -- b4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   Date: 24 Apr 03 11:51:16 PST From: mckinneyj@cpva.saic.comt2 Subject: Re: Question on logical name PSM$ANNOUNCE( Message-ID: <TKxBGQo+G1Lt@cpva.saic.com>  ? In article <OFA6AF0B89.14B41132-ON85256D12.005D5D05@metso.com>,c  norm.raphael@metso.com writes:e > 6 > Question on logical name PSM$ANNOUNCE (/SYSTEM/EXEC) > G > I have this on my system and it changes the text in the middle of ther@ > top and bottom "ribbons" on the flag/burst page when printing. > ; > Is this an OpenVMS construct or something added by a pastrD > system manager?  I suspect it is standard, but I could not find itF > in the online documentation (which does not mean it's not in there). >  > -Normn > @ 	Standard, been there at least back to VMS V4 or so and probably 	earlier but I don't recall.   ------------------------------  % Date: Thu, 24 Apr 2003 15:22:24 -0400R From: norm.raphael@metso.com2 Subject: Re: Question on logical name PSM$ANNOUNCE? Message-ID: <OF04A33837.71CAE16B-ON85256D12.006A6379@metso.com>   5 Thanks, now where is it in the documentation, please?   5 From:  mckinneyj@cpva.saic.com on 04/24/2003 03:51 PMi  ) Please respond to mckinneyj@cpva.saic.coma   To:    Info-VAX@Mvb.Saic.Com cc:e  5 Subject:    Re: Question on logical name PSM$ANNOUNCEb    ? In article <OFA6AF0B89.14B41132-ON85256D12.005D5D05@metso.com>,.  norm.raphael@metso.com writes:e >u6 > Question on logical name PSM$ANNOUNCE (/SYSTEM/EXEC) >eG > I have this on my system and it changes the text in the middle of thef@ > top and bottom "ribbons" on the flag/burst page when printing. > ; > Is this an OpenVMS construct or something added by a pastlD > system manager?  I suspect it is standard, but I could not find itF > in the online documentation (which does not mean it's not in there). >l > -Normu > C              Standard, been there at least back to VMS V4 or so andf probably(              earlier but I don't recall.   ------------------------------  % Date: Thu, 24 Apr 2003 15:39:05 -0400-< From: "Peter Weaver" <WeaverConsultingServices@sympatico.ca>2 Subject: Re: Question on logical name PSM$ANNOUNCE5 Message-ID: <b89egu$7mu9u$1@ID-141708.news.dfncis.de>-   norm.raphael@metso.com wrote: 7 > Thanks, now where is it in the documentation, please?0 >...  0 Chapter 14 of "OpenVMS System Manager's Manual."  > http://h71000.www7.hp.com/doc/731FINAL/6017/6017pro_062.html#b annerm   -- Peter Weaver Weaver Consulting Services Inc.t) Serving Southern Ontario/Western New York    ------------------------------    Date: 24 Apr 2003 12:21:21 -0500 From: briggs@encompasserve.org2 Subject: Re: Question on logical name PSM$ANNOUNCE3 Message-ID: <DbIQgOzmbYFz@eisner.encompasserve.org>n  ^ In article <OFA6AF0B89.14B41132-ON85256D12.005D5D05@metso.com>, norm.raphael@metso.com writes: > 6 > Question on logical name PSM$ANNOUNCE (/SYSTEM/EXEC) > G > I have this on my system and it changes the text in the middle of thel@ > top and bottom "ribbons" on the flag/burst page when printing. > ; > Is this an OpenVMS construct or something added by a pastcD > system manager?  I suspect it is standard, but I could not find it  > It's standard.  Not sure where (or if) it's documented though.   	John Briggs   ------------------------------    Date: 24 Apr 2003 15:10:38 -0500 From: briggs@encompasserve.org2 Subject: Re: Question on logical name PSM$ANNOUNCE3 Message-ID: <2VUCibUxmujP@eisner.encompasserve.org>D  ^ In article <OF04A33837.71CAE16B-ON85256D12.006A6379@metso.com>, norm.raphael@metso.com writes: > 7 > Thanks, now where is it in the documentation, please?a  E Well, the third hit on Yahoo with a search string of VMS PSM$ANNOUNCEf is:i  G http://www.itec.suny.edu/scsys/vms/OVMSDOC073/V73/6017/6017pro_060.htmll   	John Briggs   ------------------------------  # Date: Thu, 24 Apr 2003 20:21:11 GMTm4 From: brad@.gateway.2wire.net (Bradford J. Hamilton)2 Subject: Re: Question on logical name PSM$ANNOUNCE= Message-ID: <XGXpa.74794$gK.178194@rwcrnsc52.ops.asp.att.net>o  T In article <2VUCibUxmujP@eisner.encompasserve.org>, briggs@encompasserve.org writes:_ >In article <OF04A33837.71CAE16B-ON85256D12.006A6379@metso.com>, norm.raphael@metso.com writes:t >> E8 >> Thanks, now where is it in the documentation, please? > F >Well, the third hit on Yahoo with a search string of VMS PSM$ANNOUNCE >is: >uH >http://www.itec.suny.edu/scsys/vms/OVMSDOC073/V73/6017/6017pro_060.html >3
 >	John Briggs@  G That's funny - when you use the search function provided on the hp pagetO (openvms.compaq.com/doc) and attempt to search for PSM, you only get two hits -hK the Utility Routines Manual and the System Messages Companion Guide Manual.a  I Searching for PSM$ANNOUNCE, and all its variations (uppercase, lowercase,>* quoted, non-quoted) yields no hits at all.  G If the site maintainer is lurking, can something be done to improve the  "built-in" search engine?h  A _________________________________________________________________a0 Bradford J. Hamilton			"All opinions are my own"/ bMradAhamiPltSon@atMtAbi.cPoSm		"Lose the MAPS"o   ------------------------------  % Date: Thu, 24 Apr 2003 15:52:45 -0500a$ From: Lyle West <arf@ourtownusa.org>2 Subject: Re: Question on logical name PSM$ANNOUNCE- Message-ID: <3EA8084D.2EA5CB2@ourtownusa.org>l   norm.raphael@metso.com wrote:m > 7 > Thanks, now where is it in the documentation, please?t >  	V7.1 Utility Routines Manual " 	Print Symbiont Modification (PSM)   -- r   Lyle W. West  > Try ell with three dubya's and at with mninter arf net and use dot rather than arf  __   ------------------------------    Date: 24 Apr 2003 14:51:04 -0700. From: spamsink2001@yahoo.com (Alan E. Feldman)2 Subject: Re: Question on logical name PSM$ANNOUNCE= Message-ID: <b096a4ee.0304241351.14dbf657@posting.google.com>t  c norm.raphael@metso.com wrote in message news:<OFA6AF0B89.14B41132-ON85256D12.005D5D05@metso.com>...c6 > Question on logical name PSM$ANNOUNCE (/SYSTEM/EXEC) > G > I have this on my system and it changes the text in the middle of theh@ > top and bottom "ribbons" on the flag/burst page when printing. > ; > Is this an OpenVMS construct or something added by a pastfD > system manager?  I suspect it is standard, but I could not find itF > in the online documentation (which does not mean it's not in there). >  > -Normo    & Do you mean online HELP or online Web?  : Anyway, it is in my v6.2 "OpenVMS System Manager's Manual:D Essentials", section 13.8.7.1, (Understanding Banner Pages) Flag and Burst Pages    Disclaimer: JMHO Alan E. Feldmane   ------------------------------    Date: 24 Apr 2003 21:55:16 +0200' From: huber@mppmu.mpg.de (Joseph Huber)y Subject: Re: TCPIP_SSH EAK+ Message-ID: <wptLCT3HjYRI@vms.mppmu.mpg.de>a  m In article <3EA80EC9.5030508@mpi-muelheim.mpg.de>, Wolfgang Angenendt <angenendt@mpi-muelheim.mpg.de> writes:7G > I've installed OpenVMS 7.3, TCP/IP 5.3 and the SSH for OpenVMS (EAK).mI > The installation was ok, but the configuration of the SSH server and=20g > client has failed. > I > My SYS$LIBRARY:TCPIP$TEMPLATES.TLB does not contain the SSH2_CONFIG ande< > SSHD2_CONFIG files. When I create them manually, it works.$ > Can anyone send me this two files? >    It is in the release notes:hL  extract tcpip$templates.tlb_ssh (or similar name, I don't have access now),, copy it to sys$library:tcpip$templates.tlb .    -- yN Joseph "Sepp" Huber   mailto:joseph.huber@web.de   http://www.huber-joseph.de/   ------------------------------    Date: 24 Apr 2003 11:04:20 -0700! From: jude.malar@lycos.com (jude)i Subject: Thread Scheduling= Message-ID: <ac82ff94.0304241004.3947e6a2@posting.google.com>    Hello,  &     I am facing one strange problem . A My application has two process . The second process is creating aaC thread and it is executing ,a subroutine which does synchronous I/O D and it waits on a mutex conditional variable  . At the same time theF second process  is also executing a synchronous I/O call .  This pointF the created thread is going into running state and  the second process thread is in ready state .E    I couldn't able to understand the reason , of thread blocking .   u Can anyone explain .      --jude   ------------------------------  % Date: Thu, 24 Apr 2003 22:57:44 +0400b2 From: "Ruslan R. Laishev" <Laishev@StarLet.SPB.RU> Subject: Re: Thread Scheduling- Message-ID: <3EA833A8.2080105@StarLet.SPB.RU>n   VAX, Alpha ?    Linked with KERNEL & UPCALLS ?   jude wrote:a > Hello, > ( >     I am facing one strange problem . C > My application has two process . The second process is creating a E > thread and it is executing ,a subroutine which does synchronous I/OaF > and it waits on a mutex conditional variable  . At the same time theH > second process  is also executing a synchronous I/O call .  This pointH > the created thread is going into running state and  the second process > thread is in ready state .G >    I couldn't able to understand the reason , of thread blocking .   i > Can anyone explain . >      > --jude >      -- c Cheers, Ruslan.rD +---------------------pure personal opinion------------------------+2               Mobile: +7 (812) 116-3222/NMT/IMT-MCB     TKD (WTF) in Russia, St.-Petersburg - www.TaeKwonDo-WTF.SPb.RU0                  http://starlet.spb.ru/~laishev/   ------------------------------  # Date: Thu, 24 Apr 2003 18:07:25 GMTI& From: "John Hayes" <hayes1966@cox.net>$ Subject: Unwanted Broadcast messages: Message-ID: <xJVpa.149949$It5.53565@news2.central.cox.net>  , This is a multi-part message in MIME format.  + ------=_NextPart_000_000A_01C30A6A.F66F0D30t Content-Type: text/plain;e 	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printablei  I I have a terminal server running with terminal and printers on it. When =rB system shuts down it broadcasts messages to printers even though =, broadcast disabled on the port and terminal.  
 Port settingsm  ? Port  6:                               Server: LAT_0000F8F347302  F Character Size:            8           Input Speed:               9600F Flow Control:            DSR           Output Speed:              9600F Parity:                 None           Signal Control:        Disabled Stop Bits:           Dynamic  F Access:               Remote           Local Switch:              NoneF Backwards Switch:       None           Name:                    PORT_6F Break:                 Local           Session Limit:                4F Forwards Switch:        None           Type:                      AnsiF Default Protocol:        LAT           Default Menu:              NoneF Autolink Timer One:10 Two:10           Dialer Script:             None   Preferred Service: Nonet Authorized Groups:   0 (Current)  Groups:   0   Enabled Characteristics:D Failover,  Input Flow Control,  Lock,  Loss Notification,  Message = Codes," Output Flow Control,  Verification      Terminal settings are as follows  @ Terminal: _LTA3000:   Device_Type: LQP02         Owner: No Owner  B    Input:    9600     LFfill:  0      Width: 132      Parity: None0    Output:   9600     CRfill:  0      Page:   66   Terminal Characteristics: E    Interactive        Echo               No Typeahead       No Escapel?    No Hostsync        TTsync             Lowercase          TabdG    No Wrap            Hardcopy           No Remote          No EightbitdC    No Broadcast       No Readsync        Form               Fulldup B    No Modem           No Local_echo      No Autobaud        HangupE    No Brdcstmbx       No DMA             No Altypeahd       Set_speedpG    No Commsync        No Line Editing    Overstrike editing No FallbacktF    No Dialup          No Secure server   No Disconnect      No PasthruH    No Syspassword     No SIXEL Graphics  No Soft Characters No Printer = Port@    Numeric Keypad     No ANSI_CRT        No Regis           No =
 Block_modeG    No Advanced_video  No Edit_mode       No DEC_CRT         No DEC_CRT2r@    No DEC_CRT3        No DEC_CRT4        No DEC_CRT5        No =
 Ansi_Color    VMS Style Input $e     Any idea what I am missing ?  + ------=_NextPart_000_000A_01C30A6A.F66F0D30m Content-Type: text/html; 	charset="iso-8859-1"a+ Content-Transfer-Encoding: quoted-printablen  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =o charset=3Diso-8859-1">9 <META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR>y <STYLE></STYLE>a </HEAD>w <BODY>G <DIV><FONT face=3D"Courier New">I have a terminal server running with =l terminal and=20sB printers on it. When system shuts down it broadcasts messages to = printers even=20@ though broadcast disabled on the port and terminal.</FONT></DIV>3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV> : <DIV><FONT face=3D"Courier New">Port settings</FONT></DIV>1 <DIV><BR><FONT face=3D"Courier New">Port&nbsp;=20 J 6:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=J ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=' &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20l% Server: LAT_0000F8F34730</FONT></DIV>e3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>e, <DIV><FONT face=3D"Courier New">Character=20J Size:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20F 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Input=20J Speed:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;=20 9600<BR>Flow=206J Control:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;=20I DSR&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Output=20FJ Speed:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;=20J 9600<BR>Parity:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=) p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20lJ None&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Signal=20F Control:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Disabled<BR>Stop=20D Bits:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 Dynamic</FONT></DIV>3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>.
 <DIV><FONT=20o face=3D"Courier =nJ New">Access:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;=20J Remote&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Local =  J Switch:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;= &nbsp;&nbsp;=20p@ None<BR>Backwards Switch:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20C None&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20MJ Name:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=1 bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20.J PORT_6<BR>Break:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=* sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20C Local&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =o
 Session=20J Limit:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;&nbsp;&nbsp;&nbsp;=20B 4<BR>Forwards Switch:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20C None&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20nJ Type:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n== bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20eF Ansi<BR>Default Protocol:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20J LAT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Default=20J Menu:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
 bsp;&nbsp;=20   None<BR>Autolink Timer One:10=20D Two:10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =	 Dialer=20iJ Script:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=	 &nbsp;=20V None</FONT></DIV>k3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>tH <DIV><FONT face=3D"Courier New">Preferred Service: None<BR>Authorized=20> Groups:&nbsp;&nbsp; 0<BR>(Current)&nbsp; Groups:&nbsp;&nbsp; = 0</FONT></DIV>3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV> ) <DIV><FONT face=3D"Courier New">Enabled =y, Characteristics:<BR>Failover,&nbsp; Input=20C Flow Control,&nbsp; Lock,&nbsp; Loss Notification,&nbsp; Message=20e> Codes,<BR>Output Flow Control,&nbsp; Verification</FONT></DIV>3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>e3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>c: <DIV><FONT face=3D"Courier New">Terminal settings are as = follows</FONT></DIV>3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>eA <DIV><FONT face=3D"Courier New">Terminal: _LTA3000:&nbsp;&nbsp; =@ Device_Type:=20 B LQP02&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Owner: No=20 Owner</FONT></DIV>3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV> H <DIV><FONT face=3D"Courier New">&nbsp;&nbsp; Input:&nbsp;&nbsp;&nbsp;=20, 9600&nbsp;&nbsp;&nbsp;&nbsp; LFfill:&nbsp; =" 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20H Width: 132&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Parity: None<BR>&nbsp;&nbsp;=20A Output:&nbsp;&nbsp; 9600&nbsp;&nbsp;&nbsp;&nbsp; CRfill:&nbsp;=20eA 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Page:&nbsp;&nbsp; 66</FONT></DIV>b3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>l* <DIV><FONT face=3D"Courier New">Terminal =# Characteristics:<BR>&nbsp;&nbsp;=20h8 Interactive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20J Echo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;=205 No Typeahead&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No =  Escape<BR>&nbsp;&nbsp; No=205 Hostsync&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20oJ TTsync&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp;=20B Lowercase&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 Tab<BR>&nbsp;&nbsp; No=20mI Wrap&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20lJ Hardcopy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20B Remote&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20 Eightbit<BR>&nbsp;&nbsp; No = 3 Broadcast&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20i5 Readsync&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20mJ Form&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;=20 Fulldup<BR>&nbsp;&nbsp; No=20 G Modem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20-. Local_echo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=204 Autobaud&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Hangup<BR>&nbsp;&nbsp; No=203 Brdcstmbx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20 J DMA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs= p; No=20I Altypeahd&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set_speed<BR>&nbsp;&nbsp; =c No=20r= Commsync&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No Line=20rJ Editing&nbsp;&nbsp;&nbsp; Overstrike editing No Fallback<BR>&nbsp;&nbsp; = No=20aI Dialup&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No Secure=20)D server&nbsp;&nbsp; No Disconnect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20J Pasthru<BR>&nbsp;&nbsp; No Syspassword&nbsp;&nbsp;&nbsp;&nbsp; No SIXEL=20C Graphics&nbsp; No Soft Characters No Printer Port<BR>&nbsp;&nbsp; =3
 Numeric=20$ Keypad&nbsp;&nbsp;&nbsp;&nbsp; No=208 ANSI_CRT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20G Regis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20r8 Block_mode<BR>&nbsp;&nbsp; No Advanced_video&nbsp; No=203 Edit_mode&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20b= DEC_CRT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20o DEC_CRT2<BR>&nbsp;&nbsp; No =e5 DEC_CRT3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20y; No DEC_CRT4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No=20H7 DEC_CRT5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No =o Ansi_Color<BR>&nbsp;&nbsp;=20 % VMS Style Input<BR>$<BR></FONT></DIV>t3 <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>b< <DIV><FONT face=3D"Courier New">Any idea what I am missing = ?</FONT></DIV>A <DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV></BODY></HTML>o  - ------=_NextPart_000_000A_01C30A6A.F66F0D30--a   ------------------------------  # Date: Thu, 24 Apr 2003 21:10:04 GMT . From: "Diego CLAEYS" <diego.claeys@pandora.be>A Subject: VAX & ALPHA hobbyist hardware wanted in or near Belgium.s: Message-ID: <MoYpa.61014$t_2.5467@afrodite.telenet-ops.be>  
 Hi everybody,-  H  I'm a OpenVMS hobbyist in Belgium, I'm looking for VAX and ALPHA stuff.L If you have hardware, big or small, and you want to get rid off, please drop me a email!e    Many thanks in advance!   ------------------------------  % Date: Thu, 24 Apr 2003 20:10:27 +0200M6 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>6 Subject: Re: VMS SECURITY: Adding Privileges to a USER) Message-ID: <3EA82893.6050100@vajhoej.dk>o   David Froble wrote:r > Arne Vajhj wrote: >> newbee wrote:1 >>> What is the command to add user privileges???    >> $ SET DEF SYS$SYSTEMr >> $ RUN AUTHORIZE! >> UAF> MODI username /PRIV=xxxxxh >> UAF> EXIT >>) >> And be carefull about what you grant !n  E > You might want to use /DEFPRIV rather than /PRIV.  I don't do this  F > often, and might have things backwards, but what I remember is that J > /PRIV gives the user the priv but it's not enabled.  /DEFPRIV gives the  > user the priv enabled.  7 You are absolutely correct about the difference betweenr /PRIV and /DEFPRIV.d  3 I just tend to prefer /PRIV because that forces thet3 users to explicit do a SET PROC/PRIV=xxxxx whenevere# they need to actually use the priv.0   Arne   ------------------------------  % Date: Thu, 24 Apr 2003 19:36:30 +0200l7 From: Robert Trawinski <robert.trawinski@softax.com.pl>h6 Subject: Re: VMS SECURITY: Adding Privileges to a USER/ Message-ID: <b8957m$5vp$1@bozon2.softax.com.pl>-  
 newbee wrote:r/ > What is the command to add user privileges???- > 
 > Thank U!   $ SET DEF SYS$SYSTEM $ RUN AUTHORIZE  UAF> SHOW user_namem@ UAF> MODI user_name/PRIV=(priv_list)/DEFPRIV=(default_priv_list) ...l	 UAF> EXITm $    Robert   ------------------------------  % Date: Thu, 24 Apr 2003 13:32:16 -0400e( From: David Froble <davef@tsoft-inc.com>6 Subject: Re: VMS SECURITY: Adding Privileges to a USER* Message-ID: <3EA81FA0.30808@tsoft-inc.com>   Arne Vajhj wrote:   > newbee wrote:m > 0 >> What is the command to add user privileges??? >  >  > $ SET DEF SYS$SYSTEM > $ RUN AUTHORIZE3  > UAF> MODI username /PRIV=xxxxx > UAF> EXITe > ( > And be carefull about what you grant ! >  > Arne >     N You might want to use /DEFPRIV rather than /PRIV.  I don't do this often, and N might have things backwards, but what I remember is that /PRIV gives the user I the priv but it's not enabled.  /DEFPRIV gives the user the priv enabled.m   Dave     --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Fri, 25 Apr 2003 00:08:08 +0200u( From: "H Vlems" <hvlems.nieuw@zonnet.nl>6 Subject: Re: VMS SECURITY: Adding Privileges to a USER5 Message-ID: <b89n8a$7n1oc$1@ID-143435.news.dfncis.de>n  2 "Arne Vajhj" <arne@vajhoej.dk> schreef in bericht# news:3EA82893.6050100@vajhoej.dk...  > David Froble wrote:o > > Arne Vajhj wrote: > >> newbee wrote:3 > >>> What is the command to add user privileges???v >  > >> $ SET DEF SYS$SYSTEMr > >> $ RUN AUTHORIZE# > >> UAF> MODI username /PRIV=xxxxxo > >> UAF> EXIT > >>+ > >> And be carefull about what you grant !e >wF > > You might want to use /DEFPRIV rather than /PRIV.  I don't do thisG > > often, and might have things backwards, but what I remember is thatyK > > /PRIV gives the user the priv but it's not enabled.  /DEFPRIV gives the- > > user the priv enabled. >o9 > You are absolutely correct about the difference betweenp > /PRIV and /DEFPRIV.d >s5 > I just tend to prefer /PRIV because that forces thei5 > users to explicit do a SET PROC/PRIV=xxxxx whenever<% > they need to actually use the priv.h >  > Arne >c  H The general idea is that users should not need elevated privilges beyondH NETMBX and TMPMBX. In those cases where additional privileges are neededJ then I agree with Arne's point of view. Allow them but make the user awareL of their presence by turning them on explicitly. Putting a set proc/priv=xxxB command in login.com does not count in terms of user awareness :-)J That said, my first reaction reading the original post was that this was aH hacker trying to find his way in a VMS system. There is no such thing asJ "adding" privileges, they are granted up front and may be asserted. AddingD is more in line with su behaviour and there ain't such thing in VMS.   ------------------------------   End of INFO-VAX 2003.227 ************************