0 INFO-VAX	Mon, 22 Jan 2001	Volume 2001 : Issue 44      Contents: $setimr problem 7 Re: Apache web server:  Actively discarding privileges? + Re: Bootup TK70 drive problem? or is it ... ! Re: Calculate a percentage in DCL ! Re: Calculate a percentage in DCL 4 Re: Compaq: A simple, affordable clustering solution4 RE: Compaq: A simple, affordable clustering solution4 RE: Compaq: A simple, affordable clustering solution4 RE: Compaq: A simple, affordable clustering solution4 Re: Compaq: A simple, affordable clustering solution4 Re: Compaq: A simple, affordable clustering solution4 Re: Compaq: A simple, affordable clustering solution4 Re: Compaq: A simple, affordable clustering solution RE: Copying disk ? Re: Copying disk ?! Re: digital PrintServer 17 600 ps + Re: Don't know whether to laugh or cry.....  Re: DS20 - Slow I/O & Re: Dual ethernet config for failover? eBay down again. Re: eBay down again. Re: eBay down again. Re: eBay down again. Re: eBay down again.@ ES40 Quikspecs (was: Re: Compaq continues the Digital Tradition) Expect my address to change  Re: Ghostscript v6.50  Re: GS160 hardware question  RE: GS160 hardware question  Re: GS160 hardware question  Re: GS160 hardware question  Re: GS160 hardware question  RE: GS160 hardware question  Re: GS160 hardware question  Re: GS160 hardware question  RE: GS160 hardware question  RE: GS160 hardware question  Re: GS160 hardware question  Re: GS160 hardware question  Re: GS160 hardware question  Re: GS160 hardware question 4 Re: Has anyone sucessfully ported SMG from VMS to NTE Is there any real successor of the PrintServer printers (LPS20&LPS17) $ Re: Linux worm and RedHat 7.0 broken$ Re: Linux worm and RedHat 7.0 broken$ Re: Linux worm and RedHat 7.0 broken Multiple path devices... Re: Multiple path devices...! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line ! Re: New OpenVMS Times now on line 4 Re: No technical computing, was: expanding the niche4 Re: No technical computing, was: expanding the niche4 Re: No technical computing, was: expanding the niche4 Re: No technical computing, was: expanding the niche Re: Oldtimer forgot!) Re: Open VMS mail and set forward numbers ( Re: RA230+ (KZPAC-CA) and 18/36 GB DisksN Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)N Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)N Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)N Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)N Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion) Re: Remote boot via DECnet?  Re: samba 2.0.3 : NT client  Re: samba 2.0.3 : NT client  Re: samba 2.0.3 : NT client H Script to read directory of all drives, clustered, shared, etc. at once?L Re: Script to read directory of all drives, clustered, shared, etc. at once? Re: TCPIP$BIND: dynamic updates  Re: TCPIP$BIND: dynamic updates  Re: TCPIP$BIND: dynamic updates  test Re: the value of "/" in FTP 9 Re: To Hoff Hoffman: Any news about the VMS DHCP client ? 9 Re: To Hoff Hoffman: Any news about the VMS DHCP client ? 9 Re: To Hoff Hoffman: Any news about the VMS DHCP client ?  Re: Variables in DCL RE: vms not an option?  F ----------------------------------------------------------------------  # Date: Mon, 22 Jan 2001 18:05:56 GMT  From: cstranslations@msn.com Subject: $setimr problem) Message-ID: <94hsps$u35$1@nnrp1.deja.com>   8 Let's see how much criticism I can open myself upto. . .   OpenVMS 7.1-1H2, BASIC V1.2-000   B Q: Is there any reason as to why (or how) $setimr would decided to return ss$_bufferovr?   . The code sequence in question runs as follows:  @ 3862 result = sys$qio( , chan by value, io$_readvblk by value, &@ 3863                  qiosb, MailBoxAST, chan, claim,          &@ 3864                  len(claim::ClaimOverlay) by value, , , , )# 3865 if (result <> ss$_normal) then & 3866    call lib$stop(result by value) 3867 end if  3868 3869 FifteenMinutes = space$(8) 4 3870 call sys$bintim("0 :15", FifteenMinutes by ref) 3871C 3872 result = sys$setimr( , FifteenMinutes by ref, CloseDropsChan,& / 3873                     DropsTimer by value, ) # 3874 if (result <> ss$_normal) then & 3875    call lib$stop(result by value) 3876 end if   C This is code for a process that runs as a detached process. The wee B hours of this morning it decided to fall over and die on line 3875 (with ss$_bufferovr).   G I'm guessing the offending argument was the wake time (FifteenMinutes). B This kinda sorta doesn't seem to make much sense. It's a read onlyG argument and it's passed by reference. I could (possibly) see an accvio 4 if FifteenMinutes was a string of less than 8 bytes.   An ideas welcome.    Joe      Sent via Deja.com  http://www.deja.com/   ------------------------------   Date: 22 Jan 2001 14:24:11 GMT= From: jlw@psulias.psu.edu (j.lance wilkinson, (814) 865-1818) @ Subject: Re: Apache web server:  Actively discarding privileges?, Message-ID: <94hfqb$15gm@r02n01.cac.psu.edu>  d In article <6%0a6.37661$lV5.464626@news2.giganews.com>, "Andy Stoffel" <acs@fcgnetworks.net> writes:K >"j.lance wilkinson, (814) 865-1818" <jlw@psulias.psu.edu> wrote in message & >news:949s2k$u00@r02n01.cac.psu.edu... > M >>         Well, no it didn't.  Installed my test script which does the above M >>         described procedures with BYPASS, WORLD, CMKRNL, SYSPRV and SYSLCK L >>         privileges.  Confirmed that it IS installed.  Ran it from Apache.E >>         Image Privileges: NONE.  Ran it from under OSUHTTPD, Image  >Privileges:J >>         BYPASS, CMKRNL, SYSLCK, SYSPRV and WORLD.  Again, it seems like >theE >>         Apache server is actively thwarting any use of privileges.  > K >Hmmm... I haven't had any problems with that.... seems to work fine for me G >on the systems I've installed Apache/CSWS on.... & yes, I WOULD notice  >if it was doing that %-).  @ 	OK, can you share some code samples with me?  I was thinking of> 	maybe a small sample program that demonstrates activation of A 	privileges that are AUTHORIZED while not DEFAULTED.  I'd compile A 	and run said code here to see if under MY combination of OpenVMS > 	v7.2-1H1, Multinet v4.2B, and DECC the program fails while inC 	your installation it succeeds.  THAT would be fuel for my incident  	open with Colorado Springs....   M +-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+ N | J.Lance Wilkinson ("Lance")            InterNet:  Lance.Wilkinson@psu.edu | M | Systems Design Specialist - Lead       AT&T:      (814) 865-1818          | M | Library Computing Services             FAX:       (814) 863-3560          | M | E3 Paterno Library                     "I'd rather be dancing..."         | M | Penn State University         A host is a host from coast to coast,       | M | University Park, PA 16802     And no one will talk to a host that's close | M | <postmaster@psulias.psu.edu>  Unless the host that isn't close            | M | VMS GopherMeister             Is busy, hung or dead.                      | M +------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+ 9                 [apologies to DeForest Kelley, 1920-1999] 3 <A Href="http://perdita.lcs.psu.edu">home page</a>  J <a Href="http://perdita.lcs.psu.edu/junkdec.htm">junk mail declaration</a>   ------------------------------    Date: 22 Jan 2001 10:49:48 -0500* From: nsg9719@osfmail.isc.rit.edu (GAFFIN)4 Subject: Re: Bootup TK70 drive problem? or is it ...' Message-ID: <3a6c569c@news.isc.rit.edu>   6 In article <94a710$lqv$1@mailint03.im.hou.compaq.com>,3 Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote:  > U >In article <3a686138@news.isc.rit.edu>, nsg9719@osfmail.isc.rit.edu (GAFFIN) writes:  > [...] G >  Four-slot hard disk chassis?  I'll GUESS that this is a BA123 series F >  enclosure -- this box looks like a coffee table on casters.  Three F >  (hard) disk slots are stacked vertically on the end with the power G >  button, with one slot adjacent to this stack that is typically used   >  for RX50 or TK tape...     5 This might be unlike anything you've ever dealt with. - I could be wrong. Here is what it looks like:   ( http://www.rit.edu/~nsg9719/chassis.html  , There are 7 pictures of the scenario, should+ anyone care to take a look. I can get close 2 ups of the cards, and what is behind them, altough it may not be relevant.    > F >  The other common enclosure is the BA23 -- a pedestal enclosure (andG >  no casters), sometimes refered to as the "space heater" enclosure...  > > >  The BA23 has nine Q-bus slots, BA123 and BA213 have twelve. >  > [...]  > L >  Please describe the Q-bus modules installed in the BA-series enclosure.  I >  Specifically, provide the M-number off the spine of the Q-bus modules, G >  and the exact slot occupancy.  (Up to two dual-width Q-bus cards can I >  reside in a single Q-bus (Q22/Q22) slot.)    One of these will likely  H >  be a TQK70 controller.  The TQK70 M-number is M7559.  The two common D >  disk controllers are RQDX3 (M7555) and KDA50 (M7164 and M7165)... > H >  See the Ask The Wizard area for discussions of correctly configuring B >  the Q-bus -- search for "serpentine".  Start with topic (1149).  6 I will search the documentation I was handed, and then6 take a closer look. I am thinking this could very well be a power supply problem...   Thanks,  Neil G.    ------------------------------   Date: 22 Jan 2001 16:44:16 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)* Subject: Re: Calculate a percentage in DCL, Message-ID: <94ho10$5g1@gap.cco.caltech.edu>  F In article <94ald1$es2$1@nnrp1.deja.com>, jbecker@ui.urban.org writes:G >Hmmm, who'd have thought there'd be so many responses to such a simple 	 >request?  > H >For the specific case of checking for the 10% threshold, you don't have! >to worry about integer overflow: , >$ if free .lt. total/10 then goto send_mail >  <SNIP>  L If you load ICALCV you can get real percentages, and then post process them  any way you want.  Example:    $ icalc 20/100; 40/100; 50/100         0.2          0.4          0.5  $ write sys$output icalc_out#         0.2,        0.4,        0.5      Pick it up from:  7   http://seqaxp.bio.caltech.edu/pub/SOFTWARE/ICALCV.ZIP    Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech     ------------------------------  # Date: Mon, 22 Jan 2001 17:11:32 GMT  From: jbecker@ui.urban.org* Subject: Re: Calculate a percentage in DCL) Message-ID: <94hpjr$r3u$1@nnrp1.deja.com>   D Oops. I just noticed an error in my posting. It affects only certain* ranges of values, but it's still an error.  % The corrected version of PERCENT.COM:    > $ maxint = %x7fffffff  > $ p1 = f$integer (p1)  > $ p2 = f$integer (p2)  > $ if p1 .gt. maxint/100  > $ then > $       multiplier = 1 > $       divisor = p2/100 > $ else > $       multiplier = 100 > $       divisor = p2	 > $ endif  > $ if p1 + divisor/2 .lt. 0   The above line should be: ' $ if p1 * multiplier + divisor/2 .lt. 0    > $ then > $       rounding = 0 > $ else > $       rounding = divisor/2	 > $ endif 5 > $ percent == (p1 * multiplier + rounding ) /divisor    --
 Jim Becker+ The Urban Institute (http://www.urban.org/) 7 Encompass ESILUG (http://eisner.decus.org/lugs/esilug/)      Sent via Deja.com  http://www.deja.com/   ------------------------------  % Date: Mon, 22 Jan 2001 09:09:48 +0000 0 From: andrew harrison <andrew.nospam@uk.sun.com>= Subject: Re: Compaq: A simple, affordable clustering solution ) Message-ID: <3A6BF8DC.7D48BAC@uk.sun.com>    Jordan Henderson wrote:  >  > I > Ever since I can recall, and certainly since the early 80's, there have I > been those in the UNIX camp (and later to a certain extent, the Windows H > camp) who have denigrated OpenVMS as a hopelessly backward dinosaur, aH > Mainframe wannabee operating system that has no future beyond the nextI > wave of innovation that surely is coming.  Those waves have washed over D > the IT landscape time and time again, and I still see OpenVMS withJ > capabilities and attributes still not available elsewhere.  However, theF > detractors continute to snipe.  After many years of this, it takes aH > definite toll on the professional who wants to have current skills andG > be ready for that next wave that surely will, this time, wash OpenVMS  > completely away. >   < Jordan, I have never suggested that OpenVMS is a hopelessly 8 backward dinosaur. In fact quite the opposite. I have a & great deal of respect for technology.   : There are areas where OpenVMS does not excel, file I/O for9 example, but I have not been involved in highlighting its  deficiencies in this area.  > I have suggested however that OpenVMS is hopelessly supported,= sold and marketed by Compaq and before them Digital. Perhaps  > the best example of this spilling through into the technology < is the area of TCP/IP. There is no doubt that Digitals poor = support for IP in OpenVMS origionally making it an unbundled  9 product was a huge mistake. Almost certainly a marketing  8 decision that has had overspill into the technology but 9 more important it made it more difficult for customers to $ use OpenVMS as an Internet platform.  : I have suggested that ISV support for OpenVMS is very poor8 and this is undeniable. This poor support has little to 8 do with the technology and almost everything to do with 3 Compaqs handling of OpenVMS as one of their brands.   5 I say almost everything because the decision to drop  3 POSIX support from OpenVMS was not helpfull in this  respect.  2 I have suggested that OpenVMS support for Java is 3 poor, it is but it only reflects Compaqs underlying 0 confusion over what to do with Java, support it 4 wholeheartedly like IBM and brave the wrath of their3 most feared partner MS or help MS try and kill it.    J > This is Andrew's real message.  He's been alluding to it for years, thatM > OpenVMS is in an irrevsible downward spiral and, by implication, that smart L > professionals had better gain some UNIX skills now, before the tide washesE > their career as well.  This war for the hearts and minds of OpenVMS F > professionals is faught in public forums, not with Compaq marketing. >   5 That is not my real message, sorry you can draw that  8 conclusion from my "message" but that isn't the message.  > My message is that you cannot trust Compaq directly or people = quoting unattributable sources close to or inside Compaq when < they make any kind of marketing/sales/positioning statement  about OpenVMS.    < Digital/Compaq have missled OpenVMS customers for years over= the state of and their intentions for the OpenVMS market. Now = this is probably because neither Digital nor Compaq have been 3 able to work out what their intentions ought to be.   : Perhaps a good example of how people are being missled is : the current crop of "OpenVMS wins" being trumpeted by your7 favourite Compaq employee. Very few people count losing = most of a companys platform infrastructure to other vendors,  9 while retaining a backend server platform which has been  : upgraded from large (high service revenue) servers to much: smaller lower cost systems as a win. Winning is increasing; your footprint in a customers infrastructure and if you are 7 in sales increasing your annual revenues, only a Compaq 6 Marketing person could describe the opposite as a win.     Regards  Andrew Harrison  Enterprise IT Architect    ------------------------------  % Date: Mon, 22 Jan 2001 06:25:34 -0600 + From: "Main, Kerry" <Kerry.Main@compaq.com> = Subject: RE: Compaq: A simple, affordable clustering solution N Message-ID: <910612C07BCAD1119AF40000F86AF0D805284C72@kaoexc3.kao.cpqcorp.net>   Andrew,   3 Back at work I see .. We missed you on the weekend.    :-)   I >>> Perhaps a good example of how people are being missled is the current I crop of "OpenVMS wins" being trumpeted by your favourite Compaq employee. J Very few people count losing most of a companys platform infrastructure toH other vendors,  while retaining a backend server platform which has beenH upgraded from large (high service revenue) servers to much smaller lowerJ cost systems as a win. Winning is increasing your footprint in a customersL infrastructure and if you are in sales increasing your annual revenues, onlyB a Compaq Marketing person could describe the opposite as a win.<<<  J Wow - pretty poor fud - even for you Andrew. The Eurex was a NEW win for a: NEW project with the CBOT. As was the Sydney Exchange win.  J I guess thats the difference between us. You stated that winning is simply increasing your box footprint.  B I view winning as gaining a Customers confidence that what you areL delivering is a solid solution that will meet their business requirements.    H I view winning as doing things that cause industry analysts like GartnerE Group, who for years have had doubts about OpenVMS now publish a very  positive report on it.L <http://enterprise.cnet.com/enterprise/0-9566-707-1751615.html?tag=st.it.956 >a5 Quote - "Tru64 Unix and OpenVMS are proven winners." m  J Its a multi-platform world and there is no one solution or one OS platform8 that will address all requirements, so whats your point?  I If increasing your footprint is Sun's main measurement of success, how doeK you explain all the server consolidation projects that are going on in manySH medium-large companies ie. the concept of replacing many smaller serversL with fewer (but larger), centralized and in many cases, clustered servers ??  G While it might be important to you, counting boxes is imho, a very poor L measurement of success. It is not a measurement criteria used by a solutions	 provider.d   Regards,  
 Kerry Main Senior Consultant  Compaq Canada Inc. Professional Servicesr Voice: 613-592-4660e Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]l Sent: January 22, 2001 4:10 AM To: Info-VAX@Mvb.Saic.Comi= Subject: Re: Compaq: A simple, affordable clustering solutionp     Jordan Henderson wrote:  >  > I > Ever since I can recall, and certainly since the early 80's, there haveeI > been those in the UNIX camp (and later to a certain extent, the WindowsmH > camp) who have denigrated OpenVMS as a hopelessly backward dinosaur, aH > Mainframe wannabee operating system that has no future beyond the nextI > wave of innovation that surely is coming.  Those waves have washed over D > the IT landscape time and time again, and I still see OpenVMS withJ > capabilities and attributes still not available elsewhere.  However, theF > detractors continute to snipe.  After many years of this, it takes aH > definite toll on the professional who wants to have current skills andG > be ready for that next wave that surely will, this time, wash OpenVMSt > completely away. >   < Jordan, I have never suggested that OpenVMS is a hopelessly 8 backward dinosaur. In fact quite the opposite. I have a & great deal of respect for technology.   : There are areas where OpenVMS does not excel, file I/O for9 example, but I have not been involved in highlighting itse deficiencies in this area.  > I have suggested however that OpenVMS is hopelessly supported,= sold and marketed by Compaq and before them Digital. Perhaps c> the best example of this spilling through into the technology < is the area of TCP/IP. There is no doubt that Digitals poor = support for IP in OpenVMS origionally making it an unbundled -9 product was a huge mistake. Almost certainly a marketing  8 decision that has had overspill into the technology but 9 more important it made it more difficult for customers to3$ use OpenVMS as an Internet platform.  : I have suggested that ISV support for OpenVMS is very poor8 and this is undeniable. This poor support has little to 8 do with the technology and almost everything to do with 3 Compaqs handling of OpenVMS as one of their brands.r  5 I say almost everything because the decision to drop &3 POSIX support from OpenVMS was not helpfull in thism respect.  2 I have suggested that OpenVMS support for Java is 3 poor, it is but it only reflects Compaqs underlying 0 confusion over what to do with Java, support it 4 wholeheartedly like IBM and brave the wrath of their3 most feared partner MS or help MS try and kill it. 2  J > This is Andrew's real message.  He's been alluding to it for years, thatG > OpenVMS is in an irrevsible downward spiral and, by implication, that  smart L > professionals had better gain some UNIX skills now, before the tide washesE > their career as well.  This war for the hearts and minds of OpenVMSdF > professionals is faught in public forums, not with Compaq marketing. >   5 That is not my real message, sorry you can draw that )8 conclusion from my "message" but that isn't the message.  > My message is that you cannot trust Compaq directly or people = quoting unattributable sources close to or inside Compaq whena< they make any kind of marketing/sales/positioning statement  about OpenVMS. j  < Digital/Compaq have missled OpenVMS customers for years over= the state of and their intentions for the OpenVMS market. Now = this is probably because neither Digital nor Compaq have beeng3 able to work out what their intentions ought to be..  : Perhaps a good example of how people are being missled is : the current crop of "OpenVMS wins" being trumpeted by your7 favourite Compaq employee. Very few people count losinge= most of a companys platform infrastructure to other vendors, W9 while retaining a backend server platform which has been  : upgraded from large (high service revenue) servers to much: smaller lower cost systems as a win. Winning is increasing; your footprint in a customers infrastructure and if you aree7 in sales increasing your annual revenues, only a CompaqP6 Marketing person could describe the opposite as a win.     Regardsi Andrew Harrison  Enterprise IT Architecte   ------------------------------  % Date: Mon, 22 Jan 2001 12:43:56 +0000h  From: steven.reece@quintiles.com= Subject: RE: Compaq: A simple, affordable clustering solutionSH Message-ID: <OFDDC6F6EA.292B2904-ON802569DC.0044EEE0@qedi.quintiles.com>  H I agree with Kerry that counting boxes is not the correct measurement of success.D For that matter though, reduction of boxes is not the measurement of success either.   K Success (IMNSHO) has to be measured in whether the client is actually happy H with the solution provided and whether it fulfils the criteria that were put forward for the project.  F For example, the ebay problems (whether caused by Sun or a third partyI supplier or by the designers or whoever) mean that that solution is not a I success.  On the other hand there must be hundreds of other installations J that are successes for Sun as they fulfil (and probably exceed) all of the design criteria.  K The VMS installation that was planned by one of my former employers was notoJ a success since they had to upsize their systems (from 2100s to 4100s) andD then pulled out of the deployment of the systems after the 11th hourJ (probably at about 11 and a half) and went with a different solution basedI around SAP.  Their customers weren't happy with the SAP deployment in the J early stages so, unless that has been rectified, that would not be classedK as a success either.  The VMS solution that I manage at Quintiles is thoughl< since it has more than satisfied all of the design criteria.   Steve.   Kerry Main wrote:eJ >>>While it might be important to you, counting boxes is imho, a very poorB measurement of success. It is not a measurement criteria used by a	 solutions2 provider.<<<   ------------------------------  % Date: Mon, 22 Jan 2001 10:45:14 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.brD= Subject: RE: Compaq: A simple, affordable clustering solutioniL Message-ID: <OF0DB9D7CE.1AA2990C-ON032569DC.004AA1A5@ep-bc.petrobras.com.br>   Kerry Main wrote    K "Its a multi-platform world and there is no one solution or one OS platform 8 that will address all requirements, so whats your point?  I If increasing your footprint is Sun's main measurement of success, how dorK you explain all the server consolidation projects that are going on in manyoH medium-large companies ie. the concept of replacing many smaller serversI with fewer (but larger), centralized and in many cases, clustered serverse ??  G While it might be important to you, counting boxes is imho, a very poorrB measurement of success. It is not a measurement criteria used by a	 solutionsn
 provider."    I What means .... the mainframe is back ! ! ! The TCO, and operational costu of maintaning largeeK distrubuted systems is high in most companies. Client Server infrastructurer is messy, needA hundresd of people and a lot of software to mantain working fine.   J I believe in the return of the mainframe for  the corporate solutions. The PC never will die, becauseI in some places like my country (and I believe India and China),  there iso not a great telecomm.hG infrastructure - so there is no way to have an internet dependency - int this case Sun Microsystems0 is wrong.... Net PCs are for companies only ....  J But to the mainframe concept return to the corporations, I will insist:  a new graphical terminalJ must be developed. The web in the way it exists today (client-server) will not have a longeG life because of the growing of applications and limitations of speed. Ie believe in this new.I graphical terminal like an ICA Citrix client. Just the images come to the  costumers and alloE the high processing must be in the server - if the image comes to the. costumers meanseA it is safe to the costumer .... If Microsoft have sucess with WNT: Datacenter and+ Terminal Server togheter, it is a  way ....u     Regardsl   FC          < "Main, Kerry" <Kerry.Main@compaq.com> em 22/01/2001 10:25:34             Info-VAX@Mvb.Saic.Como      = Assunto: RE: Compaq: A simple, affordable clustering solutione     Andrew,o  3 Back at work I see .. We missed you on the weekend.i   :-)o  I >>> Perhaps a good example of how people are being missled is the currentrI crop of "OpenVMS wins" being trumpeted by your favourite Compaq employee.lJ Very few people count losing most of a companys platform infrastructure toH other vendors,  while retaining a backend server platform which has beenH upgraded from large (high service revenue) servers to much smaller lowerJ cost systems as a win. Winning is increasing your footprint in a customersG infrastructure and if you are in sales increasing your annual revenues,a onlyB a Compaq Marketing person could describe the opposite as a win.<<<  J Wow - pretty poor fud - even for you Andrew. The Eurex was a NEW win for a: NEW project with the CBOT. As was the Sydney Exchange win.  J I guess thats the difference between us. You stated that winning is simply increasing your box footprint.  B I view winning as gaining a Customers confidence that what you areJ delivering is a solid solution that will meet their business requirements.  H I view winning as doing things that cause industry analysts like GartnerE Group, who for years have had doubts about OpenVMS now publish a very  positive report on it. < K http://enterprise.cnet.com/enterprise/0-9566-707-1751615.html?tag=st.it.956o > 4 Quote - "Tru64 Unix and OpenVMS are proven winners."  J Its a multi-platform world and there is no one solution or one OS platform8 that will address all requirements, so whats your point?  I If increasing your footprint is Sun's main measurement of success, how do K you explain all the server consolidation projects that are going on in many/H medium-large companies ie. the concept of replacing many smaller serversI with fewer (but larger), centralized and in many cases, clustered servers: ??  G While it might be important to you, counting boxes is imho, a very poorDB measurement of success. It is not a measurement criteria used by a	 solutionsl	 provider.a   Regards,  
 Kerry Main Senior Consultantn Compaq Canada Inc. Professional Servicest Voice: 613-592-4660w Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]  Sent: January 22, 2001 4:10 AM To: Info-VAX@Mvb.Saic.Come= Subject: Re: Compaq: A simple, affordable clustering solutionn     Jordan Henderson wrote:h >  >aI > Ever since I can recall, and certainly since the early 80's, there haverI > been those in the UNIX camp (and later to a certain extent, the WindowseH > camp) who have denigrated OpenVMS as a hopelessly backward dinosaur, aH > Mainframe wannabee operating system that has no future beyond the nextI > wave of innovation that surely is coming.  Those waves have washed over D > the IT landscape time and time again, and I still see OpenVMS withJ > capabilities and attributes still not available elsewhere.  However, theF > detractors continute to snipe.  After many years of this, it takes aH > definite toll on the professional who wants to have current skills andG > be ready for that next wave that surely will, this time, wash OpenVMSa > completely away. >e  ; Jordan, I have never suggested that OpenVMS is a hopelesslye7 backward dinosaur. In fact quite the opposite. I have ar% great deal of respect for technology.i  : There are areas where OpenVMS does not excel, file I/O for9 example, but I have not been involved in highlighting itsc deficiencies in this area.  > I have suggested however that OpenVMS is hopelessly supported,< sold and marketed by Compaq and before them Digital. Perhaps= the best example of this spilling through into the technology ; is the area of TCP/IP. There is no doubt that Digitals pooro< support for IP in OpenVMS origionally making it an unbundled8 product was a huge mistake. Almost certainly a marketing7 decision that has had overspill into the technology butp9 more important it made it more difficult for customers to $ use OpenVMS as an Internet platform.  : I have suggested that ISV support for OpenVMS is very poor7 and this is undeniable. This poor support has little to 7 do with the technology and almost everything to do with 3 Compaqs handling of OpenVMS as one of their brands.   4 I say almost everything because the decision to drop3 POSIX support from OpenVMS was not helpfull in thisi respect.  1 I have suggested that OpenVMS support for Java ish3 poor, it is but it only reflects Compaqs underlyinga/ confusion over what to do with Java, support itn4 wholeheartedly like IBM and brave the wrath of their2 most feared partner MS or help MS try and kill it.  J > This is Andrew's real message.  He's been alluding to it for years, thatG > OpenVMS is in an irrevsible downward spiral and, by implication, thatc smarteE > professionals had better gain some UNIX skills now, before the tidei washesE > their career as well.  This war for the hearts and minds of OpenVMSmF > professionals is faught in public forums, not with Compaq marketing. >t  4 That is not my real message, sorry you can draw that8 conclusion from my "message" but that isn't the message.  = My message is that you cannot trust Compaq directly or peoplel= quoting unattributable sources close to or inside Compaq wheno; they make any kind of marketing/sales/positioning statement  about OpenVMS.  < Digital/Compaq have missled OpenVMS customers for years over= the state of and their intentions for the OpenVMS market. Now = this is probably because neither Digital nor Compaq have beene3 able to work out what their intentions ought to be.   9 Perhaps a good example of how people are being missled isn: the current crop of "OpenVMS wins" being trumpeted by your7 favourite Compaq employee. Very few people count losingH< most of a companys platform infrastructure to other vendors,8 while retaining a backend server platform which has been: upgraded from large (high service revenue) servers to much: smaller lower cost systems as a win. Winning is increasing; your footprint in a customers infrastructure and if you are 7 in sales increasing your annual revenues, only a Compaqw6 Marketing person could describe the opposite as a win.     Regardsg Andrew Harrisonu Enterprise IT Architectw   ------------------------------    Date: 22 Jan 2001 08:50:54 -0500, From: koehler@eisner.decus.org (Bob Koehler)= Subject: Re: Compaq: A simple, affordable clustering solutionv+ Message-ID: <yF+3gp4YQh0W@eisner.decus.org>g  \ In article <94ff5i$hen$1@lisa.gemair.com>, jordan@lisa.gemair.com (Jordan Henderson) writes:  K > This is Andrew's real message.  He's been alluding to it for years, that eN > OpenVMS is in an irrevsible downward spiral and, by implication, that smart M > professionals had better gain some UNIX skills now, before the tide washes w > their career as well.   G I have never understood this concept I've seen time and time again.  ItiH seems to be based on two ideas:  1) gernalized knowledge is not as good H as specific knowledge,  2)  knowing what everybody else knows is better   than knowing something few know.  C The first is self defeating.  If I get a resum showing a candidateaH knows only Windows or UNIX, it goes in the trash.  I want to see breadthB of knowledge and experience.  I want people who know more than oneF solution to a problem.  Anyone can learn VMS if they just a little bitE willing to learn.  I'm not running out to hire "I know UNIX, I shouldsE never have to learn anything else".  Knowledge is power.  Some of myOG best work has become available because I was willing in the 90s to workf  on a system designed in the 70s.  A The second problem is also self defeating.  If you only know whatnG everybody else knows I can replace you at the drop of a pin.  No reason.E to boost your salary, I can find someone else who will do the job for, less.l  H When VMS was king I had coworkers watching the decline of the market forG thier IBM mainframe (MVS) skills.  They all got great offers from shopsiF which had difficulties filling positions requiring those skills.  TheyC were still doing that work at a time in the 90's when the mainframeSF group was the only group at IBM making a profit.  I've lost touch with5 them but I suspect they have not lost touch with MVS.w   ------------1  real quote from a programmer someone else hired1  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = NASA GSFC Flight Software       | Federal Sector, Civil GrouptE                                 | please remove ".aspm" when replyingt   ------------------------------    Date: 22 Jan 2001 09:58:11 -0500* From: young_r@eisner.decus.org (Rob Young)= Subject: Re: Compaq: A simple, affordable clustering solutiono+ Message-ID: <6W7jSfIDbzFf@eisner.decus.org>v  Z In article <yF+3gp4YQh0W@eisner.decus.org>, koehler@eisner.decus.org (Bob Koehler) writes:^ > In article <94ff5i$hen$1@lisa.gemair.com>, jordan@lisa.gemair.com (Jordan Henderson) writes: > L >> This is Andrew's real message.  He's been alluding to it for years, that O >> OpenVMS is in an irrevsible downward spiral and, by implication, that smart lN >> professionals had better gain some UNIX skills now, before the tide washes  >> their career as well. l > I > I have never understood this concept I've seen time and time again.  It J > seems to be based on two ideas:  1) gernalized knowledge is not as good J > as specific knowledge,  2)  knowing what everybody else knows is better " > than knowing something few know. >    	[snip]t   > C > The second problem is also self defeating.  If you only know whateI > everybody else knows I can replace you at the drop of a pin.  No reasoneG > to boost your salary, I can find someone else who will do the job for  > less.  >   ; 	This is a good thing.  Especially from a senior management , 	position.  It protects you in several ways:  1 			1)  Get to see more bodies, hopefully someone  
 				qualifiedr% 			2)  Not dependent on an individualo  @ 	Leaving out specifics, I know someone that ran an ad for a yearA 	trying to find someone and eventually gave up.  They didn't needh@ 	someone that "wanted" to do the job.  They needed someone that A 	"could" do the job.  What did they do in the interim and how did 6 	they evenutally solve their dilema?   Good questions.  B 	Point is , if you are after someone with a rare skillset, you may/ 	consider moving away from using that solution.   J > When VMS was king I had coworkers watching the decline of the market forI > thier IBM mainframe (MVS) skills.  They all got great offers from shopsrH > which had difficulties filling positions requiring those skills.  TheyE > were still doing that work at a time in the 90's when the mainframe H > group was the only group at IBM making a profit.  I've lost touch with7 > them but I suspect they have not lost touch with MVS.n  5 	Yeah... I suspect MVS is also a sweet spot to be in.    				Rob    ------------------------------  % Date: Mon, 22 Jan 2001 15:05:47 +0000o0 From: andrew harrison <andrew.nospam@uk.sun.com>= Subject: Re: Compaq: A simple, affordable clustering solutiong* Message-ID: <3A6C4C4B.EE7D2D67@uk.sun.com>   "Main, Kerry" wrote: > 	 > Andrew,l > 5 > Back at work I see .. We missed you on the weekend.s >  > :-)w > K > >>> Perhaps a good example of how people are being missled is the current.K > crop of "OpenVMS wins" being trumpeted by your favourite Compaq employee. L > Very few people count losing most of a companys platform infrastructure toJ > other vendors,  while retaining a backend server platform which has beenJ > upgraded from large (high service revenue) servers to much smaller lowerL > cost systems as a win. Winning is increasing your footprint in a customersN > infrastructure and if you are in sales increasing your annual revenues, onlyD > a Compaq Marketing person could describe the opposite as a win.<<< > L > Wow - pretty poor fud - even for you Andrew. The Eurex was a NEW win for a< > NEW project with the CBOT. As was the Sydney Exchange win. >   ? Then perhaps you could comment on this response to your postings on the Sydney "WIN". s    E "Note that they ( or in some incarnation... ) have been cut down from ? 100% VMS to core only. This is just a non-loss, not a win. This-D reduction was/is being done against the advise of the people runningC the system and is pushed by VMS not 'having a future' and not beingl 'standard'."  K >I guess thats the difference between us. You stated that winning is simplyo >increasing your box footprint.n  ; No, footprint does not just mean systems, it means support,t; services, software, etc. I didn't mention boxes so its very ; revealing that you automatically translated footprint into e; boxes. You seem to think the way you accuse me of thinking.d     Regardsi Andrew Harrisont Enterprise IT Architectr   ------------------------------  # Date: Mon, 22 Jan 2001 16:39:21 GMTu, From: peterw@u.genie.co.uk (Peter Watkinson)= Subject: Re: Compaq: A simple, affordable clustering solutiont< Message-ID: <3a6d61fc.8611648@newshost.netscapeonline.co.uk>   >aE >Check back for the answer on Monday, when Andrew returns to work andeI >can once again take up his assigned duties to spread FUD in comp.os.vms. F >He _never_ posts on weekends and holidays.  They don't pay him to FUD( >comp.os.vms during non-businesss hours. >e >>___m  1 He doesn't appear once in comp.unix.sloaris......a  	  regards,      Peter Watkinson  peterw@u.genie.co.uk& http://www.windsurf-international.com/ http://www.pwnavigate.com/ http://you.genie.co.uk/peterw/   ------------------------------  + Date: Mon, 22 Jan 2001 13:50:02 +0100 (CET) : From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl> Subject: RE: Copying disk ?oJ Message-ID: <Pine.LNX.4.21.0101221337340.22576-100000@irys.stanpol.com.pl>  & On Fri, 19 Jan 2001, Tom Linden wrote:  D +One further question, how is it that you can backup to tape but not +disk with depth > 8?r  A  At start one request: please answer *after* the previous text...1  Thanks.  ;  To meritum: you *cannot* copy files to tape using BACKUP !:/  You can *only* copy files to save-set on tape.i<  The minor point is not related to the real question: BACKUP= *can* copy files with any directory depth, as can any program . where can skip the RMS file name structure -:)=  Can't check the moment if any version of BACKUP can do this,?6 but at least a /IMAGE backup (also disk-to-disk) works for years with any level depth.i    VMS 7.1-2 (not 2-1):a   ++++++++++++! $ back [*...] $8$VDA20:[*...]/logr2 %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B]4 %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C]6 %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D]8 %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E]: %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F]< %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G]> %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1]@ %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1.2]B %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1.2.3]D %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1.2.3.4]F %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1.2.3.4.5]H %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1.2.3.4.5.6]J %BACKUP-S-CREDIR, created directory $8$VDA20:[A.B.C.D.E.F.G.1.2.3.4.5.6.7]	 +++++++++d    Regards - Gotfryd   -- rE =====================================================================eF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================p   ------------------------------  + Date: Mon, 22 Jan 2001 13:56:18 +0100 (CET)l: From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl> Subject: Re: Copying disk ?eJ Message-ID: <Pine.LNX.4.21.0101221350370.22576-100000@irys.stanpol.com.pl>  - On Fri, 19 Jan 2001, Barry Treahy, Jr. wrote:    +Ken Robinson wrote: +r +>= +> Use "backup/verify/ignore=interlock  disk$disk1:[...]*.*;*  +> disk$disk2:[A.B...]/own=origy +iP +One word of caution, if you have real deep directory trees on your source disk,K +adding even just one more can cause problems because even VMS 7.2 on ODS-2  +limits you to 8 deep!!!  ,  Not so: VMS nor ODS-2 does *not* limit you.  !  The RMS file parser has a limit.i  >  But you *can* operate on filesystem level and "manually" find$ the directories FID list one-by-one.A  Have check with VMS 7.1 (see another mail with the subject) thatt, BACKUP doest that and is not limited by RMS.;  The /IMAGE is separate way - BACKUP copies files using the 8 FID list from INDEXF... And I am sure (PATHWORKS !) that; years ago the /IMAGE copy saves 32 level without problem...e  <  Have you check (and if yes - under what version) the BACKUP vs. 8-level limit ??   +Barry    Regards - Gotfryd -- eE =====================================================================eF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================i   ------------------------------  % Date: Mon, 22 Jan 2001 12:07:36 +0000i  From: steven.reece@quintiles.com* Subject: Re: digital PrintServer 17 600 psH Message-ID: <OFB4748A02.7110A1EB-ON802569DC.00423170@qedi.quintiles.com>  H If I remember rightly, the LPS17 can indeed load from an NT system usingI bootp.  Whether it will boot from anything else using bootp I'm not sure..E VMS systems would need to use MOP to load the printer as bootp is not G available (though I'm not sure whether it's a design decision on VMS ort what).  K If the broadcasts that you're seeing really are DECnet and not MOP then you   need to power cycle the printer.  $ k9020 at my dash deja dot com asked:I >>>Could someone provide guidance on reconfiguring a digital printer fromtC a decnet protocol to tcp/ip.  I have been unable to order docs from,D Compaq on this model.  I have been to Compaq site and download theirD unsupported software for Windows and Unix.  Their online docs do notG provide info on model panel.  I am currently setting this printer up onrF my home network (Alpha 300 xl running Linux, Powerpc running Macos 8 ,E dual boot W98/Linux box).  I have tried using bootp , and the Windows @ print manager with no success. I checked my wire and noticed the- printer is broadcasting a DECnet protocol.<<<c   ------------------------------    Date: 22 Jan 2001 18:26:42 +0800, From: Paul Repacholi <prep@prep.synonet.com>4 Subject: Re: Don't know whether to laugh or cry.....- Message-ID: <87y9w3evbx.fsf@prep.synonet.com>e  . "Glenn C. Everhart" <Everhart@GCE.com> writes:  ? > Compaq should not (and will not) do such a thing while sayingeC > "we couldn't get a PC solution to work". The way to approach such C > a conversion is to loudly proclaim "we liked the PC solution, butoB > our VMS solution is far more stable/secure/etc. so we switched." > @ > Or just say "we wanted a superlatively stable/secure solution," > which we got by moving to VMS".   0 "We saw the Windows adds, so we upgraded to VMS"   -- u< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------    Date: 22 Jan 2001 12:51:40 -0500* From: young_r@eisner.decus.org (Rob Young) Subject: Re: DS20 - Slow I/O+ Message-ID: <hlR2lSkNyZQf@eisner.decus.org>n  X In article <pXzL6RROqHCY@eisner.decus.org>, young_r@eisner.decus.org (Rob Young) writes:    6 	Received the following in email from someone that is 8 	very familiar with internals and not affilited with VMS
 	engineering:i   --- Begin Quote ---e  H Yes, fast_io is a major win. Internally, it avoids most of the setup andF teardown time of buffer allocation, avoids an extra trip thru IPL 4 onG every $qio, and avoids several buffer checks. John Hallyburton is to beyF commended for that effort. (Unfortunately he's no longer with VMS...he@ was another one who left due to the ambiance of the Palmer era.)  E The fast_io will work with ANY disk...it's all generic stuff..and waspF discussed in outline (though without the label) as a sensible followonF to $qio as far back as the non-disclosure talks about Alpha before itsF introduction back in 1992. It was recognized even then that the bufferG probing and other PALcode calls needed for $qio would produce much more 3 relative degradation on Alpha than they had on Vax.u  D $copy generally copies by blocks, then resets file attributes at theG end, but fastio is just, at low level, a helluva lot faster way to moveB data.r    h --- End Quote ---o   				Roba   >  > 	From your original post:. > J > "My test was copying several large files (Oracle dumps - each about     4 > 200MB) from one directory on the disk to another." > ; > 	If you really have a need to speed this up , I will makeU! > 	two suggestions (if possible):a > 0 > 	1)  Copy from one physical volume to another. >  > 	2)  Use fast_io_copyf > > > 	Here is an example copy of a 781 MByte (1600000) block file > 	using COPY and FAST_IO_COPY:s >  >  > 	Vanilla Copy resultsn >  > Accounting information:'C >  Buffered I/O count:        54  Peak working set size:       1504 C >  Direct I/O count:       50123  Peak virtual size:         166768wC >  Page faults:              393  Mounted volumes:                0b  >  Images activated:           4+ >  Elapsed CPU time:          0 00:00:17.55h+ >  Connect time:              0 00:16:24.88M > 8 >>>>>	16:24 , 50123 I/Os.  From one SCSI disk to another > 	off a SWXCR.  >  > 	fast_io_copy results: > ? > Using 16 buffers, with 127 blocks (65024 bytes) per transfer.i > & > Reading DRIVE1:[DIRECTORY]FILE.DAT;1& > Writing DRIVE2:[DIRECTORY]FILE.DAT;1 > Q >  ELAPSED:    0 00:08:55.70  CPU: 0:00:06.57  BUFIO: 1  DIRIO: 25200  FAULTS: 2 c2 >      Total Fast I/O Reads: 12599; Writes: 12599., > Maximum Outstanding Reads: 16; Writes: 16.3 > Output file truncated at VBN 1600012 by 0 blocks.o9 > New end-of-file block is 1600007, first free byte is 0.p > < >>>>>	8:56, 12599 I/Os.  Same source and destination drives. >  > C > 	Summary: FAST_IO_COPY is about twice as fast as regular COPY andh= > 	you may be able to do better as you can supply BLOCKS and e; > 	BUFFERS as args to FAST_IO_COPY... from the source code:J > / >     if (!strncmp(argv[ibuf], "-nbuffers", 9))g >     {h >       ibuf++;: >       if (ibuf < argc)	 >       {i& >         nbuffers = atoi(argv[ibuf]);: >         if ((nbuffers == 0) || (nbuffers > MAX_BUFFERS))# >           nbuffers = MAX_BUFFERS;e >  > 	same for -nblocks > < > 	Also.. even at that 1.46 MByte/sec using FAST_IO_COPY but> > 	these are plain old SCSI drives and I don't know the rating@ > 	of the SWXCR but it can't be that great.  You should do quite > 	a bit better regardless.h > A > 	Request:  Perhaps VMS engineering could add a COPY/FAST switchIA > 	that hooks to this routine.  In future versions of VMS, MEMBOB A > 	is no longer an issue (butchering Fred K.s view/words but they)< > 	will no longer be checking as they are to keep users fromB > 	chewing up system memory via other mechanisms) so maybe this is# > 	a supportable qualifier to COPY.n > 
 > 	Caveat: > 2 > 	You most likely will have to jack MAXBOBMEM ... >  > # > $ fic :== $sys$login:fast_io_copy G > $ fic DRIVE1:[DIRECTORY]SMALLFILE.DAT DRIVE2:[DIRECTORY]SMALLFILE.DATt? > Using 16 buffers, with 127 blocks (65024 bytes) per transfer.I% > Could not create buffer object #12.iP > %SYSTEM-F-EXBUFOBJLM, exceeded systemwide buffer object page limit (MAXBOBMEM) > $ set proc/priv=all  > $ mcr sysgen > SYSGEN>  SHOW MAXBOBMEM0J > Parameter Name           Current    Default     Min.      Max.     Unit 	 > DynamiceJ > --------------           -------    -------    -------   -------   ---- 	 > ------- P > MAXBOBMEM                    1600       1600         0         -1 Pagelets   DP >  internal value               100        100         0         -1 Pages      D > SYSGEN>  SET MAXBOBMEM 2400h > SYSGEN>  WRITE ACTIVEi > SYSGEN>  WRITE CURRENT > SYSGEN>  SHOW MAXBOBMEMeJ > Parameter Name           Current    Default     Min.      Max.     Unit 	 > DynamicgJ > --------------           -------    -------    -------   -------   ---- 	 > -------sP > MAXBOBMEM                    2400       1600         0         -1 Pagelets   DP >  internal value               150        100         0         -1 Pages      D > SYSGEN>  EXIT  > # > $ fic :== $sys$login:fast_io_copyoG > $ fic DRIVE1:[DIRECTORY]SMALLFILE.DAT DRIVE2:[DIRECTORY]SMALLFILE.DAT ? > Using 16 buffers, with 127 blocks (65024 bytes) per transfer. ) > Search: DRIVE1:[DIRECTORY]SMALLFILE.DAT2) > Reading DRIVE1:[DIRECTORY]SMALLFILE.DATn) > Writing DRIVE2:[DIRECTORY]SMALLFILE.DATa >  > > > 	Tests on small alpha running vms 7.1.  If you can't compile= > 	fast_io_copy, let me know and I will drop it out to you as> > 	a zip attachment. > 	 > 				Robe >    ------------------------------  % Date: Mon, 22 Jan 2001 13:04:53 +0000   From: steven.reece@quintiles.com/ Subject: Re: Dual ethernet config for failover?nH Message-ID: <OFEBC926F2.B4248D38-ON802569DC.0046938F@qedi.quintiles.com>   Keith,K Robert Deininger was correct in his comment that the limitation of only one,D DECnet interface on each network is only true of DECnet Phase IV (orK DECnet-Classic).  DECnet-Plus can have more than one ethernet connection on G the same network as long as only one has Phase IV compatible addressingiF active on it (extract from the DECnet-Plus configuration file is given below).m  I Until one of the 5.x releases of Compaq TCP/IP Services for OpenVMS thereeI is a limit on the number of interfaces that will play happily on the same K subnet.  That limit is one.  The reason is something along the lines of thesH algorithms within UCX (sorry, Compaq TCP/IP etc...) look for an ethernetH interface that they can shove the data out through.  This may be the oneA you intend or it may be another one if you have two or more cardsfI configured in the same subnet.  Both may work but it's unsupported and ifnI you have problems then you're on your own.  This bit me hard when I had ayE pair of systems that I wanted to give two IP addresses to in the sameeJ subnet and just could not get the second ethernet cards to play ball.  TheK workaround is to have one card in one subnet and the second card in anotheriI subnet.  It would then be a task for the DNS resolution to do any kind ofo	 failover.r  J For ther multi-protocol network which you've got you might like to migrateJ to DECnet-Plus with any upgrades on VMS that you're doing.  Then you couldH run things like DECnet over TCP/IP so that your network manager does notD cause any problems if he tells you that you can't run DECnet on your network any more.n Steve.  @ extract from sys$startup:net$routing_startup.ncl for DECnet-Plus .h . A SET NODE 0 ROUTING CIRCUIT CSMACD-0 ENABLE PHASEIV ADDRESS = TRUEI .s .t .SB SET NODE 0 ROUTING CIRCUIT CSMACD-1 ENABLE PHASEIV ADDRESS = FALSE .- .-   ------------------------------  % Date: Mon, 22 Jan 2001 12:03:02 +0000.$ From: Steve.Spires@yellowpages.co.uk Subject: eBay down again.s/ Message-ID: <002569DC.0042318F.00@quegw01.btyp>u   cc:o bcc:L Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza   eBay down again.    N Obviously the 7 hour downtime last week hasn't produced the results hoped for.  " How long are we in for today then?   Steve Spires     [Information] -- PostMaster:D This transmission is intended solely for the addressee(s) and may beL confidential. If you are not the named addressee, or if the message has beenP addressed to you in error, you must not read, disclose, reproduce, distribute or use this transmission.  L Delivery of this message to any person other than the named addressee is notH intended in any way to waive confidentiality.  If you have received thisF transmission in error please contact the sender or delete the message.  
 Thank you.   ------------------------------  % Date: Mon, 22 Jan 2001 12:25:22 +0000A  From: steven.reece@quintiles.com Subject: Re: eBay down again.eH Message-ID: <OF67744ABC.10F21CF3-ON802569DC.00440B47@qedi.quintiles.com>  C Is it easier to count uptime or to count downtime?  How fine is theS graduation on your stopwatch?o :-)s  4 Steve dot Spires at yellowpages dot co dot uk wrote:C >>>eBay down again.  Obviously the 7 hour downtime last week hasn't  produced the results hoped for. % How long are we in for today then?<<<e   ------------------------------   Date: 22 Jan 2001 17:03:58 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: Re: eBay down again. , Message-ID: <94hp5u$5g1@gap.cco.caltech.edu>  V In article <002569DC.0042318F.00@quegw01.btyp>, Steve.Spires@yellowpages.co.uk writes: >  >tO >Obviously the 7 hour downtime last week hasn't produced the results hoped for.i >I# >How long are we in for today then?-  G It could be that the power is out.  (The result of having too many dim k  bulbs in California government.)   Regards,   David Mathog mathog@seqaxp.bio.caltech.eduD? Manager, sequence analysis facility, biology division, Caltech b   ------------------------------  % Date: Mon, 22 Jan 2001 15:31:38 -0300g) From: fabio_compaq@ep-bc.petrobras.com.brU Subject: Re: eBay down again. L Message-ID: <OF96AE205D.5A38579D-ON032569DC.0065AD86@ep-bc.petrobras.com.br>  ; Now is needed the server consolidation = energy saver ! =))   2 Or the next stocks to buy will be from APC .......   Regardse   FC        C mathog@seqaxp.bio.caltech.edu (David Mathog) em 22/01/2001 15:03:58/  / Favor responder a mathog@seqaxp.bio.caltech.edu-             Info-VAX@Mvb.Saic.Com        Assunto: Re: eBay down again.t    / In article <002569DC.0042318F.00@quegw01.btyp>,j& Steve.Spires@yellowpages.co.uk writes: >. >.J >Obviously the 7 hour downtime last week hasn't produced the results hoped for. >e# >How long are we in for today then?w  F It could be that the power is out.  (The result of having too many dim  bulbs in California government.)   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu*> Manager, sequence analysis facility, biology division, Caltech   ------------------------------    Date: 22 Jan 2001 12:32:52 -0500* From: young_r@eisner.decus.org (Rob Young) Subject: Re: eBay down again. + Message-ID: <OKf+zH36NcPA@eisner.decus.org>r  x In article <OF96AE205D.5A38579D-ON032569DC.0065AD86@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes: > = > Now is needed the server consolidation = energy saver ! =))  > 4 > Or the next stocks to buy will be from APC ....... > 	 > Regardsa >   4 	yes.... Someone else is catching on that Google is  	"The Destroyer of Worlds"   	But I like it!e   				Rob    ------------------------------  # Date: Mon, 22 Jan 2001 16:52:27 GMT.* From: "Andy Stoffel" <acs@fcgnetworks.net>I Subject: ES40 Quikspecs (was: Re: Compaq continues the Digital Tradition).9 Message-ID: <ezZa6.258604$IP1.8696760@news1.giganews.com>.  H >> On Wed, 17 Jan 2001 11:06:02 -0500, Jack Patteeuw <jpatteeu@ford.com>	 >> wrote:R >>  # >> >STEALTH MARKETING AT ITS BEST !. >>>.J >>>Well the EV68/833 Mhz version of the ES40 is now "officially" availableJ >>>(it's on the DBL price file and in the QuickSpec).  Of course you would3 >>>never know this if you checked the ES40 web site.7 >>>(http://www5.compaq.com/alphaserver/es_series.html).A  [> And if you actually READ the quikspecs you'd wonder about it's	 accuracy.=  8 Both the KZPCC-AC & the KZPCC-CE are listed as supported? in VMS 7.2-1 & Digital Unix (which contradicts what I've heard R< about these - one was supposed to be NOT supported for VMS) @ but the following section that lists QUANTITY supported doesn't  list these 2 controllers.=  	 Oops.....-   -Andy-   ------------------------------  + Date: Mon, 22 Jan 2001 18:39:46 +0000 (   )i3 From: Christopher Smith <chriss@Mufasa.pubserv.com>C$ Subject: Expect my address to changeJ Message-ID: <Pine.LNX.4.05.10101221837020.16967-100000@Mufasa.pubserv.com>   Hello, h  3 This is just for those of you who may be concerned."  < My employment is in a temporary state of flux at this point.  H My address will change soon, expect me to post from amdocs.com (possiblyJ somewhere else), rather than pubserv.com.  My signature will probably also change.a   Regards,   ChrisD  O ===============================================================================T@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmerb Prime Synergy of Champaign, IL.(% -------------------------------------tI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and H weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 tO -------------------------------------------------------------------------------    ------------------------------  % Date: Mon, 22 Jan 2001 17:07:52 +0100=' From: Theo Jakobus <jakobus@iaf.fhg.de>= Subject: Re: Ghostscript v6.50) Message-ID: <3A6C68E8.BE035EE@iaf.fhg.de>O  H > I have a PCSI kit for ghostscript V6.50 on my ftp server available forG > anyone who'd like a straightforward install rather than a complicated= > build process. > H > After I've processed any feedback to this kit (if any), I'll submit it > to the freeware maintainer.: >  > Ftp server: mvb.saic.com > directory: [.PCSI_KITS]0 > B > You'll find both V6.01 and V6.50 versions there (VAX and Alpha). >   ' Thank you very much for this fine work!g& Installation was done without trouble.     Regards, -- t  ; *********************************************************** ; *                                                         *h; *  Theo Jakobus                                           *a; *  Fraunhofer-Institut fuer Angewandte Festkoerperphysik  * ; *  Tullastr. 72                                           *o; *  D-79108 Freiburg                                       *i; *  Germany                                                *a; *  Phone:   +49-(0)761-5159-325                           *h; *  FAX :    +49-(0)761-5159-200                           *a; *  e-mail:  jakobus@iaf.fhg.de                            *n; *  http://www.iaf.fhg.de                                  *r; *                                                         *g; ***********************************************************t   ------------------------------  % Date: Mon, 22 Jan 2001 12:42:35 +0000n0 From: andrew harrison <andrew.nospam@uk.sun.com>$ Subject: Re: GS160 hardware question* Message-ID: <3A6C2ABA.B0FAF43F@uk.sun.com>   "Main, Kerry" wrote: >  > Andrew ... > G > >>> Even if Kerry wasn't trying to respond directly to the OPS/tuningb0 > allegations by posting the TPC-C result ...>>> >  > Thank you.  Finally !  >  > Now I can rest easily. >   9 Kerry only you could rest easy after selectively cutting n% from a paragraph which actually said.   B "Even if Kerry wasn't trying to respond directly to the OPS/tuningA allegations by posting the TPC-C result which it is obvious that  > he was. You would have to question how sensible he was posting; a TPC-C result which in fact did illustrate exactly what I   said would happen."t  2 Its' good to see that you are still able to smile  though.C  0 Incedentally why did you post the origional URL 3 for the benchmark result without even checking how   it had been obtained ???   Regards  Andrew Harrisone Enterprise IT Architect    ------------------------------  % Date: Mon, 22 Jan 2001 07:17:26 -0600o+ From: "Main, Kerry" <Kerry.Main@Compaq.com>R$ Subject: RE: GS160 hardware questionN Message-ID: <910612C07BCAD1119AF40000F86AF0D805284C73@kaoexc3.kao.cpqcorp.net>   Andrew,c  L >>> Incedentally why did you post the origional URL for the benchmark result6 without even checking how it had been obtained ??? <<<  9 Perhaps because how it was obtained makes no difference? _  K Every TPC benchmark has all sorts of customized tuning efforts - usually infH the order of months of effort and at huge expense.  No vendor does a TPCI benchmark without all sorts of leading, pushing the edge, tuning efforts.e  H And this applies to all vendors on all platforms. Surely, you know this.  L By the way, OPS "in a box" (as you like to call it), offers the Customer theK ability to shutdown OS instances for preventative maint while keeping otherl@ instances up and running - hence maintaining overall application
 availability.u  H If it also has the capability to increase overall throughput, why do you  feel this is a negative feature?   Regards,  
 Kerry Main Senior Consultantu Compaq Canada Inc. Professional Servicesn Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]B Sent: January 22, 2001 7:43 AM To: Info-VAX@Mvb.Saic.Como$ Subject: Re: GS160 hardware question     "Main, Kerry" wrote: >  > Andrew ... > G > >>> Even if Kerry wasn't trying to respond directly to the OPS/tuning 0 > allegations by posting the TPC-C result ...>>> >  > Thank you.  Finally !o >  > Now I can rest easily. >   9 Kerry only you could rest easy after selectively cutting o% from a paragraph which actually said.o  B "Even if Kerry wasn't trying to respond directly to the OPS/tuningA allegations by posting the TPC-C result which it is obvious that  > he was. You would have to question how sensible he was posting; a TPC-C result which in fact did illustrate exactly what I   said would happen."a  2 Its' good to see that you are still able to smile  though.I  0 Incedentally why did you post the origional URL 3 for the benchmark result without even checking how   it had been obtained ???   Regards  Andrew Harrison  Enterprise IT Architecto   ------------------------------    Date: 22 Jan 2001 08:57:25 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson) $ Subject: Re: GS160 hardware question* Message-ID: <94he85$f67$1@lisa.gemair.com>  * In article <3A6C2ABA.B0FAF43F@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote: >"Main, Kerry" wrote:r >>  
 >> Andrew ...u >> sH >> >>> Even if Kerry wasn't trying to respond directly to the OPS/tuning1 >> allegations by posting the TPC-C result ...>>>s >> e >> Thank you.  Finally ! >> 2 >> Now I can rest easily.d >> a >n: >Kerry only you could rest easy after selectively cutting & >from a paragraph which actually said. >bC >"Even if Kerry wasn't trying to respond directly to the OPS/tuning B >allegations by posting the TPC-C result which it is obvious that ? >he was. You would have to question how sensible he was posting(< >a TPC-C result which in fact did illustrate exactly what I  >said would happen." >r  < What amazing gall Andrew demonstrates here.  He asserts both< that Kerry claimed that Wildfire didn't need tuning and that< Kerry accused Andrew of spreading FUD with regard to OPS and	 Wildfire.v  < As "proof" he quotes Kerry saying exactly the opposite with ; regard Wildfire and tuning and then admits to misconstruingh: what Kerry had said in relation to "tuning fud", yet seems/ to imply that this is some sort of vindication.f  3 >Its' good to see that you are still able to smile e >though. >F1 >Incedentally why did you post the origional URL c4 >for the benchmark result without even checking how  >it had been obtained ???h >s  ; Because perhaps nobody here agrees with your assertion that 8 there is anything, whatsoever, wrong or misleading about; a benchmark using OPS.  You are the only one here who seemsi9 concerned about this and I've not seen any other IndustryL( sources who call foul at this benchmark.  7 I guess it's predictable that you had to find SOMETHINGb wrong with the benchmark...O  	 >Regards d >Andrew Harrison >Enterprise IT Architect   -Jordan Hendersoni jordan@greenapple.com    ------------------------------  % Date: Mon, 22 Jan 2001 14:35:02 +0000 0 From: andrew harrison <andrew.nospam@uk.sun.com>$ Subject: Re: GS160 hardware question* Message-ID: <3A6C4516.16F71DA2@uk.sun.com>  1 Jordan Henderson spinning madly like a top wrote:  > 2 > >Incedentally why did you post the origional URL5 > >for the benchmark result without even checking howG > >it had been obtained ???Y > >  > = > Because perhaps nobody here agrees with your assertion thate: > there is anything, whatsoever, wrong or misleading about= > a benchmark using OPS.  You are the only one here who seems-; > concerned about this and I've not seen any other IndustryB* > sources who call foul at this benchmark. >   2 Yet again you display that you arn't competent to  comment.  * I have never suggested that using OPS in a0 box is against the TPC-C rules. Nor have I ever 1 suggested that industry sources have called foul V over this benchmark.  0 Industry sources and a lot of them have however / called into question the value of the benchmark]3 result because it uses a tuning method (OPS) which .1 is not available for some applications and which  : is also costly to impliment and own a factor not measured  by the TPC-C cost per TPM.  4 This has all been covered in detail on comp.arch and5 I suggest that you post your sentiments to that forum-" and see what you get in response.   2 Try claiming as Kerry did that its not the tuning 5 method you use but the TPC-C result that is importantD on that forum. 49 > I guess it's predictable that you had to find SOMETHINGe > wrong with the benchmark...  >   6 And it is entirely predictable that you either cannot 7 or won't understand that there is something wrong with C6 the benchmark if only because Compaq make comparisons 9 between their result and other SMP non OPS TPC-C results.e  8 You will find a significant body of opinion on comp.arch8 who would argue that TPC-C using OPS etc and TPC-C with 5 a single DBMS instance are so different as to warrantp two separate benchmarks.     Regardso Andrew Harrison  Enterprise IT Architects   ------------------------------  % Date: Mon, 22 Jan 2001 14:49:55 +0000o0 From: andrew harrison <andrew.nospam@uk.sun.com>$ Subject: Re: GS160 hardware question) Message-ID: <3A6C4893.7700094@uk.sun.com>h   "Main, Kerry" wrote: > 	 > Andrew,t > N > >>> Incedentally why did you post the origional URL for the benchmark result8 > without even checking how it had been obtained ??? <<< > : > Perhaps because how it was obtained makes no difference? > M > Every TPC benchmark has all sorts of customized tuning efforts - usually insJ > the order of months of effort and at huge expense.  No vendor does a TPCK > benchmark without all sorts of leading, pushing the edge, tuning efforts.o > J > And this applies to all vendors on all platforms. Surely, you know this. > 3 Kerry again you demonstrate your lack of knowledge.k7 Of course it matters how you get the benchmark results t7 because it has a direct impact on how people might havee5 to tune their systems to get similar performance for n say a TPC-C like OLTP system.   7 If you don't understand that there is a huge difference 7 between, buying, building and owning a OPS based systeme7 even if it is OPS in a box when compared with a single E7 instance Oracle system, most of which is not reflected C in the TPC-C costs per TPM.V  7 Compaq when they announced the Oracle TPC-C TPM result  6 claimed that they had the largest single system TPC-C 5 result, this was at a DBMS level (DBA, data training s2 etc) completely untrue because at an Oracle level 2 it was a clustered system not a non-clustered SMP 4 system. There had as you know been faster clustered  Oracle results.   2 It also matters because it uses a mechanism in OPS3 which isn't available for other DBMS's like Sybase t2 so Sybase cannot be tuned in the way Compaq tuned 0 Oracle to avoid the WildFire NUMA penalty. While3 trying to compare Sybase with Oracle results is nota3 recommended running OPS in a box makes is downrightu3 dangerous. I hope for example you have never sold as1 WildFire box to run Sybase on the strenght of youh Oracle TPC-C result.  N > By the way, OPS "in a box" (as you like to call it), offers the Customer theM > ability to shutdown OS instances for preventative maint while keeping othereB > instances up and running - hence maintaining overall application > availability., >   7 None of which has any relevance to TPC-C as you should   know.:  J > If it also has the capability to increase overall throughput, why do you" > feel this is a negative feature? >   8 I don't it is only a negative feature if it is the tool 2 you HAVE to use to get good performance to remain 7 competitive with systems that don't have to make use ofv this feature.   7 And it is also negative if you misslead your customers r4 into thinking that you somehow have parity with SMP = systems that did not need to use OPS to get good performance.   5 As I said earlier if you really think that the tuning:2 methodology you use to get a TPC-C result does not6 matter then I suggest you post this opinion forcefully to comp.arch.   9 Alternatively have a conversation off-line with your own  + benchmarking folks they will set you right.s    d RegardsI Andrew Harrisone Enterprise IT Architectt   ------------------------------  % Date: Mon, 22 Jan 2001 09:48:42 -0600b+ From: "Main, Kerry" <Kerry.Main@compaq.com>a$ Subject: RE: GS160 hardware questionN Message-ID: <910612C07BCAD1119AF40000F86AF0D805284C77@kaoexc3.kao.cpqcorp.net>   Andrew,-  L >>> If you don't understand that there is a huge difference between, buying,& building and owning a OPS based systemF even if it is OPS in a box when compared with a single instance OracleE system, most of which is not reflected in the TPC-C costs per TPM.<<<e  H The required costs of Oracle OPS were documented and included in the TPCI benchmark. If there are costs omitted that you feel should be included, I:5 would suggest taking it up with the TPC organization.d  K Since many (and increasing number) Customers seldom implement a single back K end server these days (high availability business reasons), perhaps anothercK way of looking at this benchmark is that it is a more realistic approach tod benchmarketing.d  L Performance + better availability - and all on a single system. What a novel- concept to providing solutions for Customers.b  G Yes, I know the TPC benchmark purists will disagree with this approach.. Fine. We can agree to disagree.n   Regards,  
 Kerry Main Senior Consultant  Compaq Canada Inc. Professional ServicesJ Voice: 613-592-46600 Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]6 Sent: January 22, 2001 9:50 AM To: Info-VAX@Mvb.Saic.Com,$ Subject: Re: GS160 hardware question     "Main, Kerry" wrote: > 	 > Andrew,n > G > >>> Incedentally why did you post the origional URL for the benchmarkm result8 > without even checking how it had been obtained ??? <<< > : > Perhaps because how it was obtained makes no difference? > J > Every TPC benchmark has all sorts of customized tuning efforts - usually inJ > the order of months of effort and at huge expense.  No vendor does a TPCK > benchmark without all sorts of leading, pushing the edge, tuning efforts.0 > J > And this applies to all vendors on all platforms. Surely, you know this. > 3 Kerry again you demonstrate your lack of knowledge.A7 Of course it matters how you get the benchmark results M7 because it has a direct impact on how people might have(5 to tune their systems to get similar performance for o say a TPC-C like OLTP system.h  7 If you don't understand that there is a huge differenceq7 between, buying, building and owning a OPS based systeml7 even if it is OPS in a box when compared with a single  7 instance Oracle system, most of which is not reflected d in the TPC-C costs per TPM.   7 Compaq when they announced the Oracle TPC-C TPM result  6 claimed that they had the largest single system TPC-C 5 result, this was at a DBMS level (DBA, data training t2 etc) completely untrue because at an Oracle level 2 it was a clustered system not a non-clustered SMP 4 system. There had as you know been faster clustered  Oracle results.c  2 It also matters because it uses a mechanism in OPS3 which isn't available for other DBMS's like Sybase u2 so Sybase cannot be tuned in the way Compaq tuned 0 Oracle to avoid the WildFire NUMA penalty. While3 trying to compare Sybase with Oracle results is nots3 recommended running OPS in a box makes is downright(3 dangerous. I hope for example you have never sold aM1 WildFire box to run Sybase on the strenght of you, Oracle TPC-C result.  J > By the way, OPS "in a box" (as you like to call it), offers the Customer theeG > ability to shutdown OS instances for preventative maint while keeping( otherpB > instances up and running - hence maintaining overall application > availability.- >   7 None of which has any relevance to TPC-C as you should q know.w  J > If it also has the capability to increase overall throughput, why do you" > feel this is a negative feature? >   8 I don't it is only a negative feature if it is the tool 2 you HAVE to use to get good performance to remain 7 competitive with systems that don't have to make use ofe this feature.   7 And it is also negative if you misslead your customers =4 into thinking that you somehow have parity with SMP = systems that did not need to use OPS to get good performance.6  5 As I said earlier if you really think that the tuning 2 methodology you use to get a TPC-C result does not6 matter then I suggest you post this opinion forcefully to comp.arch.   9 Alternatively have a conversation off-line with your own  + benchmarking folks they will set you right._    0 Regardso Andrew Harrison. Enterprise IT Architectr   ------------------------------  % Date: Mon, 22 Jan 2001 16:31:36 +0000a0 From: andrew harrison <andrew.nospam@uk.sun.com>$ Subject: Re: GS160 hardware question* Message-ID: <3A6C6068.4922714A@uk.sun.com>   "Main, Kerry" wrote: > 	 > Andrew,  > N > >>> If you don't understand that there is a huge difference between, buying,( > building and owning a OPS based systemH > even if it is OPS in a box when compared with a single instance OracleG > system, most of which is not reflected in the TPC-C costs per TPM.<<<  > J > The required costs of Oracle OPS were documented and included in the TPCK > benchmark. If there are costs omitted that you feel should be included, I 7 > would suggest taking it up with the TPC organization.  >   8 No they are not, the people costs are not included, the 4 setup costs are not included and the ongoing cost of8 ownership in terms of continued tuning are not included.  5 Take for example a 20 CPU GS320, 5 QBBS, 5 instances  7 of Oracle using OPS. Now what happens if your customer i6 wants to increas the CPU count to say 24 to get better1 throughput. Well guess what with OPS you have to .5 re-partition your data and your clients, this can be >2 a costly process and is not necessary on a single 3 instance SMP system. This ongoing cost is just one r# not measured or reported for TPC-C.l  3 This is one very good reason why you won't get muchu3 if any support for you tuning theories on comp.archp$ or from your own benchmarking folks.   Regardsw Andrew Harrisone Enterprise IT Architect/   ------------------------------    Date: 22 Jan 2001 11:50:38 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)i$ Subject: Re: GS160 hardware question* Message-ID: <94hocu$rtm$1@lisa.gemair.com>  * In article <3A6C4516.16F71DA2@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote:2 >Jordan Henderson spinning madly like a top wrote: >>  3 >> >Incedentally why did you post the origional URLn6 >> >for the benchmark result without even checking how >> >it had been obtained ??? >> > >>  > >> Because perhaps nobody here agrees with your assertion that; >> there is anything, whatsoever, wrong or misleading about > >> a benchmark using OPS.  You are the only one here who seems< >> concerned about this and I've not seen any other Industry+ >> sources who call foul at this benchmark.  >> u >v3 >Yet again you display that you arn't competent to p	 >comment.o >t  7 Well, it's true that nobody else _here_ seems concerned 	 about it.t  + >I have never suggested that using OPS in ah1 >box is against the TPC-C rules. Nor have I ever o2 >suggested that industry sources have called foul  >over this benchmark.e >u1 >Industry sources and a lot of them have however n0 >called into question the value of the benchmark4 >result because it uses a tuning method (OPS) which 2 >is not available for some applications and which ; >is also costly to impliment and own a factor not measured n >by the TPC-C cost per TPM.a >a5 >This has all been covered in detail on comp.arch andl6 >I suggest that you post your sentiments to that forum# >and see what you get in response.   >e  . Just as a test, I did a search in dejanews for3 "Compaq OPS Oracle" in group comp.arch.  There were , two threads, back in September of last year.  0 One HP employee commented that OPS may very well/ be a valid real-world configuration, but he did 1 want to point out that this was not a traditionalc use of an SMP system.u  : An IBM employee said that the use of this "cluster trick",= as he called it, did not conform to real world configurationsn9 but did point out another expert, who is now at Microsoft : Research, who does feel that kind of partitioning is often9 used in the real-world.  He also pointed out that IBM and - HP have used the "cluster trick" in the past.   ; There was one Andrew Harrison participating in one of thesel9 threads, and another Sun employee.  Then, there were someh Compaq employees, of course.  8 So, it only seems to be a problem to Compaq competitors.@ No discussion in the articles I read from Independent Analysts,  no Academics, just competitors.l  : Gee, I could go looking for Compaq detractors, but I guess- I get more than my fill with Andrew Harrison.o  6 >method you use but the TPC-C result that is important >on that forum. : >> I guess it's predictable that you had to find SOMETHING >> wrong with the benchmark... >> 0 >r7 >And it is entirely predictable that you either cannot R8 >or won't understand that there is something wrong with 7 >the benchmark if only because Compaq make comparisons ,: >between their result and other SMP non OPS TPC-C results. >e9 >You will find a significant body of opinion on comp.archr9 >who would argue that TPC-C using OPS etc and TPC-C with a6 >a single DBMS instance are so different as to warrant >two separate benchmarks.2 >>  < Hmm... HP, IBM and Sun are all on the TPC committees.  You'd8 think that they could get new benchmarks put together if there was a real issue here.  5 Could be that it's actually a matter of debate among  4 objective people and not a settled issue as you are ( apparently trying to lead us to believe?   >o >Regards >Andrew Harrison >Enterprise IT Architect   -Jordan Hendersone jordan@greenapple.com    ------------------------------    Date: 22 Jan 2001 12:06:07 -0500* From: young_r@eisner.decus.org (Rob Young)$ Subject: RE: GS160 hardware question+ Message-ID: <8Dw$+Fn0TV9H@eisner.decus.org>o  X In article <iXekjCRlQ6yv@eisner.decus.org>, young_r@eisner.decus.org (Rob Young) writes: > C > 	(i.e. cluster cheat not employed, besides < 1000 disks total :-)i >   ; 	Umm.. make that < 1100 disks, but what's a few dozen diskse 	among friends?i   ------------------------------    Date: 22 Jan 2001 12:04:49 -0500* From: young_r@eisner.decus.org (Rob Young)$ Subject: RE: GS160 hardware question+ Message-ID: <iXekjCRlQ6yv@eisner.decus.org>t  | In article <910612C07BCAD1119AF40000F86AF0D805284C77@kaoexc3.kao.cpqcorp.net>, "Main, Kerry" <Kerry.Main@compaq.com> writes:	 > Andrew,  > M >>>> If you don't understand that there is a huge difference between, buying,d( > building and owning a OPS based systemH > even if it is OPS in a box when compared with a single instance OracleG > system, most of which is not reflected in the TPC-C costs per TPM.<<<  > J > The required costs of Oracle OPS were documented and included in the TPCK > benchmark. If there are costs omitted that you feel should be included, I 7 > would suggest taking it up with the TPC organization.: > M > Since many (and increasing number) Customers seldom implement a single backHM > end server these days (high availability business reasons), perhaps anothertM > way of looking at this benchmark is that it is a more realistic approach toi > benchmarketing.  > N > Performance + better availability - and all on a single system. What a novel/ > concept to providing solutions for Customers.a > I > Yes, I know the TPC benchmark purists will disagree with this approach.e! > Fine. We can agree to disagree.o >   . 	Where Pfister has his biggest problem is with; 	what he calls the "cluster cheat".  Multiple copies of the @ 	DB are allowable and of course, how realistic is that?  (As you= 	have mentioned those 8000 disk runs are a little wild).  ButrD 	(correct me if I'm wrong) I believe the Tru64 folks are replicating? 	the indexes.  To me that makes the most sense and shouldn't beoD 	pooh poohed as that is what everyone else will be doing real-world.  @ 	A quick glance at the full disclosure shows that tables weren't 	replicated:  A http://www.tpc.org/results/FDR/Tpcc/compaq.gs320.00111001.fdr.pdfs  A 	(i.e. cluster cheat not employed, besides < 1000 disks total :-)    				Robe   ------------------------------  % Date: Mon, 22 Jan 2001 17:03:45 +0000e0 From: andrew harrison <andrew.nospam@uk.sun.com>$ Subject: Re: GS160 hardware question* Message-ID: <3A6C67F1.FEE802E1@uk.sun.com>   Jordan Henderson wrote:E > , > In article <3A6C4516.16F71DA2@uk.sun.com>,4 > andrew harrison  <andrew.nospam@uk.sun.com> wrote:4 > >Jordan Henderson spinning madly like a top wrote: > >>5 > >> >Incedentally why did you post the origional URLw8 > >> >for the benchmark result without even checking how > >> >it had been obtained ??? > >> > > >>@ > >> Because perhaps nobody here agrees with your assertion that= > >> there is anything, whatsoever, wrong or misleading about @ > >> a benchmark using OPS.  You are the only one here who seems> > >> concerned about this and I've not seen any other Industry- > >> sources who call foul at this benchmark.  > >> > >p4 > >Yet again you display that you arn't competent to > >comment.3 > >9 > 9 > Well, it's true that nobody else _here_ seems concerned  > about it.e > - > >I have never suggested that using OPS in a 2 > >box is against the TPC-C rules. Nor have I ever3 > >suggested that industry sources have called foulw > >over this benchmark.e > >?2 > >Industry sources and a lot of them have however2 > >called into question the value of the benchmark5 > >result because it uses a tuning method (OPS) whichC3 > >is not available for some applications and whichh< > >is also costly to impliment and own a factor not measured > >by the TPC-C cost per TPM.  > >t7 > >This has all been covered in detail on comp.arch andd8 > >I suggest that you post your sentiments to that forum$ > >and see what you get in response. > >  > 0 > Just as a test, I did a search in dejanews for5 > "Compaq OPS Oracle" in group comp.arch.  There were . > two threads, back in September of last year. > 2 > One HP employee commented that OPS may very well1 > be a valid real-world configuration, but he didd3 > want to point out that this was not a traditionalc > use of an SMP system.t > < > An IBM employee said that the use of this "cluster trick",? > as he called it, did not conform to real world configurationse; > but did point out another expert, who is now at Microsoftg< > Research, who does feel that kind of partitioning is often; > used in the real-world.  He also pointed out that IBM anda/ > HP have used the "cluster trick" in the past.l >   6 Microsoft, now I wonder why a Microsoft employee would3 be keen on partitioning and clustering. Could it beo2 that you cannot build a big TP system without both) if you want to use a MS operating system.i    5 Naa that can't be it. It is however amusing that the e3 only person supporting your argument is a Microsofta3 employee, adversity does make for very strange bed i fellows.  5 Microsoft even have a term to describe their approachl1 to building big systems its called "Scaling out".c  ; But as I said, don't post your opinions to this newsgroup, a6 post them forcefully to comp.arch you are hardly going! to get rigorous peer review here.i   Regardsl Andrew Harrisonv Enterprise IT Architecto   ------------------------------    Date: 22 Jan 2001 12:15:49 -0500* From: young_r@eisner.decus.org (Rob Young)$ Subject: Re: GS160 hardware question+ Message-ID: <mYw9cT1f87jP@eisner.decus.org>y  \ In article <94hocu$rtm$1@lisa.gemair.com>, jordan@lisa.gemair.com (Jordan Henderson) writes:   	Re: OPS   > < > An IBM employee said that the use of this "cluster trick",? > as he called it, did not conform to real world configurationsh; > but did point out another expert, who is now at Microsofte< > Research, who does feel that kind of partitioning is often; > used in the real-world.  He also pointed out that IBM andt/ > HP have used the "cluster trick" in the past.o >   9 	For an excellent overview of the "cluster cheat" pick upa< 	Pfister's "In Search of Clusters", he does a good job.  In 8 	another thread follow-up, I attempt to dispel that FUD F 	(to have the cheat going, you need multiple copies of the DB.. a big F 	clue there is if the TPC submittal has much more than ~1200 disks).   	As a for instance:G  R http://www.tpc.org/results/individual_results/Compaq/compaq.pl8500.00100601.es.pdf  ; 	That config has more than twice as many disks as the GS320t< 	Oracle OPS config.  (Yes it is higher performing , whatever 	whatever, whatever).    				Robi   ------------------------------    Date: 22 Jan 2001 13:10:45 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)e$ Subject: Re: GS160 hardware question* Message-ID: <94ht35$2g5$1@lisa.gemair.com>  * In article <3A6C67F1.FEE802E1@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote: >Jordan Henderson wrote: >> a- >> In article <3A6C4516.16F71DA2@uk.sun.com>,s5 >> andrew harrison  <andrew.nospam@uk.sun.com> wrote:e5 >> >Jordan Henderson spinning madly like a top wrote:t >> >>a6 >> >> >Incedentally why did you post the origional URL9 >> >> >for the benchmark result without even checking howr >> >> >it had been obtained ???l >> >> >  >> >>nA >> >> Because perhaps nobody here agrees with your assertion that > >> >> there is anything, whatsoever, wrong or misleading aboutA >> >> a benchmark using OPS.  You are the only one here who seemsn? >> >> concerned about this and I've not seen any other Industry5. >> >> sources who call foul at this benchmark. >> >>q >> >5 >> >Yet again you display that you arn't competent tom >> >comment. >> > >> n: >> Well, it's true that nobody else _here_ seems concerned >> about it. >> :. >> >I have never suggested that using OPS in a3 >> >box is against the TPC-C rules. Nor have I everu4 >> >suggested that industry sources have called foul >> >over this benchmark. >> >3 >> >Industry sources and a lot of them have howeverw3 >> >called into question the value of the benchmarkc6 >> >result because it uses a tuning method (OPS) which4 >> >is not available for some applications and which= >> >is also costly to impliment and own a factor not measuredl >> >by the TPC-C cost per TPM. >> >8 >> >This has all been covered in detail on comp.arch and9 >> >I suggest that you post your sentiments to that forum % >> >and see what you get in response.m >> > >> y1 >> Just as a test, I did a search in dejanews forr6 >> "Compaq OPS Oracle" in group comp.arch.  There were/ >> two threads, back in September of last year.  >> O3 >> One HP employee commented that OPS may very well 2 >> be a valid real-world configuration, but he did4 >> want to point out that this was not a traditional >> use of an SMP system. >> n= >> An IBM employee said that the use of this "cluster trick",T@ >> as he called it, did not conform to real world configurations< >> but did point out another expert, who is now at Microsoft= >> Research, who does feel that kind of partitioning is oftent< >> used in the real-world.  He also pointed out that IBM and0 >> HP have used the "cluster trick" in the past. >> r >a7 >Microsoft, now I wonder why a Microsoft employee would 4 >be keen on partitioning and clustering. Could it be3 >that you cannot build a big TP system without botho* >if you want to use a MS operating system. >  >r6 >Naa that can't be it. It is however amusing that the 4 >only person supporting your argument is a Microsoft4 >employee, adversity does make for very strange bed 	 >fellows.o >x  2 The HP employee also said that the benchmark might reflect real-world setups. r  6 Microsoft Research is an independent research lab that8 includes such luminaries as Gordon Bell, Rick Rashid (of9 Mach micro-kernel fame, Director of Research at MSR now),( and Dan Ling, to name a few.  2 While you might not consider MSR to be completely 5 independent, a researcher there has a lot of academicC; freedom and I would say that choosing from a Sun employee,  = an HP employee, and IBM employee and a researcher at MSR, youg7 could say that the MSR researcher might be expected to r# be the most objective in the group.   6 >Microsoft even have a term to describe their approach2 >to building big systems its called "Scaling out". >n< >But as I said, don't post your opinions to this newsgroup, 7 >post them forcefully to comp.arch you are hardly goingh" >to get rigorous peer review here. >p >Regards >Andrew Harrison >Enterprise IT Architect   -Jordan Hendersonh jordan@greenapple.coma   ------------------------------    Date: 22 Jan 2001 13:38:59 -0500* From: young_r@eisner.decus.org (Rob Young)$ Subject: Re: GS160 hardware question+ Message-ID: <PTdCIrBTecXh@eisner.decus.org>g  \ In article <94ht35$2g5$1@lisa.gemair.com>, jordan@lisa.gemair.com (Jordan Henderson) writes:   > 4 > While you might not consider MSR to be completely 7 > independent, a researcher there has a lot of academicr= > freedom and I would say that choosing from a Sun employee, M? > an HP employee, and IBM employee and a researcher at MSR, yout9 > could say that the MSR researcher might be expected to l% > be the most objective in the group.v >   0 	The airplane had one engine fail, then another.5 	There was a single parachute, an IBM employee, an HPi5 	employee, a Sun employee and an MSR employee . . . .s   	ahhhh... never mind.e   			Rob   ------------------------------  % Date: Mon, 22 Jan 2001 08:44:10 -0500h, From: Steve Lionel <Steve.Lionel@compaq.com>= Subject: Re: Has anyone sucessfully ported SMG from VMS to NTo8 Message-ID: <e6eo6tcositm9m062ftqg7gbobk7p4r8kg@4ax.com>  E On Sun, 21 Jan 2001 22:55:53 GMT, "pm" <fu_ri_oso@hotmail.com> wrote:n  H >HAs anyone been sucessful in port an app that uses SMG (windowing) on a" >Dec/Vax/Alpha to a pc using NT...  E Sector 7 (www.sector7.com) and Accelr8 Technologies (www.accelr8.com) * each offer SMG-emulation libraries for NT.    - Steve Lionel (mailto:Steve.Lionel@compaq.com)i Fortran Engineeringp& Compaq Computer Corporation, Nashua NH  6 Compaq Fortran web site: http://www.compaq.com/fortran   ------------------------------  + Date: Mon, 22 Jan 2001 09:17:19 +0100 (MET)g& From: Rudolf Wingert <win@fom.fgan.de>N Subject: Is there any real successor of the PrintServer printers (LPS20&LPS17)6 Message-ID: <200101220813.JAA04054@sinet1.fom.fgan.de>   Hello,  G our user do report a problem with the newly network printers like LN20.dF They did print a PowerPoint document with the effect, that printing onJ the LN20 the printer say idle after the fourth page. But the old one LPS20J did print the whole 300 pages without any problem or failure. Does anybodyK know, what the problem of LN20 (also the Tektronix Phaser550, Canon LBP420) E is? We do not understand that the printer means, that it has finishedd	 printing.n   TIA and regards Rudolf Wingert   ------------------------------  % Date: Sun, 21 Jan 2001 23:02:55 -0800t) From: Wayne Holland <wholland@tscnet.com>n- Subject: Re: Linux worm and RedHat 7.0 brokenoO Message-ID: <F7711E5818EE84E1.2E7801784F02FFA9.1BA2D53A74A95FDB@lp.airnews.net>w   Martin Vorlaender wrote: > , > Wayne Holland (wholland@tscnet.com) wrote:F > : I had Suse also. [...] I moved over to Calder Open Linux 2.4 [...]K > : Caldera also sports Webmin, a GUI system admin tool thats well endowed.i > D > As an aside to this already off-topic thread: while it's true thatJ > Caldera sponsors Webmin, it supports lots of Linux distributions as wellM > as other Unix dialects (including Tru64). See http://www.webmin.com/webmin/b0 > (or any of the mirrors worldwide) for details. > I > To get on-topic again: If I find the time (<sigh> lately, I really hatelG > that phrase...), I intend to have a look at whether it can be made toMH > run under VMS also (it's a pure perl application), with the first goalK > of aiding in the configuration of CSWS. As it is is modular in structure,s: > it even could be possible to write VMS specific modules. >  > cu, 
 >   Martin > --L > One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer9 > One OS to find them           | work: mv@pdv-systeme.de-P > One OS to bring them all      |       http://www.pdv-systeme.de/users/martinv/@ > And in the Darkness bind them.| home: martin@radiogaga.harz.de, Oooopss!  Sorry to have broken the thread...   ------------------------------  % Date: Sun, 21 Jan 2001 22:57:08 -0800 ) From: Wayne Holland <wholland@tscnet.com>s- Subject: Re: Linux worm and RedHat 7.0 brokeniO Message-ID: <739937F6CE962F35.506340DF305E1404.6FD1A6548D2AB164@lp.airnews.net>r   Paul Sture wrote:  >  > In articleL > <893DFB0367232DC7.4A09CE378474EB66.8D7EAAB8F0521A97@lp.airnews.net>, Wayne > Holland wrote: > >h > > Paul Sture wrote:c > >.
 > > <snip> > >eM > > > Ain't it lucky I switched to SuSe? :-) I must say that after I switcheddD > > > from RedHat to SuSe on my home Linux system, I was immediately@ > > > impressed by the installation, but more importantly by theL > > > documentation. No more ploughing through endless HOWTO documents, someF > > > of which are generic unix anyway. No more intensive downloads of0 > > > documents which turn out to be irrelevant. > > >>L > > > To be fair to RedHat, I am comparing RedHat 5.2 and 6.0 with 7.0 SuSe,L > > > and things are moving quickly in the Linux world, but I was astonished > > > by the difference. > > >nM > > > Why did I move to SuSe? Well it not only supported the hardware I have,iJ > > > but the Professional Edition cost only a little more than the RedHatL > > > Standard version (which missed some stuff I wanted), and was just over: > > > _half_ the price of the RedHat Professional Edition. > > >h@ > > > Anyway, back to RedHat 7.0: From www.netcraft.com/survey : > > >g
 > > <snip> > >aG > > I had Suse also.  I liked the variety of compilers they offered.  IoK > > moved over to Calder Open Linux 2.4 for the purposes of using Mesa, and K > > OpenGl look alike.  Caldera also sports Webmin, a GUI system admin tooliD > > thats well endowed.  Its drawback is that it only has one window? > > manager, Kde.  Their online documentation is very loose and@ > > unstructured.oD > > Of course I find all linux docs pretty sparse or poorly written.I > > I finally moved over to Solaris 8, as the display is better and comes_ > > with better fonts. > F > Before SuSe, I was thinking of moving to NetBSD/FreeBSD, which again- > Netcraft report as being popular out there.k > J > Solaris? Yes, attractive, but guess what? AH's rantings posted here have6 > rather put me off spending a single dollar with Sun! > D > > The documentation is complete with an online AnswerBook service. > >  > > I like the diversity, tho. > >nL > Yup. An excellent website full of good info. Would that Compaq could do as7 > well. I still hate going there, purely because of AH.  > ___> > Paul Sture
 > Switzerland B I can hear you about the Sun stuff!  Man I got flamed bad for justD asking a simple question dealing with their history of disk slices. > Don't know what to think of that, so I left their newsgroup at alt.solaris.x86.B I emailed Sun asking them to post a screen snapshot of CDE.  Their- salesrep replied "What for?"  What can I say?r  B The BSDi was for sale at a store called Staples for around $80.  IB understand that berkely hand traced all their code for bugs and isD acclaimed to be quite stable for net use.  But I only have so little money.  , After all said and done, I'd stay with Suse.   ------------------------------  % Date: Sun, 21 Jan 2001 23:00:34 -0800l) From: Wayne Holland <wholland@tscnet.com> - Subject: Re: Linux worm and RedHat 7.0 brokennO Message-ID: <57EA5FA38BE64117.3A5CD1C03EC955F7.28A67F6CC7F9B978@lp.airnews.net>    Arne Vajhj wrote: >  > Paul Sture wrote:lH > > Before SuSe, I was thinking of moving to NetBSD/FreeBSD, which again/ > > Netcraft report as being popular out there.w > G > It is my impression that *BSD are very good server operating systems. B > They are more robust than Linux. For desktop usage I think Linux< > has more applications. I many ways it is unfair that Linux > got all the publicity. > L > > Solaris? Yes, attractive, but guess what? AH's rantings posted here have8 > > rather put me off spending a single dollar with Sun! > $ > I think Solaris for x86 are free ! > > > But I would not choose that either. I do not think there are& > much apps available for Solaris x86. >  > Arne@ Hi Arne,  your right... not much freebies available for Sol x86.G Sun only gives you a free license.. it cost me $75.  Only because linux,- has probably taken a chunk out of Suns' hide.iH I think the publicity more stemmed from Linus doing a solo and making it( freely available. But I'm only guessing.   ------------------------------  % Date: Mon, 22 Jan 2001 10:47:18 +0300 + From: "Oleg Mikhailov" <olegm@sbrf.nnov.ru> ! Subject: Multiple path devices...g+ Message-ID: <94goi6$5m2$1@base.nis.nnov.su>t   Hi All!d  7 Is MA8000 with two HSG80 in multiple-bus failover mode.t And AS4100 with two KGPSA-CA.>< Accordingly to anyone unit there is an access on four paths.# HSG80-A port1 - 5000-1FE1-000B-EEC3o,                  Port2 - 5000-1FE1-000B-EEC4  # HSG80-B port1 - 5000-1FE1-000B-EEC1a+                 Port2 - 5000-1FE1-000B-EEC2s   For example:  ( Unit D1 PREFERRED_PATH = other (HSG80-B)   In OpenVMS session:w  OLEGM.SATURN > SHO DEV DGA1/FULL  F Disk $ 1 $ DGA1: (SATURN), device type HSG80, is online, file-oriented device,9I     Shareable, available to cluster, device has multiple I/O paths, errort     Logging is enabled.u  <     Error count                    0    Operations completed 15954v1     Owner process                 ""    Owner UICa [SYSTEM]0     Owner process ID        00000000    Dev Prot S:RWPL,O:RWPL,G:R,W ;     Reference count                0    Default buffer sizea 512 $     Allocation class               1  $   I/O paths to device              4E   Path PGA0.5000-1FE1-000B-EEC3 (SATURN), primary path, current path.f<     Error count                    0    Operations completed 3989)   Path PGA0.5000-1FE1-000B-EEC2 (SATURN).n<     Error count                    0    Operations completed 3989)   Path PGB0.5000-1FE1-000B-EEC1 (SATURN). <     Error count                    0    Operations completed 3988)   Path PGB0.5000-1FE1-000B-EEC4 (SATURN).h<     Error count                    0    Operations completed 3988  D Accordingly access to the disk is carried out through HSG80-A port1.H It is possible manually to change path - SET DEV $1$ DGA1:/SWITCH/PATH = PGB0.5000-1FE1-000B-EEC1    OLEGM.SATURN > SHO DEV DGA1/FULL  F Disk $ 1 $ DGA1: (SATURN), device type HSG80, is online, file-oriented device, I     Shareable, available to cluster, device has multiple I/O paths, errorh     Logging is enabled.p  <     Error count                    0    Operations completed 15980a1     Owner process                 ""    Owner UICh [SYSTEM]0     Owner process ID        00000000    Dev Prot S:RWPL,O:RWPL,G:R,Wn;     Reference count                0    Default buffer sizeu 512 $     Allocation class               1  $   I/O paths to device              47   Path PGA0.5000-1FE1-000B-EEC3 (SATURN), primary path.y<     Error count                    0    Operations completed 3996)   Path PGA0.5000-1FE1-000B-EEC2 (SATURN)..<     Error count                    0    Operations completed 39957   Path PGB0.5000-1FE1-000B-EEC1 (SATURN), current path.i<     Error count                    0    Operations completed 3994)   Path PGB0.5000-1FE1-000B-EEC4 (SATURN).t<     Error count                    0    Operations completed 3995   This unique solution?- And how to change primary path?    --     wbr Oleg M.5   ------------------------------  # Date: Mon, 22 Jan 2001 09:03:27 GMTr% From: Uwe Zessin <zessin@my-deja.com>i% Subject: Re: Multiple path devices...r) Message-ID: <94gt0t$3hs$1@nnrp1.deja.com>o  + In article <94goi6$5m2$1@base.nis.nnov.su>, .   "Oleg Mikhailov" <olegm@sbrf.nnov.ru> wrote:	 > Hi All!, > 9 > Is MA8000 with two HSG80 in multiple-bus failover mode.n > And AS4100 with two KGPSA-CA.x> > Accordingly to anyone unit there is an access on four paths.% > HSG80-A port1 - 5000-1FE1-000B-EEC3 . >                  Port2 - 5000-1FE1-000B-EEC4 > % > HSG80-B port1 - 5000-1FE1-000B-EEC1h- >                 Port2 - 5000-1FE1-000B-EEC2h >c > For example: [...]  > This unique solution?C! > And how to change primary path?   7 'Primary path' is the first path configured by OpenVMS.( Why do you want to change it?e   --
 Uwe Zessin3 (If you want to send mail, please use user "zessin"a/ who lives at "decus.decus.de", not my-deja.com)n     Sent via Deja.comt http://www.deja.com/   ------------------------------  % Date: Mon, 22 Jan 2001 09:32:41 +0100h= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com> * Subject: Re: New OpenVMS Times now on line) Message-ID: <3A6BF028.196943E0@gtech.com>-   David Beatty wrote:e8 > I can't seem to find the numbers yopu refer to at IDC. > Can you post the URLs?  6 FUD people usually prefer to post undocumented stuff !   Arne   ------------------------------  % Date: Mon, 22 Jan 2001 09:34:00 +0100<= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>a* Subject: Re: New OpenVMS Times now on line) Message-ID: <3A6BF078.6DE1EB4C@gtech.com>.   andrew harrison wrote: > David Beatty wrote:a: > > I can't seem to find the numbers yopu refer to at IDC. > > Can you post the URLs? > = > I cannot give you the URL because the information I have isi< > from the vendor data shipped to us by IDC and its an excel > spreadsheet.   Ah !  F "X is a fact, but no I can not come up with any documentation for it."  / If that is not FUD, then I do not know what is.r   Arne   ------------------------------  % Date: Mon, 22 Jan 2001 08:48:18 -0500h0 From: David Beatty <David.Beatty.NOSPAM@sas.com>* Subject: Re: New OpenVMS Times now on line2 Message-ID: <6DlsOjDqEvCk6s9sCpSrdhyj2h+g@4ax.com>  6 Yes, I got it.  ;-)  Andrew's numbers may very well be1 accurate, but without supporting documentation, Is won't trust them.   / On Mon, 22 Jan 2001 09:32:41 +0100, Arne Vajhja <arne.vajhoej@gtech.com> wrote:d   >David Beatty wrote:9 >> I can't seem to find the numbers yopu refer to at IDC.s >> Can you post the URLs?e >w7 >FUD people usually prefer to post undocumented stuff !> >e >Arnec   ------------------------------  % Date: Mon, 22 Jan 2001 09:44:26 -0500l  From: jamese@beast.dtsw.army.mil* Subject: Re: New OpenVMS Times now on line0 Message-ID: <01012209442653@beast.dtsw.army.mil>  F Paul Sture <paul@sture.ch> wrote in <VA.0000024b.2579af46@sture.ch> on  Sun, 21 Jan 2001 21:12:36 +0100:  M > I've found no way to print a straight Postscript document from a PC. It's, a > ahem, frustrating.  
 Amen to that.S  H What I do on my NT box is to go to the command prompt window, and enter:  !     D:\> type filepath.ps >>lpt1:y
         or7     D:\> type filepath.ps >>\\server\printer_queue_nameu  A I have these at the top level of the disk as .BAT files, such as:n       D:\> type hp4si.bat.*     type %1% >>\\server\printer_queue_name   then I can say:r       D:\> hp4si filepath.ps  C I can get duplex on our HP4Si, and others, is by another .BAT file:r       D:\> type hp4si_duplex.bat2     perl -ple "BEGIN { print q(%%!),qq(\n),q(%%!),4     qq(\nstatusdict begin true setduplexmode end\n);$     }" %1 >>\\server\hp4si_queuename  B The .BAT file is actually one long line, wrapped here for mailing.  : Ed James                           ed.james@telecomsys.com5 TeleCommunications Systems, Inc.   voice 410-295-1919y; 2024 West Street, Suite 300              800-810-0827 x1919.5 Annapolis, MD 21401-3556           fax   410-280-1094t   ------------------------------  % Date: Mon, 22 Jan 2001 14:51:25 +0000a0 From: andrew harrison <andrew.nospam@uk.sun.com>* Subject: Re: New OpenVMS Times now on line* Message-ID: <3A6C48ED.E480ED23@uk.sun.com>   David Beatty wrote:h > =n  8 > Yes, I got it.  ;-)  Andrew's numbers may very well be3 > accurate, but without supporting documentation, I  > won't trust them.a > =   3 > On Mon, 22 Jan 2001 09:32:41 +0100, Arne Vajh=F8j ! > <arne.vajhoej@gtech.com> wrote:  > =e   > >David Beatty wrote:; > >> I can't seem to find the numbers yopu refer to at IDC.  > >> Can you post the URLs?  > >y9 > >FUD people usually prefer to post undocumented stuff !a > >t > >Arner  , Why not ask IDC for the results you won't be dissapointed =      	 Regards =o   Andrew Harrison  Enterprise IT Architecth   ------------------------------    Date: 22 Jan 2001 18:25:19 +0800, From: Paul Repacholi <prep@prep.synonet.com>* Subject: Re: New OpenVMS Times now on line- Message-ID: <873debg9yo.fsf@prep.synonet.com>h  1 Chris Scheers <chris@applied-synergy.com> writes:A  J > However, I don't think that you are likely to find a VAX-750 on a plane!  ; Not disagreeing, but what were the Nordan 752s used for on?i Anyone able to say?o   -- u< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.r@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------  % Date: Mon, 22 Jan 2001 16:23:03 +0000 % From: Alan Greig <agreig@my-deja.com>p* Subject: Re: New OpenVMS Times now on line8 Message-ID: <20no6tgdodk22mq0qj9tcvcfle76234tpk@4ax.com>  3 On Mon, 22 Jan 2001 14:51:25 +0000, andrew harrisonv! <andrew.nospam@uk.sun.com> wrote:n    - >Why not ask IDC for the results you won't bes >dissapointed   F Hmm, I found the figures (dated DEC 2000) covering CY99. Unfortunately' IDC wants $3,5000 before I can read it.b  D I certainly would be disappointed if IDC want anything like that for= the DEC 2000 report. But as, as far as IDC's search engine is:E concerned, it does not exist that doesn't seem to be an option in anyc case.0   >g >o	 >Regards a >Andrew Harrison >Enterprise IT Architect   --
 Alan Greig   ------------------------------  % Date: Mon, 22 Jan 2001 11:38:00 -0600M/ From: Chris Scheers <chris@applied-synergy.com>N* Subject: Re: New OpenVMS Times now on line3 Message-ID: <3A6C6FF8.B7422AE6@applied-synergy.com>u   Paul Repacholi wrote:  > 3 > Chris Scheers <chris@applied-synergy.com> writes:a > L > > However, I don't think that you are likely to find a VAX-750 on a plane! > = > Not disagreeing, but what were the Nordan 752s used for on?  > Anyone able to say?0  H I'm not sure what a Nordan 752 is, but assuming that it is a militarizedD 750, I had heard of some on a sub.  (Going WAY out on the rumor limb here.)  G -----------------------------------------------------------------------a$ Chris Scheers, Applied Synergy, Inc.  C Voice: 817-237-3360            Internet: chris@applied-synergy.com h   Fax: 817-237-3074N   ------------------------------    Date: 22 Jan 2001 19:03:17 +0800, From: Paul Repacholi <prep@prep.synonet.com>= Subject: Re: No technical computing, was: expanding the nichel- Message-ID: <87u26retmy.fsf@prep.synonet.com>   4 mathog@seqaxp.bio.caltech.edu (David Mathog) writes:   > In article <rdeininger-1801012305200001@user-2iveahc.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:r > >af > >Rich Marcello recently said they have NO plans to push VMS for scientific and technical computing.   ; And I think Ric is making a BIG mistake here. more later...     L > That's rich (sorry for the pun).  The problem with VMS in a scientific andJ > technical environment is not that it cannot run the programs but that itI > makes PAINFULLY obvious how slow VMS is for computing work in general. sG > Compaq cannot push VMS for that usage now because to do so would justrJ > highlight what a really miserable job OpenVMS engineering has been doingL > with regards to key areas of OS performance.  Primarily this is related toK > disk IO, but pipes also stink, and even network IO is much slower than it F > could be.  For jobs that are CPU bound the differences are, as you'dM > expect, very small, just a few percent one way or the other.  Check throughrK > deja and you'll find a series of posts where I've documented all of these K > claims in great detail, comparing VMS and Linux on more or less identicale	 > DS10s. i  A Sorry David, but I feel you are at least 99% wrong. And the tests   I've done come out very pro-VMS.    K > Compaq knows that the VMS is hyper reliable but hideously slow except in  G > the magic "enterprise" realm, where huge numbers of disks, running on/O > zillions of controllers, are kept busy all the time shuffling massive amountsrA > of data about - AND all the data absolutely has to get to disk.   E No, if you take a unix designed and C coded app, it runs about as youn would expect; not real flash.r   ...e  F > The limitations that make VMS run poorly for the types of scientificF > computing that I usually do (very IO intensive) are the reason that M > VMS makes such a poor file server or web server.  It's the same reason VMS nI > is at the core of enterprise applications and not scattered around the  M > edges shuffling transactions.  For ANY program where disk and network IO isRH > important VMS will do a bad job unless it is propped up with megabucksJ > worth of hardware.  That isn't the sort of problem that Compaq should beM > trying to sweep under the rug or "target" their way out of - it's somethingu* > that they should be trying to fix ASAP.   E If you are running a big tech job and it is doing lots of IO, then itr% is time to rethink. Think P2 in fact.n  A It is half solved. The galaxy work, and more importantly, the newx> MM layout on Alpha is a huge step foward. The lagardly part isB the software. The LACK of VMS push in unis and Sci computing means@ that near NO app start on, or are written with any considerationC of VMS. So many things that VMS will do for the app get re-invented B many different times over. So you are faced with a major re-design% or band-aiding over the brain-damage.w  @ In several areas, data volumes are getting scary: astronomy, HEP? Mol Genetics, 3D visualization are some that come to mind. Whene= data files start runnig from hundreds of MB to hundreds of GBo7 *each*, you have to throw money. At HW, or at coffee ;).  @ But, where are the Giga BYTE plus storage connects? Where is theB GByte/sec CI replacment? And I do not see SAN yet comming anywhere@ near adite in either speed, or reliability. This seems just like6 the things you will need in your Enterprise site, yes?  ? Upper end Sci and Tech computing, is IMO the forcing ground andh> debug arena for mainstream, high performance, high reliabilityA requirements that VMS excels in. This area will keep VMS in front  of the pack.  H > Ironically, about the only applications that I know of that spend veryF > little time in IO relative to CPU time, and so run as well on VMS asH > anywhere, are cpu bound scientific and technical programs.   (AlthoughI > there you do run into the lack of support for MPI and PVM on OpenVMS.)    G Unless you have a low section bandwidth problem, or have DOE with their D billion dollar bucket, you need effective compute. You will not haveK the funds to max out every HW spec to worst case. You need to be efficient,oD and you need a system that can handle the 10% or so of jobs that are over the norm.  G This also needs to be done unless the Q wants yet another generation of @ graduates and managers whos responce to VMS is 'what's that?...'   -- p< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.d@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.   ------------------------------    Date: 22 Jan 2001 20:02:19 +0800, From: Paul Repacholi <prep@prep.synonet.com>= Subject: Re: No technical computing, was: expanding the nichen- Message-ID: <87puhfeqwk.fsf@prep.synonet.com>0  4 mathog@seqaxp.bio.caltech.edu (David Mathog) writes:   > In article <rdeininger-1801012305200001@user-2iveahc.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:/ > >Sf > >Rich Marcello recently said they have NO plans to push VMS for scientific and technical computing.   , This is not yet fit for exposure yet, but...  < These numbers are the speed in MFLOPS on Alpha M600s runningB VMS 7.2-1 and DU 4.?d Sorry, brain fade, the on before 5.0 anyway.B The VMS box has 96M, WSMAX is 32MB. The DU box, 64 MB, the process/ also grew to very close to 32MB in large sizes.f  ? The test code is FFTW-TEST, version 1 from MIT. The standard DU @ generation was used. For VMS it was just thrown at the compiler!  < The top line give OS and size of data ( complex - complex ).9 The data lines give the speed in MFLOPS for each subtest.o+ Each line is a run, most where run 5 times.t  A There is no 3600x3600 DU number as it was to large for the kernel  config.e  B Yes, I KNOW these numbers are not 'optimum', and that there shouldB be al sorts of tunning done. How ever, I suspect that it IS pretty? close to the average for most boxes on researchers desks unlessO, they have specialist support from their uni.  < Can you say paging?? Do not use for real work. You have been warned.    VMS 3600x3600 P8  ' 14.683201 14.465498 15.242671 15.426464 ' 24.153116 24.607297 24.137885 24.229562c' 24.806644 24.698597 23.967847 24.714545s' 22.892734 24.046899 24.229562 24.540248E' 22.397104 23.587522 24.532383 24.8590040   DU 1600x1600 P  '  1.624575  1.846240  2.016829  1.905070 '  2.069622  1.935263  1.812045  1.785000 '  2.097139  1.956157  1.933399  1.920702='  2.118218  1.722296  1.824570  1.814402 '  1.905643  1.823318  1.834744  1.843191$'  1.995768  1.677230  1.781479  1.830002s  
 VMS 1600x1600e  ' 34.491483 35.947588 40.367810 41.920418 ' 34.404384 37.480429 40.608453 41.791828r' 34.978526 37.173631 40.070988 41.347909o' 33.933091 37.532055 40.851982 42.642053s       DU 1500x1500  '  3.266406  3.215806  3.296795  3.356705e'  2.878771  2.984887  2.843215  2.904153 '  2.878976  2.816401  3.163741  2.804121:'  2.872444  3.042647  3.029413  3.0117730   DU 1461x1461  '  3.429431  2.286981  2.854260  4.068381 '  3.138715  2.695139  4.032257  3.789034 '  3.094126  3.827406  1.870322  4.100983S'  2.401243  3.012667  4.154292  5.260099 '  2.610360  4.476567  4.505356  3.791410t   DU 1459x1459  '  2.876645  2.448467  3.141081  3.961449R'  2.829397  2.529985  3.840333  3.3357170'  3.302588  2.543636  3.635115  3.878560B'  3.172879  2.872282  4.047744  3.569087o'  2.955844  4.767572  4.874793  3.970924s   DU 1458x1458  '  3.318994  4.275368  4.483497  4.277286h'  3.261876  4.663356  4.787488  4.667352 '  3.632155  5.468113  4.578887  5.439122 '  3.709242  4.717495  5.005797  4.917036 '  1.753306  2.484793  5.842206  6.757892o   DU 1400x1400  ' 12.370112 37.517436 39.855597 40.168510F'  2.110219 34.954176 39.659669 38.894866A'  1.496330 31.330842 39.170867 39.614732c' 34.330603 37.457141 35.123905 40.053462e' 33.631548 36.404025 34.591027 37.903864e   DU 1351x1351  '  6.151242 15.063011 15.430111 15.616060a' 14.248137 14.465512 15.538660 15.647487 ' 14.177468 14.415092 15.123957 15.618568 ' 14.237701 14.698509 15.495304 15.133378 ' 13.842265 14.824061 15.294129 15.159343    DU 1350x1350  '  7.689417 33.674395 42.344646 39.857364 ' 15.571332 37.163058 41.932914 37.291607s' 38.231979 34.537374 41.237892 39.476307 ' 37.035407 34.100425 42.586247 39.532599 ' 37.370598 33.815215 39.613289 35.991379T   DU 1306x1306  '  5.396129  5.621472  5.546450  5.707546 '  5.510608  5.587074  5.533039  5.696037.'  5.371918  5.613094  5.474896  5.631453 '  5.440134  5.628998  5.567802  5.674939c'  5.471250  5.481536  5.590356  5.357273B   DU 1304x1304  ' 12.776144  6.709414 14.078815 13.687410 ' 13.421327 13.582177 13.715539 13.790062 ' 13.433334 13.461433 13.660431 13.798511 ' 13.696772 13.912504 13.733309 14.255913p' 13.207854 13.528134 14.155125 13.707192o   DU 1250x1250  ' 31.899887 33.757880 36.097236 37.478001l   DU 1200x1200  ' 39.828380 35.084921 43.884225 42.740173a  
 DU 800x800  ' 37.856831 38.016230 42.517296 43.067785m' 37.913596 37.834159 43.185504 41.938927r' 37.419762 38.188504 41.443913 38.774215m' 37.542011 37.497466 42.078542 41.566568n' 37.320330 37.586672 43.111841 43.170749n  	 DU 1500x1:  O 63.098449 57.701281 55.818673 53.394116 63.728474 58.003795 55.316309 49.729967 O 62.835619 57.721360 58.701418 50.904566 63.851056 58.044369 55.687535 50.363861uO 63.752943 57.144927 55.261042 50.105344 63.752943 57.943051 55.631544 50.501801-O 63.998818 58.085020 56.464413 50.904582 63.900226 57.862222 54.480932 50.379157tO 63.170490 57.761539 58.432700 51.729698 63.777430 58.064687 58.166452 50.150759   	 DU 1501x1a   fpem  	 DU 1502x1   O 12.895753 12.663858 13.446638 12.636897 12.855851 12.679315 13.347289 12.968196 O 12.887749 12.617708 13.437936 13.008799 12.968200 12.718126 13.472802 13.190510   	 DU 1503x1u  O  3.127373  3.061970  3.084685  3.071016  2.042317  2.035916  2.031937  2.027973-   DU 512x1  O 79.405727 72.090091 88.333412 77.433305 79.733287 70.255721 88.495185 77.744794?O 79.569153 71.848899 87.771837 77.870080 79.733321 72.036356 88.051708 77.495396 O 78.790670 69.597959 88.051708 77.216749 79.340537 71.292336 87.851624 77.216749m    	 VMS 512x1mO 85.019676 74.602245 87.381333 75.800675 85.019676 74.898286 87.787758 76.414445 O 85.404380 74.602245 87.381333 76.106323 85.019676 74.602245 88.612056 76.725073oO 82.062470 70.690517 87.381333 77.993256 86.184329 74.602245 86.978654 76.106323jO 85.404380 70.956271 88.612056 76.106323 85.404380 74.898286 87.381333 76.106323D   VMS 100x100x100   ' 31.738167 35.090790 35.214785 37.047525o' 31.143076 35.339661 35.090790 37.047525s' 31.437805 34.845400 34.483683 38.037345t' 31.143076 34.967664 34.967664 37.465354    VMS 200x200x200t  ' 27.121903 27.129924 35.872614 33.834848p' 25.948027 27.129924 35.347312 33.661018d' 26.170121 27.421906 35.374576 36.428226c   -- c< 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: Mon, 22 Jan 2001 10:29:38 -0500+2 From: rdeininger@mindspring.com (Robert Deininger)= Subject: Re: No technical computing, was: expanding the nichenL Message-ID: <rdeininger-2201011029390001@user-2ivecei.dialup.mindspring.com>  [ In article <87puhfeqwk.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> wrote:o  . > This is not yet fit for exposure yet, but... > > > These numbers are the speed in MFLOPS on Alpha M600s runningD > VMS 7.2-1 and DU 4.?d Sorry, brain fade, the on before 5.0 anyway.D > The VMS box has 96M, WSMAX is 32MB. The DU box, 64 MB, the process1 > also grew to very close to 32MB in large sizes.s   Could you be more specific about the system(s)?  Full model name for the machine?  Processor type?  Size of the various caches?  FFTs tend to be very cache-sensitive.   What was the actual working set for the VMS process?  What was WSEXTENT?  Also there's a system parameter involved, whose name I can't remember off the top of my head.  The point is, VMS likely borrowed working set as needed above 32MB.C Make sure you are comparing similar situations between the two OSs..   Also, was VMS racking up a lot of "soft" page faults?  If so, it wasn't really paging at all in the usual meaning of the word.  There's opportunity for mischief here, since the VMS system has more total memory that the oonix one.p  A > The test code is FFTW-TEST, version 1 from MIT. The standard DU B > generation was used. For VMS it was just thrown at the compiler! > > > The top line give OS and size of data ( complex - complex ).; > The data lines give the speed in MFLOPS for each subtest.e- > Each line is a run, most where run 5 times.e > C > There is no 3600x3600 DU number as it was to large for the kernel8	 > config.  > D > Yes, I KNOW these numbers are not 'optimum', and that there shouldD > be al sorts of tunning done. How ever, I suspect that it IS prettyA > close to the average for most boxes on researchers desks unlessV. > they have specialist support from their uni. > > > Can you say paging?? Do not use for real work. You have been	 > warned.' >  > VMS 3600x3600 P  > ) > 14.683201 14.465498 15.242671 15.426464a) > 24.153116 24.607297 24.137885 24.229562n) > 24.806644 24.698597 23.967847 24.714545=) > 22.892734 24.046899 24.229562 24.540248 ) > 22.397104 23.587522 24.532383 24.859004s  \ What do the 4 numbers on a line mean?  Why is the first line so much slower than the others?    a > DU 1600x1600 P > ) >  1.624575  1.846240  2.016829  1.905070o) >  2.069622  1.935263  1.812045  1.785000s) >  2.097139  1.956157  1.933399  1.920702i) >  2.118218  1.722296  1.824570  1.814402-) >  1.905643  1.823318  1.834744  1.8431918) >  1.995768  1.677230  1.781479  1.830002e >  > VMS 1600x1600c > ) > 34.491483 35.947588 40.367810 41.920418D) > 34.404384 37.480429 40.608453 41.791828i) > 34.978526 37.173631 40.070988 41.347909s) > 33.933091 37.532055 40.851982 42.642053    Ok, I guess you are saying DUNIX doesn't page as nicely as VMS.  (Though I don't follow the details of your tests very well...)    -- p Robert Deininger rdeininger@mindspring.comn   ------------------------------   Date: 22 Jan 2001 16:39:51 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)= Subject: Re: No technical computing, was: expanding the niche-, Message-ID: <94hnon$5g1@gap.cco.caltech.edu>  a In article <94aa7u$4v5@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:o  6 Replying in one place to a bunch of different replies:   >Keith Brown said:H >At my site we happen to throw lots of controllers and disk at our DUNIXI >systems as well as our NT and OpenVMS systems.  Your accertion that thismB >is only done on VMS systems to increase IO performance is untrue.  L I did not mean to imply that it was done ONLY to improve IO performance, butL rather that in these _already_ large systems the slow intrinsic IO was beingH compensated for by extra hardware that would not have been required wereH the base VMS IO faster.  That is, in order to achieve a certain level ofF performance on VMS you will probably have to add more storage hardwareD than you might on other OS's.  Specific application example, let "1"= be the file server speed that can be achieved with Samba on aeB Linux DS10 with an U2W controller and a single 27 Gb disk under anE average (nonsaturating) load.  If you loaded VMS onto that exact same F machine, and Samba as well (or Pathworks) you will be fortunate indeedF to achieve .1 in file server performance in mixed reads/writes.  That C is, the average elapsed time for each operation would be about 10X tE longer on VMS.  (For the moment assume that the UPS on your Linux box F constitutes sufficient data integrity insurance, and that you can SYNCE all disks before its battery goes).  How much extra hardware must younE add to the identical DS10, once it's running VMS, to achieve the samen? level of file server performance?   On a very large system this-E "extraness" will be less evident, because you're already starting outyE with RAID arrays with built in (large) cache and battery backup.   IthF could be that if you choose the right storage solutions they'll behave< more or less memory (ie, they will effectively implement theA equivalent of file caching), and then you'll do no worse than theiD intrinsic 2-3X performance factor that RMS offers (versus Linux) for* file IO which is really memory to memory.   G >----------------------------------------------------------------------t' >Bill Todd" <billtodd@foo.mv.com> said:c >sJ >Perhaps it's just due to frustration (which is something I can sympathizeB >with), but in this post the bullshit far outweighs the substance.  ? Everything I said is based on my own benchmarks which are quitesE representative of the sorts of programs I run.  If you feel that theysA were deficient in some way feel free to point out the error in my  programs, they are at: s  <   http://seqaxp.bio.caltech.edu/pub/SOFTWARE/MYBENCHMARK.ZIP  F If some scaling factor takes over on larger systems that renders theseK benchmarks invalid that would be interesting.  So I invite everybody with a D spare GS$$$ and a few spare moments to run the benchmarks and see ifC you're big expensive machine can run them any faster than my small,d  inexpensive (sort of) DS10 can.    >lK >The fact that VMS disk-access-related performance *using default settings*iL >lags drastically behind, say, Linux's has been more than adequately coveredI >in this forum.  But the leap from that to the assertion that VMS *can't*lL >perform well when well-tuned is completely unfounded - just as unfounded asM >for VMS bigots to assert that Linux is intrinsically unsafe (especially when L >compared with VMS) because, by default, data gets written back to disk onlyK >when Linux happens to feel like it, hence arbitrary amounts may be lost ifo
 >power fails.t  G I will assert emphatically that on a DS10, using the benchmark programsrB indicated above, VMS *cannot* perform as well as Linux on the sameG hardware, no matter how you tune it, at least if it's written in C. ForsD programs that are completely IO bound, and record oriented, the 2-3XJ slowness of VMS/RMS/ Compaq C record IO compared to that of Linux/Compaq CI (same compiler, same language, same hardware, only the OS differs) cannot G be overcome by any amount of RMS tuning. Specifically, on an IO limitednK program VMS running RAMdisk->RAMdisk will run no faster than 1/3 to 1/2 the A speed of the same code running on Linux file cache-> file cache. b  D If you can provide an IO bound program, written in ANSI C, that doesJ better than that, RAMdisk->RAMdisk vs. filecache -> filecache, I'd be more than happy to see it.    >nG >----------------------------------------------------------------------h= >Paul Repacholi                               1 Crescent Rd.,a >SB >Sorry David, but I feel you are at least 99% wrong. And the tests! >I've done come out very pro-VMS.h  F The test you posted in the followup note was very unclear to me.  WereB you measuring the behavior of VMS *paging* versus Unix *paging*?  B That's not at all the problem I was addressing.  If you're seeing @ paging on Unix (linux in particular) it means that the amount ofI RAM available for file cache has been reduced to zero.  At that point VMSfD may well do better if for no other reason than it has locked up it'sK /buffer/block memory and that will not evaporate when the free memory pagespC go to zero.  The "solution" for Unix is, well, just don't do that. h   >eF >If you are running a big tech job and it is doing lots of IO, then it& >is time to rethink. Think P2 in fact.  + I don't understand what you are suggesting.    > B >It is half solved. The galaxy work, and more importantly, the new+ >MM layout on Alpha is a huge step foward. e  D Galaxy isn't going to do anything for small systems.  My DS10 seems F not to be running any faster since the GS models came out.  Upgrading : from a $5k system to a $250k system is also not an option!   >The lagardly part islC >the software. The LACK of VMS push in unis and Sci computing meansoA >that near NO app start on, or are written with any considerationiD >of VMS. So many things that VMS will do for the app get re-inventedC >many different times over. So you are faced with a major re-designp& >or band-aiding over the brain-damage. >oL >(Benchmarks - don't know what the program is doing or what's rate limiting.. >My comments referred to IO only, not paging.)  E I know that my benchmarks do nothing but IO.  What exactly were yourse doing?   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech  J **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------  % Date: Sun, 21 Jan 2001 22:48:23 -0800n) From: Wayne Holland <wholland@tscnet.com>r Subject: Re: Oldtimer forgot!xO Message-ID: <EB6F944F4809CC5E.8BDCEBCC2E7DA1EE.B59FD2A1510A58E5@lp.airnews.net>0   Howard S Shubs wrote:i >  > In articleF > <F6D766F0EF20C27E.4918811DC920E8AD.77B136E195466CD5@lp.airnews.net>,, > Wayne Holland <wholland@tscnet.com> wrote: > K > >The program I am compiling is a fortran source file.  Unfortunately, itstE > >an older fortran program trying to access the command line via theg > >($clidef) fortran library...aK > >"include '($clidef)' ".  So when I type in "RUN PROGRAM ARG1 ARG2" I getUI > >the dcl error of too many parameters.  I used this program a long time  > >ago on vax 785. > , > Do you have a .CLD file with that program? >  > --I > "...run in circles, scream and shout!"    I hope you have good backups.S  F Hi Howard.  No I don't have a .CLD file.  I'm still trying to regain aB lot of lost ground.  Its a different view when you get to do these things for the love of it.% Never thought I'd miss vms that much.k# And I'm writing this under Solaris.    ------------------------------  + Date: Mon, 22 Jan 2001 15:25:59 +0100 (CET)w: From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>2 Subject: Re: Open VMS mail and set forward numbersJ Message-ID: <Pine.LNX.4.21.0101221516090.22576-100000@irys.stanpol.com.pl>  # On 17 Jan 2001, Carl Perkins wrote:  [...]0< +How to get this into a file to do further processing? I was +going to suggest a2 +6- +$ define/user sys$output forwarding_data.tmp2 +2C +right before the "MAIL" command, but I just tried it and it didn't8G +work (it creates a file containing several two byte records consisting0$ +entirely of spaces - very strange).    Hmmm... Works for me !9;  But the output you describe is like empty forwarding list:5< means: *if* noone in wildcarded name has set a forward, then? MAIL returns "nothing" (mean: two empty lines) as distinct from  non-wildcarded one. 9  B.ex (testing 7.1-2 system, only few usernames defined):8 +++++++++++++++9 $ mail   MAIL> sho forw/user=*52 Username                        Forwarding address" SYSTEM                          GS   MAIL> sho forw/user=gs# GS has not set a forwarding address    MAIL> sho forw/user=g*   MAIL> sho forw/user=decnet' DECNET has not set a forwarding address8   MAIL>  ++++++++++++  6  Be aware for the empty lines after mail start and any4 command output: you get it even if does "nothing" in the expected output.  Please re-check -:)   [...] C +I do not know why the user mode redefinition of sys$output doesn't38 +work, but it doesn't on this OpenVMS Alpha V6.1 system.    For sure ?8  And in MAIL/OLD ?    Regards - Gotfryd -- 8E =====================================================================7F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME4. $!                        GS@stanpol.zabrze.plE =====================================================================5   ------------------------------  % Date: Mon, 22 Jan 2001 14:00:11 +01004, From: Hans Bachner <Hans.Bachner@compaq.com>1 Subject: Re: RA230+ (KZPAC-CA) and 18/36 GB Disks7* Message-ID: <3A6C2EDB.C984A3E7@compaq.com>   "Richard L. Dyson" wrote:2 > J > I have a few questions about the older Raid Array 230+ that Digital soldI > a few years ago.  I believe the 3-channel one was KZPAC-CB, it is a PCI13 > device and is supported in at least OpenVMS v7.1.4 V6.2-1H3 and V7.1 (and later)5  H > Does anyone know if the controller has any problems using the newer 18J > and 36 GB UltraSCSI disks?  When I got mine years ago, it was setup withI > 18 GB StorageWorks disks.  I was looking for info about the 36 GB disks7G > and this controller recently and ran across a claim in one of the SOC3: > pages that the 18 and 36 GB drives were "not supported". > < > http://www.compaq.com/products/quickspecs/SOC/QBQ24APF.PDF > D > This document refers to a dead URL about a workaround to the 32 GBC > logical limit:  http://webir.das.dec.com/info/CU5911/CU5911HM.HTM5  N Sorry about that link - it points to an internal system and in the meantime isN outdated anyway. More than that, it contains a description of the controller's7 capabilities, but not the info around the 32 GB limit. 9  A > that I have not been able to track down yet.  I believe that is4D > not to say there is a workaround for 32 GB disks, right?  Just for= > a logical volume made from, say multiple 9 GB disks, right?7  N The 32 GB limit is a limit for the *logical* volumes. You can always put sevenL 9 GB disks into a single BA356 and create a RAID 5 array with a net capacityK of ca. 54 GB. You then need to create two logical partitions of, say, 27 GB M each (though the partitions may be different in size - the only point to take3I care of is that a single logical partition can't exceed the 32 GB limit).a  L On the OpenVMS side, you'll find two drives which you can bind together as aN volume set, resulting in one large 54 GB drive from your applications point ofK view (with the additional goodie of a smaller disk cluster size on pre-V7.23J systems). The DSN article quoted in an earlier reply suggests that you useF software RAID to bind the logical volumes together which is not reallyI necessary if you let the controller do the RAID stuff as mentioned above.9  E > Since I can say the 18 GB drives are fine (running continuously for G > several years now), I wonder if I can hang 36 GB drives off the other9 > channels with no problems?  G 18 GB drives have not been tested, and therefore are not supported. I'm K (personally) not aware of any specific problems, but your mileage may vary.8  " The same is true for 36 GB drives.   --  E The above is my personal opinion which may or may not match Compaq's.  Hans Bachner Compaq Computer Austria2E Customer Services - Software Support          Hans.Bachner@compaq.com3   ------------------------------  % Date: Mon, 22 Jan 2001 10:36:13 +0000t0 From: andrew harrison <andrew.nospam@uk.sun.com>W Subject: Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)a* Message-ID: <3A6C0D1D.641878FA@uk.sun.com>   Jordan Henderson wrote:5 > , > In article <3A687E62.4FB2BD91@uk.sun.com>,4 > andrew harrison  <andrew.nospam@uk.sun.com> wrote: > >Jordan Henderson wrote: > >>. > >> In article <3A685D0F.76E1060@uk.sun.com>,7 > >> andrew harrison  <andrew.nospam@uk.sun.com> wrote:d6 > >> >Jordan Henderson spining madly like a top wrote: > >>B > >> >> Yet, when I challenged you in another post to come up with? > >> >> a single inaccuracy wrt to Java, you didn't rise to thec > >> >> challenge. > >> >>e > >> >> > >> >Perhaps another trip into dejanews would be a good idea. > >> >: > >> >No on second thoughts lets not do that we tried that9 > >> >last time and we all know now that any assertion ono= > >> >your part relating to any activity of yours in dejanews6 > >> >is at best suspect.x > >> >/ > >> >How about these, do they jog your memory.n > >> >: > >> >You asserted that the OpenVMS JVM was a little late.< > >> >This is incorrect the 1.2.X release was over 12 months< > >> >late, not a little and the 1.3.x release wasn't out at > >> >the time of posting. > >> >@ > >> >You asserted that Blackdown have some special relationship< > >> >with Sun and that Sun assists Blackdown in porting the > >> >JVM to Linux.k > >> >B > >> >This isn't true Sun provides source code drops to Blackdown. > >> > > >> > >b9 > >What is your position on your incorrect statement thats4 > >the OpenVMS JVM support was only a little late ?? > > 9 > >Oh I can guess, a little in your terms is over a year.c > >h > : > Only a little late in that very little software requires7 > 1.3.x and no other vendor other than Sun and IBM have 9 > seen fit to release it.  HP hasn't, Compaq hasn't, heckt9 > when I said that, Blackdown had just released 1.3 maybez > two weeks before.  >   8 Really, at the time of posting 1.3 wasn't out on Compaq 6 Tru64 or HP-UX as a FCS product, however in both cases- Tru64 and HP-UX beta versions were available.a  5 You now incorrectly assert that 1.3 production isn't  4 available now on either platforms. It is both Tru64 5 and HP-UX now have 1.3 production releases available.a  5 Remarkable, having got it wrong last time around you r are now repeating your errors.  8 But lets get this straight shall we, we were discussing 8 the fact that OpenVMS does not have the current 1.3 JVM,6 we now seem to have shifted this to the JVM that most  people use. Spin.   ; > Of course, par for the course for you, you've changed the9< > criteria, yet again.  Just today you said that I said that< > 1.2 was the most up-to-date.  A complete lie, I never said > it.b >   8 Well thats the rub isn't. You see you either didn't know: that 1.3 was available, in which case you had some excuse ; for saying that OpenVMS was a little out of date, assuming 59 a very loose definition of "little". Or you knew that 1.318 was available in which case you knew that your "a little7 out of date" claim was false when you posted it. Which 0 was it ???????    > > >> I stated that Sun and IBM were the only vendors that have9 > >> produced this high level of compliance that you deem0: > >> essential and you threw out these irrelevancies about< > >> Windows (whose port was produced by Sun) and Blackdown,/ > >> who to my way of thinking is not a vendor.u > >> > >y8 > >Why are Blackdown not a vendor, you never sucessfully- > >explained why you reached that conclusion.e > >J >  > Oh? I feel that I did: >   3 No you didn't. In fact what is obvious is that you  1 introduced Blackdown claiming that they had some s2 sort of special development relationship with Sun.  8 When it was clear that this was yet another mistake you 9 tried to claim that they are not a vendor to remove them a7 from the equation, they had by then become a liability y to you.h  7 It is clear that all your subsequent wriggling and spins reflects this.  4 You were the person who introduced Blackdown to the 	 equation.d  D > In article <8snjf1$hpd$1@nnrp1.deja.com>, first you are quoted and > then I reply:i > 3 > > > All this talk about perception is irrelevant.a > >t? > > It is not.  Other vendors are only investing in Java to thepB > > extent that they see it's in their benefit.  Investing heavilyA > > in a platform controlled by another vendor has been enough toeD > > give all the players (save Sun, of course) some reason to pause. > B > So, I feel that I have responded quite adequately explained whatB > the special interest is for vendors here.  You may not disagree,: > but this not a matter of accuracy or facts, but opinion. > ? > What was it you said awhile back about confusing disagreementt > with veracity? >   5 Quite and you appear to be confusing "adequate" with n8 inadequate. All you succeded in doing adequately was to 7 show that Blackdown who you introduced to the argument  + had become an embarassing liability to you..  4 > >And anyway why would Blackdown not being a vendor7 > >even be relevant to the discussion anyway. They havea9 > >to go through the same process to get a running JVM onc: > >Linux as OpenVMS engineering do to get a running JVM on > >OpenVMS.V > >o6 > >How ironic that in your attempt to refute my points4 > >you have re-introduced yet another example of the1 > >inaccuracies that littered your Java postings.h > > < > >You have also not explained why IBM being able to release: > >their production JVM's at the same time as Sun does not: > >disprove your argument that the Java platform market is9 > >tilted in Sun's favour from an availability of the JVMd > >standpoint. > > 7 > >Surely you understand that if IBM can do it then any  > >other vendor can. > 7 > Oh yes, right, IBM, the largest software/hardware and-3 > consultancy in the world.  If they can do it, why 3 > anyone can.  Of course, that makes perfect sense.  > 4 Ohh so now its a resourcing issue. This wasn't what  you were arguing before.  4 This of course ignores the fact that IBM are a huge 7 company but the HW divisions that provide Java support  6 for their platforms are not. IBM's server revenues for5 all of its server businesses is only marginally more  & than Sun and Compaqs server business.   5 It also ignores the fact that IBM provide a lot more A1 Java than Compaq does. WebSphere for example and o1 VisualAge provide Java development and deployments. platforms and consume a large amount of IBM's 
 resources.  9 It also ingores the fact that IBM also provide much more a9 in the way of platform support than Compaq do, the AS/400n4 Java toolkit for example is a model of how one could7 open OpenVMS services to Java apps if one put ones mindm to it. n  7 Of course resources are an issue, clearly Compaq don't s6 have the resources for a full and up-to-date supported8 Java platform on all their platforms and because of that9 some are better supported than others. This however isn'tu anything to do with Sun.    6 > I'm still waiting for real inaccuracies and not just > differences of opinion.h >   9 Jordan the very first point, you suggestion that Compaq'sw7 support for OpenVMS is only a little bit out of date iss6 demonstrably untrue and with it raises the question of7 your understanding of what the current JVM is. Rememberi7 if as you claim you knew that 1.3.x was the current JVM 9 then your little bit out of date statement gets even more  embarrasing.   Regardsa Andrew Harrisone Enterprise IT Architect    ------------------------------    Date: 22 Jan 2001 09:57:53 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)nW Subject: Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)n* Message-ID: <94hhph$jcv$1@lisa.gemair.com>  * In article <3A6C0D1D.641878FA@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote: >Jordan Henderson wrote: >> a- >> In article <3A687E62.4FB2BD91@uk.sun.com>,m5 >> andrew harrison  <andrew.nospam@uk.sun.com> wrote:s >> >Jordan Henderson wrote:i >> >>,/ >> >> In article <3A685D0F.76E1060@uk.sun.com>,-8 >> >> andrew harrison  <andrew.nospam@uk.sun.com> wrote:7 >> >> >Jordan Henderson spining madly like a top wrote:  >> >>tC >> >> >> Yet, when I challenged you in another post to come up witht@ >> >> >> a single inaccuracy wrt to Java, you didn't rise to the >> >> >> challenge.e >> >> >> >> >> >o? >> >> >Perhaps another trip into dejanews would be a good idea.x >> >> >?; >> >> >No on second thoughts lets not do that we tried thate: >> >> >last time and we all know now that any assertion on> >> >> >your part relating to any activity of yours in dejanews >> >> >is at best suspect. >> >> >d0 >> >> >How about these, do they jog your memory. >> >> > ; >> >> >You asserted that the OpenVMS JVM was a little late.e= >> >> >This is incorrect the 1.2.X release was over 12 monthsj= >> >> >late, not a little and the 1.3.x release wasn't out ata >> >> >the time of posting.e >> >> > A >> >> >You asserted that Blackdown have some special relationshipr= >> >> >with Sun and that Sun assists Blackdown in porting them >> >> >JVM to Linux. >> >> >aC >> >> >This isn't true Sun provides source code drops to Blackdown.y >> >> >  >> >>y >> >: >> >What is your position on your incorrect statement that5 >> >the OpenVMS JVM support was only a little late ??5 >> >: >> >Oh I can guess, a little in your terms is over a year. >> > >> e; >> Only a little late in that very little software requiresr8 >> 1.3.x and no other vendor other than Sun and IBM have: >> seen fit to release it.  HP hasn't, Compaq hasn't, heck: >> when I said that, Blackdown had just released 1.3 maybe >> two weeks before. >> d >d9 >Really, at the time of posting 1.3 wasn't out on Compaq h7 >Tru64 or HP-UX as a FCS product, however in both casesm. >Tru64 and HP-UX beta versions were available. >a6 >You now incorrectly assert that 1.3 production isn't 5 >available now on either platforms. It is both Tru64 .6 >and HP-UX now have 1.3 production releases available. >o6 >Remarkable, having got it wrong last time around you  >are now repeating your errors.* >*  8 OK.  So, HP hadn't, Compaq hadn't.  Oh my, you've caught3 me in an inaccuracy!  I guess I no longer have any *2 right to talk about, what appears to be, your many lies and errors.  4 Of course, when I make a real error, I stand up and 8 admit it.  I don't just silently cut those uncomfortable8 questions that I wish to sidestep out of my replies like some do.  9 >But lets get this straight shall we, we were discussing a9 >the fact that OpenVMS does not have the current 1.3 JVM,D7 >we now seem to have shifted this to the JVM that most   >people use. Spin. >r< >> Of course, par for the course for you, you've changed the= >> criteria, yet again.  Just today you said that I said thatn= >> 1.2 was the most up-to-date.  A complete lie, I never saidi >> it. >> w > 9 >Well thats the rub isn't. You see you either didn't knowo; >that 1.3 was available, in which case you had some excuse a< >for saying that OpenVMS was a little out of date, assuming : >a very loose definition of "little". Or you knew that 1.39 >was available in which case you knew that your "a little 8 >out of date" claim was false when you posted it. Which  >was it ???????e >t  : I wouldn't have said it was a little out of date had I not; known about the existence of 1.3, would I have?  Of course,d8 I still contend that 1.2 is just a "little out of date".7 The gross majority of existing Java commercial softwarei still supports it.  6 If we're talking about inaccuracies, you just recently8 accused me of saying that 1.2 was the most recent, which you've been unable back up.>   >n? >> >> I stated that Sun and IBM were the only vendors that have : >> >> produced this high level of compliance that you deem; >> >> essential and you threw out these irrelevancies aboutg= >> >> Windows (whose port was produced by Sun) and Blackdown,80 >> >> who to my way of thinking is not a vendor. >> >>c >> >9 >> >Why are Blackdown not a vendor, you never sucessfully.. >> >explained why you reached that conclusion. >> > >> y >> Oh? I feel that I did:* >> o > 4 >No you didn't. In fact what is obvious is that you 2 >introduced Blackdown claiming that they had some 3 >sort of special development relationship with Sun., >l9 >When it was clear that this was yet another mistake you L: >tried to claim that they are not a vendor to remove them 8 >from the equation, they had by then become a liability  >to you. >s8 >It is clear that all your subsequent wriggling and spin >reflects this.h >o5 >You were the person who introduced Blackdown to the 8
 >equation. >+    7 Actually, I said that the only groups that had producedd6 Java 1.3 were Sun and IBM.  I was thinking at the time4 'vendors', but didn't know that the Linux effort was independent of the vendors.e  8 You came back with "how do you explain Windows and Linux: then?????".  Well, Windows was PRODUCED by Sun, so that's 4 a non-issue.  I guess I have to admit to yet another9 'inaccuracy'.  Oh, the shame, I'll never be able to live = it down.  7 Of course, it's not substantive nor important.  ClearlyL6 the point stands that, among vendors, only Sun and IBM7 are so interested in releasing the newest Java releases= in lockstep.  6 As you've pointed out, HP and Compaq have now released3 1.3.  So, they've shown long term commitment to theB platform.  B  E >> In article <8snjf1$hpd$1@nnrp1.deja.com>, first you are quoted ande >> then I reply: >> 44 >> > > All this talk about perception is irrelevant. >> >@ >> > It is not.  Other vendors are only investing in Java to theC >> > extent that they see it's in their benefit.  Investing heavily B >> > in a platform controlled by another vendor has been enough toE >> > give all the players (save Sun, of course) some reason to pause.y >> lC >> So, I feel that I have responded quite adequately explained what C >> the special interest is for vendors here.  You may not disagree,i; >> but this not a matter of accuracy or facts, but opinion.e >> a@ >> What was it you said awhile back about confusing disagreement >> with veracity?n >> p >t6 >Quite and you appear to be confusing "adequate" with 9 >inadequate. All you succeded in doing adequately was to o8 >show that Blackdown who you introduced to the argument , >had become an embarassing liability to you. > 5 >> >And anyway why would Blackdown not being a vendorn8 >> >even be relevant to the discussion anyway. They have: >> >to go through the same process to get a running JVM on; >> >Linux as OpenVMS engineering do to get a running JVM onn >> >OpenVMS. >> >7 >> >How ironic that in your attempt to refute my pointsu5 >> >you have re-introduced yet another example of thee2 >> >inaccuracies that littered your Java postings. >> >= >> >You have also not explained why IBM being able to releases; >> >their production JVM's at the same time as Sun does noty; >> >disprove your argument that the Java platform market isw: >> >tilted in Sun's favour from an availability of the JVM >> >standpoint.e >> >8 >> >Surely you understand that if IBM can do it then any >> >other vendor can.t >> e8 >> Oh yes, right, IBM, the largest software/hardware and4 >> consultancy in the world.  If they can do it, why4 >> anyone can.  Of course, that makes perfect sense. >>  5 >Ohh so now its a resourcing issue. This wasn't what   >you were arguing before.. > 5 >This of course ignores the fact that IBM are a huge g8 >company but the HW divisions that provide Java support 7 >for their platforms are not. IBM's server revenues fore6 >all of its server businesses is only marginally more ' >than Sun and Compaqs server business.   >n  . Oh?  Is this including mainframes and AS/400s?  4 In any case, IBM being a huge business is extremely , important here.  The other vendors show less5 enthusiastic support for a platform that will clearlyr5 lend credence and probably sales to Sun's bottom linei2 (through Sun's undeniable association as being the king of Java).  2 IBM has clearly decided that it's a strategic move1 to show as much support for Java as Sun.  I posit20 that this is to help prop up flagging mainframe 1 viability and to eliminate small players from the-0 server field who don't have the wherewithall to  support Java on their machines.m  4 Only the biggest IT company in the world can commit 3 to such a strategy.  Others resource the Java portsg1 perhaps a little less enthusiastically.  I wondere0 if there's any real marketing studies that have 1 demostrated that potential customers are effecteds3 by this?  On the positive side, Compaq continues to>6 be able to demonstrate world-beating Java performance,3 making Sun's numbers look pitiful in comparison.  Io) would expect that to help sales somewhat.t  6 >It also ignores the fact that IBM provide a lot more 2 >Java than Compaq does. WebSphere for example and 2 >VisualAge provide Java development and deployment/ >platforms and consume a large amount of IBM's t >resources.u >b: >It also ingores the fact that IBM also provide much more : >in the way of platform support than Compaq do, the AS/4005 >Java toolkit for example is a model of how one could 8 >open OpenVMS services to Java apps if one put ones mind >to it.  >>8 >Of course resources are an issue, clearly Compaq don't 7 >have the resources for a full and up-to-date supported 9 >Java platform on all their platforms and because of that : >some are better supported than others. This however isn't >anything to do with Sun.. >   5 I agree it has nothing to do with Sun. And that's why 7 we were talking about Compaq's commitment.  Quit tryingw
 to spin here.e   >>7 >> I'm still waiting for real inaccuracies and not justd >> differences of opinion. >> . > : >Jordan the very first point, you suggestion that Compaq's8 >support for OpenVMS is only a little bit out of date is7 >demonstrably untrue and with it raises the question ofe8 >your understanding of what the current JVM is. Remember8 >if as you claim you knew that 1.3.x was the current JVM: >then your little bit out of date statement gets even more
 >embarrasing.p >h  9 I disagree.  I've pointed out two inaccuracies above, one 9 that I just made recently and one I had made, but quickly 7 corrected, in our earler discussions.  Hardly in league : with your many inaccuracies and outright deceptions.  Some	 examples:a  0 	SIMS product used no code developed on OpenVMS.  5 	The eBay failures have been completely demonstrated,s1 	beyond the shadow of any doubt, not to have beene 	caused by Sun HW/SW.a  . 	The Sun eCache problems have long been fixed.  / 	Your contention that it's an absurd and biasedi3 	charge that Sun has used NDAs to silence customersa2 	who have stories to tell about Sun unreliability.3 	(Even though Analysts like Gartner and trade pressp0 	sources agree that this is exactly what Sun was3 	doing with their NDAs and a Sun Exec VP even later ) 	said that these NDAs were "a bad idea".)   / 	Accusing people of FUD for years here when youa1 	apparently didn't even know what the term meant.   4 	Accusing me of not using the term FUD consistently.  ? Even on the Java issue we discussed, I believe you demonstratedtF  more real substantive inaccuracies (not just differences of opinion, A like I contend is the case for the "little out of date" statement  above), than I did:s  5 	IBM was never at odds over standards issues with Sun 4 	on Java.  (I was able to show this to be false, you 	never responded.)  7 	Your contention that I said that Java 1.2 was the mosti 	up-to-date.  + You just keep digging yourself in deeper...(   >Regards >Andrew Harrison >Enterprise IT Architect   -Jordan Hendersong jordan@greenapple.com>   ------------------------------  % Date: Mon, 22 Jan 2001 16:19:34 +0000n0 From: andrew harrison <andrew.nospam@uk.sun.com>W Subject: Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)d* Message-ID: <3A6C5D96.19C9AD25@uk.sun.com>   Jordan Henderson wrote:n > 5 > Of course, when I make a real error, I stand up and : > admit it.  I don't just silently cut those uncomfortable: > questions that I wish to sidestep out of my replies like
 > some do. >   5 You havn't admitted one so far and you have made somew4 real corkers so I very much doubt that this is true.    < > I wouldn't have said it was a little out of date had I not= > known about the existence of 1.3, would I have?  Of course,I: > I still contend that 1.2 is just a "little out of date".9 > The gross majority of existing Java commercial softwarei > still supports it. >   6 Well again there is the rub. When you made your claims5 1.2.X had just been released over 12 months late for b4 OpenVMS and 1.3 wasn't available at all in any form.  3 Now not having the current release at all either on 3 either alpha or beta isn't a little late is it. If  3 you don't know when something is going to arrive ats1 all then you cannot describe it as a little late.s  5 I am glad you arn't in the transportation business :)o  1 So which was it. Did you just want to try to makeu. a throwaway point or did you know exactly what you were doing ???    8 > If we're talking about inaccuracies, you just recently: > accused me of saying that 1.2 was the most recent, which > you've been unable back up.A >   3 Jordan this argument is obviusly too taxing for youe take a rest and think about it.y  6 Either you were b******TING when you said that OpenVMS3 was a "little late" or you didn't know about 1.3 in 3 which case you were just stating an opinion withouti being equipped to make one.u  6 >>This of course ignores the fact that IBM are a huge 9 >>company but the HW divisions that provide Java support h8 >>for their platforms are not. IBM's server revenues for7 >>all of its server businesses is only marginally more  ( >>than Sun and Compaqs server business.  >t0 > Oh?  Is this including mainframes and AS/400s? >   * Yes, I did say all IBM's server revenues.   5 > In any case, IBM being a huge business is extremelyt. > important here.  The other vendors show less7 > enthusiastic support for a platform that will clearlyc7 > lend credence and probably sales to Sun's bottom lineO4 > (through Sun's undeniable association as being the > king of Java). > 4 > IBM has clearly decided that it's a strategic move3 > to show as much support for Java as Sun.  I positn1 > that this is to help prop up flagging mainframe 3 > viability and to eliminate small players from ther1 > server field who don't have the wherewithall too! > support Java on their machines.u >   2 Do you remember SAA, to IBM Java is SAA it allows 4 them to have one development and deployment platform4 for all their OS/s and all their hardware platforms.  4 This is one reason why IBM has pumped resources into2 Java. Ironically you are right they also see it as3 the saviour of the mainframe because it will allow a- them to get apps back onto the platform, ringp a bell.   3 It would appear that your criticism if any is that s2 IBM seem to be more interested in preserving their1 high end server platform and OS than Compaq does.r  2 As with most of your arguments you end up arguing . against things that expose the deficiences of 1 your favourite vendor rather that arguing againste the deficiencies themselves.  5 > Only the biggest IT company in the world can commito5 > to such a strategy.  Others resource the Java portsr3 > perhaps a little less enthusiastically.  I wonder 1 > if there's any real marketing studies that havee3 > demostrated that potential customers are effected 5 > by this?  On the positive side, Compaq continues toi8 > be able to demonstrate world-beating Java performance,5 > making Sun's numbers look pitiful in comparison.  Im+ > would expect that to help sales somewhat.o >     : Really again you are ill informed. You may be refering to 7 SPEC JVM98 which is by SPEC's own description a client c8 side Java benchmark and therefor not really great market for OpenVMS.  9 SPEC JBB2000 the server side Java benchmark would be much$5 more applicable to the market the Alpha boxes running@; any OS play in and no Compaq does not have industry leadingt performance for SPEC JBB2000.>    9 > >Of course resources are an issue, clearly Compaq don'ta9 > >have the resources for a full and up-to-date supportede; > >Java platform on all their platforms and because of thatu< > >some are better supported than others. This however isn't > >anything to do with Sun.  > >n > 7 > I agree it has nothing to do with Sun. And that's whyl9 > we were talking about Compaq's commitment.  Quit tryingl > to spin here.t >   8 Really, your point origionally was that Sun had made the4 Java playing field slant in our direction, this had 7 nothing to do with resources and you accuse me of spin.h  6 I would suggest that whenever you think of making this9 accusation that you reflect that in almost every occasiont; that you have made this in the past you have been refering u to yourself and not me.H > >o9 > >> I'm still waiting for real inaccuracies and not justs > >> differences of opinion. > >> > >a< > >Jordan the very first point, you suggestion that Compaq's: > >support for OpenVMS is only a little bit out of date is9 > >demonstrably untrue and with it raises the question ofY: > >your understanding of what the current JVM is. Remember: > >if as you claim you knew that 1.3.x was the current JVM< > >then your little bit out of date statement gets even more > >embarrasing.c > >r > ; > I disagree.  I've pointed out two inaccuracies above, onet; > that I just made recently and one I had made, but quicklyp9 > corrected, in our earler discussions.  Hardly in league < > with your many inaccuracies and outright deceptions.  Some > examples:t > A > Even on the Java issue we discussed, I believe you demonstratedtG >  more real substantive inaccuracies (not just differences of opinion,tC > like I contend is the case for the "little out of date" statement> > above), than I did:d > > >         IBM was never at odds over standards issues with Sun= >         on Java.  (I was able to show this to be false, youa >         never responded.)v >   0 No sorry again you did not, you may have thought- you had but you confused the standardisation s- process with branding. Yet another simple butr crucial mistake.  @ >         Your contention that I said that Java 1.2 was the most >         up-to-date.y >    Regards* Andrew Harrisona Enterprise IT Architectm   ------------------------------    Date: 22 Jan 2001 12:09:13 -0500/ From: jordan@lisa.gemair.com (Jordan Henderson)aW Subject: Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)I* Message-ID: <94hpfp$tbs$1@lisa.gemair.com>  * In article <3A6C5D96.19C9AD25@uk.sun.com>,2 andrew harrison  <andrew.nospam@uk.sun.com> wrote: >Jordan Henderson wrote: >> a6 >> Of course, when I make a real error, I stand up and; >> admit it.  I don't just silently cut those uncomfortable ; >> questions that I wish to sidestep out of my replies liker >> some do.c >> d >e6 >You havn't admitted one so far and you have made some5 >real corkers so I very much doubt that this is true.i >I  6 I still haven't seen any "real corkers".  You seem to 9 apply the 'big lie' technique of Goebbles.  Say somethingi6 loud enough and often enough and people will start to  believe you.   >u= >> I wouldn't have said it was a little out of date had I noty> >> known about the existence of 1.3, would I have?  Of course,; >> I still contend that 1.2 is just a "little out of date".t: >> The gross majority of existing Java commercial software >> still supports it.h >> n > 7 >Well again there is the rub. When you made your claimse6 >1.2.X had just been released over 12 months late for 5 >OpenVMS and 1.3 wasn't available at all in any form.f >r4 >Now not having the current release at all either on4 >either alpha or beta isn't a little late is it. If 4 >you don't know when something is going to arrive at2 >all then you cannot describe it as a little late. >o6 >I am glad you arn't in the transportation business :) >o2 >So which was it. Did you just want to try to make/ >a throwaway point or did you know exactly whatw >you were doing ???d >  >)9 >> If we're talking about inaccuracies, you just recentlyv; >> accused me of saying that 1.2 was the most recent, which  >> you've been unable back up. >>   > 4 >Jordan this argument is obviusly too taxing for you  >take a rest and think about it. > 7 >Either you were b******TING when you said that OpenVMSw4 >was a "little late" or you didn't know about 1.3 in4 >which case you were just stating an opinion without >being equipped to make one. >e  4 I claim I did know about 1.3.  You claim I didn't.  3 Seeing as other vendors hadn't come out with 1.3 atm1 the time, I felt justified in calling it a little  late.b  3 You however keep sidestepping the point here.  You w2 did say that I claimed that 1.2 was the latest.  A clear innacuracy.c  0 This debate really isn't about Java, it's about 0 accuracy, mine and yours.  You keep spouting off- huge inaccuracies and picking at nits from myi	 postings.w  4 I would advise you to get a mirror, but as I've said6 before you either couldn't look into it or it wouldn't do you any good.  7 >>>This of course ignores the fact that IBM are a huge i: >>>company but the HW divisions that provide Java support 9 >>>for their platforms are not. IBM's server revenues forv8 >>>all of its server businesses is only marginally more ) >>>than Sun and Compaqs server business.   >>1 >> Oh?  Is this including mainframes and AS/400s?  >> u > + >Yes, I did say all IBM's server revenues.   >.6 >> In any case, IBM being a huge business is extremely/ >> important here.  The other vendors show lessc8 >> enthusiastic support for a platform that will clearly8 >> lend credence and probably sales to Sun's bottom line5 >> (through Sun's undeniable association as being thev >> king of Java).n >> t5 >> IBM has clearly decided that it's a strategic move>4 >> to show as much support for Java as Sun.  I posit2 >> that this is to help prop up flagging mainframe4 >> viability and to eliminate small players from the2 >> server field who don't have the wherewithall to" >> support Java on their machines. >> h >.3 >Do you remember SAA, to IBM Java is SAA it allows  5 >them to have one development and deployment platformy5 >for all their OS/s and all their hardware platforms.t >e5 >This is one reason why IBM has pumped resources inton3 >Java. Ironically you are right they also see it asd4 >the saviour of the mainframe because it will allow . >them to get apps back onto the platform, ring	 >a bell. a >i4 >It would appear that your criticism if any is that 3 >IBM seem to be more interested in preserving theiri2 >high end server platform and OS than Compaq does. >s3 >As with most of your arguments you end up arguing e/ >against things that expose the deficiences of >2 >your favourite vendor rather that arguing against >the deficiencies themselves.d >d6 >> Only the biggest IT company in the world can commit6 >> to such a strategy.  Others resource the Java ports4 >> perhaps a little less enthusiastically.  I wonder2 >> if there's any real marketing studies that have4 >> demostrated that potential customers are effected6 >> by this?  On the positive side, Compaq continues to9 >> be able to demonstrate world-beating Java performance,h6 >> making Sun's numbers look pitiful in comparison.  I, >> would expect that to help sales somewhat. >> d >e >d; >Really again you are ill informed. You may be refering to y8 >SPEC JVM98 which is by SPEC's own description a client 9 >side Java benchmark and therefor not really great marketr
 >for OpenVMS.e > : >SPEC JBB2000 the server side Java benchmark would be much6 >more applicable to the market the Alpha boxes running< >any OS play in and no Compaq does not have industry leading >performance for SPEC JBB2000. >   ; I'm not sure why Compaq hasn't done JBB2000 on their larger 8 systems, but the price performance looks excellent, with4 similarly sized Compaq systems beating the similarly3 sized competition.  Compaq has the best 2 processors2 result, the best 4 processor result and the best 8 processor result.l  < Sun, for some reason, hasn't subitted any JBB2000 benchmarks at all.  I wonder why?   > : >> >Of course resources are an issue, clearly Compaq don't: >> >have the resources for a full and up-to-date supported< >> >Java platform on all their platforms and because of that= >> >some are better supported than others. This however isn'tw >> >anything to do with Sun. >> > >> s8 >> I agree it has nothing to do with Sun. And that's why: >> we were talking about Compaq's commitment.  Quit trying >> to spin here. >> s >t9 >Really, your point origionally was that Sun had made theh5 >Java playing field slant in our direction, this had c8 >nothing to do with resources and you accuse me of spin. >e7 >I would suggest that whenever you think of making thisi: >accusation that you reflect that in almost every occasion< >that you have made this in the past you have been refering  >to yourself and not me. >> >: >> >> I'm still waiting for real inaccuracies and not just >> >> differences of opinion.e >> >>t >> >= >> >Jordan the very first point, you suggestion that Compaq's ; >> >support for OpenVMS is only a little bit out of date isi: >> >demonstrably untrue and with it raises the question of; >> >your understanding of what the current JVM is. Rememberp; >> >if as you claim you knew that 1.3.x was the current JVM>= >> >then your little bit out of date statement gets even morev >> >embarrasing. >> > >> d< >> I disagree.  I've pointed out two inaccuracies above, one< >> that I just made recently and one I had made, but quickly: >> corrected, in our earler discussions.  Hardly in league= >> with your many inaccuracies and outright deceptions.  Somen >> examples: >> mB >> Even on the Java issue we discussed, I believe you demonstratedH >>  more real substantive inaccuracies (not just differences of opinion,D >> like I contend is the case for the "little out of date" statement >> above), than I did: >> i? >>         IBM was never at odds over standards issues with Suns> >>         on Java.  (I was able to show this to be false, you >>         never responded.) >> 1 >x1 >No sorry again you did not, you may have thoughtd. >you had but you confused the standardisation . >process with branding. Yet another simple but >crucial mistake.t >j   Well, here it goes again...   6 I quote from my posting <8snjf1$hpd$1@nnrp1.deja.com>:  ? > > You seem to be mistaking branding with standardisation, twoiB > > different things. IBM have had issues with the branding, which? > > despite your FUD have been resolved, they havn't had issues & > > with the API standards themselves. > 2 > Oh?  Just about branding?  Let's take a look at: > B > http://www.zdnet.com/intweek/stories/news/0,4164,2404696,00.html > ! > Which contains the interesting:s > A >   At the same time, IBM is threatening to back an internationaltG >   standard body's effort to establish a public specification for JavatA >   without Sun's cooperation, if Sun persists in withholding theE% >   details of the standard for Java.A > C >   "The ECMA technical committee has sent out a letter stating itsaH >   intent to evaluate the possibility of moving forward [to establish aA >   standard]," Hebner said. "IBM supports that move. We're stillcF >   hopeful, though, that this process will get back to where it was." > H > Sounds to me like IBM was concerned over the status of standardization > at one time.  B Care to take a stab at this point now?  You didn't respond to this/ point back in Oct 2000 when I posted it before.w  C I'm surprised you'd challenge me again.  But, you'll probably just aB bluster on, deleting all my good points as you have in this thread* and grand standing on some nit or another.    A >>         Your contention that I said that Java 1.2 was the mostn >>         up-to-date. >> - >- >Regards >Andrew Harrison >Enterprise IT Architect   -Jordan Henderson  jordan@greenapple.como   ------------------------------  % Date: Mon, 22 Jan 2001 18:25:13 +0000a0 From: andrew harrison <andrew.nospam@uk.sun.com>W Subject: Re: Rehash of Andrew's Java on OpenVMS FUD.  (was: Re: GS160 hardwarequestion)d* Message-ID: <3A6C7B09.73FED248@uk.sun.com>   Jordan Henderson wrote:  > 9 > >Either you were b******TING when you said that OpenVMSe6 > >was a "little late" or you didn't know about 1.3 in6 > >which case you were just stating an opinion without > >being equipped to make one. > >i > 4 > I claim I did know about 1.3.  You claim I didn't.5 > Seeing as other vendors hadn't come out with 1.3 ato3 > the time, I felt justified in calling it a little  > late.o >   / I know what you claim, the problem is your pastp, postings do not support this claim and your 0 allegation that OpenVMS's JVM support is only a  little late.  0 You are trying to have both when for you its an  either or question.   1 Either you knew that 1.3 was the current release  / in which case you also new that the little latef1 claim was untrue or you did not in which case thee1 little late claim is just a new definition on thea0 word little. Over 12 months after 1.2.X had been/ made available on other plaforms is not little.t  4 > You however keep sidestepping the point here.  You4 > did say that I claimed that 1.2 was the latest.  A > clear innacuracy.u >   2 You don't get it do you, you didn't claim directly7 that 1.2.X was the latest release but you demonstrated o5 that you were unaware it was by saying fact that the e9 1.2.x had just made it onto OpenVMS ment that JVM support " on OpenVMS was only a little late.  / Now you contend that you did know that 1.3 was  , the latest release, which if true ment that / you knew that your "little" statment was untruee+ when you made it. You cannot use little to p, describe the availability of a product when * you have no release date for that product.   Which do you want it to be ????s  1 > This debate really isn't about Java, it's aboutn2 > accuracy, mine and yours.  You keep spouting off/ > huge inaccuracies and picking at nits from myd > postings.s >   / This is not picking nits, you either knew that u/ 1.3 was the current release and hence knew thatr1 your little statement wasn't true or you did not.a  < > >SPEC JBB2000 the server side Java benchmark would be much8 > >more applicable to the market the Alpha boxes running> > >any OS play in and no Compaq does not have industry leading  > >performance for SPEC JBB2000. > >s > = > I'm not sure why Compaq hasn't done JBB2000 on their largero: > systems, but the price performance looks excellent, with6 > similarly sized Compaq systems beating the similarly5 > sized competition.  Compaq has the best 2 processor 4 > result, the best 4 processor result and the best 8 > processor result.l >   4 Firstly SPEC does not measure price performance, and3 secondly Compaq have not published an 8 CPU JBB2000M6 result. They do not have the best 8 CPU result because they have not published one.  4 > > Oh?  Just about branding?  Let's take a look at: > >pD > > http://www.zdnet.com/intweek/stories/news/0,4164,2404696,00.html > >t  . Wonderfull the URL you posted is exactly what . I said, a reference to a branding dispute long# since resolved between Sun and IBM.t  , The branding dispute was not about what say * should be included in for example JMS etc ) but about what components JMS etc had to  . be included in a platform for it to be branded as being J2EE compliant.  1 IBM wanted a reduced set of components Sun wanted ) all the origionally specified components.e  2 Nor would the dispute have stopped IBM rolling out4 their own Java platform, if it hadn't been resolved 5 which it was before your posting IBM simply would nots3 have been able to brand say WebSphere as being J2EEt
 compliant.  0 IBM have subsequently signed up to the branding 1 scheme as have the other major middleware vendorso such as BEA etc.  1 It is ironic that in producing this post you havem0 demonstrated that you don't grasp the difference0 between branding (what Sun and IBM were arguing  about) and standardisation.a  . And I did respond to it then pointing out your' comprehension gap (branding/standards).i   Regardse Andrew Harrison  Enterprise IT Architecta   ------------------------------  % Date: Mon, 22 Jan 2001 13:36:29 +0000B  From: steven.reece@quintiles.com$ Subject: Re: Remote boot via DECnet?H Message-ID: <OFB900B0EA.55756277-ON802569DC.004A4655@qedi.quintiles.com>  E It would be interesting to see what kind of configuration the varioustD systems have.  I'm using DECnet-Plus and always seem to get the sameH problems as Bart - DECnet shuts down too early and kills off the sessionK that's shutting the system down.  This is whether I'm running with a DECnetl+ over IPP connection or just on DECnet-Plus.a  I Two ways to get around it.  The first has already been suggested which isi# to use SYSMAN to reboot the system.nE Another way is to connect a DECserver up to the serial console on thenF system and connect to the appropriate port on the DECserver, login andI reboot the system.  This I can recommend if you have to do remote support>I of a system since you can watch the system as it reboots as well as crash : it or bring it down to console level if it goes diodes up.   Steve.   John Santos wrote/quoted:OI >>>I've done this lots of times, it hasn't ever failed that I can recall. C However it is possible that all the DECnet-plus hosts I've rebooted D remotely, I was connected on a DECnet-over-IP connection rather thanC on a raw DECnet connection.  I think that would require both DECnet ? and TCP/IP to still be up when SHUTDOWN.COM actually shuts downn. the system (runs OPCCRASH.EXE?), but it works.    % On Sat, 20 Jan 2001, Bart Zorn wrote:r  ; > It depends on the version of DECnet that you are running.u >aI > DECnet IV: it will probably work, as the RTA session stays up until the J > AS2100 actually goes down to reboot. DECnet-plus, OTOH, stops at an veryB > early stage during shutdown (Way too early, IMHO). You lose your
 connection* > and the shutdown procedure gets aborted. > E > With both versions of DECnet you could use the SYSMAN SHUTDOWN NODEs command,D > with /AUTO. In that way the shutdown procedure does not run in the context ? > of your RTA session and you are not susceptible for prematurea disconnects.<<<a   ------------------------------   Date: 22 Jan 2001 09:16:58 GMT7 From: Thomas.Hahnemann@nospam_s-t.de (Thomas Hahnemann)c$ Subject: Re: samba 2.0.3 : NT client0 Message-ID: <Oozvf8elmJpy-pn2-unkVNndZRj9O@Tom2>  E On Fri, 19 Jan 2001 11:08:32, Thomas.Hahnemann@nospam_s-t.de (Thomas - Hahnemann) wrote:n  ( > Server : DECAlpha VMS 7.1, Samba 2.0.3" > Client : Windows NT patchlevel 4 > 4 > If I try to read a directory with about 9000 files2 > the connection breaks off. It works with smaller/ > directorys. In the logfile appear the lines :k >  > [2001/01/17 17:14:40, 0] r7 > DSA1:[KITS.SAMBA-2_0_3.SOURCE.LIB]UTIL_SOCK.C;6:(411)>2 >   write_data: write failure. Error = broken pipe > [2001/01/17 17:16:52, 0]  7 > DSA1:[KITS.SAMBA-2_0_3.SOURCE.LIB]UTIL_SOCK.C;6:(572) 1 >   Error writing 39 bytes to client. -1. Exiting  >  > Has anybody seen this ?i* > Is there a workaround for that problem ? >  > and  > J > 2001/01/18 09:27:41, 0] DSA1:[KITS.SAMBA-2_0_3.SOURCE.SMBD]UID.C;1:(285)5 >   Warning: You appear to have a trapdoor gid systemG >  > What does it mean ?o >  > Thomas Hahnemann >    Thanks for your replies,  C I've tried to compile and install Samba 2.0.6 but I couldn't get itaD work. The directory's with about 9000 files belongs to a measurementG system. I've never had ab ig problem with this amount of files on VMS, g@ OS/2 and Novell driven filesystems and I can't change to another% directory structure with little work.s  - Well, I will try harder to get 2.0.6 working.j   Thomas Hahnemann   ------------------------------    Date: 22 Jan 2001 09:08:37 -05002 From: malmberg@eisner.decus.org (John E. Malmberg)$ Subject: Re: samba 2.0.3 : NT client+ Message-ID: <8yqn4FCMnjgK@eisner.decus.org>o  ? One thing to do to improve directorly listing time on SAMBA forb; OpenVMS, is to modify the parameter "case sensitive = YES".p  ? (If you have the option set to use case sensitive names that isy8  only available on SAMBA 2.0.3, this may not work right)  : On OpenVMS, the file lookup is always case insensitive, so7 changing this parameter from the default will result int= significantly less code being executed, thus an optimization..    0 In article <Oozvf8elmJpy-pn2-unkVNndZRj9O@Tom2>,9 Thomas.Hahnemann@nospam_s-t.de (Thomas Hahnemann) writes:o >e > Thanks for your replies, >a5 > I've tried to compile and install Samba 2.0.6 but Iu > couldn't get it work.   G A specific error message or problem description could help us help you.   1 It could also help me refine the build procedure.e  > I just noticed that the FRONTPORT link procedure does not make8 sure that the resulting shared image is protected /w:re.  @ > The directory's with about 9000 files belongs to a measurement@ > system. I've never had ab ig problem with this amount of files? > on VMS, OS/2 and Novell driven filesystems and I can't changek2 > to another directory structure with little work.  B The problem has been identified in the UN*X version.  It just does= not affect them as badly.  They need to fix it though if theyn= want to get better benchmarking numbers.  The are supposed to . be improvements in the 2.2.0 release for UNIX.  ? Because of the nature of the code involved, the OpenVMS version A it hit particularly hard.  The work on getting SAMBA 2.0.6 portedn< to OpenVMS and other less UN*Xy platforms helped bring it to the SAMBA teams attention.  / > Well, I will try harder to get 2.0.6 working.   C The SAMBA 2.0.6 for OpenVMS should not require a compilation to get 3 running.  There is a binary kit for both platforms.h  B The installation instructions are different than the 2.0.3 versionA mainly due to the different structure.  Shared images are used to  improve memory usage.a  @ To compile it, requires both the VMS specific source kit and the generic UN*X source kit.  A The instructions for building and linking are in the VMS specific  source kit.l  @ If you do want to compile it yourself, good.  For SAMBA 2.0.6 ifC you disable the SMBD service from starting from your TCPIP program,>@ you can run it interactively in DEBUG.  By using the PCA programA (license available with the OpenVMS hobbyist program) you can gete a profile map.  > The samba_vms(at)samba.org mailing list is also available, and6 can be signed up from a web interface from a mirror of http://www.samba.org  D Running SAMBA in debug mode can be a very useful learning experience in this mixed-vendor world.    -John  wb8tyw@qsl.network Personal Opinion Onlyl   ------------------------------    Date: 22 Jan 2001 16:11:29 +0100* From: eplan@kapsch.net (Peter LANGSTOEGER)$ Subject: Re: samba 2.0.3 : NT client( Message-ID: <3a6c4da1@news.kapsch.co.at>  ` In article <8yqn4FCMnjgK@eisner.decus.org>, malmberg@eisner.decus.org (John E. Malmberg) writes:@ >One thing to do to improve directorly listing time on SAMBA for< >OpenVMS, is to modify the parameter "case sensitive = YES". >.@ >(If you have the option set to use case sensitive names that is9 > only available on SAMBA 2.0.3, this may not work right)i >t; >On OpenVMS, the file lookup is always case insensitive, sod8 >changing this parameter from the default will result in> >significantly less code being executed, thus an optimization.   Are you sure about that ?f  H I changed this parameter with V1.9 and then I had to enter the filenamesC as lowercases on the client side or else they wouldn't be findable.S# I switched then back to original...r   -- a< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888a< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  # Date: Mon, 22 Jan 2001 16:50:34 GMTn From: john_20_28_2000@yahoo.com Q Subject: Script to read directory of all drives, clustered, shared, etc. at once?s) Message-ID: <94hocm$ptl$1@nnrp1.deja.com>o   Is there a DCL script to:c  D Read the directory of all drives, clustered, shared, etc. at once byG just running a command file and maybe saving it to an output?  I wantedt= to be able to use wildcards in the command file with the DIR.e  C I guess you could create a DCL command file that has all your driveeD names and accepts a parameter for DIR from the command line.  But, I= did not know if this was the correct way to proceed.  Thanks.'     Sent via Deja.comw http://www.deja.com/   ------------------------------  # Date: Mon, 22 Jan 2001 17:14:39 GMTi* From: Alan E. Feldman <alan48@my-deja.com>U Subject: Re: Script to read directory of all drives, clustered, shared, etc. at once? ) Message-ID: <94hppl$r6l$1@nnrp1.deja.com>   ) In article <94hocm$ptl$1@nnrp1.deja.com>, "   john_20_28_2000@yahoo.com wrote: > Is there a DCL script to:i >oF > Read the directory of all drives, clustered, shared, etc. at once byB > just running a command file and maybe saving it to an output?  I wanted? > to be able to use wildcards in the command file with the DIR.e >nE > I guess you could create a DCL command file that has all your driveeF > names and accepts a parameter for DIR from the command line.  But, I? > did not know if this was the correct way to proceed.  Thanks.n  	 Check outs   $ HELP LEXICALS F$DEVICE  ( afeldman@gfigroup.ButItSaidItPrinted.com   --F NOTE: If you wish to e-mail me, please do NOT use the deja address. ItD is not a valid address. Instead, use the address below, removing the long wrong part first. Thanks.   Disclaimer: JMHO Alan E. Feldman  &-)( afeldman@gfigroup.ButItSaidItPrinted.com     Sent via Deja.comy http://www.deja.com/   ------------------------------  % Date: Mon, 22 Jan 2001 09:12:50 +0100o7 From: "Walter A. Ambrosch" <Walter.Ambrosch@adicom.com>n( Subject: Re: TCPIP$BIND: dynamic updates( Message-ID: <980151370.418611@ns.alb.de>  ? Peter LANGSTOEGER <eplan@kapsch.net> schrieb in im Newsbeitrag:s 3a684882@news.kapsch.co.at...f? > In article <979899887.965762@ns.alb.de>, "Walter A. Ambrosch"s$ <Walter.Ambrosch@adicom.com> writes:G > >Thanks a lot. I added "allow-update { 172.26/16; };" to the relevant  zones,L > >and bingo: I got my first updates. Now I'm still having a problem, but of adJ > >different kind: the updates for the reverse zone are ok, but the server hast > H > I have problems with the reverse zone. W2K clients do too often updateK > their "IP address to name" info. That means they register eg. "a.b.c.d isaK > host.domain.name" without checking that the registration is already done,iJ > done umpteen times, and is still there. The negative side effect of thisH > is, that the automatically increased zone serial# (in SOA RR) gets too big. > ; > We had over 100 updates per day for only 3 W2K clients !!iI > Imagine that with 1500 W2K clients and with a serial# where the date issK > also in there for manually edited static entries. You end up with numberstJ > with at least 11 digits or you really have to use *_MERGE_* (which would0 > OTOH be ok, if the comments won't get screwed) >h8 > For now we turned off the DDNS for the Reverse Zone...  H Maybe I'll have to do that, too. But for the moment this doesn't hurt meI much, because this is the first W2K machine I have installed this way, son* this is more an educational issue with me.   >rJ > Our NT people were of course not interested in how to fix this (decreaseJ > the update rate or 'update only if changed' or ...) because M$ told themH > to use W2K DNS (with ADS integration enabled) in every case and, guessK > what, we will really switch from BIND 8/9 'standard' to M$ DNS crap. Sighu >iL > >a problem with the updates for the forward zone. Do you (or anybody else)J > >know what that W2K Server box is trying to tell my BIND server? I don't seeo0 > >anything except the error message in the log. >d+ > What error messages ? The following one ?o >tI > Wed 17 21:18:06 ERROR: error processing update packet id 10006 from ...a  L Yes, that's exactly the one. Additionally, I'm getting "ERROR: zone dump forL '26.172.IN-ADDR.ARPA' failed, rescheduling" since I enabled dynamic updates,' but I don' know if this is a W2K issue.a   >pK > This one - I heard - is from the fact, that Win2000 is not fully RFC DDNS8L > compatible and that you need a proprietary Win2000 DNS server (with ActiveJ > Directory Integration) to make a Win2000 client really happy. M$ screwed it.n > J > Q TCPIP engineering is investigating how to blame-M$/workaround-in-TCPIP >  > --> > Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651= > Network and OpenVMS system manager  Fax.    +43 1 81111-888i> > <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netJ > A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"  L Yes, it is not fully compatible. I found that out when I had to manually addK the netlogon.dns entries for both our DCs into the BIND db files of my BIND J server (I have no control over them, they use MS DNS integrated with ADS).H The entries for the 2nd DC are ok, but there is an entry in the 1st DC'sG netlogon.dns: "gc._msdcs.ADICOM.COM. 600 IN A 172.25.1.1" which clearly L isn't. Maybe it's something like that, or maybe the BIND server doesn't likeL dynamic updates for SRV entries. I haven't found any netlogon.dns on my box,K but perhaps I have to disable dynamic updates completely to provoke it into H producing one. Anyway, I'll let you know if I find out anything further.   Walter A. Ambrosch ADICOM Informatik GmbH   ------------------------------    Date: 22 Jan 2001 12:44:26 +0100* From: eplan@kapsch.net (Peter LANGSTOEGER)( Subject: Re: TCPIP$BIND: dynamic updates( Message-ID: <3a6c1d1a@news.kapsch.co.at>  b In article <980151370.418611@ns.alb.de>, "Walter A. Ambrosch" <Walter.Ambrosch@adicom.com> writes:^ >Peter LANGSTOEGER <eplan@kapsch.net> schrieb in im Newsbeitrag: 3a684882@news.kapsch.co.at..., >> What error messages ? The following one ? >>J >> Wed 17 21:18:06 ERROR: error processing update packet id 10006 from ... >uM >Yes, that's exactly the one. Additionally, I'm getting "ERROR: zone dump for M >'26.172.IN-ADDR.ARPA' failed, rescheduling" since I enabled dynamic updates, ( >but I don' know if this is a W2K issue.  I No, the additional messages is - as was already discussed here - from thes' fact that you didn't define the logical   ( 	TCPIP$BIND_SERVER_MERGE_DYNAMIC_UPDATES  I Do it, and the zone dump errors will go away, but the zone file will thenoH be automatically and regularly written and thus destroying the order andH also comment records. If you rely on these, you will want to keep livingF with the zone dump errors (and so far no problems seen caused by this)F and you also will want to define an opposite '*DONT_MERGE*' locical in= TCPIP V5.1 because the merge default state changes with V5.1.i   -- P< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888t< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Tue, 23 Jan 2001 02:35:10 +1000t4 From: "Matt Muggeridge" <Matt.Muggeridge@compaq.com>( Subject: Re: TCPIP$BIND: dynamic updates5 Message-ID: <c4%a6.19$cu.129@gazette.loc1.tandem.com>t  ? >I know there is currently no BIND 9 on VMS (said to be in 5.1)b  K To avoid you looking too hard, this will not appear in V5.1.  It is planneda for a later release.   Matt.    ------------------------------  + Date: Mon, 22 Jan 2001 07:04:01 +0000 (UTC)e From: abc@21cn.com(ccc)l
 Subject: testa* Message-ID: <94gm11$4l7$550@mail.cn99.com>  # <html><head><title>ewebform</title>hD <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head><body><p> Hi,<br><br>You have to check out DatingClub.com!<br><br>It's an incredible dating site with 1,700,000 members from all over the world. You can meet your ideal mate by searching through the database, matching profiles, checking out photos, sending anonymous emails, chatting, and sending messages.<br><br>There are also many other features that make online dating fun, and DatingClub.com Membership worthwhile. For instance, they have community pages with great links and interactive features. There are forums an <br><br><iframe src="http://www.ewebform.com/webinfo/showme.htm" width=60 height=15 frameborder=0 scrolling=no></iframe></body></html>   ------------------------------  + Date: Mon, 22 Jan 2001 14:33:41 +0100 (CET)n: From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>$ Subject: Re: the value of "/" in FTPJ Message-ID: <Pine.LNX.4.21.0101221423200.22576-100000@irys.stanpol.com.pl>  - On Thu, 18 Jan 2001 Bru@stanpol.com.pl wrote:w   +hello,  +tH +I want some ftp user to see only their data, not login.com and ucx*.log + > +in order to do that, I have the folowing directory structure: +w +disk:[dir]u +disk:[dir.home] +hH +with the first as login directory (ucx*.log and login.com go there) andG +the second for the data. in the login.com, I have a "$set def [.home]"g  ?  As Bob say - may be best set the login directory in [dir.home]r2 and the login procedure name as b.ex. [-]LOGIN -:)  Ragardless the previous point:r  G +all works well exept if the user enter "cd /" as an ftp command. after F +"cd /", the default directory becomes disk:[dir] *even* if I redefine +sys$login.t  &  *How* you define the SYS$LOGIN name ?%  Be aware, that "original" SYS$LOGIN:b. 1. is defined before the LOGIN.COM is executed( 2. is defined in /JOB table, not process  3. is defined in EXECUTIVE mode.  8  Althought some utilities can be aware of 1. and 3. have3 this moment check ("FTP Server (Version 5.0)") thatS7 what you asks depends only from /JOB requirement (2.) !n   $ DEFINE/JOB SYS$LOGIN anythings    works for me.  ; +is there any workaroud ? is there a way to define the hometE +directory (I mean "/") for an ftp user elsewhere than in the OpenVMSo +default dir ?  <  Be aware, that the "login directory" (means: seen after FTP? login) and "/ directory" (after CD /) doesn't must be the same:u9 you *can* in LOGIN check FTP session, do SET DEF [onedir]u$ and DEFINE/JOG SYS$LOGIN [otherdir].  -:)   +I'm using UCX V4.2 ECO2  1  Hm... Checked under V5.0A, can't check in older.    +Pierre.    Regards - Gotfryd   -- pE =====================================================================-F $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEj. $!                        GS@stanpol.zabrze.plE =====================================================================m   ------------------------------    Date: 22 Jan 2001 11:37:43 +0100* From: eplan@kapsch.net (Peter LANGSTOEGER)B Subject: Re: To Hoff Hoffman: Any news about the VMS DHCP client ?* Message-ID: <3a6c0d77$1@news.kapsch.co.at>  ^ In article <3a6b5ede@newsfeed.vitts.com>, "John Gemignani, Jr." <john@ossc.DELETE.net> writes:; >TCP/IP Services for OpenVMS V5.1 submitted this past week.1% >It includes support for DHCP client.r  ) May I ask someone for a copy of the kit ?    -- [< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888n< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Mon, 22 Jan 2001 07:02:39 -0500t2 From: norm lastovica <norman.lastovica@oracle.com>B Subject: Re: To Hoff Hoffman: Any news about the VMS DHCP client ?* Message-ID: <3A6C215F.2E62320E@oracle.com>   Peter LANGSTOEGER wrote: > ` > In article <3a6b5ede@newsfeed.vitts.com>, "John Gemignani, Jr." <john@ossc.DELETE.net> writes:= > >TCP/IP Services for OpenVMS V5.1 submitted this past week.i' > >It includes support for DHCP client.e > + > May I ask someone for a copy of the kit ?h  0 	I believe that when you sign up for the vms 7.35 field test, you get a copy of the tcp/ip services 5.1.4 field test software as well.  otherwise, you'll need to contact compaq directly.q   >  > --> > Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651= > Network and OpenVMS system manager  Fax.    +43 1 81111-888 > > <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netJ > A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   --  > norman lastovica / oracle rdb engineering / usa / 610.696.4685   ------------------------------  # Date: Mon, 22 Jan 2001 16:53:23 GMTc2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)B Subject: Re: To Hoff Hoffman: Any news about the VMS DHCP client ?5 Message-ID: <7AZa6.15$cu.152@gazette.loc1.tandem.com>y  H In article <3A69B881.7CFFBA8E@home.nl>, Dirk Munk <munk@home.nl> writes: :The subject says it all :-)  D   QA-MT3AD-H8 (V7.3 EFT2/SDK2) includes the kit for TCP/IP Services >   V5.1, and V5.1 includes the DHCP client support for OpenVMS.  A   Cost: US$40 for the QA-MT3AD-H8 Software Developer's Kit (SDK).e  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  + Date: Mon, 22 Jan 2001 16:26:26 +0100 (CET) : From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl> Subject: Re: Variables in DCLeJ Message-ID: <Pine.LNX.4.21.0101221618360.22576-100000@irys.stanpol.com.pl>  # On Sun, 14 Jan 2001, Tom Gee wrote:n  I +Got a bit tricky problem with DCL, can't find out how to solve it... I'meA +trying to write a DCL command procedure where another DCL COM isM3 +written, and this COM finally creates a third one.t  D  Regardless of the discussion here: IHO - regards to DCL limitation,A including the "255 characters PIPE bug" -;> still may be requiredr a "COM generated in COM". D  But IMHO two-level DCL may/must be enought to resolve all problems;< yes, I can imagine that you find a example when three-levels *looks* simple. But...B  Can you - even for curiousity - explain the reason to three-level "COM in COM" ?@  (And yes - have read the other messages and will agree with the1 techniques like "placeholder" filled in-run-time)e   [...]X    Regards - Gotfryd   -- oE =====================================================================fF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================e   ------------------------------  % Date: Mon, 22 Jan 2001 09:26:16 -0500b4 From: "Bochnik, William J" <BochnikWJ@bernstein.com> Subject: RE: vms not an option?eJ Message-ID: <2B37459189B0D211BE710000F8EF9D8508908B69@nts0147.beehive.com>  J This message is in MIME format. Since your mail reader does not understand< this format, some or all of this message may not be legible.  ' ------_=_NextPart_001_01C0847F.42F61D341 Content-Type: text/plain;s 	charset="iso-8859-1"E  K And "newbies" have a tendancy to look directly into them, and get "burned".a   (Sorry, couldnt resist)j   -----Original Message-----0 From: Main, Kerry [mailto:Kerry.Main@compaq.com] Sent: January 21, 2001 11:18 AMy To: Info-VAX@mvb.saic.com  Subject: RE: vms not an option?t      B >>> 	Take heart, Fabio. An eclipse is only a temporary event...<<<  K Yep, first everyone goes into the dark and then they start to see the lightt again ..   :-)M   Regards,  
 Kerry Main Senior Consultant, Compaq Canada Inc. Professional Servicesa Voice: 613-592-4660s Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com      ' ------_=_NextPart_001_01C0847F.42F61D34n Content-Type: text/html; 	charset="iso-8859-1"t  1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">  <HTML> <HEAD>H <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">H <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">% <TITLE>RE: vms not an option?</TITLE>  </HEAD>H <BODY>   <P><FONT SIZE=2 FACE="Arial">And &quot;newbies&quot; have a tendancy to look directly into them, and get &quot;burned&quot;.</FONT>- </P>  ; <P><FONT SIZE=2 FACE="Arial">(Sorry, couldnt resist)</FONT>_ </P>  > <P><FONT SIZE=2 FACE="Arial">-----Original Message-----</FONT> <BR><FONT SIZE=2 FACE="Arial">From: Main, Kerry [<A HREF="mailto:Kerry.Main@compaq.com">mailto:Kerry.Main@compaq.com</A>]</FONT>D <BR><FONT SIZE=2 FACE="Arial">Sent: January 21, 2001 11:18 AM</FONT>> <BR><FONT SIZE=2 FACE="Arial">To: Info-VAX@mvb.saic.com</FONT>D <BR><FONT SIZE=2 FACE="Arial">Subject: RE: vms not an option?</FONT> </P> <BR> <BR>   <P><FONT SIZE=2 FACE="Arial">&gt;&gt;&gt; &nbsp;&nbsp;&nbsp; Take heart, Fabio. An eclipse is only a temporary event...&lt;&lt;&lt;</FONT> </P>  o <P><FONT SIZE=2 FACE="Arial">Yep, first everyone goes into the dark and then they start to see the light</FONT>2- <BR><FONT SIZE=2 FACE="Arial">again ..</FONT>  </P>  ' <P><FONT SIZE=2 FACE="Arial">:-)</FONT>  </P>  , <P><FONT SIZE=2 FACE="Arial">Regards,</FONT> </P>  . <P><FONT SIZE=2 FACE="Arial">Kerry Main</FONT>6 <BR><FONT SIZE=2 FACE="Arial">Senior Consultant</FONT>7 <BR><FONT SIZE=2 FACE="Arial">Compaq Canada Inc.</FONT>e: <BR><FONT SIZE=2 FACE="Arial">Professional Services</FONT>8 <BR><FONT SIZE=2 FACE="Arial">Voice: 613-592-4660</FONT>C <BR><FONT SIZE=2 FACE="Arial">Fax&nbsp; :&nbsp; 819-772-7036</FONT>dA <BR><FONT SIZE=2 FACE="Arial">Email: Kerry.Main@Compaq.com</FONT>f </P> <BR>   </BODY>r </HTML>a) ------_=_NextPart_001_01C0847F.42F61D34--e   ------------------------------   End of INFO-VAX 2001.044 ************************