1 INFO-VAX	Wed, 18 Apr 2001	Volume 2001 : Issue 216       Contents: Re: 3rd party memory products P Re: =?iso-8859-1?Q?Z=FCrich?= Tech Seminar (was: London, England	Technical	Techn Re: Apache 2.0 Re: Apache 2.0 Re: Apache 2.0 Re: Backup problem Big News  Ϣ RE: DCE Question Re: DCE Question DFWDAYS 20010 How does NCP Link # correlate to NETnnn: device?4 Re: How does NCP Link # correlate to NETnnn: device?- Re: KZCCA Ultrawide SCSI Adapters for the VAX - Re: KZCCA Ultrawide SCSI Adapters for the VAX * Re: NOSLOT No PCB available (failed spawn)* Re: NOSLOT No PCB available (failed spawn) Re: OpenVMS and Human Resources / Re: OpenVMS article - please explain last line! / Re: OpenVMS article - please explain last line! / Re: OpenVMS article - please explain last line! / Re: OpenVMS article - please explain last line! / Re: OpenVMS article - please explain last line! / Re: OpenVMS article - please explain last line! / Re: OpenVMS article - please explain last line!  OT: OMG I built SSH  Re: OT: OMG I built SSH = Re: Sources of the ODS-2 specification; McCoy is out of print , Re: Star Office progress report (on Solaris)B Re: Talk to Rich Marcello, but DOES HE LISTEN? - Austin Texas area  Re: TCPIP v5.0A MAP command hang! RE: tuning VMS for Oracle7 Server , Re: Using 3-phase power converters on VAXen? Re: VMS-Related: Affordable 5 Re: Why is this a Bad Thing? (was: Future Computing.) 5 Re: Why is this a Bad Thing? (was: Future Computing.) 5 Re: Why is this a Bad Thing? (was: Future Computing.) 5 Re: Why is this a Bad Thing? (was: Future Computing.)   F ----------------------------------------------------------------------  # Date: Tue, 17 Apr 2001 21:32:02 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk> & Subject: Re: 3rd party memory products/ Message-ID: <3ADCB443.44C56953@cableinet.co.uk>    Arne Vajhj wrote:   A > The problem is whether Compaq will blame the third party memory & > the day you have a hardware problem.   > in my uni days we sometimes had to swap out non-Digital parts > (not just RAM, sometimes interface boards too) to troubleshoot? hardware. Digital field service had no problem with doing that. C Have things changed? Since Compaqtion I only have maintained fully  2 Digital systems (all purchased before Compaqtion).   ------------------------------  % Date: Wed, 18 Apr 2001 01:16:25 +0200 ) From: Christof Brass <brass@infopuls.com> Y Subject: Re: =?iso-8859-1?Q?Z=FCrich?= Tech Seminar (was: London, England	Technical	Techn , Message-ID: <3ADCCEC9.CAAD183F@infopuls.com>   "Terry C. Shannon" wrote:  > < > "Bob Koehler" <koehler@encompasserve.org> wrote in message/ > news:5S18JF$ZnSjv@eisner.encompasserve.org... N > > In article <3AD6A048.FDF557D1@ims.ch>, Didier Morandi <DMo@ims.ch> writes: > > > L > > > PS: Who is Charlie Matco? (I avoid reading non technical threads, this
 > is why I > > > ask the question). > > ( > > And will his coffee cups ship again? > >  > N > Only if Charlie can find a Merchant Fab who can product the vitreous wonders? > at an attractive price point. Might be a good idea, though...   @ Nice to see the umlaut in Zrich ;-) (one of the many good ideas< of DEC the DEC Multi National Character Set offered European< characters 10 years before the first SUN was able to display
 them IIRC)  @ I'm living in Zrich and would be glad to organise something for; our VMS friends visiting our small city and coming from far  away.  Is there any interest?/ Would others from the Zrich area like to join?    ------------------------------    Date: 17 Apr 2001 16:27:58 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: Re: Apache 2.0 3 Message-ID: <1znzWVvu$Ej1@eisner.encompasserve.org>   Z In article <9bhjpi$65p$1@milo.mcs.anl.gov>, "Tony Scandora" <scandora@cmt.anl.gov> writes:N > A public beta, source code only, of Apache 2.0 has just been released, basedK > on a portable runtime library that uses threads, not processes, among its I > other virtues.  News reports said how good it would be for Windows, but . > nothing about VMS.  Is a VMS port under way?  N Tony, I am surprised you don't remember about running version n.0 of software.   ------------------------------  % Date: Tue, 17 Apr 2001 16:28:28 -0400 8 From: "Scott LePage" <Scott.Lepage@ihatespam.compaq.com> Subject: Re: Apache 2.0 2 Message-ID: <vH1D6.972$fB6.24325@news.cpqcorp.net>    The short answer is:  "Not yet."  K We are still in the process of trying to get the Apache Software Foundation I to accept our code changes for the 1.3 code stream.  Which is why nothing A is mentioned about VMS in the news.  From their viewpoint, Apache A doesn't run on VMS.  All of those changes are being maintained by  Compaq (for now).   J I can tell you there are plans to move to the 2.0 code base in the future.G However, we didn't want to come out with a version of the Compaq Secure L Web Server that did not include all of the features currently shipping.  TheH big piece that's missing right now is there is no SSL support for Apache 2.0.  C hmmm....maybe we could ship one out and call it the Compaq Insecure  Web Server....nah...   Stay tuned,  Scott  CSWS development team   7 "Tony Scandora" <scandora@cmt.anl.gov> wrote in message % news:9bhjpi$65p$1@milo.mcs.anl.gov... H > A public beta, source code only, of Apache 2.0 has just been released, based K > on a portable runtime library that uses threads, not processes, among its I > other virtues.  News reports said how good it would be for Windows, but . > nothing about VMS.  Is a VMS port under way? > 3 > Tony Scandora, Argonne National Lab, 630-252-7541  > scandora@cmt.anl.gov >  >    ------------------------------  # Date: Wed, 18 Apr 2001 05:35:56 GMT  From: Dirk Munk <munk@home.nl> Subject: Re: Apache 2.0 ' Message-ID: <3ADD27BB.FB89CE3E@home.nl>    Scott LePage wrote:   " > The short answer is:  "Not yet." > M > We are still in the process of trying to get the Apache Software Foundation K > to accept our code changes for the 1.3 code stream.  Which is why nothing C > is mentioned about VMS in the news.  From their viewpoint, Apache C > doesn't run on VMS.  All of those changes are being maintained by  > Compaq (for now).  > L > I can tell you there are plans to move to the 2.0 code base in the future.I > However, we didn't want to come out with a version of the Compaq Secure N > Web Server that did not include all of the features currently shipping.  TheJ > big piece that's missing right now is there is no SSL support for Apache > 2.0. > E > hmmm....maybe we could ship one out and call it the Compaq Insecure  > Web Server....nah...  , Sure you can. Compaq webserver for Windows ?     >  > 
 > Stay tuned,  > Scott  > CSWS development team  > 9 > "Tony Scandora" <scandora@cmt.anl.gov> wrote in message ' > news:9bhjpi$65p$1@milo.mcs.anl.gov... J > > A public beta, source code only, of Apache 2.0 has just been released, > based M > > on a portable runtime library that uses threads, not processes, among its K > > other virtues.  News reports said how good it would be for Windows, but 0 > > nothing about VMS.  Is a VMS port under way? > > 5 > > Tony Scandora, Argonne National Lab, 630-252-7541  > > scandora@cmt.anl.gov > >  > >    ------------------------------   Date: 18 Apr 2001 03:48:49 GMT- From: Joe Heimann <heimann@nog.ecs.umass.edu>  Subject: Re: Backup problem , Message-ID: <9bj2r1$1n4$3@odo.ecs.umass.edu>  / Michael Austin <maustin@nc.prestige.net> wrote: 7 > maybe a bad tape?  what are the exact error messages?  > NEI.   > Michael Austin > DBA Consultant   > stavros frountzas wrote:  , >> we have experienced the following problemN >> We make a standalone save set on a Vax 3400 booting from a stabakit and the# >> command bavkup/image............  >> We create 4 TK50  tapesM >> whwn we try to read them, we can read all of them except the third one. we  >> use vms 6.2* >> Can anyone suggest something about this  G If I remember correctly, back around the 6.2 time frame there was a bug F in the standalone backup code where it would not always write a properC tape label on an uninitialized tape.  You might be able to copy the G third tape's contents onto another tape and append it after a good tape  label.   Joe Heimann    heimann@ecs.umass.edu    ------------------------------  ) Date: Tuesday, 17 Apr 2001 20:23:47 -0600  From: nobody@nowhere33.yet Subject: Big News  Ϣ ) Message-ID: <17040120.2347@nowhere33.yet>      \ ==Сй䣬żȻһվ㣬öɶԷֽҪݼ==   ŮѡԿ       ѡʱ䣨ĸͻ·ݣԿŮ˵׼ȷʿɴﵽ90%ϡ߶ΧŮʮһ˽ͳƣʮ뱾9698Ͽó׻ϼÿ200Ԫ۴ˡǰո˱ֹڡ  
 ÿ  ]     Ϲվ㶼֧ÿ֧ʼģ飬Ƚ׹ɹװλȼ۸񲻳300ԲƷ,ǧҪ̫Ʒ̫Ʒ̼һ㲻ܹʼ乺򣬶Һױ֡ммǣҲҪͬһվιôһǹһطǧҪڹڵĹվ㣬̫ˣûǿƼվ㡣 F     ϵշɫվûʲôرʹҪ󣬷Ĵ󵨵ʹðɡR     ·ֵ¹ĹվҲȽ׹ɹܶԼңڿļ⡣  
 Ѵ绰       .Ѵſ绰ķ      .;绰ķ      .Ѵлķ      .õ绰Ѵ;绰      .еĵ绰Ѵ;      .200øѵķ  &     .ͻĳЩλ;绰      .ƭ      .ѵ绰      .ICѴ򴫺      .ICѴ绰      .Ѵֻ      @  ַ http://www.100megspop2.com/makemoney/default.htm                 ------------------------------  % Date: Tue, 17 Apr 2001 13:58:28 -0500 0 From: arturo saavedra <arturo.saavedra@wcom.com> Subject: RE: DCE Question C Message-ID: <MOEAJKGGEIMGCCPEPJBHCELODPAA.arturo.saavedra@wcom.com>   I Thanks Wayne.. does that mean they can both be configured to be protocols F for DCE communication at the same time.. sort of a fail over redundant configuration?  
 Thanks..!!       -----Original Message-----7 From: Wayne Morrison [mailto:Wayne.Morrison@compaq.com] & Sent: Tuesday, April 17, 2001 11:41 AM To: Info-VAX@Mvb.Saic.Com  Subject: Re: DCE Question     G Yes, DCE for OpenVMS has supported both TCP/IP and DECnet as transports  since K DCE V1.0.  Any of the versions of DCE for OpenVMS which have shipped in the I past several years support both DECnet Phase IV and DECnet Phase V.  That F certainly includes DCE V1.5 and DCE V3.0, as you indicate you're using below.  K Oh, yes.  The support for this is the same on both VAX and Alpha.  The only D noticable difference between the platforms is DCE's support for NTLM	 security, 3 which is Alpha-only, and only as of OpenVMS V7.2-1.    	Wayne Morrison  	OpenVMS Engineering 	Compaq Computer Corp.   arturo saavedra wrote: > . > Hi all.. had a question about DCE on Alphas. > E > Can DCE be configured to use both TCPIP and DECnet as its transport  > protocol?  >  > Hw:  ES40  > os:  OpenVMS 7.2-16 > ls:  DCE 1.5 and DCE 3.0 , TCPIP 5.1, DECnet Phase V > 	 > Thanks!  >  > abs    ------------------------------  % Date: Tue, 17 Apr 2001 15:25:06 -0400 0 From: Wayne Morrison <Wayne.Morrison@compaq.com> Subject: Re: DCE Question * Message-ID: <3ADC9892.5997FEFF@compaq.com>  O Yes, it's certainly possible to have both configured for DCE at the same time.   In fact, it's the default!  L Unless you define the logical name RPC_SUPPORTED_PROTSEQS, or use one of theK rpc_server_use*protseq* calls (other than rpc_server_use_all_protseqs), DCE L uses all supported protocol sequences.  For OpenVMS, that's TCP/IP, TCP/UDP,$ DECnet Phase IV, and DECnet Phase V.  F Now, your application would have to be set up to accept these protocolN sequences on the other end of the connection as well, for things to be able toM use either TCP or DECnet interchangably.  And obviously your network needs to K be able to pass DECnet though the path from client to/from server if you're # going to use it as a DCE transport.    	Wayne   arturo saavedra wrote: > K > Thanks Wayne.. does that mean they can both be configured to be protocols H > for DCE communication at the same time.. sort of a fail over redundant > configuration? >  > Thanks..!! >  > -----Original Message-----9 > From: Wayne Morrison [mailto:Wayne.Morrison@compaq.com] ( > Sent: Tuesday, April 17, 2001 11:41 AM > To: Info-VAX@Mvb.Saic.Com  > Subject: Re: DCE Question  > I > Yes, DCE for OpenVMS has supported both TCP/IP and DECnet as transports  > since M > DCE V1.0.  Any of the versions of DCE for OpenVMS which have shipped in the K > past several years support both DECnet Phase IV and DECnet Phase V.  That H > certainly includes DCE V1.5 and DCE V3.0, as you indicate you're using > below. > M > Oh, yes.  The support for this is the same on both VAX and Alpha.  The only F > noticable difference between the platforms is DCE's support for NTLM > security, 5 > which is Alpha-only, and only as of OpenVMS V7.2-1.  >  >         Wayne Morrison >         OpenVMS Engineering  >         Compaq Computer Corp.  >  > arturo saavedra wrote: > > 0 > > Hi all.. had a question about DCE on Alphas. > > G > > Can DCE be configured to use both TCPIP and DECnet as its transport 
 > > protocol?  > > 
 > > Hw:  ES40  > > os:  OpenVMS 7.2-18 > > ls:  DCE 1.5 and DCE 3.0 , TCPIP 5.1, DECnet Phase V > >  > > Thanks!  > >  > > abs    ------------------------------  # Date: Wed, 18 Apr 2001 02:01:01 GMT - From: Terry C Shannon <shannon@world.std.com>  Subject: DFWDAYS 2001 D Message-ID: <Pine.SGI.4.21.0104172156290.24830-100000@world.std.com>  H Rumour has it Charlie Matco will discuss some significant changes on theH BCSG org chart during his DFWDAYS talk on Wednesday night April 18. SaidI changes will be of interest to the Alpha, OpenVMS, and Tru64 communities.    ------------------------------  % Date: Tue, 17 Apr 2001 15:20:42 -0600 = From: Arlen Williams <remove.arlen.williams@remove.sabre.com> 9 Subject: How does NCP Link # correlate to NETnnn: device? / Message-ID: <3ADC5F49.54523A4@remove.sabre.com>   C I want to know how to tie a link number shown by MCR NCP SHOW KNOWN H LINKS to a NETnnn: device shown by show device net or from in SDA to tie it the other way. Thanks!    ------------------------------  % Date: Wed, 18 Apr 2001 00:55:11 +0200 . From: "Jesper Naur" <jesper.naur@post.tele.dk>= Subject: Re: How does NCP Link # correlate to NETnnn: device? , Message-ID: <9bihik$naq$1@news.inet.tele.dk>  H Arlen Williams <remove.arlen.williams@remove.sabre.com> wrote in message) news:3ADC5F49.54523A4@remove.sabre.com... E > I want to know how to tie a link number shown by MCR NCP SHOW KNOWN J > LINKS to a NETnnn: device shown by show device net or from in SDA to tie > it the other way. Thanks!    Hello Arlen.  H I found something - you may or may not be able to use it, but here goes:  . Be advised, that I in this particular case use  ( VAXstation 3100/GPX running OpenVMS V6.2  I since this is the only machine in my vicinity, which runs Decnet Phase IV   
 I can say:   $ mc ncp sho kno links  6 Known Link Volatile Summary as of 18-APR-2001 00:28:31  I    Link       Node           PID     Process     Remote link  Remote user   D   8196   41.280 (NGFA)     20200054  REMACP                4  JESPERB   8197   41.280 (NGFA)     2020005A  JESPER                5  X$X0  
 Later, I say:    SDA> sh proc remacp/chan  ; Process index: 0014   Name: REMACP   Extended PID: 20200054 ; ----------------------------------------------------------- < Channel  Window           Status        Device/file accessed< -------  ------           ------        --------------------	 [snip...] .   0050  808B2B00                        NET17:   When I now say:    SDA> ex 808B2B00 + 40    I get:   808B2B40:  20040004   "... "  I where you will see bit 31-16 = 2004 (hex) = 8196 (dec) = Local link,  and  bit 15-0 = 0004  = remote link.    I can also say   SDA> sh proc jesper/chan; Process index: 001A   Name: JESPER   Extended PID: 2020005A ; -----------------------------------------------------------   < Channel  Window           Status        Device/file accessed< -------  ------           ------        --------------------   [snip..].   0160  808C0140             Busy       NET22:   and if I now say   SDA> e 808C0140 + 40   I get-   808C0180:  20050005   "... "  < where you will see 2005 (hex) = 8197 (dec) and 5 is obvious.    L I tried a few other examples and they all worked the same, so it seems, thatI under this version of VAX/VMS/Decnet, you can find the local process name=J using NCP SHO KNO LINKS, find the channel using SDA> SH PROC/CHAN and look into <Window> + 40.0  I Of course, if you have a different version of the operating system (or anL Alpha), you may have to do some experimenting on your own, in particular theL offset '40' may be subject to variation, maybe the explanations above can be an inspiration.  < If you wish to go the other way round, you can say (to DCL):   $ SHOW DEV NET22:/FULL  % which will give you the process name:  G Device NET22:, device type unknown, is online, mounted, network device, mailbox     device.  <     Error count                    0    Operations completed 1351     Owner process           "JESPER"    Owner UIC [JESPER]0     Owner process ID        2020005A    Dev Prot S:RWPL,O:RWPL,G:RWPL,W:RWPL;     Reference count                1    Default buffer size 256   ' which you can continue with inside SDA.       Best regards     Jesper Naur   ------------------------------  % Date: Tue, 17 Apr 2001 20:29:01 -04002 From: rdeininger@mindspring.com (Robert Deininger)6 Subject: Re: KZCCA Ultrawide SCSI Adapters for the VAXL Message-ID: <rdeininger-1704012029020001@user-2ive67u.dialup.mindspring.com>  < In article <3ADC73F8.FDBEDCE1@mmaz.com>, "Barry Treahy, Jr." <treahy@mmaz.com> wrote:      N > I still can't decide if this represented Compaq/DEC marketing or engineeringD > at their best, but it is a flash back to the old Emulex Q-bus SCSIM > controller that could only handle tape or disk, the UC07 I believe.  If youiM > wanted both, you had to buy the UC08 which was actually a dual channel SCSI-6 > which really wasn't addressing the issue properly...  ? I think Q-bus was in its twilight before SCSI was even a littleoI standardized.  These adapters often had firmware tailored to a very small F group of devices; sometimes other devices mostly worked, but it was an	 accident.   H I've used cards from various vendors that had trouble with non-preferred" SCSI devices.  It wasn't just DEC.  C Though DEC had less to gain by supporting SCSI well during the DSSI J days... DSSI was more capable and easier to work with since non-conformingA devices were forbidden.  (Forbidden in principal if not always inp
 practice.)   -- i Robert Deininger rdeininger@mindspring.comn   ------------------------------  # Date: Wed, 18 Apr 2001 03:14:58 GMTC( From: Terry Kennedy <terry@gate.tmk.com>6 Subject: Re: KZCCA Ultrawide SCSI Adapters for the VAX' Message-ID: <GByx0y.5Mo@spcuna.spc.edu>t  + Barry Treahy, Jr. <treahy@mmaz.com> writes:4J > I do not believe so.  The KZCCA is actually a native daughter board thatH > connects to the MB using an interface that I believe was available for > another DSSI bus.:  8   True. The initial design also had Fast Ethernet on it.  9 > The 4000/100 is not a real expandable system unlike theFM > big chassis models of the 4000 but even with the big chassis, it is perhaps H > my misunderstanding that a lot of the SCSI adapters for the likes of a5 > 4000/600 or 4000/700 are tape and CD only adapters._  M   DEC only produced Q-bus SCSI adapters, so they're limited to the throughputlM of the Q-bus (which is something like 3MByte/sec usable in block mode, IIRC).a  K   The adapters they made were intended to attach specific DEC gizmos to theaI systems, said gizmos being CD-ROM drives (even DEC wasn't clueless enough I to try to get a vendor to build a CD-ROM drive with a DSSI interface) andiH tape drives (likewise - DEC's DAT offerings were re-badged products from other vendors).r  N > I still can't decide if this represented Compaq/DEC marketing or engineering > at their best,  J   Given the relatively low throughput on the Q-bus and DEC's push for DSSIM at that time, it was a combination of marketing and engineering that producedtI cards like the KZQSA. It was marketed as only supporting CD-ROM and tape rK drives, but the firmware worked with many hard disks if you were willing to4) go the "unsupported configuration" route.c  H   Note that DEC did offer a Q-bus FDDI adapter, but it was a spectacular) under-performer for the obvious reason...1  5 > but it is a flash back to the old Emulex Q-bus SCSIiM > controller that could only handle tape or disk, the UC07 I believe.  If youeM > wanted both, you had to buy the UC08 which was actually a dual channel SCSIu6 > which really wasn't addressing the issue properly...  J   That's just Emulex being dense. Companies like CMD produced boards whichJ were disk-only, tape-only, or both - all running on the same SCSI bus. TheJ only reason for the restriction was that they had to pay DEC another MSCP/. TMSCP license fee for the dual-function cards.  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USAc   ------------------------------  % Date: Tue, 17 Apr 2001 14:14:36 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 3 Subject: Re: NOSLOT No PCB available (failed spawn) , Message-ID: <3ADC880A.96D01883@videotron.ca>   "Barry Treahy, Jr." wrote:W > individual that told me to hike the SPTREQ.  Because I have two system apps that both:X > suck up SPTE's like they are going out of style, I took his recommended amount for his= > product and the minimum from the second and arrived at 70k.     According to the help in SYSGEN: ##R Number of system page table entries required for mapping the following components: 	Executive image
 	RMS image 	SYSMSG.EXE file 	Multiport memory structures 	each massbus adapter  	each unibus adapter 	each DR32 adatper  J The number of system page table entries required for all other purposes isK automatically computed and added to the value of SPTREQ to yield the actualw size of the system page table. ##  E Of the above listed components, which ones would "grow" because of an 6 application running after you've booted the thing up ?  N Or is it a case of the "automatically computed" which fails to allocate enough% additional for the "other purposes" ?c   ------------------------------  % Date: Tue, 17 Apr 2001 11:23:43 -0700i+ From: "Barry Treahy, Jr." <treahy@mmaz.com><3 Subject: Re: NOSLOT No PCB available (failed spawn)a( Message-ID: <3ADC8A2F.23809C6F@mmaz.com>   JF Mezei wrote:n   > "Barry Treahy, Jr." wrote:Y > > individual that told me to hike the SPTREQ.  Because I have two system apps that bothDZ > > suck up SPTE's like they are going out of style, I took his recommended amount for his? > > product and the minimum from the second and arrived at 70k.h >p" > According to the help in SYSGEN:G > Of the above listed components, which ones would "grow" because of ant8 > application running after you've booted the thing up ? >kP > Or is it a case of the "automatically computed" which fails to allocate enough' > additional for the "other purposes" ?t  Y Again, you are asking for an explanation as to 'why' and as I said, I cannot explain why, V all I can say is that the NOSLOT problem ceased.  If AUTOGEN was actually sensitive toY SPTE's in use, they it should automatically adjust based on the system usage, but it does-[ not.  For example, with RAXCO's Perfectcache running, I may have 100,000 pages allocated to U the caching software and if I run AUTOGEN while those pages are allocated, AUTOGEN is-Y clueless and calculates SPTREQ as if there is little or no demand.  Like I said, I cannot I provide an answer why it worked for me, I'm simply stating that it did...s  
 Best regards,0   Barry    --  ? Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028P   ------------------------------  % Date: Tue, 17 Apr 2001 16:45:15 -0300-) From: fabio_compaq@ep-bc.petrobras.com.br ( Subject: Re: OpenVMS and Human ResourcesL Message-ID: <OF0EBE1F1D.423351CD-ON03256A31.006C83AC@ep-bc.petrobras.com.br>  : --0__=03256A31006C83AC8f9e8a93df938690918c03256A31006C83AC+ Content-transfer-encoding: quoted-printablec, Content-type: text/plain; charset=iso-8859-1     Dilbert ????  9 I believe he  is my soul mate  .....  If I told you .....Y   Regards    FC        2 Don Sykes <don@alphase.com> em 17/04/2001 14:18:05  - Favor responder a Don Sykes <don@alphase.com>w             Info-VAX@Mvb.Saic.Com       ( Assunto: Re: OpenVMS and Human Resources    H Do you get the "Dilbert" comic strip down there ? This sounds exactly l= ike  a Dilbert strip.  H fabio_compaq@ep-bc.petrobras.com.br wrote: Today I spent half-day in a = jobi, interview=A0 (far 250 km from my actual job) and the HR woman asked me ...i  . - Where / what=A0 are you working (with) now ?  0 a) It was written in my resume, in her hands....   =A0-=A0 What is OpenVMS ?a   a) She wanted a MVS guy ....  A - Oh you cannot work with Unix so....=A0 you need to recycle ....T  H a) What is the magic in recycle in Unix ?=A0 Last time I worked with So= laris  was one year ago.g   - Bye, bye the door is opened !t   a) I HATE HR women ....E   RegardsA   FC (See attached file: don.vcf)         =a  : --0__=03256A31006C83AC8f9e8a93df938690918c03256A31006C83AC( Content-type: application/octet-stream;   	name="=?iso-8859-1?Q?don.vcf?="D Content-Disposition: attachment; filename="=?iso-8859-1?Q?don.vcf?="! Content-Transfer-Encoding: base64   L YmVnaW46dmNhcmQgDQpuOlN5a2VzO0Rvbg0KdGVsO2NlbGw6QXZhaWxhYmxlIHRvIGN1c3RvbWVyL cyBvbmx5DQp0ZWw7ZmF4OjQxNS00ODUtNjg5NQ0KdGVsO3dvcms6NDE1LTQ1Ny04NTMyDQp4LW1vL emlsbGEtaHRtbDpUUlVFDQp1cmw6d3d3LmFscGhhc2UuY29tDQpvcmc6QWxwaGEgU29mdHdhcmUgL RXhwcmVzcywgTExDDQphZHI6OzsxMzgwIExpbmNvbG4gQXZlIC0gU3VpdGUgNTtTYW4gUmFmYWVsL O0NBOzk0OTAxO1VTQQ0KdmVyc2lvbjoyLjENCmVtYWlsO2ludGVybmV0OmRvbkBhbHBoYXNlLmNvL bQ0KdGl0bGU6UHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyDQpub3RlO3F1b3RlZC1wcmludGFiL bGU6V2Vic2l0ZTogIGh0dHA6Ly9hbHBoYXNlLmNvbT0wRD0wQVJlc3VtZTogIGh0dHA6Ly9hbHBoL YXNlLmNvbS9Eb25zQ1YuaHRtbD0wRD0wQUFsdGVybmF0ZSBFbWFpbCBBZGRyZXNzOiAgYWxwaGFzL ZUBwYWNiZWxsLm5ldA0KeC1tb3ppbGxhLWNwdDo7LTE5NTIwDQpmbjpEb24gU3lrZXMNCmVuZDp2 Y2FyZA0K  < --0__=03256A31006C83AC8f9e8a93df938690918c03256A31006C83AC--   ------------------------------    Date: 18 Apr 2001 05:08:36 +0800, From: Paul Repacholi <prep@prep.synonet.com>8 Subject: Re: OpenVMS article - please explain last line!- Message-ID: <87wv8jfd4b.fsf@prep.synonet.com>n  # Shane.F.Smith@Healthnet.com writes:C  D > Incidentally, I saw an interesting article the other day. Not sure: > where though, sorry. I'll post the link if I can find itE > again. Intel had shown at a demo how the P4 makes use of its higherDB > memory bandwidth by measiring the usage while running a standardD > benchmark. The article's author noticed they just showed the usageE > (4x the P3), not the benchmark score, so he did some digging. TurnsiE > out the P4 scored almost the same as the P3, meaning three quartersr< > of the bandwidth used was wasted for no actual performanceD > gain. That got attributed to the P4 having 128-byte cache rows and> > the P3 having 32-byte rows. If the data chunks are small andB > non-contiguous, the P4 wastes most of its bandwidth.  Of course,A > that effect will only be seen in certain applications, but it'sb@ > interesting Intel themselves used one to display the bandwidth > throughput numbers.   C > So, I guess memory bandwidth is as unreliable as Mhz in measuring  > speed.  @ Memory bandwidth on a benchmark (other than a streams type) is a measure of cache failure!n  F Even more interesting with the P4 is the thermal 'managment'. Now, youD have to be carefull, there are two of them. One is optional, and theF clock stuttering ratio can be altered. The other is not.  Intel stressC several times that disabling it is 'unsuported'! When the core temp,= reaches its limit, the clock is switched off for a 50-50 dutypA cycle. So no matter the clock speed, the performance limit is CPUi; power so that the case is <72C... So when you need it, it'sp gone. Well, half gone.  C Tests have hit this limit with a one pound lump Intel fit as a heat. sink.-  ? Intel P4, the computer you have when you don't have a computer.    --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.c@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Tue, 17 Apr 2001 14:46:45 -0700h! From: Shane.F.Smith@Healthnet.comi8 Subject: Re: OpenVMS article - please explain last line!D Message-ID: <OF148D5595.FD8B13A7-ON88256A31.00777F9F@foundation.com>  K True, but even overclockers have not been getting the thermal protection to.H kick in unless they deliberately tried to. Check out www.HardOCP.com for? their comments on one article complaining about that "feature".h   ShaneT          E Paul Repacholi <prep@prep.synonet.com>@k9.healthnet.com on 04/17/2001. 02:08:36 PMa  8 Please respond to Paul Repacholi <prep@prep.synonet.com>   Sent by:  prep@k9.healthnet.com      To:   Info-VAX@Mvb.Saic.Com  cc:n  9 Subject:  Re: OpenVMS article - please explain last line!h    # Shane.F.Smith@Healthnet.com writes:c  D > Incidentally, I saw an interesting article the other day. Not sure: > where though, sorry. I'll post the link if I can find itE > again. Intel had shown at a demo how the P4 makes use of its higher B > memory bandwidth by measiring the usage while running a standardD > benchmark. The article's author noticed they just showed the usageE > (4x the P3), not the benchmark score, so he did some digging. Turns E > out the P4 scored almost the same as the P3, meaning three quartersa< > of the bandwidth used was wasted for no actual performanceD > gain. That got attributed to the P4 having 128-byte cache rows and> > the P3 having 32-byte rows. If the data chunks are small andB > non-contiguous, the P4 wastes most of its bandwidth.  Of course,A > that effect will only be seen in certain applications, but it'so@ > interesting Intel themselves used one to display the bandwidth > throughput numbers.p  C > So, I guess memory bandwidth is as unreliable as Mhz in measuring  > speed.  @ Memory bandwidth on a benchmark (other than a streams type) is a measure of cache failure!e  F Even more interesting with the P4 is the thermal 'managment'. Now, youD have to be carefull, there are two of them. One is optional, and theF clock stuttering ratio can be altered. The other is not.  Intel stressC several times that disabling it is 'unsuported'! When the core tempb= reaches its limit, the clock is switched off for a 50-50 dutySA cycle. So no matter the clock speed, the performance limit is CPUw; power so that the case is <72C... So when you need it, it's  gone. Well, half gone.  C Tests have hit this limit with a one pound lump Intel fit as a heatr sink.u  ? Intel P4, the computer you have when you don't have a computer.e   --< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Tue, 17 Apr 2001 18:58:35 -0700n From: <tsmurphy@addr.com>:8 Subject: Re: OpenVMS article - please explain last line!6 Message-ID: <YA6D6.3000$AF2.1356252@nntp3.onemain.com>  . <Shane.F.Smith@Healthnet.com> wrote in message> news:OF5B993D2E.CB9FAA79-ON88256A31.005D640C@foundation.com... >vH > NO! yourself, JF. Get him out of AMD so they have a chance of chopping > Intel down to size.e >tI > Don't know why their stocks are so low. Intel is in deep do-do over the. P4,.K > people are avoiding it in droves. The public seem to have woken up to theoH > fact that Mhz isn't everything, and the Athlon's reaping the benefits.  G Not really. According to the CNET article today about Intel's earnings,mJ AMD's marketshare has increased from 15.9% in '99 to 17.1% today, a growthC of 1.2%. I believe that Intel has grown more than that. From what I-D understand, AMD and Intel have grown mainly at the expense of Cyrix.  I AMD's main benefit is that they have a more competitive part leading to a8K higher ASP. They haven't gained marketshare though. Intel's main problem is2I a massive demand shortfall, which permits them to price processors just aaH little bit more than their competition (before, they were able to charge  MUCH more than the competition).  J > Incidentally, I saw an interesting article the other day. Not sure whereK > though, sorry. I'll post the link if I can find it again. Intel had showniL > at a demo how the P4 makes use of its higher memory bandwidth by measiringL > the usage while running a standard benchmark. The article's author noticedL > they just showed the usage (4x the P3), not the benchmark score, so he didJ > some digging. Turns out the P4 scored almost the same as the P3, meaningK > three quarters of the bandwidth used was wasted for no actual performancenK > gain. That got attributed to the P4 having 128-byte cache rows and the P3 K > having 32-byte rows. If the data chunks are small and non-contiguous, theSL > P4 wastes most of its bandwidth.  Of course, that effect will only be seenL > in certain applications, but it's interesting Intel themselves used one to+ > display the bandwidth throughput numbers.e >tJ > So, I guess memory bandwidth is as unreliable as Mhz in measuring speed.  B Perhaps. But it's funny that prior to the P4, people defended RISCJ processors (which mostly had lower performance - especially integer - thanI Intel processors) on the basis that they had better memory bandwidth. NowpJ that P4 has better memory bandwidth than any RISC processor AND has higherH performance (only Alpha beats it on FP, and nobody beats it on INT), howG will people defend paying 4x-5x the price for less performance and lessf
 bandwidth?   ------------------------------  % Date: Tue, 17 Apr 2001 19:06:06 -0700k From: <tsmurphy@addr.com>o8 Subject: Re: OpenVMS article - please explain last line!6 Message-ID: <5J6D6.3006$AF2.1359387@nntp3.onemain.com>  7 Paul Repacholi <prep@prep.synonet.com> wrote in messageh' news:87wv8jfd4b.fsf@prep.synonet.com...d  H > Even more interesting with the P4 is the thermal 'managment'. Now, youF > have to be carefull, there are two of them. One is optional, and theH > clock stuttering ratio can be altered. The other is not.  Intel stressE > several times that disabling it is 'unsuported'! When the core temp ? > reaches its limit, the clock is switched off for a 50-50 dutyaC > cycle. So no matter the clock speed, the performance limit is CPUi= > power so that the case is <72C... So when you need it, it's  > gone. Well, half gone.  K This is FUD; nobody has ever observed thermal throttling on a system unless L you put heaters on the CPU's. My P4 system (1.4 GHz), incidentally, idles atL 30 degrees, and the absolute peak I've been able to get it at is 40 degrees.L Nowhere remotely close to 72 degrees. Although it's possible that there will. be problems as it ramps to higher frequencies.  J Actually, the whole feature is more of a safety device than anything else.I AMD has had a lot of problems with people returning CPU's damaged by heatiK problems at 900 MHz and above (people overclocking it and forgetting to putiJ the heatsink on). I haven't heard of P4's burning up, precisely because itE has this feature. Even Slashdot, which has one of the most militantly0L anti-Intel user bases anywhere on the Internet, agreed it was a nice feature and wished AMD had it too.   ------------------------------  % Date: Tue, 17 Apr 2001 19:23:05 -0700u! From: Shane.F.Smith@Healthnet.comh8 Subject: Re: OpenVMS article - please explain last line!D Message-ID: <OFA94297AE.FD912250-ON88256A32.000CE3F6@foundation.com>  A I don't know about the market share, but check out Intel's stock:w  N http://www.bigcharts.com/quickchart/quickchart.asp?symb=intc&sid=0&o_symb=intc  G Also, IIRC the P4 has considerably less memory bandwidth than the AlphaeG chip. Can someone provide figures? I know I saw some here recently, buth) don't have access to Deja to dig them up.d   Shanes            + tsmurphy@addr.com on 04/17/2001 06:58:35 PMn  # Please respond to tsmurphy@addr.com    To:   Info-VAX@Mvb.Saic.Com  cc:l  9 Subject:  Re: OpenVMS article - please explain last line!e      . <Shane.F.Smith@Healthnet.com> wrote in message> news:OF5B993D2E.CB9FAA79-ON88256A31.005D640C@foundation.com... > H > NO! yourself, JF. Get him out of AMD so they have a chance of chopping > Intel down to size.  >iI > Don't know why their stocks are so low. Intel is in deep do-do over theh P4, K > people are avoiding it in droves. The public seem to have woken up to the H > fact that Mhz isn't everything, and the Athlon's reaping the benefits.  G Not really. According to the CNET article today about Intel's earnings,iJ AMD's marketshare has increased from 15.9% in '99 to 17.1% today, a growthC of 1.2%. I believe that Intel has grown more than that. From what ItD understand, AMD and Intel have grown mainly at the expense of Cyrix.  I AMD's main benefit is that they have a more competitive part leading to a K higher ASP. They haven't gained marketshare though. Intel's main problem is-I a massive demand shortfall, which permits them to price processors just aoH little bit more than their competition (before, they were able to charge  MUCH more than the competition).  J > Incidentally, I saw an interesting article the other day. Not sure whereK > though, sorry. I'll post the link if I can find it again. Intel had shownyB > at a demo how the P4 makes use of its higher memory bandwidth by	 measiringhD > the usage while running a standard benchmark. The article's author noticedEH > they just showed the usage (4x the P3), not the benchmark score, so he didcJ > some digging. Turns out the P4 scored almost the same as the P3, meaningK > three quarters of the bandwidth used was wasted for no actual performancerK > gain. That got attributed to the P4 having 128-byte cache rows and the P3sK > having 32-byte rows. If the data chunks are small and non-contiguous, thewG > P4 wastes most of its bandwidth.  Of course, that effect will only beh seenI > in certain applications, but it's interesting Intel themselves used one  to+ > display the bandwidth throughput numbers.l >oJ > So, I guess memory bandwidth is as unreliable as Mhz in measuring speed.  B Perhaps. But it's funny that prior to the P4, people defended RISCJ processors (which mostly had lower performance - especially integer - thanI Intel processors) on the basis that they had better memory bandwidth. Now J that P4 has better memory bandwidth than any RISC processor AND has higherH performance (only Alpha beats it on FP, and nobody beats it on INT), howG will people defend paying 4x-5x the price for less performance and lessu
 bandwidth?   ------------------------------  % Date: Tue, 17 Apr 2001 19:47:06 -0700o From: <tsmurphy@addr.com>:8 Subject: Re: OpenVMS article - please explain last line!6 Message-ID: <Lm7D6.3023$AF2.1374928@nntp3.onemain.com>  . <Shane.F.Smith@Healthnet.com> wrote in message= news:OFA94297AE.FD912250ON88256A32.000CE3F6@foundation.com...i  I > Also, IIRC the P4 has considerably less memory bandwidth than the AlphaaI > chip. Can someone provide figures? I know I saw some here recently, but + > don't have access to Deja to dig them up.l  I I don't understand how somebody can post such a blatantly false statementh7 when stream is a click away. Here are the real numbers:C  # Intel Pentium 4 1.4 GHz - 1574 MB/s0 Compaq ES40 - 1338 MB/s  Compaq DS20 - 1323 MB/si HP B2000 - 960 MB/s  AMD Athlon 800 MHz - 586 MB/sG$ Intel Pentium III 733 MHz - 544 MB/s  H I expect that Compaq will catch up to the P4 with EV7 which will feature7 quad-channel Rambus, but that's not until 2002 or 2003..   ------------------------------    Date: 18 Apr 2001 01:26:10 -0500+ From: young_r@encompasserve.org (Rob Young) 8 Subject: Re: OpenVMS article - please explain last line!3 Message-ID: <XnOzNFwBNPC3@eisner.encompasserve.org>p  R In article <Lm7D6.3023$AF2.1374928@nntp3.onemain.com>, <tsmurphy@addr.com> writes:0 > <Shane.F.Smith@Healthnet.com> wrote in message? > news:OFA94297AE.FD912250ON88256A32.000CE3F6@foundation.com...A > J >> Also, IIRC the P4 has considerably less memory bandwidth than the AlphaJ >> chip. Can someone provide figures? I know I saw some here recently, but, >> don't have access to Deja to dig them up. > K > I don't understand how somebody can post such a blatantly false statement29 > when stream is a click away. Here are the real numbers:m > % > Intel Pentium 4 1.4 GHz - 1574 MB/s  > Compaq ES40 - 1338 MB/sH > Compaq DS20 - 1323 MB/sg > HP B2000 - 960 MB/ss > AMD Athlon 800 MHz - 586 MB/sc& > Intel Pentium III 733 MHz - 544 MB/s > J > I expect that Compaq will catch up to the P4 with EV7 which will feature9 > quad-channel Rambus, but that's not until 2002 or 2003.k >   ? 	They will catch up much sooner than that.  There are some morea$ 	powerful chipsets in the pipelines.   				RobA   ------------------------------  % Date: Tue, 17 Apr 2001 17:58:59 -0400k+ From: John Eisenschmidt <jeisensc@aaas.org>T Subject: OT: OMG I built SSH# Message-ID: <sadc8480.041@aaas.org>   I I'm sorry to waste the bandwidth to even send this message, but I can't =)H tell you how excited I am. I've done a fair amount of porting/building =L source on Unix, but today was my first attempt on VMS. I was able to build =E tar, gzip, OpenSSL, and SSH. I'm off to go have a drink to celebrate.o   I love this operating system.l   ------------------------------  % Date: Tue, 17 Apr 2001 15:49:07 -0700n  From: Jon <jsmyth69@hotmail.com>  Subject: Re: OT: OMG I built SSH2 Message-ID: <R8jcOvn1iI6e+ohLRZhftWA8t4UR@4ax.com>  D Just because I need to do this soon, Which distribution did you use? Thanks!Q      , John Eisenschmidt <jeisensc@aaas.org> wrote:   >I'm sorry to waste the bandwidth to even send this message, but I can't tell you how excited I am. I've done a fair amount of porting/building source on Unix, but today was my first attempt on VMS. I was able to build tar, gzip, OpenSSL, and SSH. I'm off to go have a drink to celebrate. >v >I love this operating system.   ------------------------------   Date: 17 Apr 2001 17:31 PDTp) From: rankin@eql.caltech.edu (Pat Rankin)uF Subject: Re: Sources of the ODS-2 specification; McCoy is out of print/ Message-ID: <17APR200117315011@eql.caltech.edu>   . In article <87elurh830.fsf@prep.synonet.com>,\1  Paul Repacholi <prep@prep.synonet.com> writes...eE > Simon Clubley<simon_clubley@remove_me.excite.com-Earth.UFP> writes:cG >> I am trying to find a copy of the ODS-2 specification, and yes, I ami >> aware of the McCoy book. :-)  > 4 > There is an old copy on one of the 198x sig tapes.  >      A long time ago Carl Lydick transcribed a printed copy byA hand and I'm pretty sure that he posted it to Info-VAX.  (I'm notuC sure about that; the cover page does assert copyright for Digital.) > The copy I have has a file date of 9-FEB-1987 but I don't knowA whether I got that from Info-VAX or directly from him.  I suspecte@ that if you dig up the Info-VAX archives from that time frame orB the DECUS VAX SIG tapes (they weren't called VMS SIG tapes yet...)5 from the following spring you could probably find it.s   > <thinks> Don't think itl> > has 39+39, real info on ACLs or the shadow/SCB stuff though. >u > No ODS-5, needless to add.  C      No, it's a draft which appears to predate the first release ofvA VMS.  There's a lot of RSXisms, but it does describe the reservedoC files in [000000], directory layout, and the file header layout forpA pre-V4.0 (9.3 file name length limit) files, and no doubt various C other things that I've forgotten such as prologue version 1 indexed  files.  2                 Pat Rankin, rankin@eql.caltech.edu   ------------------------------    Date: 17 Apr 2001 16:21:55 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e5 Subject: Re: Star Office progress report (on Solaris),3 Message-ID: <scv1HTkGMaqa@eisner.encompasserve.org>5  ] In article <3ADC03F7.B9A526D0@uk.sun.com>, andrew harrison <andrew.nospam@uk.sun.com> writes:  > Keith Brown wrote: >>   >> Larry Kilgallen wrote:  >> >? >> > > X-NEWS: eisner.encompasserve.org comp.sys.sun.apps: 2842  >> > > Path: iad-read.news.verio.net!dfw-artgen.news.verio.net!dfw-peer.news.verio.net!news.verio.net!newsfeed.mathworks.com!sunqbc.risq.qc.ca!news.maxwell.syr.edu!news.cis.ohio-state.edu!malgudi.oar.net!news.cas.org!not-for-mail  >> > > From: lvirden@cas.org$ >> > > Newsgroups: comp.sys.sun.apps    K >> I presume from your post that you are trying to run SO on Solaris. WhilepG >> I have no experience with Solaris I can say that I have been runningOI >> StarOffice on Linux for about a year and I am very pleased with it.  I7J >> just wish someone would be kind enough to port it to OpenVMS for me :-) >>   > D > I also find it difficult to believe that you cannot get StarOfficeE > to run on Solaris. I run 5.2 and 6 beta on Solaris for Sparc/Intel aC > and win98. I havn't had problems running it on any of these OS's pD > and it has been as reliable as the alternatives (Office) on win98.  E Personally I do not have a Solaris machine and I have not been tryingkF to get StarOffice to run on any machine.  There was discussion in thisD group about porting StarOffice to VMS, so I wanted to point out thisF discussion in another newsgroup to those from this newsgroup who might be involved in such an effort.  G I am not surprised that anyone would have trouble getting any arbitrary F software to run on any arbitrary operating system, but whether this isE the fault of StarOffice or the person attempting it can be studied byo2 those considering (or involved in) porting to VMS.   ------------------------------  % Date: Tue, 17 Apr 2001 20:00:09 -0400e, From: "islandco.com" <dbturner@islandco.com>K Subject: Re: Talk to Rich Marcello, but DOES HE LISTEN? - Austin Texas area / Message-ID: <tdpm3q8mhe4m49@news.supernews.com>h  	 FYI David   & You couldn't be further from the truth  = We make around $120 on the "Blow Out"  systems as configured.aI These were long term rental systems, and for us to get the deal we had ton scrape through on margin. @ Not that we will not make more cash from these people next time.  J As for our accountant - she is quite happy with our annual results, thoughA our  average margin is actually more realistically around 25-28%.m  L IF, yes IF, we had these in stock for $200 each, then we would sell them forF around $400, because it has to be worth our stocking and refurbishing.  J Remember, except for these blow-out PWS systems, we put in NEW CDROMs, newG floppy, NEW memory, NEW cache, NEW video card, NEW hard disk drive, NEWdG front door assembly and we respray the panels of the system if requireda  E Try buying even just the video card fo rless than $150 anywhere USED.i  K As for retiring, I am 35 - and have no intention or capacity to retire - itl5 was a meagre comment not meant to be taken seriously.u  K For all those in the Educational and Government Employ - the privat esectoru ain't what it used to be !!!!    :0(p     David T      -- David Turner Island Computers US Corporation0 2700 Gregory Street  Savannah GA 31404  Tel: 912 447 6622  Fax:912 201 0096 sales@islandco.com? "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message-& news:9b7dbe$6n7@gap.cco.caltech.edu...E | In article <mbiddtsebejrlre6o06ojpjhb2oqvqs49o@4ax.com>, Alan GreigV <a.greig@virgin.net> writes: | >nG | >If Island can ship EV56 systems with unused DEC motherboards (au andiB | >164LX series) running at up to 600 Mhz for less than a thousandF | >dollars which make ideal hobby machines then surely Compaq could do | >something similar.e | 	 | Or not.  |eL | Now I don't now what Island's profit margin is, but you can be pretty sureI | they didn't pay more than a couple of hundred dollars for those systemseI | they're "blowing out" for <$1000.  (Partially I base this on an off thenK | cuff comment that if all the machines on hand were sold, the seller couldbL | retire.)  That suggests that Compaq doesn't have any of these left, havingK | essentially dumped all of their old machines to Island and other vendors. K | That they had this much stock to dump is of course a direct result of theyL | overpricing of their products (THEY NEVER LISTEN!) and the inadequacies ofG | their inventory control.  I bet their accountants made it appear thato there2I | was at least a 50% margin on every EV56 workstation sold. And I'll alsoa bettK | that one of the ways that they did this was to post the loss from dumpingrJ | all of these unsold systems went into a completely separate category, so. | that the margin numbers wouldn't be reduced. |o
 | Regards, |I | David Mathog | mathog@seqaxp.bio.caltech.edu @ | Manager, sequence analysis facility, biology division, Caltech   ------------------------------  % Date: Tue, 17 Apr 2001 13:03:43 -0500d@ From: Brenda Westergren Deimerly <bmwester@collins.rockwell.com>) Subject: Re: TCPIP v5.0A MAP command hang 4 Message-ID: <3ADC857F.E487204D@collins.rockwell.com>  K For further clarification, I have discovered that the SHOW MAP command onlyh@ seems to hang when I have a MAP command going on another system.   Brenda Westergrenw  ! Brenda Westergren Deimerly wrote:o   >tH > Most of the cluster has been up for 23 or 78 days.  On these nodes theF > SHOW MAP command hangs on /disk2 and /disk8, but not for our other 8G > maps.  Most importantly, NFS IS WORKING to /disk2 and /disk8 on these  > nodes. >  > Thank you for your time, > Brenda Westergrenr > Rockwell Collins   ------------------------------    Date: 17 Apr 2001 12:51:59 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) * Subject: RE: tuning VMS for Oracle7 Server, Message-ID: <Akvvo3q7PHFY@malvm1.mala.bc.ca>  A In article <1245D1C0C039D411933708002BB29C644B298D@DOAISD02003>,  1   "Rowell, Bradley" <browell@state.mt.us> writes:  >  > K > If you are using UCX 4.2 or older you will gain a performance increase byo > upgrading toD > UCX 5.0a, Oracle with 4.2 sometimes sends the data multiple times. >   3     I'm using TCP/IP Services 5.1 ( OpenVMS 7.2-1 ):   ------------------------------  # Date: Wed, 18 Apr 2001 00:44:54 GMT.% From: bdc@world.std.com (Brian Chase)c5 Subject: Re: Using 3-phase power converters on VAXen?w& Message-ID: <GByq2v.Ct0@world.std.com>  3 In article <lix8PF$y8OVv@eisner.encompasserve.org>,n4 John E. Malmberg <malmberg@encompasserve.org> wrote:  E > For those of you who have not had formal training with using higherTG > than 20A house hold currents, and are toying with the idea of gettingu > their own 3-phase toys:   J In the case of my three phase toy, a VAX 6000, I've been told that it onlyD takes about 600-700W to run diskless config I have.  At 208V, that'sG around 3-3.5A.  So even if the power consumption is say 5A, I should begA able to handle that fairly neatly on a common 15A or 20A circuit.   A > The symptom of "infant mortality" for a new breaker can be that)J > it explodes with the force of a hand grenade.  Professional ElectriciansD > really do use "10 foot poles" to touch these under load, and stand/ > to the side, out of the potential blast zone.s  H Is that relatively common?  Even at 1 in a 1000 or 1 in 10,000 odds, I'mJ guessing this would be grounds for some extremely costly lawsuits directed, towards the manufacturers of those breakers.   -brian.n -- vF --- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----C IT'S SOMETHING INTANGIBLE, NOT WRITTEN JUST TO PLEASE.  -- MegaHAL.e* http://www.amristar.com.au/~hutch/megahal/   ------------------------------  % Date: Tue, 17 Apr 2001 21:45:31 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> $ Subject: Re: VMS-Related: Affordable( Message-ID: <9birj0$a3h$1@pyrite.mv.net>  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4puebedtz.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...+ > "Bill Todd" <billtodd@foo.mv.com> writes:t >eH > > > But then you're not using the calls provided by the C RTL, but the system > > > call directly.> * > > So will a 'raw' device access on Unix. >yK > That's the equivalent of a logical/physical I/O under VMS. On a disk, youo canr@ > still do a $QIO or block-mode RMS I/O on a file (virtual I/O). >sH > > MSVC++'s fread interface description indicates that you provide it a pointeruK > > to where you want the data, which means that if indeed the C RTL simply K > > passes the pointer down through the system interface (e.g., to ReadFilet in aK > > Win32 environment), the system deblocks whatever you requested from its K > > internal block-structured buffer and moves it directly to your buffer -e ao > > single copy operation. >wI > Which leaves you, still, with one kernel-to-user-memory copy operation.e ButaJ > you do get the deblocking. OTOH, you can't do block-aligned I/O with the dataL > being deposited directly in the user-mode buffer, as $QIO will do for you.  G So what?  This sub-discussion began with my suggestion that even with a L fully-functional XFC normal data access (via non-block-I/O RMS or the C RTL)I would still be at a slight disadvantage w.r.t. a typical Unix environmenteH due to the second data copy operation involved (once in the XFC layer, aC second time in the RMS layer).  Nothing has surfaced to change thatg observation.   - bill   >e > Jann   ------------------------------  % Date: Tue, 17 Apr 2001 18:47:00 -0700s From: <tsmurphy@addr.com>r> Subject: Re: Why is this a Bad Thing? (was: Future Computing.)6 Message-ID: <tn6D6.2980$AF2.1351062@nntp3.onemain.com>  0 Alan Greig <a.greig@virgin.net> wrote in message$ news:3ADC5E3F.D56E0DD9@virgin.net... > JF Mezei wrote:nJ > > Remember that this "80%" is really the industry standard servers (aka: 8086I > > based enterprise servers) with VMS and Unix helping. It does not meanl that 80%6 > > of Compaq's profits are generated by VMS and Unix. >hI > In this case though I think it very nearly does mean this. Somewhere ono
 the CompaqI > site there's a slide showing income per O/S. VMS is still at $4billion,o	 Tru-64 atfL > $3 Billion, ISSG at $7 billion. The (suspected) margins on VMS alone would seem to I > suggest that 80% of Compaq's recent profits come from VMS alone - neverw
 mind Unix.  H There is absolutely no way that VMS/Tru64 make up billions of dollars ofG profit per year. Absolutely no chance whatsoever. There are a couple of $ different ways you can look at this:  G 1. In '00, Dell made $2.3 billion in profit (selling absolutely nothingrL besides PC's) and Compaq made less than $0.6 billion. Since Compaq's PC unitI is even bigger than Dell's, the only plausible explanation is that CompaqhE PC's division made $2.3 billion or more in profit and Compaq's non-PChJ division (Tandem & DEC stuff) lost $1.7 billion or more (after all, CompaqK is nothing more than Dell with an unprofitable and inefficient 'enterprise'h unit kludged on).e  K 2. DEC historically made very little money from VMS/Tru64. The company lost-F money every year in the 90's. The biggest driver of growth in the pastE several years was the internet. Two-thirds of servers are Intel-basedtK (Windows, Linux), and most of the rest are Sun based, with some HP and IBM.iL So, VMS/Tru64 have grown very little since Compaq bought them. You expect meD to believe -- even though these products did not grow in the biggestJ technology expansion in history -- that they were miraculously turned fromF money losing products into billion dollar products. That is absolutely ridiculous.   L I suspect that of that 80%, about 150% is made from Intel based servers, and' that about -50% is made from VMS/Tru64.s   ------------------------------  % Date: Tue, 17 Apr 2001 22:18:56 -0400q' From: "Bill Todd" <billtodd@foo.mv.com> > Subject: Re: Why is this a Bad Thing? (was: Future Computing.)( Message-ID: <9bithl$g30$1@pyrite.mv.net>  E Why is it that the most clueless individuals are always the ones mosto  certain of their misconceptions?  J At any rate, while I don't have access to '00 figures, I do recall (from AD Source Who Was Unquestionably In A Position To Know For A Fact) thatI VMS-related contributions in 1999 to Compaq's *profit* totaled about $0.8aJ billion.  AFAIK, VMS margins haven't dropped significantly since then, and5 VMS shipments are if anything up a bit.  Do the math.    - bill  $ <tsmurphy@addr.com> wrote in message0 news:tn6D6.2980$AF2.1351062@nntp3.onemain.com...2 > Alan Greig <a.greig@virgin.net> wrote in message& > news:3ADC5E3F.D56E0DD9@virgin.net... > > JF Mezei wrote:,L > > > Remember that this "80%" is really the industry standard servers (aka: > 8086K > > > based enterprise servers) with VMS and Unix helping. It does not mean.
 > that 80%8 > > > of Compaq's profits are generated by VMS and Unix. > > K > > In this case though I think it very nearly does mean this. Somewhere on  > the CompaqK > > site there's a slide showing income per O/S. VMS is still at $4billion,a > Tru-64 at H > > $3 Billion, ISSG at $7 billion. The (suspected) margins on VMS alone would 	 > seem to0K > > suggest that 80% of Compaq's recent profits come from VMS alone - nevere > mind Unix. > J > There is absolutely no way that VMS/Tru64 make up billions of dollars ofI > profit per year. Absolutely no chance whatsoever. There are a couple ofa& > different ways you can look at this: >sI > 1. In '00, Dell made $2.3 billion in profit (selling absolutely nothingnI > besides PC's) and Compaq made less than $0.6 billion. Since Compaq's PCf unitK > is even bigger than Dell's, the only plausible explanation is that Compaq G > PC's division made $2.3 billion or more in profit and Compaq's non-PCvL > division (Tandem & DEC stuff) lost $1.7 billion or more (after all, Compaq@ > is nothing more than Dell with an unprofitable and inefficient 'enterprise' > unit kludged on).R >OH > 2. DEC historically made very little money from VMS/Tru64. The company lostH > money every year in the 90's. The biggest driver of growth in the pastG > several years was the internet. Two-thirds of servers are Intel-based H > (Windows, Linux), and most of the rest are Sun based, with some HP and IBM.K > So, VMS/Tru64 have grown very little since Compaq bought them. You expectf meF > to believe -- even though these products did not grow in the biggestL > technology expansion in history -- that they were miraculously turned fromH > money losing products into billion dollar products. That is absolutely
 > ridiculous.( > J > I suspect that of that 80%, about 150% is made from Intel based servers, and ) > that about -50% is made from VMS/Tru64.e >  >    ------------------------------  # Date: Wed, 18 Apr 2001 03:40:17 GMTp- From: Terry C Shannon <shannon@world.std.com>_> Subject: Re: Why is this a Bad Thing? (was: Future Computing.)D Message-ID: <Pine.SGI.4.21.0104172336330.25330-100000@world.std.com>  , On Tue, 17 Apr 2001 tsmurphy@addr.com wrote:  2 > Alan Greig <a.greig@virgin.net> wrote in message& > news:3ADC5E3F.D56E0DD9@virgin.net... > > JF Mezei wrote:eL > > > Remember that this "80%" is really the industry standard servers (aka: > 8086K > > > based enterprise servers) with VMS and Unix helping. It does not mean1
 > that 80%8 > > > of Compaq's profits are generated by VMS and Unix. > >.K > > In this case though I think it very nearly does mean this. Somewhere onr > the CompaqK > > site there's a slide showing income per O/S. VMS is still at $4billion,r > Tru-64 at N > > $3 Billion, ISSG at $7 billion. The (suspected) margins on VMS alone would	 > seem todK > > suggest that 80% of Compaq's recent profits come from VMS alone - neverf > mind Unix. > J > There is absolutely no way that VMS/Tru64 make up billions of dollars ofI > profit per year. Absolutely no chance whatsoever. There are a couple ofe& > different ways you can look at this: > I > 1. In '00, Dell made $2.3 billion in profit (selling absolutely nothingsN > besides PC's) and Compaq made less than $0.6 billion. Since Compaq's PC unitK > is even bigger than Dell's, the only plausible explanation is that Compaq:G > PC's division made $2.3 billion or more in profit and Compaq's non-PCjL > division (Tandem & DEC stuff) lost $1.7 billion or more (after all, CompaqM > is nothing more than Dell with an unprofitable and inefficient 'enterprise'  > unit kludged on).a >   / Well, that's an, umm, "interesting" conclusion.L   ------------------------------  # Date: Wed, 18 Apr 2001 04:18:57 GMTp From: LBohan@dbc.spam_less..com:> Subject: Re: Why is this a Bad Thing? (was: Future Computing.)8 Message-ID: <7m3qdtch93tj67om8hp49aioau3ehbd64p@4ax.com>  > On Tue, 17 Apr 2001 18:47:00 -0700, <tsmurphy@addr.com> wrote:  I >There is absolutely no way that VMS/Tru64 make up billions of dollars ofpH >profit per year. Absolutely no chance whatsoever. There are a couple of% >different ways you can look at this:   7 Could be.  But then there's this (dated) USEnet quote, n citing "Mr Affinity".. xF (w/ DejaNews having gone downhill, I don't have the original posting)      ....> On the other hand, Wes Melling did comment back in May 1998 in> Stoke-on-Trent that OpenVMS Software Support makes more money B than the whole of the rest of Digital and makes more than Compaq's0 entire server business (Classic Compaq that is). ...y   ------------------------------   End of INFO-VAX 2001.216 ************************