1 INFO-VAX	Sun, 09 Apr 2000	Volume 2000 : Issue 198       Contents: Re: 1.6 GHz Alpha  RE: 1.6 GHz Alpha  Re: 1.6 GHz Alpha  Re: 1.6 GHz Alpha  Re: 1.6 GHz Alpha  RE: 1.6 GHz Alpha  Re: 1.6 GHz Alpha  Re: 1.6 GHz Alpha  RE: 1.6 GHz Alpha  Re: 1.6 GHz Alpha  Re: 1.6 GHz Alpha $ Anyone have some LA70 documentation?( Re: Anyone have some LA70 documentation?
 Re: australia  Re: CC patches ?
 Channel Count  Re: Channel Count  Re: Channel Count  Re: Channel Count ' Re: Compaq Song and Dance (the lack of) ' Re: Compaq Song and Dance (the lack of) ' Re: Compaq Song and Dance (the lack of)  Re: Debunking the B2B hype# Re: ELSA Gloria Synergy part number $ FA:  project box Vaxstation 3100 M38 Re: Freeware MIME  Re: Freeware MIME 2 Re: Galaxy (or perhaps Wildfire) and shared memory2 Re: Galaxy (or perhaps Wildfire) and shared memory< Re: Hobbyist VMS V7.2 TK50 DECnet-Plus installation failure?< Re: Hobbyist VMS V7.2 TK50 DECnet-Plus installation failure? Re: Manuals for DEC 3000-400s " Re: Pascal Compile-TIme stack dump So who will buy VMS ?  Re: So who will buy VMS ?  Re: So who will buy VMS ?  Re: split large files  Re: Suggestion for authorize& Re: Sun considers VMS a "mainframe" OS& RE: Sun considers VMS a "mainframe" OS  F ----------------------------------------------------------------------  % Date: Sat, 08 Apr 2000 14:13:28 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca> Subject: Re: 1.6 GHz Alpha/ Message-ID: <38EF76C2.5C96DB5E@vl.videotron.ca>    "Main, Kerry" wrote:I > Big point to be made from this article - "Our products are for servers, L > differing in design structure from the ones for general PCs from Intel and > AMD," he added"   K Another example of a company fearing Microsoft's wrath and making sure they 5 don't apear to be competing against the Wintel mafia.   M Computer are computers. And Intel's 8086 are used today as serious servers by G institutions you'd think would have the smarts not to use such toys for I serious work. So in the end, if Intel 8086s (and eventually IA64) compete 1 against you, why can't you compete against them ?    ------------------------------  $ Date: Sat, 8 Apr 2000 14:31:53 -0400+ From: "Main, Kerry" <Kerry.Main@Compaq.com>  Subject: RE: 1.6 GHz AlphaJ Message-ID: <910612C07BCAD1119AF40000F86AF0D8052841CF@kaoexc4.kao.dec.com>  
 Hello JF -  L I suspect the point that the author might have been hinting at is that theseK new servers will be optimized for SMP and servers while the recent 1Ghz x86 6 chips are focussed on single CPU WS / desktop designs.   Regards,  
 Kerry Main Senior Consultant,
 Compaq Canada  Professional Services  Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.com        -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@vl.videotron.ca] & Sent: Saturday, April 08, 2000 2:13 PM To: Info-VAX@Mvb.Saic.Com  Subject: Re: 1.6 GHz Alpha     "Main, Kerry" wrote:I > Big point to be made from this article - "Our products are for servers, L > differing in design structure from the ones for general PCs from Intel and > AMD," he added"   K Another example of a company fearing Microsoft's wrath and making sure they 5 don't apear to be competing against the Wintel mafia.   J Computer are computers. And Intel's 8086 are used today as serious servers byG institutions you'd think would have the smarts not to use such toys for I serious work. So in the end, if Intel 8086s (and eventually IA64) compete 1 against you, why can't you compete against them ?    ------------------------------  " Date: Sat, 8 Apr 2000 18:52:41 GMT* From: young_r@eisner.decus.org (Rob Young) Subject: Re: 1.6 GHz Alpha& Message-ID: <2000Apr8.145241.1@eisner>  b In article <38EF76C2.5C96DB5E@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > "Main, Kerry" wrote:J >> Big point to be made from this article - "Our products are for servers,M >> differing in design structure from the ones for general PCs from Intel and  >> AMD," he added" > M > Another example of a company fearing Microsoft's wrath and making sure they 7 > don't apear to be competing against the Wintel mafia.  > O > Computer are computers. And Intel's 8086 are used today as serious servers by I > institutions you'd think would have the smarts not to use such toys for K > serious work. So in the end, if Intel 8086s (and eventually IA64) compete 3 > against you, why can't you compete against them ?     : 	Samsung fears no one.  In fact, they pretty much dominate< 	memories and if you look at history from the mid-80s on youA 	see where Intel once dominated memories.  The fellow that headed ? 	up memories moved over to the CPU side.  Perhaps they can make A 	inroads into servers across the board.  Samsung's strong support @ 	of Linux is a wise move.  We'll see how they do.  But as far as9 	the comment being related to fear...  I think you got it F 	turned around.  After all, the last time I checked Intel manufacturesA 	the Xeon and other server related CPUs.  The gentleman's comment @ 	could be interpreted to mean that Intel is "just a PC company."D 	Looks like a slight to me.  Besides, not that far off.  If the EV68A 	starts shipping at 1.5 GHz with 8 MBytes of L2 clocking along at > 	1 GHz, then I would say THAT is a server part!  Intel's parts: 	would be PC parts in comparison... especially that pokey @ 	Smoking Brick Of Death* (aka Itanium) burning along at 700 MHz.   	That's my read.   				Rob   C * Thanks to Paul Demone  (gotta love that SBOD at 150 watts, OUCH!)    ------------------------------  $ Date: Sat, 8 Apr 2000 15:12:54 -0400' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: 1.6 GHz Alpha( Message-ID: <8co08a$og5$1@pyrite.mv.net>  ; JF Mezei <jfmezei.spamnot@vl.videotron.ca> wrote in message ) news:38EF76C2.5C96DB5E@vl.videotron.ca...  > "Main, Kerry" wrote:K > > Big point to be made from this article - "Our products are for servers, J > > differing in design structure from the ones for general PCs from Intel and  > > AMD," he added"  > H > Another example of a company fearing Microsoft's wrath and making sure they7 > don't apear to be competing against the Wintel mafia.   L I suppose one could interpret it that way, but my own impression was that itG was more to the effect that if you want a real server system, don't use L Wintel toys to build it - stated with characteristic Asian subtlety (for theL politically-correct portion of the audience, that's a cultural rather than a racial observation).   - bill   > L > Computer are computers. And Intel's 8086 are used today as serious servers byI > institutions you'd think would have the smarts not to use such toys for K > serious work. So in the end, if Intel 8086s (and eventually IA64) compete 3 > against you, why can't you compete against them ?    ------------------------------  % Date: Sat, 08 Apr 2000 15:22:42 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca> Subject: Re: 1.6 GHz Alpha/ Message-ID: <38EF86F8.3FD22D7A@vl.videotron.ca>    Rob Young wrote:M >         Looks like a slight to me.  Besides, not that far off.  If the EV68 J >         starts shipping at 1.5 GHz with 8 MBytes of L2 clocking along atG >         1 GHz, then I would say THAT is a server part!  Intel's parts B >         would be PC parts in comparison... especially that pokeyI >         Smoking Brick Of Death* (aka Itanium) burning along at 700 MHz.   L Reality doesn't matter, marketing does. If Compaq markets its 32way 8086 andE responds to RFPs with 32way 8086 servers, then guess what will sell ?   N I know that a 760mhz Alpha (probably) still beats a 1 Ghz 8086 (but the marginK is probably narrowing). But the general marketplace doesn't. They really do M think that Intel does make the world's fastest chip and that it is a Pentium, V and it is Compaq's fault for not defending its turf where it counts: in the marketing.  L Had Bobby Palmer's goal not been to find a way to shove the money losing FABN plant down't Intel's troath, I have a feeling that he could have gotten a hellK of a lot of mileage of the accusation that Intel had "inspired" itself from L Alpha technologies for its Pentium. But as it stood, his goal was to prepare* Digital for Compaq and shed the FAB plant.   ------------------------------   Date: 8 Apr 2000 20:40:50 GMT 2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: RE: 1.6 GHz Alpha, Message-ID: <8co5gi$bij@gap.cco.caltech.edu>  x In article <910612C07BCAD1119AF40000F86AF0D8052841CF@kaoexc4.kao.dec.com>, "Main, Kerry" <Kerry.Main@Compaq.com> writes: >Hello JF -  > M >I suspect the point that the author might have been hinting at is that these L >new servers will be optimized for SMP and servers while the recent 1Ghz x867 >chips are focussed on single CPU WS / desktop designs.   J Ahem. There are large classes of problems which can be addressed very wellJ on parallel single processor machines at huge savings over the equivalent G number of processors in an SMP.  I'm currently setting up a 9 node DS10 J beowulf which ran around $50k. The equivalent SMP alpha machine would haveI been unthinkably expensive, probably costing a factor of 10 more.   There D are plenty of problems that need SMP, and lots of others that don't.  K My point being 1.3 Ghz processors should be available for both monster SMP  C machines and smaller single CPU building blocks, and that whatever  H optimizations for SMP there are should not negatively affect performanceJ on the single CPU machines.  Right now the mythical 700 Mhz part which is F going into Celera's machines seems not be available in single CPU unit' building blocks - and that's a mistake.    Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech     ------------------------------  % Date: Sat, 08 Apr 2000 16:23:16 -0400 * From: David A Froble <davef@tsoft-inc.com> Subject: Re: 1.6 GHz Alpha- Message-ID: <38EF9534.62324C26@tsoft-inc.com>    Rob Young wrote: > d > In article <38EF76C2.5C96DB5E@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > > "Main, Kerry" wrote:L > >> Big point to be made from this article - "Our products are for servers,O > >> differing in design structure from the ones for general PCs from Intel and  > >> AMD," he added" > > O > > Another example of a company fearing Microsoft's wrath and making sure they 9 > > don't apear to be competing against the Wintel mafia.  > > Q > > Computer are computers. And Intel's 8086 are used today as serious servers by K > > institutions you'd think would have the smarts not to use such toys for M > > serious work. So in the end, if Intel 8086s (and eventually IA64) compete 5 > > against you, why can't you compete against them ?  > C >         Samsung fears no one.  In fact, they pretty much dominate E >         memories and if you look at history from the mid-80s on you J >         see where Intel once dominated memories.  The fellow that headedH >         up memories moved over to the CPU side.  Perhaps they can makeJ >         inroads into servers across the board.  Samsung's strong supportI >         of Linux is a wise move.  We'll see how they do.  But as far as B >         the comment being related to fear...  I think you got itO >         turned around.  After all, the last time I checked Intel manufactures J >         the Xeon and other server related CPUs.  The gentleman's commentI >         could be interpreted to mean that Intel is "just a PC company." M >         Looks like a slight to me.  Besides, not that far off.  If the EV68 J >         starts shipping at 1.5 GHz with 8 MBytes of L2 clocking along atG >         1 GHz, then I would say THAT is a server part!  Intel's parts B >         would be PC parts in comparison... especially that pokeyI >         Smoking Brick Of Death* (aka Itanium) burning along at 700 MHz.  >  >         That's my read.  > % >                                 Rob  > E > * Thanks to Paul Demone  (gotta love that SBOD at 150 watts, OUCH!)   N Actually, servers are much more than CPU speed.  Where CPU speed might be moreN important is in workstations that are compute intensive and doing graphics andM such.  I have to agree with JM on this one, CPUs are CPUs, and can be used in J any application.  Yeah, normally faster is better, and the Alpha does mostM things better than the X86 toys, when given the chance and the applications.  * And on Alpha, VMS does most things better.  M So what's wrong with "VMS the best, most secure, most flexible, most scalable O commercial operating system in the world!"  Most of the time when listening for - such, all you'll hear is a long loud silence.    Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  % Date: Sat, 08 Apr 2000 16:26:47 -0400 * From: David A Froble <davef@tsoft-inc.com> Subject: Re: 1.6 GHz Alpha- Message-ID: <38EF9607.CB35F3B1@tsoft-inc.com>    JF Mezei wrote:  >  > Rob Young wrote:O > >         Looks like a slight to me.  Besides, not that far off.  If the EV68 L > >         starts shipping at 1.5 GHz with 8 MBytes of L2 clocking along atI > >         1 GHz, then I would say THAT is a server part!  Intel's parts D > >         would be PC parts in comparison... especially that pokeyK > >         Smoking Brick Of Death* (aka Itanium) burning along at 700 MHz.  > N > Reality doesn't matter, marketing does. If Compaq markets its 32way 8086 andG > responds to RFPs with 32way 8086 servers, then guess what will sell ?   # At a guess, DELL X86 based systems?   P > I know that a 760mhz Alpha (probably) still beats a 1 Ghz 8086 (but the marginM > is probably narrowing). But the general marketplace doesn't. They really do O > think that Intel does make the world's fastest chip and that it is a Pentium, X > and it is Compaq's fault for not defending its turf where it counts: in the marketing.  2 Perception is reality, at least for the perceiver.  N > Had Bobby Palmer's goal not been to find a way to shove the money losing FABP > plant down't Intel's troath, I have a feeling that he could have gotten a hellM > of a lot of mileage of the accusation that Intel had "inspired" itself from N > Alpha technologies for its Pentium. But as it stood, his goal was to prepare, > Digital for Compaq and shed the FAB plant.  P I've been collecting feathers.  Probably could round up a rail.  Anyone got some$ tar?  We should pay Bobby P a visit.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.com  Vanderbilt, PA  15486    ------------------------------  $ Date: Sat, 8 Apr 2000 19:53:34 -0400+ From: "Main, Kerry" <Kerry.Main@Compaq.com>  Subject: RE: 1.6 GHz AlphaJ Message-ID: <910612C07BCAD1119AF40000F86AF0D8052841D0@kaoexc4.kao.dec.com>   David,  L You are correct that there is a place for single processor boxes and a place for SMP config's.   A Kind of like the auto industry - no one solution will address all 
 requirements.   I Btw - in case anyone thinks the 1Ghz x86's are now faster than single cpu ! Alpha's, check out the following: H http://www.spec.org/osg/cpu2000/results/cpu2000.html (single cpu EV6/667L still rated higher (444 vs 410) in Spec CPU2000 and still MUCH higher in the! Specfp 2000 (577 vs 284) results)    Regards,  
 Kerry Main Senior Consultant,
 Compaq Canada  Professional Services  Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.com        -----Original Message-----# From: mathog@seqaxp.bio.caltech.edu & [mailto:mathog@seqaxp.bio.caltech.edu]& Sent: Saturday, April 08, 2000 4:41 PM To: Info-VAX@Mvb.Saic.Com  Subject: RE: 1.6 GHz Alpha    J In article <910612C07BCAD1119AF40000F86AF0D8052841CF@kaoexc4.kao.dec.com>,- "Main, Kerry" <Kerry.Main@Compaq.com> writes:  >Hello JF -  > G >I suspect the point that the author might have been hinting at is that  these L >new servers will be optimized for SMP and servers while the recent 1Ghz x867 >chips are focussed on single CPU WS / desktop designs.   J Ahem. There are large classes of problems which can be addressed very wellJ on parallel single processor machines at huge savings over the equivalent G number of processors in an SMP.  I'm currently setting up a 9 node DS10eJ beowulf which ran around $50k. The equivalent SMP alpha machine would haveI been unthinkably expensive, probably costing a factor of 10 more.   ThereoD are plenty of problems that need SMP, and lots of others that don't.  K My point being 1.3 Ghz processors should be available for both monster SMP oC machines and smaller single CPU building blocks, and that whatever eH optimizations for SMP there are should not negatively affect performanceJ on the single CPU machines.  Right now the mythical 700 Mhz part which is F going into Celera's machines seems not be available in single CPU unit' building blocks - and that's a mistake.s   Regards,   David Mathog mathog@seqaxp.bio.caltech.edue? Manager, sequence analysis facility, biology division, Caltech ?   ------------------------------  % Date: Sat, 08 Apr 2000 21:16:29 -0400 0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca> Subject: Re: 1.6 GHz Alpha/ Message-ID: <38EFD9EB.33F97443@vl.videotron.ca>    "Main, Kerry" wrote:K > Btw - in case anyone thinks the 1Ghz x86's are now faster than single cpu # > Alpha's, check out the following:SJ > http://www.spec.org/osg/cpu2000/results/cpu2000.html (single cpu EV6/667N > still rated higher (444 vs 410) in Spec CPU2000 and still MUCH higher in the# > Specfp 2000 (577 vs 284) results)a  K How come I don't see Compaq (or APC) ads on CNN during the business news toi& flaunt the world's fastest processor ?  J Such ads would probably result in Compaq's stock rising by $20 quickly, soJ shareholders would be very happy that Compaq spent money for such ads. AndM such ads would protray Compaq as a leader, cut the wind from Dell's effort tot5 outsell Compaq, and give Compaq much needed momentum.s  M I am affraid to say that Compaq has absorbed the Digital gene that results ink the inability to do marketing.   ------------------------------   Date: 9 Apr 2000 03:34:36 +0200e* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: 1.6 GHz Alpha* Message-ID: <38efde2c$1@news.kapsch.co.at>  b In article <38EFD9EB.33F97443@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: >"Main, Kerry" wrote:1L >> Btw - in case anyone thinks the 1Ghz x86's are now faster than single cpu$ >> Alpha's, check out the following:K >> http://www.spec.org/osg/cpu2000/results/cpu2000.html (single cpu EV6/667 O >> still rated higher (444 vs 410) in Spec CPU2000 and still MUCH higher in the $ >> Specfp 2000 (577 vs 284) results) >rL >How come I don't see Compaq (or APC) ads on CNN during the business news to' >flaunt the world's fastest processor ?m   This is Non-PC business.L COMPAQ wanted to buy Digital "to get a good world wide service organisation"G (and does now sell service business in pieces at least in Germany, as IRL heard at the last DECUS Germany event) and inherited the enterprise business8 in addition (but still doesn't know what to do with it).  K >Such ads would probably result in Compaq's stock rising by $20 quickly, so K >shareholders would be very happy that Compaq spent money for such ads. AndeN >such ads would protray Compaq as a leader, cut the wind from Dell's effort to6 >outsell Compaq, and give Compaq much needed momentum.   Sigh  N >I am affraid to say that Compaq has absorbed the Digital gene that results in >the inability to do marketing.   
 Amen to that.A   -- p< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-8881< FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------  $ Date: Sat, 8 Apr 2000 13:08:49 -07005 From: "cstranslations" <cstranslations@email.msn.com>"- Subject: Anyone have some LA70 documentation?c) Message-ID: <efK4$YZo$GA.226@cpmsnbbsa03>'  J I have a LA70 printer attached to my system here and am trying to define aJ 132 character wide form. It's been ages since I've done anything along theE lines of form set-up (but have some vague memory of having to put theoC necessary escape sequences into a text file and then load it into ag, library - after stoppint the queue manager).  I The big problem at the moment is that I don't have any docs for the LA70. H Anyone out there know where I can find something on the web (or have theL hardcopy docs). Obviously what I'm most interested in is the sequence to setC it to 132 characters (and the one to get it back to 80 characters).a   Thanks in advance, Joer   ------------------------------  % Date: Sat, 08 Apr 2000 16:21:41 -0400c0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>1 Subject: Re: Anyone have some LA70 documentation?c/ Message-ID: <38EF94C7.4EBCF584@vl.videotron.ca>r  J Not sure about the LA70, but here are some of the escape sequences for theN LA75 I still had handy. I suspect they are quite similar to the LA70. It comes from ALL-IN-1.    % ATTRIBUTE TABLE:             LA75.PRAe     ---------------g  PRINTER SETUP ---------------A  $ Initialization sequence:     <27>[!p$ Termination sequence:        <27>[!p( Page size:                   <27>[<DEC>t Maximum Page size:           0 Number of page ejects:       1 Loaded page in printer:      N  " ----------------------------------!  FALLBACKS AND CONTROL CHARACTERS-" ----------------------------------   Carriage return char(ASCII): 13l Line feed char      (ASCII): 101 Backspace char      (ASCII): 8 Change bar char     (WPL):   25i Underline fallback  (WPL):   0 Dbl under fallback  (WPL):   0 Redline fallback    (WPL):   18  Underline in dbl underline:  N Underline pass:              1   --------------
  HIGHLIGHTINGs --------------  % Superscript on:              <27>[?4me& Superscript off:             <27>[?24m% Subscript on:                <27>[?5mm& Subscript off:               <27>[?24m$ Underline on:                <27>[4m% Underline off:               <27>[24mu% Double underline on:         <27>[21mb% Double underline off:        <27>[24mo Redline on:e Redline off:$ Bold on:                     <27>[1m% Bold off:                    <27>[22m  Reverse on:c Reverse off:
 Shadow on: Shadow off:o Extra dark on: Extra dark off:a   -------r  TRAYS -------   ! Send Page Eject <SPE>:       <12>   " Tray 0:  (NOTRAY)            <SPE>% Tray 1:  (FRONT)             <27>[1!v % Tray 2:  (REAR)              <27>[2!vv" Tray 3:  (ENVELOPE)          <SPE>" Tray 4:                      <SPE>" Tray 5:                      <SPE>" Tray 6:                      <SPE>" Tray 7:                      <SPE>" Tray 8:                      <SPE>" Tray 9:                      <SPE>" Tray 10:                     <SPE> LETTERHEAD First Tray:       1 LETTERHEAD Ensuing Tray:     2 ALTERNATE Odd Tray:          1 ALTERNATE Even Tray:         2  
 -------------   ORIENTATION
 -------------f  	 Portrait: 
 Landscape:   ----------------------  VERTICAL POSITIONINGn ----------------------   Default pitch:               6 Resolution:                  0 Spacing adjustment:          0  Maximum increment:           255 Relative positioning:f Absolute positioning:u   ------------------  VERTICAL PITCHES' ------------------   2         <27>[4zt 3         <27>[5zd 4         <27>[6zw 6         <27>[1ze 8         <27>[2z  12        <27>[3zn   ------------------------  HORIZONTAL POSITIONING  ------------------------   Default pitch:               10  Resolution:                  0 Spacing adjustment:          0  Maximum increment:           255 Relative left positioning: Relative right positioning:n Absolute positioning:c   --------------------  HORIZONTAL PITCHESs --------------------   5         <27>[5w<27>[10mi 6         <27>[6w<27>[10ms 8         <27>[8w<27>[10mh 10        <27>[1w<27>[10me 12        <27>[2w<27>[10mt 15        <27>[4w<27>[10md   ----------------  CHARACTER SETSo ----------------  # ASCII:                       <27>(Bp# LINE DRAWING:                <27>(0h# TECHNICAL:                   <27>(>-# MULTINATIONAL:               <27>(<  ALTERNATE 1: ALTERNATE 2: ALTERNATE 3: ALTERNATE 4: ALTERNATE 5:   -------p -------g  FONTS -------@   DEFAULTt WPL$PRT:DECLMT.PRC <27>[10m    
 LETTER_GOTHIC8 WPL$PRT:DECLMT.PRC <27>[2w<27>[17m"     ORATOR WPL$PRT:DECLMT.PRC <27>[1w<27>[17ml      
 ----------	  KEYWORDSp
 ----------   DRAFTm <27>[1"z   LETTER <27>[2"z   MEMO <27>[3"z   NEAR_LETTERo <27>[4"z   ------------------------------   Date: 8 Apr 2000 20:19:10 GMTn2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: Re: australia, Message-ID: <8co47u$bij@gap.cco.caltech.edu>  j In article <002501bfa09e$a6b65f70$585b5cc0@socrates.Subway>, "Bob Ricci" <maxx0623@concentric.net> writes:M >will be installing a frame-relay line to Australia. Need to print from alphaMM >host in US to a printer on the NT network in Australia. Compaq does not haveoJ >ln16 's available in Australia. I was wondering if anybody from AustraliaK >can help me out as to what printers they are using with alpha/vms 6.2, and , >how to set them up on our network in the US >thanksl >ricci_r@subway.com  >t  K If that printer hooks directly to the network then you can just print to iteL via LPD or DPCS.  If it hangs off the side of an NT box you can still print F to it once you get your hands on a recent SMBCLIENT from the VMS samba port.  See:   A   http://seqaxp.bio.caltech.edu/pub/SOFTWARE/PRINT_TO_WINDOWS.ZIP.   Regards,   David Mathog mathog@seqaxp.bio.caltech.eduo? Manager, sequence analysis facility, biology division, Caltech     ------------------------------   Date: 9 Apr 2000 04:08:43 +0200n* From: eplan@kapsch.net (Peter LANGSTOEGER) Subject: Re: CC patches ?t* Message-ID: <38efe62b$1@news.kapsch.co.at>  U In article <38B2EF32.5B1A21B9@mediaone.net>, Duane Smith <nhdas@mediaone.net> writes:eI >Perhaps the C++ project leader has more clout than the C project leader? : >I will speak to the C project leader about this tomorrow.  B And now, a month later, my thanks to you and the C project leader.  5 CCAE03062 is now downloadable (since a few days ago).o   -- w< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888n< FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"N "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998   ------------------------------  $ Date: Sat, 8 Apr 2000 17:28:41 +01005 From: "Chris Fisher" <Chris.Fisher@nationwideisp.net>  Subject: Channel Count2 Message-ID: <8cnlvd$rfk$1@cedar.nationwideisp.net>  J We have lost our System Manager for reasons I wont go into. This leaves me trying to fill the gap!r  F One of our software suppliers has indicated we have a problem with theK Channel Count. I know its a SYSMAN setting but dont seem to be able to finde it.fL Which SYSMAN parameter do I use to show the current setting and having found it how do I change it?   TIA..................... Chris   ------------------------------  % Date: Sat, 08 Apr 2000 15:16:10 -0400r0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca> Subject: Re: Channel Count/ Message-ID: <38EF8570.CCEC5200@vl.videotron.ca>    Chris Fisher wrote:pH > One of our software suppliers has indicated we have a problem with theM > Channel Count. I know its a SYSMAN setting but dont seem to be able to findt > it.mN > Which SYSMAN parameter do I use to show the current setting and having found > it how do I change it?  8 You are probably thinking of SYSGEN instead of SYSMAN...  " If you are running VMS 7.2, then :; MC SYSGEN HELP SYS_PARA CHANNELCNT  will get you some info.c
 otherwise: MC SYSGEN HELP PARA CHANNELCNT  : *Normally*, system parameters are changed in a file calledN SYS$SYSTEM:MODPARAMS.DAT which sort of documents in a permananent way what you1 want the parameters to be. You then run a utility N @SYS$UPDATE:AUTOGEN  which takes your MODPARAMS.DAT and integrates it into theN SYSGEN (as well as doing some nanity checks and calculations (if you raise oneJ parameter, it may require automatic modification of another for instance).  L However, if you are truly uncertain of the state of your machine and whetherI MODPARAMS.DAT really reflects your current machine, you can do the SYSGENl changes yourself:   	 MC SYSGEN E SYSGEN> USE CURRENT		! uses the current "permanent" sysgen parameterse: SYSGEN> SHOW CHANNELCNT	! take a note of the current value? SYSGEN> SET CHANNELCNT XXX !where XXX is the new value you want L SYSGEN> WRITE CURRENT		! writes the updated parameters back to the permanent SYSGEN file. SYSGEN> EXIT  M You would then have to reboot for the new values to take effect. (SYSGEN doescK have some dynamic parameters, and you will see a (D) at the end of the lineiK when showing its value, for these, you can WRITE ACTIVE and the active/livepE parameters will be updated and the new value takes effect right away.,  L Note: please read the HELP text of CHANNELCNT carefully and evaluate whether7 you really want to do this. Sounds quite strange to me.    ------------------------------  " Date: Sat, 8 Apr 2000 19:17:38 GMT* From: young_r@eisner.decus.org (Rob Young) Subject: Re: Channel Count& Message-ID: <2000Apr8.151738.1@eisner>  j In article <8cnlvd$rfk$1@cedar.nationwideisp.net>, "Chris Fisher" <Chris.Fisher@nationwideisp.net> writes:L > We have lost our System Manager for reasons I wont go into. This leaves me > trying to fill the gap!l > H > One of our software suppliers has indicated we have a problem with theM > Channel Count. I know its a SYSMAN setting but dont seem to be able to findi > it. N > Which SYSMAN parameter do I use to show the current setting and having found > it how do I change it? >   > TIA..................... Chris >  >   	Didn't you see the other reply?  = 	From a suitably prived account you can modify CHANNELCNT, orl 	examine it:   $ run sys$system:sysgen  SYSGEN>  SHOW CHANNELCNTH Parameter Name            Current    Default     Min.     Max.     Unit  DynamicoH --------------            -------    -------    -------  -------   ----  -------hL CHANNELCNT                    255        127        31      2047 Channels   
 SYSGEN>  EXIT   = 	Notice it isn't a Dynamic parameter so it requires a reboot.4  > 	But what disturbs me more is there was no recommendation fromA 	your software supplier as to what the setting should be and why.A  ? 	You seem to be in a tough spot as you have to come up to speed ; 	in a hurry or get someone in in a hurry (assuming you have   	a critical system running VMS).   				Rob1   ------------------------------  % Date: Sat, 08 Apr 2000 16:34:03 -0400r* From: David A Froble <davef@tsoft-inc.com> Subject: Re: Channel Count- Message-ID: <38EF97BB.BA211E5C@tsoft-inc.com>u   Chris Fisher wrote:w > L > We have lost our System Manager for reasons I wont go into. This leaves me > trying to fill the gap!  > H > One of our software suppliers has indicated we have a problem with theM > Channel Count. I know its a SYSMAN setting but dont seem to be able to find0 > it.tN > Which SYSMAN parameter do I use to show the current setting and having found > it how do I change it? >   > TIA..................... Chris  ) There have been good replies form others.   G I would ask what your vendor is recommending for a CHANNEL COUNT value.h  , I would also ask what your current value is.  ) From a suitably privilidged user account:    $ run SYS$SYSTEM:SYSGENM SHOW CHANNEL ^Z  N Post the result from this, along with what type of system you are running, how9 many users, and what type of load the system experiences.   L There will be people in this group that will be helpful.  There's nothing asP helpful as an experienced VMS person with access to your system so they can lookP at the many pertinent things relavent to changing SYSGEN parameters.  This isn't9 a "let's try this and see what happens" type of exercise.a   Dave   -- e4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.coma Vanderbilt, PA  15486v   ------------------------------   Date: 8 Apr 2000 19:30:45 -0400b4 From: "Robert Deininger" <rdeininger@mindspring.com>0 Subject: Re: Compaq Song and Dance (the lack of)+ Message-ID: <B5153967-C918A@165.247.45.253>h  E On Fri, Apr 7, 2000 3:56 PM, Terry C. Shannon <shannon@world.std.com>  wrote:  I >As the source of Magee's speeds-n-feeds info, methinks Compaq is waitingt for / >the >1GHz Alphae before it makes a big splash.R  A >"Larry D Bohan, Jr" <LBohan@dbc.spam_less..com> wrote in messageh    D >> and President Bill Clinton, who currently runs the United States.  H Terry, were you also the source of this peculiar nugget?  You've mislead the poor fellow.  7 Everyone knows Janet Reno is currently running the U.S.-   :-)-     ---------------------------  Robert Deininger rdeininger@mindspring.com.   ------------------------------  # Date: Sat, 08 Apr 2000 23:36:50 GMTE= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)n0 Subject: Re: Compaq Song and Dance (the lack of)0 Message-ID: <009E851A.3FBAF7F3@SendSpamHere.ORG>  b In article <B5153967-C918A@165.247.45.253>, "Robert Deininger" <rdeininger@mindspring.com> writes:F >On Fri, Apr 7, 2000 3:56 PM, Terry C. Shannon <shannon@world.std.com> >wrote:  >)J >>As the source of Magee's speeds-n-feeds info, methinks Compaq is waiting >for0 >>the >1GHz Alphae before it makes a big splash. >uB >>"Larry D Bohan, Jr" <LBohan@dbc.spam_less..com> wrote in message >o >hE >>> and President Bill Clinton, who currently runs the United States.d >uI >Terry, were you also the source of this peculiar nugget?  You've misleadt >the poor fellow.n >i8 >Everyone knows Janet Reno is currently running the U.S. >C >:-) >  >o >--------------------------- >Robert Deiningerl >rdeininger@mindspring.com >- >- >-  J I was certain that it was Hillary!  Perhaps, this is a Dr. Jeckyl/Mr. Hyde story with a different gender?   --N VAXman- OpenVMS APE certification number: AAA-0001           VAXman@TMESIS.COM  O Compaq C V6.2 has bugs, bugs, bugs, bugs, bugs! No wait! They're ANSI features!e   ------------------------------  % Date: Sat, 08 Apr 2000 17:10:53 -0400t* From: David A Froble <davef@tsoft-inc.com>0 Subject: Re: Compaq Song and Dance (the lack of)- Message-ID: <38EFA05D.307970E5@tsoft-inc.com>r   cstranslations wrote:i > ; > Terry C. Shannon <shannon@world.std.com> wrote in message " > news:FsnwBp.1GG@world.std.com...L > > As the source of Magee's speeds-n-feeds info, methinks Compaq is waiting > fora2 > > the >1GHz Alphae before it makes a big splash. >   N I sort of liked AMD's approach.  Every so often they would bring out an AthlonL that would beat whatever Intel had just done.  Each time they would tell theM world about their newest CPU.  Instead of waiting for the 1 GHz Athlon, whichsK many believed they could do whenever they wanted to, they periodically, andCP often, grabbed the headlines, and instead of one pie in Intel's face, they had aJ large bucket of mud and continually were smashing Intel in the face with a handful of mud.d  L And, from a financial perspective, last October or thereabouts, both AMD andN Compaq stock was around $18 per share.  Today AMD's stock is at $74 per share,O and Compaq's closed yesterday at $29.50 per share.  Every time I think about myNL decision in November when I didn't buy some AMD stock, I smack myself on the head and shout IDIOT!1   Dave   -- I4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596; 170 Grimplin Road               E-Mail: davef@tsoft-inc.comn Vanderbilt, PA  15486e   ------------------------------  % Date: Mon, 03 Apr 2000 11:57:44 +01002B From: Andrew Harrison SUNUK Consultancy <andrew.nospam@uk.sun.com># Subject: Re: Debunking the B2B hypen* Message-ID: <38E87927.F3B1B2D5@uk.sun.com>   Arne Vajhj wrote:  ' > The computer-side is relative simple:2F >   - a standard browser at the buyer (Netscape Navigator, MS Internet > Explorer, ...)J >   - a web-server which usually is capable of SSL (Apache on Linux or IIS
 > on NT or# >     OSU on VMS would all do well)e? >   - some scripts (good old CGI-scripts, ASP or Java servlets)tH >   - often a database at the backend (normal database with information)J >   - if it is done professionally some redundancy (VMS cluster or Unix/NT >     failover)t >e0 > All well-known and relative simple technology. >t  B Most transactions on the Internet are relatively low value, people> buying paper clips not plant and machinery. This is because of? an area you have completely missed from your list of technology-  which is the peices you need to:  8 Establish the identity of the purchaser and the supplier6 To secure the transaction and guarantee it if anything untoward happens.   4 Services like Verisign establish Identity but do not; provide enough information for most financial transactions.A  8 At the security level simple userid password schemes are7 not considered secure enough for large transactions for  a number of obvious reasons.     RegardsP Andrew Harrison- Enterprise IT Architecta   ------------------------------  $ Date: Sun, 2 Apr 2000 16:18:02 -0400+ From: "David Turner" <d_b_turner@yahoo.com>e, Subject: Re: ELSA Gloria Synergy part number. Message-ID: <sefak2t5eop72@corp.supernews.com>   WE SELL THEM !!!!-   Call Toll Free 877 636 4332A  K Our main customers are dealer but we have no problem selling to an indivuall   David Turner Island Computers US CORP 912 447 6622 sales@islandco.com      @ "cstranslations" <cstranslations@email.msn.com> wrote in message# news:u6a42ksm$GA.246@cpmsnbbsa03... J > On the off hand chance that I decide to throw some more money at the DPWJ > 433-a sitting over in the corner in an attempt to get OpenVMS running on itL > I was wondering if there's anyone out there in comp.os.vms land that knowsH > the part number for the ELSA Gloria Synergy card. It was out here in a postJ > a while back, or maybe it was comp.sys.dec. I had it scribbled down someK > where but can't seem to find it (or turn it up via dejanews). I spent thenI > better part of a hour on and off hold with digital [er compaq] customer<J > service this morning and the nice lady on the other end couldn't seem toK > find a digital sounding part number. When she tried to look up the compaq J > part number the system couldn't seem to find anything. Maybe they're out of. > them and I should opt for a PowerStorm card. >rF > Also - anybody familiar with a reseller were I can pick up a Q-LogicI > QLA1040? I have the part number but I would liked to have fallen out of7 the I > chair this morning when they (digital - er - compaq) gave me the price.  FromH > what I'm seeing on www.qlc.com Q-Logic doesn't seem to retail. The one linkI > I followed off their web-site led to a page with a bug which reared its  uglyG > head any time I moved the cursor. Yes - this made getting to the backt button
 > impossible.- >- > Joe- >- >V   ------------------------------  % Date: Sun, 02 Apr 2000 12:55:32 -0400 # From: dONo <studiodoc@netscape.net>p- Subject: FA:  project box Vaxstation 3100 M38:, Message-ID: <38E77B84.116C12AA@netscape.net>  F Offers accepted on a VS 3100 M38 with floppy, 2 Hard drives - one withE VMS 6.4, the other with VMS 7.2.  Quite clean and hard copy of owners  manual.>   ------------------------------   Date: 8 Apr 2000 20:24:23 GMT-2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: Re: Freeware MIME, Message-ID: <8co4hn$bij@gap.cco.caltech.edu>  _ In article <8ckjuo$rij$1@cyan.nl.gxn.net>, "Frits A.M. Storms" <frits@storms.tmfweb.nl> writes:iI >I am looking for a simple freeware tool to encode & decode MIME files onR	 >OpenVMS.CA >Could someone point me to the appropriate download site please ?  >>   I use MUNPACK a lot, from here:[  >   http://seqaxp.bio.caltech.edu/pub/SOFTWARE/VMS_MPACK_1_5.TAR  < If you also want to send valid MIME messages have a look at:  6   http://seqaxp.bio.caltech.edu/pub/SOFTWARE/MMAIL.COM   or use PINE.   Regards,   David Mathog mathog@seqaxp.bio.caltech.eduU? Manager, sequence analysis facility, biology division, Caltech LJ **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------   Date: 8 Apr 2000 20:30:13 GMTE2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: Re: Freeware MIME, Message-ID: <8co4sl$bij@gap.cco.caltech.edu>  ` In article <38ee6cbc_1@dilbert.ic.sunysb.edu>, jlauret@?.chem.sunysb.edu (Jerome LAURET) writes: >aI >	Oups ! And I forgot to specify that indeed sys$system:mime.exe is thereu >on OpenVMS7.2 and up ...3  L Never tried it.  The messages it sends cannot be read by regular MIME aware K programs on nonVMS platforms.  To which I say, why bother with a tool that aJ cannot achieve the minimum functionality required for 2 way communication?  F Extraction of messages from them should be ok.  This is documented in:  < $ help/library=SYS$COMMON:[SYSHLP]MIME$HELP.HLB;1 over restr   Regards,   David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech i   ------------------------------  % Date: Sat, 08 Apr 2000 14:48:27 -0500r% From: Chris Scheers <asi@airmail.net>a; Subject: Re: Galaxy (or perhaps Wildfire) and shared memory/O Message-ID: <7DB82C9167CA9ADB.C28F5D67EFBA4E40.77ECF7ACBABA2B41@lp.airnews.net>a   Bill Todd wrote: > 2 > Chris Scheers <asi@airmail.net> wrote in messageK > news:21685555D1262E29.AA372B211D0D206C.88434F3685342C02@lp.airnews.net...0 >  > ...  > A > > When I looked into this once, I found that there are hardwarecC > > multiprocessor write back caching schemes which will ensure the25 > > integrity of both local caches and global memory.e > > K > > Disclaimer: I'm not a hardware guru, so I may have some of these pointse
 > > wrong. > >p: > > For this to work correctly, several things must occur. > >nJ > > 1) The cache should maintain a dirty bit, i.e., whether or not a value+ > > in the cache has been modified locally.e > >EK > > 2) The cache must snoop the memory bus to see what other processors aret
 > > doing. > > K > > 3) If some other processor writes to a location in the local cache, thenL > > current value in the cache must either be invalidated or replaced by the > > written value. > > I > > 4) If some other processor reads from a location that is dirty in thewK > > local cache, the read must be pended while the location is written from-H > > the local cache to global memory, then the read can proceed with the > > updated value. > > J > > I believe that a major part of the SMP support hardware is involved inF > > satisfying these requirements.  This mechanism is SMP specific andJ > > Galaxy independent.  It does not care how a Galaxy operates.  The viewD > > of global memory should remain correct indpendently from what is > > currently cached.e > H > The difference between normal SMP operation and Galaxy (or perhaps SunM > 'domain' or S/390 'hardware-partitioned') operation is that when a hardware = > fault occurs in a 'normal' SMP, the entire system stops and64 > cache/main-memory coherence ceases to be an issue. > M > In a Galaxy, if a fault disables a cache that is holding dirty data that no L > other processor has yet expressed an interest in, then that data is lost -C > but subsequent use of the related but unupdated memory can occur.t > L > Hoff just reminded me that the required explicit use of memory barriers inL > Alpha environments may make this a non-issue (at least in any sense beyondK > the issue that already must be addressed explicitly in 'normal' Alpha SMPhM > configurations - where processor and cache hardware failures bring down the L > entire system - to keep shared memory consistent).  But there are some SMPJ > environments that do not require such explicit handling of shared-memoryH > consistency - which may well make those environments considerably moreF > difficult to adapt to inter-partition memory sharing with good faultH > isolation (though I suspect that simply disabling caching or even justL > write-back caching of inter-partition shared memory may be sufficiently to > address such difficulties).      -----------------s  G In the Alpha Architecture Handbook (4/92), page 5-4, section "Cache andt. Write Buffers", the following points are made:  E 1) Write buffers may be used to delay and aggregate writes.  From theyB viewpoint of another processor, buffered writes appear not to haveF happened yet.  (Write buffers must not delay writes indefinitely.  SeeF Timeliness. [I didn't find this section.  I probably just missed it.])  F 2) Write-back caches must be able to detect a later write from another5 procesor and invalidate or update the cache contents.   A 5) A processor must guarantee that all of its previous writes arehG visible to all other processors before a HALT instruction completes.  ApF processor must guarantee that its caches are coherent with the rest of) the system before continuing from a HALT.N   -----------------v  D Page 5-19, section "Implications for Hardware", selected paragraphs:  E The coherency point for physical address x is the place in the memory B subsystem at which accesses to x are ordered.  It may be at a mainH memory board, or at a cache containing x exclusively, or at the point of! winning a common bus arbitration.r  F The coherency point for x may move with time, as exclusive access to x0 migrates between main memory and various caches.  H MB and IMB force all preceding writes to at least reach their respectiveG coherency points.  This does not mean that main-memory writes have beenbC done, just that the order of the eventual writes is committed.  For = example, on the XMI with retry, this means getting the writes F acknowledged as receved with good parity at the inputs to memory board, queues; the actual RAM write happens laters.   -----------------i  H It appears that MB by itself doesn't solve the problem.  MB just ensuresE that all pending memory accesses complete before any new accesses area4 started.  This serves to serialize access to memory.  H As I read this, MB does NOT require that the data be flushed to physicalF memory.  If the coherency point is the cache, MB just ensures that theG data has been moved from the Alpha to the cache.  If the cache hardwarew then fails, the data is lost.a  G -----------------------------------------------------------------------o$ Chris Scheers, Applied Synergy, Inc.  G 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asi@airmail.neti   ------------------------------  $ Date: Sat, 8 Apr 2000 18:26:03 -0400' From: "Bill Todd" <billtodd@foo.mv.com> ; Subject: Re: Galaxy (or perhaps Wildfire) and shared memory<( Message-ID: <8cobih$5i7$1@pyrite.mv.net>  0 Chris Scheers <asi@airmail.net> wrote in messageI news:7DB82C9167CA9ADB.C28F5D67EFBA4E40.77ECF7ACBABA2B41@lp.airnews.net...n   ...t  I > In the Alpha Architecture Handbook (4/92), page 5-4, section "Cache andr0 > Write Buffers", the following points are made: > G > 1) Write buffers may be used to delay and aggregate writes.  From thefD > viewpoint of another processor, buffered writes appear not to haveH > happened yet.  (Write buffers must not delay writes indefinitely.  SeeH > Timeliness. [I didn't find this section.  I probably just missed it.]) >tH > 2) Write-back caches must be able to detect a later write from another7 > procesor and invalidate or update the cache contents.d  K I think that has to mean "... must be able to detect a later write *to mainsJ memory* (as opposed to some cache level) from another processor...":  thatE presumably would use the same notification mechanism that invalidatespK 'clean' cached data when it's modified in main memory by another processor,eG so no additional inter-cache connections would be required (it all getsn, coordinated through the main memory system).  I ... except that this would imply that if two processors both wrote to therK same memory location and coherency is handled as you quote below, MBs would D not provide any way to ensure which write 'won', since that would beI determined at some later time by which write happened to get de-staged to-J main memory first, so in that context it's not clear how to manage without" direct inter-cache connectivity...   > C > 5) A processor must guarantee that all of its previous writes are6I > visible to all other processors before a HALT instruction completes.  AsH > processor must guarantee that its caches are coherent with the rest of+ > the system before continuing from a HALT.e >G > -----------------a > F > Page 5-19, section "Implications for Hardware", selected paragraphs: > G > The coherency point for physical address x is the place in the memorydD > subsystem at which accesses to x are ordered.  It may be at a mainJ > memory board, or at a cache containing x exclusively, or at the point of# > winning a common bus arbitration.- >-H > The coherency point for x may move with time, as exclusive access to x2 > migrates between main memory and various caches.  J May just be dense today, but I'm having a difficult time figuring out justJ how this knowledge of per-cache-line exclusivity is maintained (especiallyG in the presence of 'blind' writes), let alone who maintains it.  If therG answer to the latter is 'the main memory system', then it would seem to5K require a bit (or possibly just a count field, but that gets awkward in the H presence of failures you don't want to reboot the entire system for) perI processor per cache line, potentially consuming almost as much RAM as the@F RAM it's tracking, and that still doesn't address blind writes (thoughL main-memory-level informational exchanges for them might usually be maskableK behind other activity, since they'd only have to have completed by the timeyE the next MB occurred).  If the answer is 'inter-cache snooping', then-/ inter-cache connectivity raises its head again.r   >nJ > MB and IMB force all preceding writes to at least reach their respectiveI > coherency points.  This does not mean that main-memory writes have beenmE > done, just that the order of the eventual writes is committed.  ForC? > example, on the XMI with retry, this means getting the writeseH > acknowledged as receved with good parity at the inputs to memory board. > queues; the actual RAM write happens laters.  E This specific example at least gets the data to a universally-centralsH location that can ensure consistent access to it - it's the times it may4 *not* get to such a location that I'm worried about.   >  > -----------------o >.J > It appears that MB by itself doesn't solve the problem.  MB just ensuresG > that all pending memory accesses complete before any new accesses are 6 > started.  This serves to serialize access to memory.   Only by that one processor.h   >uJ > As I read this, MB does NOT require that the data be flushed to physicalH > memory.  If the coherency point is the cache, MB just ensures that theI > data has been moved from the Alpha to the cache.  If the cache hardwareC > then fails, the data is lost.n  F If that's true, then I think the kind of undetectible corruption I was7 worried about could in fact occur in the contents of anuL inter-partition-shared memory region if a partition accessing it experiencedH a failure that kept cached dirty data from being written back after thatG modification had *logically* been committed to main (shared) memory (byvL release of the relevant software interlocks).  And if so that's a bad thing.  J But it would not surprise me excessively if existing Alpha implementationsL were more conservative such that the problem could not in fact occur even ifG the architecture specification allows implementations in which it couldn occur.  D Thanks for taking the time I didn't take to pursue this.  It's stillI entirely possible that it's a non-issue, but that's not yet clear (though.K Hoff's statements have pretty high reliability and it may well be that just2K a bit more explanation is required - if he or someone else has the patiencev to provide it).    - bill   >sI > ----------------------------------------------------------------------- & > Chris Scheers, Applied Synergy, Inc. >(I > 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asi@airmail.net    ------------------------------   Date: 8 Apr 2000 19:41:43 GMT & From: Cthulhu <cthulhu@kadath.deep.it>E Subject: Re: Hobbyist VMS V7.2 TK50 DECnet-Plus installation failure?e( Message-ID: <8co21n$53$1@kadath.deep.it>   sms@antinode.org wrote:o  J >    I've recently been playing with putting the Hobbyist VMS V7.2 CD-ROM H > installation kit onto TK50 tape.  After extracting the data concerning  C Is it workable to get a step-by-step list of things to do to create ) bootable TK50 installation tapes from CD?d7 Just for knowledge, until I'll get more time to play...u  	 	copying,c
 	  Cthulhu   --    G        Ph'nglui mglw'nafh Cthulhu http://www.rlyeh.it wgah'nagl fhtgan!e% 		       <cthulhu at flashnet dot it>n   ------------------------------  + Date: Sat, 08 Apr 2000 16:11:37 -0500 (CDT)e From: sms@antinode.orgE Subject: Re: Hobbyist VMS V7.2 TK50 DECnet-Plus installation failure?r) Message-ID: <00040816113703@antinode.org>H  & From: Cthulhu <cthulhu@kadath.deep.it>  E > Is it workable to get a step-by-step list of things to do to create + > bootable TK50 installation tapes from CD?c9 > Just for knowledge, until I'll get more time to play...t  E    Sure, but I normally deal only with people who provide a real name6 and a working e-mail address.e  ' ---- Transcript of session follows ----n9 %TCPIP-E-SMTP_UNKHST, remote host unknown, kadath.deep.it4, -SYSTEM-F-NOSUCHNODE, remote node is unknown      Call me eccentric.l  H ------------------------------------------------------------------------  C    Steven M. Schweda               (+1) 651-699-9818  (voice, home)-C    382 South Warwick Street        (+1) 763-781-0308  (voice, work) G    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work)t9    sms@antinode.org                sms@provis.com  (work)    ------------------------------  % Date: Mon, 03 Apr 2000 03:54:29 -0700 < From: Chris Doran <chrisj.doranNOchSPAM@physics.org.invalid>& Subject: Re: Manuals for DEC 3000-400s9 Message-ID: <1f7a3c18.de53e620@usw-ex0106-047.remarq.com>r  : In article <HYKF4.32753$dc2.320996@news0.telusplanet.net>,$ "Craig Wood" <cswood@agt.net> wrote:? >Does anyone know where I can get on-line manuals, user guides,c	 etc for aa% >DEC 3000-400s (aka Sandpiper) Alpha?i >aA >There are on-line guides for the 3000-600, etc. but not the 400.S >m? >From what I can tell the 600 seems similar to the 400 with thep exception of? >CPU speed, bus speed and SCSI through-put. Could I assume thata the 600o >manual would suffice?  @ I haven't done a page-by-page comparison :-), but they (I assume@ you mean the Owner's Guides) look pretty similar on the basis of a few spot checks.   Chrisf    L * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *G The fastest and easiest way to search and participate in Usenet - Free!s   ------------------------------   Date: 9 Apr 2000 06:50:55 GMTe- From: djweath@attglobal.net (Dave Weatherall)<+ Subject: Re: Pascal Compile-TIme stack dumpc5 Message-ID: <DTiotGxQ0bj6-pn2-H4CyxuRw5s9Q@localhost>2  E On Sun, 7 Apr 3900 00:43:00, carl@gerg.tamu.edu (Carl Perkins) wrote:d  / > Assuming the subject line is correct, then...  > K > My guess would be that you are trying to use a Pascal compiler to compile  > a program written in Fortran.  > = > The above looks like Fortran. It does not look like Pascal.e > In Pascal you'd have >  >   NPNT := NLEG+I;c > 
 > instead of e >  >   NPNT = NLEG+Ig > N > I.E. in Pascal the assignment operator is ":=" not "=" and statements end inL > semicolons. In Pascal the "=" operator is a relational operator (like "==" > in C, or .EQ. in Fortran).   Hi Carl @                 yes that would have been a dumb thing to do :-) 7 However, I had originally responded to a query about :-   F       my pascal module has always compiled but now with latest version0 of the compiler it crashes the compiler instead.  D I'd had a similar experience with the code snippet shown, using the B V7.1 Fortran compiler and had been trying to indicate the kind of C things the optimiser had trouble with to give Michael a clue as to * what he might look for.    Cheers - Dave.   ------------------------------  $ Date: Sun, 2 Apr 2000 16:58:32 -0400+ From: "David Turner" <d_b_turner@yahoo.com>- Subject: So who will buy VMS ?/ Message-ID: <sefd0iqfeop106@corp.supernews.com>i  J All said and done - it certainly seems as though the Almighty Q is panningH for one it's fellow demi-gods and will undoubtedly dump it's last trusty
 disciple, VMS.   Who's gonna buy it ?   AT&T ?	 Siemens ?s  1 Someone's got to make an offer the Q can't refusee  L Curious, because I have seen an obvious drop on our Online-DEC-Broker trades in VMS systems  J From this time last year, every dealer in the US and Europe were trying to buy USED VMS ALpha's and Vaxen  G Now, the mostpart are buying Proliants and the base Tru64 Alpha systemsx   What's gonna happen ?      -- David Turner Island Computers US Corporationb 2700 Gregory StreetL Savannah GA 31404v Tel: 912 447 6622, Fax:912 201 0096 sales@islandco.com   ------------------------------  # Date: Mon, 03 Apr 2000 01:41:19 GMTh7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> " Subject: Re: So who will buy VMS ?- Message-ID: <38E7F766.AB8E7E8A@earthlink.net>o   David Turner wrote:  > L > All said and done - it certainly seems as though the Almighty Q is panningJ > for one it's fellow demi-gods and will undoubtedly dump it's last trusty > disciple, VMS  >  > Who's gonna buy it ?  D Well, I'm still researching the possibility of organizing a group of? investors and/or some combination of leveraged/employee buyout.u  D Compaq may not live or die by OpenVMS (an arguable point - let's notG argue it here, huh?). My feeling is that if owned by poeple who DO live E or die by OpenVMS, OpenVMS's future would be driven more by marketing E than by it's character as a "cash cow". The problem is that Compaq is E milking the cash cow without nourishing it with aggressive, pointedlyeD effective marketing. So, it must eventually starve to death. This isA inevitable, and anyone who denies it is only kidding him/herself.o    Denizens of the "Q" take notice:  F We who have already been displaced or lost our jobs due to our OpenVMSE systems being replaced by Solaris, NT, AIX, OS/400, UN*X, Linux, etc.aE know only too well the importance of marketing OpenVMS, and result ofs the Q's failure to do so.a  F Please don't be so naive as to think "it can't happen to us". The manyF "former digits" out here in the "real world" can - and often do - post+ their experiences, both here and elsewhere.r   -- f David J. Dachterar dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/h   ------------------------------  " Date: Mon, 3 Apr 2000 03:21:17 GMT* From: young_r@eisner.decus.org (Rob Young)" Subject: Re: So who will buy VMS ?& Message-ID: <2000Apr2.232117.1@eisner>  b In article <38E7DFBE.CBF09F99@vl.videotron.ca>, JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes: > Rob Young wrote:L >>         Your premise is fatally flawed.  VMS is a very profitable segment# >>         for Compaq.  Get a clue.  > O > Spinning off VMS would be seen as an attempt to boost it back up. Selling VMShT > would be seen as trying to get rid of something that isn't critical or profitable. > ( 	He mentions sell, doesn't say spin off.   				Robl   ------------------------------   Date: 3 Apr 2000 11:01:58 GMTa+ From: "Gerke Grashuis" <g.grashuis@kpn.com>h Subject: Re: split large files8 Message-ID: <01bf9d5c$07b9c370$8d4c15ac@hktgn9911301604>  * Better get an update for your zip utility.I I'm using G(UN)ZIP 1.2.4 on VMS systems and have seen it pack files of 10  GB and greater!P   Gerke.  A MariuszM <Mariusz.Macherzynski@zks.skoczow.pl> schreef in artikel ) <YXZF4.28728$a01.607641@news.tpnet.pl>...iI > I have one sequential file (more than 2GB, record format - fixed lengths 8800 > byte)d > I want to pack it by zipH > but earlier I have to split this file into two smaller parts - because zipn) > doesn't work on files larger than 2 GB.nF > Could someone tell me how to split this file (and of course merge it later)?c > 	 > regardso > Mariusz Macherzynski, > email: Mariusz.Macherzynski@zks.skoczow.pl >  >  >    ------------------------------  # Date: Mon, 03 Apr 2000 00:49:12 GMTo7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>p% Subject: Re: Suggestion for authorize - Message-ID: <38E7EB30.CAC2A11E@earthlink.net>e   "Richard B. Gilbert" wrote:i > M >         Most of the problems with AUTHORIZE can be solved with a simple DCLtL > shell.  I wrote one around 1984-1985 and have been tweaking it ever since.J > It creates the account.  It creates the user's directory with the properH > ownership and what I think are the proper protections.  It gives him a> > skeleton LOGIN.COM.  It sets up a [.MAIL] subdirectory, etc.  + Here's a challenge I've had more than once:   B For a collection of users not easily identifiable (hundreds of UAFC records), increase process quotas to certain minimum values withoutdG depriving accounts which already have quotas in excess of the minimums.o  G The ability to select records by such critera is extremely limited, anduH usually possible only through such unsupported methods as Datatrieve and DCL.  B Maybe the minimum would be a program (DCL proc.?) to interpret theE appropriate macros and convert them to Datatrieve record definitions.w  G I dunno - it just seems to me that there should be an easier way. 'BoutmH the only option available is to tweak the PQL_Mmumble param.'s which, ofE course impacts the system globally - not always what you want/need tos do.s   -- g David J. Dachteraw dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/e   ------------------------------  % Date: Sat, 08 Apr 2000 14:07:53 -0400e0 From: JF Mezei <jfmezei.spamnot@vl.videotron.ca>/ Subject: Re: Sun considers VMS a "mainframe" OS / Message-ID: <38EF7574.B741CA76@vl.videotron.ca>    Curtis Rempel wrote:N > And if you're lucky, you can spot one on Ebay now and then for a few hundred > bucks. > G > Or just a CPU module to show your kids and unimpress your wife:   ;-)i > C >  http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=299634281-    M Could I fit that 9000 CPU module in my MicroVAX-II Q-BUS ?????  Wouldn't that-< at least tripple performance of my all mighty Microvax II ?    :-) :-) :-) :-) ;-) ;-) :-) ;-)0   ------------------------------  $ Date: Sat, 8 Apr 2000 14:26:04 -0400+ From: "Main, Kerry" <Kerry.Main@Compaq.com></ Subject: RE: Sun considers VMS a "mainframe" OSiJ Message-ID: <910612C07BCAD1119AF40000F86AF0D8052841CE@kaoexc4.kao.dec.com>   Hello Malcolm -B  K >>> I think the last is the closest answer. I've always been told that it's,K the I/O architechture of "mainframes" which tends to differentiate them,<<<d  I Well, a fully loaded Wildfire will support 224 PCI slots spread across 64hA PCI buses, 12.8Gb/sec Global bandwidth, so this should improve IO  capabilities....J http://www.digital.com/alphaserver/announce/oct99_general.html#performance   :-)'  
 Kerry Main Senior Consultant,
 Compaq Canada) Professional Servicesa Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.coml       -----Original Message-----4 From: dunnett@mala.bc.ca [mailto:dunnett@mala.bc.ca]& Sent: Thursday, April 06, 2000 3:01 PM To: Info-VAX@Mvb.Saic.Come/ Subject: Re: Sun considers VMS a "mainframe" OSw    0 In article <38ECD343.19D395A3@vl.videotron.ca>, 4   JF Mezei <jfmezei.spamnot@vl.videotron.ca> writes:  I > Ok, someone please explain to me why VMS/ALPHA is not considered in theb same" > class as IBM/390/MVS machines ?  > " > Isn't Alpha a faster processor ?4 > Do IBM disk drives have far superior performance ?J > Is is a question of the bus which is much faster on IBM than on Alphas ? > J    I think the last is the closest answer. I've always been told that it'sH the I/O architechture of "mainframes" which tends to differentiate them,  not things like processor speed.  I    However I suspect in this case "mainframe" is being used strictly in avD perjorative, rather than technical, sense ( as in "you don't want anG obsolete, legacy 'mainframe' O/S like VMS, you want a state-of-the-art,  'open' O/S like Solaris" )   ------------------------------   End of INFO-VAX 2000.198 ************************