1 INFO-VAX	Tue, 04 Dec 2001	Volume 2001 : Issue 674       Contents:> 872           Your Vacation Winning !                  3810953$ Re: Alpha vs. Itanic:  facts vs. FUD$ Re: Alpha vs. Itanic:  facts vs. FUD Another DSSI cluster question." Re: Another DSSI cluster question.! Carly's HP shows its true colours % Re: Carly's HP shows its true colours  DCPS problem Urgent  Re: DCPS problem Urgent  Re: DCPS problem Urgent  Re: DEC is DEAD  Re: DEC is DEAD  Re: DEC is DEAD  Re: DEC is DEAD  Re: DEC is DEAD  Re: DEC is DEAD  DECdocument <FIGURE_FILE>  Re: DECdocument <FIGURE_FILE>  Re: DECdocument <FIGURE_FILE>  DTGreet and DTLogin 2 Enabling the SWCC Command console LUN on an RA30006 Re: Enabling the SWCC Command console LUN on an RA3000# Example of server code using thread ' Re: Example of server code using thread " File cache performance for dummies& Re: File cache performance for dummiesC Free certification on Alpha, Tru64, and VMS at ITUG/DECUS in Europe  Re: Future of VMS ?  Re: Future of VMS ?  Re: Future of VMS ? # FWIW - Capellas at Oracle OpenWorld ' Re: FWIW - Capellas at Oracle OpenWorld ' Re: FWIW - Capellas at Oracle OpenWorld ' Re: FWIW - Capellas at Oracle OpenWorld ' Re: FWIW - Capellas at Oracle OpenWorld ' Re: FWIW - Capellas at Oracle OpenWorld  Help with Shadowing Parameter < Re: Hidden accounting: was Re: No surprise about Tru64 death< Re: Hidden accounting: was Re: No surprise about Tru64 death HP OpenView and OpenVMS $ Inquirer article on Compaq and Alpha( Re: Inquirer article on Compaq and Alpha( Re: Inquirer article on Compaq and Alpha, Re: Installing Icon permanently to CDE menu?, Re: Installing Icon permanently to CDE menu?, Re: Installing Icon permanently to CDE menu?, Re: Installing Icon permanently to CDE menu?# Jumpers for rz29-labelled barracuda ' Re: Jumpers for rz29-labelled barracuda ' Re: Jumpers for rz29-labelled barracuda ' Re: Jumpers for rz29-labelled barracuda  Linus' view on VMS RE: Linus' view on VMS Re: Linus' view on VMS RE: Linus' view on VMS RE: Linus' view on VMS RE: Linus' view on VMS RE: Linus' view on VMS Re: Linus' view on VMS Re: Linus' view on VMS Re: Linus' view on VMS9 Re: Microsoft Pyramid Collapses Enron and Hewlett Packard P Openvms support for another 25 years! Does anyone know what this pact is called?P Re: Openvms support for another 25 years! Does anyone know what this pact is calP Re: Openvms support for another 25 years! Does anyone know what this pact is cal Re: Oracle problems. Re: Oracle problems.K Re: Q: Tool or script to remove nonprinting characters from a SET HOST log? K Re: Q: Tool or script to remove nonprinting characters from a SET HOST log? K Re: Q: Tool or script to remove nonprinting characters from a SET HOST log?  RDB course offering for January  Re: RECALL does not work Re: RL02 disk drive  Send() Error Buffer Problem  Re: Send() Error Buffer Problem J Re: Shared PIRQ error on PCI multifunction card; how to assign interrupt ?J Re: Shared PIRQ error on PCI multifunction card; how to assign interrupt ? tcpip config Re: tcpip config. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues- Re: The Real Story About HP's Announcement... E Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))   Re: tubes (was: RE: DEC is DEAD)0 Was the Alpha to Intel agreement ever approved ?  F ----------------------------------------------------------------------   Date: Tue, 4 Dec 2001 18:53:38% From: 5338109travelincentives@aol.com G Subject: 872           Your Vacation Winning !                  3810953 . Message-ID: <200112041059.CAA19942@d3tech.com>  > You have been specially selected to qualify for the following:  0 Premium Vacation Package and Pentium PC Giveaway6 To review the details of the please click on the link # with the confirmation number below:    http://vacation.81832.com    Confirmation Number#Lh340 J Please confirm your entry within 24 hours of receipt of this confirmation.  " Wishing you a fun filled vacation!J If you should have any additional questions or cann't connect to the site % do not hesitate to contact me direct: , mailto:vacation@btamail.net.cn?subject=Help!   ------------------------------   Date: 4 Dec 2001 14:10:16 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) - Subject: Re: Alpha vs. Itanic:  facts vs. FUD , Message-ID: <9uilg8$1mj5$1@info.cs.uofs.edu>  + In article <9uignn$t6p$1@news.netpower.no>, >  "David Brown" <dav-nospam-id@westco-nospam-ntrol.com> writes: |>  6 |> Then why did they buy the Alpha in the first place? |>    G They didn't "buy Alpha".  They wanted the services businees of Digital, F but Alpha was a mandatory part of the deal.  Kind of like the place inF Holland that was giving away the Cray, but you had to take everything,9 including the computer room air conditioning system!! :-)    bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  ! Date: Tue, 04 Dec 01 13:03:32 GMT  From: jmfbahciv@aol.com - Subject: Re: Alpha vs. Itanic:  facts vs. FUD + Message-ID: <9uiood$c1n$4@bob.news.rcn.net>   , In article <9uilg8$1mj5$1@info.cs.uofs.edu>,5    bill@triangle.cs.uofs.edu (Bill Gunshannon) wrote: , >In article <9uignn$t6p$1@news.netpower.no>,? > "David Brown" <dav-nospam-id@westco-nospam-ntrol.com> writes:  >|> 7 >|> Then why did they buy the Alpha in the first place?  >|>  > H >They didn't "buy Alpha".  They wanted the services businees of Digital,- >but Alpha was a mandatory part of the deal.    @ Do you know why it was mandatory?  I never understood that part.   > .. Kind of like the place inG >Holland that was giving away the Cray, but you had to take everything, : >including the computer room air conditioning system!! :-)   :-)  /BAH  ' Subtract a hundred and four for e-mail.    ------------------------------  % Date: Tue, 04 Dec 2001 09:57:03 +0000 1 From: Robert DiRosario <rdirosario@starpower.net> ' Subject: Another DSSI cluster question. - Message-ID: <3C0C9DEE.A1767B88@starpower.net>   @ I'm back to working on my hobbyist cluster and have another DSSI	 question.   H Does VMS care how I assign the DSSI address?  For example, should I giveC the four VAX's low DSSI address (0,1,2,3) and the two disks and two H HDS10's the high address (4,5,6,7)?  Does the DSSI address determine any type of priority on the bus?   Thanks Robert   ------------------------------  % Date: Tue, 04 Dec 2001 18:02:02 +0100 2 From: "Thomas H. Pauli" <thomaspauli@arcormail.de>+ Subject: Re: Another DSSI cluster question. + Message-ID: <3C0D018A.5000904@arcormail.de>   
 Hi Robert,= I'm not too sure, but I seem to remember, that the higher the < DSSI address the more priority it gets. This is why the host( adapters always should be given 7 and 6.   Thomas   Robert DiRosario wrote:   B > I'm back to working on my hobbyist cluster and have another DSSI > question.  > J > Does VMS care how I assign the DSSI address?  For example, should I giveE > the four VAX's low DSSI address (0,1,2,3) and the two disks and two J > HDS10's the high address (4,5,6,7)?  Does the DSSI address determine any > type of priority on the bus? >  > Thanks > Robert >  >  >      --  9 Thomas H. Pauli, Hammersteinstr.19, 14199 Berlin, Germany    ------------------------------  % Date: Tue, 04 Dec 2001 10:51:04 +0000 % From: Alan Greig <a.greig@virgin.net> * Subject: Carly's HP shows its true colours8 Message-ID: <ucap0ug7tglkf34k1a76uuvogtoubgo0jt@4ax.com>  7 http://www.interex.org/hpworldnews/hpw111/01letter.html   E Home > Publications > HP World > Letters to the Editor Volume 4 Issue  11    HP NOT Walking the Walk    C  My company, Security Applications, Inc., is both a customer for HP B products and an HP vendor for electronic security systems. We haveF supplied the computer software running HP's card access control system5 in Roseville, Calif. This software is based on HP-UX.   B HP has informed us that the company will not consider any internal= solution based on any platform other than Windows NT/2000 for D worldwide deployment. HP also said it will not consider UNIX for any> internal applications including, but not limited to, security, purchasing, or mail servers.  E I have sent messages to HP CEO, Chairman, and President Carly Fiorina ? and many other HP executives to make them aware of my company's D problems. Each of them promised to look into the matter and call me,F but so far no one has. We have invested heavily in making our softwareB products available on HP's premier platform, the HP 9000 family ofF servers and workstations, so that we could become a worldwide supplierD for HP. But HP is now refusing to even consider our products becauseA our software is based on UNIX or Linux and not Microsoft Windows.   @ HP's position has now raised doubts in the marketplace about theE viability of HP's UNIX or Linux products. If Fiorina is wondering why E HP is losing business, this is one of the reasons--it has essentially D limited itself to the Windows PC market. HP will soon be in the sameF position as Compaq and wondering why it can't make any money. HP-UX isF probably doomed, and forget about MPE. I guess the HP community is not concerned about its future.   @ By the way, IBM has a different attitude on this subject, so our? company has decided to go there for Linux platforms to move our  business into the future.    Dave Swartz, vice-president  Security Applications, Inc.  Fishkill, New York.       P --------------------------------------------------------------------------------     This is no 'HP Way' F I applaud the open reporting and acknowledgment about the press and HPA CEO, Chairman and President Carly Fiorina (see "There's Something D About Carly," October 2001 HP World, page 1). I do disagree with theE statement that the majority of news is positive; that was true early, C but not recently. Perhaps this was a tempering of the article so as ) not to stir the emotional pots within HP?   C The real reason I am writing is about a comment near the end of the ? article. It said that the "Carly's Way" article was an apparent D reference to the movie "Carlito's Way." I feel that the more obviousF reference was that Carly is drastically changing the "HP Way" into theF "Carly Way." If the author was not familiar with that extremely commonD term (the HP Way), there is a book about it that might be dropped on? their desk. That book should now be subtitled "The way it was."    Fred Mallett Laguna Vista, Texas       P --------------------------------------------------------------------------------    C HP World welcomes its readers' opinions. Letters to the Editor must D include name, address and daytime telephone number. Readers can mail@ their letters to HP World at 1192 Borregas Avenue, Sunnyvale, CAE 94089, or can send them by e-mail to editor@interex.org. HP World may ( edit the letters for clarity and space.            -- Alan   ------------------------------   Date: 4 Dec 2001 12:26:57 GMT ) From: leslie@clio.rice.edu (Jerry Leslie) . Subject: Re: Carly's HP shows its true colours' Message-ID: <9uifeh$dub$3@joe.rice.edu>   & Alan Greig (a.greig@virgin.net) wrote:9 : http://www.interex.org/hpworldnews/hpw111/01letter.html   G : Home > Publications > HP World > Letters to the Editor Volume 4 Issue  : 11 :    : HP NOT Walking the Walk  :   ' Check out the Leakware (tm) HP slide at   )   http://www.theinquirer.net/04120107.htm    HP loves linux for Itanium   No mention of NSK or VMS.   4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  % Date: Tue, 04 Dec 2001 16:04:07 +0100 7 From: Alain Chappuis <alain.chappuis@medecine.unige.ch>  Subject: DCPS problem Urgent1 Message-ID: <3C0CE5E7.C71FFC44@medecine.unige.ch>    Hello 5 For 2 days my DecLaser 2250 has not printed any more.  She is supported by DCPS.    Problem:= With each documents sent to the printer, he is written on the A banner the message: %DCPS-E-FLUSHING, Rest of job will be ignored  and nothing more...writed!  0 Could somebody it say to me what it does not go?   Thank you in advance.    Alain. --  D  +----------------------+------------------------------------------+D  | Alain Chappuis       | Responsable: E-mail; cmu.unige.ch        |D  | Analyste             | WEB    : www.medecine, ebn, jid, Sifm    |D  | Universite de Geneve | E-mail : Alain.Chappuis@unige.ch         |D  | Centre Medical Univ. | Phone  : +41 (22) [70]25.073             |D  | 1, Rue Michel-Servet | FAX    : +41 (22) 347.33.34 ou 702.58.58 |K  | CH-1211 Geneve 4     | http://ebn.unige.ch/www/alain.html       |        D  +----------------------+------------------------------------------+   ------------------------------  % Date: Tue, 04 Dec 2001 10:50:28 -0500 0 From: Paul Anderson <paul.r.anderson@compaq.com>  Subject: Re: DCPS problem Urgent; Message-ID: <041220011050286840%paul.r.anderson@compaq.com>   @ In article <3C0CE5E7.C71FFC44@medecine.unige.ch>, Alain Chappuis) <alain.chappuis@medecine.unige.ch> wrote:   7 > For 2 days my DecLaser 2250 has not printed any more.  > She is supported by DCPS.  > 
 > Problem:? > With each documents sent to the printer, he is written on the C > banner the message: %DCPS-E-FLUSHING, Rest of job will be ignored  > and nothing more...writed!  F If your problem really is urgent, you should call your Compaq customer support center.   D The FLUSHING message usually indicates a PostScript error.  AssumingD you are not trying to print the same file over and over, power-cycle@ the printer.  This may clear up some PostScript confusion in theE printer.  I know this sounds like the Bill Gates way of doing things, > but you could try stopping and restarting the DCPS queue also.   Paul   --    Paul Anderson   OpenVMS Engineering    Compaq Computer Corporation    ------------------------------  % Date: Tue, 04 Dec 2001 17:49:59 +0100 7 From: Alain Chappuis <alain.chappuis@medecine.unige.ch>   Subject: Re: DCPS problem Urgent1 Message-ID: <3C0CFEB7.DBCDF6E1@medecine.unige.ch>    Paul Anderson a crit :  > B > In article <3C0CE5E7.C71FFC44@medecine.unige.ch>, Alain Chappuis+ > <alain.chappuis@medecine.unige.ch> wrote:  > 9 > > For 2 days my DecLaser 2250 has not printed any more.  > > She is supported by DCPS.  > >  > > Problem:A > > With each documents sent to the printer, he is written on the E > > banner the message: %DCPS-E-FLUSHING, Rest of job will be ignored  > > and nothing more...writed! > H > If your problem really is urgent, you should call your Compaq customer > support center.    Maybe   F > The FLUSHING message usually indicates a PostScript error.  AssumingF > you are not trying to print the same file over and over, power-cycleB > the printer.  This may clear up some PostScript confusion in theG > printer.  I know this sounds like the Bill Gates way of doing things,   K I do not see what Bill comes to do here?...if is only to give us viruses...   @ > but you could try stopping and restarting the DCPS queue also.   Yes twice already    I used:    stop/queue/next printer  delete/queue printer @sys$startup:dcps$startup.com    after them the queue is ready   / but nothing to do and allways the same message!      >  Paul Anderson >   OpenVMS Engineering  >   Compaq Computer Corporation    Thank again. Alain. --  D  +----------------------+------------------------------------------+D  | Alain Chappuis       | Responsable: E-mail; cmu.unige.ch        |D  | Analyste             | WEB    : www.medecine, ebn, jid, Sifm    |D  | Universite de Geneve | E-mail : Alain.Chappuis@unige.ch         |D  | Centre Medical Univ. | Phone  : +41 (22) [70]25.073             |D  | 1, Rue Michel-Servet | FAX    : +41 (22) 347.33.34 ou 702.58.58 |K  | CH-1211 Geneve 4     | http://ebn.unige.ch/www/alain.html       |        D  +----------------------+------------------------------------------+   ------------------------------   Date: 4 Dec 2001 13:26:42 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)i Subject: Re: DEC is DEAD, Message-ID: <9uiiui$1kne$1@info.cs.uofs.edu>  9 In article <WAYO7.1133$kT5.230506@dfiatx1-snr1.gtei.net>,e%  Art Rice <arice@myhouse.org> writes:o |> Bill Gunshannon wrote:u |> oJ |> > Most (probably more than 99%) of televisions still have at least one.M |> > As do a very high percentage of computers for the very same reason.  :-)  |> >  N |> Oh, as in CRT?  He he :>)   I was also thinking about other applications.  N |> Just ask any guitarist about the warmth (no pun intended) of a tube driven B |> amp.  And, the natural distortion is also difficult to imitate. |>  G Well, I knew of more as well, but I just picked something everyone hereeF was likely to be familiar with.  My best shortwave radio is still tubeH based (R-390) and I ma trying to fond parts now to rebuild a Fisher tubeI amplifier for my home stereo.  I had a modern all solid-state one by Sony P but my daughter confiscated that.  And it sure isn't worth fighting her for. :-)  E Tubes are rare, but like Alphas, which are going to become rare, (or lD VAXen and PDP's for that matter) they have some definite advantages.  . But then, what do I know, I'm just a dinosaur.   bill   -- lJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   c   ------------------------------   Date: 4 Dec 2001 07:47:36 -0600 - From: koehler@encompasserve.org (Bob Koehler)n Subject: Re: DEC is DEAD3 Message-ID: <RQP1tVZViIop@eisner.encompasserve.org>m  [ In article <BlMO7.27$y4.15015@paloalto-snr1.gtei.net>, Art Rice <arice@myhouse.org> writes:u > Antonio wrote:K >> I remember the days when transistors started to replace the vacuum tube,zH >> and you guessed it, there were people that beleived it was all things! >> evil. How time repeats itself.n > D > And there are still ligimate uses for vacuum tubes (valves) today. >   E    Just try to get out a TV signal over more than a mile without one.e   ------------------------------   Date: 4 Dec 2001 07:48:44 -0600p- From: koehler@encompasserve.org (Bob Koehler)  Subject: Re: DEC is DEAD3 Message-ID: <L2zUU1w+CP9B@eisner.encompasserve.org>w  _ In article <9uga5h$i27$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:s > G > Most (probably more than 99%) of televisions still have at least one.mJ > As do a very high percentage of computers for the very same reason.  :-)  E    I don't want to sound like I'm supporting Antonio, but I do really &    like the flat screen on my new Mac.   ------------------------------   Date: 4 Dec 2001 08:05:05 -0600 - From: koehler@encompasserve.org (Bob Koehler)  Subject: Re: DEC is DEAD3 Message-ID: <cmlsavNPoqYt@eisner.encompasserve.org>u  ` In article <9uiiui$1kne$1@info.cs.uofs.edu>, bill@triangle.cs.uofs.edu (Bill Gunshannon) writes: > I > Well, I knew of more as well, but I just picked something everyone here H > was likely to be familiar with.  My best shortwave radio is still tubeJ > based (R-390) and I ma trying to fond parts now to rebuild a Fisher tubeK > amplifier for my home stereo.  I had a modern all solid-state one by SonydR > but my daughter confiscated that.  And it sure isn't worth fighting her for. :-) > G > Tubes are rare, but like Alphas, which are going to become rare, (or sF > VAXen and PDP's for that matter) they have some definite advantages.  F    My 1968 Piper Cherokee still has it's tube based ADF.  Unlike laterG    non-tube based radios, it actually can find and point to stations onuF    a reliable basis.  Other pilots have told me that if we ever decide9    to let it go they would be glad to give it a new home.b  B    Too bad the FAA won't let us transmit on our tube based Nav/Com0    any more.  Those coffee grinders worked good.  I    OBTW, my Pro-350 is healthy now, too. Even if it is just an F-11 chip      set and maxed out at 128KB.   ------------------------------  # Date: Tue, 04 Dec 2001 16:49:18 GMTf* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: DEC is DEADB Message-ID: <i87P7.127266$uB.17459911@bin3.nnrp.aus1.giganews.com>  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:cmlsavNPoqYt@eisner.encompasserve.org...-J >    OBTW, my Pro-350 is healthy now, too. Even if it is just an F-11 chip  >    set and maxed out at 128KB.  J I would have sworn that an F-11 (and a Pro-350) maxed out at 256 KB (well,L 248 KB plus I/O space).  But my memory isn't what it used to be (or at least1 I think I remember that it used to be better...).>   - bill   ------------------------------  % Date: Tue, 04 Dec 2001 13:11:43 -0500.* From: Chuck Chopp <ChuckChopp@rtfmcsi.com> Subject: Re: DEC is DEAD+ Message-ID: <3C0D11DF.7C89DCFD@rtfmcsi.com>c   Art Rice wrote:w   > Antonio wrote: >, > >yL > > I remember the days when transistors started to replace the vacuum tube,I > > and you guessed it, there were people that beleived it was all things " > > evil. How time repeats itself. >tD > And there are still ligimate uses for vacuum tubes (valves) today. >a  P And anybody who's in the business of manufacturing high-end audio amplifiers forO musical performers knows that vacuum tubes are "da bomb".  Transistors clip the@G waveforms in high-power audio amplifiers, while vacuum tubes produce aniK amplified waveform with far less distortion when the output signal is being  amplified by a large amount.     -- Chuck Choppe  8 ChuckChopp@rtfmcsi.com            http://www.rtfmcsi.com0                                   ICQ # 22321532@ RTFM Consulting Services Inc.     864 801 2795 voice & voicemail2 103 Autumn Hill Road              864 801 2774 fax4 Greer, SC  29651                  800 774 0718 pager7                                   8007740718@skytel.comn   ------------------------------  $ Date: Tue, 4 Dec 2001 13:32:28 -0000, From: "Bob Knowles" <bob.knowles@compaq.com>" Subject: DECdocument <FIGURE_FILE>1 Message-ID: <Nf4P7.104$BK1.2769@news.cpqcorp.net>   H A build with DECdocument, specifying the destination as HTML, produces aF helpful .COM file for making a  .GIF file out of .PS. But can you thenH include it as the first parameter of a <FIGURE_FILE> tag, or is the onlyC remedy to hack the HTML - not onerous, but a bit naff? I've guessedoB <FIGURE_FILE>(GIF...), <FIGURE_FILE>(HTML...) and (in desperation)K <FIGURE_FILE>(BOOKREADER...) but to no avail. The 3.3 docs don't mention ito: under <FIGURE_FILE>. Is there a 'new features' supplement?   Thanks   b    ------------------------------  $ Date: Tue, 4 Dec 2001 10:30:35 -0500% From: "John Vottero" <John@mvpsi.com>-& Subject: Re: DECdocument <FIGURE_FILE>/ Message-ID: <u0pr0qlpvvaq44@news.supernews.com>P  K I don't have to hack the HTML.  I think it takes the "<FIGURE_FILE>(PS\..." 5 file specification and changes the extension to .gif.r  7 "Bob Knowles" <bob.knowles@compaq.com> wrote in messagee+ news:Nf4P7.104$BK1.2769@news.cpqcorp.net...sJ > A build with DECdocument, specifying the destination as HTML, produces aH > helpful .COM file for making a  .GIF file out of .PS. But can you thenJ > include it as the first parameter of a <FIGURE_FILE> tag, or is the onlyE > remedy to hack the HTML - not onerous, but a bit naff? I've guessedrD > <FIGURE_FILE>(GIF...), <FIGURE_FILE>(HTML...) and (in desperation)J > <FIGURE_FILE>(BOOKREADER...) but to no avail. The 3.3 docs don't mention it< > under <FIGURE_FILE>. Is there a 'new features' supplement? >m > Thanks >9 > b9 >e >n   ------------------------------   Date: 4 Dec 2001 11:08:13 -06001- From: Kilgallen@SpamCop.net (Larry Kilgallen)g& Subject: Re: DECdocument <FIGURE_FILE>3 Message-ID: <RON0i32V46t0@eisner.encompasserve.org>o  W In article <u0pr0qlpvvaq44@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:iM > I don't have to hack the HTML.  I think it takes the "<FIGURE_FILE>(PS\..."i7 > file specification and changes the extension to .gif..  H That is my experience as well, although I happen to spell out POSTSCRIPT0 in my SDML, rather than use the PS abbreviation.   ------------------------------   Date: 4 Dec 2001 08:45:51 -0800 $ From: smgcircle@home.com (smgcircle) Subject: DTGreet and DTLogin= Message-ID: <20eea475.0112040845.567bf5fd@posting.google.com>o  E Can anyone help me with how to control whether or not the DTGreet andl> DTLogin processes are started. We have a number of "identical"C systems, some running these processes and some not. We can't figuren8 out how to prevent them from starting at system startup.  # Any help would be most appreciated.e   == Steve ==m   ------------------------------   Date: 4 Dec 2001 04:04:45 -0800 6 From: andrew.rycroft@intrinsitech.com (Andrew Rycroft); Subject: Enabling the SWCC Command console LUN on an RA3000i= Message-ID: <58ba0101.0112040404.7c6709d4@posting.google.com>o   Hi,e  C I have an RA3000 connected to a system with OpenVMS. I am trying tov= set up the SWCC, and the H22CONFIG procuedure asks me for the A communications LUN. I cannot find any doucmentatin on how this isdF enabled. I have been through all the screens on the serially connectedF console, and the SWCC help does not cover this eiterh. It is certainly@ not there enabled currently as all I can see from OpenVMS is the1 RAIDset I have configured. Any input appreciated.a   Thanks Andrew   ------------------------------  % Date: Tue, 04 Dec 2001 16:46:19 +0100u2 From: "Thomas H. Pauli" <thomaspauli@arcormail.de>? Subject: Re: Enabling the SWCC Command console LUN on an RA3000h+ Message-ID: <3C0CEFCB.8020303@arcormail.de>   = AFAIK you can only determine if you want a fixed or floating  I communications lun. If you do a SHOW DEVI D on the VMS prompt you'll see eI one more drive than you've bought. This is the communications device you -G are recommended to do your SET HOST/SCSI to. It's number is related to i the communications LUN.u   Thomas   Andrew Rycroft wrote:n   > Hi,n > E > I have an RA3000 connected to a system with OpenVMS. I am trying tol? > set up the SWCC, and the H22CONFIG procuedure asks me for thefC > communications LUN. I cannot find any doucmentatin on how this ishH > enabled. I have been through all the screens on the serially connectedH > console, and the SWCC help does not cover this eiterh. It is certainlyB > not there enabled currently as all I can see from OpenVMS is the3 > RAIDset I have configured. Any input appreciated.l >  > Thanks > Andrew >      --  9 Thomas H. Pauli, Hammersteinstr.19, 14199 Berlin, GermanyC   ------------------------------  % Date: Tue, 04 Dec 2001 10:30:40 -0500(  From: Binh Nguyen <binh@egh.com>, Subject: Example of server code using thread' Message-ID: <3C0CEC20.D3768B21@egh.com>   M Hi,  is there any sample server code using thread that I can take a look at ?-M I've downloaded the http server written by David Jones, but there's not a loteK of documentation.  Any help would be appreciated.  BTW, I'd be writing thism in either C or basic.d  
 Thanks.  Binhi   ------------------------------  % Date: Tue, 04 Dec 2001 21:51:39 +0300 4 From: "Ruslan R. Laishev" <laishev@smtp.deltatel.ru>0 Subject: Re: Example of server code using thread0 Message-ID: <3C0D1B3B.E34CBC1E@smtp.deltatel.ru>   Hi ! 	What is your primary task?r     Binh Nguyen wrote: > O > Hi,  is there any sample server code using thread that I can take a look at ?$O > I've downloaded the http server written by David Jones, but there's not a lotrM > of documentation.  Any help would be appreciated.  BTW, I'd be writing thisL > in either C or basic.m >  > Thanks.  Binh    -- N Cheers, Ruslan.lD +---------------------pure personal opinion------------------------+;       RADIUS Server for OpenVMS project - www.radiusvms.como8         vms-isps@dls.net - Forum for ISP running OpenVMS*                  Mobile: +7 (901) 971-3222A    TKD (WTF) in Russia, St.-Petersburg - www.TaeKwonDo-WTF.SPb.RU    ------------------------------   Date: 4 Dec 2001 07:16:30 -0800r+ From: stephane_paquin@hotmail.com (SPaquin).+ Subject: File cache performance for dummies2< Message-ID: <fdd7874.0112040716.2c9402a9@posting.google.com>  ? I am new to performance analysis so forgive my errors. I have 3 E identical VAX VMS 3100-98 512Mb having the same software on it. VAX A D is backup, has 54 processes(11 users). VAX B(104 proc, 53 users) andB C(80 proc,31 users) are in production. The same compilation job isB slower on VAX A than on VAX C. Since VAX A has almost no workload,@ this is puzzling. I have read the OpenVMS Performance ManagementC manual and searched my systems for the IO cache performance. I usedeB MON FILE and MON IO for 24h to get a sense of the hit % and other. Here is some data:  #                 VAX A      B      C $ DIR FCB           63%      71     99$ DIR DATA          16       22     99$ FILE HDR          35       52     95  $ DIRECT IO         54       60     19$ BUFFER IO         33       99     56% PAGE READ IO RATE 2.1      3.2    2.6-  E  I noticed a very bad hit rate for DIR DATA on VAX A and B, excellentaE on C. How is that possible? I found out that the DIR DATA hit rate iseF dependant on ACP_DIRCACHE parameter. I have searched the current value for this parameter.F  #                 VAX A      B      C 8 ACP_DIRCACHE    65535*   65535* 16384   (*=maximum size)  F The fact that the current value has grown to the maximum size on A and@ B is puzzling. And C is getting great performance from a smallerA cache. The command sh mem/cach/full gives a VIOC Read Hit Rate ofo@ 94-96% range for all vax with sizes of 11394, 61053 and 14223. AF defrag runs on all VAXes every day. Last item, the direct IO count forE the same compilation job on the VAXes is 2500 on VAX A and B, 1000 oni VAX C.  D I think the file system cache is wrong. How can I determine if it is7 working properly ? What other investigations can I do ?e    Suggestions are welcome.s  Thanks to VMS gurus    SPaquin   ------------------------------  % Date: Tue, 04 Dec 2001 16:42:06 +0100 2 From: "Thomas H. Pauli" <thomaspauli@arcormail.de>/ Subject: Re: File cache performance for dummies-+ Message-ID: <3C0CEECE.9090003@arcormail.de>:   Hello,  @ since it's a compilation job I'm not convinced, that file cache E performance is the critical thing. What did the jobs do? How many CPUgD I/Os and so on were consumed? Did you compare the accounting data onG the different machines ? Did you use MONITOR SYSTEM or MONITOR IO when >I the job in question was running ? Did you see many page faults (>1000/s)  C   or perhaps 100% CPU ? I am really astonished about the very high eH ACP_DIRCACHE value on all machines. This seems to point to a bottleneck I in your cluster (IS it a cluster ?), probably an application which opens ! and closes far too many files.   Thomas   SPaquin wrote:  A > I am new to performance analysis so forgive my errors. I have 3sG > identical VAX VMS 3100-98 512Mb having the same software on it. VAX AgF > is backup, has 54 processes(11 users). VAX B(104 proc, 53 users) andD > C(80 proc,31 users) are in production. The same compilation job isD > slower on VAX A than on VAX C. Since VAX A has almost no workload,B > this is puzzling. I have read the OpenVMS Performance ManagementE > manual and searched my systems for the IO cache performance. I usedcD > MON FILE and MON IO for 24h to get a sense of the hit % and other. > Here is some data: > % >                 VAX A      B      Cd& > DIR FCB           63%      71     99& > DIR DATA          16       22     99& > FILE HDR          35       52     95 > & > DIRECT IO         54       60     19& > BUFFER IO         33       99     56' > PAGE READ IO RATE 2.1      3.2    2.6n > G >  I noticed a very bad hit rate for DIR DATA on VAX A and B, excellent G > on C. How is that possible? I found out that the DIR DATA hit rate isnH > dependant on ACP_DIRCACHE parameter. I have searched the current value > for this parameter.] > % >                 VAX A      B      Ce: > ACP_DIRCACHE    65535*   65535* 16384   (*=maximum size) > H > The fact that the current value has grown to the maximum size on A andB > B is puzzling. And C is getting great performance from a smallerC > cache. The command sh mem/cach/full gives a VIOC Read Hit Rate oftB > 94-96% range for all vax with sizes of 11394, 61053 and 14223. AH > defrag runs on all VAXes every day. Last item, the direct IO count forG > the same compilation job on the VAXes is 2500 on VAX A and B, 1000 on> > VAX C. > F > I think the file system cache is wrong. How can I determine if it is9 > working properly ? What other investigations can I do ?c >  >  Suggestions are welcome.. >  Thanks to VMS gurus > 
 >  SPaquin >      -- a9 Thomas H. Pauli, Hammersteinstr.19, 14199 Berlin, Germanyu   ------------------------------  $ Date: Tue, 4 Dec 2001 10:06:34 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>L Subject: Free certification on Alpha, Tru64, and VMS at ITUG/DECUS in Europe1 Message-ID: <LC5P7.111$BK1.2846@news.cpqcorp.net>t  K For details on ITUG/DECUS visit  http://jointconference.org. For additionalbL information, contact the Joint European Conference Headquarters in Europe atK +32 2 743 1548 or in the United States at +1 (312) 321 6851 or +1 (800) 845f7 4884 (inside the United States only), or send a note tow info@jointconference.org.r& Compaq Accredited Professional Program  @ Compaq OpenVMS V7, Tru64 UNIX V5, and AlphaServer Certifications  J Compaq's High Performance Server business is pleased to offer AlphaServer,H Tru64 UNIX V5, and OpenVMS V7 certification exams at no cost during thisH year's ITUG/DECUS Joint European Conference. Subject Matter Experts willH offer several exam overview sessions to help familiarize exam candidatesE with exam objectives, recommended training options, and documentationsK sources to help prepare for exams. The technical experts will also overview@G the topics to be tested and answer questions about the content, to help.K candidates who wish to take the free exams offered at the event. CandidatesmE who wish to prepare for exams before the event should review the ExamaH Preparation Guides (EPGs) available at the URLs provided below. Each EPGG provides information similar to what is to be presented at the overviewoE sessions, including a complete list of the competencies to be tested,lD recommended courses and study references, and sample test questions.  H  The following table lists the exams to be offered at the event for eachJ certification, and where to find the Exam Preparation Guides. Please referJ to the EPGs for a detailed description of the audiences for whom the examsJ are intended. Visit the Compaq Accredited Professional program web site atL www.compaq.com/certification/ for complete descriptions of each platform and' operating system accreditation program.              Exam #      Exam Titler      EPG  $       Operating System Accreditation  &       OpenVMS V7 Systems Administrator  	       651 &      OpenVMS V7 Systems AdministrationC      http://www.ase.emea.compaq.com/certification/training/651.html   !       OpenVMS V7 Systems Engineerm  	       450uA      OpenVMS V7 Advanced Administration, Performance, and Supporto      Available Q1, 2002w  	       436 &      OpenVMS V7 Network Administration      Available Q1, 2002e  )       Tru64 UNIX V5 Systems Administrator   	       601eB      Tru64 UNIX V5 System Administration, Support, and IntegrationC      http://www.ase.emea.compaq.com/certification/training/601.htmla  $       Tru64 UNIX V5 Systems Engineer  	       702eD      Tru64 UNIX V5 Advanced Administration, Performance, and SupportC      http://www.ase.emea.compaq.com/certification/training/702.html(  	       703 )      Tru64 UNIX V5 Network AdministrationeC      http://www.ase.emea.compaq.com/certification/training/703.htmla  	       704i-      TruCluster V5 Implementation and Support C      http://www.ase.emea.compaq.com/certification/training/704.htmls         System Accreditation  E       AlphaServer Midrange /OpenVMS V7 Accredited Platform IntegratorT  G       AlphaServer Midrange/Tru64 UNIX V5 Accredited Platform Integrator.    9      Compaq Alpha Systems Product Architecture (ASYSPARC)hH      http://www.ase.emea.compaq.com/certification/training/ASYSPARC.html  A       AlphaServer Midrange/OpenVMS V7 Accredited Systems Engineer1  .       Exams 651, 450, 436, and ASYSPARC above.  D       AlphaServer Midrange/Tru64 UNIX V5 Accredited Systems Engineer  3       Exams 601, 702, 703, 704, and ASYSPARC above.e  	       401o$      Tru64 UNIX V4 to V5 Update Exam  K       (This exam is ONLY for Tru64 UNIX V4 ASEs who wish to migrate to V5.)       Available January, 2002   ------------------------------  % Date: Tue, 04 Dec 2001 11:20:17 +0000o% From: Alan Greig <a.greig@virgin.net>B Subject: Re: Future of VMS ?8 Message-ID: <39cp0usnq9e5nbgonbkdja5jqrqpsp9blp@4ax.com>  F On Wed, 28 Nov 2001 23:06:21 GMT, "Bill Todd" <billtodd@metrocast.net> wrote:   >  >,L >Any evidence that current management 'got religion' about VMS should almostJ >certainly be treated as an outright lie designed to deflect the otherwise' >natural consequences of their actions.   F If Winkler truly has found religion then maybe I should mail him againE and suggest that his new post heading up "supply chain management" intF the new HP would allow him to fund a VMS SAP port to replace the Tru64E SAP systems running Compaq. If Compaq/HP used SAP on VMS to run theirnA business that would send a clear signal. Given that he told me heaE found religion it might be interesting to see a reply. My guess is heh would just ignore it.o  A Anyone know what ERP systems HP use? Is it SAP? If so I guess itso probably on HP-UX.   >>K >> 6.  The abandoning of the merger should mean that Capellas is out on hiscG >> ear, hopefully accompanied by the coterie who supported him.  I, for K >> one, would be very happy to see a bunch of over-paid under-achievers get I >> their marching orders.  In about 30 months Capellas has not managed to H >> check the slide in the performance of Compaq - this year alone, up toI >> 30th September Compaq has lost almost $1.8 million every day in the PC-
 >> sector. >u> >That alone is sufficient reason to work to derail the merger. >a >>H >> 7.  If Capellas (et al) depart, the market will at least give the newE >> management a chance to prove themselves, which means that Compaq'snE >> credibility rating would go from "negative" to "neutral", which of.% >> course would be a big improvement.  >sL >Almost any change would be likely to be (and to be seen as) an improvement. >  >>G >> 8.   If Compaq sincerely lacks the will or motivation to do anythingHJ >> productive with VMS, then it should be made available to an alternativeJ >> buyer as soon as practicable. If the merger goes ahead but in 12 monthsH >> the new company decides to rid itself of VMS, the market value of theJ >> platform will have fallen even further and the job of restoring some ofK >> its attractiveness becomes that much more difficult.  (A few weeks ago IsD >> noticed a favourable response to the rumour of an IBM purchase ofH >> Compaq.  This indicates to me that the posters to this newsgroup haveK >> greater confidence in IBM's ability than Compaq's when it comes to doing1  >> something positive with VMS.) > G >I doubt that VMS is a salable entity without its support organization.u >C >> >>K >> I want a new company management team to be responsible for VMS.  I don'tsJ >> care much if it still within Compaq but free of the wanton stupidity ofB >> concentrating on the PC market, or if it in a whole new company
 >> somewhere.L >H >Whole-heartedly agree.o > ? >  I believe that without these changes we will continue to gettE >> more of the same neglect that has dogged VMS for the last 5 years.n > K >No:  without these changes, VMS will rapidly either become comatose or diee
 >outright. >  >- billr >  >g   -- Alan   ------------------------------  % Date: Tue, 04 Dec 2001 12:12:04 +0000D% From: Alan Greig <a.greig@virgin.net>g Subject: Re: Future of VMS ?8 Message-ID: <jsep0ukhaqmrebkvpob93d3fpem2ncsvq2@4ax.com>  C On Tue, 04 Dec 2001 11:20:17 +0000, Alan Greig <a.greig@virgin.net>_ wrote:   >iG >If Winkler truly has found religion then maybe I should mail him againeF >and suggest that his new post heading up "supply chain management" inG >the new HP would allow him to fund a VMS SAP port to replace the Tru64 F >SAP systems running Compaq. If Compaq/HP used SAP on VMS to run theirB >business that would send a clear signal. Given that he told me heF >found religion it might be interesting to see a reply. My guess is he >would just ignore it. >lB >Anyone know what ERP systems HP use? Is it SAP? If so I guess its >probably on HP-UX.h  D Given the following quote from a letter to HP World (see full letterB in another posting) it is quite clear that HP will migrate its ERPC systems (and hence Compaq's) to Windows. This confirms the logic of0E appointing Winkler to this position. At first it seems a strange movef> but is exactly the sort of  appointment that would precede his< appointment to HP/Compaq CEO a couple of years down the line  D From a supplier to HP of security products.( www.cardaccess.com ) to	 HP World.   C "HP has informed us that the company will not consider any internalc= solution based on any platform other than Windows NT/2000 forbD worldwide deployment. HP also said it will not consider UNIX for any> internal applications including, but not limited to, security, purchasing, or mail servers."l   -- Alan   ------------------------------  * Date: Tue, 4 Dec 2001 13:50:57 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Future of VMS ?* Message-ID: <9uikc1$lm$1@aquila.mdx.ac.uk>  ` In article <39cp0usnq9e5nbgonbkdja5jqrqpsp9blp@4ax.com>, Alan Greig <a.greig@virgin.net> writes:G >On Wed, 28 Nov 2001 23:06:21 GMT, "Bill Todd" <billtodd@metrocast.net>d >wrote:i >o >> >>M >>Any evidence that current management 'got religion' about VMS should almostoK >>certainly be treated as an outright lie designed to deflect the otherwisen( >>natural consequences of their actions. >TG >If Winkler truly has found religion then maybe I should mail him againhF >and suggest that his new post heading up "supply chain management" inG >the new HP would allow him to fund a VMS SAP port to replace the Tru64HF >SAP systems running Compaq. If Compaq/HP used SAP on VMS to run theirB >business that would send a clear signal. Given that he told me heF >found religion it might be interesting to see a reply. My guess is he >would just ignore it. >I  J I'd suggest that Winkler's religion probably involves bloody sacrifices toK the twin gods Intel and Microsoft. And we can all guess VMS's star role. :)n  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  # Date: Tue, 04 Dec 2001 12:08:03 GMT:& From: "Jeff Killeen" <Jeff@IDM-IO.com>, Subject: FWIW - Capellas at Oracle OpenWorld5 Message-ID: <D03P7.185$wp3.4961@nwrddc01.gnilink.net>   B http://www.computerworld.com/storyba/0,4125,NAV47_STO66276,00.html   ------------------------------  # Date: Tue, 04 Dec 2001 12:17:02 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>0 Subject: Re: FWIW - Capellas at Oracle OpenWorld5 Message-ID: <293P7.201$wp3.6346@nwrddc01.gnilink.net>-   More from OpenWorld...  2 http://www.itworld.com/Net/3697/IDG011203capellas/  F http://www.infoworld.com/articles/hn/xml/01/12/03/011203hncappelas.xml  = http://www.zdnet.com/zdnn/stories/news/0,4586,5100243,00.htmli  L http://www.infoworld.com/articles/hn/xml/01/12/03/011203hnbarrettkeynote.xml   ------------------------------  % Date: Tue, 04 Dec 2001 12:59:49 +0000l% From: Alan Greig <a.greig@virgin.net>J0 Subject: Re: FWIW - Capellas at Oracle OpenWorld8 Message-ID: <0thp0u4nbd2giv38nufjc3k18s8llg3dea@4ax.com>  B On Tue, 04 Dec 2001 12:08:03 GMT, "Jeff Killeen" <Jeff@IDM-IO.com> wrote:  C >http://www.computerworld.com/storyba/0,4125,NAV47_STO66276,00.html    Quote...  D "Capellas also announced the company's first certified configurationE for linking Oracle9i Real Application Clusters with Microsoft Corp.'s2> Windows 2000 operating system. This means users can now choose> pretested combinations of Compaq ProLiant servers running both$ Oracle's software and Windows 2000.   E While the current economic downturn has caused a sharp pullback in ITgB spending, companies will need to purchase clustering technology toE keep their infrastructures up to date, Capellas said to the OpenWorldM
 audience.   E "This clustering of nodes that grew up in the world of supercomputing14 is now coming to commercial applications," he said.   > Several users said after the speech that Capellas' vision of aE clustered computing future is the right approach, but they added thatg' the concept really isn't all that new."a   End quote...    A Wow "clustering grew up in the world of supercomputing and is nowa1 coming to commercial applications" says Capellas.t  C The guy's a complete *expletive deleted*  idiot or else assumes hisC customers are.     But then we knew that already.   -- Alan   ------------------------------  ! Date: Tue, 04 Dec 01 11:28:39 GMT  From: jmfbahciv@aol.com 0 Subject: Re: FWIW - Capellas at Oracle OpenWorld+ Message-ID: <9uij6i$ble$7@bob.news.rcn.net>e  8 In article <0thp0u4nbd2giv38nufjc3k18s8llg3dea@4ax.com>,)    Alan Greig <a.greig@virgin.net> wrote: C >On Tue, 04 Dec 2001 12:08:03 GMT, "Jeff Killeen" <Jeff@IDM-IO.com>r >wrote:e >oD >>http://www.computerworld.com/storyba/0,4125,NAV47_STO66276,00.html > 	 >Quote...6 >5E >"Capellas also announced the company's first certified configuration F >for linking Oracle9i Real Application Clusters with Microsoft Corp.'s? >Windows 2000 operating system. This means users can now choose ? >pretested combinations of Compaq ProLiant servers running both1% >Oracle's software and Windows 2000. n >lF >While the current economic downturn has caused a sharp pullback in ITC >spending, companies will need to purchase clustering technology tonF >keep their infrastructures up to date, Capellas said to the OpenWorld >audience. a >tF >"This clustering of nodes that grew up in the world of supercomputing5 >is now coming to commercial applications," he said. - > ? >Several users said after the speech that Capellas' vision of atF >clustered computing future is the right approach, but they added that( >the concept really isn't all that new." >e
 >End quote...  >c >tB >Wow "clustering grew up in the world of supercomputing and is now2 >coming to commercial applications" says Capellas. > D >The guy's a complete *expletive deleted*  idiot or else assumes his >customers are.    >h >But then we knew that already.  >M  ? What bothers me more is that it means he doesn't know about they= stuff that DEC had.  That implies that the knowledge is gone.s   /BAH  ' Subtract a hundred and four for e-mail.o   ------------------------------  $ Date: Tue, 4 Dec 2001 15:06:42 +0100% From: "Dr. Dweeb." <Dweeb@nospam.com>n0 Subject: Re: FWIW - Capellas at Oracle OpenWorld0 Message-ID: <lL4P7.114$uQ4.5368@news.get2net.dk>   Hmm,  L That would of cousre presuppose that he actually *had* the knowledge at some time.   C a) IIRC he was not one of the people involved in the DEC aquisition1J b) I cannot recall him having demonstrated possession of this knowledge (I, have not been listening very closely though)   Ignorance is bliss !  K An appalling state of affairs really and this quote is tantamount to sayingeC "by the way I am an ignorant moron with no clue about my companiesIA intellectual property, the heritage of its component parts or then2 development of the computer industyry in general".   They shoot horses dont they ?   Dweeb J <jmfbahciv@aol.com> wrote in message news:9uij6i$ble$7@bob.news.rcn.net...: > In article <0thp0u4nbd2giv38nufjc3k18s8llg3dea@4ax.com>,+ >    Alan Greig <a.greig@virgin.net> wrote:6E > >On Tue, 04 Dec 2001 12:08:03 GMT, "Jeff Killeen" <Jeff@IDM-IO.com> 	 > >wrote:r > >DF > >>http://www.computerworld.com/storyba/0,4125,NAV47_STO66276,00.html > >t > >Quote...  > >aG > >"Capellas also announced the company's first certified configurationtH > >for linking Oracle9i Real Application Clusters with Microsoft Corp.'sA > >Windows 2000 operating system. This means users can now choose A > >pretested combinations of Compaq ProLiant servers running botha& > >Oracle's software and Windows 2000. > >eH > >While the current economic downturn has caused a sharp pullback in ITE > >spending, companies will need to purchase clustering technology to1H > >keep their infrastructures up to date, Capellas said to the OpenWorld > >audience. > > H > >"This clustering of nodes that grew up in the world of supercomputing6 > >is now coming to commercial applications," he said. > > A > >Several users said after the speech that Capellas' vision of asH > >clustered computing future is the right approach, but they added that* > >the concept really isn't all that new." > >e > >End quote...9 > >l > >eD > >Wow "clustering grew up in the world of supercomputing and is now4 > >coming to commercial applications" says Capellas. > >oF > >The guy's a complete *expletive deleted*  idiot or else assumes his > >customers are.D > >5! > >But then we knew that already.  > >  >aA > What bothers me more is that it means he doesn't know about theb? > stuff that DEC had.  That implies that the knowledge is gone.  >E > /BAH >3) > Subtract a hundred and four for e-mail.(   ------------------------------  ! Date: Tue, 04 Dec 01 12:58:47 GMTr From: jmfbahciv@aol.comi0 Subject: Re: FWIW - Capellas at Oracle OpenWorld+ Message-ID: <9uiofg$c1n$2@bob.news.rcn.net>   0 In article <lL4P7.114$uQ4.5368@news.get2net.dk>,)    "Dr. Dweeb." <Dweeb@nospam.com> wrote:   + Hey!  Stop the upsidedown postings, please.t   >Hmm,  >m2 >That would of cousre presuppose that he actually " >*had* the knowledge at some time.  : In this case, the company also included its people (a fact, that other people don't seem to understand).   /BAH <pins>   /BAH  ' Subtract a hundred and four for e-mail.r   ------------------------------  $ Date: Tue, 4 Dec 2001 16:30:23 -0000* From: Andrew Robinson <arobinson@hspg.com>& Subject: Help with Shadowing ParameterM Message-ID: <CDA4BAD1E10ED41181AC00508B6051D3C3E4C5@grumpy.internal.hspg.com>x  K I have a number of data disks that are shadowed between two machines, theselH are beginning to slow down due to high usage. Before upgrading the disksK with faster/bigger drives I heard of an undocumented parameter I could set,fI which is switching on bit 16 on SYSGEN - SHADOW_SYS_DISK which would then H perform local disk reads instead of using the MSCP served set, but would+ then perform writes to the MSCP served set.aG Please could someone tell me which end is bit 16 - The parameter at theo1 moment is set to 65536 which is 10000000000000000tK Do I need to set the parameter to 65537 (10000000000000001) or am I gettings the wrong end of the stick.iK Also does anyone know of any pitfalls to changing this setting. SYSGEN sayseK its a Dynamic setting, but is it one of those which you still should reallyp do a reboot to switch on.n Parts :    2 Alpha 1200's Internal disks RZ1CB0 Using Private FDDI Ring for intercluster traffic0 OVMS version 7.2-1 (Upgrading to 7.2-2 shortly)    Regardsh   Andrew RobinsonM   ------------------------------  % Date: Tue, 04 Dec 2001 18:56:54 +0010o' From: <paddy.o'brien@zzz.tg.nsw.gov.au>bE Subject: Re: Hidden accounting: was Re: No surprise about Tru64 death 5 Message-ID: <01KBHBGFBZQQ0013ZA@tgmail.tg.nsw.gov.au>i   John McLean wrote:   >Tim Llewellyn wrote:s >> d >> John McLean wrote:a >> tG >> > I don't like dishonesty and incompetence in anyone or any company.h >>  & >> so, why are you working in IT John? >>  ) >> Don't worry, I have a similar failing.t >iF >It's funny you should ask Tim, I spent 5 years at university doing anC >architecture course and before results my known for the final yearA5 >(which I passed), I'd enrolled in Computing Studies.t >cE >At the time I found it like a breath of fresh air.  No longer did I o >haveuB >to put up with vague opinions about what was better and what was  >right. G >IT people would argue with facts and logic - and that made things justc >so simple.o >I >Time's change ....  :-(  F Times do indeed change, John.  Firstly, when I was a young lad, there B were no such studies.  Secondly, and more germaine, these days IT B people are bean counters, usually failing in that career path and  taking up the "easy option".  F I shall not say that my industry is riddled with such, but you didn't  hear what I didn't say. :-))   Regards, Paddy   ------------------------------  % Date: Tue, 04 Dec 2001 10:01:13 +0000C4 From: John Laird <john@laird-towers.freeserve.co.uk>E Subject: Re: Hidden accounting: was Re: No surprise about Tru64 deathi8 Message-ID: <jl7p0ugeucbkn6426evs0all3uh1kbui06@4ax.com>  / On Tue, 04 Dec 2001 07:01:24 +0100, John McLean0& <mcleanj@swissonline.delete.ch> wrote:  G >IT people would argue with facts and logic - and that made things justj >so simple.@  C Blimey, never been involved in a language war or O/S battle, then ?r   	John>   ------------------------------  # Date: Tue, 04 Dec 2001 13:54:09 GMTa( From: "Rich Bjers" <RBjers@Cinci.RR.Com>  Subject: HP OpenView and OpenVMS9 Message-ID: <5A4P7.92148$z55.12041803@typhoon.neo.rr.com>o  J Does anyone know of any freeware or licensed package's that can send eventL messages (oracle is down) and error messages (fan has failed) via SNMP traps% to an HP OpenView Management station.P   --   Thanks,t  
 Richard Bjerst Email: RBjers@Cinci.RR.Com   ------------------------------  % Date: Tue, 04 Dec 2001 11:50:08 +0000.% From: Alan Greig <a.greig@virgin.net>i- Subject: Inquirer article on Compaq and Alphau8 Message-ID: <fodp0uk1t36i7sejuf41dkik6h1d73dvp0@4ax.com>  ? There's a good but lengthy analysis of recent and future Compaq @ actions just been posted on The Inquirer by "Nicholas Penne" - a& pseudonym. Here's the opening section:  ' http://www.theinquirer.net/04120101.htmI  
 RIP Alpha    Analysis: Dead. Got it? Dead n* by Nicholas Penne, 04/12/2001 09:14:24 BST    E THE COMPAQ ALPHA DIVESTITURE and its implications for Compaq's futureeE has been a favourite topic for industry analysts and the trade press.3F Like the blind men describing an elephant, they get parts correct, but miss the big picture.l Rules for Speculationn  E Although many will speculate on past and future courses of action for,F Compaq, there are certain ground rules that time and again have proven> themselves mandatory in order for any speculation to be deemed reasonable.n  ' Rule #1. Is it going to cost anything?    A Although Compaq has been known to buy businesses, they have nevertE significantly increased their investment in an existing business. Anyc; speculation that requires Compaq to increase funding in anytB substantive way is beyond the realm of possibility. Note that even7 groups internal to Compaq have run afoul of this rule. u  1 Rule #2. Do they actually have to *tell* anyone? e  B At Compaq, what people commonly refer to as "marketing" is allowedF only in the PC division. The levels of approval required for any otherB Compaq organization for something as simple as a press release areB astounding. So give up any speculations that require "marketing."    Rule #3. Not in Houston? r  D At Compaq, membership in the executive "good old boys/girls" club isE limited to those in Houston. A part-time office is not enough. If theI< executives who would be in charge of your speculation resideD elsewhere, they will be powerless to assume any role other than thatC of caretaker. (They will also be very busy removing the knives fromb
 their back.) w  . Rule #4. "Software is something Partners do."   B A commonly held belief by those in charge from Compaq Classic (and= actually articulated by Enrico Pesatori) is that "software islB something partners do." If your speculation requires Compaq to get@ into a software business, you are engaging in wishful thinking.    RIP Alpha. What's next?   F Given recent history and Compaq's internal prejudices, the decision toD divest Alpha was inevitable. This decision has its roots as far back? as Compaq's original reason for acquiring Digital, which was togD acquire a world-class services organization. Although there was someD noise made about acquiring an enterprise capability, there was then,E (and still today) no understanding of what it takes to be a player in F the enterprise market by the executives controlling Compaq's strategic direction. o  D Those executives can only mindlessly follow Microsoft's "lead" for aC future enterprise direction. Besides, there's that pesky rule #4 to C consider. The word "Solution" has been much in vogue, but upon evengE cursory examination, these "solutions" are found to be collections of D components. Since there's yet to be a software ISV who will a prioriA refuse to make their product available on other vendor's hardwarem7 (especially when they're all Intel-based), this form ofgA "differentiation" is illusory at best. Given the timing, it seemseC likely that Alpha was on the table during the HP talks, but that HPrA was solidly behind the decision to divest, and may have made it ay prerequisite to the deal.   ) Compaq has now completed divestiture of: q   * Windows NT on Alphaw$ * Commercial software for Windows NT; * The Alpha processor and its associated engineering groupsH" * Compiler technology and products  D Each of these events can be seen to be small steps in a larger plan.C Each step perturbed the customer base, but each in itself was smallt> enough to allow the corporation to survive, and to mislead theA customer base that each step was the last. Ignoring (for now) the @ potential HP acquisition, the process will not be complete untilF Compaq has divested itself of the rest of the Business Critical Server Group (BCSG), which includes:    * Tru64 UNIX	 * OpenVMSe * NSK/Himalaya * Custom Systems   .... [CUT]. ....E "Nicholas Penne" is a computer professional with over thirty years inl= the industry, in such diverse fields as Software Engineering,vC Education, Services, Operations and Marketing. Since 1990, Nick hasoC been a competitive, strategic and industry analyst. In the industrytE analyst community, excessive candour can sometimes impede the abilitylC to make a living, so Nick chooses to remain anonymous at this time.tC But these days, that doesn't preclude direct communication. You canH' reach him at nicholas_penne@hotmail.comt   -- Alan   ------------------------------  $ Date: Tue, 4 Dec 2001 14:01:15 +0100% From: "Dr. Dweeb." <Dweeb@nospam.com>a1 Subject: Re: Inquirer article on Compaq and Alpha / Message-ID: <0O3P7.99$uQ4.4844@news.get2net.dk>i  F I somehow missed that one previously.  Still, it is depressing to read because it rings so true.i   Dweeb.2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:fodp0uk1t36i7sejuf41dkik6h1d73dvp0@4ax.com...A > There's a good but lengthy analysis of recent and future Compaq-B > actions just been posted on The Inquirer by "Nicholas Penne" - a( > pseudonym. Here's the opening section: >a) > http://www.theinquirer.net/04120101.htmw >4 > RIP Alphag >i > Analysis: Dead. Got it? Dead, > by Nicholas Penne, 04/12/2001 09:14:24 BST >  >-G > THE COMPAQ ALPHA DIVESTITURE and its implications for Compaq's future G > has been a favourite topic for industry analysts and the trade press.OH > Like the blind men describing an elephant, they get parts correct, but > miss the big picture./ > Rules for Speculation/ >0G > Although many will speculate on past and future courses of action for3H > Compaq, there are certain ground rules that time and again have proven@ > themselves mandatory in order for any speculation to be deemed
 > reasonable.e >l( > Rule #1. Is it going to cost anything? >uC > Although Compaq has been known to buy businesses, they have neverJG > significantly increased their investment in an existing business. Anyb= > speculation that requires Compaq to increase funding in any:D > substantive way is beyond the realm of possibility. Note that even8 > groups internal to Compaq have run afoul of this rule. >.2 > Rule #2. Do they actually have to *tell* anyone? >iD > At Compaq, what people commonly refer to as "marketing" is allowedH > only in the PC division. The levels of approval required for any otherD > Compaq organization for something as simple as a press release areC > astounding. So give up any speculations that require "marketing."c >w > Rule #3. Not in Houston? >cF > At Compaq, membership in the executive "good old boys/girls" club isG > limited to those in Houston. A part-time office is not enough. If thel> > executives who would be in charge of your speculation resideF > elsewhere, they will be powerless to assume any role other than thatE > of caretaker. (They will also be very busy removing the knives froma > their back.) >n/ > Rule #4. "Software is something Partners do."a > D > A commonly held belief by those in charge from Compaq Classic (and? > actually articulated by Enrico Pesatori) is that "software isgD > something partners do." If your speculation requires Compaq to getA > into a software business, you are engaging in wishful thinking.  >  > RIP Alpha. What's next?  >-H > Given recent history and Compaq's internal prejudices, the decision toF > divest Alpha was inevitable. This decision has its roots as far backA > as Compaq's original reason for acquiring Digital, which was toeF > acquire a world-class services organization. Although there was someF > noise made about acquiring an enterprise capability, there was then,G > (and still today) no understanding of what it takes to be a player in4H > the enterprise market by the executives controlling Compaq's strategic > direction. >sF > Those executives can only mindlessly follow Microsoft's "lead" for aE > future enterprise direction. Besides, there's that pesky rule #4 touE > consider. The word "Solution" has been much in vogue, but upon evensG > cursory examination, these "solutions" are found to be collections ofrF > components. Since there's yet to be a software ISV who will a prioriC > refuse to make their product available on other vendor's hardwaren9 > (especially when they're all Intel-based), this form ofaC > "differentiation" is illusory at best. Given the timing, it seemsoE > likely that Alpha was on the table during the HP talks, but that HP-C > was solidly behind the decision to divest, and may have made it at > prerequisite to the deal.  >t* > Compaq has now completed divestiture of: >n > * Windows NT on Alphat& > * Commercial software for Windows NT= > * The Alpha processor and its associated engineering groups $ > * Compiler technology and products >CF > Each of these events can be seen to be small steps in a larger plan.E > Each step perturbed the customer base, but each in itself was smallM@ > enough to allow the corporation to survive, and to mislead theC > customer base that each step was the last. Ignoring (for now) the B > potential HP acquisition, the process will not be complete untilH > Compaq has divested itself of the rest of the Business Critical Server > Group (BCSG), which includes:: >I > * Tru64 UNIX > * OpenVMSr > * NSK/Himalaya > * Custom Systems >g > .... > [CUT]. > ....G > "Nicholas Penne" is a computer professional with over thirty years in ? > the industry, in such diverse fields as Software Engineering,CE > Education, Services, Operations and Marketing. Since 1990, Nick hastE > been a competitive, strategic and industry analyst. In the industryaG > analyst community, excessive candour can sometimes impede the abilitytE > to make a living, so Nick chooses to remain anonymous at this time.bE > But these days, that doesn't preclude direct communication. You cant) > reach him at nicholas_penne@hotmail.com  >u > -- > Alan   ------------------------------  # Date: Tue, 04 Dec 2001 14:50:10 GMTt& From: "Jeff Killeen" <Jeff@IDM-IO.com>1 Subject: Re: Inquirer article on Compaq and Alphas5 Message-ID: <Co5P7.22$II1.27574@nwrddc02.gnilink.net>>  F > Those executives can only mindlessly follow Microsoft's "lead" for a > future enterprise direction.  K Those who think Compaq is mindlessly in bed with Microsoft should take noteeK of Capellas's keynote at Oracle OpenWorld.  Based on my experience over therG last 2 years with CETS planning it appears to that Compaq has adopted aC/ triangulation policy with Microsoft and Oracle.a  C There are very solid business reasons why both Compaq would want tosI triangulate Microsoft with Oracle and why Intel would want to triangulateeE Microsoft with HP/Compaq non-Microsoft OS's.  Andy Grove has tried toeF diversify the IA dependence on Microsoft before but he could not reachH critical mass.  It is something he dearly would love to do, has publiclyJ stated so, and the opportunity now exists if the HP/Compaq merger happens.J The straw that appears to have broken the back with Capellas and MicrosoftE was Microsoft's failure to give Compaq credit when Microsoft beat theuD competition on a TP benchmark using Proliants that Compaq had helpedI Microsoft tune.  Rumor has it  a high level decision was made to play thee Oracle card.  L The interesting thing about the article, and the blind faith assumption thatE some in this newsgroup have, is the assumption as fact that MicrosofteL controls Compaq.  That blind faith assumption ignores that even an idiot CEOL would see that pursuing that path means it would place Compaq in a situationL where its market differentiator was price since everyone would have the sameG product.  That is a bad place to be.  A classic example of that type of-K market is the airline industry - Boeing (and maybe someday Airbus) make allbH the real profits and the airlines fighting it out over price.  SouthwestG being the Dell example today and Continental being what Compaq hopes tow become..  H It just never ceases to amaze me when I read articles like the one belowJ that people discount Compaq and Intel acting in their own self interest byI making sure they control as much of their product technology as possible. L To that end the name of the game is to triangulate Microsoft and not becomes its slave...    2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:fodp0uk1t36i7sejuf41dkik6h1d73dvp0@4ax.com...A > There's a good but lengthy analysis of recent and future CompaquB > actions just been posted on The Inquirer by "Nicholas Penne" - a( > pseudonym. Here's the opening section: >m) > http://www.theinquirer.net/04120101.htme >a > RIP Alpha  >  > Analysis: Dead. Got it? Dead, > by Nicholas Penne, 04/12/2001 09:14:24 BST >t >dG > THE COMPAQ ALPHA DIVESTITURE and its implications for Compaq's futureuG > has been a favourite topic for industry analysts and the trade press.wH > Like the blind men describing an elephant, they get parts correct, but > miss the big picture.w > Rules for Speculations >aG > Although many will speculate on past and future courses of action foroH > Compaq, there are certain ground rules that time and again have proven@ > themselves mandatory in order for any speculation to be deemed
 > reasonable.i >i( > Rule #1. Is it going to cost anything? >aC > Although Compaq has been known to buy businesses, they have nevereG > significantly increased their investment in an existing business. Anyt= > speculation that requires Compaq to increase funding in anyID > substantive way is beyond the realm of possibility. Note that even8 > groups internal to Compaq have run afoul of this rule. >-2 > Rule #2. Do they actually have to *tell* anyone? >oD > At Compaq, what people commonly refer to as "marketing" is allowedH > only in the PC division. The levels of approval required for any otherD > Compaq organization for something as simple as a press release areC > astounding. So give up any speculations that require "marketing."y >d > Rule #3. Not in Houston? >cF > At Compaq, membership in the executive "good old boys/girls" club isG > limited to those in Houston. A part-time office is not enough. If thep> > executives who would be in charge of your speculation resideF > elsewhere, they will be powerless to assume any role other than thatE > of caretaker. (They will also be very busy removing the knives fromf > their back.) >r/ > Rule #4. "Software is something Partners do."a >tD > A commonly held belief by those in charge from Compaq Classic (and? > actually articulated by Enrico Pesatori) is that "software isTD > something partners do." If your speculation requires Compaq to getA > into a software business, you are engaging in wishful thinking.r >e > RIP Alpha. What's next?p >aH > Given recent history and Compaq's internal prejudices, the decision toF > divest Alpha was inevitable. This decision has its roots as far backA > as Compaq's original reason for acquiring Digital, which was to F > acquire a world-class services organization. Although there was someF > noise made about acquiring an enterprise capability, there was then,G > (and still today) no understanding of what it takes to be a player in0H > the enterprise market by the executives controlling Compaq's strategic > direction. > F > Those executives can only mindlessly follow Microsoft's "lead" for aE > future enterprise direction. Besides, there's that pesky rule #4 toeE > consider. The word "Solution" has been much in vogue, but upon even-G > cursory examination, these "solutions" are found to be collections ofmF > components. Since there's yet to be a software ISV who will a prioriC > refuse to make their product available on other vendor's hardwarey9 > (especially when they're all Intel-based), this form ofdC > "differentiation" is illusory at best. Given the timing, it seems E > likely that Alpha was on the table during the HP talks, but that HPtC > was solidly behind the decision to divest, and may have made it a- > prerequisite to the deal.e >0* > Compaq has now completed divestiture of: >i > * Windows NT on Alphai& > * Commercial software for Windows NT= > * The Alpha processor and its associated engineering groups $ > * Compiler technology and products >uF > Each of these events can be seen to be small steps in a larger plan.E > Each step perturbed the customer base, but each in itself was smallr@ > enough to allow the corporation to survive, and to mislead theC > customer base that each step was the last. Ignoring (for now) theVB > potential HP acquisition, the process will not be complete untilH > Compaq has divested itself of the rest of the Business Critical Server > Group (BCSG), which includes:  >t > * Tru64 UNIX > * OpenVMSp > * NSK/Himalaya > * Custom Systems >u > .... > [CUT]. > ....G > "Nicholas Penne" is a computer professional with over thirty years inr? > the industry, in such diverse fields as Software Engineering,eE > Education, Services, Operations and Marketing. Since 1990, Nick hasgE > been a competitive, strategic and industry analyst. In the industrysG > analyst community, excessive candour can sometimes impede the abilitynE > to make a living, so Nick chooses to remain anonymous at this time.iE > But these days, that doesn't preclude direct communication. You canv) > reach him at nicholas_penne@hotmail.coml >  > -- > Alan   ------------------------------   Date: 4 Dec 2001 07:42:40 -0600a- From: koehler@encompasserve.org (Bob Koehler)l5 Subject: Re: Installing Icon permanently to CDE menu?e3 Message-ID: <kKADU2Bba5eg@eisner.encompasserve.org>n  c In article <PxUtQwKctFC+@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: e > In article <nDHz4Hxy7dhN@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:i > E >>    And why doesn't that "good documentation" show up on my OpenVMSt >>    documentation CD?g > F > When DEQ write it.  That in stores, and that which you buy from DEQ, > is almost entirely C-centric.k  F    The real shame is that prior to my first Ultrix system I had alwaysH    found DEC shipped excellent documentation.  To see poor documentationC    ship with VMS really hurts, but it started back when DEC droppedb#    thier own X11 reference manuals.i   ------------------------------   Date: 4 Dec 2001 07:43:36 -0600t- From: koehler@encompasserve.org (Bob Koehler) 5 Subject: Re: Installing Icon permanently to CDE menu? 3 Message-ID: <ri3VggF+fTRq@eisner.encompasserve.org>d  h In article <sMMO7.65$BK1.1939@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:K > Mostly I suppose, since CDE is something we ported, and didn't write.  SozM > you can generally find stuff on it on the market.  Just as we don't publishl > an OpenGL programming manual.t  F    So in the future I can expect no more Fortran reference?  No more C    reference, ...u  3    No thanks.  Maybe I'll expect some other vendor.h   ------------------------------   Date: 4 Dec 2001 07:44:04 -0600u- From: koehler@encompasserve.org (Bob Koehler)t5 Subject: Re: Installing Icon permanently to CDE menu?e3 Message-ID: <qVnmH0Ml$T$o@eisner.encompasserve.org>,  g In article <75749e0a.0112031209.70d461f6@posting.google.com>, doran167w@aol.com (Doran Werling) writes:w >> > > $ >>>> You can find the CDE docset at ] >>>> http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V50A_HTML/SYSADMIN/TITLE.HTMf >   2    I am using the CDE docset that Compaq produced.   ------------------------------  $ Date: Tue, 4 Dec 2001 11:38:43 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>v5 Subject: Re: Installing Icon permanently to CDE menu?n1 Message-ID: <n17P7.114$BK1.2538@news.cpqcorp.net>l    Bob Koehler wrote in message ...C >In article <sMMO7.65$BK1.1939@news.cpqcorp.net>, "Fred Kleinsorge" % <kleinsorge@star.zko.dec.com> writes:aL >> Mostly I suppose, since CDE is something we ported, and didn't write.  SoF >> you can generally find stuff on it on the market.  Just as we don't publisho  >> an OpenGL programming manual. >tG >   So in the future I can expect no more Fortran reference?  No more Co >   reference, ... > 4 >   No thanks.  Maybe I'll expect some other vendor. >e  J Dunno what to tell you.  If the compiler is produced by someone other thanG Compaq, I'd expect the documentation to come from the same source.  But. that's just my guess.o  K Since the CDE on VMS was just a subset of the standard UNIX stuff, the only L thing I remember that was ever VMS specific was documentation of things thatI were different (like logical names instead of pathnames, etc).  I use the  stuff on the Tru64 site myself.t   ------------------------------   Date: 4 Dec 2001 12:20:46 GMTl- From: forkosh@panix1.panix.com (John Forkosh)i, Subject: Jumpers for rz29-labelled barracuda( Message-ID: <9uif2u$sf$1@news.panix.com>  - I have several 4.3GB rz29 Seagate Barracudas,t. narrow 50-pin, but can't figure out how to set. scsi id (Google search and seagate.com were no* help).  With no jumpers set, they identify+ themselves as dka0 on a vs4000/60, and workg just fine that way.8.      The back face of the drive (with scsi and, power connectors) has 14 jumpers.  Eleven of+ them are arranged in a vertical block along , the right-hand side, and the remaining three+ are horizontally arranged at the upper-lefto of that block.*      The three-jumper group doesn't do it,) and the advice I got to try the top three * jumpers on the vertical block doesn't seem+ to work either.  Anybody know which jumpersp( to set (or where else to look for info)? Thanks,h John (forkosh@panix.com)   ------------------------------  % Date: Tue, 04 Dec 2001 12:52:17 +0000O4 From: John Laird <john@laird-towers.freeserve.co.uk>0 Subject: Re: Jumpers for rz29-labelled barracuda8 Message-ID: <bkgp0ucmslgq640fisqnvq6gdit8r9gm97@4ax.com>  C On 4 Dec 2001 12:20:46 GMT, forkosh@panix1.panix.com (John Forkosh)u wrote:  . >I have several 4.3GB rz29 Seagate Barracudas,/ >narrow 50-pin, but can't figure out how to set3/ >scsi id (Google search and seagate.com were noi+ >help).  With no jumpers set, they identifyo, >themselves as dka0 on a vs4000/60, and work >just fine that way./ >     The back face of the drive (with scsi andh- >power connectors) has 14 jumpers.  Eleven ofh, >them are arranged in a vertical block along- >the right-hand side, and the remaining threep, >are horizontally arranged at the upper-left >of that block.u+ >     The three-jumper group doesn't do it,i* >and the advice I got to try the top three+ >jumpers on the vertical block doesn't seem#, >to work either.  Anybody know which jumpers) >to set (or where else to look for info)?o >Thanks,  A Odd - I've always found Seagate's pages to be absolutely spot-on.e   You need to be looking inq? http://www.seagate.com/support/disc/specs/family_barracuda.htmls  B It won't tell you what an RZ29 is/was, and even if it did you willH likely find several matches anyway.  If you have a half-height disk (wasG there such an RZ29 variant ?), it will be an ST1xxxxN device, otherwiseoC ST3xxxxN.  The "family" numbers, Barracuda 2/4/9 etc, relate to theyC maximum capacity in Gb at the time the family was introduced and to G further help the family suffix indicates the profile.  The xxxx numbersmE are the formatted or unformatted capacity of the individual drives ineG each family.  Most likely you will find the information you need in themH 4/4LP/9LP range - look for models with 4xxx or 5xxx capacities for a 4Gb drive.  G I have two, but they are completely different jumper-wise and I can see % further variants on the Seagate site.a     	Johnh -- h
 John Laird Yezerski Roper Ltd   ------------------------------   Date: 4 Dec 2001 14:03:00 GMTe- From: forkosh@panix1.panix.com (John Forkosh)l0 Subject: Re: Jumpers for rz29-labelled barracuda) Message-ID: <9uil2k$2d3$1@news.panix.com>a  5 John Laird (john@laird-towers.freeserve.co.uk) wrote:z0 : forkosh@panix1.panix.com (John Forkosh) wrote:0 : >I have several 4.3GB rz29 Seagate Barracudas,1 : >narrow 50-pin, but can't figure out how to set 1 : >scsi id (Google search and seagate.com were noy	 : >help).i  C : Odd - I've always found Seagate's pages to be absolutely spot-on.s : You need to be looking iniA : http://www.seagate.com/support/disc/specs/family_barracuda.htmlr  > Mea culpa, missed that page while searching/browsing the site.> As you said, "spot-on."  My drive turns out to be an st15150n.9 The page for it couldn't have provided better informationi9 even if they'd personally asked me what I wanted and theneA designed the page accordingly.  Thanks so much for pointer, John.  John (forkosh@panix.com)   ------------------------------  % Date: Tue, 04 Dec 2001 14:29:12 +0000v4 From: John Laird <john@laird-towers.freeserve.co.uk>0 Subject: Re: Jumpers for rz29-labelled barracuda8 Message-ID: <ivmp0uku8tvl4ohse85po2jl0e142ustdv@4ax.com>  C On 4 Dec 2001 14:03:00 GMT, forkosh@panix1.panix.com (John Forkosh)s wrote:  6 >John Laird (john@laird-towers.freeserve.co.uk) wrote:1 >: forkosh@panix1.panix.com (John Forkosh) wrote:o1 >: >I have several 4.3GB rz29 Seagate Barracudas, 2 >: >narrow 50-pin, but can't figure out how to set2 >: >scsi id (Google search and seagate.com were no
 >: >help). >tD >: Odd - I've always found Seagate's pages to be absolutely spot-on. >: You need to be looking inB >: http://www.seagate.com/support/disc/specs/family_barracuda.html > ? >Mea culpa, missed that page while searching/browsing the site.e? >As you said, "spot-on."  My drive turns out to be an st15150n.C: >The page for it couldn't have provided better information: >even if they'd personally asked me what I wanted and thenB >designed the page accordingly.  Thanks so much for pointer, John.  G You're welcome.  You have an early Barracuda there.  Half-height, zippysH and a fine source of heat if it is anything like mine :-)  I worried forE a while and then figured it was sat in the best possible place, rightaH next to a fan and in a fairly empty enclosure.  (Much better layout thanB a typical AT case or even an AS200 where the air is optimisticallyE expected to meander a strange course between inlet and outlet vents.)i  F As you mentioned RZ29 specifically, I'd guess this drive will actuallyH work - I got a non-DEC version which wouldn't play ball easily on AlphasH as its TCQ implementation was badly broken.  (Fixed by patching DKDRIVER with the help of gurus here...)s     	JohnD -- 5
 John Laird Yezerski Roper Ltd   ------------------------------  % Date: Tue, 04 Dec 2001 09:54:05 +0000f4 From: John Laird <john@laird-towers.freeserve.co.uk> Subject: Linus' view on VMS 8 Message-ID: <mg6p0ukeekdrfn1l915oavee20sa9ul4fs@4ax.com>  ? [There is not much levity in this ng at the moment, forgive thewE diversion from conspiracy theories and the exact timing of the end ofo the world.]   G Picked up Linus Torvalds' book "Just for Fun" in the library yesterday.mC I've not read it all yet, but "just for fun" I looked up VMS in theo% index.  He was not impressed in 1990:h  D "It was a horrible operating system..."  "It was hard to use."  "You1 couldn't easily figure out how large a file was."r  E What a choice, then:  a world dominated by a system based on a kernellH written by a nerd (although the majority seem to think he rewrote all ofD some Unix) who thinks VMS is hard to use and its rich feature set isC "ugly", versus a world dominated by a system based on a half-inchedo> glorified disk driver acquired by another nerd who is decidelyG megalomaniac (or surrounds himself by such) but who was savvy enough ton/ get one of the primary VMS architects on-board.e  F I used to work with someone who said, in gloomier moments, "I'd ratherG be digging holes in the road".  Slowly, I am beginning to see his points :-)a   -- t
 John Laird Yezerski Roper Ltd   ------------------------------  $ Date: Tue, 4 Dec 2001 12:06:04 -00008 From: John Macallister <J.Macallister1@physics.ox.ac.uk> Subject: RE: Linus' view on VMShN Message-ID: <35666012DF4CD411BE940090279FA240010BF132@ppnt41.physics.ox.ac.uk>  H >Picked up Linus Torvalds' book "Just for Fun" in the library yesterday.D >I've not read it all yet, but "just for fun" I looked up VMS in the& >index.  He was not impressed in 1990:  L Anyone who could say, in 1990 or earlier, that VMS was hard to use must haveI had a very limited experience of other operating systems. My own guess onCI Linus' OS experience is that he's had eperience of many OS's, all of themrI different flavours of UNIX. I'd even hazard a guess and suggest that mostoE proponents of UNIX have no real experience of non-UNIX systems. For a G non-UNIX expert UNIX is probably one of the most difficult OS's to use.e   John    B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.uk= Post: Denys Wilkinson Building, Keble Road, Oxford OX1 3RH,UKbA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)m   ------------------------------  % Date: Tue, 04 Dec 2001 12:26:17 +0000s4 From: John Laird <john@laird-towers.freeserve.co.uk> Subject: Re: Linus' view on VMSP8 Message-ID: <7nfp0uchaovpi4los6ok8oa975muhkf7ts@4ax.com>  3 On Tue, 4 Dec 2001 12:06:04 -0000, John Macallisters( <J.Macallister1@physics.ox.ac.uk> wrote:  I >>Picked up Linus Torvalds' book "Just for Fun" in the library yesterday.eE >>I've not read it all yet, but "just for fun" I looked up VMS in thet' >>index.  He was not impressed in 1990:p > M >Anyone who could say, in 1990 or earlier, that VMS was hard to use must havenJ >had a very limited experience of other operating systems. My own guess onJ >Linus' OS experience is that he's had eperience of many OS's, all of themJ >different flavours of UNIX. I'd even hazard a guess and suggest that mostF >proponents of UNIX have no real experience of non-UNIX systems. For aH >non-UNIX expert UNIX is probably one of the most difficult OS's to use.  E I couldn't agree more with your last statement.  With a mere 20 yearslF experience, I still dread having to do anything on our Linux firewall,D and various GUIs haven't improved matters much - it's still a tussle with man and the howtos.  D  [My last head-banging experience was trying to empty the mail spoolG directory of thousands of bounced messages - it has apparently occurredaH to no-one to document the fact that rm is real picky about its input andE won't accept a piped-in list, if I remember rightly.  And here was meiH thinking this wonderful bag of tools would do anything *I asked it to*.]     	Johno   ------------------------------  $ Date: Tue, 4 Dec 2001 09:13:27 -0500( From: "Daniel P Allen" <dallen@nist.gov> Subject: RE: Linus' view on VMSs: Message-ID: <PHECLHHFDGKPFDHKILFNGEKDCAAA.dallen@nist.gov>   	John,   	Which "rm" ;-)e   -----Original Message-----; From: John Laird [mailto:john@laird-towers.freeserve.co.uk]a( Sent: Tuesday, December 04, 2001 7:26 AM To: Info-VAX@Mvb.Saic.Com  Subject: Re: Linus' view on VMS     3 On Tue, 4 Dec 2001 12:06:04 -0000, John Macallisteri( <J.Macallister1@physics.ox.ac.uk> wrote:  I >>Picked up Linus Torvalds' book "Just for Fun" in the library yesterday.nE >>I've not read it all yet, but "just for fun" I looked up VMS in the ' >>index.  He was not impressed in 1990:C >aH >Anyone who could say, in 1990 or earlier, that VMS was hard to use must haveJ >had a very limited experience of other operating systems. My own guess onJ >Linus' OS experience is that he's had eperience of many OS's, all of themJ >different flavours of UNIX. I'd even hazard a guess and suggest that mostF >proponents of UNIX have no real experience of non-UNIX systems. For aH >non-UNIX expert UNIX is probably one of the most difficult OS's to use.  E I couldn't agree more with your last statement.  With a mere 20 years F experience, I still dread having to do anything on our Linux firewall,D and various GUIs haven't improved matters much - it's still a tussle with man and the howtos.  D  [My last head-banging experience was trying to empty the mail spoolG directory of thousands of bounced messages - it has apparently occurreddH to no-one to document the fact that rm is real picky about its input andE won't accept a piped-in list, if I remember rightly.  And here was me H thinking this wonderful bag of tools would do anything *I asked it to*.]     	John    ------------------------------  $ Date: Tue, 4 Dec 2001 06:17:50 -0800# From: "Tom Linden" <tom@kednos.com>o Subject: RE: Linus' view on VMS 9 Message-ID: <CIEJLCMNHNNDLLOOGNJICENKDKAA.tom@kednos.com>p  C Actually,  Linus' contribution wasn't in advancing the state of thenC art in OS kernels, but in creating a worldwide development movementh   > -----Original Message-----= > From: John Laird [mailto:john@laird-towers.freeserve.co.uk]n* > Sent: Tuesday, December 04, 2001 1:54 AM > To: Info-VAX@Mvb.Saic.Comf > Subject: Linus' view on VMSq >  > A > [There is not much levity in this ng at the moment, forgive theeG > diversion from conspiracy theories and the exact timing of the end ofl
 > the world.]  > I > Picked up Linus Torvalds' book "Just for Fun" in the library yesterday.CE > I've not read it all yet, but "just for fun" I looked up VMS in theh' > index.  He was not impressed in 1990:i > F > "It was a horrible operating system..."  "It was hard to use."  "You3 > couldn't easily figure out how large a file was."i > G > What a choice, then:  a world dominated by a system based on a kernelcJ > written by a nerd (although the majority seem to think he rewrote all ofF > some Unix) who thinks VMS is hard to use and its rich feature set isE > "ugly", versus a world dominated by a system based on a half-inchede@ > glorified disk driver acquired by another nerd who is decidelyI > megalomaniac (or surrounds himself by such) but who was savvy enough tob1 > get one of the primary VMS architects on-board.y > H > I used to work with someone who said, in gloomier moments, "I'd ratherI > be digging holes in the road".  Slowly, I am beginning to see his pointK > :-)n >  > --   > John Laird > Yezerski Roper Ltd >    ------------------------------   Date: 4 Dec 2001 14:26:15 GMT 1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)w Subject: RE: Linus' view on VMSt, Message-ID: <9uime7$1mj5$2@info.cs.uofs.edu>  N In article <35666012DF4CD411BE940090279FA240010BF132@ppnt41.physics.ox.ac.uk>,;  John Macallister <J.Macallister1@physics.ox.ac.uk> writes:l |>O |> Anyone who could say, in 1990 or earlier, that VMS was hard to use must havei= |> had a very limited experience of other operating systems.    G Being as he was still just a student when he wrote Linux, I would guessaF his total experience up to that point was probably Unix and a PeeCees.  M |>                                                            My own guess ongL |> Linus' OS experience is that he's had eperience of many OS's, all of them |> different flavours of UNIX. s  L Nobody who uses Unix considers the different flavors to be "many OSes".  AndG from the users standpoint, the differences are really pretty trivial.   / Differences in obscure and little used oprions.r  M |>                              I'd even hazard a guess and suggest that most C |> proponents of UNIX have no real experience of non-UNIX systems. m  H If your talking about Linux kiddies, your probably right, but if you areG talking about anyone who has been in this businees for 20 years or moreIH (which takes you back to the time when there actually were other OSes to) choose from) you would probably be wrong.a  I |>                                                                  For arJ |> non-UNIX expert UNIX is probably one of the most difficult OS's to use.  O And for a non-VMS expert VMS is probably one of the most difficult OS's to use. N And for a non-CMS expert CMS is (was?) probably one of the most difficult OS's to use.eM And for a non-PRIMOS expert PRIMOS is probably one of the most difficult OS'sd to use. * etc. etc. etc. etc.  Mother duck syndrome.   bill   -- sJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   p   ------------------------------  $ Date: Tue, 4 Dec 2001 16:26:14 -00008 From: John Macallister <J.Macallister1@physics.ox.ac.uk> Subject: RE: Linus' view on VMSuN Message-ID: <35666012DF4CD411BE940090279FA240010BF133@ppnt41.physics.ox.ac.uk>  K > |>                                                                  For alL > |> non-UNIX expert UNIX is probably one of the most difficult OS's to use.  L > And for a non-VMS expert VMS is probably one of the most difficult OS's to use.  L It's always been true with VMS that a new user could start doing useful workC within a few minutes of being shown a few basic commands e.g. edit, J "compile", link, run, print. With UNIX, even today, you would have troubleH finding an editor that was "safe" even after several hours of work. WithL UNIX it's always a case of "use it or lose it" : once you've learned a trickD or too they're easily forgotten if not used every day because of the7 arbitrary, even bizarre, nature of many things in UNIX.c   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.uk= Post: Denys Wilkinson Building, Keble Road, Oxford OX1 3RH,UKnA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)w          ------------------------------  $ Date: Tue, 4 Dec 2001 13:05:27 -0500 From: kat <kathee@mindiq.com>n Subject: Re: Linus' view on VMSh8 Message-ID: <20011204180527.B110639AC0@kauai.mindiq.com>  H Let's not turn this into an OS war.  Anyone couldeasily list pluses and N minuses for every OS, (including windows)... Of course this list favors VMS.  K I work with VMS (since 1.1) and Unix (wrote drivers for 4.2 BSD on VAXen!) (K and windows since the dawn of dirt.  They all have good and bad points and -- things like this are really meaningless here.0   Just my 2 cents  Kat   = On Tuesday 04 December 2001 11:26 am, John Macallister wrote:eM > > |>                                                                  For a@I > > |> non-UNIX expert UNIX is probably one of the most difficult OS's too > > |> use.  > >hK > > And for a non-VMS expert VMS is probably one of the most difficult OS'so > > to >e > use. >dI > It's always been true with VMS that a new user could start doing usefulyJ > work within a few minutes of being shown a few basic commands e.g. edit,L > "compile", link, run, print. With UNIX, even today, you would have troubleJ > finding an editor that was "safe" even after several hours of work. WithH > UNIX it's always a case of "use it or lose it" : once you've learned aL > trick or too they're easily forgotten if not used every day because of the9 > arbitrary, even bizarre, nature of many things in UNIX.  >t > John >dD > Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.uk? > Post: Denys Wilkinson Building, Keble Road, Oxford OX1 3RH,UKoC > Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)i   ------------------------------  % Date: Tue, 04 Dec 2001 10:16:35 -0800 ' From: David Mathog <mathog@caltech.edu>d Subject: Re: Linus' view on VMSf+ Message-ID: <3C0D1303.714055AE@caltech.edu>l   John Laird wrote:h  >  He was not impressed in 1990: > F > "It was a horrible operating system..."  "It was hard to use."  "You3 > couldn't easily figure out how large a file was."b  H Old Linus just dropped about 5 pegs in my estimation.  I can forgive the firstcD two statements since they are completely subjective but the third is simply ridiculous.C It usually takes even the dimmest Unix user only a minute or two tom realize that DIR hH is used instead of ls on VMS, and then it's a complete no brainer to get toG HELP DIR to see what the command line options are for that command.  In  fact, on RH 6.2 G (and for all I know all other Linuxes) there's actually a "dir" commandp which acts just-
 like "ls".  G Maybe he meant figure out how large a file was inside a DCL procedure? m In that caseH the learning curve is very slightly steeper since you had to know enough
 to use the proper lexical function.  D Or if he meant from within C then he may have had a case - the VAX C compiler of that era2 was pretty crappy.  Not an OS issue per se though.  F All that said, there was not then, and is not now, any document in the land of UnixF remotely as complete and useful as the VMS User's and System Manager's manuals.  I'm givingG Linux the benefit of the doubt and assuming that he never had access top either one.r   Regards,   David Mathog mathog@caltech.edu   ------------------------------   Date: 4 Dec 2001 12:31:54 -0600n+ From: young_r@encompasserve.org (Rob Young)l Subject: Re: Linus' view on VMSt3 Message-ID: <ANJ9GQRIQfLd@eisner.encompasserve.org>d  U In article <3C0D1303.714055AE@caltech.edu>, David Mathog <mathog@caltech.edu> writes:k > John Laird wrote:-! >>  He was not impressed in 1990:  >> 0G >> "It was a horrible operating system..."  "It was hard to use."  "You.4 >> couldn't easily figure out how large a file was." > J > Old Linus just dropped about 5 pegs in my estimation.  I can forgive the > firstTF > two statements since they are completely subjective but the third is > simply ridiculous.E > It usually takes even the dimmest Unix user only a minute or two to> > realize that DIR rJ > is used instead of ls on VMS, and then it's a complete no brainer to get > toI > HELP DIR to see what the command line options are for that command.  Inv > fact, on RH 6.2aI > (and for all I know all other Linuxes) there's actually a "dir" command: > which acts justu > like "ls". > I > Maybe he meant figure out how large a file was inside a DCL procedure? s > In that caseJ > the learning curve is very slightly steeper since you had to know enough > to use the > proper lexical function. >   C 	Having fought almost all the Unix wars there was/is to fight, I'veeD 	seen this battle before too.  Not knowing exactly what Linus meant,@ 	he might just be referring to dir/size and dir/size=all... Unix 	doesn't have that ambiguity.    	Here is kilobytes and bytes:i  	 	$ ls -lsl  @ 1072 -rw-r--r--   1 root     system   1094925 Aug 21 15:56 a.zip  # 	1072 kilobytes and 10494925 bytes.s  0 	In VMS, how many blocks are you *really* using?   	$ dire/date/size=allocated   = L.L;44                     0/0        28-NOV-2001 15:11:05.47t= L.L;43                     2/17       28-SEP-2001 16:21:45.91 = L.L;42                     2/17       28-SEP-2001 16:18:53.42w  ? 	Two or 17?  Well 17 actually... well then you better make sure 1 	you look at allocated blocks then!  How pitiful!h  A 	You get second hand stories from frightened Unixphiles that haveR@ 	had to actually log on and use a VMS system and often they best6 	they can come up with is some screwy snipe.  Figures.   				Robo   ------------------------------  $ Date: Tue, 4 Dec 2001 11:48:17 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> B Subject: Re: Microsoft Pyramid Collapses Enron and Hewlett Packard1 Message-ID: <ka7P7.116$BK1.2880@news.cpqcorp.net>   < Jerry Leslie wrote in message <9ugotr$ons$3@joe.rice.edu>...   snip  E >One of the more recent entries on that thread paints a scary picturen9 >of the Southern MA & NH area (URL wrapped to two lines):o >aG >   http://www.netslaves.com/cgi-bin/yabb/YaBB.pl?action=display&board=h$ >   005&num=1007032630&start=105#114 >t >   Posted by slamitbobbya >s0 >   Re: Happy Anniversary: One Year Without Work >h     snip  C His resume must be 4 pages of rubbish, he interviews bad, or he hasuH unrealistic expectations (perhaps he wants too much money).  For all theJ downsizing that has occured, the MA/NH area still has jobs for people withB the right skills.  Heck, someone (who occasionally  writes in this1 conference) started work *here* in VMS yesterday.c  K The truth is that trying to get a job via cold interviews is hard.  Usually,I your next job comes from the contacts that you make along the way... or a  good job search consultant.n   ------------------------------   Date: 4 Dec 2001 04:00:23 -0800 % From: mb301@hotmail.com (Mark Bowman)oY Subject: Openvms support for another 25 years! Does anyone know what this pact is called?-< Message-ID: <1d08b916.0112040400.2ba9ae4@posting.google.com>  M It would appear that Compaq have entered into some sort of pack with various aA military and governments to support Openvms for another 25 years.n$ Does anyone know anything about it.?   Mark   ------------------------------   Date: 4 Dec 2001 12:05:44 -0000m= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>eY Subject: Re: Openvms support for another 25 years! Does anyone know what this pact is calt6 Message-ID: <20011204120544.30938.qmail@gacracker.org>  5 On 4 Dec 2001, mb301@hotmail.com (Mark Bowman) wrote: N >It would appear that Compaq have entered into some sort of pack with various B >military and governments to support Openvms for another 25 years.% >Does anyone know anything about it.?a >k >Mark   J DII-COE (Defense Information Infrastructure Common Operating Environment).   Seee  K http://www.openvms.compaq.com/presentations/cets2001/cets2001-1042_diicoe_fe iles/cets2001-1042_diicoe.ppt0   URL will need unwrapped.     Doc. -- e6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.net0   ------------------------------  % Date: Tue, 04 Dec 2001 18:17:41 +0100i1 From: John McLean <mcleanj@swissonline.delete.ch>lY Subject: Re: Openvms support for another 25 years! Does anyone know what this pact is cal 5 Message-ID: <3C0D0535.4EA33077@swissonline.delete.ch>h   Mark Bowman wrote: > N > It would appear that Compaq have entered into some sort of pack with variousC > military and governments to support Openvms for another 25 years. & > Does anyone know anything about it.? >  > Mark    G Does that mean that Compaq promises not to lose the documentation untile then ???     John McLeanp   ------------------------------  $ Date: Tue, 4 Dec 2001 09:05:29 -05000 From: "Syltrem" <syltrem@videotron.spammenot.ca> Subject: Re: Oracle problems.e4 Message-ID: <IE4P7.2118$Q06.15749@tor-nn1.netcom.ca>  L If this database is vital for your enterprise, I would strongly recommend anH upgrade, as Oracle 7.1.5 is no longer supported. You may find patches ifG it's a known problem, but other than that you'll be pretty much left tot	 yourself.   L For information (and comparison) I`ve been running Oracle 7.3.4 on VMS 7.2-1L and never had this kind of problems. I have since upgraded Oracle to 8.0.5.1K then 8.1.6.0 and all versions were stable enough (save for one or two thingd# not related to your current issue).J  I By the way you put this you seem not to be very familiar with Oracle ("As0H far as I am aware it is using Oracle 7.1.5 "). Have a look at your alertL log. It may contain some information pertaining to the error. Also check for( trace files. These should be located in:K Trace files = ORA_ROOT:[DB_sid.TRACE]*.TRC (possibly many files; none if noa errors occurred)> Alert log = ORA_ROOT:[DB_sid.TRACE]*ALERT*.LOG (always 1 file)   sid is you database name.0   HTH6 --   Syltrem I http://pages.infinit.net/syltrem (OpenVMS related web site - en franais) > To reply to myself directly, remove .spammenot from my address  I "David J. Dachtera" <djesys.nospam@fsi.net> a crit dans le message news:e 3C0C5050.9C4F1828@fsi.net... > Hoff Hoffman wrote:a > > E > > In article <9uh0g8$7kk$1@newsg1.svr.pol.co.uk>, "Leigh G. Bowden"e+ <LGBowden@bowdenfamily.fsnet.co.uk> writes:wK > > :We have an AlphaServer 2100 4/200 with two CPU's and 1GB of memory andl$ > > :plenty of disks - all shadowed. > >eK > >   That's a comparitively old and slow EV4-class Alpha platform, and onep@ > >   gigabbyte of main memory is comparatively small by current
 configurationm > >   standards. > >sF > > :As far as I am aware it is using Oracle 7.1.5 on OpenVMS 6.2 AXP. > > H > >   You will want to confirm this, since this version information willJ > >   be central to most of the subsequent research that is required here.L > >   Your version of OpenVMS Alpha lacks various of the enhancements aroundJ > >   sixty-four bit addressing that were added for V7.0, and thus has theI > >   VAX limitations around stuffing most everything of consequence intopJ > >   the S0 and S1 space (2TB) address range -- this probably likely willI > >   not help with the apparent leak reported here, but I've encountered]K > >   numerous Alpha (pre-V7) systems with the resulting addressing limits.: > >8J > > :It appears to be unreliable. After about three weeks this system will lockL > > :up and the console will report "Insufficient memory for operation" type > > :errors' > >aF > >   You will want to get the specific error message, not the type ofG > >   message.  (No offense is intended.)  There are many similar erroriJ > >   messages, and the specific and full error message text is invaluableF > >   evidence when determining the details of the particular problem.H > >   Abbreviations or any other alterations to the reported text shouldI > >   be carefully avoided, given the likelyhood these changes will served# > >   only to introduce ambigiuity.  > > K > > :...and will allow nobody to logon even at the console. The only way toa' > > :get out of this to power cycle it.S > >hI > >   This initially appears to be a memory leak, either in OpenVMS or inaK > >   the database software.  You will want to apply the mandatory ECO kitswI > >   for OpenVMS Alpha, and you will want to check with Oracle (classic,sK > >   I assume, since that is not an Rdb version) for any database patches,iJ > >   and you will want to configure a sufficiently large system crashdumpI > >   file and learn how to force an OpenVMS system crash from the system  > >   console. >rH > Sounds familiar! Like Hoff said, check for patches - VMS *AND* Oracle!C > If memory serves (and it frequently doesn't), this may be a knownn > problem with a fix available.n >a > -- > David J. Dachteraw > dba DJE Systemsd > http://www.djesys.com/ >a* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/K   ------------------------------  $ Date: Tue, 4 Dec 2001 10:52:53 -0500- From: "Peter Weaver" <peter.weaver@stelco.ca>1 Subject: Re: Oracle problems.u3 Message-ID: <Tj6P7.69396$Z2.1019213@nnrp1.uunet.ca>o  F "Leigh G. Bowden" <LGBowden@bowdenfamily.fsnet.co.uk> wrote in message) news:9uh0g8$7kk$1@newsg1.svr.pol.co.uk...hH > We have an AlphaServer 2100 4/200 with two CPU's and 1GB of memory andI > plenty of disks - all shadowed. As far as I am aware it is using Oracle  > 7.1.5 on OpenVMS 6.2 AXP.  >iL > It appears to be unreliable. After about three weeks this system will lockI > up and the console will report "Insufficient memory for operation" type L > errors and will allow nobody to logon even at the console. The only way to$ > get out of this to power cycle it. >gI > Has anybody experienced this before and got any suggestions for a fix??h  K I do not know if this will help or not, but it sounds like a problem we hadeJ with an old version or Oracle (I don't think it was 7.1.5, but it may haveJ been). Make sure you take a look at what the procedure is doing and run itI in test mode (i.e.  comment out the actual deassign and double check thatgL the table the .COM wants to deassign is actually no longer in use before youK let the job run completely) since I do not know what versions of VMS/Oracleu we had had this problem on.o       --J A study has shown that sheep can remember faces for up to 2 years, I guess- that means I'm dumber than the average sheep.o! CLEANUP_ORACLE_LNM_GARBAGE.COM;18      $! $!5 $ command_procedure = "''f$environment("procedure")'"  $ command_procedure = -tD "''command_procedure'" - "''F$PARSE(COMMAND_PROCEDURE,,,"VERSION")'"> $ submit/after="00:00+7-00:00"/keep/noprint 'command_procedureF $ log_file = "''f$parse("sys$login:",".log",command_procedure)'" - ";" $ purge 'log_file /keep=2n $! $ set noverify $!- $ show log/table=lnm$system_directory TNS_* -O2 /output=sys$scratch:cleanup_oracle_lnm_garbage.dat
 $ set noon $! close xfile $!) $ SAVE_MESSAGE = F$ENVIRONMENT("MESSAGE")a; $ SET MESSAGE/NOFACILITY/NOIDENTIFICATION/NOSEVERITY/NOTEXTe $!= $ open /read xfile sys$scratch:cleanup_oracle_lnm_garbage.datn $ read xfile first_line  $ read xfile second_line $ read xfile third_line- $loop:' $ read/error= exit_path xfile next_line-( $ log_table = f$elem (2, " ", next_line) $ pid = log_table - "TNS_"$ $ write sys$output "Checking ''pid'" $!< $ if f$getjpi("%X''pid'","USERNAME") .nes. "" then goto loop- $ write sys$output "Deassigning ''log_table'"  $!6 $ deassign /user/table=lnm$system_directory 'log_table $ goto loop  $ exit_path: $ SET MESSAGE'SAVE_MESSAGE'  $!
 $ close xfilexE $ delete/nolog/noconfirm sys$scratch:cleanup_oracle_lnm_garbage.dat;*w $ exit   ------------------------------  # Date: Tue, 04 Dec 2001 07:28:05 GMTwL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")T Subject: Re: Q: Tool or script to remove nonprinting characters from a SET HOST log?8 Message-ID: <00A05FDA.9F742F64@SSRL04.SLAC.STANFORD.EDU>  [ In article <3C0C4D7D.FF47DEC0@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  >Nic Clews wrote:a >> a- >> Alan Winston - SSRL Admin Cmptg Mgr wrote:m >> > >> > Comp.os.vmsers -- >> >M >> > I remember vaguely reading something about a tool or script specificallykB >> > designed to clean up the log files you get from SET HOST/LOG. >> iG >> Umph, a quick and dirty way is to use EDT and create a listing file.- >> - >> From command line mode: >> : >> SET NONUMBERS >> PRINT filespec.LIS  >j* >Yeah - that's what I was gonna suggest... >1  I I think I was inadequately clear.  I wanted the nonprint characters to go 7 away rather than be replaced with symbolic equivalents.S   -- Alang  O ===============================================================================x0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056kM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================    ------------------------------   Date: 4 DEC 2001 15:52:07 GMTe+ From: Dave Greenwood <greenwoodde@ornl.gov> T Subject: Re: Q: Tool or script to remove nonprinting characters from a SET HOST log?1 Message-ID: <4DEC01.15520727@feda01.fed.ornl.gov>s  M winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") wrote:i] > In article <3C0C4D7D.FF47DEC0@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:W > >Nic Clews wrote:  > >> l/ > >> Alan Winston - SSRL Admin Cmptg Mgr wrote:e > >> > > >> > Comp.os.vmsers -- > >> >O > >> > I remember vaguely reading something about a tool or script specifically D > >> > designed to clean up the log files you get from SET HOST/LOG. > >> rI > >> Umph, a quick and dirty way is to use EDT and create a listing file.  > >>   > >> From command line mode: > >> h > >> SET NONUMBERS > >> PRINT filespec.LISi > >e, > >Yeah - that's what I was gonna suggest... > >3 >  iK > I think I was inadequately clear.  I wanted the nonprint characters to go 9 > away rather than be replaced with symbolic equivalents.<  E Below my sig are two messages I've saved from 1995.  I tried both the1I CONVERT and TPU methods on a sample SETHOST.LOG file and rather preferrednG the latter.  It didn't get every non-printable character but the resulte was very readable. YMMV.   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVsH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself  , ============================================    From: IN%"lambn@cbr.hhcs.gov.au" Date: 16-FEB-1995  15:29:09rE Description: RE: Logging/printing a session                          '  . Message sent: Thu, 16 Feb 1995 14:26:16 +1000.  { In article <950210005245_76702.1567_CHN69-1@CompuServe.COM>, "Richard B. Gilbert [VAX]" <76702.1567@compuserve.com> writes:t" > 	PSILVA1@eos.bentley.edu writes: >>> >>I am going to be doing a presentation next week on the topic; >>of the internet.  My internet access is through a VAX.  I = >>had hoped to show the class some print-outs of my exploits,  >>so I did this: >>7 >>        $ set host 0/log=interesting_presentation.txt  >>< >>I was hoping that this would log my session and provide me< >>with some output to show the class.  I am able to type the9 >>file, but when I edit it, there are quite a few specialy< >>characters in it.  magine my suprise!  Is there a VAX guru: >>out there who knows how I can translate this file into a< >>printable file?  Does anyone know of a way to get the file? >>close to readable?  (I don't mind working on it in an editor,-8 >>if I could just get it close).  Is there another, more% >>sophisticated way to log a session?R >> >sF > 	I recall reading of a trick with a little known editor called TECO.M > I believe I even tried it once.  Make a COPY of your file before you start;r$ > I am relying on memory alone here. >n+ > $ EDIT /TECO INTERESTING_PRESENTATION.TXTr > E$$p >tO > The $$ represents two escape characters (that is how they should echo).  TECOaL > loads the file and then saves it, minus the <cr><lf>.  I think it may kill6 > some or all of the other control characters as well. >rF > 	Be SURE to make a copy first.  One of the standing jokes about TECO3 > is "guess what it will do if you type your name!"r >oA > 	It has also been said "Unix is multi-user TECO" (John Dvorak).n >' > --K > *************************************************************************nK > *                        Here, there be dragons!                        *tK > *                      76702.1567@CompuServe.Com                        *sK > *                                                                       *rE > *	I'm job hunting.  Any offers or leads will be appreciated.      *cK > * I'm looking for something in central NJ or eastern PA.  Thanks!       *vK > *                                                                       *bK > *                                                Richard B. Gilbert     *eK > *************************************************************************  >H    M One easy way of stripping non-printable characters is to use the attached tpu K command file STRIP.TPU. Place it in your working directory and invoke it at,3 the DCL prompt, i.e. to clean up a file, junk.txt :a  '  $ edit/tpu/command=strip.tpu junk.txt.   N This will clean out most of the crap from a set host session, what remains canM easily be edited. I think this command file originally came from Digital CSC.:     procedure strip    on_error if error<> tpu$_strnotfound  then return;u endif; endon_error;   begin_value := 32; last_of_good_chars := 127; end_value := 256;n   srch_counter1 := 0;R loop.        exitif srch_counter1 = begin_value - 1;      loopt>         rng1 := search (ascii(srch_counter1), forward, exact);         exitif rng1 = 0;         position (rng1);         erase (rng1);5      endloop;   +         srch_counter1 := srch_counter1 + 1;j          position (buffer_begin);   endloop;  $ srch_counter2 := last_of_good_chars; loop  (        exitif srch_counter2 = end_value;      loop   >         rng2 := search (ascii(srch_counter2), forward, exact);         exitif rng2 = 0;         position (rng2);         erase (rng2);e      endloop;t  +         srch_counter2 := srch_counter2 + 1;m          position (buffer_begin);   endloop;
 endprocedure;7 strip;# exit;    ! to terminate TPU sessiont  , ============================================  ( From: IN%"vandenheuvel@eps.enet.dec.com" Date: 18-JAN-1995  11:41:34nE Description: RE: SET HOST/LOG                                        o  . Message sent: Wed, 18 Jan 1995 10:44:12 +0000.    ` In article <3fj0sn$q74@gap.cco.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes... >In article <95011709142217@vax.livjm.ac.uk>, S.R.REECE@liverpool-john-moores.ac.uk (No one hears me cryin, they don't see the man behind closed doors. Do I pay the price for hiding all that you were looking for?) writes: K >=Regarding SET HOST/LOG and the difference between what appears during the M >=session and what goes into the file, we have similar problems here at LJMU.v :s  D Admittedly I have not followed this discussion and have note studiedC the problem in detail. I do seem to recall however that the biggestwI problem with the set host log output is the presence of CR-LF comibations E where a line break is expected. Well, there is a silly, but effectives way to deal with that using: 	 8 	$convert/fdl=sys$input sethost.log sethost.fixed_middle 	record; format stream;  	$  B This will strip leading zeroes (goodness against DCL prompts!) andE terminate any record it found with CR-LF. At this point 'records' andaG 'line-breaks' become one and the same. All that may be needed now is to0G convert back to VAR format. Before doign so, you may also want to striph, trailing CR's in command line records using:  B 	$convert/fdl=sys$input sethost.fixed_middle sethost.fixed_endings!         record; format stream_cr;i@         $convert/fdl=sys$input sethost.fixed_endings sethost.txt 	record; format varn 	$  9 Ayup, that is 3 image activations. Still, it is likely tos< be much faster then any DCL procedure on a decend sized log.    A Hope this helps someone,	+--------------------------------------+bF Hein van den Heuvel, Digital.	| All opinions expressed are mine, and |C   "Makers of VMS and other	| may not reflect those of my employer | D    fine Operating Systems."	+--------------------------------------+   ------------------------------  $ Date: Tue, 4 Dec 2001 12:43:40 -0500- From: "Peter Weaver" <peter.weaver@stelco.ca>-T Subject: Re: Q: Tool or script to remove nonprinting characters from a SET HOST log?3 Message-ID: <LX7P7.69430$Z2.1019935@nnrp1.uunet.ca>   5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messagem# news:3C0B67AF.1F7BEB31@127.0.0.1...n > ...a@ > Lets see 10 billion explanations of how TPU could do it... :-) >...H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>C wrote in message news:00A05FDA.9F742F64@SSRL04.SLAC.STANFORD.EDU...m >...K > I think I was inadequately clear.  I wanted the nonprint characters to gog9 > away rather than be replaced with symbolic equivalents.a >...  K OK, I see Dave Greenwood has TPU entry #1, but I don't think that satisfiese5 Alan's requirement. Here is entry #2 of 10 billion :)     Alan; 1) watch the line wrappingL          2) you can create more PAT5, PAT6... and call REMOVE_NONPRINTING as required:          3) First build the section file using the commandF "EDIT/TPU/NOSECTION/COMMAND=REMOVE_NONPRINTING/NODISPLAY" then use theK section file using the command "edit/tpu/section=prw$utl:REMOVE_NONPRINTING  logfilename"   --J A study has shown that sheep can remember faces for up to 2 years, I guess- that means I'm dumber than the average sheep.1 remove_nonprinting.tpu PROCEDURE tpu$init_procedure ;  3 input_file := GET_INFO(COMMAND_LINE, 'file_name') ; 2 main_buffer := CREATE_BUFFER('main', input_file) ;   esc_char := ASCII(27) ;*# boldtxt := FAO("!AS[1m",esc_char) ;a! norm :=  FAO("!AS[0m",esc_char) ;_   count := 0 ;   ctrl_char_str  :=sK                 ASCII   (0)  +  ASCII   (1)  +  ASCII   (2)  +  ASCII   (3)i +nK                 ASCII   (4)  +  ASCII   (5)  +  ASCII   (6)  +  ASCII   (7)d +cK                 ASCII   (8)                  +  ASCII  (10)  +  ASCII  (11)f +nK                 ASCII  (12)  +  ASCII  (13)  +  ASCII  (14)  +  ASCII  (15)m +wK                 ASCII  (16)  +  ASCII  (17)  +  ASCII  (18)  +  ASCII  (19)o +nK                 ASCII  (20)  +  ASCII  (21)  +  ASCII  (22)  +  ASCII  (23)  +0>                 ASCII  (24)  +  ASCII  (25)  +  ASCII  (26)  +L                 ASCII  (28)  +  ASCII  (29)  +  ASCII  (30)  +  ASCII  (31);   numbers := any('0123456789;') ;a end_char := any ('HJm');   width_chars := any('346');  ' pat1 := esc_char&'['&numbers&end_char ;  remove_nonprinting (pat1);  " pat2 := esc_char&'#'&width_chars ; remove_nonprinting (pat2);    pat3 := esc_char&'('&any('0B') ; remove_nonprinting (pat3);   pat4 := any(ctrl_char_str);t remove_nonprinting (pat4);   IF count = 0    THENo0       msg_text := FAO('!ASNothing was removed in# !AS.!AS',boldtxt,input_file,norm) ;n    ELSEr3       msg_text := FAO('!ASRemoved !UL pattern!%S ini( !AS!AS',boldtxt,count,input_file,norm) ;       WRITE_FILE (main_buffer)
    ENDIF ;   MESSAGE (msg_text) ;   QUIT ;   ENDPROCEDURE  $ PROCEDURE remove_nonprinting(findit) ON_ERROR    RETURN ;o
 ENDON_ERROR ;   ' POSITION (BEGINNING_OF (main_buffer)) ;s   LOOP(    src_range := SEARCH(findit,FORWARD) ;'    POSITION (beginning_of (src_range)); (    ERASE_CHARACTER (LENGTH (src_range));    count := count + 1f  	 ENDLOOP ;y     ENDPROCEDURE  H !         This will save the PRW$UTL:REMOVE_NONPRINTING.TPU$SECTION file when  !         it is called by doing;I !               $ EDIT/TPU/NOSECTION/COMMAND=REMOVE_NONPRINTING/NODISPLAYh: !         This way we can call this program using /SECTION% !         to speed up the processing.f !e% SAVE ("prw$utl:REMOVE_NONPRINTING") ;n !r1 QUIT ;      ! This is only for the /COMMAND call.    ------------------------------  $ Date: Tue, 4 Dec 2001 09:19:42 -05002 From: "Sue Skonetski" <susan.skonetski@compaq.com>( Subject: RDB course offering for January1 Message-ID: <PW4P7.106$BK1.2674@news.cpqcorp.net>t  E Have you always wanted to know why Oracle Rdb's optimizer chooses thekK strategies it does? Would you like to be able to read Rdb's bugcheck dumps?pL Do you know how Rdb chooses the pages on which it stores new records? Do youJ know what is actually stored on a database page? If you'd like to know theL answers to these questions and dozens of others, plan to attend one of these! 2002 offerings of the popular Rdbe  . Internals course, now updated for version 7.1.  - * De Meern, Netherlands on January 7-11, 2002l  . * Nashua, New Hampshire on January 14-18, 2002  3 * Colorado Springs, Colorado on January 21-25, 2002)  D You can register for the De Meern offering or read a complete courseJ description at, www.oracle.com/nl/education/specials/index.html?sp187.html  L To register for either of the United States offerings, you must telephone anL Oracle University registrar at 800.529.0165 or 312.364.4005. Ask to registerK for class number 112181 (Colorado Springs) or class number 116180 (Nashua).DE The instructor for this course will be Mark Bradley. Mark has a greateI combination of excellent presentation skills and thorough knowledge ofthepL Rdb product. He is the author of the most recent revisions to this course. I@ hope you'll take advantage of this unique learning  opportunity.  
 Best regards,    Kevin Duffye   Oracle Rdb Development Director   C -------------------------------------------------------------------t  D You have received this message because of your business relationship  E with Oracle Rdb. If your name is on our list in error please reply to   C this message with the word "Remove" as the subject of your message.b  D If you have received multiple copies of this message or if you would  A like future mailings on Rdb to be sent to your colleagues, pleaseo  - reply to this address with your instructions.a   ------------------------------  % Date: Tue, 04 Dec 2001 18:43:50 +0010 ' From: <paddy.o'brien@zzz.tg.nsw.gov.au>h! Subject: Re: RECALL does not workt5 Message-ID: <01KBHB07AZUQ0013YX@tgmail.tg.nsw.gov.au>n   Carl Perkins wrote:y   {bits of snips}   F >}I think you will find the 20 limit went out years ago, wasnt it VMS  >5.0 ? >} n >}-- >}Chris  >d >VMS V5.5-2 had a limit of 20. > F >VMS 6.1, on Alpha at least, had a much larger limit - the same limit  as
 >now: 254. >R< >I don't know what the limit on 6.0 or the Alpha's V1.5 was.  H If my geriatric memory serves me, the official limit was still 20 until F 6.2.  I used to use Hunter's 64 recall limit, but from 6.2 on, it has C been 254.  Not sure what the actual buffer size is, but many of my s4 recalls are way less than 254 because of long lines.   Regards, Paddy     ------------------------------  % Date: Tue, 04 Dec 2001 11:20:39 +0000t% From: "a.carlini" <arcarlini@iee.org>a Subject: Re: RL02 disk drive' Message-ID: <3C0CB187.2D0A4430@iee.org>"  & pat@cart-server.purdueriots.com wrote:  G > I'm looking for documentation on the hardware of the RL02 disk drive.o  * Start at http://www.decdocs.org and trawl ' the various links. I know Maincoone hase( some RL02 schematics and the User Guide.   Antonioe   -- -   ---------------l- Antonio Carlini             arcarlini@iee.orgS   ------------------------------  $ Date: Tue, 4 Dec 2001 18:09:03 -0000% From: "Gary" <someone@btinternet.com>t$ Subject: Send() Error Buffer Problem3 Message-ID: <9uj3ao$oh8$1@plutonium.btinternet.com>l  	 Hi there,o  E I'm having a problem with send on OpenVMS v6.2 (VAX) and OpenVMS v7.1 K (Alpha).  I have investigated the problem further on v6.2 and it seems thatt the following code:-  C         int nBytesSent = send(sock->sock, buffer, nBytesToSend, 0);L  L returns a EVMSERR return code.  I have then looked at the vaxc$errorno whichI is 844 (%SYSTEM-F-IVBUFLEN, invalid buffer length), which doesn't help meD much.5  L The only thing I can think of is that there is a maximum buffer size you canG send in one call of send.  I say this because as nBytesToSend the erroraL creeps in, i.e. with only 50000 bytes it's ok, but I am trying to send 68113 bytes of data which is failing.u  I Does anyone know if there is a maximum and if so what it is?  Or where itc can be retreived?e   Thanks   Gary   ------------------------------   Date: 4 Dec 2001 12:11:44 -0600e- From: Kilgallen@SpamCop.net (Larry Kilgallen)e( Subject: Re: Send() Error Buffer Problem3 Message-ID: <ozoiHtlUeEBG@eisner.encompasserve.org>g  [ In article <9uj3ao$oh8$1@plutonium.btinternet.com>, "Gary" <someone@btinternet.com> writes:r   > Hi there,e > G > I'm having a problem with send on OpenVMS v6.2 (VAX) and OpenVMS v7.1=M > (Alpha).  I have investigated the problem further on v6.2 and it seems that@ > the following code:  > E >         int nBytesSent = send(sock->sock, buffer, nBytesToSend, 0);5 > N > returns a EVMSERR return code.  I have then looked at the vaxc$errorno whichK > is 844 (%SYSTEM-F-IVBUFLEN, invalid buffer length), which doesn't help me= > much.- > N > The only thing I can think of is that there is a maximum buffer size you canI > send in one call of send.  I say this because as nBytesToSend the errorgN > creeps in, i.e. with only 50000 bytes it's ok, but I am trying to send 68113! > bytes of data which is failing.E > K > Does anyone know if there is a maximum and if so what it is?  Or where itC > can be retreived?   B Check the documentation of the corresponding SYS$QIO call for your= TCP/IP package.  65535 is a common limit, perhaps that is it.    ------------------------------   Date: 4 Dec 2001 07:41:08 -0600e- From: koehler@encompasserve.org (Bob Koehler)>S Subject: Re: Shared PIRQ error on PCI multifunction card; how to assign interrupt ?a3 Message-ID: <xTHuQgX7$V7r@eisner.encompasserve.org>n   In article <nlLO7.46754$xS6.76102@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:  J > Both devices on the card are recognised correctly, but when I use SDA toJ > examine the PCI Bus Array Entry for each device, the interrupt vector is > zero.l  G    Unless PCI throws a major wrench into the IO system, which I haven't     seen written down anywhere:  C    Generally interrupt vectors were loaded when the IO data base ist&    built. Traditionally this requires:;       a) loading the driver (which you haven't written yet) .       b) connecting the driver to the hardware  D    Both of these are done via SYSMAN IO commands (SYSGEN on VAX, but%    we're talking Alpha and PCI here).=   ------------------------------  # Date: Tue, 04 Dec 2001 14:31:49 GMT9G From: Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> S Subject: Re: Shared PIRQ error on PCI multifunction card; how to assign interrupt ?26 Message-ID: <p75P7.48226$xS6.79018@www.newsranger.com>  ( On 4 Dec 2001 07:41:08 -0600, in article; <xTHuQgX7$V7r@eisner.encompasserve.org>, Bob Koehler wrote:e >i >In article <nlLO7.46754$xS6.76102@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.altavista.co.uk-Earth.UFP> writes:s >oK >> Both devices on the card are recognised correctly, but when I use SDA tolK >> examine the PCI Bus Array Entry for each device, the interrupt vector ise >> zero. >vH >   Unless PCI throws a major wrench into the IO system, which I haven't >   seen written down anywhere:  >t   It does. :-) See below.e  D >   Generally interrupt vectors were loaded when the IO data base is' >   built. Traditionally this requires:>< >      a) loading the driver (which you haven't written yet)/ >      b) connecting the driver to the hardwaren > E >   Both of these are done via SYSMAN IO commands (SYSGEN on VAX, buto& >   we're talking Alpha and PCI here). >   H Referring to "Writing OpenVMS Alpha Device Drivers in C", and looking atL chapter 14, section 14.7: Basically, the PCI interrupt vector for the deviceC is automatically assigned by the console as part of PCI's automaticE configuration capability.   C You then have to examine the PCI Bus Array Entry for your device to)K extract the interrupt vector allocated by the console. Section 14.7.3 gives 0 you an example of doing this manually using SDA.  I The problem is that I can find both array entries just fine (one for eacheE function on the card), but the interrupt vector is zero in each case, < meaning that the console did not assign an interrupt vector.  M I am also aware that I may not be asking this question in the best newsgroup.*J Is there a newsgroup for Alpha hardware that is more likely to be the best" place to ask Alpha PCI questions ?   Thanks for any information,    Simon.   --  @ Simon Clubley, simon_clubley@remove_me.altavista.co.uk-Earth.UFPK In the task of removing Microsoft from the marketplace, I have discovered aeE truly remarkable plan, but this signature is too small to contain it.    ------------------------------  % Date: Tue, 04 Dec 2001 10:44:29 +0100 - From: Serge ZANGHERI <serge.zangheri@sema.fr>  Subject: tcpip configR' Message-ID: <3C0C9AFD.3F11333A@sema.fr>*   Hi,*3 I need to modify certain param in the tcpip config, F What is the difference between /broadcast_mask and /c_broadcast_mask ?3 idem for the /c_network and /network_mask parametero" Is there a relation with Cluster ? Thanx  Sergem   ------------------------------  % Date: Tue, 04 Dec 2001 14:17:41 +0100u= From: Oswald Knoppers <Oswald.Knoppers@contrastmediagroep.nl>t Subject: Re: tcpip config 5 Message-ID: <3C0CCCF5.BB0D2ED9@contrastmediagroep.nl>c   Serge ZANGHERI wrote:  >  > Hi, 5 > I need to modify certain param in the tcpip config, H > What is the difference between /broadcast_mask and /c_broadcast_mask ?5 > idem for the /c_network and /network_mask parameterp$ > Is there a relation with Cluster ?  C Yes there is. In a cluster you can configure an alias address. ThisoF (type of) alias is for failover purposes only. At any time one node inA the cluster will be the impersonator and all traffic to the alias_ address will go to that member.(  G The c_broadcast and c_network are associated with the alias address you  configure on the interface.    Regards,   Oswald   ------------------------------  % Date: Tue, 04 Dec 2001 19:01:01 +0010 ' From: <paddy.o'brien@zzz.tg.nsw.gov.au>;7 Subject: Re: the Compaq pseudo-technical spin continuesc5 Message-ID: <01KBHBLIPOOY0013ZA@tgmail.tg.nsw.gov.au>r   >Speak for yourself, butthead.  ! >Joe Keane, amateur mathematicianP   Amateur flamer.=   Paddy=   ------------------------------  # Date: Tue, 04 Dec 2001 08:43:12 GMT . From: "Duane Sand" <Duane.Sand@mindspring.com>7 Subject: Re: the Compaq pseudo-technical spin continuese+ Message-ID: <A00P7.3213$Px.70983@rwcrnsc54>    > "Fred Kleinsorge" wrotepL > > I am quite sure that any number of our field specialists in OpenVMS willG > > be happy to work with you to overcome the doubts of your customers.c >  del cecchi wrote:yI > Doubts about what?  The future of Alpha?  The wonderfulness of Itanium,n, > and the vapor port?  Is Itanium bi-endian?  = Itanium is bi-endian.  As is Alpha, Mips, Sparc, and PowerPC.r   ------------------------------   Date: 4 Dec 2001 09:10:33 -0000l= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>i7 Subject: Re: the Compaq pseudo-technical spin continuesd6 Message-ID: <20011204091033.26893.qmail@gacracker.org>  3 On Tue, 04 Dec 2001, Joe Keane <jgk@jgk.org> wrote:a3 >In article <wHSN7.2188$RL6.63696@news.cpqcorp.net>s6 >Fred Kleinsorge <kleinsorge@star.zko.dec.com> writes:F >>We are now moving to an architecture with a WIDESPREAD ACCEPTANCE inF >>the industry as being the next generation 64-bit platform.  In fact,C >>everyone but Sun has embraced Itanium as the future for 64 bits. o >  >Speak for yourself, butthead. >e? >I am not Sun.  I don't embrace Itanium.  I recently said that,k- >basically, Hammer is the future for 64 bits.a >t >--i! >Joe Keane, amateur mathematiciane  K Since you chose to flame one of the more respected contributors, I wonderedn( what contributions you'd added to c.o.v.    All google turned up was this...  E http://groups.google.com/groups?selm=7meh77%24pa8%241%40rocky.jgk.orgm  E >I'm dubious about video phones when so many people put their repliesc= >before what they reply to.  How does that work in real time?-  G Now I see, you flame people and criticise for top posting when your ownpD netiquette is sadly lacking. That is a good way of earning the label "troll".     Doc. -- o6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.net0   ------------------------------  # Date: Tue, 04 Dec 2001 11:54:11 GMT:& From: "Jeff Killeen" <Jeff@IDM-IO.com>7 Subject: Re: the Compaq pseudo-technical spin continues63 Message-ID: <DP2P7.8$II1.6290@nwrddc02.gnilink.net>s  D If they don't have a credible port (credible as judged by the targetJ customers) mostly completed within 18 months of June 25th IMHO this is allH an academic debate.  I believe after that point the mass defections willL begin.  Opinions range as to when that point in time will occur.  Some claimL it has effectively happened and others I am sure will claim the date extendsL beyond 18 months.  No matter what one claims the date is the claim itself is@ opinion that will either be proved correct or incorrect by time.  F As many customers as possible should press Compaq for "Golden Blanket"L guarantees as soon as they can get them.  Don't get caught in FUD - find out	 for sure!O  , It had better be sooner rather than later...    5 "Bill Todd" <billtodd@metrocast.net> wrote in messageM< news:HpLO7.135593$8q.14437426@bin2.nnrp.aus1.giganews.com... >g3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageT4 > news:rjKO7.2058$Vj6.165100@typhoon2.gnilink.net... > >r9 > > "Bill Todd" <billtodd@metrocast.net> wrote in messagem@ > > news:t3AO7.113835$uB.15988925@bin3.nnrp.aus1.giganews.com...H > > > Exactly which growing market space is VMS going to be #1 or #2 in, Jeff?bK > > > Especially given the way Compaq handles it.  The reason some of thosed
 > > peopleI > > > who really wouldn't care whether they ran VMS on Alpha or on Itanic  arec > > veryJ > > > worried is because the reasoning Compaq claims it used to get rid of > Alpha I > > > seems very similarly applicable to VMS whenever they may choose to.d > > H > > Precisely Bill - with little chance that OVMS, Tru64, or Alpha Linux would D > > become #1 or #2 the high profile dollars being invested in Alpha remained > a H > > noticeable blip on the radar screen of the investment community.  As long > asB > > it remains profitable it is likely OVMS can fly below radar... >0I > Neglecting the question of whether it was the high-profile dollars that K > Compaq did *not* spend on its Alpha products that attracted the attention  ofE > the investment community, the problem remains that on June 25th the4J > profitability of VMS took a major hit that will persist for at least theK > duration of the full port (still said to be about 3 years, culminating in L > 2004 in a platform that still may be missing significant pieces, Compaq orG > ISV, for some customers).  Remaining sufficiently profitable to causee CompaqI > to expend any real effort other than the port itself on VMS during thisr timeK > seems, given the history of Compaq's support, unlikely - since it did not_L > expend such effort in the profitability climate that existed prior to JuneG > 25th once it had completed the VMS projects that had been in progressE before > it bought DEC. >O > - bill >I >( >I   ------------------------------  % Date: Tue, 04 Dec 2001 11:38:08 -0500;- From: JF Mezei <jfmezei.spamnot@videotron.ca>E7 Subject: Re: the Compaq pseudo-technical spin continues , Message-ID: <3C0CFBEC.BCA40A0B@videotron.ca>   Jeff Killeen wrote:WH > As many customers as possible should press Compaq for "Golden Blanket"N > guarantees as soon as they can get them.  Don't get caught in FUD - find out > for sure!   I When I went to a Compaq presentation in september, it was mentioned a fewrN times that HP would honour all legal contracts Compaq had made with customers,% so it was time to get stuff on paper.-   ------------------------------  % Date: Tue, 04 Dec 2001 18:21:55 +0100e1 From: John McLean <mcleanj@swissonline.delete.ch>R7 Subject: Re: the Compaq pseudo-technical spin continues15 Message-ID: <3C0D0633.18BF6B48@swissonline.delete.ch>n   Bob Koehler wrote: > T > In article <Gns8tA.1s12n@world.std.com>, alexc@world.std.com (Alex Colvin) writes: > M > > Their new head of computing, an ex-IBM salesguy, had one look and orderedyJ > > them to get that thing out of there. Singer spent years paying outsideB > > time-sharing vendors to continue to run that thing's software. > >f$ > > So colour does matter to people. > J >    Ever hear the war story about the "orange VAX"?  I know where you can >    find a whole room full.    " Did you think about Compaq's PCs ?  C They change the shape of the housing to something that looks like a 6 weight-challenged tower just to try to make it appeal.  G Evo has a few changes but again it looks like the design of the box was. an important issue.o     John McL   ------------------------------  $ Date: Tue, 4 Dec 2001 09:56:43 -0500- From: "Peter Weaver" <peter.weaver@stelco.ca>i6 Subject: Re: The Real Story About HP's Announcement...3 Message-ID: <ev5P7.69277$Z2.1019039@nnrp1.uunet.ca>o  : "george c stachnik" <stachnik@cup.hp.com> wrote in message$ news:3C0C3476.67D252E0@cup.hp.com... >... > WHO'S TO BLAME?  > ============H > A lot of the rhetoric that has appeared on this list in the last threeG > weeks has sought to fix blame on HP for "killing" the HP e3000.  It'siI > easy, in hindsight, to look back on the last 30 years, (and a number of-F > the emails that I've responded to have tried to do exactly that) and* > second guess the decisions that HP made. >h: > *  Did HP put enough energy and resources into marketing >     the HP e3000?e >t? > *  Should HP have positioned the HP e3000 differently againstv >     the HP 9000? >i4 > *  Should we have spent more money on advertising? >sA > *  Should we have spent our advertising dollars in publicationsr# >     like the Wall Street Journal?- >-C > If all you're concerned about is the HP e3000, then these are all H > "no-brainers".  The answers are clearly "yes", "yes", "yes" and "yes."H > But HP isn't (and should not be) concerned with ONLY one product, evenF > when that product is the HP e3000.  It's important to recognize thatI > every decision is a trade-off.  It's easy for the armchair-quarterbacks J > among us (and I'm as guilty of this as anybody) to point out things thatD > HP "coulda, shoulda" done on behalf of the HP e3000.  But it's notJ > always so easy to see what impact those decisions might have had on HP's+ > other product lines, or on HP as a whole.s >u= > *   If HP had put more energy into resources into marketingt= >     the HP e3000, would we have ended up like DEC - who put ? >     their resources behind the VAX and wound up being sold to 
 >     Compaq?- >...   BULL!-  I By the time Palmer handed DEC to Compaq the VAX was already at EOL. YearsoK before that sale DEC had stopped marketing the VAX. DEC was still marketing 4 the Alpha, but only as an UNIX and/or NT play thing.  H Had DEC continued to market VMS... had HP continued to market MPE... ???       --J A study has shown that sheep can remember faces for up to 2 years, I guess- that means I'm dumber than the average sheep.-   ------------------------------   Date: 4 Dec 2001 07:32:32 -0600S- From: koehler@encompasserve.org (Bob Koehler),N Subject: Re: Tru64 .vs. HP-UX  (was: Compaq's Secret VMS Plans (The Inquirer))3 Message-ID: <zVddRanAkAIm@eisner.encompasserve.org>l  [ In article <3C0C48A2.25474D47@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:a > = > But, isn't that true of any poorly documented installation?  >   ?    I should have to keep writing downwhat I told the computer? e?    Something it obviously knows?  All I can promise you is thatSA    in the real workd such a document would always be out of date.8   ------------------------------  * Date: Tue, 4 Dec 2001 07:44:29 -0700 (MST)" From: John Nebel <nebel@csdco.com>) Subject: Re: tubes (was: RE: DEC is DEAD) E Message-ID: <Pine.OSF.4.21.0112040708090.481-100000@athena.csdco.com>a  @ Magnetron tubes are used in microwave ovens, RADAR, and land and! space (satellite) communications.f  
 John Nebel    * On Mon, 3 Dec 2001, Fred Kleinsorge wrote:  I > In fact, many prized guitars (like old Fender Stratocasters) are prized-K > because of their hand-wound pickups, which over time warped in mysteriouso) > ways to provide unique sound qualities.( > / > _Fred (yeah, I once pretended to play guitar)n >  > ! > Phillip Helbig wrote in messageo4 > <01KBFVFNP0369125K1@sysdev.deutsche-boerse.com>...J > >> Most (probably more than 99%) of televisions still have at least one.M > >> As do a very high percentage of computers for the very same reason.  :-)b > >uG > >One area where tubes are still preferred to transistors is in guitarnJ > >amplifiers.  The idea here is NOT high-fidelity; the tubes and speakersH > >contribute substantially to the sound.  (Specifically, the non-linearJ > >effects of the tubes when overdriven leads to a "soft" distorted sound,I > >and the typical speakers act as low-pass filters, which is why even in E > >the studio the sound going into the mixing desk often comes from aTI > >microphone placed in front of a speaker, rather then directly from the H > >amplifier or even the guitar itself (perhaps after a pre-amp), thoughF > >this is not uncommon for bass guitars, where most amps and speakers) > >contribute less to the sound quality.)f >  >  >    ------------------------------  % Date: Tue, 04 Dec 2001 18:33:35 +0100h1 From: John McLean <mcleanj@swissonline.delete.ch> 9 Subject: Was the Alpha to Intel agreement ever approved ?e5 Message-ID: <3C0D08EF.D4A61D43@swissonline.delete.ch>o  C Does anyone know if the regulators ever got around to approving theQ transfer of Alpha to Intel ?  G I'm curious to know what has happened to date on this issue and whethery it could all be cancelled.  D I am also curious to know how the Securities and Exchange CommissionC (and others) might react if this transfer was to intended to have an? major influence on the merger of HP and Compaq.  Any opinions ?s     John McLeanj   ------------------------------   End of INFO-VAX 2001.674 ************************