0 INFO-VAX	Thu, 05 Feb 2004	Volume 2004 : Issue 71      Contents:! Re: cURL 7.11.0 available for VMS < DECserver(tm) Trade-Up Promotion ~ Now through June 30, 20042 Re: Does iSCSI infringe on any MSCP patents or IP? RE: Hobbyist questions? ? Re: Is Encompass a member of Interex (was : Hobbyist questions) . ITRC with Mozilla, was Re: Moderate this group2 Re: ITRC with Mozilla, was Re: Moderate this group J F discusses child sexuality ! Re: J F discusses child sexuality $ Just making sure that  you are aware Re: License questions?% LK401-AA keyboard - no PS2 connector. ) Re: LK401-AA keyboard - no PS2 connector.  Re: Moderate this group  Re: Moderate this group  Re: Moderate this group  Re: Oracle 9.2.0.2 installP Re: Oracle Rdb and RMU/BACKUP/DENSITY (was: Re: HOW MANY BPI DOES A DLT7000 WRITC Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ????? C Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ????? C Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ????? C Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ????? ( Re: Print Queue to FAX/E-mail Solutions?( RE: Print Queue to FAX/E-mail Solutions? Re: Problem with Ghost Script  Re: Problem with Ghost Script  RE: Problem with Ghost Script  Problems with File Access Dates # Re: Problems with File Access Dates # Re: Problems with File Access Dates # Re: Problems with File Access Dates # Re: Problems with File Access Dates ? SYS$STARTUP:MMOV$SHUTDOWN.COM -- Insufficiently discriminating? C Re: SYS$STARTUP:MMOV$SHUTDOWN.COM -- Insufficiently discriminating? ! Re: VMS runs well on HP Superdome P WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - Sun AP Re: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - SP Re: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - SP Re: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - S Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? RE: Why was VAX abandonned ? RE: Why was VAX abandonned ? RE: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? RE: Why was VAX abandonned ? Re: Why was VAX abandonned ? Re: Why was VAX abandonned ? RE: Why was VAX abandonned ? RE: Why was VAX abandonned ? Re: Why was VAX abandonned ?
 RE: ZIP/UNZIP 
 Re: ZIP/UNZIP ) Re: [OT but useful] Kaspersky antivirus ? ) Re: [OT but useful] Kaspersky antivirus ? ) RE: [OT but useful] Kaspersky antivirus ?   F ----------------------------------------------------------------------  % Date: Thu, 05 Feb 2004 07:46:59 +0100  From: Dirk Munk <munk@home.nl>* Subject: Re: cURL 7.11.0 available for VMS2 Message-ID: <bvspnl$p54$1@news2.tilbu1.nb.home.nl>  < >>   Curl is a command line tool for transferring files with; >>   URL syntax, supporting FTP, FTPS, HTTP, HTTPS, GOPHER, 5 >>   TELNET, DICT, FILE and LDAP. Curl supports HTTPS 6 >>   certificates, HTTP POST, HTTP PUT, FTP uploading,8 >>   kerberos, HTTP form based upload, proxies, cookies,= >>   user+password authentication, file transfer resume, http : >>   proxy tunneling and a busload of other useful tricks. >>= >>I haven't tested all the features, since I only use it for  : >>HTTP(S), but it does compile and link cleanly on all the >>platforms outlined above.  >  >  > B > Kudos to Marty... This is how unix tools ported to VMS should beA > announced.  Many here may not be well versed on all things unix B > and an explaination of the package (any package for that matter,B > unix ported or otherwise) is a welcome addition to the announce- > ment.  >  > --D > http://www.legacy-2000.com  for the *best* OpenVMS system securityE >                             solutions that others only claim to be.    My thanks to Marty as well. Q It is indeed a very nice tool if you want to download files to a VMS system, and  0 you don't have a browser running on that system.  < This is how a typical command line for Curl could look like:  P $curl "http://Some-Website.com/Some%20File.dat" --output "[output]Some_File.dat"   Don't forget the double quotes!   L If you want to preserve the case for the output file (on a ODS-5 disk), you 9 obviously will have to run your process in extended mode:   " $set process /parse_style=extended  / and you will need to set the following logical:   % $define DECC$EFS_CASE_PRESERVE ENABLE   A (for newbies: ODS-5 is only supported on Alpha and IA64, not Vax)    ------------------------------   Date: 5 Feb 2004 08:33:20 -0800 1 From: susan_skonetski@hotmail.com (Sue Skonetski) E Subject: DECserver(tm) Trade-Up Promotion ~ Now through June 30, 2004 = Message-ID: <857e9e41.0402050833.1c7784d2@posting.google.com>    Dear Newsgroup,   E I recevied this today and wanted to pass it along.  I used to work in E the Networking group at DEC and we had some really great products its ) nice to know that the heritage continues.    Warm Regards as always,  Sue     V Web: www.dnpg.com ____________________________________________________________________      @ Ensuring network availability is critical to your organization'sB success. Recognizing this, Digital Networks continues to deliver a@ comprehensive suite of Device and Console Management products toE provide you multiple ways to remotely and securely monitor and manage & your network from anywhere at anytime.  @ As the only manufacturer of DECserver(tm) hardware and software,D Digital Networks is continually refining our DECserver(tm) family ofB products based on the invaluable customer feedback we receive fromD you, the world's largest installed terminal and console server base.B We are proud to consistently offer you newer, replacement productsE with equivalent and/or additional hardware and software functionality   your IT infrastructure requires.  < From now until June 30, 2004, Digital Networks is offering a@ substantial credit toward the purchase of a new DECserver(tm) or> CServer product when you trade-in any one of our DECserver(tm) products listed below.  , Model                           Part Number ! DECserver 200           DSRVB-**  ! DECserver 300           DSRVF-**   DECserver 500           DSRVS 0 DECserver 700-08        DSRVW-A*; -B*; -E*; -F* 0 DECserver 700-16        DSRVW-C*; -D*; -G*; -H* ! DECserver 90L           DSRVD-**  ! DECserver 90L+          DSRVG-**  ! DECserver 90TL          DSRVE-**  ! DECserver 90M           DSRVH-**    F Looking for more functionality at affordable prices? Take advantage ofC this limited time offer!The DECserver(tm) family today includes the < 8-Port DECserver(tm) 90M+, 8-port DECserver(tm) 708, 16-PortA DECserver(tm) 716, the 32-Port DECserver(tm) 732, and the 32-Port D DECserver(tm) 900TM. The CServer family includes the 16-Port CServer 16 and the 32-Port CServer 32.  9 Contact your Authorized Digital Networks Reseller or call E +1-877-351-9594 and a Digital Networks Sales Representative will help 3 you determine which model will best fit your needs.   4 For terms and conditions please visit our website at- http://www.digitalnetworks.net/promotions.htm    ------------------------------   Date: 5 Feb 2004 02:11:33 -0800 . From: fabiopenvms@yahoo.com.br (Fabio Cardoso); Subject: Re: Does iSCSI infringe on any MSCP patents or IP? = Message-ID: <f30679fb.0402050211.1341e264@posting.google.com>   ~ "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net> wrote in message news:<40219C4F.E5A9CA95@NeOaSrPtAhMlNiOnWk.net>... > Paul Repacholi wrote:  > > 3 > > Kilgallen@SpamCop.net (Larry Kilgallen) writes:  > > b > > > In article <87oesjh28z.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes: > > > D > > >> The interesting thaing, is IBM have pulled back in a big way, > > >   > > > What do you mean by that ? > > C > > There was a big iSCSI bakeoff recently. Report was that IBM had C > > not shown, and had pulled back from all iSCSI stuff. No reasons  > > or insight given though. > E > I would think that iSCSI would only be of value over (multi)gigabit  > ethernet.   C Is iSCSI virus free ? I dont want  a DoS in a iSCSI "network" if it E will be shared with LAN. By the way... may be its a good way to have  inter-serverF connection. No use of the LAN anymore for server-to-server operations.F May be iSCSI will change the way we have networking. iSCSI WAN Routers etc...   REgards    FC   ------------------------------  $ Date: Thu, 5 Feb 2004 06:44:23 -0700B From: "Tillman, Brian (AGRE)" <Brian.Tillman@smiths-aerospace.com>  Subject: RE: Hobbyist questions?O Message-ID: <11721EF39C7D7F47A55447158274CAF79A3D08@cossmgmbx01.email.corp.tld>    Didier Morandi wrote:    > http://www.encompassus.org/   > "Encompass, an HP User Group". >=0D" > http://www.interex.org/home.htmlG > "Interex, the International HP Customer Community, is an independent, B > not for-profit association providing information, education, and3 > advocacy services to members all over the world".   E How does showing that Encompass US and Interex share common interests 1 imply that they're part of the same organization?  --=0D  Brian Tillman        =0D Smiths Aerospace 3290 Patterson Ave. SE, MS 1B3 Grand Rapids, MI 49512-1991 > Brian.Tillman is the name, smiths-aerospace.com is the domain.	       =0D : I don't speak for Smiths, and Smiths doesn't speak for me.      * ******************************************G The information contained in, or attached to, this e-mail, may contain= D  confidential information and is intended solely for the use of the=G  individual or entity to whom they are addressed and may be subject to= H  legal privilege.  If you have received this e-mail in error you should=H  notify the sender immediately by reply e-mail, delete the message from=L  your system and notify your system manager.  Please do not copy it for any=F  purpose, or disclose its contents to any other person.  The views or=I  opinions presented in this e-mail are solely those of the author and do= G  not necessarily represent those of the company.  The recipient should= I  check this e-mail and any attachments for the presence of viruses.  The= A  company accepts no liability for any damage caused, directly or= 4  indirectly, by any virus transmitted in this email.* ******************************************   ------------------------------  % Date: Thu, 05 Feb 2004 09:42:12 -0600 / From: Clay M. Denton <denton@orison.dsserv.com> H Subject: Re: Is Encompass a member of Interex (was : Hobbyist questions)8 Message-ID: <40p420lk04vmag317j0ggbe8h76kbentjv@4ax.com>  P I don't want to have a discussion over any organizations use of marketing terms.  L The 3 organizations you have listed are separate corporations, with separateM membership bases, representing different portions of the "HP User Community".    Clay  G On Wed, 04 Feb 2004 21:44:56 +0100, Didier Morandi <no@spam.com> wrote:    >http://www.encompassus.org/ >"Encompass, an HP User Group".  > ! >http://www.interex.org/home.html K >"Interex, the International HP Customer Community, is an independent, not  P >for-profit association providing information, education, and advocacy services   >to members all over the world". >  >http://www.hp-interex.org/ K >"HP-Interex EMEA, the newly-formed federation of HP user groups in Europe  Q >resulting from the merger of the Compaq Users Organisation EMEA (formerly DECUS  K >Europe) and interex Europe (the HP Enterprise User Group), represents the  Q >largest body of Enterprise System Users in the EMEA region, uniting over 70 000   >IT professionals".  >   >EMEA today, Worldwide tomorrow.L >Tell us how an HP User Group could not be a member of the International HP  >Customer Community, Clay. >  >D.  >  >  >Clay M. Denton wrote:9 >> Encompass and Interex are VERY separate organizations.  >>   >> Clay Denton >> Director  >> Encompass US, Inc.  >>   ------------------------------  % Date: Thu, 05 Feb 2004 14:05:09 +0000 * From: Nic Clews <sendspamhere@[127.0.0.1]>7 Subject: ITRC with Mozilla, was Re: Moderate this group ' Message-ID: <bvtijf$8il$1@lore.csc.com>    Chris Sharman wrote: >  > > http://www.itrc.hp.com > > B > And you have to be using Microsoft Internet Explorer to do that.% > I tried with Mozilla & got nowhere. H > I emailed, and got an email back suggesting I phone someone in the US.E > I expressed disbelief, and got a pointer to a webpage with assorted  > international numbers on it.G > I forget what I wanted off their site now, but it wasn't worth _that_  > much hassle.  A I use Mozilla 1.4 on VMS for ITRC and it works fine. I've had one F support call to the ITRC folks in the Netherlands handled OK, this wasG regarding accessing the VMS related former FTP portions properly from a  supported VMS platform.    --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  % Date: Thu, 05 Feb 2004 14:48:23 +0000 0 From: Chris Sharman <chris.sharman@sorry.nospam>; Subject: Re: ITRC with Mozilla, was Re: Moderate this group 4 Message-ID: <bvtl3n$kgf$1$8300dec7@news.demon.co.uk>   Nic Clews wrote:   > Chris Sharman wrote: >  >>>http://www.itrc.hp.com  >>>  >>B >>And you have to be using Microsoft Internet Explorer to do that.% >>I tried with Mozilla & got nowhere. H >>I emailed, and got an email back suggesting I phone someone in the US.E >>I expressed disbelief, and got a pointer to a webpage with assorted  >>international numbers on it.G >>I forget what I wanted off their site now, but it wasn't worth _that_  >>much hassle. > C > I use Mozilla 1.4 on VMS for ITRC and it works fine. I've had one H > support call to the ITRC folks in the Netherlands handled OK, this wasI > regarding accessing the VMS related former FTP portions properly from a  > supported VMS platform.   H OK, I'll take it back - second time around, taking the minimal path, it H worked. First time, I filled in everything, then instead of giving me a % userid, it took me to the login page.    Chris    ------------------------------  + Date: Thu,  5 Feb 2004 13:51:57 +0100 (CET) . From: starwars <nobody@tatooine.homelinux.net>& Subject: J F discusses child sexualityE Message-ID: <cc5e143e0f3032f1f793eb9c7c1cb295@tatooine.homelinux.net>   = JF Mezei <nobody@nobody.org> discusses his favorite subjects:    >BTR1701 wrote: D >> How does seeing a part of the human body make a child delinquent? > N >If it gives the little boy an erection, the little kid is then more likely toL >learn about masturbation before age 18, and in the USA, masturbating before1 >that age is not considered acceptable as per the / >bible-belt/moral-majority/family-values thing.  > M >So, parents all over the United States should sue CBS/Timberlake/Jackson for 5 >having prematurely awakened their son's sexual life.  > L >And there is a financial cost to this too. The earlier your son is sexuallyO >awakened, the earlier he might get a girlfriend pregnant which would force the N >parents to wed the boy with that teenage girl to conserve the appearance of a4 >proper family with no children born out of wedlock. > N >And if parents are forced to prematurely cash in their savings to pay for theO >wedding, it messes with their financial planning which had predicted a wedding L >much later. So there is a financial cost to parents. And if the cost of theJ >teenage wedding takes away the money that would have gone towards collegeG >tuition, then the son may end up a waiter instead of a doctor, costing G >millions in revenus over the child's lifetime. One more reason to sue.  > J >And since Superbowl is seen by millions of children, when you repeat thisL >story a million times, it will seriously affect the USA economy since thereL >will be million fewer highly educated males which will cost the USA much inL >terms of innovation and industrial leadership since all males who have seenJ >Jackson's tit will end up bums and waiters with teenage wives and babies. > M >Therefore, the Bush regime should also sue Jackson/Timberlake for having set O >in motion something which will seriously damage the USA economy in the future.  > L >The one positive aspect of this is that it will help with birth rates sinceO >you'll have plenty of teenagers having babies before they learn about condoms, C >which will result in a higher number of average babies per family.  > J >In conclusion, it is clear that this small tit exposure will cost the USAL >massive damage to the current and next generation americans whose life will >have changed due to this. > K >(outside the USA, this will have no effect since seing a tit is considered * >good to to a son's development/education)   ------------------------------  # Date: Thu, 05 Feb 2004 13:06:58 GMT A From: "Gregory Morrow" <gregorymorrowTHEPAJAMAGAME@earthlink.net> * Subject: Re: J F discusses child sexualityC Message-ID: <SdrUb.10836$jH6.3814@newsread1.news.atl.earthlink.net>    starwars wrote:   ? > JF Mezei <nobody@nobody.org> discusses his favorite subjects:  >  > >BTR1701 wrote: F > >> How does seeing a part of the human body make a child delinquent? > > F > >If it gives the little boy an erection, the little kid is then more	 likely to G > >learn about masturbation before age 18, and in the USA, masturbating  before3 > >that age is not considered acceptable as per the 1 > >bible-belt/moral-majority/family-values thing.  > > K > >So, parents all over the United States should sue CBS/Timberlake/Jackson  for 7 > >having prematurely awakened their son's sexual life.  > > E > >And there is a financial cost to this too. The earlier your son is  sexuallyG > >awakened, the earlier he might get a girlfriend pregnant which would 	 force the K > >parents to wed the boy with that teenage girl to conserve the appearance  of a6 > >proper family with no children born out of wedlock. > > L > >And if parents are forced to prematurely cash in their savings to pay for the I > >wedding, it messes with their financial planning which had predicted a  wedding J > >much later. So there is a financial cost to parents. And if the cost of the L > >teenage wedding takes away the money that would have gone towards collegeI > >tuition, then the son may end up a waiter instead of a doctor, costing I > >millions in revenus over the child's lifetime. One more reason to sue.  > > L > >And since Superbowl is seen by millions of children, when you repeat thisH > >story a million times, it will seriously affect the USA economy since there K > >will be million fewer highly educated males which will cost the USA much  inI > >terms of innovation and industrial leadership since all males who have  seenL > >Jackson's tit will end up bums and waiters with teenage wives and babies. > > K > >Therefore, the Bush regime should also sue Jackson/Timberlake for having  set I > >in motion something which will seriously damage the USA economy in the  future.  > > H > >The one positive aspect of this is that it will help with birth rates since H > >you'll have plenty of teenagers having babies before they learn about condoms,E > >which will result in a higher number of average babies per family.  > > L > >In conclusion, it is clear that this small tit exposure will cost the USAI > >massive damage to the current and next generation americans whose life  will > >have changed due to this. > > B > >(outside the USA, this will have no effect since seing a tit is
 considered, > >good to to a son's development/education)    H What's wrong with being a waiter?  I know waiters that make six - figureH incomes.  And even those that don't are at least employed, which is more than can be said for JF....    --   Best Greg   ------------------------------   Date: 5 Feb 2004 08:30:16 -0800 1 From: susan_skonetski@hotmail.com (Sue Skonetski) - Subject: Just making sure that  you are aware = Message-ID: <857e9e41.0402050830.7b32cb1a@posting.google.com>   D If you go to the OpenVMS home page there is a button that will allow: you to get a 30% discount on all books from Digital Press.C http://h71000.www7.hp.com/ this 30% disount will be until April 15.   
 Warm Regards,  Sue    ------------------------------   Date: 5 Feb 2004 01:45:04 -0800 - From: martin.walker@csf.co.uk (Martin Walker)  Subject: Re: License questions? = Message-ID: <2462c4e9.0402050145.64199379@posting.google.com>   B I think you can transfer the licenses within EIP (but not the Base= license - this is not part of EIP and cannot be moved between 	 systems).   F You can transfer (FOC) the Volshad and additional users licenses.  ButC if you want to upgrade them from their current versions you need to @ purchase a right-to-upgrade license from HP unless they are on a license subscription contract.  & (I assume this is a commercial system)   HTH     Martin      j tadamsmar@yahoo.com (Tom Adams) wrote in message news:<ea44f5a1.0401300646.3b6503bb@posting.google.com>...C > I am about to buy a replacement for an dead Alphastation 400/233.  > 3 > We are considering buying a refurbished DS10/600.  > 2 > I want double check the info I have on licenses. >  > It is my understanding that: > A > 1.  I need to buy the Enterprise Integration Package.  I cannot 
 > transfer > these licenses.  > > > 2.  I will be able to transfer my 1050 unit VOLSHAD license. > F > 3.  I will be able to transfer my 800 unit OPENVMS-ALPHA-ADL license
 > to allow > concurrent users.  > + > Does this ring true with your experience?  > G > The unit counts are the same as on our current DS10/466, but are they  > sufficient for a DS10/600? > , > Can I just load the PAKs it will all work? > G > I think I need to do some paperwork and pay a fee to make the license ! > transfer  all kosher.  Correct?    ------------------------------  % Date: Thu, 05 Feb 2004 12:23:51 +0100 * From: Paul Sture <nospam@sture.homeip.net>. Subject: LK401-AA keyboard - no PS2 connector.0 Message-ID: <402235D7.612B7424@sture.homeip.net>  D My LK461-A2, with PS2 plug is dead. I have a spare LK401-AA keyboardF which is like new, but unfortunately has an MMJ? style plug which fits my trusty old VAXstation 3100.  C Before I try taking the keyboards apart to see if I can simply swap % cables, I though I'd try asking here.   G Has anyone managed to do this, or I do I need to hunt down a converter? @ And yes, I've had a look at the VMS FAQ, but didn't see anything obvious.   TIA    --  
 Paul Sture% (ticked off with using a PC keyboard)    ------------------------------  # Date: Thu, 05 Feb 2004 13:52:05 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> 2 Subject: Re: LK401-AA keyboard - no PS2 connector.3 Message-ID: <9UrUb.13836$Wz6.2675@news.cpqcorp.net>   & No such animal exists to my knowledge.  7 "Paul Sture" <nospam@sture.homeip.net> wrote in message * news:402235D7.612B7424@sture.homeip.net...F > My LK461-A2, with PS2 plug is dead. I have a spare LK401-AA keyboardH > which is like new, but unfortunately has an MMJ? style plug which fits  > my trusty old VAXstation 3100. > E > Before I try taking the keyboards apart to see if I can simply swap ' > cables, I though I'd try asking here.  > I > Has anyone managed to do this, or I do I need to hunt down a converter? B > And yes, I've had a look at the VMS FAQ, but didn't see anything
 > obvious. >  > TIA  >  > --   > Paul Sture' > (ticked off with using a PC keyboard)    ------------------------------  % Date: Thu, 05 Feb 2004 10:43:33 +0000 0 From: Chris Sharman <chris.sharman@sorry.nospam>  Subject: Re: Moderate this group4 Message-ID: <bvt6ol$imd$1$830fa79f@news.demon.co.uk>   David B Sneddon wrote:   > Stewart, Bill espoused:  >  >> Dave, >>I >>     Could you give us a pointer to those itrc forums. (for those of us % >> that would like a moderated forum)  >> >> Bill Stewart   :-)  >  >  > http://www.itrc.hp.com > G > You have to register to get access, but I guess that is what helps to  > keep the lunatic fringe away.   @ And you have to be using Microsoft Internet Explorer to do that.# I tried with Mozilla & got nowhere. F I emailed, and got an email back suggesting I phone someone in the US.D I expressed disbelief, and got a pointer to a webpage with assorted  international numbers on it.F I forget what I wanted off their site now, but it wasn't worth _that_  much hassle.   ------------------------------  # Date: Thu, 05 Feb 2004 12:02:27 GMT 4 From: brad@.gateway.2wire.net (Bradford J. Hamilton)  Subject: Re: Moderate this group. Message-ID: <nhqUb.97220$U%5.485337@attbi_s03>  g In article <bvt6ol$imd$1$830fa79f@news.demon.co.uk>, Chris Sharman <chris.sharman@sorry.nospam> writes:  !David B Sneddon wrote:  !snip! !>   !> http://www.itrc.hp.com  !>  H !> You have to register to get access, but I guess that is what helps to  !> keep the lunatic fringe away. ! A !And you have to be using Microsoft Internet Explorer to do that. $ !I tried with Mozilla & got nowhere.G !I emailed, and got an email back suggesting I phone someone in the US. E !I expressed disbelief, and got a pointer to a webpage with assorted   !international numbers on it. G !I forget what I wanted off their site now, but it wasn't worth _that_  
 !much hassle.  !   N As David has mentioned in another thread in this forum, acessing the fora fromK Mozilla is do-able.  I have accessed ITRC from Mozilla and Mozilla Firebird L on a WXP platform with no issues.  I've run across *very* few sites that are- not acessible with Mozilla or its derivative.   J __________________________________________________________________________A Bradford J. Hamilton                    "All opinions are my own" K bMradAhamiPltSon-at-coMmcAast.nPeSt     "Lose the MAPS, and replace '-at-'  0                                          with @"   ------------------------------  % Date: Thu, 05 Feb 2004 13:48:48 +0000 - From: David B Sneddon <dbsneddon@bigpond.com>   Subject: Re: Moderate this group* Message-ID: <402249C0.7040904@bigpond.com>   Chris Sharman espoused:  > B > And you have to be using Microsoft Internet Explorer to do that.% > I tried with Mozilla & got nowhere. H > I emailed, and got an email back suggesting I phone someone in the US.F > I expressed disbelief, and got a pointer to a webpage with assorted  > international numbers on it.H > I forget what I wanted off their site now, but it wasn't worth _that_  > much hassle. >  >   D I live in a Micro$lop Free Zone -- I only use Mozilla either on VMS, MacOS X or Linux.    Regards, Dave.  --  I David B Sneddon (dbs)    VMS Systems Programmer     dbsneddon@bigpond.com I Sneddo's quick guide ...          http://www.users.bigpond.com/dbsneddon/ I DBS freeware at ...   http://www.users.bigpond.com/dbsneddon/software.htm I "Life is what happens to you while you're busy making other plans" Lennon    ------------------------------   Date: 5 Feb 2004 10:01:07 -0800 & From: magalettac@massdor.com (Carmine)# Subject: Re: Oracle 9.2.0.2 install = Message-ID: <4093a3af.0402051001.37787cc9@posting.google.com>    Thanks for the information.....    Carmine    ------------------------------   Date: 5 Feb 2004 01:48:42 -0800 . From: fabiopenvms@yahoo.com.br (Fabio Cardoso)Y Subject: Re: Oracle Rdb and RMU/BACKUP/DENSITY (was: Re: HOW MANY BPI DOES A DLT7000 WRIT = Message-ID: <f30679fb.0402050148.26ad0c66@posting.google.com>   ^ hoff@hp.nospam (Hoff Hoffman) wrote in message news:<HweUb.13804$N66.1674@news.cpqcorp.net>...^ > In article <1d08b916.0402031137.7ef9e8d5@posting.google.com>, mb301@hotmail.com (MB) writes: > : 1 > :I am using Rdb(7.0) and trying to do a backup.  > D >   Ah, a critical detail of the question comes to light -- this is A >   something involving an Oracle Rdb RMU/BACKUP/DENSITY command.  > D >   I would suggest asking Oracle Rdb -- this isn't really a genericA >   OpenVMS question, this is something specific to Oracle Rdb.       L I suggest doing the backup to disk and uploading by Netbackup, Legato etc...6 You never know when the backup to tape is really OK !  :-)    Regards    FC     > G >   If the Oracle Rdb command syntax parallels that of OpenVMS, see the F >   HELP text for INITIALIZE/DENSITY -- based on what I see in the RdbE >   help, it does not appear to parallel OpenVMS here, and it appears B >   you should apparently select either zero or one as the value.  > G >   Again, somebody that knows this corner of Rdb would have to address 
 >   this.  > O > :I have init the tape "Sony DLTtape iv tape " with /media=compaction but rdb   > :seems to ignore it.   > : 3 > :Any ideas what value "/density=??" I should try?  > P >  ---------------------------- #include <rtfaq.h> -----------------------------M >     For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq P >  --------------------------- pure personal opinion ---------------------------G >         Hoff (Stephen) Hoffman   OpenVMS Engineering   hoff[at]hp.com    ------------------------------  $ Date: Thu, 5 Feb 2004 13:56:30 +0100  From: "Dr. Dweeb" <dr@dweeb.com>L Subject: Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ?????- Message-ID: <bvtehu$1h0o$1@news.cybercity.dk>    Daryl Jones wrote: > Dear Fabio Cardoso:  > G > Oracle Rdb will run on VMS, OpenVMS, and Unix (maybe NT?). Therefore, D > making Rdb apart of VMS would not be cost worthy. Yes, once upon aD > time, VMS and Rdb run-time kernel was tied together(DTM?). at thatG > time, Rdb name was Rdb/VMS. This was when the VMS license was $30,000 E > and so was(I believe) the price of the Rdb development license. Rdb A > back then was bringing in about $100 million a year in for DEC. F > However, Palmer started to sell off DEC assets. Therefore, Rdb, CDD,C > and related products were sold to Oracle. I always thought by now E > Oracle would have move everyone over to its databases, Oracle RDBMS H > 7,8,8i,9i, and now Oracle 10g. As you can see, Oracle Rdb still exists" > with its current version of 7.x.   Rdb Current Version 7.1.x   J While Rdb has been under a cloud recently, it has historically been a veryH good performer for the Oracle Corporation according to heresay evidence.D There are a plethora of reasons why Rdb users do not want to move to+ OracleClassic database.  The main ones are;   C * Administration - Rdb is an order og magnitude easier to setup and  administer. H * Performance - For a large class of TP applications Rdb is a measurably better solution E * 3rd. party apps. - TP applications you have probably never heard of L running very critical, 24*7 systems with zero downtime requirements providedL by 3rd party providers - it is doubtful whether these applications will evenB run on Oracle classic, so the chances of them being ported is low.L * The products are in some ways mutually exclusive as a deployment database,: so flipping from Rdb to Oracle Classic is not a no-brainerK * Bad experience - There is a body of emprical evidence suggesting that Rdb B to Oracle classic conversions are unlikely to be the success their proponents hope.+ * OracleRdb is a better product technically   
 Dr. Dweeb.   > 
 > Regards,
 > Daryl Jones  > ; > fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in message ; > news:<f30679fb.0402041522.4c5cee0c@posting.google.com>... 1 >> "John Smith" <a@nonymous.com> wrote in message I >> news:<xVaUb.130724$9Ce1.54975@news04.bloor.is.net.cable.rogers.com>...  >>> Malcolm Dunnett wrote:A >>>> In article <f30679fb.0402040128.4659871@posting.google.com>, 5 >>>> fabiopenvms@yahoo.com.br (Fabio Cardoso) writes:  >>>>> Click  >>>>> ? >>>>> http://news.com.com/2100-7344_3-5152672.html?tag=nefd_top  >>>>>  >>>>> E >>>>> Oracle announced the availability of its Oracle 10g database on G >>>>> Tuesday and cut prices, in an effort to gain more customers among  >>>>> midsize businesses.  >>>>> G >>>>> As previously reported by CNET News.com, Oracle released the Unix C >>>>> and Linux versions of its Oracle 10g database and dropped the F >>>>> price of its entry-level database to about $5,000 per processor,B >>>>> matching the cost of Microsoft's SQL Server 2000 database. AF >>>>> Windows version of Oracle 10g is slated for completion in a "few. >>>>> weeks," according to company executives. >>>>> (...)  >>>>>  >>>>F >>>>    Do they say somewhere what the difference is between "Standard >>>> Edition One" G >>>> and "Standard Edition"? The only thing I can see is that "Standard  >>>> Edition One" F >>>> supports a maximum of 2 processors in a server ( vs unlimited for >>>> "SE" ). >>>>H >>>>    Any indication they will release "Standard Edition One" for VMS? >>>> Right nowC >>>> it only says "Windows, Linux and Unix". None of our VMS Oraclea >>>> servers haveoD >>>> more than 2 processors so I'd hate to be spending an additional
 >>>> $10k per ) >>>> processor just to run Oracle on VMS.o >>>>H >>>>   (note to Sue et al - it would be very supportive for the "low-end	 >>>> VMS" H >>>> market if Oracle could be encouraged to make this product available
 >>>> on VMS )n >>>KB >>> A far cry from the days of Rdb run-time included with NAS 200,3 >>> which IIRC was included with every VMS licence.t >>: >> What Oracle gains retaining RDB ?  It should be bundled6 >> with OpenVMS autmatically and Oracle could sell the0 >> other products for the customer side ! Etc...5 >> How is the cost of  RDB developemnt for Oracle andc >> how much it worth for them ?  >>
 >> Regards >> >> FC    ------------------------------  % Date: Thu, 05 Feb 2004 14:21:54 +0100r* From: Paul Sture <nospam@sture.homeip.net>L Subject: Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ?????0 Message-ID: <40225182.1B1EA40D@sture.homeip.net>   Dr. Dweeb wrote: >  > Daryl Jones wrote: > > Dear Fabio Cardoso:  > >eI > > Oracle Rdb will run on VMS, OpenVMS, and Unix (maybe NT?). Therefore,eF > > making Rdb apart of VMS would not be cost worthy. Yes, once upon aF > > time, VMS and Rdb run-time kernel was tied together(DTM?). at thatI > > time, Rdb name was Rdb/VMS. This was when the VMS license was $30,000lG > > and so was(I believe) the price of the Rdb development license. Rdb[C > > back then was bringing in about $100 million a year in for DEC.GH > > However, Palmer started to sell off DEC assets. Therefore, Rdb, CDD,E > > and related products were sold to Oracle. I always thought by nowtG > > Oracle would have move everyone over to its databases, Oracle RDBMSuJ > > 7,8,8i,9i, and now Oracle 10g. As you can see, Oracle Rdb still exists$ > > with its current version of 7.x. >  > Rdb Current Version 7.1.x  > L > While Rdb has been under a cloud recently, it has historically been a veryJ > good performer for the Oracle Corporation according to heresay evidence.F > There are a plethora of reasons why Rdb users do not want to move to- > OracleClassic database.  The main ones are;  > E > * Administration - Rdb is an order og magnitude easier to setup ande
 > administer.bJ > * Performance - For a large class of TP applications Rdb is a measurably > better solutionnG > * 3rd. party apps. - TP applications you have probably never heard ofiN > running very critical, 24*7 systems with zero downtime requirements providedN > by 3rd party providers - it is doubtful whether these applications will evenD > run on Oracle classic, so the chances of them being ported is low.N > * The products are in some ways mutually exclusive as a deployment database,< > so flipping from Rdb to Oracle Classic is not a no-brainerM > * Bad experience - There is a body of emprical evidence suggesting that RdbTD > to Oracle classic conversions are unlikely to be the success their > proponents hope.- > * OracleRdb is a better product technicallyo >   F * Hot backups too. I know of one large application where the main show7 stopper for migration away from VMS is that very issue.a     > >o > > Regards, > > Daryl Jones  > >'= > > fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in message,= > > news:<f30679fb.0402041522.4c5cee0c@posting.google.com>...u3 > >> "John Smith" <a@nonymous.com> wrote in messageiK > >> news:<xVaUb.130724$9Ce1.54975@news04.bloor.is.net.cable.rogers.com>...w > >>> Malcolm Dunnett wrote:C > >>>> In article <f30679fb.0402040128.4659871@posting.google.com>, 7 > >>>> fabiopenvms@yahoo.com.br (Fabio Cardoso) writes:a
 > >>>>> Clickt > >>>>> A > >>>>> http://news.com.com/2100-7344_3-5152672.html?tag=nefd_topu > >>>>>  > >>>>> G > >>>>> Oracle announced the availability of its Oracle 10g database onMI > >>>>> Tuesday and cut prices, in an effort to gain more customers among  > >>>>> midsize businesses.o > >>>>>aI > >>>>> As previously reported by CNET News.com, Oracle released the UnixCE > >>>>> and Linux versions of its Oracle 10g database and dropped the H > >>>>> price of its entry-level database to about $5,000 per processor,D > >>>>> matching the cost of Microsoft's SQL Server 2000 database. AH > >>>>> Windows version of Oracle 10g is slated for completion in a "few0 > >>>>> weeks," according to company executives.
 > >>>>> (...)o > >>>>>c > >>>>H > >>>>    Do they say somewhere what the difference is between "Standard > >>>> Edition One"6I > >>>> and "Standard Edition"? The only thing I can see is that "Standard  > >>>> Edition One"kH > >>>> supports a maximum of 2 processors in a server ( vs unlimited for > >>>> "SE" ). > >>>>J > >>>>    Any indication they will release "Standard Edition One" for VMS? > >>>> Right nowE > >>>> it only says "Windows, Linux and Unix". None of our VMS Oraclei > >>>> servers haveoF > >>>> more than 2 processors so I'd hate to be spending an additional > >>>> $10k peri+ > >>>> processor just to run Oracle on VMS.  > >>>>J > >>>>   (note to Sue et al - it would be very supportive for the "low-end > >>>> VMS"uJ > >>>> market if Oracle could be encouraged to make this product available > >>>> on VMS )t > >>>oD > >>> A far cry from the days of Rdb run-time included with NAS 200,5 > >>> which IIRC was included with every VMS licence.m > >>< > >> What Oracle gains retaining RDB ?  It should be bundled8 > >> with OpenVMS autmatically and Oracle could sell the2 > >> other products for the customer side ! Etc...7 > >> How is the cost of  RDB developemnt for Oracle and ! > >> how much it worth for them ?  > >> > >> Regards > >> > >> FCe   -- a   -- r
 Paul Sture   ------------------------------  % Date: Thu, 05 Feb 2004 17:35:02 +0100n2 From: martin@radiogaga.harz.de (Martin Vorlaender)L Subject: Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ?????; Message-ID: <402270b6.524144494f47414741@radiogaga.harz.de>a  + Paul Sture (nospam@sture.homeip.net) wrote:( > Dr. Dweeb wrote:N > > While Rdb has been under a cloud recently, it has historically been a veryL > > good performer for the Oracle Corporation according to heresay evidence.H > > There are a plethora of reasons why Rdb users do not want to move to/ > > OracleClassic database.  The main ones are;s [...]0 >6H > * Hot backups too. I know of one large application where the main show9 > stopper for migration away from VMS is that very issue.V  B Oracle Classic has that these days, too. Since version 8 at least.   cu,a   Martin -- iG  Your mouse has moved.     | Martin Vorlaender  |  VMS & WNT programmert4  Windows must be restarted | work: mv@pdv-systeme.deH  for the change to take    |    http://www.pdv-systeme.de/users/martinv/;  effect. Reboot now? [OK]  | home: martin@radiogaga.harz.de    ------------------------------   Date: 5 Feb 2004 10:34:00 -0800c. From: fabiopenvms@yahoo.com.br (Fabio Cardoso)L Subject: Re: Oracle ships 10g database, cuts price  <-- Oracle RDB too ?????= Message-ID: <f30679fb.0402051034.5ccd786a@posting.google.com>m  b Paul Sture <nospam@sture.homeip.net> wrote in message news:<40225182.1B1EA40D@sture.homeip.net>... > Dr. Dweeb wrote: > >  > > Daryl Jones wrote: > > > Dear Fabio Cardoso:m > > >.K > > > Oracle Rdb will run on VMS, OpenVMS, and Unix (maybe NT?). Therefore,oH > > > making Rdb apart of VMS would not be cost worthy. Yes, once upon aH > > > time, VMS and Rdb run-time kernel was tied together(DTM?). at thatK > > > time, Rdb name was Rdb/VMS. This was when the VMS license was $30,000 I > > > and so was(I believe) the price of the Rdb development license. RdbnE > > > back then was bringing in about $100 million a year in for DEC.yJ > > > However, Palmer started to sell off DEC assets. Therefore, Rdb, CDD,G > > > and related products were sold to Oracle. I always thought by now I > > > Oracle would have move everyone over to its databases, Oracle RDBMShL > > > 7,8,8i,9i, and now Oracle 10g. As you can see, Oracle Rdb still exists& > > > with its current version of 7.x. > >  > > Rdb Current Version 7.1.x) > > N > > While Rdb has been under a cloud recently, it has historically been a veryL > > good performer for the Oracle Corporation according to heresay evidence.H > > There are a plethora of reasons why Rdb users do not want to move to/ > > OracleClassic database.  The main ones are;w > > G > > * Administration - Rdb is an order og magnitude easier to setup and- > > administer. L > > * Performance - For a large class of TP applications Rdb is a measurably > > better solutioncI > > * 3rd. party apps. - TP applications you have probably never heard of4P > > running very critical, 24*7 systems with zero downtime requirements providedP > > by 3rd party providers - it is doubtful whether these applications will evenF > > run on Oracle classic, so the chances of them being ported is low.P > > * The products are in some ways mutually exclusive as a deployment database,> > > so flipping from Rdb to Oracle Classic is not a no-brainerO > > * Bad experience - There is a body of emprical evidence suggesting that RdbtF > > to Oracle classic conversions are unlikely to be the success their > > proponents hope./ > > * OracleRdb is a better product technically4 > >  > H > * Hot backups too. I know of one large application where the main show8 > stopper for migration away from VMS is that very issue    ; We are using Hot Stanby and its working fine too ! But ...m  > When was the last Ad / News of Oracle RDB in Oracle Magazine ?     Regardsn   FC o  n >  > > >e > > > Regards, > > > Daryl Jonesv > > >r? > > > fabiopenvms@yahoo.com.br (Fabio Cardoso) wrote in messagel? > > > news:<f30679fb.0402041522.4c5cee0c@posting.google.com>...=5 > > >> "John Smith" <a@nonymous.com> wrote in messageeM > > >> news:<xVaUb.130724$9Ce1.54975@news04.bloor.is.net.cable.rogers.com>...  > > >>> Malcolm Dunnett wrote:E > > >>>> In article <f30679fb.0402040128.4659871@posting.google.com>,s9 > > >>>> fabiopenvms@yahoo.com.br (Fabio Cardoso) writes:  > > >>>>> Clicky	 > > >>>>>tC > > >>>>> http://news.com.com/2100-7344_3-5152672.html?tag=nefd_topa	 > > >>>>>n	 > > >>>>>pI > > >>>>> Oracle announced the availability of its Oracle 10g database onuK > > >>>>> Tuesday and cut prices, in an effort to gain more customers among* > > >>>>> midsize businesses.*	 > > >>>>>-K > > >>>>> As previously reported by CNET News.com, Oracle released the Unix G > > >>>>> and Linux versions of its Oracle 10g database and dropped theeJ > > >>>>> price of its entry-level database to about $5,000 per processor,F > > >>>>> matching the cost of Microsoft's SQL Server 2000 database. AJ > > >>>>> Windows version of Oracle 10g is slated for completion in a "few2 > > >>>>> weeks," according to company executives. > > >>>>> (...)i	 > > >>>>>t > > >>>>J > > >>>>    Do they say somewhere what the difference is between "Standard > > >>>> Edition One".K > > >>>> and "Standard Edition"? The only thing I can see is that "Standard  > > >>>> Edition One"eJ > > >>>> supports a maximum of 2 processors in a server ( vs unlimited for > > >>>> "SE" ). > > >>>>L > > >>>>    Any indication they will release "Standard Edition One" for VMS? > > >>>> Right nowG > > >>>> it only says "Windows, Linux and Unix". None of our VMS Oraclef > > >>>> servers haveuH > > >>>> more than 2 processors so I'd hate to be spending an additional > > >>>> $10k perm- > > >>>> processor just to run Oracle on VMS.H > > >>>>L > > >>>>   (note to Sue et al - it would be very supportive for the "low-end
 > > >>>> VMS",L > > >>>> market if Oracle could be encouraged to make this product available > > >>>> on VMS )a > > >>> F > > >>> A far cry from the days of Rdb run-time included with NAS 200,7 > > >>> which IIRC was included with every VMS licence.c > > >>> > > >> What Oracle gains retaining RDB ?  It should be bundled: > > >> with OpenVMS autmatically and Oracle could sell the4 > > >> other products for the customer side ! Etc...9 > > >> How is the cost of  RDB developemnt for Oracle and:# > > >> how much it worth for them ?t > > >> > > >> Regards > > >>	 > > >> FCc >  > --   ------------------------------   Date: 5 Feb 2004 03:50:26 -0800o+ From: steve.burch@bigfoot.com (Steve Burch)r1 Subject: Re: Print Queue to FAX/E-mail Solutions? = Message-ID: <93b3fc8a.0402050350.3ab72e98@posting.google.com>    Hi,U  F Many thanks for all the information - I've subsequently found out thatD we possibly intend to use a specific remittance module of a payments? application (Paybase from a vendor called Bottomline) to do theiC document distribution. I've yet to find out what format they expectlD their input in, but hopefully I'll find a automated solution with no intermediate steps.a   Steve Burchp   ------------------------------  $ Date: Thu, 5 Feb 2004 07:20:40 -0700B From: "Tillman, Brian (AGRE)" <Brian.Tillman@smiths-aerospace.com>1 Subject: RE: Print Queue to FAX/E-mail Solutions?hO Message-ID: <11721EF39C7D7F47A55447158274CAF79A3D18@cossmgmbx01.email.corp.tld>    Steve Burch wrote:  ? > Many thanks for all the information - I've subsequently found3: > out that we possibly intend to use a specific remittance9 > module of a payments application (Paybase from a vendor > > called Bottomline) to do the document distribution. I've yet9 > to find out what format they expect their input in, butaF > hopefully I'll find a automated solution with no intermediate steps.  G If there is processing on the VMS side you need to do to feed the print F files to the payments application, check out EXECSMB (freeware disk, IB believe, or at Process Software's VMS freeware download site).  ItB creates a print symbiont that executes anything you program it to.G Print your job to it, have it process the file in any way you need, ande pass it on to the app. --=0Df Brian Tillman        =0D Smiths Aerospace 3290 Patterson Ave. SE, MS 1B3 Grand Rapids, MI 49512-1991,> Brian.Tillman is the name, smiths-aerospace.com is the domain.	       =0D : I don't speak for Smiths, and Smiths doesn't speak for me.      * ******************************************G The information contained in, or attached to, this e-mail, may contain= D  confidential information and is intended solely for the use of the=G  individual or entity to whom they are addressed and may be subject to=dH  legal privilege.  If you have received this e-mail in error you should=H  notify the sender immediately by reply e-mail, delete the message from=L  your system and notify your system manager.  Please do not copy it for any=F  purpose, or disclose its contents to any other person.  The views or=I  opinions presented in this e-mail are solely those of the author and do=aG  not necessarily represent those of the company.  The recipient should=TI  check this e-mail and any attachments for the presence of viruses.  The=eA  company accepts no liability for any damage caused, directly or=r4  indirectly, by any virus transmitted in this email.* ******************************************   ------------------------------   Date: 5 Feb 2004 09:15:40 +0100a' From: huber@mppmu.mpg.de (Joseph Huber)e& Subject: Re: Problem with Ghost Script+ Message-ID: <gctfoCsxAfSs@vms.mppmu.mpg.de>a  \ In article <1022te9m7eqbtb9@corp.supernews.com>, Andrew Robert <arobert@townisp.com> writes: > Hi Everyone, > I > I am trying to use Ghostscript to convert some postscript files to PDF w	 > format.s% > When I enter the following command:wK > gs  "-sDEVICE=pdfwrite" -sOutputFile=graphs.pdf"  "-dNOPAUSE"  "-dBATCH"  " > kits:[pef_graphs]force_graphs.ps > I get the error message:M > %DCL-W-MAXPARM, too many parameters - reenter command with fewer parametersh >   \"-sDEVICE=pdfwrite"\a  E I'm not aware of a Ghostscript version with a DCL command definition.l  , Do You have a foreign command "gs" defined ?:   do a "show symbol gs" to see if it points to ghostscript  ! Do You have a verb "gs" defined ? D   if neither a symbol "gs" is defined , nor dcl$path:gs exists, thenD   use the "verb" utility (see freeware or process.com) , and show us
   "verb gs" .v   --  >    Joseph "Sepp" Huber, Muenchen   http://www.huber-joseph.de/   ------------------------------  # Date: Thu, 05 Feb 2004 13:15:11 GMTh( From: Phaeton   <spameater@spam.invalid>& Subject: Re: Problem with Ghost Script6 Message-ID: <zlrUb.862$KS1.38558@nasal.pacific.net.au>  * Andrew Robert <arobert@townisp.com> wrote: > Hi Everyone, > I > I am trying to use Ghostscript to convert some postscript files to PDF t	 > format.a > % > When I enter the following command:l > K > gs  "-sDEVICE=pdfwrite" -sOutputFile=graphs.pdf"  "-dNOPAUSE"  "-dBATCH" c" > kits:[pef_graphs]force_graphs.ps  A 	Could be a typo, but isn't there a missing quotation mark at the- 	second parameter, -sOut...  ?   							Cheers,  CsabaM  J  -------------------------------------------------------------------------H   CSABA I. HARANGOZO  |d|i|g|i|t|a|l|  csabah(at)zipworld(dot)com(dot)auJ  -------------------------------------------------------------------------;    EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:e  C  Never wrestle with a pig, you both get dirty and the pig likes it.    ------------------------------  $ Date: Thu, 5 Feb 2004 06:52:45 -0700B From: "Tillman, Brian (AGRE)" <Brian.Tillman@smiths-aerospace.com>& Subject: RE: Problem with Ghost ScriptO Message-ID: <11721EF39C7D7F47A55447158274CAF79A3D11@cossmgmbx01.email.corp.tld>    Andrew Robert wrote:   > Hi Everyone, >=0DH > I am trying to use Ghostscript to convert some postscript files to PDF	 > format.s >=0D% > When I enter the following command:c >=0DF > gs  "-sDEVICE=3Dpdfwrite" -sOutputFile=3Dgraphs.pdf"  "-dNOPAUSE"=0D, > "-dBATCH" kits:[pef_graphs]force_graphs.ps >=0D > I get the error message: >=0DB > %DCL-W-MAXPARM, too many parameters - reenter command with fewer& >   parameters \"-sDEVICE=3Dpdfwrite"\  ; Looks like you're missing a quote in from of "-sOutputFile"a --=0Dh Brian Tillman        =0D Smiths Aerospace 3290 Patterson Ave. SE, MS 1B3 Grand Rapids, MI 49512-1991 > Brian.Tillman is the name, smiths-aerospace.com is the domain.	       =0De: I don't speak for Smiths, and Smiths doesn't speak for me.      * ******************************************G The information contained in, or attached to, this e-mail, may contain=nD  confidential information and is intended solely for the use of the=G  individual or entity to whom they are addressed and may be subject to=sH  legal privilege.  If you have received this e-mail in error you should=H  notify the sender immediately by reply e-mail, delete the message from=L  your system and notify your system manager.  Please do not copy it for any=F  purpose, or disclose its contents to any other person.  The views or=I  opinions presented in this e-mail are solely those of the author and do= G  not necessarily represent those of the company.  The recipient should=lI  check this e-mail and any attachments for the presence of viruses.  The=tA  company accepts no liability for any damage caused, directly or= 4  indirectly, by any virus transmitted in this email.* ******************************************   ------------------------------  % Date: Thu, 05 Feb 2004 12:42:38 +0100i From: Gruhl <gruhl@isidata.de>( Subject: Problems with File Access Dates* Message-ID: <40222C2E.AFB86828@isidata.de>  K Yesterday I updated the factory installed VMS 7.3-1 on a new DS15 to 7.3-2. N Because I had read about 'Copy and Search Performance Enhancements', I devisedE some primitive benchmarks (e.g. $ SEARCH/STAT SYS$MANAGER:*.COM ZXY).kY But to my surprise, elapsed times *increased* by a factor of  five (!) after the upgrade.e   It took quite a long time to find out that VMS chose to update file access dates after each open (although DIR/FU mentioned 'Accessed: <none specified>').+ This killed most of XFCs performance gains.   k The behaviour  may be a side effect of my selection to convert the system disk to ODS-5 during the upgrade.o  3 So I ventured to undo this modification by enteringw= $ SET  VOLUME /VOLUME_CHARACTERISTICS=NOACCESS  SYS$SYSDEVICEt. This made no difference, however. Then I tried4 $ SET  VOLUME /VOLUME=ACCESS=01:00:00  SYS$SYSDEVICEF in order to have the updates happen only on dates older than one hour.T The only difference in behaviour was that $ DIR/FU now tells about the access dates.p They seem still to be updated on every file open (or may be close), regardless of the intervening time interval. It seems that specification of a time interval for SET VOLUME/VOL=ACCESS is ignored. This is true even for newly created files. Reboot didn't help either.   HELP SET VOLUME  directs me to the 'Guide to OpenVMS File Applications', which unfortunately seems to say nothing about this command, however.  F Does anyone know how I can get rid of these file access date updates ?   ------------------------------  % Date: Thu, 05 Feb 2004 12:56:53 +0100a* From: Paul Sture <nospam@sture.homeip.net>, Subject: Re: Problems with File Access Dates0 Message-ID: <40223D95.738B4EA4@sture.homeip.net>   Gruhl wrote: > M > Yesterday I updated the factory installed VMS 7.3-1 on a new DS15 to 7.3-2.iP > Because I had read about 'Copy and Search Performance Enhancements', I devisedG > some primitive benchmarks (e.g. $ SEARCH/STAT SYS$MANAGER:*.COM ZXY).t[ > But to my surprise, elapsed times *increased* by a factor of  five (!) after the upgrade.E >  > It took quite a long time to find out that VMS chose to update file access dates after each open (although DIR/FU mentioned 'Accessed: <none specified>').- > This killed most of XFCs performance gains./ > m > The behaviour  may be a side effect of my selection to convert the system disk to ODS-5 during the upgrade.m > 5 > So I ventured to undo this modification by entering-? > $ SET  VOLUME /VOLUME_CHARACTERISTICS=NOACCESS  SYS$SYSDEVICE00 > This made no difference, however. Then I tried6 > $ SET  VOLUME /VOLUME=ACCESS=01:00:00  SYS$SYSDEVICEH > in order to have the updates happen only on dates older than one hour.V > The only difference in behaviour was that $ DIR/FU now tells about the access dates.r > They seem still to be updated on every file open (or may be close), regardless of the intervening time interval. > It seems that specification of a time interval for SET VOLUME/VOL=ACCESS is ignored. This is true even for newly created files. Reboot didn't help either. >  > HELP SET VOLUME  directs me to the 'Guide to OpenVMS File Applications', which unfortunately seems to say nothing about this command, however. >   1 I've not got V7.3-2, but from the help on V7.3-1:e  > $ HELP V731_FEATURES System_Management File_Service_Extensions DCL_Access_Dates .. .e .g  
 V731_FEATURES6     System_Managementn       File_Service_Extensionso         DCL_Access_Dates  G            To enable automatic update of access dates on ODS-5 volumes,u usemF            the SET VOLUME/VOLUME_CHARACTERISTICS command. For example:  ;         $ SET VOLUME/VOLUME_CHARACTERISTICS=ACCESS_DATES= -s!         _$ [delta-time] NODE$COE1l  B            The default value for delta-time is 1 second, chosen to complyD            with the "seconds since EPOCH" time interface required byC            POSIX st_atime. A site can choose a larger delta time to  reduce<            overhead if 1-second granularity is not required.  F           Another way to enable automatic update of access dates is to useeF            the INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES command, as            follows:   E            $ INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES NODE$COE1e            $ MOUNT NODE$COE1  B            To disable access date support on a volume, use the SETE            VOLUME/VOLUME_CHARACTERISTICS=NOACCESS_DATES command. ThistH            command affects only the node on which the command is issued.D            Other nodes are not affected by the change until the next time!            the volume is mounted.   D            The DCL commands DIRECTORY or DUMP/HEADER support the new4            timestamps. Use the following qualifiers:  )            Qualifier          Descriptione  =            /DATE=ACCESSED     Specifies the last access date. G            /DATE=ATTRIBUTES   Specifies the last attribute modificationn$                                date.H            /DATE=DATA_        Specifies the last data modification date.            MODIFIED-  D            For example, the following command displays the last time data"            was read from the file:  $            $ DIRECTORY/DATE=ACCESSED                   tH > Does anyone know how I can get rid of these file access date updates ?   Does the above help? .   --  
 Paul Sture   ------------------------------  % Date: Thu, 05 Feb 2004 16:56:59 +0100Y* From: Paul Sture <nospam@sture.homeip.net>, Subject: Re: Problems with File Access Dates0 Message-ID: <402275DB.343A03F1@sture.homeip.net>   Andreas Gruhl wrote: >  > Paul Sture wrote:  > >l > > Gruhl wrote: > > >lQ > > > Yesterday I updated the factory installed VMS 7.3-1 on a new DS15 to 7.3-2.eT > > > Because I had read about 'Copy and Search Performance Enhancements', I devisedK > > > some primitive benchmarks (e.g. $ SEARCH/STAT SYS$MANAGER:*.COM ZXY).c_ > > > But to my surprise, elapsed times *increased* by a factor of  five (!) after the upgrade.  > > >  > > > It took quite a long time to find out that VMS chose to update file access dates after each open (although DIR/FU mentioned 'Accessed: <none specified>').1 > > > This killed most of XFCs performance gains._ > > >_q > > > The behaviour  may be a side effect of my selection to convert the system disk to ODS-5 during the upgrade.n > > >a9 > > > So I ventured to undo this modification by enteringlC > > > $ SET  VOLUME /VOLUME_CHARACTERISTICS=NOACCESS  SYS$SYSDEVICE-4 > > > This made no difference, however. Then I tried: > > > $ SET  VOLUME /VOLUME=ACCESS=01:00:00  SYS$SYSDEVICEL > > > in order to have the updates happen only on dates older than one hour.Z > > > The only difference in behaviour was that $ DIR/FU now tells about the access dates.v > > > They seem still to be updated on every file open (or may be close), regardless of the intervening time interval. > > > It seems that specification of a time interval for SET VOLUME/VOL=ACCESS is ignored. This is true even for newly created files. Reboot didn't help either. > > >w > > > HELP SET VOLUME  directs me to the 'Guide to OpenVMS File Applications', which unfortunately seems to say nothing about this command, however. > > >a > > 5 > > I've not got V7.3-2, but from the help on V7.3-1:i > >.B > > $ HELP V731_FEATURES System_Management File_Service_Extensions > > DCL_Access_Dates > > .  > > .t > > .w > >s > > V731_FEATURESd > >f > >   System_Management  > >n > >     File_Service_Extensions  > >  > >       DCL_Access_Dates > >-K > >            To enable automatic update of access dates on ODS-5 volumes,c > > usenJ > >            the SET VOLUME/VOLUME_CHARACTERISTICS command. For example: > >c? > >         $ SET VOLUME/VOLUME_CHARACTERISTICS=ACCESS_DATES= -m% > >         _$ [delta-time] NODE$COE1  > >eF > >            The default value for delta-time is 1 second, chosen to
 > > complyH > >            with the "seconds since EPOCH" time interface required byG > >            POSIX st_atime. A site can choose a larger delta time to 
 > > reduce@ > >            overhead if 1-second granularity is not required. > >cJ > >           Another way to enable automatic update of access dates is to > > use@J > >            the INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES command, > > as > >            follows:t > >fI > >            $ INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES NODE$COE1   > >            $ MOUNT NODE$COE1 > > F > >            To disable access date support on a volume, use the SETI > >            VOLUME/VOLUME_CHARACTERISTICS=NOACCESS_DATES command. ThissL > >            command affects only the node on which the command is issued.H > >            Other nodes are not affected by the change until the next > > time% > >            the volume is mounted.e > >aH > >            The DCL commands DIRECTORY or DUMP/HEADER support the new8 > >            timestamps. Use the following qualifiers: > >O- > >            Qualifier          Descriptionp > >lA > >            /DATE=ACCESSED     Specifies the last access date. K > >            /DATE=ATTRIBUTES   Specifies the last attribute modificationv( > >                                date.L > >            /DATE=DATA_        Specifies the last data modification date. > >            MODIFIED  > >dH > >            For example, the following command displays the last time > > data& > >            was read from the file: > >e( > >            $ DIRECTORY/DATE=ACCESSED > >- > >-L > > > Does anyone know how I can get rid of these file access date updates ? > >o > > Does the above help? > >E > > -- > > Paul StureI > Thanks, but I have tried these and SET VOL/VOL=ACC=[delta-time] doesn't1  > do what it's advertised to do. >   G Just double checking that you aren't sharing this disk clusterwide, I'm? assuming you saw this bit:  C "This command affects only the node on which the command is issued. 9 Other nodes are not affected by the change until the next. time the volume is mounted."   Are you on a support contract?     -- c
 Paul Sture   ------------------------------  % Date: Thu, 05 Feb 2004 16:31:35 +0100 & From: Andreas Gruhl <gruhl@isidata.de>, Subject: Re: Problems with File Access Dates* Message-ID: <402261D7.4D585692@isidata.de>   Paul Sture wrote:a >  > Gruhl wrote: > >mO > > Yesterday I updated the factory installed VMS 7.3-1 on a new DS15 to 7.3-2.rR > > Because I had read about 'Copy and Search Performance Enhancements', I devisedI > > some primitive benchmarks (e.g. $ SEARCH/STAT SYS$MANAGER:*.COM ZXY). ] > > But to my surprise, elapsed times *increased* by a factor of  five (!) after the upgrade.r > >o > > It took quite a long time to find out that VMS chose to update file access dates after each open (although DIR/FU mentioned 'Accessed: <none specified>')./ > > This killed most of XFCs performance gains.a > >eo > > The behaviour  may be a side effect of my selection to convert the system disk to ODS-5 during the upgrade.b > >n7 > > So I ventured to undo this modification by entering A > > $ SET  VOLUME /VOLUME_CHARACTERISTICS=NOACCESS  SYS$SYSDEVICEb2 > > This made no difference, however. Then I tried8 > > $ SET  VOLUME /VOLUME=ACCESS=01:00:00  SYS$SYSDEVICEJ > > in order to have the updates happen only on dates older than one hour.X > > The only difference in behaviour was that $ DIR/FU now tells about the access dates.t > > They seem still to be updated on every file open (or may be close), regardless of the intervening time interval. > > It seems that specification of a time interval for SET VOLUME/VOL=ACCESS is ignored. This is true even for newly created files. Reboot didn't help either. > >i > > HELP SET VOLUME  directs me to the 'Guide to OpenVMS File Applications', which unfortunately seems to say nothing about this command, however. > >  > 3 > I've not got V7.3-2, but from the help on V7.3-1:e > @ > $ HELP V731_FEATURES System_Management File_Service_Extensions > DCL_Access_Dates > .u > .> > .e >  > V731_FEATURES: >  >   System_Managementw >  >     File_Service_Extensions. >  >       DCL_Access_Dates > I >            To enable automatic update of access dates on ODS-5 volumes,o > useyH >            the SET VOLUME/VOLUME_CHARACTERISTICS command. For example: > = >         $ SET VOLUME/VOLUME_CHARACTERISTICS=ACCESS_DATES= - # >         _$ [delta-time] NODE$COE1t > D >            The default value for delta-time is 1 second, chosen to > complyF >            with the "seconds since EPOCH" time interface required byE >            POSIX st_atime. A site can choose a larger delta time to  > reduce> >            overhead if 1-second granularity is not required. > H >           Another way to enable automatic update of access dates is to > useMH >            the INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES command, > as >            follows:  > G >            $ INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES NODE$COE1  >            $ MOUNT NODE$COE1 > D >            To disable access date support on a volume, use the SETG >            VOLUME/VOLUME_CHARACTERISTICS=NOACCESS_DATES command. ThisiJ >            command affects only the node on which the command is issued.F >            Other nodes are not affected by the change until the next > time# >            the volume is mounted.  > F >            The DCL commands DIRECTORY or DUMP/HEADER support the new6 >            timestamps. Use the following qualifiers: > + >            Qualifier          Descriptionp > ? >            /DATE=ACCESSED     Specifies the last access date. I >            /DATE=ATTRIBUTES   Specifies the last attribute modificationO& >                                date.J >            /DATE=DATA_        Specifies the last data modification date. >            MODIFIEDA > F >            For example, the following command displays the last time > data$ >            was read from the file: > & >            $ DIRECTORY/DATE=ACCESSED >  > J > > Does anyone know how I can get rid of these file access date updates ? >  > Does the above help? >  > -- > Paul StureG Thanks, but I have tried these and SET VOL/VOL=ACC=[delta-time] doesn't- do what it's advertised to do.  
 Andreas Gruhl    ------------------------------  % Date: Thu, 05 Feb 2004 18:20:45 +0100a& From: Andreas Gruhl <gruhl@isidata.de>, Subject: Re: Problems with File Access Dates* Message-ID: <40227B6D.FA58836F@isidata.de>   Paul Sture wrote:F >  > Andreas Gruhl wrote: > >R > > Paul Sture wrote:n > > >d > > > Gruhl wrote: > > > >eS > > > > Yesterday I updated the factory installed VMS 7.3-1 on a new DS15 to 7.3-2.MV > > > > Because I had read about 'Copy and Search Performance Enhancements', I devisedM > > > > some primitive benchmarks (e.g. $ SEARCH/STAT SYS$MANAGER:*.COM ZXY).ra > > > > But to my surprise, elapsed times *increased* by a factor of  five (!) after the upgrade.n > > > >G > > > > It took quite a long time to find out that VMS chose to update file access dates after each open (although DIR/FU mentioned 'Accessed: <none specified>').3 > > > > This killed most of XFCs performance gains.M > > > >,s > > > > The behaviour  may be a side effect of my selection to convert the system disk to ODS-5 during the upgrade.  > > > >e; > > > > So I ventured to undo this modification by entering,E > > > > $ SET  VOLUME /VOLUME_CHARACTERISTICS=NOACCESS  SYS$SYSDEVICEr6 > > > > This made no difference, however. Then I tried< > > > > $ SET  VOLUME /VOLUME=ACCESS=01:00:00  SYS$SYSDEVICEN > > > > in order to have the updates happen only on dates older than one hour.\ > > > > The only difference in behaviour was that $ DIR/FU now tells about the access dates.x > > > > They seem still to be updated on every file open (or may be close), regardless of the intervening time interval. > > > > It seems that specification of a time interval for SET VOLUME/VOL=ACCESS is ignored. This is true even for newly created files. Reboot didn't help either. > > > >n > > > > HELP SET VOLUME  directs me to the 'Guide to OpenVMS File Applications', which unfortunately seems to say nothing about this command, however. > > > >R > > >r7 > > > I've not got V7.3-2, but from the help on V7.3-1:e > > > D > > > $ HELP V731_FEATURES System_Management File_Service_Extensions > > > DCL_Access_Dates > > > .s > > > .e > > > .p > > >h > > > V731_FEATURESs > > >e > > >   System_Management  > > > ! > > >     File_Service_Extensionsp > > >n > > >       DCL_Access_Dates > > >rM > > >            To enable automatic update of access dates on ODS-5 volumes,e	 > > > use L > > >            the SET VOLUME/VOLUME_CHARACTERISTICS command. For example: > > >0A > > >         $ SET VOLUME/VOLUME_CHARACTERISTICS=ACCESS_DATES= -u' > > >         _$ [delta-time] NODE$COE1b > > >$H > > >            The default value for delta-time is 1 second, chosen to > > > complyJ > > >            with the "seconds since EPOCH" time interface required byI > > >            POSIX st_atime. A site can choose a larger delta time to  > > > reduceB > > >            overhead if 1-second granularity is not required. > > >>L > > >           Another way to enable automatic update of access dates is to	 > > > use L > > >            the INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES command, > > > as > > >            follows:l > > >tK > > >            $ INITIALIZE/VOLUME_CHARACTERISTICS=ACCESS_DATES NODE$COE1 " > > >            $ MOUNT NODE$COE1 > > > H > > >            To disable access date support on a volume, use the SETK > > >            VOLUME/VOLUME_CHARACTERISTICS=NOACCESS_DATES command. ThisiN > > >            command affects only the node on which the command is issued.J > > >            Other nodes are not affected by the change until the next
 > > > time' > > >            the volume is mounted.n > > >aJ > > >            The DCL commands DIRECTORY or DUMP/HEADER support the new: > > >            timestamps. Use the following qualifiers: > > >a/ > > >            Qualifier          Descriptionf > > >>C > > >            /DATE=ACCESSED     Specifies the last access date.aM > > >            /DATE=ATTRIBUTES   Specifies the last attribute modification * > > >                                date.N > > >            /DATE=DATA_        Specifies the last data modification date. > > >            MODIFIED> > > >eJ > > >            For example, the following command displays the last time
 > > > data( > > >            was read from the file: > > >>* > > >            $ DIRECTORY/DATE=ACCESSED > > >p > > >aN > > > > Does anyone know how I can get rid of these file access date updates ? > > >d > > > Does the above help? > > >w > > > -- > > > Paul StureK > > Thanks, but I have tried these and SET VOL/VOL=ACC=[delta-time] doesn't " > > do what it's advertised to do. > >  > I > Just double checking that you aren't sharing this disk clusterwide, I'm  > assuming you saw this bit: > E > "This command affects only the node on which the command is issued.>; > Other nodes are not affected by the change until the next- > time the volume is mounted." >   > Are you on a support contract? >  > -- > Paul Sture  " The machine is running standalone.I And yes, we have a support contract and we will approach HP 'officially'.2  
 Andreas Gruhlr   ------------------------------  * Date: Thu, 5 Feb 2004 01:12:48 -0600 (CST) From: sms@antinode.orgH Subject: SYS$STARTUP:MMOV$SHUTDOWN.COM -- Insufficiently discriminating?) Message-ID: <04020501124811@antinode.org>n  E    While playing with my two-workststion cluster (Alpha, VMS V7.3-1), G I've noticed that the multimedia server keeps dying on my main system.  D I've lost track of the reasons, but my SYS$MANAGER:SYSHUTDWN.COM (onA both systems) contains code to run SYS$STARTUP:MMOV$SHUTDOWN.COM.i  G    Interestingly, running SYS$STARTUP:MMOV$SHUTDOWN.COM appears to shut.E down the MMOV$SERVER process on any node that's convenient, thanks tor9 its rather over-broad search for the MMOV$SERVER process:r  
 $ ctx = ""4 $!!! Hey, what do I care on which node it's running?9 $!!!                                VVVVVVVVVVVVVVVVVVVVVm: $ temp = F$CONTEXT ("PROCESS", ctx, "NODENAME", "*","EQL")C $ temp = F$CONTEXT ("PROCESS", ctx, "PRCNAM", "mmov$server", "EQL")r $ !i $ pid = F$PID(ctx) $ IF pid .EQS. ""0 $ THEN $       exit $ ELSE4 $       write sys$output "mmov$server shutting down" $       Stop /id='pid' $ ENDIFa  E    So, every time I shut down ALP2, it whacks the MMOV$SERVER on ALP,0? instead of its own.  Is there any good reason for this behavior = somewhere else?  (It certainly makes no sense in my cluster.)l  D    Commenting out the first use of F$CONTEXT solves the problem, as,F according to the HELP, 'The default is your local node. To request all nodes, use the value "*".'  (    PRODUCT SHOW PRODUCT /FULL MMOV says:  9 DEC AXPVMS MMOV V2.2                Full LP     Installed,  H ------------------------------------------------------------------------  4    Steven M. Schweda               (+1) 651-699-98183    382 South Warwick Street        sms@antinode-orgo    Saint Paul  MN  55105-2547,   ------------------------------   Date: 5 Feb 2004 10:41:24 -0600t- From: Kilgallen@SpamCop.net (Larry Kilgallen)eL Subject: Re: SYS$STARTUP:MMOV$SHUTDOWN.COM -- Insufficiently discriminating?3 Message-ID: <kd02dKWwO45W@eisner.encompasserve.org>h  B In article <04020501124811@antinode.org>, sms@antinode.org writes:  I >    Interestingly, running SYS$STARTUP:MMOV$SHUTDOWN.COM appears to shut G > down the MMOV$SERVER process on any node that's convenient, thanks toe; > its rather over-broad search for the MMOV$SERVER process:o  G >    So, every time I shut down ALP2, it whacks the MMOV$SERVER on ALP, A > instead of its own.  Is there any good reason for this behavioru? > somewhere else?  (It certainly makes no sense in my cluster.)f  B Perhaps it was tested in an environment where MMOV$ was running onF another machine somehow, but that should certainly not be the default.   ------------------------------   Date: 5 Feb 2004 07:14:40 -0800v2 From: ranjit_mathews@yahoo.com (M. Ranjit Mathews)* Subject: Re: VMS runs well on HP Superdome= Message-ID: <1d4c67e3.0402050714.572ef1fd@posting.google.com>   v "Charles J. Fisher" <cfisher@rhadmin.org> wrote in message news:<Pine.BSO.4.53.0402031500420.6320@bart.rhadmin.org>...* > On Thu, 15 Jan 2004, Keith Parris wrote: > K > > TruClusters and AdvFS from Tru64 will live on in HP-UX. The synergy hasi > > been excellent.i > 6 > In this particular regard, I must disagree with you. > B > Tru64 was technically superior to HP-UX in a number of respects. > E > HP had the opportunity to merge the two tastefully, creating a fineoI > vintage OS. HP-UX really needs to simply junk its packaging system, therI > imported Veritas filesystem, the 27 different installed versions of theaF > Korn shell (only slightly exaggerated), CDE, pfsd, harden the OS out > of the box, etc.  A What would HPUX users who are using these say if HP removed them?lE Different users might prefer different shells, there must be users of  CDE, and so on.a  J > I had really hoped to see a "TruHP" operating system that was a completeJ > overhaul and a new frontier for commercial UNIX, perhaps integrating GNUK > code in preference to SYSV. I wanted to see the same kernel on PA, Alpha,o > and Itanium.  @ That would have been nice, especially if it included MPE and VMS portability libraries.  ( > I wanted to see new ideas in userland. > J > Instead, Tru64 was basically the victim of a "smash and grab," and HP-UX > keeps all its faults.u  ? Doesn't an OS have to be fault-compatible with its predecessor?  > 0 > Yes, doing it right would have been expensive. > Q >     ---------------------------------------------------------------------------eP >    / Charles J. Fisher   |"How ridiculous not to flee from one's own wicked- /O >   /  cfisher@rhadmin.org | ness, which is possible, yet endeavor to flee    /oN >  /   http://rhadmin.org  | from another's, which is not." -Marcus Aurelius /M > ---------------------------------------------------------------------------e   ------------------------------  $ Date: Thu, 5 Feb 2004 08:38:46 +0100( From: "Rudolf Wingert" <win@fom.fgan.de>Y Subject: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - Sun Aa: Message-ID: <MCELKPMOKPMNDNKJNIONAEFACKAA.win@fom.fgan.de>   Hello,  O today I did get this message. Sorry, but this is in German and I am not able to M trnaslate it in understandable english. May be some one of you can do it. ThetJ quintessense of this message is: There are two security wholes within SunsN Solaris and other Unixex. With the first one, user can get all rights he want,M the second allows the user to hand up the system (DoS attack). Only the first 7 one is a problem of Solaris 9 (the newest one Solaris).u  ! -----Ursprngliche Nachricht-----dA Von: owner-local-cert@fgan.de [mailto:owner-local-cert@fgan.de]Imm# Auftrag von win-sec-ssc@dfn-cert.deo) Gesendet: Mittwoch, 4. Februar 2004 17:02t An: win-sec-ssc@dfn-cert.dedA Betreff: [local-cert] [Sun][Other] Schwachstellen in pfexec() undc% tcsetattr() - Sun Alert 57453 / 57474s    " -----BEGIN PGP SIGNED MESSAGE-----   Liebe Kolleginnen und Kollegen,d  B soeben erreichten uns die nachfolgenden Bulletins des SUN Customer= Warning System ueber unsere Kollegen von UNIRAS, dem CERT dernC britischen Regierung. Wir geben diese Informationen unveraendert an  Sie weiter.c   1) pfexec() - Sun Alert 57453-  F   Mittels "Execution Profiles" koennen normale Nutzer in Solaris 8 undF   9 bestimmte Kommandos mit besonderen Rechten ausfuehren (vgl. "sudo"   auf anderen Systemen).  E   Enthalt die Datenbasis fuer Nutzerprofile (/etc/security/exec_attr)nB   ungueltige Eintraege fuer einen bestimmten Benutzer, kann dieser@   mittels des pfexec(1) Aufrufs seine Privilegien ueber das Mass0   hinaus erweitern, welches das Profil vorsieht.  C   Betroffen von dieser Schwachstelle sind Solaris 8 und 9 auf Sparci<   und Intel Plattformen. Sun stellt Patches zur Behebung der   Schwachstelle bereit.     2) tcsetattr() - Sun Alert 57474  D   Durch einen Fehler ein der tcsetattr(3C) Funktion kann ein lokalerB   Angreifer das System "aufhaengen", indem er/sie die Funktion mitB   entsprechend formulierte Argumenten aufruft (Denial-of-Service).  H   Betroffen von dieser Schwachstelle sind Solaris 2.6, 7 und 8 auf SparcD   Plattformen. Intel Plattformen und Solaris 9 sind nicht betroffen.;   Sun stellt Patches zur Behebung der Schwachstelle bereit.o    : Das DFN-CERT bietet einen Mirror der Patches von Sun unter  - 	ftp://ftp.cert.dfn.de/pub/vendor/sun/patches    an.n  A (c) der deutschen Zusammenfassung bei DFN-CERT Services GmbH; diefF Verbreitung, auch auszugsweise, ist nur unter Hinweis auf den Urheber,I DFN-CERT Services GmbH, und nur zu nicht kommerziellen Zwecken gestattet.e   Mit freundlichen Gruessen, 		Klaus Moeller, DFN-CERTi    $ - -----BEGIN PGP SIGNED MESSAGE-----  P - - ---------------------------------------------------------------------------- ------L    UNIRAS (UK Govt CERT) Briefing Notice - 39/04 dated 03.02.04  Time: 10:05O  UNIRAS is part of NISCC(National Infrastructure Security Co-ordination Centre)sP - - ---------------------------------------------------------------------------- ------M   UNIRAS material is also available from its website at www.uniras.gov.uk andtC          Information about NISCC is available from www.niscc.gov.uk P - - ---------------------------------------------------------------------------- ------   Title  =====n  $ Two Sun Microsystems Security Alerts  H 1. The pfexec(1) Command May Execute a "Profile" Command With Additional Privileges.o  O 2. Security Vulnerability Involving the tcsetattr(3C) Library Function on SPARC  Based-    Systems.t       Detail ======  P 1.  A local unprivileged user with a custom rights profile (see profiles(1)) may be ablesN to execute a profile command with greater privileges than originally assigned, if theM execution profiles database (exec_attr(4)) contains an invalid entry for that  custom rights profile.h    C 2.  On SPARC based Solaris systems, a security vulnerability in thes" tcsetattr(3C) library function mayO allow an unprivileged local user the ability to hang the system hard which is an type of Denial of* Service (DoS).        F 1.   ESB-2004.0079 -- Sun(sm) Alert Notification - Sun Alert ID: 57453<                The pfexec(1) Command May Execute a "Profile"7                      Command With Additional Privileges@-                              02 February 2004b    ! Product:                pfexec(1)r( Publisher:              Sun Microsystems! Operating System:       Solaris 9i!                         Solaris 8  Platform:               SPARCe                         IA-32 , Impact:                 Increased Privileges( Access Required:        Existing Account   Original Bulletin:H          http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57453  G - - - --------------------------BEGIN INCLUDED TEXT--------------------w      DOCUMENT ID: 57453iG    SYNOPSIS: The pfexec(1) Command May Execute a "Profile" Command Withd    Additional Privileges    DETAIL DESCRIPTION:   Sun(sm) Alert Notification        * Sun Alert ID: 57453F      * Synopsis: The pfexec(1) Command May Execute a "Profile" Command!        With Additional Privilegeso      * Category: Securitys      * Product: Solaris       * BugIDs: 4925561      * Avoidance: Patche      * State: Resolved!      * Date Released: 29-Jan-2004,      * Date Closed: 29-Jan-2004       * Date Modified:a  	 1. Impactu  >    A local unprivileged user with a custom rights profile (seeE    profiles(1)) may be able to execute a profile command with greater:A    privileges than originally assigned, if the execution profilesoD    database (exec_attr(4)) contains an invalid entry for that custom    rights profile.   2. Contributing Factorss  2    This issue can occur in the following releases:      SPARC Platformg(      * Solaris 8 without patch 109007-15(      * Solaris 9 without patch 116237-01      x86 Platformt(      * Solaris 8 without patch 109008-15(      * Solaris 9 without patch 116238-01  	    Notes:-/     1. Solaris 7 is not affected by this issue.l@     2. The modification of the exec_attr(4) file requires "root"        privileges.  H    The pfexec(1) program is used to execute commands with the attributesH    specified by the user's profiles in the exec_attr(4) database. A userB    must be part of an execution profile in addition to the defaultI    profiles of "Basic Solaris User" and "All". A user can determine whichpF    profiles they are part of by running the profiles(1) command, as in    this example:     % profiles     Basic Solaris User     Allw   3. Symptoms   I    There are no reliable symptoms that would show the described issue hassE    been exploited to gain unauthorized elevated privileges on a host.a    SOLUTION SUMMARY:   4. Relief/Workaround  E    There is no workaround. Please see the "Resolution" section below.g  
 5. Resolution   5    This issue is addressed in the following releases:y      SPARC Platform .      * Solaris 8 with patch 109007-15 or later.      * Solaris 9 with patch 116237-01 or later      x86 Platformt.      * Solaris 8 with patch 109008-15 or later.      * Solaris 9 with patch 116238-01 or later  E    This Sun Alert notification is being provided to you on an "AS IS" I    basis. This Sun Alert notification may contain information provided byeI    third parties. The issues described in this Sun Alert notification mayoB    or may not impact your system(s). Sun makes no representations,H    warranties, or guarantees as to the information contained herein. ANYG    AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATIONiF    WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ORF    NON-INFRINGEMENT, ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENTG    YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT,rF    INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISEF    OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN.H    This Sun Alert notification contains Sun proprietary and confidentialI    information. It is being provided to you pursuant to the provisions of G    your agreement to purchase services from Sun, or, if you do not haver>    such an agreement, the Sun.com Terms of Use. This Sun AlertG    notification may only be used for the purposes contemplated by these,    agreements.  I    Copyright 2000-2004 Sun Microsystems, Inc., 4150 Network Circle, Santae.    Clara, CA 95054 U.S.A. All rights reserved.            F 2.   ESB-2004.0085 -- Sun(sm) Alert Notification - Sun Alert ID: 57474H   Security Vulnerability Involving the tcsetattr(3C) Library Function on/                             SPARC Based SystemsS-                              03 February 2004e    6 Product:                tcsetattr(3C) library function( Publisher:              Sun Microsystems! Operating System:       Solaris 8e!                         Solaris 7(#                         Solaris 2.6< Platform:               SPARC ) Impact:                 Denial of Servicea( Access Required:        Existing Account   Comment: Original Bulletin:   H          http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F57474  G - - - --------------------------BEGIN INCLUDED TEXT--------------------s      DOCUMENT ID: 57474vG    SYNOPSIS: Security Vulnerability Involving the tcsetattr(3C) Libraryn"    Function on SPARC Based Systems    DETAIL DESCRIPTION:   Sun(sm) Alert Notification        * Sun Alert ID: 57474C      * Synopsis: Security Vulnerability Involving the tcsetattr(3C)e.        Library Function on SPARC Based Systems      * Category: Securitya      * Product: Solarisc      * BugIDs: 4360114      * Avoidance: PatchS      * State: Resolved!      * Date Released: 30-Jan-2004o      * Date Closed: 30-Jan-2004T      * Date Modified:t  	 1. ImpactO  B    On SPARC based Solaris systems, a security vulnerability in theF    tcsetattr(3C) library function may allow an unprivileged local userC    the ability to hang the system hard which is a type of Denial ofe    Service (DoS).1   2. Contributing FactorsS  2    This issue can occur in the following releases:      SPARC Platforms*      * Solaris 2.6 without patch 105924-12(      * Solaris 7 without patch 107589-06(      * Solaris 8 without patch 109815-20  F    Note: Solaris 9 and Solaris on the x86 platform are not affected by    this issue.   3. Symptoms   H    If the described issue occurs, the system will be unresponsive, and a8    reboot is typically required to regain functionality.    SOLUTION SUMMARY:   4. Relief/Workaround  E    There is no workaround. Please see the "Resolution" section below.s  
 5. Resolution(  5    This issue is addressed in the following releases:       SPARC Platform 0      * Solaris 2.6 with patch 105924-12 or later.      * Solaris 7 with patch 107589-06 or later.      * Solaris 8 with patch 109815-20 or later      * Solaris 9  E    This Sun Alert notification is being provided to you on an "AS IS"TI    basis. This Sun Alert notification may contain information provided byiI    third parties. The issues described in this Sun Alert notification mayaB    or may not impact your system(s). Sun makes no representations,H    warranties, or guarantees as to the information contained herein. ANYG    AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION F    WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ORF    NON-INFRINGEMENT, ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENTG    YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT,TF    INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISEF    OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN.H    This Sun Alert notification contains Sun proprietary and confidentialI    information. It is being provided to you pursuant to the provisions of7G    your agreement to purchase services from Sun, or, if you do not have >    such an agreement, the Sun.com Terms of Use. This Sun AlertG    notification may only be used for the purposes contemplated by theseC    agreements.  I    Copyright 2000-2004 Sun Microsystems, Inc., 4150 Network Circle, SantaT.    Clara, CA 95054 U.S.A. All rights reserved.          P - - ---------------------------------------------------------------------------- ------  I For additional information or assistance, please contact the HELP Desk by J telephone or Not Protectively Marked information may be sent via EMail to: uniras@niscc.gov.ukq  
 Office Hours:  Mon - Fri: 08:30 - 17:00 Hrs" Tel: +44 (0) 20 7821 1330 Ext 4511 Fax: +44 (0) 20 7821 1686Z   Outside of Office Hours: On Call Duty Officer: 0 Tel: +44 (0) 20 7821 1330 and follow the prompts  P - - ---------------------------------------------------------------------------- ------J UNIRAS wishes to acknowledge the contributions of Sun Microsystems for the informationS contained in this Briefing.TP - - ---------------------------------------------------------------------------- ------L This Briefing contains the information released by the original author. SomeO of the information may have changed since it was released. If the vulnerabilitypO affects you, it may be prudent to retrieve the advisory from the canonical siteQP to ensure that you receive the most current information concerning that problem.  J Reference to any specific commercial product, process, or service by tradeH name, trademark manufacturer, or otherwise, does not constitute or implyL its endorsement, recommendation, or favouring by UNIRAS or NISCC.  The viewsJ and opinions of authors expressed within this notice shall not be used for, advertising or product endorsement purposes.  G Neither UNIRAS or NISCC shall also accept responsibility for any errorsnM or omissions contained within this briefing notice. In particular, they shall N not be liable for any loss or damage whatsoever, arising from or in connection; with the usage of information contained within this notice.R  O UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST)>K and has contacts with other international Incident Response Teams (IRTs) in N order to foster cooperation and coordination in incident prevention, to promptK rapid reaction to incidents, and to promote information sharing amongst itsm# members and the community at large.eP - - ---------------------------------------------------------------------------- ------ <End of UNIRAS Briefing> - -----BEGIN PGP SIGNATURE-----a Version: PGP 8.0  @ iQCVAwUBQB9zH4pao72zK539AQFzMAQAkkfgIJGLLtR5QJ5AohB59kVqfow2xRb/@ EHzHSPIage9zaK/Zkfz6KeSBOu7adAG0FbiXHHrFIOALLxN2hXF4egILfDOgjZk3@ PQHO7gjy2XAxhCm3KznQ6tUCPlcCLD/SGt2hB1Hh3ynaTATUyQuMbE7hE8mUkqwn HRSnag4Rf+M= =pk4k  - -----END PGP SIGNATURE-----e   - --H Dipl. Inform. Klaus Moeller  (CSIRT)              DFN-CERT Services GmbHH https://www.dfn-cert.de/                               +49-40-808077-555H PGP RSA/2048, 0BB7C8F9, 6D CC 59 0F 86 0C 58 4D  35 D7 0C 55 EF 4F 42 23   -----BEGIN PGP SIGNATURE-----I Version: 2.6.2iE  @ iQEVAwUBQCEXkIrEggYLt8j5AQF+Awf+N6r1xRWKdLQyqWabRhQsXnnot0lO9IcG@ Oi7hnBjlTROItMsij3RdqGlOKDnpSqYXvpK7tr3aHxxnigKIy1UAf+Le9lkQcEt2@ 6IGFp2UAKXwdrZtX1QsUmOVXGnepgEGgwKNXaermjx1nwBhCP7AgAn1iKMhWGXov@ R06DX+Km4bMYjdJRsDiI0A/BmVLnn/vcvA/afibVc6omy7LCwN02ErM6gfnaGJQt@ vYqog2Qcuiczgq4Wnu5KJsfVDXehOHHMbywS6Ak+GsnJhxXpH7UmSB1lpps8gPiW8 FEQXFOh4sus5MmSPKvlVtmBX2nASmz/iaZ2l2wNLXb5o4F/BFf3FZw== =FTOVS -----END PGP SIGNATURE-----e         Hinweis:F Um aus der Liste ausgetragen zu werden, eine Mail an majordomo@fgan.de. mit dem Text: unsubscribe local-cert schicken.   ------------------------------   Date: 5 Feb 2004 15:36:12 GMTu, From: bill@gw5.cs.uofs.edu (Bill Gunshannon)Y Subject: Re: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - Sa: Message-ID: <bvtntc$10t5c5$1@ID-135708.news.uni-berlin.de>  : In article <bvtdto$10b7s1$1@id-152801.news.uni-berlin.de>,6 	Michael Unger <spam.to.unger@spamgourmet.com> writes:. > On 2004-02-05 08:38, "Rudolf Wingert" wrote: > 	 >> Hello,a >> tR >> today I did get this message. Sorry, but this is in German and I am not able toR >> trnaslate it in understandable english. May be some one of you can do it. [...] > I > Why "translate"?? The original message (from UNIRAS) is appended to thee > German text. >   B And what does this have to do with VMS?  And you people still keep calling Andrew a troll......   bill   -- eJ 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>   e   ------------------------------  % Date: Thu, 05 Feb 2004 13:42:51 +0100I3 From: Michael Unger <spam.to.unger@spamgourmet.com>oY Subject: Re: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - S : Message-ID: <bvtdto$10b7s1$1@ID-152801.news.uni-berlin.de>  , On 2004-02-05 08:38, "Rudolf Wingert" wrote:   > Hello, > Q > today I did get this message. Sorry, but this is in German and I am not able toaQ > trnaslate it in understandable english. May be some one of you can do it. [...]e  G Why "translate"?? The original message (from UNIRAS) is appended to thel German text.   > [...]  > R > - - ---------------------------------------------------------------------------- > ------N >    UNIRAS (UK Govt CERT) Briefing Notice - 39/04 dated 03.02.04  Time: 10:05Q >  UNIRAS is part of NISCC(National Infrastructure Security Co-ordination Centre) R > - - ---------------------------------------------------------------------------- > ------O >   UNIRAS material is also available from its website at www.uniras.gov.uk andoE >          Information about NISCC is available from www.niscc.gov.ukaR > - - ---------------------------------------------------------------------------- > ------ >  > Title  > =====  > & > Two Sun Microsystems Security Alerts > J > 1. The pfexec(1) Command May Execute a "Profile" Command With Additional
 > Privileges.e > Q > 2. Security Vulnerability Involving the tcsetattr(3C) Library Function on SPARCL > Based[
 >    Systems.s >  > [...]a   Michaelr   -- o; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system.e5 My e-mail account at DECUS Munich is no longer valid.t   ------------------------------  % Date: Thu, 05 Feb 2004 17:04:04 +0100u3 From: Michael Unger <spam.to.unger@spamgourmet.com> Y Subject: Re: WG: [local-cert] [Sun][Other] Schwachstellen in pfexec() und tcsetattr() - Sh: Message-ID: <bvtta1$10h5vo$1@ID-152801.news.uni-berlin.de>  - On 2004-02-05 16:36, "Bill Gunshannon" wrote:m   > [...]r > 0 > And what does this have to do with VMS?  [...]   Nothing of course.   Michaela   -- a; Real names enhance the probability of getting real answers. @ Please do *not* send "Security Patch Notifications" or "SecurityA Updates"; this system isn't running a Micro$oft operating system.o5 My e-mail account at DECUS Munich is no longer valid.u   ------------------------------  % Date: Thu, 05 Feb 2004 04:18:48 -0500r' From: John Sauter <J_Sauter@Empire.Net>c% Subject: Re: Why was VAX abandonned ?l8 Message-ID: <bh24209lnqkvh3hcncfdma6aut8cc54h3u@4ax.com>   JF Mezei wrote:e    ( Power was able to go from 32 to 64 bits.3 The 8086 was able to go from 8/16 to 32 to 64 bits.u  ' Why couldn't VAX have gone to 64 bits ?    John Sauter responded:  - It did, twice.  The one that actually shippeds was called Alpha.,%     John Sauter (J_Sauter@Empire.Net)M   ------------------------------  % Date: Thu, 05 Feb 2004 05:50:19 -0500h( From: David Froble <davef@tsoft-inc.com>% Subject: Re: Why was VAX abandonned ?s, Message-ID: <40221FEB.7090401@tsoft-inc.com>   John Brandon wrote:    >>What about VLM arrays? >>: >>  The capacity of a 32-bit architecture against a 64-bit >>  architecture, is there9 >>  not a memory limitation associated with the bit size?g >>D >>  Would you be able to plug a VAX chip into the switch environment >>  (mesh) thatP( >>  the Alpha is now?  How about GALAXY? >>. >>  I believe David Froble hits it on the head >>G >>I don't think so.  You assume that the only thing you could do was to,I >>shrink the die.  Do you think the Pentium today uses the same design astE >>the earlier X86's.  Pentium today is largely an x86 set instruction7J >>emulator on a core (used to be a modified 801 architecture,don't if that >>is still the case) >>K >>Digital had been far better off and could possibly have survived had theylI >>taken a similar approach.  Had they done so, I repeat, that there is no L >>irrefutable reason why a VAX instruction set computer couldn't have run atH >>the same speed as pentium other than lack of vision and will to do so. >> > O > At what cost?  Was not Palmer the guy who said desktop PC are nonsense?  MoreE, > to it than just the direction of the chip. > O > And how does that account for memory limitations of a 32-bit instruction set?e > P > It is easy (and fun) to play the what-if game.  However there were limitationsQ > to the VAX architecture.  At what expense and cost of performance would it haveCM > taken to get the VAX chip to a level of Pentium?  So what if you did?  Then G > what?  Would you have the same problems the chip has now?  Lackluster  > performance?    8 I think what I was trying to say has been misunderstood.  O I think the Alpha was a good direction for DEC to go.  It's record as the best nQ of the best, right up until it's funding was reduced, then entirely chopped off, . is proof of this.r  Q But DEC didn't need to ignore the VAX business.  Have Alpha at the high end, and  Q VAX for thise who still required it for whatever reasons.  Reasons could include eM using software that never mede it to Alpha, embedded controllers that worked QO well and didn't need more capabilities, small business, the desktop, and such.  N As long as the VAX business made profits, there was no reason to kill it off. P Reduced R&D is Ok.  Alpha would be the CPU for those who required more than the  VAX had to give.  P The marketing of DEC left much to be desired.  At one time, an AlphaServer 1000 M with VMS sold for around $18,000.  At the same time a MicroVAX 3100 model 98 rK sold with VMS for about $37,000.  In hindsight it's pretty clear what such y< practices told the customers, and what they did in response.  Q Note that this is before many people left VMS for cheaper pastures.  What if DEC aM would have priced the MicroVAX relative to it's capabilities compared to the rQ Alpha?  Say for 1/3 of the price of the Alpha.  At $6,000 in that time frame the 0M VAX would have sold well, and if the overhead of the VAX business was trimed e- appropriately, there would have been profits.a  N Keep in mind that before the last N-VAX production was shut down, enough CPUs L were produced for a 5-year supply.  Even with the price gouging, the supply M didn't last the 5 years.  Maybe they all became earrings, but I'd think that o0 there was a market, that was screwed up royally.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Roadt Vanderbilt, PA  15486    ------------------------------  $ Date: Thu, 5 Feb 2004 22:43:31 +1100' From: "alphadoc" <all.the.fun@the.fair>s% Subject: Re: Why was VAX abandonned ?o; Message-ID: <40222b3e$0$5224$afc38c87@news.optusnet.com.au>m  ? None of these discussions acknowledge the one amazing thing theDI microsoft/intel evolution have done; they have brought cheap computing tof the masses.tH Truly mass volumes have been achieved that make pci cards, agp cards etc: cheap and readily available from the corner computer shop.I This could never have happened with the existing DEC mindset from the vaxoE era. Even alpha pricing meant that the mass market was never going to  happen.nK Novell once a big name in networking, has fallen victim to the same dilemma." as DEC; but these are side issues.  G My biggest consern is for "what's next". Where should I spend my budgete+ dollars that won't end up a white elephant.o  ) What lessons can be learnt from the past?S Thanks,e no name; no spam.n   Tom Linden wrote in message ...d@ >There is no reason why VAX architecture couldn't run as fast asA >Pentium.  Alpha was a foolish adventure.  My expreience suggestssC >that it takes more-or-less two ticks of alpha to equal one of VAX.  >e >t >  -----Original Message-----o4 >  From: JF Mezei [mailto:jfmezei.spamnot@istop.com], >  Sent: Tuesday, February 03, 2004 10:56 AM >  To: Info-VAX@Mvb.Saic.Com$ >  Subject: Why was VAX abandonned ? >s > J >  > > I personally think a 64-bit extended VAX architecture incorporating9 >  > > current processor technologies would be dreamy :-)  > D >  At the time the decision was made to ditch VAX and develop Alpha,
 >  were there ? >  compelling technical reasons to do so, or was there a strong: >  marketing urge to* >  adopt the then buzzword-du-jour: RISC ? >TA >  The one argument I had heard was the need to have fixed length  >  instruction setD >  in order to make pipelining etc work better. Does the 8086 have a >  fixed lengthc >  instruction set ? >t@ >  When one looks at what Intel was able to do with the 8086, it >  makes one wonderi- >  if the same could have been done with VAX.  >1' >  What was the fastest VAX chip made ?  >  > D >  Also, if, for my birthday, Sue were to give me the rights and all >  designs forL >  VAX architecture, could I go to TI, IBM or Intel and ask them to FAB me a >  couple thousands VAX chips ?s > J >  If, during the last fab, they clocked the VAX at say 200mhz,  if I were toJ >  provide the same designs today, but have it fabbed using the latest and> >  greatest process, could the mhz be cranked up significantly >  because the chip,G >  albeit the same phsyical size as before, would be manufacturerd witho/ >  significantly better precision than before ?  >  >  ---) >  Incoming mail is certified Virus Free. = >  Checked by AVG anti-virus system (http://www.grisoft.com).tC >  Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004D >s >---' >Outgoing mail is certified Virus Free.e; >Checked by AVG anti-virus system (http://www.grisoft.com).rA >Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004  >c   ------------------------------   Date: 5 Feb 2004 07:20:24 -0600c; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: Why was VAX abandonned ?/3 Message-ID: <xg4PCIEVouJj@eisner.encompasserve.org>n  W In article <40221FEB.7090401@tsoft-inc.com>, David Froble <davef@tsoft-inc.com> writes:m > S > But DEC didn't need to ignore the VAX business.  Have Alpha at the high end, and  ; > VAX for thise who still required it for whatever reasons.   D    There wasn't any VAX business.  When DEC introduced the VAX, theyG    thought PDP-11 business would go away within five years.  It didn't.uH    Customers who were doing new things bought VAXen.  Customers who wereH    replacing existing systems kept buying PDP-11.  Five years later DEC K    found it economically benificial to introduce new PDP-11 models to take iI    advantage of new technology that let them make PDP-11 at lower cost.  sF    Today there's still enough PDP-11 business to keep Mentech going.    H    When DEC introduced the Alpha, they hoped that the VAX business wouldD    keep going for a while.  It didn't.  Customers who were doing newG    things bought Alphas or went to other vendors.  Customers replacing hH    existing systems bought Alphas or went to other vendors.  Five years J    later they were fabbing the last chips for a line of systems that were     making too little money.?   ------------------------------   Date: 5 Feb 2004 07:13:09 -0600 ; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)d% Subject: Re: Why was VAX abandonned ? 3 Message-ID: <kOxeVZItHtJD@eisner.encompasserve.org>   V In article <40217EBA.2FB25402@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > * > Power was able to go from 32 to 64 bits.5 > The 8086 was able to go from 8/16 to 32 to 64 bits.O > ) > Why couldn't VAX have gone to 64 bits ?   C   It could have.  We could in principle now have 64 bit PDP-8, too. @   But the VAX performance issue prevented justification for the G   effort needed.  Why not build a fast chip at the same time as puttingC(   in 64 bits?  That's just what DEC did.   ------------------------------   Date: 5 Feb 2004 07:11:21 -0600Q; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) % Subject: Re: Why was VAX abandonned ?u3 Message-ID: <m0yHYz3ifQXd@eisner.encompasserve.org>i  V In article <40217DAA.F7493BDC@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > Bob Koehler wrote:E >>    The compelling reason was that DEC did a nose dive when the VAXy? >>    simply couldn't keep up with everyone else's performance.s >  > P > No. The real reason was that Digital did not lower the prices of VAXes quicklyP > enough to maintauin price-performance leadership against the newcomers such as > Apollo and Sun.X  A    While the performance was gasping it's last breath, cheap RISC-D    workstations were close to VAX 9000 performance levels.  Sure theE    price/performance was poor, but peak performance was also missing.e   ------------------------------   Date: 5 Feb 2004 07:23:29 -0600-; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)r% Subject: Re: Why was VAX abandonned ?l3 Message-ID: <qjaEKS03PgEu@eisner.encompasserve.org>n  e In article <40222b3e$0$5224$afc38c87@news.optusnet.com.au>, "alphadoc" <all.the.fun@the.fair> writes:1 > + > What lessons can be learnt from the past?   F    The average consumer has been taught that computers are unreliable.E    You can sell them anything that will keep their attention for fivet    minutes.h  C    When the same systems are applied to serious business the TCO ism6    bigger, but the purchase cost still blinds the CIO.   ------------------------------  # Date: Thu, 05 Feb 2004 13:44:55 GMTe9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> % Subject: Re: Why was VAX abandonned ?n4 Message-ID: <rNrUb.13834$3A6.12433@news.cpqcorp.net>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message-# news:40217DAA.F7493BDC@istop.com...0 > Bob Koehler wrote:F > >    The compelling reason was that DEC did a nose dive when the VAX@ > >    simply couldn't keep up with everyone else's performance. >n >oH > No. The real reason was that Digital did not lower the prices of VAXes quickly.H > enough to maintauin price-performance leadership against the newcomers such asi > Apollo and Sun.r  J Apollo was never a threat.  I agree that there were times *before* the VAXK was running on vapors that aggressive pricing (on say, the VAXstation 2000) K may have changed the long term outcomes of what were at the time very smallPL upstarts like Sun.  However, DEC found itself desperately lowering prices toE be in the "price/performance" curve - but low on it... while the nexto5 generation of VAX processors never arrived (in time).s   ------------------------------  # Date: Thu, 05 Feb 2004 13:49:26 GMT 9 From: "Fred Kleinsorge" <my-last-name@stardotzko.dec.com> % Subject: Re: Why was VAX abandonned ?l3 Message-ID: <GRrUb.13835$Bx6.2787@news.cpqcorp.net>e  L But the PC really arrived when DEC "thought" that the competition for it wasG the PDP11.  The Pro-300 was the ill-fated response, and did reflect themJ opinion that it was so much better technology that people would just flockK to it.  The VAX was big-iron in comparison, and it was years before it madenJ it down to workstations.  If there was a real DEC mistake, the mistake wasJ to not pursue the merger with Apple and adopt the Lisa (which evolved into	 the Mac).a      2 "alphadoc" <all.the.fun@the.fair> wrote in message5 news:40222b3e$0$5224$afc38c87@news.optusnet.com.au...eA > None of these discussions acknowledge the one amazing thing the K > microsoft/intel evolution have done; they have brought cheap computing to-
 > the masses.aJ > Truly mass volumes have been achieved that make pci cards, agp cards etc< > cheap and readily available from the corner computer shop.K > This could never have happened with the existing DEC mindset from the vaxMG > era. Even alpha pricing meant that the mass market was never going to-	 > happen.-E > Novell once a big name in networking, has fallen victim to the same8 dilemma1$ > as DEC; but these are side issues. >dI > My biggest consern is for "what's next". Where should I spend my budgetc- > dollars that won't end up a white elephant.K >O+ > What lessons can be learnt from the past? 	 > Thanks,h > no name; no spam.t >i! > Tom Linden wrote in message ... B > >There is no reason why VAX architecture couldn't run as fast asC > >Pentium.  Alpha was a foolish adventure.  My expreience suggests E > >that it takes more-or-less two ticks of alpha to equal one of VAX.c > >t > >r > >  -----Original Message----- 6 > >  From: JF Mezei [mailto:jfmezei.spamnot@istop.com]. > >  Sent: Tuesday, February 03, 2004 10:56 AM > >  To: Info-VAX@Mvb.Saic.Com& > >  Subject: Why was VAX abandonned ? > >g > > L > >  > > I personally think a 64-bit extended VAX architecture incorporating; > >  > > current processor technologies would be dreamy :-)- > >dF > >  At the time the decision was made to ditch VAX and develop Alpha, > >  were there A > >  compelling technical reasons to do so, or was there a strongb > >  marketing urge to, > >  adopt the then buzzword-du-jour: RISC ? > >lC > >  The one argument I had heard was the need to have fixed lengthA > >  instruction setF > >  in order to make pipelining etc work better. Does the 8086 have a > >  fixed length( > >  instruction set ? > >tB > >  When one looks at what Intel was able to do with the 8086, it > >  makes one wonderi/ > >  if the same could have been done with VAX.u > >e) > >  What was the fastest VAX chip made ?f > >u > >rF > >  Also, if, for my birthday, Sue were to give me the rights and all > >  designs forL > >  VAX architecture, could I go to TI, IBM or Intel and ask them to FAB me ai! > >  couple thousands VAX chips ?v > >hL > >  If, during the last fab, they clocked the VAX at say 200mhz,  if I were > toL > >  provide the same designs today, but have it fabbed using the latest and@ > >  greatest process, could the mhz be cranked up significantly > >  because the chip,I > >  albeit the same phsyical size as before, would be manufacturerd withu1 > >  significantly better precision than before ?u > >  > >  ---+ > >  Incoming mail is certified Virus Free.t? > >  Checked by AVG anti-virus system (http://www.grisoft.com).aE > >  Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004B > >n > >---) > >Outgoing mail is certified Virus Free.e= > >Checked by AVG anti-virus system (http://www.grisoft.com)..C > >Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004n > >  >- >T   ------------------------------  $ Date: Thu, 5 Feb 2004 06:09:00 -0800# From: "Tom Linden" <tom@kednos.com> % Subject: RE: Why was VAX abandonned ?e9 Message-ID: <NDEMLKKEBOIFBMJLCECIIEHECMAA.tom@kednos.com>l     -----Original Message-----@   From: Fred Kleinsorge [mailto:my-last-name@stardotzko.dec.com]+   Sent: Thursday, February 05, 2004 5:49 AM-   To: Info-VAX@Mvb.Saic.Com)'   Subject: Re: Why was VAX abandonned ?T    C   But the PC really arrived when DEC "thought" that the competitiono   for it wasI   the PDP11.  The Pro-300 was the ill-fated response, and did reflect the-L   opinion that it was so much better technology that people would just flock>   to it.  The VAX was big-iron in comparison, and it was years   before it madeL   it down to workstations.  If there was a real DEC mistake, the mistake wasL   to not pursue the merger with Apple and adopt the Lisa (which evolved into   the Mac).e  ; But then you would have had to order your bits correctly:-)       4   "alphadoc" <all.the.fun@the.fair> wrote in message7   news:40222b3e$0$5224$afc38c87@news.optusnet.com.au...tC   > None of these discussions acknowledge the one amazing thing the @   > microsoft/intel evolution have done; they have brought cheap   computing to   > the masses.sL   > Truly mass volumes have been achieved that make pci cards, agp cards etc>   > cheap and readily available from the corner computer shop.@   > This could never have happened with the existing DEC mindset   from the vaxI   > era. Even alpha pricing meant that the mass market was never going to    > happen.eG   > Novell once a big name in networking, has fallen victim to the same2	   dilemma &   > as DEC; but these are side issues.   >4K   > My biggest consern is for "what's next". Where should I spend my budget /   > dollars that won't end up a white elephant.    > -   > What lessons can be learnt from the past?c   > Thanks,    > no name; no spam.e   > #   > Tom Linden wrote in message ... D   > >There is no reason why VAX architecture couldn't run as fast asE   > >Pentium.  Alpha was a foolish adventure.  My expreience suggests G   > >that it takes more-or-less two ticks of alpha to equal one of VAX.    > >l   > >i!   > >  -----Original Message-----m8   > >  From: JF Mezei [mailto:jfmezei.spamnot@istop.com]0   > >  Sent: Tuesday, February 03, 2004 10:56 AM    > >  To: Info-VAX@Mvb.Saic.Com(   > >  Subject: Why was VAX abandonned ?   > >a   > >l@   > >  > > I personally think a 64-bit extended VAX architecture   incorporating =   > >  > > current processor technologies would be dreamy :-)e   > >(H   > >  At the time the decision was made to ditch VAX and develop Alpha,   > >  were thererC   > >  compelling technical reasons to do so, or was there a strong*   > >  marketing urge to.   > >  adopt the then buzzword-du-jour: RISC ?   > > E   > >  The one argument I had heard was the need to have fixed length    > >  instruction setH   > >  in order to make pipelining etc work better. Does the 8086 have a   > >  fixed lengthd   > >  instruction set ?   > >nD   > >  When one looks at what Intel was able to do with the 8086, it   > >  makes one wonderd1   > >  if the same could have been done with VAX.n   > >n+   > >  What was the fastest VAX chip made ?f   > >g   > >eH   > >  Also, if, for my birthday, Sue were to give me the rights and all   > >  designs for?   > >  VAX architecture, could I go to TI, IBM or Intel and askh   them to FAB me   ar#   > >  couple thousands VAX chips ?t   > > C   > >  If, during the last fab, they clocked the VAX at say 200mhz,o    if I were   > toC   > >  provide the same designs today, but have it fabbed using thei   latest andB   > >  greatest process, could the mhz be cranked up significantly   > >  because the chip,K   > >  albeit the same phsyical size as before, would be manufacturerd withu3   > >  significantly better precision than before ?u   > > 
   > >  ----   > >  Incoming mail is certified Virus Free.hA   > >  Checked by AVG anti-virus system (http://www.grisoft.com). G   > >  Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004s   > >    > >---+   > >Outgoing mail is certified Virus Free.i?   > >Checked by AVG anti-virus system (http://www.grisoft.com).TE   > >Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004s   > >h   >s   >o       ---b(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004   ---c& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004   ------------------------------  $ Date: Thu, 5 Feb 2004 06:07:42 -0800# From: "Tom Linden" <tom@kednos.com>v% Subject: RE: Why was VAX abandonned ?d9 Message-ID: <NDEMLKKEBOIFBMJLCECIEEHECMAA.tom@kednos.com>      -----Original Message-----@   From: Fred Kleinsorge [mailto:my-last-name@stardotzko.dec.com]+   Sent: Thursday, February 05, 2004 5:45 AMA   To: Info-VAX@Mvb.Saic.ComC'   Subject: Re: Why was VAX abandonned ?       9   "JF Mezei" <jfmezei.spamnot@istop.com> wrote in messageI%   news:40217DAA.F7493BDC@istop.com...A   > Bob Koehler wrote:H   > >    The compelling reason was that DEC did a nose dive when the VAXB   > >    simply couldn't keep up with everyone else's performance.   >    >OJ   > No. The real reason was that Digital did not lower the prices of VAXes	   quicklyiJ   > enough to maintauin price-performance leadership against the newcomers	   such ast   > Apollo and Sun.   L   Apollo was never a threat.  I agree that there were times *before* the VAX<   was running on vapors that aggressive pricing (on say, the   VAXstation 2000)B   may have changed the long term outcomes of what were at the time   very small;   upstarts like Sun.  However, DEC found itself desperately    lowering prices toG   be in the "price/performance" curve - but low on it... while the next-7   generation of VAX processors never arrived (in time).u  G BTW, the same happened to Prime and DG.  Intel was able to keep pumpimg G the X86 thanks to Microsoft, until they were finally able to match (and  exceed)2" the performance of the RISC chips.     ---C(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004   ---m& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004   ------------------------------  $ Date: Thu, 5 Feb 2004 09:33:55 -0500# From: "Dan Allen" <dallen@nist.gov>-% Subject: RE: Why was VAX abandonned ?v: Message-ID: <JFEPKAPBPMDFDBOIANGDAEANEMAA.dallen@nist.gov>   > -----Original Message-----3 > From: JF Mezei [mailto:jfmezei.spamnot@istop.com] , > Sent: Wednesday, February 04, 2004 6:18 PM > To: Info-VAX@Mvb.Saic.Com ' > Subject: Re: Why was VAX abandonned ?e >  >  > Bob Koehler wrote:F > >    The compelling reason was that DEC did a nose dive when the VAX@ > >    simply couldn't keep up with everyone else's performance. >  > P > No. The real reason was that Digital did not lower the prices of VAXes quicklyP > enough to maintauin price-performance leadership against the newcomers such as > Apollo and Sun.t  B It wasn't the price of the Vax - it was the price of the software.^ The myth of a free hardware generic OS (UNIX) took the masses by storm (can you spell Linux)?    Dann >  >    ------------------------------   Date: 5 Feb 2004 14:59:46 GMTC, From: bill@gw5.cs.uofs.edu (Bill Gunshannon)% Subject: Re: Why was VAX abandonned ?h: Message-ID: <bvtlp2$113d9k$1@ID-135708.news.uni-berlin.de>  9 In article <NDEMLKKEBOIFBMJLCECIEEHECMAA.tom@kednos.com>,e& 	"Tom Linden" <tom@kednos.com> writes: > + > BTW, the same happened to Prime and DG.    >   C Not sure I would agree with this.  Having been a Pr1me guy in theirlD glory days it always seemd to me that the nails in their coffin wereA the systems they decided to sell that were not based on their owntD technology but merely re-badged computers from another manufacturer.E Basicly, it took money that should have been going into their coffers*6 and diverted it to someone else's.  (Sound familiar??)  D While today many people may look back and think of Pr1me as a nobodyF in the business, I worked with the 50 Series alongside mainframes likeC Univac and Honeywell and the little Pr1me's easily outperformed therD "big iron".  And, like the VAX and the PDP, long after the demise ofA the company there are still an amazing number of systems still inr production operation.a   bill   -- aJ 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>   E   ------------------------------  % Date: Thu, 05 Feb 2004 09:04:18 -0600T( From: brandon@dalsemi.com (John Brandon)% Subject: Re: Why was VAX abandonned ?O1 Message-ID: <04020509041889@dscis6-0.dalsemi.com>N   Dan Allen writes:uD > It wasn't the price of the Vax - it was the price of the software.Q > The myth of a free hardware generic OS (UNIX) took the masses by storm (can youm > spell Linux)?   ' I disagree with half of that statement.   L The VAX hardware (and Alpha hardware) and VMS software is expensive comparedM to other platforms.  It was/is a better product than most of the competition.pH I believe it worth the price - however when you have bottom-line focusedI executives then the TCO of goes out the door and you have junk coming in.-  J The VAX and Alpha hardware have always been more expensive for a number of reasons.  In my opinion...  N 1) Market share - bulk chips are much easier to sell at a reduced costs.  ThatM supply and demand thing.  Have lots of supply and lower the price then create M the demand.  This does not make the chip better just more readily avaiable at1 an affordable price.  K Since VAX or Alpha chips were not the bulk of the chips on the market theirp cost was inflated.  G 2) Market target - the VAX and Alpha were targeted towards the business-K community - this translates to more dollars to invest and therefore the MFGeO feels they can charge more.  I believe that when the PC hit the consumer market-M and landed in the homes and eventually on the the desk top there was bound toe1 be long term changes and impacts on the big IRON.   K Consumers expect quality product at cheap prices.  Business followed suit -pJ since the business community is not more than the consumer community - us.  I Now getting a quality product at a cheap price is another thing mind you.a  M 3) Server design.  I remember when the 486 came out on the market.  My fatheryL bought one - as it was a "Multi-Media" computer.  I laugh at the Multi-MediaN label - since a 2400 baud modem, printer, sound card and pair of speakers wereL thrown into the box with the PC and monitor.  Presto, you have a Multi-Media computer system.  L My point - business ended servers are typically more robust, have CPU bladesJ with cache, larger memory, redundant power, etc. - making the product more expensive.  But well worth it.    M LINUX?  I wonder if VMS should become freeware to survive...  Much less othere O/S...     J*o*h*n B*r*a*n*d*o*nh VMS Systems Administratori* firstname.lastname.spam.me.not@dalsemi.com   ------------------------------  $ Date: Thu, 5 Feb 2004 06:56:52 -0800# From: "Tom Linden" <tom@kednos.com>e% Subject: RE: Why was VAX abandonned ?n9 Message-ID: <NDEMLKKEBOIFBMJLCECIAEHGCMAA.tom@kednos.com>e     -----Original Message-----5   From: Bill Gunshannon [mailto:bill@gw5.cs.uofs.edu]e+   Sent: Thursday, February 05, 2004 7:00 AM-   To: Info-VAX@Mvb.Saic.Com-'   Subject: Re: Why was VAX abandonned ?>    ;   In article <NDEMLKKEBOIFBMJLCECIEEHECMAA.tom@kednos.com>,B(   	"Tom Linden" <tom@kednos.com> writes:   >o+   > BTW, the same happened to Prime and DG.H   >L  E   Not sure I would agree with this.  Having been a Pr1me guy in theirMF   glory days it always seemd to me that the nails in their coffin wereC   the systems they decided to sell that were not based on their owneF   technology but merely re-badged computers from another manufacturer.G   Basicly, it took money that should have been going into their coffers 8   and diverted it to someone else's.  (Sound familiar??)  F   While today many people may look back and think of Pr1me as a nobodyH   in the business, I worked with the 50 Series alongside mainframes likeE   Univac and Honeywell and the little Pr1me's easily outperformed theRF   "big iron".  And, like the VAX and the PDP, long after the demise ofC   the company there are still an amazing number of systems still inn   production operation.F  D I had seveal 50 series as well.  Guess who provided their compilers?     bill     --L   Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF   bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.   University of Scranton   |@   Scranton, Pennsylvania   |         #include <std.disclaimer.h>     ---h(   Incoming mail is certified Virus Free.<   Checked by AVG anti-virus system (http://www.grisoft.com).B   Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004   ---<& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.566 / Virus Database: 357 - Release Date: 1/22/2004   ------------------------------  % Date: Thu, 05 Feb 2004 09:54:43 -0500b* From: JF Mezei <jfmezei.spamnot@istop.com>% Subject: Re: Why was VAX abandonned ?r) Message-ID: <40225927.6600674B@istop.com>x   Bob Koehler wrote:C >    While the performance was gasping it's last breath, cheap RISCwF >    workstations were close to VAX 9000 performance levels.  Sure theG >    price/performance was poor, but peak performance was also missing.e  H gasping last breath ? Seems to me that Digital was able to significantlyO increase the VAX performance after the start of the decline in the late 1980s. -  I Secondly, even if vax wasn't a world leader in performance at that stage,gK proper pricing would still have made it a ideal choice for workstations. IteL was still far more performant than the 8086 desktops. And yes, it would haveK have to be sold cheaper that the higher performance new kids on the block.    L And with clustering which others didn't have, you could have setup a clusterF of cheap less performant VAXes to get the computing power you needed.   N History has shown that the money was in the large volume low value market, not' the low volume high performance market.     G Look at wintel: with performance far worse than VAX, but with the right- pricing, they succeeded.   ------------------------------   Date: 5 Feb 2004 15:45:39 GMT:, From: bill@gw5.cs.uofs.edu (Bill Gunshannon)% Subject: Re: Why was VAX abandonned ? : Message-ID: <bvtof3$10t5c5$2@ID-135708.news.uni-berlin.de>  9 In article <NDEMLKKEBOIFBMJLCECIAEHGCMAA.tom@kednos.com>,s& 	"Tom Linden" <tom@kednos.com> writes: > F > I had seveal 50 series as well.  Guess who provided their compilers? >   < Hmmmm......  University of Sheffield.(F77)  Garth Conboy.(C)  A All the rest came directly from Pr1me and all my support contactswD were directly with them so I assumed they did most of it themselves.) Boy do I miss working with SPL and PL1/g.l   bill   -- eJ 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>   y   ------------------------------  $ Date: Thu, 5 Feb 2004 11:16:51 -0500# From: "Dan Allen" <dallen@nist.gov>i% Subject: RE: Why was VAX abandonned ?v: Message-ID: <JFEPKAPBPMDFDBOIANGDGEBAEMAA.dallen@nist.gov>   > -----Original Message-----1 > From: John Brandon [mailto:brandon@dalsemi.com]c, > Sent: Thursday, February 05, 2004 10:04 AM > To: Info-VAX@Mvb.Saic.Comt' > Subject: Re: Why was VAX abandonned ?- >8 >n > Dan Allen writes: F > > It wasn't the price of the Vax - it was the price of the software.S > > The myth of a free hardware generic OS (UNIX) took the masses by storm (can youe > > spell Linux)?e >o) > I disagree with half of that statement.d >nN > The VAX hardware (and Alpha hardware) and VMS software is expensive comparedO > to other platforms.  It was/is a better product than most of the competition. J > I believe it worth the price - however when you have bottom-line focusedK > executives then the TCO of goes out the door and you have junk coming in.s   <snip>  I Agreed but DEC's departure from it's original software licensing model toiJ a much costlier structure greatly excacerbated the HW price differentials.J We for example would have been happy to pay the HW differential to upgradeH existing VAX systems but when the software upgrade costs for existing LPK exceeded the HW cost by an order of magnitude the decision was a done deal.- We made it to Alpha ONLY because DEC promoted the HW by offering transfers of all our licensed SW as part of the HW deal. The cost of our unlimited user VMS license for the AXP 3000-800 we bought DWARFED the HW cost not to mention unlimited use licenses for DEC! C, Fortran, Pascal, Cobol, Basic,4 Datatrieve, ADA, and RDB.t   We were/are basically an R&D operation - we don't need a lot of HW performance just an extensive SW portfolio. HW upgrades were/aree just tom keep current with technology. My management couldn't justify the SW cost expenditures of follow-on AXP upgrades - we spent the money
 to migrate toeI a "open source, nonproprietary" environment (Sun OS on Sparc) instead.  AuK quadruple amputee can now count the number of Suns we run without unzippingeL their pants. Can you spell Linux and Intel? Same argument, different decade.   I'm 53 years old and I expect to be retired and playing golf daily (which I pretty much do now anyway ;-) when the next cycle rollse in.i   Cheers,a   Dand   ------------------------------   Date: 5 Feb 2004 10:49:05 -0600a- From: Kilgallen@SpamCop.net (Larry Kilgallen) % Subject: RE: Why was VAX abandonned ?h3 Message-ID: <wKVcVdf0xCm2@eisner.encompasserve.org>a  _ In article <NDEMLKKEBOIFBMJLCECIAEHGCMAA.tom@kednos.com>, "Tom Linden" <tom@kednos.com> writes:e >  >  >   -----Original Message-----7 >   From: Bill Gunshannon [mailto:bill@gw5.cs.uofs.edu]n- >   Sent: Thursday, February 05, 2004 7:00 AMw >   To: Info-VAX@Mvb.Saic.Come) >   Subject: Re: Why was VAX abandonned ?t >  > = >   In article <NDEMLKKEBOIFBMJLCECIEEHECMAA.tom@kednos.com>,e* >   	"Tom Linden" <tom@kednos.com> writes: >   >d- >   > BTW, the same happened to Prime and DG.l >   >  > G >   Not sure I would agree with this.  Having been a Pr1me guy in theirsH >   glory days it always seemd to me that the nails in their coffin wereE >   the systems they decided to sell that were not based on their ownfH >   technology but merely re-badged computers from another manufacturer.I >   Basicly, it took money that should have been going into their coffersa: >   and diverted it to someone else's.  (Sound familiar??) > H >   While today many people may look back and think of Pr1me as a nobodyJ >   in the business, I worked with the 50 Series alongside mainframes likeG >   Univac and Honeywell and the little Pr1me's easily outperformed theoH >   "big iron".  And, like the VAX and the PDP, long after the demise ofE >   the company there are still an amazing number of systems still in  >   production operation.u > F > I had seveal 50 series as well.  Guess who provided their compilers?  : Well Pacer supplied the C compiler, and one other I think.   ------------------------------  $ Date: Thu, 5 Feb 2004 12:05:40 -0500= From: "Robert A. Matern" <ramatern@SEND.MEuninetsNO.SPAM.net> % Subject: Re: Why was VAX abandonned ?f3 Message-ID: <bvtt53$24k$1@ngspool-d02.news.aol.com>e  G And Prime's Multics heritage didn't hurt, either...   I miss Multics so?L much...   it makes most newer OSes look like garbage...   the last U.S. NavyJ Multics was shutdown in '96, the last Multics in the world bit the dust in, early 2000...    RIP, but live on forever...  ? Bob (Multician from CSC & NWGS - see http://www.multicians.org)   9 "Bill Gunshannon" <bill@gw5.cs.uofs.edu> wrote in messagew4 news:bvtof3$10t5c5$2@ID-135708.news.uni-berlin.de...; > In article <NDEMLKKEBOIFBMJLCECIAEHGCMAA.tom@kednos.com>, ' > "Tom Linden" <tom@kednos.com> writes:o > >.H > > I had seveal 50 series as well.  Guess who provided their compilers? > >o > > > Hmmmm......  University of Sheffield.(F77)  Garth Conboy.(C) > C > All the rest came directly from Pr1me and all my support contacts F > were directly with them so I assumed they did most of it themselves.+ > Boy do I miss working with SPL and PL1/g.h >a > bill >c > -- WL > Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesF > bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. > University of Scranton   |@ > Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  $ Date: Thu, 5 Feb 2004 06:58:25 -0700B From: "Tillman, Brian (AGRE)" <Brian.Tillman@smiths-aerospace.com> Subject: RE: ZIP/UNZIPO Message-ID: <11721EF39C7D7F47A55447158274CAF79A3D15@cossmgmbx01.email.corp.tld>e   David J. Dachtera wrote:    ? > Site appears to not be standards compliant (doesn't work withi > non-IE browsers)..  ! And even on IE produces an error:    Line: 15 Char: 1i Error: Syntax errorW Code: 0lA URL: http://forums1.itrc.hp.com/service/forums/questionanswer.do? ?      admit=3D716493758+1075989410200+28353475&threadid=3D418827n --=0Dn Brian Tillman        =0D Smiths Aerospace 3290 Patterson Ave. SE, MS 1B3 Grand Rapids, MI 49512-1991P> Brian.Tillman is the name, smiths-aerospace.com is the domain.	       =0Dt: I don't speak for Smiths, and Smiths doesn't speak for me.      * ******************************************G The information contained in, or attached to, this e-mail, may contain=,D  confidential information and is intended solely for the use of the=G  individual or entity to whom they are addressed and may be subject to=hH  legal privilege.  If you have received this e-mail in error you should=H  notify the sender immediately by reply e-mail, delete the message from=L  your system and notify your system manager.  Please do not copy it for any=F  purpose, or disclose its contents to any other person.  The views or=I  opinions presented in this e-mail are solely those of the author and do=tG  not necessarily represent those of the company.  The recipient should=oI  check this e-mail and any attachments for the presence of viruses.  The= A  company accepts no liability for any damage caused, directly or=w4  indirectly, by any virus transmitted in this email.* ******************************************   ------------------------------  # Date: Thu, 05 Feb 2004 15:45:52 GMTa9 From: Hein van den Heuvel <hein_netscape@eps.zko.dec.com>T Subject: Re: ZIP/UNZIP/ Message-ID: <40226520.BB15BC49@eps.zko.dec.com>s  H I like using Netscape whenever I can, but more and more I can not. Yuck.  g The ITRC support folks are constantly reminded on multiple browser support, notably to support Mozilla.c_ (Actually, not 'support it', but trying to avoid to offend it by trying to avoind IE specials.)a  q By and large the ITRC forums work, and so far have not been polutted with with the Mezei/Andrew/John Smith stuff.lb (No disrespect to the individuals intended, I'm just annoyed with the ongoing needling and worse.)   Hein.6   "Tillman, Brian (AGRE)" wrote:   > David J. Dachtera wrote: >oA > > Site appears to not be standards compliant (doesn't work withe > > non-IE browsers).o >r# > And even on IE produces an error:  > 
 > Line: 15	 > Char: 10 > Error: Syntax error-	 > Code: 0-C > URL: http://forums1.itrc.hp.com/service/forums/questionanswer.do?.= >      admit=716493758+1075989410200+28353475&threadid=418827d > -- >  > Brian TillmanC >o > Smiths Aerospace  > 3290 Patterson Ave. SE, MS 1B3 > Grand Rapids, MI 49512-1991F@ > Brian.Tillman is the name, smiths-aerospace.com is the domain. >n > < > I don't speak for Smiths, and Smiths doesn't speak for me. >h, > ****************************************** > The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions present9ed in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.e, > ******************************************   ------------------------------  % Date: Thu, 05 Feb 2004 09:41:51 +0300-: From: "Ruslan R. Laishev" <Laishev{at}DeltaTelecom{dot}RU>2 Subject: Re: [OT but useful] Kaspersky antivirus ?3 Message-ID: <B1E200D908EBE7E55A565C6D435EA420@nntp>H   Hi !   Didier Morandi wrote: K > I just heard of the Kaspersky Antivirus software (aka KAV). The info was >I > given to me by a MicroSoft Support Engineer (http://www.kaspersky.com/)l > K > Until now, I thought that the best AV ever for Windows was McAfee. Looks  / > like KAV is today the Rolls Royce of the AVs.  >  > What do you think? 	We use it, it's a nice thing.   > 	 > Thanks,c >  > D.   --   Cheers, Ruslan.hD +---------------------pure personal opinion------------------------+C   RADIUS Server for OpenVMS project - www.starlet.spb.ru/radiusvms/ @   TKD (WTF) in Russia, St.-Petersburg - www.TaeKwonDo-WTF.SPb.RU   ------------------------------  * Date: Thu, 5 Feb 2004 11:36:45 +0000 (UTC) From: david20@alpha2.mdx.ac.uk2 Subject: Re: [OT but useful] Kaspersky antivirus ?) Message-ID: <bvt9sd$ohk$1@news.mdx.ac.uk>   Y In article <402162c7$0$11328$636a55ce@news.free.fr>, Didier Morandi <no@spam.com> writes:>P >I just heard of the Kaspersky Antivirus software (aka KAV). The info was given B >to me by a MicroSoft Support Engineer (http://www.kaspersky.com/) > O >Until now, I thought that the best AV ever for Windows was McAfee. Looks like  ) >KAV is today the Rolls Royce of the AVs.n >w5 Does it run on anything other than Windows (or MAC) ?nM ie Can you run it on your VMS system to look at pathworks/samba served files,s incoming mail files etcc  N As to the BEST AV for Windows  I tend to think all the major vendor's products are pretty much the same.n  N Promotion of a particular anti-virus product for windows which doesn't run on + VMS is extremely off topic for comp.os.vms.r  < If you want to promote it promote it on a windows newsgroup.    
 David Webb VMS and Unix team leader CCSS Middlesex University   >What do you think?  >t >Thanks, >a >D.e >-- 3 >VAXUS - Your new helpful friend in the DEC Family! 3 >EHQ: 19 chemin de la Butte, 31400 Toulouse, Francen0 >      Phone: +336 7983 6418 Fax: +335 6154 1928% >                http://www.vaxus.orgt >T   ------------------------------  $ Date: Thu, 5 Feb 2004 06:48:28 -0700B From: "Tillman, Brian (AGRE)" <Brian.Tillman@smiths-aerospace.com>2 Subject: RE: [OT but useful] Kaspersky antivirus ?O Message-ID: <11721EF39C7D7F47A55447158274CAF79A3D0A@cossmgmbx01.email.corp.tld>w   Didier Morandi wrote:e  D > Until now, I thought that the best AV ever for Windows was McAfee.5 > Looks like KAV is today the Rolls Royce of the AVs.l  @ I think AVG from http://www.grisoft.com/ is the most widely-used@ freeware AV program and it has excellent performance in terms of5 catching everything and not falsely tagging anything.e --=0DX Brian Tillman        =0D Smiths Aerospace 3290 Patterson Ave. SE, MS 1B3 Grand Rapids, MI 49512-1991o> Brian.Tillman is the name, smiths-aerospace.com is the domain.	       =0Df: I don't speak for Smiths, and Smiths doesn't speak for me.      * ******************************************G The information contained in, or attached to, this e-mail, may contain= D  confidential information and is intended solely for the use of the=G  individual or entity to whom they are addressed and may be subject to=iH  legal privilege.  If you have received this e-mail in error you should=H  notify the sender immediately by reply e-mail, delete the message from=L  your system and notify your system manager.  Please do not copy it for any=F  purpose, or disclose its contents to any other person.  The views or=I  opinions presented in this e-mail are solely those of the author and do=rG  not necessarily represent those of the company.  The recipient should=aI  check this e-mail and any attachments for the presence of viruses.  The=aA  company accepts no liability for any damage caused, directly or= 4  indirectly, by any virus transmitted in this email.* ******************************************   ------------------------------   End of INFO-VAX 2004.071 ************************