1 INFO-VAX	Thu, 04 Apr 2002	Volume 2002 : Issue 185       Contents: Alert:(OTC BB:CMPT.OB)2 Re: Announcing a boot contest for OpenVMS on Intel2 Re: Announcing a boot contest for OpenVMS on Intel2 Re: Announcing a boot contest for OpenVMS on Intel2 Re: Announcing a boot contest for OpenVMS on Intel Re: Blade architectures  Re: Blade architectures  Re: Blade architectures  RE: Blade architectures  Re: Blade architectures  RE: Blade architectures  Re: Blade architectures  Re: Blade architectures  Re: British Summer Time  Compaq below $10.00 again  Re: Compaq below $10.00 again  RE: Compaq below $10.00 again  Re: Continuous forms printers  Re: Continuous forms printers  Re: Continuous forms printers  Re: DEC C and C++ compatibility  Re: DEC C and C++ compatibility - Re: DECTPU: Inconsistant language behaviour ?  Re: Disk Monitoring  Re: File IO query.( Re: FORTRAN (was: Re: R.I.P. OpenVMS...)8 Re: Fred Kleinsorge at work (formerly HP's viewpoint...) Re: HELP question  Re: IA64 is not the VAX  Re: IA64 is not the VAX  Re: IA64 is not the VAX  Re: IA64 is not the VAX  Re: IA64 is not the VAX  Re: IA64 is not the VAX D Re: Language support on Itanium VMS (was: Announcing a boot contest)D Re: Language support on Itanium VMS (was: Announcing a boot contest). MCSE, MCSA, CCNA, CCNP, Security and More! icv Re: Memory Channel vs. CI  Re: Memory Channel vs. CI  Re: Memory Channel vs. CI . Re: Newbie trying to get 2 Alpha boxes running* Re: Once a fool, always a fool I guess ...* Re: Once a fool, always a fool I guess ... OpenVMS VAX V7.3 Re: OpenVMS VAX V7.3 Re: OpenVMS VAX V7.3 Re: OpenVMS VAX V7.3 Re: OpenVMS VAX V7.3P Re: OT: Choosing from Lists (was: Re: Announcing a boot contest for OpenVMS on I= Re: Possible (mis)behavior of sys$manager:utc_time_setup.com? ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) RE: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) RE: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) RE: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it ) Re: Predictions - just for the hell of it > Re: Relative invulnerability of VMS to buffer-overflow attacks> RE: Relative invulnerability of VMS to buffer-overflow attacks> Re: Relative invulnerability of VMS to buffer-overflow attacks> Re: Relative invulnerability of VMS to buffer-overflow attacks> Re: Relative invulnerability of VMS to buffer-overflow attacks> Re: Relative invulnerability of VMS to buffer-overflow attacks> Re: Relative invulnerability of VMS to buffer-overflow attacks> Re: Relative invulnerability of VMS to buffer-overflow attacks+ Re: Seek information on FAXSR and VMS 7.3-1  Re: Selling: DS10L's NEW !!!4 Re: Spring Forward, Fall Back - unfortunately not :-- Re: TCPIP: no new default route when IP is ON - Re: TCPIP: no new default route when IP is ON - Re: TCPIP: no new default route when IP is ON 4 TCPIP: remove host from local table generates ACCVIOE RE: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E RE: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64 E Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64  re: The Digital 7-year plan... Re: The Digital 7-year plan... Re: The Digital 7-year plan...  The Latest Web Technologies jbmp Re: UCX Routing Table grows * VMS "unhackable" example just for Andy ...5 RE: VMS boottime - how to calculate # of days running 5 RE: VMS boottime - how to calculate # of days running 5 Re: VMS boottime - how to calculate # of days running 5 RE: VMS boottime - how to calculate # of days running 5 Re: VMS boottime - how to calculate # of days running 5 Re: VMS boottime - how to calculate # of days running 5 Re: VMS boottime - how to calculate # of days running 5 RE: VMS boottime - how to calculate # of days running 5 Re: VMS boottime - how to calculate # of days running % Re: VMS on 533au Ultimate Workstation % Re: VMS on 533au Ultimate Workstation % Re: VMS on 533au Ultimate Workstation % Re: VMS on 533au Ultimate Workstation   Re: VMS To Tru64 Migration Plans( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( RE: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...( Re: Why VMS is "unhackable" lesson 1 ...$ Why VMS is "unhackable" lesson 3 ...( RE: Why VMS is "unhackable" lesson 3 ...( Re: Why VMS is "unhackable" lesson 3 ...0 Re: [Q] How to set up flag pages on HP printers?0 Re: [Q] How to set up flag pages on HP printers?  F ----------------------------------------------------------------------   Date: 4 Apr 2002 02:04:32 -0000 * From: "Mag Net News" <MAG@lb.bcentral.com> Subject: Alert:(OTC BB:CMPT.OB) ( Message-ID: <1017885872.30799.qmail@ech>  & Computone Corporation (OTC BB:CMPT.OB)< ------------------------------------------------------------  + Computone Poised for Success in Fiscal 2003   J Computone Corporation (OTC BB:CMPT, www.computone.com) and its wholly own=J ed subsidiary Multi-User Solutions (www.multiuser.com) continue to see in=J creased interest in both its products and its custom service offerings.  =J  Computone=92s new 24 and 48 port high density products, are designed to =J provide serial connectivity and remote console management functions to th=J e high performance computing systems based upon various clustering techno=J logies. The design of these products coincides with the needs of these ma=J rkets for efficient use of space and high availability.  With our continu=J ed commitment to research and development, the company will deliver these=J  next generation products during the next quarter.  The design of the 24 =J and 48 port products is suitable to fit the needs of the cluster-based se=J rvers.  The many major companies who have expressed significant interest =J have verified the design.  The Computone products that have been produced=J  in the past and the 4 and 8 port density product lines that were introdu=J ced in June have also received renewed interest.  These products fill bot=J h the serial connectivity and remote console management needs of the dist=< ributed networks found in retail and hospitality industries.   =20   J Computone=92s wholly owned subsidiary, Multi-User Solutions (MUS), receiv=J ed increased interest by introducing its customized services offering to =J new market segments. MUS has created a unique market niche over the last =J nine years in the market segment for solutions that employ Intel based te=J chnology in servers.  MUS is currently expanding its target markets into =J arenas including support for storage solution providers and the system bu=J ilders as well as expanding the support offerings to servers employing ot=J her technology including Sun=AE Solaris 8=AE and IBM=AE AIX=AE. .  These =J new market areas increase both the size of the opportunities and the numb=J er of potential opportunities. In pursuit of the support for the storage =J based solutions, MUS has added both experienced staff as well as embarked=J  on a certification program. The certification program has already produc=@ ed certification for Cisco=AE, Solaris, and IBM=AE/Mylex=AE. =20   =20   J Computone Corporation and Multi-User Solutions look forward to an excitin=J g year with several major opportunities based on rising number of recent =J business inquiries.  The current market conditions make the company perfe=J ctly suited for growth.  As the recovery from a sluggish economy continue=J s, Computone Corporation is extremely excited about the potential that ca=( n make for a successful Fiscal 2003. =20   About Computone Corporation   J Computone (OTC BB: CMPT, www.computone.com) has been a leader in the IT i=J ndustry since 1984. Today, Computone designs, manufactures and markets a =J line of intelligent servers for secure remote network management, secure =J E-commerce, and remote access communications for Internet, Sun=AE (SUNW),=J  Linux=AE, Hewlett-Packard=AE (HWP), Microsoft=AE Windows=AE NT (MSFT) an=J d Novell=AE (NOVL). Multi-User Solutions (www.multiuser.com), a subsidiar=J y of Computone provides nationwide on-site hardware maintenance, operatin=J g system support, systems integration, and logistics management to custom= ers in North America.   J This press release contains certain forward-looking statements within the=J  meaning of section 27A of the Securities Act of 1933 and Section 21E of =J the Securities Exchange Act of 1934. With the exception of historical inf=J ormation contained herein, the matters discussed in this press release in=J volve risk and uncertainties. Actual results could differ materially from=5  those expressed in any forward-looking statement.=20   8 All trademarks are properties of their respective owners    < ------------------------------------------------------------
 Disclaimer  J MAG publishes reports providing informationon selected companies that MAG= =20 J believes has investment potential. MAG is not a registered investment adv=
 isor or=20J broker-dealer. This reportis provided as an information service only, and=  the=20 J statements and opinionsin this report should not be construed as an offer=  or=20J solicitation tobuy or sell any security. MAG accepts no liability for any=  loss=20J arisingfrom an investor's reliance on or use of this report. An investmen=
 t inThe=20J Above named company is considered to be highly speculative and shouldnot = be=20 J considered unless a person can afford a complete loss of investment.MAG h=
 as been=20H hired by a third party consultant, and is contracted toreceive a cash=20J advertising fee of $500-$5000 for the publication andcirculation of this =
 report.=20J Subsequently MAG may buy or sell shares ofthe stock of the above mentione= d=20J company in the open market. This reportcontains forward-looking statement= s,=20 J which involve risks, and uncertaintiesthat may cause actual results to di= ffer=20 J materially from those set forthin the forward-looking statements. For fur= ther=20 J details concerning theserisks and uncertainties, see the SEC filings of t= he=20 J above mentioned companyincluding the company's most recent annual and qua=	 rterly=20  reports.    G _______________________________________________________________________  Powered by List Builder  To unsubscribe follow the link: J http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=3D11414&subid= =3D1746D89F74C7F1A3&msgnum=3D25    ------------------------------  # Date: Thu, 04 Apr 2002 02:04:37 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"); Subject: Re: Announcing a boot contest for OpenVMS on Intel 8 Message-ID: <00A0BEC2.7B57F9A7@SSRL04.SLAC.STANFORD.EDU>  c In article <U4JGrWg4h$Sc@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: b >In article <3CAAE16E.3C9D42B5@BlueBubble.UK.Com>, Roy Omond <Roy.Omond@BlueBubble.UK.Com> writes: >> Patrick Young wrote:  >>  M >>> Many thanks - this looks interesting! I have one gripe BTW, and it is one ' >>> I have with *many* US web sites....  >>> = >>> State: <drop down menu with US/Canada states listed only> O >>> Country <drop down menu with US/Canada as well as _other_ countries listed>  >>>  >>> State *not* being optional.  >>> L >>> Well, I guess I live in Sydney which is located in California which is aK >>> state of Australia. Who am I to argue - people who design web templates  >>> know best :-)  >>   >> One of my pet peeves too. > B >From the US, my pet web-form-state peeve is the requirement to goG >down a long popup list of states to choose the two-letter abbreviation  >for the state in which I live.  > C >I am actually so intellectually advanced that I can _remember_ the E >two letter abbreviation fo the state where I have lived for the past 
 >40 years :-)   I Have you tried typing the first letter of the two-letter abbreviation for N the state while the cursor is in that popup list?  Many browsers will position3 the cursor to the first entry matching that letter.   J (Of course, if reflex kicks in and you type the second letter, you'll thenK be positioned to the first entry beginning with the second letter, which is  not much help.)    -- Alan     O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================    ------------------------------  % Date: Wed, 03 Apr 2002 21:30:28 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> ; Subject: Re: Announcing a boot contest for OpenVMS on Intel , Message-ID: <3CABBAB8.706607F4@videotron.ca>  * Alan Winston - SSRL Admin Cmptg Mgr wrote:K > Have you tried typing the first letter of the two-letter abbreviation for P > the state while the cursor is in that popup list?  Many browsers will position5 > the cursor to the first entry matching that letter.   J Netscape on Macintosh does not have that behaviour. That is what very long lists can be annoying on a mac.   L Note that drop down lists in HTML have no particular ordering. So having theI behavious of pressing a letter to find the first item beginning with that ( letter may not yield the desired result.  L If Monaco is listed first, and Montral listed last, pressing "M" would giveN me the first entry, and I would still have to manually scroll down to the end.   ------------------------------   Date: 3 Apr 2002 20:54:52 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen) ; Subject: Re: Announcing a boot contest for OpenVMS on Intel 3 Message-ID: <V9Y4$5dCtQWJ@eisner.encompasserve.org>    In article <00A0BEC2.7B57F9A7@SSRL04.SLAC.STANFORD.EDU>, winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") writes: e > In article <U4JGrWg4h$Sc@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:   C >>From the US, my pet web-form-state peeve is the requirement to go H >>down a long popup list of states to choose the two-letter abbreviation  >>for the state in which I live. >>D >>I am actually so intellectually advanced that I can _remember_ theF >>two letter abbreviation fo the state where I have lived for the past >>40 years :-) > K > Have you tried typing the first letter of the two-letter abbreviation for P > the state while the cursor is in that popup list?  Many browsers will position5 > the cursor to the first entry matching that letter.   E Please see my rebuttal, elsewhere in this thread, to someone else who = made that claim.  Hint: try that after securing your browser.8   ------------------------------  # Date: Thu, 04 Apr 2002 02:57:38 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"); Subject: Re: Announcing a boot contest for OpenVMS on Intelg8 Message-ID: <00A0BEC9.E334CE9A@SSRL04.SLAC.STANFORD.EDU>  \ In article <3CABBAB8.706607F4@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:+ >Alan Winston - SSRL Admin Cmptg Mgr wrote:lL >> Have you tried typing the first letter of the two-letter abbreviation forQ >> the state while the cursor is in that popup list?  Many browsers will position 6 >> the cursor to the first entry matching that letter. >tK >Netscape on Macintosh does not have that behaviour. That is what very longE  >lists can be annoying on a mac.  I True, although IE (to which I'm morally opposed, but which seems to work u+ better on my Powerbook) does work that way.) >eM >Note that drop down lists in HTML have no particular ordering. So having the J >behavious of pressing a letter to find the first item beginning with that) >letter may not yield the desired result.   I They have the ordering that the originator put them in.  Some people put oD their state lists in order by population; most just go alphabetical. >iM >If Monaco is listed first, and Montral listed last, pressing "M" would giveCO >me the first entry, and I would still have to manually scroll down to the end.e  G True.  But that abusively bad order is the  fault of whoever wrote the s6 <Select> statement, not of HTML or a specific browser.   -- Alan   O ===============================================================================70  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056tM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================c   ------------------------------   Date: 3 Apr 2002 12:54:47 -0800 ( From: bob@instantwhip.com (Bob Ceculski)  Subject: Re: Blade architectures= Message-ID: <d7791aa1.0204031254.534f2833@posting.google.com>    Andrew Harrison SUNUK Consultancy <andrew_nospam.remove_this.harrison@sun.com> wrote in message news:<3CA1FC84.7020901@sun.com>...  6 > Anyone who thinks the Linux on a mainframe is a good: > idea must have deep pockets and little or no shareholder > scrutiny.e > 	 > Regards  > Andrew Harrisonf  A gentlemen, the only system available to run efficently, securely,u< and give you 99.9999% uptime w/its superior clustering is an= Alpha VMS system ... there are no others ... discussion over!n   ------------------------------  % Date: Wed, 03 Apr 2002 17:30:39 -0500e1 From: Michael Austin <maustin@firstdbasource.com>c  Subject: Re: Blade architectures2 Message-ID: <3CAB828F.1A3DD424@firstdbasource.com>   Bob Ceculski wrote:h >  > Andrew Harrison SUNUK Consultancy <andrew_nospam.remove_this.harrison@sun.com> wrote in message news:<3CA1FC84.7020901@sun.com>... > 8 > > Anyone who thinks the Linux on a mainframe is a good< > > idea must have deep pockets and little or no shareholder
 > > scrutiny.r > >a > > Regardse > > Andrew Harrisony > C > gentlemen, the only system available to run efficently, securely,o> > and give you 99.9999% uptime w/its superior clustering is an? > Alpha VMS system ... there are no others ... discussion over!b  F I had a person who said they had not had any "unscheduled" downtime on> their NT boxes.  the scheduled downtime was another discussion; altogether, including when it got scheduled for reboot.  :)o  C Oh, Andrew... what was all of the stuff in the recent past (Aug-SepCF timeframe) that said that if your CPU clock tick rate was one thing orG another, that if you didn't reboot your Solaris box, would corrupt yourED database?  Reboot, reboot,reboot. The mantra of most Unix and NT sys	 admins...i   -- e Regards,  7 Michael Austin            Registered Linux User #261163-7 First DBA Source, Inc.    http://www.firstdbasource.com  Sr. Consultant 704-947-1089 (Office)2 704-236-4377 (Mobile)6   ------------------------------   Date: 3 Apr 2002 23:45:29 GMT   From: hack@watson.ibm.com (hack)  Subject: Re: Blade architectures+ Message-ID: <a8g46p$lcc$1@news.btv.ibm.com>m  = In article <d7791aa1.0204031254.534f2833@posting.google.com>, ) Bob Ceculski <bob@instantwhip.com> wrote:  >Andrew Harrison SUNUK Consultancy <andrew_nospam.remove_this.harrison@sun.com> wrote in message news:<3CA1FC84.7020901@sun.com>...t >A7 >> Anyone who thinks the Linux on a mainframe is a goode; >> idea must have deep pockets and little or no shareholderc >> scrutiny. >>  
 >> Regards >> Andrew Harrison >cB >gentlemen, the only system available to run efficently, securely,= >and give you 99.9999% uptime w/its superior clustering is and> >Alpha VMS system ... there are no others ... discussion over!  @ Congratulations!  There aren't many six-nines systems out there.C (OS/390 Sysplex is another one, also thanks to clustering.  WithouthI clustering I believe five nines is the best I've heard, also for OS/390.)f9 How many nines can an NT cluster claim?  A single NT box?y   Michel.    ------------------------------  $ Date: Wed, 3 Apr 2002 19:41:58 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>t  Subject: RE: Blade architecturesT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1E20@kaoexc01.americas.cpqcorp.net>   Michel,e  # Re: multiple 9's of availability ..   H Well, my $.02 is that these numbers have become marketing things that doH not deal with what Customers require in todays world. The reason is thatH all vendors (including Compaq) do not count scheduled system downtime in their numbers.  E This is a throwback to the era whereby mainframe vendors were able toaB convince Customers that it was ok for weekly/monthly shutdowns forE scheduled maintenance and that these numbers should not count againstn$ them for their availability numbers.  E How else could a system (mainframe) that goes down weekly/monthly forbB scheduled maintenance be held as a standard for high availability?  F With large IT Consolidation projects, B2B with many partners, InternetH trading etc, this practice is rapidly becoming unacceptable to Customers& with mission critical applications.=20  H Imho, a critical decision criteria in the future is going to be "tell meB what your availability numbers are - and include downtimes for any> scheduled system maintenance. Given that every system requiresB occasional maintenance or HW (cpu/memory/IO) upgrades to deal withA changing business loads, tell me how you plan to deliver 5 9's ofs application availability..."   Regards,  
 Kerry Main Senior Consultanto Compaq Canada Corp.t Professional Servicesn Voice: 613-592-4660s Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----* From: hack [mailto:hack@watson.ibm.com]=20 Sent: April 3, 2002 6:45 PMc To: Info-VAX@Mvb.Saic.Com   Subject: Re: Blade architectures    = In article <d7791aa1.0204031254.534f2833@posting.google.com>,=) Bob Ceculski <bob@instantwhip.com> wrote: % >Andrew Harrison SUNUK Consultancy=20mA ><andrew_nospam.remove_this.harrison@sun.com> wrote in message=20=# >news:<3CA1FC84.7020901@sun.com>...e >x7 >> Anyone who thinks the Linux on a mainframe is a goodiE >> idea must have deep pockets and little or no shareholder scrutiny.m >>=20m
 >> Regards >> Andrew Harrison >nI >gentlemen, the only system available to run efficently, securely, and=20eF >give you 99.9999% uptime w/its superior clustering is an Alpha VMS=204 >system ... there are no others ... discussion over!  H Congratulations!  There aren't many six-nines systems out there. (OS/390H Sysplex is another one, also thanks to clustering.  Without clustering IE believe five nines is the best I've heard, also for OS/390.) How manyi0 nines can an NT cluster claim?  A single NT box?   Michel.s   ------------------------------  % Date: Wed, 03 Apr 2002 20:45:33 -0500.- From: JF Mezei <jfmezei.spamnot@videotron.ca>   Subject: Re: Blade architectures+ Message-ID: <3CABB035.920E439@videotron.ca>t   "Main, Kerry" wrote:G > This is a throwback to the era whereby mainframe vendors were able tosD > convince Customers that it was ok for weekly/monthly shutdowns forG > scheduled maintenance and that these numbers should not count againsto$ > them for their availability number  7 And many banking applications required daily shutdowns.t  M Couple of years ago, when I was in Australia, I was surprised to see that onesN of the larger (and most conservative) banks still had scheduled daily shutdownJ for their ATMs. I later met an employee of another bank who confirmed thatC this big "old" bank had very old IT systems. (IBM shop, of course).r  H > With large IT Consolidation projects, B2B with many partners, InternetJ > trading etc, this practice is rapidly becoming unacceptable to Customers% > with mission critical applications.   J But taken to the extreme, consolidation does have drawbacks. If you have aM single cluster with a gazillion applications each with their OS requirements,mL it becomes harder to manage that beast and its applications (especially when the time comes to upgrade).=  N If you manage an application that has its own proprietary drivers or ACPs,  itG becomes much harder to share the system with other applications becausegK drivers or ACPs can require a reboot when they go nuts (or if use of a tapetI drive makes something go RWAST.). Another issue is data security from thesN user's point of view. If the application has very strong data value (such as aL SWIFT application), then the user may not tolerate that the server is shared with other applications.   ------------------------------  $ Date: Wed, 3 Apr 2002 23:16:11 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>l  Subject: RE: Blade architecturesT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1E25@kaoexc01.americas.cpqcorp.net>   JF,   E Consolidation is not for every Customer or for every case. As always,1) one needs to balance a number of factors..  H Good example which often catches some Customers with their pants down isG system time ie. users in one time zone accessing systems in a differentu" time zone. Potentially huge issue.  ; Re: putting applications on different servers / clusters ..   G In general, when one consolidates, you also have to start thinking like-? a mainframe type person and that means looking at resource mgmt B capabilities like class schedulers (VMS V7.3) which will limit the= amount of resources a specific process/processes can consume.t  E On the reboot issue, as long as one can move users around the clusters; without the users knowing it or impacting their applicationoD availability, then proactively rebooting servers is not really a big issue.  H On the security side, you are right that for some applications, businessD requirements with respect to security can (and should) over-ride all technical arguments.   Regardsp  
 Kerry Main Senior Consultante Compaq Canada Corp.t Professional Servicesu Voice: 613-592-4660f Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20e Sent: April 3, 2002 8:46 PMc To: Info-VAX@Mvb.Saic.Coms  Subject: Re: Blade architectures     "Main, Kerry" wrote:J > This is a throwback to the era whereby mainframe vendors were able to=20G > convince Customers that it was ok for weekly/monthly shutdowns for=20cJ > scheduled maintenance and that these numbers should not count against=20$ > them for their availability number  7 And many banking applications required daily shutdowns.   D Couple of years ago, when I was in Australia, I was surprised to seeH that one of the larger (and most conservative) banks still had scheduledF daily shutdown for their ATMs. I later met an employee of another bankD who confirmed that this big "old" bank had very old IT systems. (IBM shop, of course).l  H > With large IT Consolidation projects, B2B with many partners, Internet  C > trading etc, this practice is rapidly becoming unacceptable to=200/ > Customers with mission critical applications.D  H But taken to the extreme, consolidation does have drawbacks. If you haveA a single cluster with a gazillion applications each with their OS0< requirements, it becomes harder to manage that beast and its9 applications (especially when the time comes to upgrade).s  D If you manage an application that has its own proprietary drivers or< ACPs,  it becomes much harder to share the system with otherF applications because drivers or ACPs can require a reboot when they goC nuts (or if use of a tape drive makes something go RWAST.). Another<H issue is data security from the user's point of view. If the applicationG has very strong data value (such as a SWIFT application), then the usertC may not tolerate that the server is shared with other applications.i   ------------------------------  % Date: Wed, 03 Apr 2002 23:45:46 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>n  Subject: Re: Blade architectures, Message-ID: <3CABDA69.D6F1F86C@videotron.ca>   "Main, Kerry" wrote:G > On the reboot issue, as long as one can move users around the clustert= > without the users knowing it or impacting their applicationcF > availability, then proactively rebooting servers is not really a big > issue.  N Moving processes to another node isn't always possible or easy. It works greatF if all your applications are server-type that can exists with multiple? instances on multiple nodes. Such isn't always the case though.i  " I would like to see the following: 	-unloading of any driver Q 	-ability to safely stop any process in any state, including the nasty RWAST etc.e  L This would go a long way towards allowing multiple applications to co-exist,K allowing a corrupt application to be completely reset without affecting the= other, or requiring a reboot.i  L When I re-read the "VAXORCIST" on April 1, I was reminded that back in thoseP days, reboots weren't such a rare occurance. How things have changed since then.   ------------------------------  $ Date: Wed, 3 Apr 2002 21:57:33 -0800" From: Erik Magnuson <erik@cts.com>  Subject: Re: Blade architectures; Message-ID: <Pine.SOL.4.43.0204032142230.17699-100000@erik>F   On 3 Apr 2002, hack wrote:  > >In article <d7791aa1.0204031254.534f2833@posting.google.com>,* >Bob Ceculski <bob@instantwhip.com> wrote: >>Andrew Harrison SUNUK Consultancy <andrew_nospam.remove_this.harrison@sun.com> wrote in message news:<3CA1FC84.7020901@sun.com>... >>8 >>> Anyone who thinks the Linux on a mainframe is a good< >>> idea must have deep pockets and little or no shareholder
 >>> scrutiny.e >>>e >>> Regards  >>> Andrew Harrisonh >>C >>gentlemen, the only system available to run efficently, securely,t> >>and give you 99.9999% uptime w/its superior clustering is an? >>Alpha VMS system ... there are no others ... discussion over!i >nA >Congratulations!  There aren't many six-nines systems out there. D >(OS/390 Sysplex is another one, also thanks to clustering.  WithoutJ >clustering I believe five nines is the best I've heard, also for OS/390.): >How many nines can an NT cluster claim?  A single NT box? >  >Michel. > A Hmm. Somewhere around 5 to 6 nines you really have to pay as much J attention to facilities and infrastructure as you do the computer/OS. This@ includes things like buildings resistant to natural and man madeD disasters, power supplies and communications links designed to avoidG single points of failure (e.g. Jim-Bob backhoe operator cutting throughi your fiber optic lines).  F I don't see Microsoft's positioning of NT as not requiring "expensive"= suport staff as being conducive to getting five-nines uptime.e  
 Erik Magnusonb   ------------------------------   Date: 3 Apr 2002 16:15:11 -0800i- From: tony_mcgrath@toll.com.au (Tony McGrath)e  Subject: Re: British Summer Time= Message-ID: <ba84734f.0204031615.611268e6@posting.google.com>a  ~ "Chris Sharman" <chris.sharman@ccagroup.co.uk> wrote in message news:<1017823930.25390.0.nnrp-12.9e989e7e@news.demon.co.uk>...; > OpenVMS Alpha 7.3, TCPIP (ucx) 5.1 eco 3, iupop3, mx 5.0.cF > I dialled in to set Summer Time on Monday night (I thought it did it% > automatically, but apparently not).  > M > Now everything (VMS, PCs) shows the right time, but email's arriving on PCsa$ > timestamped an hour in the future. > : > Here's all the logicals I can see ($ sh log *tim*,*tz*).+ > Anyone know what I've done wrong please ?n > 	 > Thanks,S > Chris Sharmang > " >   "IUPOP3_CLIENT_TIMEOUT" = "10"8 >   "PWRK$PCFS_STARTUP_TIME" = "23-FEB-2002 17:57:35.63"7 >   "PWRK$PCI_STARTUP_TIME" = "23-FEB-2002 17:57:35.63"i= >   "PWRK$STREAMSOS_STARTUP_TIME" = "23-FEB-2002 17:57:36.50"t- >   "SYS$DST_DELTA_TIME" = "ffff2726a756d909"fA >   "SYS$LOCALTIME" = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]GB-EIRE."s( >   "SYS$TIMEZONE_DAYLIGHT_SAVING" = "0"% >   "SYS$TIMEZONE_DIFFERENTIAL" = "0"N >   "SYS$TIMEZONE_NAME" = "GMT"e: >   "SYS$TIMEZONE_RULE" = "GMT0BST-1,M3.5.0/01,M10.4.0/02"3 >   "SYS$TZDIR" = "SYS$SYSROOT:[SYS$ZONEINFO.USER]"a/ >         = "SYS$SYSROOT:[SYS$ZONEINFO.SYSTEM]" ! >   "TCPIP$BIND_TIMEOUT" = "...."     	 Hi Chris,dC I had the same problem here in Oz, having just finished with Summerb Time.s: Mail from VMS to the PC showed up as one hour in the past.C I checked the headers of the mail message and saw that PMDF had note' been told about the change in timezone.m
 I had to..( $ DEFINE /SYS/EXEC PMDF_TIMEZONE "+1000"  . Maybe you have to do something similar with MX  F As for the automatic time change on VMS, check out the AUTO_DLIGHT_SAV parameter in SYSGEN.   Cheers from Oz,n    Tonyo ---w Tony McGrathE OpenVMS Support, Toll Transport, Laverton North, VIC, Australia, 3026t   ------------------------------  % Date: Wed, 03 Apr 2002 16:11:21 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>=" Subject: Compaq below $10.00 again, Message-ID: <3CAB6FDD.3A30CE57@videotron.ca>   Closed at 9.77 today.l  L Has the firm who counts HP's votes given any indication of when it will haveI the results ready ? I find it unusual that for such a high tech form, its=( votes would still take so long to count.  I Does HP have any power to delay the publication of the official results ?4   ------------------------------   Date: 3 Apr 2002 15:48:01 -0600a+ From: young_r@encompasserve.org (Rob Young)3& Subject: Re: Compaq below $10.00 again3 Message-ID: <UpMCBBlsM7ZH@eisner.encompasserve.org>_  \ In article <3CAB6FDD.3A30CE57@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Closed at 9.77 today.e > N > Has the firm who counts HP's votes given any indication of when it will haveK > the results ready ? I find it unusual that for such a high tech form, itst* > votes would still take so long to count. >   ? 	Hand count... just like they do in Canada.  Thankfully, we usee? 	machines for general elections here in the USA.  And further --D 	even with dangling chads - the outcome comes out excellent!  Can ya 	believe it?  K > Does HP have any power to delay the publication of the official results ?4  C 	Maybe.  Wasn't there an X-Files episode that played on that theme,U1 	or am I remembering a Weekly World News article?@   				Robo   ------------------------------  $ Date: Wed, 3 Apr 2002 17:06:56 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>a& Subject: RE: Compaq below $10.00 againT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4016CED15@kaoexc01.americas.cpqcorp.net>   Rob,  2 >>> Hand count... just like they do in Canada. <<<  C Yep - nowhere to plug in them new fangled systems in our igloo's ..M  2 Hey, but we do know how to fool them American's ..5 http://news.com.com/2100-1001-874686.html?tag=3Dcd_mhe% "Gates duped by Canadian radio hosts"e   :-) :-)d   Regards   
 Kerry Main Senior Consultantn Compaq Canada Corp.c Professional Serviceso Voice: 613-592-4660t Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----5 From: Rob Young [mailto:young_r@encompasserve.org]=20f Sent: April 3, 2002 4:48 PMi To: Info-VAX@Mvb.Saic.Com & Subject: Re: Compaq below $10.00 again    5 In article <3CAB6FDD.3A30CE57@videotron.ca>, JF Mezei & <jfmezei.spamnot@videotron.ca> writes: > Closed at 9.77 today.  >=20G > Has the firm who counts HP's votes given any indication of when it=209I > will have the results ready ? I find it unusual that for such a high=20e9 > tech form, its votes would still take so long to count.) >=20  ? 	Hand count... just like they do in Canada.  Thankfully, we usem? 	machines for general elections here in the USA.  And further -.A 	even with dangling chads - the outcome comes out excellent!  Cann ya 	believe it?  D > Does HP have any power to delay the publication of the official=20 > results ?@  < 	Maybe.  Wasn't there an X-Files episode that played on that theme,1 	or am I remembering a Weekly World News article?    				Robc   ------------------------------  $ Date: Wed, 3 Apr 2002 23:06:22 -05000 From: "Jeff Morgan" <vmswiz@geonospamcities.com>& Subject: Re: Continuous forms printers+ Message-ID: <a8gjpa$nr$1@news3.infoave.net>.  J Get a serial to parallel converter and use any new continuous form printerI that you want. We haven't done this for a few years, but it always workedkI fine. Parallel to serial converters aren't too hard too locate. Black Boxe; probably still has them. We used to pay about $60 for them.c  K OKIdata used to offer optional serial interfaces on all their printers. You J might want to check their website for available options on that particular model.  0                                             *JM*    : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CA25322.8BCCD99B@videotron.ca...H > Does anyone know if Compaq still has a refurbished products service in canada ? >oI > A friend needs a low end printer to generate reports on continuous form  paper K > (tractor feed) from a serial port. A brief look at on-line stores reveals  that. > most printers are now USB with some paralel. >sI > Any suggestions on where I might look for something not expensive ? Hisw vendorK > quoted him something like cad $400 for an okidata printer. (that is aboutf $250K > US). He needs to print stuff such as his store's inventory, so fanfold isn muchE > mroe convenient to consult/search than  separate letter size paper.a   ------------------------------  % Date: Wed, 03 Apr 2002 23:25:47 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> & Subject: Re: Continuous forms printers, Message-ID: <3CABD5BC.DEE7C8D3@videotron.ca>   Jeff Morgan wrote: > L > Get a serial to parallel converter and use any new continuous form printer > that you want.  1 Some printers now are starting to be USB only !!!e  K I tried to look at the HP printer site, but couldn't see any obvious inkjetdI printers capable of handling continuious forms. Does anyone know if HP orsB others make inexpensive inkjets that can handle continuous forms ?  2 Or is dot matrix really the only option possible ?  M > OKIdata used to offer optional serial interfaces on all their printers. You-L > might want to check their website for available options on that particular > model.  M That is what my friend was told. but they cost 4 times as much as the low enda inkjet printers.   ------------------------------  % Date: Thu, 04 Apr 2002 07:49:57 +0200> From: Dirk Munk <munk@home.nl>& Subject: Re: Continuous forms printers& Message-ID: <3CABE985.8070106@home.nl>   JF Mezei wrote:8   >Jeff Morgan wrote:  > L >>Get a serial to parallel converter and use any new continuous form printer >>that you want. >> >n2 >Some printers now are starting to be USB only !!! > L >I tried to look at the HP printer site, but couldn't see any obvious inkjetJ >printers capable of handling continuious forms. Does anyone know if HP orC >others make inexpensive inkjets that can handle continuous forms ?a >a3 >Or is dot matrix really the only option possible ?. >SM >>OKIdata used to offer optional serial interfaces on all their printers. You L >>might want to check their website for available options on that particular >>model. >> > N >That is what my friend was told. but they cost 4 times as much as the low end >inkjet printers.: >3  I Maybe, but have you considered the running costs ? Inkjet cartridges are aE very expensive and don't last long. HP is generating its profit form rD inkjet cartridges these days. Furthermore this ink isn't waterproof.   >    ------------------------------  % Date: Wed, 03 Apr 2002 15:16:17 -0500f. From: Boris Gubenko <Boris.Gubenko@compaq.com>( Subject: Re: DEC C and C++ compatibility* Message-ID: <3CAB6311.23FCBB4B@compaq.com>  , This is a multi-part message in MIME format.& --------------60FAD89D4D9DD5D85988F098* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bitk  C DEC C V6.0 for OpenVMS VAX has been released in November 1998 whilepF Compaq C++ V5.6C for OpenVMS VAX has been released about a year later,@ in October, 1999. I have not compared header files myself, but IC think, that in your case, the C++ kit provided more recent C header ' files than those provided by the C kit.   A For Compaq C++ for Alpha, the kitinstal procedure was enhanced totA check dates and make sure, that more recent C header files on thee? system are not overwritten. The kitinstal procedure for old VAXm kit has not been modified.   Boris Gubenko, Compaq C++ team.i     JF Mezei wrote:    > OK, did my homework: > 
 > VAX VMS 7.2  >a > DEC C 6.0 (from hobbyist CD)  > C++ 5.6C (from DEC's ftp site) > 
 > The actors:s >e+ > [1] DEC C's  SYS$LIBRARY:DECC$RTLDEF.TLB" = > [2] DEC C's  SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]*.hs* > [3] C++.s    SYS$LIBRARY:DECC$RTLDEF.TLB >  > [1] has 75 modules > [3] has 404 modulesrO > [2] has 404 files  (75 of which had 2 versions, total 479 files in directory)  >lP > Interestingly, there were differences found between DEC-C's [1] and C++'s [3],  > notably the following modules: >         BUILTINSL >                         PAL_PROBER uses "offset" as middle argument in C++N >                         PAL_PROBER uses "length" as middle argument in DEC C@ >                         _popcnt, _poppar, _leadz, _trailz are:8 >                                         __int64 in C++C >                                         unsigned __int64 in DEC-Cc >h >         CTYPE ? >                         _ctypet (*decc$$ga___ctypet) in DEC-Ca< >                         _ctypet (decc$$ga___ctypet) in C++ >u >                 but later on: I >                         extern const unsigned int __ctypet []; in DEC-Ca` >                         extern const unsigned int *__ctypet ; in C++ (comments added above it) >a >         IF_TRNSTAT\ >                 59 differences. Mostlty stuff such as u_char in DEC-C and __u_char in C++. >c
 >         IN6t! >                 u_int for DEC-C ! >                 __u_int for C++h >         NAMSER) >                 u_char, u_long in DEC-Ci+ >                 __u_char, __u_long in C++i  >                 34 differences >sI > NOTE: in none of those files where there are differences, are there anynP > comments to indicate which is more recent. (no differences found in comments). >eL > NOTE: of the 75 files which have 2 versions in the [2] directory, the sameJ > differences exist between the ;1 and ;2 version, with the second version( > matching what the C++ .TLB  installed. > N > NOTE: the second version in that directory seems to have been created by theP > C++ installation, even though the C++ installation makes no mention that files- > would have been modified in that directory.y >iO > I will have to do some additional work to figure out which of these files aren > more recent. >2G > The C++ 5.6C VMSINSTAL procedure is most certaintly flawed and poorlysN > documented. it should warn that it is about to squash files that may be moreG > recent. Do not specify the "purge files installed" if you install it.         & --------------60FAD89D4D9DD5D85988F098- Content-Type: text/x-vcard; charset=us-ascii;   name="Boris.Gubenko.vcf"M Content-Transfer-Encoding: 7bitt+ Content-Description: Card for Boris Gubenkoa  Content-Disposition: attachment;  filename="Boris.Gubenko.vcf"r   begin:vcard  n:Gubenko;Boris  tel;fax:603.884.0153 tel;work:603.884.1675, x-mozilla-html:FALSE5 org:Compaq Computer Corporation;Core Technology Groupi? adr:;;110 Spit Brook Road (ZKO2-3/N65);Nashua;NH;03062-2698;USAt version:2.1 ' email;internet:Boris.Gubenko@compaq.comw& title:Senior Member of Technical Staff x-mozilla-cpt:;-22800  fn:Boris Gubenko	 end:vcardh  ( --------------60FAD89D4D9DD5D85988F098--   ------------------------------  % Date: Wed, 03 Apr 2002 15:56:35 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca> ( Subject: Re: DEC C and C++ compatibility, Message-ID: <3CAB6C69.5022E988@videotron.ca>   Boris Gubenko wrote: > E > DEC C V6.0 for OpenVMS VAX has been released in November 1998 whilesH > Compaq C++ V5.6C for OpenVMS VAX has been released about a year later,B > in October, 1999. I have not compared header files myself, but IE > think, that in your case, the C++ kit provided more recent C headeri) > files than those provided by the C kit.   N Thanks. Since the C++ install procedure on VAX was flawed/untrustable, I choseJ to stay with the DECC header files. But you are right, the C++ compiler is more recent than the DEC-C one.t   ------------------------------   Date: 3 Apr 2002 16:49:44 -0600 - From: koehler@encompasserve.org (Bob Koehler) 6 Subject: Re: DECTPU: Inconsistant language behaviour ?3 Message-ID: <VeTgRs+Wgbsq@eisner.encompasserve.org>e  } In article <f9FSQc7ZjgJb@eisner.encompasserve.org>, simon_clubley@remove_me.altavista.co.uk-Earth.UFP (Simon Clubley) writes: F > In DECTPU, can you refer to a CONSTANT definition before it actually* > appears in the source file ? An example: >  > procedure test11(in) >  > !	test_num := 5;
 > 	case in > 		[3]:	message("opt 3");! > 		[test_num]:	message("opt 5");  > 	endcase;r > endprocedure;p >  > constant test_num := 5;l > 
 > 	test11(5);p > 	quit; > B > [In order to understand what follows, you need to be aware that:K > (a) If something appears on the left hand side of an assignment before itnM > is defined, then that something is defined implicitly as a global variable.nI > (b) In an assignment statement, you can assign something to a constant,3C > provided that it's the value that the constant was defined with.]e >  > If you execute:n > 5 > 	$ edit/tpu/nosection/nodisplay/command=example.tpu0 >  > then this runs correctly.7 > K > However, if you uncomment the "test_num := 5" statement, then compilationm
 > fails with:r > N > %TPU-E-CONTRADEF, contradictory definition for variable or constant TEST_NUM& > -TPU-I-SOURCELINE, at source line 10) > %TPU-W-COMPILEFAIL, compilation aborteda  C TPU appears to use a multi pass compiler.  Forward references nevers seemed to be a problem.e  P > as if test_num had been implicitly defined as a variable during the assignmentJ > statement and then an attempt had been made to redefine it as a constantM > when the constant statement was reached. It's also interesting to note that O > the case statement still thinks that test_num is a constant as you don't get:( > C > "%TPU-E-MUSTBECONST, expression must be a compile-time constant".t  C Local variable names can hide those of outer levels.  IIRC the caseH4 statement doesn't require a constant (this isn't C).  L > If you now also move the constant definition to before the procedure, then > the code now works correctly.  > J > In summary, it appears that some language elements can forward referenceI > the constant definition and that some cannot, which is inconsistant andc > appears to be a bug in TPU.  >    Not as I see it.   ------------------------------  % Date: Wed, 03 Apr 2002 13:51:15 -0700   From: Jon <jsmyth69@hotmail.com> Subject: Re: Disk Monitoring8 Message-ID: <rpqmaukgfnh1qpgjktc6ncl75s971nllvv@4ax.com>  
 Thank you!      , "Main, Kerry" <Kerry.Main@Compaq.com> wrote:   >Jon,  >p; >As a suggestion, you might be interested in the following:M >a >Performance API's for OpenVMS: D >http://www.openvms.compaq.com/openvms/performance-and-capacity.html >C >Performance profiling tool-? >http://www.openvms.compaq.com/openvms/products/dcpi/index.html9 >9 >Regards >n >Kerry Main  >Senior Consultant >Compaq Canada Corp. >Professional Services >Voice: 613-592-4660 >Fax  :  819-772-7036I >Email: Kerry.Main@Compaq.coma >, >t >-----Original Message----- ) >From: Jon [mailto:jsmyth69@hotmail.com]   >Sent: April 3, 2002 12:31 PM  >To: Info-VAX@Mvb.Saic.Com >Subject: Disk Monitoringe >g >l >Hi all, >$I > I was asked to create a disk i/o monitoring and I was REALLY wanting tohH >avoid doing a monitor disk to an output file and read it in.  Are thereE >lexicals that can return disk io? I'm specifically looking for queue_ >length.  Thanks!2 >:   ------------------------------   Date: 3 Apr 2002 19:36 CST' From: carl@gerg.tamu.edu (Carl Perkins)f Subject: Re: File IO query.C, Message-ID: <3APR200219360335@gerg.tamu.edu>  . "Bill Todd" <billtodd@metrocast.net> writes...- }"wing" <wingwong@witty.com> wrote in messageS8 }news:873e96d6.0204010756.2fbfc587@posting.google.com... }> Hi, }>H }> I have written a testing program to write 10000 records in a file. ItI }> takes less than 4s. However, if I run 48 copies of the testing program"I }> at the same time (by submit it to a job queue), it takes >47s to writes }> 10000 records.i }> }> How to avoid this?P  K }Larry is likely correct that your problem is that the way you're using VMS L }is causing a separate write to the disk for each record:  200 writes/secondK }is about what you'd expect from a disk, given that only rotational latencygG }is involved (assuming no other significant disk activity is going on).e } M }He's also correct in suggesting that a central logging process will help - aGE }lot.  The way to implement it is to use RMS asynchronous I/O (or two3K }separate threads working with each other) such that you can accumulate new0L }log records from the rest of the world while writing the previous batch andH }then submit the new batch while accumulating the next batch.  This way,H }you'll be able to write records at a significant fraction of the disk'sJ }actual streaming-write capabilitiy (one batch per revolution, rather thanL }one record per revolution as you're getting now) - assuming you use a largeF }enough RMS buffer to avoid performing multiple disk writes per batch. } M }If you need even more speed, use RMS 'placement control' to position the logrM }file on the outer cylinders of the disk (and make it contiguous).  There areZK }conditions where delaying your writes a bit to accumulate enough to nearlyJE }fill an entire disk track might improve things slightly, but only ateE }boundary rates (i.e., higher or lower rates will avoid the problem).  } K }I assume you're fsyncing after each log write to make sure it gets to diskoL }immediately  (as a transactional log would).  If you don't need to do that,I }then you can just accumulate as many log records as will fit in your RMSiM }buffer before a disk write occurs - and if you use multiple RMS buffers (agaoL }in, each should be fairly large:  if 127 blocks is still the limit, use it,K }else more like 128 KB - 256 KB) and the 'multi-buffering' option you won'tsK }even need a second thread (since RMS will do the writes transparently eachsL }time a buffer fills, IIRC).  How much of this you can do through C (withoutK }dealing explicitly with RMS FABs and RABs), and how much of what you can't:J }do through C you can do through using DCL to set up before running your C }program, I'm not sure.p   }- bill   F You can speed up C's regular I/O a lot without going directly to using> RMS calls. The default settings are what might be called "veryB conservative", and C gives you the means to tweak the RMS settings that it's I/O uses.m  A In the open(), fopen(), and/or creat() statements after the usual E parameters you can add in various VMS specific parameters, like maybesH these (you do need to include the quotation marks when specifying them):K "ALQ=2048", "DEQ=2048", "MBF=8", "MBC=64", "FOP=cbt,tef,sqo", "ROP=rah,wbh"n  F This sort of thing can speed up the disk I/O considerably. As for whatB these things mean, well... I hesitate to say, because I hate to be wrong, but:C  7 ALQ = initial allocation (in blocks; 2048 blocks = 1MB)>J DEQ = default extention quantity (in blocks - allocate this many each time$       the file needs to be extended)0 MBF = multi-buffer count (use this many buffers)+ MBC = multi-block count (blocks per buffer)vK FOP - cbt = "contiguos best try", i.e. try to make the file have one extente!             but don't require it.mG FOP - tef = "truncate at EOF on close" (you can leave this one off, but L             it is nice to release the disk space not used since we are using             big extensions)tK FOP - sqo = "sequential access only" (IIRC this triggers some optimizationsh=             inside of RMS, reducing the RMS related overhead)m; ROP - rah = "read ahead" (not used when writing, of course)-H ROP - wbh = "write behind" (this and the two MB* ones above are the ones@             that should give your the most benefit when writing)  H Some of these aren't going to help with just writing. This is a mix that? you can use for both reading and writing to speed them both up.t  F If you have some idea of how big the file will end up being, adjusting/ the ALQ to be about that size could help a bit.   D If you don't know how big the file will be, but know it will be hugeD then you might increase the DEQ to make it extend the file even lessG often (not too surprisingly, each time it does this all I/O to the diskp. stops while the new space is being allocated).  D If your process quotas and such are not high enough, you may need toF reduce the MBF and/or the MBC from the above. If they are high enough,B then you can increases the MBC although any additional increase inE speed is not likely to be anywhere as you get when going to the abovesD value from the default you might try doubling it, but with more than? that it may only give you an infinitesimal improvement, if any.oB Increaseing the MBF probably won't help too much either, but you'd have to try it to be sure.  A How well these things work with shared file access, I'm not sure. C I've never tried it. If nothing else, using this in conjuntion withsA a single logger process to which the others all pass the messagesc may be a good option.a  F You can set some of these things for exsisting programs that you can'tD modify via the SET RMS command, but not the "rah" and "wbh" options.  B The larger MBC value should cause there to be fewer writes for anyB given amount of data, meaning that if the I/O rate is the limiting@ factor (which it probably is) but there is still plenty of writeC speed to the media left (which there probably is unless each of hisrE records is big, which doesn't seem to be the case based on the recorddF write rate he is already getting) then some speedup should happen when this is increased.   --- Carl   ------------------------------  % Date: Wed, 03 Apr 2002 21:40:37 -0500y* From: John Reagan <john.reagan@compaq.com>1 Subject: Re: FORTRAN (was: Re: R.I.P. OpenVMS...) ) Message-ID: <3CABBD25.3020108@compaq.com>o  e > "Richard Maher" <maher_rj@hotmail.c0m> wrote in message news:<a6ven1$24g$1@paris.btinternet.com>...s > J >>I notice that Fortran now also offers full support for 64 bit addresses.G >>Would you happen to know what's happening with any other languages inuI >>particular COBOL. We have C, MACRO-32 and now Fortran. Do you ever come>% >>across Don Braffit in your travels?o >>  + Pascal has it also (for several years now).u   TYPE"    LONG_POINTER = [QUAD] ^INTEGER;       -- > John Reaganr' Compaq Pascal/{A|I}MACRO Project Leader!   ------------------------------  % Date: Wed, 03 Apr 2002 20:28:45 -0500 2 From: rdeininger@mindspring.com (Robert Deininger)A Subject: Re: Fred Kleinsorge at work (formerly HP's viewpoint...)aJ Message-ID: <rdeininger-0304022028450001@1cust61.tnt6.nashua.nh.da.uu.net>  0 In article <3CAB18B4.D70973D9@aaa.com>, Jan-Erik1 =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> wrote:i  @ >Oh, just for no reason at all, anyone know a good, high quality >color printer ?  8 Where are you going to get the right paper and ink?  ;-)  J Getting a current (last issued in the 1930's) $1000 bill accepted would be8 difficult.  Passing the 1880 model would be even harder.  H Though both are still legal tender;  the U.S. has never de-monetized anyF currency it issued.  If a bill reaches a federal reserve bank, it getsI withdrawn.  There are still a few $1000, $5000, and $10000 bills redeemedo
 each year.  C Any large-denomination will is worth more than it's face value as aeI collectible, even in horrible condition.  The nice example in the picture  is likely worth a * $100,000 or more -- but it's not for sale.   ------------------------------  % Date: Wed, 03 Apr 2002 19:50:08 -0500 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: HELP questionJ Message-ID: <rdeininger-0304021950080001@1cust61.tnt6.nashua.nh.da.uu.net>  5 In article <3CA9090A.C9E9445F@videotron.ca>, JF Mezei % <jfmezei.spamnot@videotron.ca> wrote:   ' >$ HELP HINTS Operators   (VAX VMS 7.2)  >tM >It says that to indicate a negative number one uses "--" and to subtract onet >uses "--".  > N >Is that an error in the documentation ? Or some quirk in HELP that prevents a >single - from appearing?   @ I've passed this particular bug report to the appropriate folks.   ------------------------------  $ Date: Wed, 3 Apr 2002 14:49:54 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>C  Subject: Re: IA64 is not the VAX3 Message-ID: <G7Jq8.1827$fL6.37293@news.cpqcorp.net>2  J Come on.  I wasn't really doing the comparison.  The moron tried to make aK point that the decision to drop the 10/20 in favor of VAX/VMS was "suicide" K for DEC.  My point is that if it was, then it was the best decision we ever H made.  And if he is trying to draw Alpha comparisons, I can only hope it+ will be as successful as that decision was.:  # Peter da Silva wrote in message ... 4 >In article <7bGq8.1813$fL6.36956@news.cpqcorp.net>,5 >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:"F >>But let me assume that there was an intent to illuminate or teach usK >>something... To address the stupidity in the base note - if killing AlphaCJ >>leads to the same results that killing the DECsystem-20 did -- then lets all H >>cheer.  Technical rants and lost souls aside - the VAX/VMS era was the most6 >>successful time in the history of Digital Equipment. >+F >There are a number of differences between IA64 and the VAX. Technical issues >aside:n >_C > Digital was 100% behind VAX/VMS: "all the wood behind one arrow", B > and VMS was a new clean OS design with a single core vision... IB > don't happen to care much for VMS but I do have to give it that. >iD > CHomPaq has 2 UNIX variants it's trying to merge, a 64 bit NT thatA > it abandoned a few years back and now needs to resuscitate, andRD > three legacy operating systems (and they just killed one of them). > D > Plus they have IA32 and x86-64 competing with IA64, and no controlD > over that. And then there's active Linux work on all four hardwareC > platforms (ia32, x86-64, IA64, and Alpha). And it sometimes seemssE > most of the innovative people left are messing around with iPaq ando > Itsy.a >  >--fA >Rev. Peter da Silva, ULC.                                  WWFD?n > G >"Be conservative in what you generate, and liberal in what you accept"  > -- Matthew 10:16 (l.trans)   ------------------------------  # Date: Wed, 03 Apr 2002 20:18:35 GMTm* From: "Bill Todd" <billtodd@metrocast.net>  Subject: Re: IA64 is not the VAXC Message-ID: <vsJq8.545518$pN4.39063539@bin8.nnrp.aus1.giganews.com>s  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:G7Jq8.1827$fL6.37293@news.cpqcorp.net...eL > Come on.  I wasn't really doing the comparison.  The moron tried to make aC > point that the decision to drop the 10/20 in favor of VAX/VMS was 	 "suicide"-
 > for DEC.  D That would be incorrect, but subtly:  the decision to drop the 10/20H significantly injured DEC (given how and when it occurred), but what wasK *really* suicide for DEC was the *mindset* that led to the decision to dropB
 the 10/20.  C   My point is that if it was, then it was the best decision we everk > made.1  I You're confused.  The decision to develop VAX and VMS could arguably haverA been the best decision DEC ever made (given the excellence of itsSL execution), but the decision to drop the 10/20 as and when it was done was a major mistake.   - bill   ------------------------------  # Date: Wed, 03 Apr 2002 21:01:40 GMTD" From: "Hans Vlems" <hvlems@iae.nl>  Subject: Re: IA64 is not the VAX/ Message-ID: <U4Kq8.286$o3.4403@typhoon.bart.nl>.   Fred,i  D one question: how many 10/20's did DEC/Digital sell and how many VMS systems?3 That should put things in perspective, wouldn't it. J OTOH I do understand Crispin's feelings and yes, VMS may go down the drain in aL similar way as TOPS. That is the lesson: corporate policies have no relation to customer needs. So be it.s  
 Hans Vlems    > Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote in message- news:G7Jq8.1827$fL6.37293@news.cpqcorp.net... L > Come on.  I wasn't really doing the comparison.  The moron tried to make aC > point that the decision to drop the 10/20 in favor of VAX/VMS wasc	 "suicide" H > for DEC.  My point is that if it was, then it was the best decision we everJ > made.  And if he is trying to draw Alpha comparisons, I can only hope it- > will be as successful as that decision was.r > % > Peter da Silva wrote in message ...a6 > >In article <7bGq8.1813$fL6.36956@news.cpqcorp.net>,7 > >Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:.H > >>But let me assume that there was an intent to illuminate or teach usG > >>something... To address the stupidity in the base note - if killing  AlphacL > >>leads to the same results that killing the DECsystem-20 did -- then lets > all	J > >>cheer.  Technical rants and lost souls aside - the VAX/VMS era was the > most8 > >>successful time in the history of Digital Equipment. > >dH > >There are a number of differences between IA64 and the VAX. Technical > issues	 > >aside:i > > E > > Digital was 100% behind VAX/VMS: "all the wood behind one arrow",iD > > and VMS was a new clean OS design with a single core vision... ID > > don't happen to care much for VMS but I do have to give it that. > > F > > CHomPaq has 2 UNIX variants it's trying to merge, a 64 bit NT thatC > > it abandoned a few years back and now needs to resuscitate, andrF > > three legacy operating systems (and they just killed one of them). > > F > > Plus they have IA32 and x86-64 competing with IA64, and no controlF > > over that. And then there's active Linux work on all four hardwareE > > platforms (ia32, x86-64, IA64, and Alpha). And it sometimes seemsuG > > most of the innovative people left are messing around with iPaq andl	 > > Itsy.s > >e > >--hC > >Rev. Peter da Silva, ULC.                                  WWFD?t > > I > >"Be conservative in what you generate, and liberal in what you accept"c > > -- Matthew 10:16 (l.trans) >  >o   ------------------------------  $ Date: Wed, 3 Apr 2002 12:53:22 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>P  Subject: Re: IA64 is not the VAXP Message-ID: <Pine.LNX.4.50.0204031237450.30061-100000@shiva0.cac.washington.edu>  $ On Wed, 3 Apr 2002, Bill Todd wrote:B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message > > The moron tried to make aoE > > point that the decision to drop the 10/20 in favor of VAX/VMS wasp > > "suicide" for DEC.  H This is a perfect example of the mindset that killed Digital; slurs suchA as "moron" at anyone who is not in harmony with Digital Political  Correctness.  F > That would be incorrect, but subtly:  the decision to drop the 10/20J > significantly injured DEC (given how and when it occurred), but what wasM > *really* suicide for DEC was the *mindset* that led to the decision to drop, > the 10/20.  
 Of course.  C There are scenarios in which dropping the 10/20 could have happenedtE without destroying Digital, but the Digital corporate mindset is whatm) rendered that injury into a mortal wound.t  E >   My point is that if it was, then it was the best decision we evero	 > > made.uK > You're confused.  The decision to develop VAX and VMS could arguably havemC > been the best decision DEC ever made (given the excellence of its N > execution), but the decision to drop the 10/20 as and when it was done was a > major mistake.   Right again.  I Digital practically screamed to the world that it could not be trusted as F a vendor.  People left that DECUS symposium knowing that they would beJ told to clean out their desk, and these were people in the corporate worldJ that Digital was trying to hawk VAXen to.  As a result, Digital got on theF "never buy" at quite a few large corporations.  The trend may not have= been noticable in the immediate aftermath, but by 1988 it was 
 unmistakable..  A Also, VAX and VMS never were significant players in either the PC3I revolution or the Internet revolution.  Although some early Internet UNIXeG systems were based upon VAX, by the late 1980s the Attack of the Killer0" Micros had wiped most of them out.  I The 20, on the other hand, was a significant Internet player up until the E genesis of the web.  SIMTEL20 was there until the early 90s.  Digitalt? never "got" the Internet, and always saw it as a fringe market.i  
 -- Mark --   http://staff.washington.edu/mrc>F Science does not emerge from voting, party politics, or public debate.   ------------------------------  $ Date: Wed, 3 Apr 2002 13:40:09 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>h  Subject: Re: IA64 is not the VAXP Message-ID: <Pine.LNX.4.50.0204031338020.30061-100000@shiva0.cac.washington.edu>  % On Wed, 3 Apr 2002, Hans Vlems wrote:rF > one question: how many 10/20's did DEC/Digital sell and how many VMS
 > systems?5 > That should put things in perspective, wouldn't it.s   A better measure is:  ? How many 10/20s were on the Internet, and how many VMS systems?o  9 VMS did not replace the 10/20 on the Internet.  UNIX did.   
 -- Mark --   http://staff.washington.edu/mrc F Science does not emerge from voting, party politics, or public debate.   ------------------------------   Date: 3 Apr 2002 23:48:28 GMTb( From: peter@taronga.com (Peter da Silva)  Subject: Re: IA64 is not the VAX2 Message-ID: <a8g4cc$1n4l$1@citadel.in.taronga.com>  3 In article <G7Jq8.1827$fL6.37293@news.cpqcorp.net>, 4 Fred Kleinsorge <kleinsorge@star.zko.dec.com> wrote:K >Come on.  I wasn't really doing the comparison.  The moron tried to make aaL >point that the decision to drop the 10/20 in favor of VAX/VMS was "suicide"L >for DEC.  My point is that if it was, then it was the best decision we everI >made.  And if he is trying to draw Alpha comparisons, I can only hope it , >will be as successful as that decision was.  J Unfortunately, I fully expect the IA64 to be as successful as the iAPX432.   -- t@ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)    ------------------------------   Date: 3 Apr 2002 16:28:06 -0600 - From: koehler@encompasserve.org (Bob Koehler)sM Subject: Re: Language support on Itanium VMS (was: Announcing a boot contest) 3 Message-ID: <USbzNuRNKeQd@eisner.encompasserve.org>a  c In article <pTAcWd7uT3Ev@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:g   > 9 > 4. I have seen no clear statement that the ACT product,'; >    even if available, would work with the VMS debugger onr
 >    Itanium.C  8    I have seen clear public statements that it will not.   ------------------------------  % Date: Wed, 03 Apr 2002 19:55:08 -0500t2 From: rdeininger@mindspring.com (Robert Deininger)M Subject: Re: Language support on Itanium VMS (was: Announcing a boot contest) J Message-ID: <rdeininger-0304021955080001@1cust61.tnt6.nashua.nh.da.uu.net>  3 In article <USbzNuRNKeQd@eisner.encompasserve.org>,k. koehler@encompasserve.org (Bob Koehler) wrote:  J >In article <pTAcWd7uT3Ev@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:h >h >>  : >> 4. I have seen no clear statement that the ACT product,< >>    even if available, would work with the VMS debugger on >>    Itanium. >r9 >   I have seen clear public statements that it will not.c  * Where are these statements, if you please?   ------------------------------  $ Date: Wed, 3 Apr 2002 13:10:51 -0600, From: rqkMr Lasader <gaPeterLasader@msn.com>7 Subject: MCSE, MCSA, CCNA, CCNP, Security and More! icvO" Message-ID: <5062418@MVB.SAIC.COM>   <html> <head>  <title>Untitled Document</title>H <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head>o  ' <body bgcolor="#FFFFFF" text="#000000">eZ <p>I noticed your email address on a technology list serve related to I.T. certification. U   With your permission, we would like to send you information regarding new training MP   solutions  including 14-day instructor-led BootCamps for certifications such T   as the MCSE, MCSA, CCNA, CCNP and more. To provide us a little bit of information ~   on yourself so that we can send you the right details, please <a href="http://195.235.97.200/personal8/toppromo2/tt/">click    here</a>. </p> <p>Sincerely, <br> </p> <p>Jake Swanson</p>  </body>m </html>t  $ pxxidxjgvvomkcmedybwmfwonkvddsnyjqdw   ------------------------------   Date: 3 Apr 2002 14:26:47 -0800l1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)e" Subject: Re: Memory Channel vs. CI= Message-ID: <cf15391e.0204031426.3fb72a05@posting.google.com>   Y Nic Clews <sendspamhere@127.0.0.1> wrote in message news:<3CAAC537.20915903@127.0.0.1>...hI > For completeness Keith, do you have the lock latency on 10 MB/s LAN vs. , > DSSI on VAX? [Any other relevant figures?]  F No, sorry.  All the other figures I have can be found at approximatelyg slide 99 within http://www.geocities.com/keithparris/decus_presentations/f2001_vmsclusters_advanced.pptg. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------   Date: 3 Apr 2002 14:42:14 -0800h1 From: keithparris_NOSPAM@yahoo.com (Keith Parris)d" Subject: Re: Memory Channel vs. CI= Message-ID: <cf15391e.0204031442.25af5971@posting.google.com>   e Jan C. Vorbrggen <jvorbrueggen@mediasec.de> wrote in message news:<3CAB142D.C55D03EC@mediasec.de>...eK > > MC even comes close to the speed of Galaxy Shared Memory Interconnect,  = > > where I measured about 100 microseconds for lock latency.t > I > 'scuse me - 100 000 cycles latency for exchanging a simple lock requeste > over shared memory!?  D The request has to be put into the form of an SCS message and passed@ through the SCS and port driver code once on each end, into lockC manager code on the lock master node, and then the response must gouF out via a message through SCS and the port driver code on each node on
 the way back.r  C A local lock request takes 4 to 6 microseconds, in contrast.  So ithE appears it is probably not spending a lot of time in the lock manager  code.e  B GSMCI is more efficient than MC because it avoids a couple of dataF copy operations which are made necessary by the fact that MC transfersB data between nodes by the act of the CPU writing data to a special range of address space.s  B Note that in theory, with Galaxy technology, one might conceivablyD just put the lock manager data structures in shared memory where all@ nodes could access it, instead of having SCS messages fly around between nodes.. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------   Date: 3 Apr 2002 21:39:49 -0600 + From: young_r@encompasserve.org (Rob Young) " Subject: Re: Memory Channel vs. CI3 Message-ID: <OxMuxwYIfaQn@eisner.encompasserve.org>0  q In article <cf15391e.0204031442.25af5971@posting.google.com>, keithparris_NOSPAM@yahoo.com (Keith Parris) writes:(g > Jan C. Vorbrggen <jvorbrueggen@mediasec.de> wrote in message news:<3CAB142D.C55D03EC@mediasec.de>... L >> > MC even comes close to the speed of Galaxy Shared Memory Interconnect, > >> > where I measured about 100 microseconds for lock latency. >> oJ >> 'scuse me - 100 000 cycles latency for exchanging a simple lock request >> over shared memory!?  > F > The request has to be put into the form of an SCS message and passedB > through the SCS and port driver code once on each end, into lockE > manager code on the lock master node, and then the response must gorH > out via a message through SCS and the port driver code on each node on > the way back.t > E > A local lock request takes 4 to 6 microseconds, in contrast.  So it-G > appears it is probably not spending a lot of time in the lock managere > code.r > D > GSMCI is more efficient than MC because it avoids a couple of dataH > copy operations which are made necessary by the fact that MC transfersD > data between nodes by the act of the CPU writing data to a special > range of address space.u > D > Note that in theory, with Galaxy technology, one might conceivablyF > just put the lock manager data structures in shared memory where allB > nodes could access it, instead of having SCS messages fly around > between nodes.    @ 	And I recall that being on a roadmap and must surely fall under? 	current roadmaps in the more arcane "performance improvments."t  ? 	Funny... there is a related post in comp.arch, touches on this  	issue too:g  & From: zaitcev@yahoo.com (Pete Zaitcev) Newsgroups: comp.archoC Subject: Re: Greg's latency analysis (Was: Re: Blade architectures): Date: 3 Apr 2002 21:04:00 GMTe Organization: Red Hat Inc.    > Two notes about latencies. They _very_ very much in the eye ofA a beholder. At Sun we did a replicated memory storage controller,pC and I tried to introduce a transparent software replication insteadh? of hardware replication. In the process, there was a discussion : if FC/AL is appropriate instead of SCI to run Sun Cluster.< Cluster people were bandying about 10uS latencies, and I did; 130uS. What they did was a busy loop thread on a slave node @ which waited until a word value changes then replied by changingA some other word. I had a (kernel mode) thread that sent a packet,w: and a thread on other node to take the interrupt and replyB with other packet. As you can see, both threads could do something< useful, which it would be very hard to keep those busy loops: for every word that might have been changed on other node.; Once you introduce anything that does actual work, all thate( 10uS stuff goes right out of the window.    A 	Point is ... seems (regardless of OS/mechanism) to get a message6> 	from Node A to Node B, layers are involved.  That is why lock; 	structures in Galactic Shared Memory is such a great idea.M   			 	Rob   ------------------------------  # Date: Thu, 04 Apr 2002 02:20:36 GMTc1 From: "David J. Dachtera" <djesys.nospam@fsi.net>m7 Subject: Re: Newbie trying to get 2 Alpha boxes running ' Message-ID: <3CABBADE.53B65CE2@fsi.net>    David Waine wrote: > 
 > Dear ng, > N > Thanks to those who responded through the ng and e-mail.  The long and shortA > of it is that I've got the VMS box working and should have readA > 7 > http://www.openvms.compaq.com/wizard/openvms_faq.htmlt > M > before posting as this answered all of my questions (including sources of aaL > selection of on-line and hard-copy tutorials).  As a result of reading theK > above, I've realised that this could be a big project...  (learning VMS Iv > mean). > ' > Anyway thanks for the welcoming help.e  G Well done! You've taken your first steps into a very interesting world!e  H If you can put up with our belly-aching, bitching, and bickering, you'll< find this group informative as well as amusing, aggravating, frustrating, infuriating, ...a   -- m David J. Dachterar dba DJE Systemst http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  $ Date: Wed, 3 Apr 2002 15:27:43 -05005 From: "Brad McCusker" <Brad.McCuskerNOSP@MCompaq.com>s3 Subject: Re: Once a fool, always a fool I guess ...s3 Message-ID: <jEJq8.1831$fL6.37253@news.cpqcorp.net>   G "Andrew Harrison" <andrew_nospam.harrison_remove_this@sun.com> wrote ine$ message news:3CAAFE13.507@sun.com... >e >c@ > company (Digital) that lost money on every AlphaServer sold if@ > you included the cost of the FAB. We used to tell customers toC > buy as many Alpha boxes as they could since it was only hastening  > Digitals demise. >(  @ This makes about as much sense as everything else Andrew writes.  D Without getting into the specifics of the FAB and its costs (which IC have no first hand knowledge of), it should be safe to say that ther= FAB costs Andrew refers to are fixed.  Produce one chip, or aVC bazillion chips, the costs of the FAB stay the same. Therefor, each A Alpha chip would contribute to the recovery of those fixed costs.y@ So, the more alphas sold, the less money lost on the FAB's fixedC costs, and essentially, the opposite effect from what Andrew statedn would be realized.  	 Sheesh...    ------------------------------  % Date: Wed, 03 Apr 2002 16:01:55 -0500b- From: JF Mezei <jfmezei.spamnot@videotron.ca>n3 Subject: Re: Once a fool, always a fool I guess ...1, Message-ID: <3CAB6DA8.57B67623@videotron.ca>   Brad McCusker wrote:E > bazillion chips, the costs of the FAB stay the same. Therefor, eachoC > Alpha chip would contribute to the recovery of those fixed costs.pB > So, the more alphas sold, the less money lost on the FAB's fixedE > costs, and essentially, the opposite effect from what Andrew stated  > would be realized.  J Problem arose when Digital started to want to build wintel PCs and to helpH that new endeavour, decided not to allow Alpha to compete at the low endM against wintel. That prevented Alpha from ever reaching the volumes needed totL justify that FAB. And from what I was told, Digital actually REFUSED FABbingN business from other companies (I think AMD) in order to keep the FAB available& should Alpha ever take off in volumes.   ------------------------------  % Date: Wed, 03 Apr 2002 20:14:52 +0100o/ From: Tony  Barker <tony@dartfactordata.ltd.uk>  Subject: OpenVMS VAX V7.3a6 Message-ID: <B8D1133C.8E39%tony@dartfactordata.ltd.uk>  . I have a VAX 7740 happily running OpenVMS V7.1L Before I port it all over to an Alpha I am about to upgrade the VAX to V7.3.K Does anyone have any thoughts as to whether this is a good move or not?  IscE V7.3 stable/usable or am I letting myself in for a lot of extra work?v   Thanks   Tony   ------------------------------  % Date: Wed, 03 Apr 2002 20:11:18 -0500d2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: OpenVMS VAX V7.3eJ Message-ID: <rdeininger-0304022011190001@1cust61.tnt6.nashua.nh.da.uu.net>  C In article <B8D1133C.8E39%tony@dartfactordata.ltd.uk>, Tony  Barkerf# <tony@dartfactordata.ltd.uk> wrote:6  / >I have a VAX 7740 happily running OpenVMS V7.1 M >Before I port it all over to an Alpha I am about to upgrade the VAX to V7.3.sL >Does anyone have any thoughts as to whether this is a good move or not?  IsF >V7.3 stable/usable or am I letting myself in for a lot of extra work?  J Of course, you will want to read the intervening release notes and upgradeH instructions before you begin.  And always make a good, standalone image1 backup copy of your system disk before upgrading.t  I There haven't been big functionaly changes in VMS on the VAX side betweeniH V7.1 and V7.3.  You aren't likely to stumbing into any problems with the upgrade.   ------------------------------   Date: 3 Apr 2002 17:36:39 -0800 ( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: OpenVMS VAX V7.3 = Message-ID: <d7791aa1.0204031736.5e68b8bf@posting.google.com>t  m Tony  Barker <tony@dartfactordata.ltd.uk> wrote in message news:<B8D1133C.8E39%tony@dartfactordata.ltd.uk>... 0 > I have a VAX 7740 happily running OpenVMS V7.1N > Before I port it all over to an Alpha I am about to upgrade the VAX to V7.3.M > Does anyone have any thoughts as to whether this is a good move or not?  IseG > V7.3 stable/usable or am I letting myself in for a lot of extra work?w >  > Thanks >  > Tony  @ I heard 7.3-1 was out ... I would recommend using it if you must use 7.3 ...    ------------------------------  % Date: Wed, 03 Apr 2002 20:58:15 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca>e Subject: Re: OpenVMS VAX V7.3e, Message-ID: <3CABB32E.25694445@videotron.ca>   Robert Deininger wrote:bK > There haven't been big functionaly changes in VMS on the VAX side betweenhJ > V7.1 and V7.3.  You aren't likely to stumbing into any problems with the
 > upgrade.  N 7.3 drops support for display postscript. So for workstations, you should stop	 at 7.2-2.    ------------------------------  % Date: Wed, 03 Apr 2002 20:53:04 -0500 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: OpenVMS VAX V7.3nJ Message-ID: <rdeininger-0304022053040001@1cust61.tnt6.nashua.nh.da.uu.net>  = In article <d7791aa1.0204031736.5e68b8bf@posting.google.com>,i) bob@instantwhip.com (Bob Ceculski) wrote:a  ; >Tony  Barker <tony@dartfactordata.ltd.uk> wrote in messagep2 news:<B8D1133C.8E39%tony@dartfactordata.ltd.uk>...1 >> I have a VAX 7740 happily running OpenVMS V7.1yO >> Before I port it all over to an Alpha I am about to upgrade the VAX to V7.3.dN >> Does anyone have any thoughts as to whether this is a good move or not?  IsH >> V7.3 stable/usable or am I letting myself in for a lot of extra work? >>  	 >> Thanksa >> e >> Tony  > A >I heard 7.3-1 was out ... I would recommend using it if you mustt >use 7.3 ...  1 There's no 7.3-1 release for VAX in the pipeline.,  J 7.3-1 for alpha won't ship to customers for a while yet.  Field testing is just getting started.9   ------------------------------  % Date: Wed, 03 Apr 2002 22:51:16 -0500n1 From: Michael Austin <maustin@firstdbasource.com>0Y Subject: Re: OT: Choosing from Lists (was: Re: Announcing a boot contest for OpenVMS on Iu1 Message-ID: <3CABCDB4.F908934@firstdbasource.com>o   Larry Kilgallen wrote: > Y > In article <C2256B90.005FCB99.00@jklh22.valmet.com>, norm.raphael@jamesbury.com writes:  > >o > > 	 > > go ton  > > http://support.microsoft.com > > highlight the window below > > Search (KB)d > E > Below that (and above "Support Menu" I see a text link "Search Now"gB > and a white arrow pointing right with a green square background. >  > > and type a W, for example2 > > Wheel Mouse will appear. > C > No, a W appears in place of the URL up at the top of the Netscapea > Communicator window. > 3 > > Hit the down-arrow and you will scroll the W's.c& > > Hit I and it will jump to the I's.I > > Click the pulldown and you will see the list from the letter you hit.  > C > Perhaps you have me confused with someone who enables JavaScript. 8 > I though you had been around this newsgroup longer :-)  ? Sheesh, you people are supposed to "know" what you are doing :)h  6 It is not javascript.. for a non corporate test go to:  " http://www.spacelots.com/test.html  F It won't do anything, just demonstrate drop-down lists... and there is) no submit button so it won't go anywhere.U  E I can add a second one that does do javascript if you would like... auE little pop-up window that says "Boo" or something when you select it.  -- - Regards,  7 Michael Austin            Registered Linux User #261163m7 First DBA Source, Inc.    http://www.firstdbasource.comL Sr. Consultant 704-947-1089 (Office)n 704-236-4377 (Mobile)    ------------------------------  # Date: Wed, 03 Apr 2002 19:46:48 GMTc8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond)F Subject: Re: Possible (mis)behavior of sys$manager:utc_time_setup.com?3 Message-ID: <I_Iq8.1825$fL6.37284@news.cpqcorp.net>o  A Here is a piece of valuabe information that is easily overlooked:p  D If you have DECnet Plus (DECNET_OSI a.k.a. DECnet Phase V) installed> and you do NOT want DTSS to run, then you must "disable" DTSS.   You do this by defining:  &     $ define/system net$disable_dtss 1   in SYS$MANAGER:SYLOGICALS.COM.  6 (This is documented in the DECnet Plus release notes.)   -- nK     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USA@H        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  $ Date: Wed, 3 Apr 2002 14:52:00 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>>2 Subject: Re: Predictions - just for the hell of it3 Message-ID: <D9Jq8.1829$fL6.37253@news.cpqcorp.net>s  K I'm just tired of 20 year old DS20 complaints.  VAX/VMS propelled us to #2,1 not the 10/20.      ! Mark Crispin wrote in message ... * >I wonder why Fred Kleinsorge is so upset. >oB >Perhaps it's because he has to dust off his resume, what with hisD >impending job loss once HP abolishes the last pathethic remnants ofF >Digital.  He's now discovering that nobody wants to hire anyone a VMS >developer.e >pE >It's interesting how he labels a period in which customers abandoned.H >Digital en masse as "the most successful time in the history of Digital >Equipment." >eK >Successful time?  I can't think of a more egregious failure.  Digital wenttJ >from being the #2 computer company to extinction.  Digital totally missedE >the personal computer revolution, and its feeble attempts to have PCi( >products were the joke of the industry. >7F >Digital's terminal status was already obvious in 1988, a mere 5 years >after the 10/20 was canned. >/ >-- Mark --l >   >http://staff.washington.edu/mrcG >Science does not emerge from voting, party politics, or public debate.l >r >  >t   ------------------------------  % Date: Wed, 03 Apr 2002 15:25:43 -0500I- From: JF Mezei <jfmezei.spamnot@videotron.ca>t2 Subject: Re: Predictions - just for the hell of it, Message-ID: <3CAB652E.714BDE2F@videotron.ca>   Fred Kleinsorge wrote: > M > I'm just tired of 20 year old DS20 complaints.  VAX/VMS propelled us to #2,  > not the 10/20.    B As much as Fred is going to hate it, I fully agree with the above.  U Ironic that deemphasizing VMS has resulted in Digital going from #2 down to oblivion.v   ------------------------------  # Date: Wed, 03 Apr 2002 20:14:00 GMT * From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Predictions - just for the hell of itC Message-ID: <coJq8.215555$2q2.19050029@bin4.nnrp.aus1.giganews.com>s  5 "Bill Todd" <billtodd@metrocast.net> wrote in message3< news:INGq8.101367$VJ1.8367111@bin3.nnrp.aus1.giganews.com... > B > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message/ > news:7bGq8.1813$fL6.36956@news.cpqcorp.net...s   ...   H > > But let me assume that there was an intent to illuminate or teach usG > > something... To address the stupidity in the base note - if killingc Alpha L > > leads to the same results that killing the DECsystem-20 did -- then lets > allfJ > > cheer.  Technical rants and lost souls aside - the VAX/VMS era was the > most8 > > successful time in the history of Digital Equipment. >nH > You're comparing apples and oranges.  The VAX/VMS era started in 1978, while J > the 36-bit line was declared dying in 1983 IIRC.  And as I was there for thenL > period 1976 - 1987, I can assure you that DEC's decline *did* begin aroundG > the latter date (reasonable arguments could place it a bit earlier or  later,H > but not much), even though DEC's financial decline lagged the internal. > upper-level management rot by several years.  J On further reflection, my response above really doesn't adequately addressJ the lessons that should be learned, starting indeed 20 years ago.  So I'll
 expand a bit.s  J To a very large degree, the decline of DEC (and now Compaq) can be tightlyL connected to several massive and massively-misguided attempts to drive usersI in directions the company felt were most convenient/cost-effective for it-J rather than letting customers tell the company what they wanted and acting accordingly.  In other words,h  G Maxim #1:  Customers are like cats:  trying to herd them is not usuallytB effective, especially when they have other options to choose from.  K Maxim #2:  Existing customers are birds in the hand; new customers are justi? someone's dream of the future which may or may not be accurate.   G Maxim #3:  Therefore, providing customers with products they're eagerlytI lining up to buy at a decent profit to you is usually not only the safest>H but the most profitable course for a company to take.  By all means alsoE develop new products for the future, but don't start phasing out your H existing ones until the new ones are at least equally acceptable - which leads to  H Maxim #4:  Premature consolidation to reduce costs that don't need to beK reduced (because sufficient demand still exists for the wider product rangedG to return a good profit) is stupid, stupid, stupid:  it pisses off yournL customers unnecessarily and with *no* guarantee of compensating return.  AndH that's happened repeatedly at first DEC, now Compaq, and likely soon HP.  E Or perhaps one can put it more simply:  acting for your own perceivedyF convenience at the expense of your customers' doesn't work well unlessJ you're a monopoly, since at least some of your competitors likely won't be that stupid.   Cases in point:o  K 1.  The death of the 36-bit machines.  Consolidating to VAX would certainlyoL have been a reasonable strategy *if* VAX and the systems on it had been realH replacements in the eyes of the customer base.  But VAX did not have theG performance to be such at the time Jupiter (and further 36-bit hardwarevI development) was cancelled, and VMS never got all the features the 36-bit  people wanted.  I As a result, DEC alienated a whole lot of customers in the exact high-end:K market segment it wanted to push VAX into.  Had it waited for VAX to become:K performance-competitive, not only would it have retained the business *and*vF affection of those customers, but VMS would quite likely have had moreK impetus to incorporate the features those customers found useful (given thelI continuing internal competition).  The degree of that alienation is stilluE very evident today, and *that* itself is significant.  One could alsosJ suggest that the 11 had a lot more life left in it than DEC took advantageI of, but while that too may have been a mistake it was a far less dramatic  one.  K 2.  The one case DEC *did* handle half-decently was the transition from VAXsL to Alpha.  But that transition was *not* driven by consolidation desires butJ rather by engineering considerations:  RISC seemed a better bet for futureL performance advances than CISC (over a dozen years later the success of IA32I may call that assessment into some question, but it certainly seemed trueuF then - and one should not forget that Intel has likely put an order ofK magnitude more money into IA32 development than DEC put into Alpha), and 32 K bits of address space was clearly not going to be sufficient forever in thed mid-range and up.r  H 3.  The infamous 'affinity' program.  Again, an attempt to consolidate -K this time to a 'commodity' OS - and, again, a problem more because it was ajD (drastically) premature attempt at replacement (and replacement of aH highly-profitable platform with a far-less-profitable one) rather than aL simple attempt to expand in new directions.  Customers weren't pleased, and,: correctly fearing for VMS's owner's commitment, many left.  K 4.  The cancellation of NT on Alpha.  While the profitability may have beenpI marginal, the potential of having Alpha as the initial platform for Win64eE was major.  Instead, Compaq just elected to piss off another bunch of F customers in the hope that it *might* save a few bucks (if the adverseL customer reaction to the decision didn't cost far more than the savings, and6 leaving aside the upside potential of Win64 on Alpha).  L 5.  The death-notice for Alpha itself - *long* before Itanic was even usableJ by VMS or Tru64, let alone had proven a decent replacement.  ConsolidationE (and treachery, in terms of solemn and repeated commitments summarilywL broken) par excellence, but to an inferior platform - and, as usual, withoutH any apparent concern about how the existing customer base felt about it.  K 6.  The decision not to port Tru64 to Itanic after all, despite both having:J 'committed' to when the Alphacide was announced *and* having major aspectsJ of the port already done (back when it was first planned).  Given that theI Tru64 base is now supposedly comparable to VMS's, that should give peoplep here pause as well.s  H Those are just the biggies that come to mind off hand.  Feel free to add more.o  E Call it insensitivity to customer wishes.  Call it excessive zeal foroF cost-containment.  Call it disasterous over-confidence in management's@ abilities to control and/or predict markets.  Call it monumental
 incompetence.A  L Call it whatever you want, but it's a real pattern.  And it started with the7 36-bit material you seem still to refuse to learn from.o   - bill   ------------------------------  $ Date: Wed, 3 Apr 2002 12:55:42 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>c2 Subject: Re: Predictions - just for the hell of itP Message-ID: <Pine.LNX.4.50.0204031254210.30061-100000@shiva0.cac.washington.edu>  # On Wed, 3 Apr 2002, JF Mezei wrote:e > Fred Kleinsorge wrote:O > > I'm just tired of 20 year old DS20 complaints.  VAX/VMS propelled us to #2,  > > not the 10/20.W > Ironic that deemphasizing VMS has resulted in Digital going from #2 down to oblivion.3  > So did the public attitudes of Digital employees, such as Fred Kleinsorge's postings.  
 -- Mark --   http://staff.washington.edu/mrcpF Science does not emerge from voting, party politics, or public debate.   ------------------------------  % Date: Wed, 03 Apr 2002 16:32:11 -0500l- From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Predictions - just for the hell of it, Message-ID: <3CAB74BE.6FC24F45@videotron.ca>   Mark Crispin wrote: Y > > Ironic that deemphasizing VMS has resulted in Digital going from #2 down to oblivion.f > @ > So did the public attitudes of Digital employees, such as Fred > Kleinsorge's postings.  I For as much as Mr Kleinsorge hates me, I do not think that he can be madet responsible for VMS's demise.   M Sure, we may have liked to see the VMS engineers mount an internal revolt and0H chain themselves to cover Curly's parking spot and make as much noise asM possible to outline the stupidity of Compaq squandering Alpha and VMS. But iflL these guys are told not to worry and that everything is being taken care of,N then the motivation to risk your job by rebelling against the corporation just isn't there.  N Also remember that those employees are only told about the WINs, not about theJ LOSSES. They may not even be aware of cases when Compaq sales critters are' pitching Windows to existing VMS sites.    ------------------------------  $ Date: Wed, 3 Apr 2002 16:28:05 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>02 Subject: Re: Predictions - just for the hell of it3 Message-ID: <IzKq8.1832$fL6.37221@news.cpqcorp.net>e  ! Mark Crispin wrote in message ...e$ >On Wed, 3 Apr 2002, JF Mezei wrote: >> Fred Kleinsorge wrote: L >> > I'm just tired of 20 year old DS20 complaints.  VAX/VMS propelled us to #2,h >> > not the 10/20.oK >> Ironic that deemphasizing VMS has resulted in Digital going from #2 down  to oblivion. >o? >So did the public attitudes of Digital employees, such as Fredi >Kleinsorge's postings.a >   K Get a life.  I didn't do anything.  I'm sorry you are still pissed a couplepK decades later.  You have made it clear that VAX/VMS was the proximate causeoH of the death of TOPS-20 - and thus have no interest or positive opinionsK about VMS.  If there was *anything* I could say that would cause you to buy-I a VMS system. I'd... well.  whatever.  The simple truth is, regardless ofBF the reasons for killing the DEC-20, it was meaningless to the eventualI success and subsequent failure of DEC.  DEC grew to #2 on the strength oftJ VAX/VMS, and then imploded for many reasons, each of which can create it'sI own debate.  But DEC was growing so fast on the strength of VAX/VMS, thate the DEC-20 became irrelevant.r  J If Tru64 or Windows had been propelling DEC or Compaq with the same growthL and profitability as VAX/VMS drove DEC - then VMS would have long ago ceasedD to have any relevance, and should have been killed just like TOPS-20I regardless of any of it's technical advantages.  Some would argue that it-G doesn't have any relevance any more - but I believe that it's continued<J existance, and the port to IA64 proves that it still does have some - evenJ if that does not mean that it will be the flagship product of the company.   Time will tell.a   ------------------------------  $ Date: Wed, 3 Apr 2002 16:40:22 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>.2 Subject: Re: Predictions - just for the hell of it3 Message-ID: <dLKq8.1833$fL6.37336@news.cpqcorp.net>-  = JF Mezei wrote in message <3CAB74BE.6FC24F45@videotron.ca>...  >Mark Crispin wrote:H >> > Ironic that deemphasizing VMS has resulted in Digital going from #2 down to oblivion.0 >>A >> So did the public attitudes of Digital employees, such as Fred0 >> Kleinsorge's postings.l >oJ >For as much as Mr Kleinsorge hates me, I do not think that he can be made >responsible for VMS's demise. >p  I I don't hate you.  I'm annoyed that with you and a few others there is nop room for anything positive.>  J >Sure, we may have liked to see the VMS engineers mount an internal revolt andDI >chain themselves to cover Curly's parking spot and make as much noise as K >possible to outline the stupidity of Compaq squandering Alpha and VMS. But  ifI >these guys are told not to worry and that everything is being taken careu of,iJ >then the motivation to risk your job by rebelling against the corporation just
 >isn't there.l >   J If chaining myself to a CEO's leg would make any difference, I would have.F The only leverage VMS has is that A) it is profitable, and B) it sells Alphas and eventually IA64s.  F Anything that is done to make either of these significantly less true,I reduces any future leverage VMS might have to resume the comeback that we8L had been making pre-Q4 (i.e. when the hits of Compaq announcements, 9/11 and/ the general economic decline all hit everyone).e  L We have to get past the Alpha decision, and the HP merger.  The ONLY thing IH can do to try and assure a future for VMS is to make sure that I and theJ people working for and with me execute to the IPF port roadmap, and TRY toL assure people as best I can to DON'T PANIC that things will be OK.  EV7 willG be FANTASTIC.  And when EV7 finally grows long in the tooth, we will bepF shipping IA64 systems - some perhaps not as fast, but I'll wager a lot cheaper.  K >Also remember that those employees are only told about the WINs, not about  theuK >LOSSES. They may not even be aware of cases when Compaq sales critters are ( >pitching Windows to existing VMS sites.  J Of course we aren't told when a salesman tries to sell Windows.  How wouldL we get that visibility?  What we can see is that the VMS sales trends are inJ general following along lines that show a general downturn of the economy,I and then a return to growth.  Our large customers and ISV's seem to be OKsI with IA64.  We seem to be getting new customers faster than we are losing 	 old ones.a  K BTW - we *do* see losses when it was a VMS account that was being worked bynJ one of our VMS field specialists... which is also where we see most of our "win" data as well.m   ------------------------------  $ Date: Wed, 3 Apr 2002 13:36:35 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>e2 Subject: Re: Predictions - just for the hell of itP Message-ID: <Pine.LNX.4.50.0204031259280.30061-100000@shiva0.cac.washington.edu>  $ On Wed, 3 Apr 2002, Bill Todd wrote:J > Those are just the biggies that come to mind off hand.  Feel free to add > more.o  E 7. Increasingly lackadasical approach to software quality.  ADV FS on J Tru64 being an all-too-painful example.  Ever discover what happens to theJ reliability of your ADVFS filesystem once you cross a particular threshold in size?  
 -- Mark --   http://staff.washington.edu/mrcSF Science does not emerge from voting, party politics, or public debate.   ------------------------------  $ Date: Wed, 3 Apr 2002 13:58:05 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>e2 Subject: Re: Predictions - just for the hell of itP Message-ID: <Pine.LNX.4.50.0204031342090.30061-100000@shiva0.cac.washington.edu>  # On Wed, 3 Apr 2002, JF Mezei wrote:, > Mark Crispin wrote:5[ > > > Ironic that deemphasizing VMS has resulted in Digital going from #2 down to oblivion.oB > > So did the public attitudes of Digital employees, such as Fred > > Kleinsorge's postings.K > For as much as Mr Kleinsorge hates me, I do not think that he can be made  > responsible for VMS's demise.   I Not directly; but by calling customers "morons" in public he demonstratessF remarkable indiscretion, particularly in doing so from a dec.com email address.  B Unfortunately, this same attitude problem was exhibited by DigitalI employees in the 1980s.  At DECUS symposia at the time, Digital employeesbF stated that "only poor programmers" need to edit files larger than 64KF (Rainbow editor's 64K file size limit), need to be able to splice in aF debugger on a process that got an execution fault, need something likeI CTRL/T to monitor the PC of a running process, need other networking thant DECnet, etc.  G In other words, anyone who wanted something that Digital didn't deliverj. (and/or didn't want to deliver) was a "moron".  J One by one, the DEC employees who didn't think that way left Digital; they: were made so thoroughly miserable that they couldn't stay.  
 -- Mark --   http://staff.washington.edu/mrcsF Science does not emerge from voting, party politics, or public debate.   ------------------------------  $ Date: Wed, 3 Apr 2002 14:19:35 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>o2 Subject: Re: Predictions - just for the hell of itO Message-ID: <Pine.LNX.4.50.0204031405020.2560-100000@shiva0.cac.washington.edu>m  * On Wed, 3 Apr 2002, Fred Kleinsorge wrote:A > >So did the public attitudes of Digital employees, such as Fredw > >Kleinsorge's postings.a$ > Get a life.  I didn't do anything.  D Calling customers "morons" in public from a dec.com email address is@ certainly doing something.  It demonstrates an attitude problem.  * >  I'm sorry you are still pissed a couple > decades later.  G I'm not pissed.  I'm thoroughly enjoying watching the demise of VMS ands" VMS bigots crying into their beer.  $ > The simple truth is, regardless ofH > the reasons for killing the DEC-20, it was meaningless to the eventualJ > success and subsequent failure of DEC. DEC grew to #2 on the strength of	 > VAX/VMSt  A I see that you are ignorant of history as well as being arrogant.u  > DEC was a success, and had become #2, long before VMS existed.  H DEC was built on the success of the 8, the 10/20, and especially the 11.I The 18-bit systems, culminating in the 15, played a part too in the earlynG years; the other systems would not have happened if the 4, 7, and 9 had < flopped, and the tiger team on the 15 was paying for itself.  J VMS was the beneficiary of DEC's earlier successes; but unlike the earlierI systems VMS failed to build upon those successes.  Yes, Digital sold many1H VAX/VMS systems after the demise of the 10/20 in 1983.  But just 5 yearsF later, it was clear to everybody that Digital was dying.  Its products5 were widely perceived as overpriced and poor quality.e  I Any number of organizations within Digital tried to save the company, butrJ in the end to no avail because the underlying problem was never addressed.  
 -- Mark --   http://staff.washington.edu/mrcyF Science does not emerge from voting, party politics, or public debate.   ------------------------------  % Date: Wed, 03 Apr 2002 18:00:16 -0500m- From: JF Mezei <jfmezei.spamnot@videotron.ca>d2 Subject: Re: Predictions - just for the hell of it+ Message-ID: <3CAB895B.D0AD917@videotron.ca>m   Mark Crispin wrote:aJ > VAX/VMS systems after the demise of the 10/20 in 1983.  But just 5 yearsH > later, it was clear to everybody that Digital was dying.  Its products7 > were widely perceived as overpriced and poor quality.i    G Bet you that if DEC had kept the PDP-11, the PDP-11 would have remainedeM overpriced and DEC would have ignored its new competitors the same way it dide
 with VMS.   H It is ironic that DEC's success was based on making computing affordableN compared to the big guys like IBM, but when someone else started to make theirN machines "more" affordable, DEC refused to foloow suit because it wanted to be	 like IBM.t   ------------------------------  $ Date: Wed, 3 Apr 2002 14:53:57 -0800# From: "Tom Linden" <tom@kednos.com> 2 Subject: RE: Predictions - just for the hell of it9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEPPEKAA.tom@kednos.com>i   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]) > Sent: Wednesday, April 03, 2002 3:00 PM  > To: Info-VAX@Mvb.Saic.Comm4 > Subject: Re: Predictions - just for the hell of it >s >E > Mark Crispin wrote:lL > > VAX/VMS systems after the demise of the 10/20 in 1983.  But just 5 yearsJ > > later, it was clear to everybody that Digital was dying.  Its products9 > > were widely perceived as overpriced and poor quality.o >l >lI > Bet you that if DEC had kept the PDP-11, the PDP-11 would have remained ? > overpriced and DEC would have ignored its new competitors thes > same way it did* > with VMS.s >eJ > It is ironic that DEC's success was based on making computing affordableB > compared to the big guys like IBM, but when someone else started > to make theirhC > machines "more" affordable, DEC refused to foloow suit because itr > wanted to be > like IBM.. > 8 Had they been like IBM they would still be around today.   ------------------------------  # Date: Wed, 03 Apr 2002 23:06:46 GMTe From: Doc <doc@laughing.com>2 Subject: Re: Predictions - just for the hell of it0 Message-ID: <slrnaan2og.c0l.doc@george.home.org>  P On Wed, 3 Apr 2002 11:28:45 -0500, Fred Kleinsorge <kleinsorge@star.zko.dec.com>  wrote:o+ > yet-another-one-of-these-useless-threads.o > H > Not a single one of these inane dissertations that were spammed acrossJ > groups that included alt.sys.pdp10 had any other objective than to wasteM > peoples time, and continue some 20 year old argument that isn't really even I > interesting anymore, no matter how many peoples feelings were hurt thati# > there pet architecture was tubed.i  G   As a completely distanced bystander, I have to interject here.  In anaC earlier post you claimed that this "troll" would attract 300 posts.aG Whether or not the 20-year argument is *productive* may be in question,s: but you yourself have proved pretty conclusively that it's *interesting*.   	Doc   ------------------------------  $ Date: Wed, 3 Apr 2002 17:39:03 -0600$ From: "Art Beane" <beane@petris.com>2 Subject: RE: Predictions - just for the hell of it7 Message-ID: <004201c1db68$bd2f9b20$352810ac@petris.com>u  < US$0.02 on contributing to the decline of 36 bit products...  H Until about 1983 or -4, 36-bit machines were critical to AI development.E DEC 10s and 20s had almost all the market until Xerox, Symbolics, andyD LISP Machines LISP processors came on the market. Software on all of@ these systems was based on list processing, where a list elementD consisted of two pointers (the current and next objects). The 36 bitA machines were very powerful list processors because both pointers.; (18-bit physical addresses) fit into a single machine word.a  F Unfortunately, real world problems grew beyond an 18-bit address spaceF about that same time. Rule based applications (like XCON) in languagesD like OPS5 ran out of space and ports to 32-bit address spaces becameE financially imperative/feasible. The early 32-bit LISPs were not veryeC fast, but the address space relief more than made up for speed. ThenG native OPS5 compiler for VMS solved the performance issues. Work prettyw much ended on 36-bit machines.  ? Since DEC was heavily invested in AI at the time, pressure (akaeD "funding") was placed on several universities (Carnegie Mellon, MIT,> Edinburgh, etc.) to port languages and tools to VAX. The firstH implementation of Common LISP was on VAX, and the ports of InterLISP and1 PROLOG all moved to solve the performance issues.n  2 TI even built a 32-bit LISP machine, the Explorer.  H While LISP machines have gone the way of 36-bit machines, the AI problemH solving techniques have not. The OPS compiler was rewritten in C (OPS83)- and was still in use as late as mid-2000 (seei4 http://www.computer.org/tkde/tk2000/k0391abs.htm and> http://www.cs.uh.edu/Defenses/miminy.html). A java derivative," CommonRules is currently availableE (http://www.alphaworks.ibm.com/tech/commonrules) with XML extensions.e  G So, while the machines may not live on, the concepts certainly do, kinda0 of like a page out of James Burkes' Connections.   Art Beane (ebd 76-95)t Petris Technology, Inc.d (713) 403-8423   ------------------------------  $ Date: Wed, 3 Apr 2002 15:22:44 -0800+ From: Mark Crispin <mrc@CAC.Washington.EDU>,2 Subject: Re: Predictions - just for the hell of itO Message-ID: <Pine.LNX.4.50.0204031521220.6562-100000@shiva0.cac.washington.edu>-  # On Wed, 3 Apr 2002, JF Mezei wrote:1I > Bet you that if DEC had kept the PDP-11, the PDP-11 would have remained O > overpriced and DEC would have ignored its new competitors the same way it didM > with VMS.s  H I wouldn't have wanted to take you up on that bet.  I'd rather find some sucker who'd bet the other way!b  J > It is ironic that DEC's success was based on making computing affordableP > compared to the big guys like IBM, but when someone else started to make theirP > machines "more" affordable, DEC refused to foloow suit because it wanted to be > like IBM.     Ironic yes, but also deeply sad.  H Also, it was not DEC that "refused to follow suit".  It was Digital.  To- some of us, the difference is important!  :-)7  
 -- Mark --   http://staff.washington.edu/mrc F Science does not emerge from voting, party politics, or public debate.   ------------------------------   Date: 3 Apr 2002 23:44:41 GMTe( From: peter@taronga.com (Peter da Silva)2 Subject: Re: Predictions - just for the hell of it2 Message-ID: <a8g459$1n1a$1@citadel.in.taronga.com>  C In article <coJq8.215555$2q2.19050029@bin4.nnrp.aus1.giganews.com>,a) Bill Todd <billtodd@metrocast.net> wrote: K >rather by engineering considerations:  RISC seemed a better bet for future M >performance advances than CISC (over a dozen years later the success of IA32 J >may call that assessment into some question, but it certainly seemed true  F The 386 is not a classical CISC instruction set, and in fact there areF many design decisions in the 386 that are shared with the classic RISCG model... such as the load-store architecture (which makes a lot of hightC performance optimizations easier because you only have one stall to-H access memory per instruction... for most instructions), whereas the VAXH is almost the archetype of a CISC, with its extremely regular and human-J friendly instruction set that pretty much requires a just-in-time compilerH in hardware to convert the complex VAX instructions into a set of easily0 pipelined and reordered load-store instructions.  I Back when the Alpha project was started it was not at all clear that thisoI was possible without superhuman efforts... and it may well be argued thatwG it's still not possible without superhuman efforts: it just became costs< effective for intel and AMD to make that kind of effort. :->   -- o@ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)v   ------------------------------  % Date: Wed, 03 Apr 2002 18:55:47 -0500o- From: JF Mezei <jfmezei.spamnot@videotron.ca>t2 Subject: Re: Predictions - just for the hell of it, Message-ID: <3CAB9683.511D08A3@videotron.ca>   Mark Crispin wrote:tJ > Also, it was not DEC that "refused to follow suit".  It was Digital.  To/ > some of us, the difference is important!  :-)n  H Disagree. Digital's downfall did begin during Ken O's reign. Palmer just accelerated it.e   ------------------------------  # Date: Wed, 03 Apr 2002 23:54:57 GMTd* From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Predictions - just for the hell of itA Message-ID: <lDMq8.17433$TG6.2559705@bin5.nnrp.aus1.giganews.com>d  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3CAB9683.511D08A3@videotron.ca... > Mark Crispin wrote:'L > > Also, it was not DEC that "refused to follow suit".  It was Digital.  To1 > > some of us, the difference is important!  :-)e >mJ > Disagree. Digital's downfall did begin during Ken O's reign. Palmer just > accelerated it.l  K Not sure what you're trying to say above:  the change to 'digital' occurred5H long before Palmer appeared, but did roughly coincide with the change inJ corporate attitude.  So there's really nothing to disagree with Mark about here.p   - bill   ------------------------------  # Date: Wed, 03 Apr 2002 23:58:58 GMTs* From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Predictions - just for the hell of itC Message-ID: <6HMq8.217264$2q2.19251258@bin4.nnrp.aus1.giganews.com>c  5 "Peter da Silva" <peter@taronga.com> wrote in messagea, news:a8g459$1n1a$1@citadel.in.taronga.com...E > In article <coJq8.215555$2q2.19050029@bin4.nnrp.aus1.giganews.com>, + > Bill Todd <billtodd@metrocast.net> wrote:hF > >rather by engineering considerations:  RISC seemed a better bet for futureJ > >performance advances than CISC (over a dozen years later the success of IA32L > >may call that assessment into some question, but it certainly seemed true >pH > The 386 is not a classical CISC instruction set, and in fact there areH > many design decisions in the 386 that are shared with the classic RISCI > model... such as the load-store architecture (which makes a lot of high E > performance optimizations easier because you only have one stall tohJ > access memory per instruction... for most instructions), whereas the VAXJ > is almost the archetype of a CISC, with its extremely regular and human-L > friendly instruction set that pretty much requires a just-in-time compilerJ > in hardware to convert the complex VAX instructions into a set of easily2 > pipelined and reordered load-store instructions. >iK > Back when the Alpha project was started it was not at all clear that thismK > was possible without superhuman efforts... and it may well be argued thateI > it's still not possible without superhuman efforts: it just became costt> > effective for intel and AMD to make that kind of effort. :->  H Without having gone into the detail you provided two paragraphs above, IJ though your last paragraph above was pretty much what I'd said (though you snipped part of it).   - bill   ------------------------------  # Date: Thu, 04 Apr 2002 00:08:11 GMTs* From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Predictions - just for the hell of itC Message-ID: <LPMq8.404375$uv5.34168847@bin6.nnrp.aus1.giganews.com>d  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message% news:3CAB895B.D0AD917@videotron.ca...t > Mark Crispin wrote: L > > VAX/VMS systems after the demise of the 10/20 in 1983.  But just 5 yearsJ > > later, it was clear to everybody that Digital was dying.  Its products9 > > were widely perceived as overpriced and poor quality.a >e >eI > Bet you that if DEC had kept the PDP-11, the PDP-11 would have remainedtK > overpriced and DEC would have ignored its new competitors the same way ith dide > with VMS.o  B By the mid-'80s the 11 was no longer over-priced:  you could buy aG ('Micro-11'?) RT or RSX or RSTS F11 (even J11?) -based system for undereL $10K, and given the superiority in hardware and software to a PC this wasn'tL unreasonable (remember, a decent PC cost around $3K back then).  It would beD a while yet before DEC learned how to make PC-comparable hardware atL PC-comparable prices (the Professional workstations were sort of betwixt and' between), but that's a different issue.n   >aJ > It is ironic that DEC's success was based on making computing affordableJ > compared to the big guys like IBM, but when someone else started to make their J > machines "more" affordable, DEC refused to foloow suit because it wanted to bet > like IBM.c  L DEC really did try, first with the PC efforts (which admittedly it attemptedJ to differentiate such that they wouldn't compete with higher-margin 'real'K 11s) and then with the 'real' 11.  But it hadn't yet learned how to produce0I low-quality products at commodity prices (as its early efforts to producek% PC-compatibles demonstrated as well).m   - bill   ------------------------------  # Date: Thu, 04 Apr 2002 00:11:35 GMTt* From: "Bill Todd" <billtodd@metrocast.net>2 Subject: Re: Predictions - just for the hell of itB Message-ID: <XSMq8.102948$VJ1.8722148@bin3.nnrp.aus1.giganews.com>  8 "Mark Crispin" <mrc@CAC.Washington.EDU> wrote in messageI news:Pine.LNX.4.50.0204031405020.2560-100000@shiva0.cac.washington.edu...p   ...a  @ > DEC was a success, and had become #2, long before VMS existed.  % To forestall some obvious rejoinders:D  H The point at which I remember DEC becoming '#2' was when it passed HP inL total revenue, some time in the early '80s.  Of course, HP had major revenueC from non-computer sources, so DEC arguably became the #2 *computer*n" manufacturer at some earlier date.   - bill   ------------------------------   Date: 4 Apr 2002 00:42:52 GMT ( From: peter@taronga.com (Peter da Silva)2 Subject: Re: Predictions - just for the hell of it2 Message-ID: <a8g7ic$1orl$1@citadel.in.taronga.com>  C In article <6HMq8.217264$2q2.19251258@bin4.nnrp.aus1.giganews.com>,t) Bill Todd <billtodd@metrocast.net> wrote:dI >Without having gone into the detail you provided two paragraphs above, IsK >though your last paragraph above was pretty much what I'd said (though you, >snipped part of it).-  F I'm just addressing the myth that "because intel made the 386 run fastG anyone can make anything run fast". There's two problems with that: the G one I noted in my second paragraph and you had commented on, that IntelsH isn't "anyone"; and the more important part that people still don't seemI to understand, which is that for all its obvious and horrid flaws the x86nK architecture is better designed to accept '90s-era performance enhancements , than any classic CISC like the VAX or 68000.  ; Which is why Apple isn't shipping iMacs with 680x0s inside.r   --  @ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)b   ------------------------------   Date: 3 Apr 2002 16:50:59 -0800n. From: quodling@bigpond.net.au (Peter Quodling)2 Subject: Re: Predictions - just for the hell of it= Message-ID: <7106a72f.0204031650.219cafd3@posting.google.com>r  a Paul Repacholi <prep@prep.synonet.com> wrote in message news:<87sn6dsxo2.fsf@prep.synonet.com>...x/ > "Main, Kerry" <Kerry.Main@Compaq.com> writes:t > H > > >>> As for HP buying into the Compaq professional services business,F > > it literally doesn't exist anymore. They (Compaq) have had massiveG > > layoffs and are rejecting new business. I think the few that remainaE > > in senior positions, are posturing for as comfortable a fall froms > > grace as possible.<<<  >  m' > > Wow, where did that fud come from? s > ? > It came from some one who was with DEC 20 years ago. You know0! > the Pak Generater? He wrote it.e  ? Thanks for the vote of support, Reptile, but I didn't write the A Pakgenerator. That was some contract work, and one of the ugliestrA kludges around. I was however, involved in LMF Development in VMSnD Engineering for a couple of years. Those were some of the best yearsD of my working life, working with Visionaries and brilliant engineers= like Greg Robert, Bob Wyman, Marty Jack, Andy Goldstein, Fred-  Kleinsorge and many many others.  C The key point here, is however, that irrespective of history or thet@ future, Compaq (and HP) are now making some very stupid business
 decisions.  F They are rejecting large amounts of business, while trying to buy intoE other customers. HP is trying to poach business of CPQ, which robbing B peter to pay paul. They are rejecting business and losing existingF business, not just in Australia, but in at least 4 different countries8 that I am aware of (The post digital/compaq networks are; extensive...). Some of their business practices are runningeB dangerously close to litigation, and a number the people that have? left, have quit on ethical grounds, rather than being laid off.B  D A downturn is a downturn, but when frontlogs of 4-6 months of agreedE to work, are being cancelled, and staff are being laid off, all over.-  @ And to top it off, the executive management are acting with lessA decorum than my 10 year old son. There has been no clear plan putjE forward by CPQ and HP Management, as to what lives and what dies, ande% why. There is not even a strong plan.-  C Sadly, I believe that we are at the hands of a number of ExecutivesnA that believe that "size" is everything. I would much rather see ajC number of $1-5 Bn entities, that understood their market niches andnD served them well, than a $30bn plus (or less) monolith, that doesn't# even have a stated clear direction.l  A I am a Compaq Stockholder, and Its now not even worth the time orlE effort to divest myself of them. I keep them as a reminder not to put  my trust in others.1  E Getting back to the original issue of prediction of compaq futures. IeA tend to agree, that the Itaniums will continue to be a non event. D There is a point at sometime in the not to far distant future, whereD CPQ/HP will need to drop all possibility of Continuing EV8/9, and goF with Itanium. I hope that the have the basic business sense to be sure> that Itanium can cut it, before throwing out the baby with the
 bathwater.   Qo   ------------------------------  $ Date: Wed, 3 Apr 2002 16:50:56 -0800# From: "Tom Linden" <tom@kednos.com> 2 Subject: RE: Predictions - just for the hell of it9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEADELAA.tom@kednos.com>h   > -----Original Message-----1 > From: Peter da Silva [mailto:peter@taronga.com].) > Sent: Wednesday, April 03, 2002 4:43 PMe > To: Info-VAX@Mvb.Saic.Como4 > Subject: Re: Predictions - just for the hell of it >  > E > In article <6HMq8.217264$2q2.19251258@bin4.nnrp.aus1.giganews.com>,a+ > Bill Todd <billtodd@metrocast.net> wrote: K > >Without having gone into the detail you provided two paragraphs above, IrB > >though your last paragraph above was pretty much what I'd said 
 > (though you  > >snipped part of it).e > H > I'm just addressing the myth that "because intel made the 386 run fastI > anyone can make anything run fast". There's two problems with that: the I > one I noted in my second paragraph and you had commented on, that InteloJ > isn't "anyone"; and the more important part that people still don't seemK > to understand, which is that for all its obvious and horrid flaws the x86oA > architecture is better designed to accept '90s-era performance   > enhancements. > than any classic CISC like the VAX or 68000.  + Rubbish.  Your previous was also inaccurate    > = > Which is why Apple isn't shipping iMacs with 680x0s inside.n >  > --  B > Rev. Peter da Silva, ULC.	                                 WWFD? > H > "Be conservative in what you generate, and liberal in what you accept" > 	-- Matthew 10:16 (l.trans)  >    ------------------------------  % Date: Wed, 03 Apr 2002 18:17:09 -0700 + From: Ben Franchuk <bfranchuk@jetnet.ab.ca>p2 Subject: Re: Predictions - just for the hell of it, Message-ID: <3CABA995.FC2ADFA4@jetnet.ab.ca>   Bill Todd wrote: > < > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message' > news:3CAB895B.D0AD917@videotron.ca...N > > Mark Crispin wrote: N > > > VAX/VMS systems after the demise of the 10/20 in 1983.  But just 5 yearsL > > > later, it was clear to everybody that Digital was dying.  Its products; > > > were widely perceived as overpriced and poor quality.l > >r > >sK > > Bet you that if DEC had kept the PDP-11, the PDP-11 would have remained M > > overpriced and DEC would have ignored its new competitors the same way its > did 
 > > with VMS.e > D > By the mid-'80s the 11 was no longer over-priced:  you could buy aI > ('Micro-11'?) RT or RSX or RSTS F11 (even J11?) -based system for undertN > $10K, and given the superiority in hardware and software to a PC this wasn'tN > unreasonable (remember, a decent PC cost around $3K back then).  It would beF > a while yet before DEC learned how to make PC-comparable hardware atN > PC-comparable prices (the Professional workstations were sort of betwixt and) > between), but that's a different issue.2 >  > >aL > > It is ironic that DEC's success was based on making computing affordableL > > compared to the big guys like IBM, but when someone else started to make > their L > > machines "more" affordable, DEC refused to foloow suit because it wanted > to bek
 > > like IBM.  > N > DEC really did try, first with the PC efforts (which admittedly it attemptedL > to differentiate such that they wouldn't compete with higher-margin 'real'M > 11s) and then with the 'real' 11.  But it hadn't yet learned how to producePK > low-quality products at commodity prices (as its early efforts to produce0' > PC-compatibles demonstrated as well).   H What stands out to me was the fact the fact that DEC's PC did not come aD floppy disk format program. You had to Buy DEC's pre-formated disks., The weird floppy too I bet cost lots of $$$.   --  % Ben Franchuk - Dawn * 12/24 bit cpu * + www.jetnet.ab.ca/users/bfranchuk/index.htmle   ------------------------------  % Date: Wed, 03 Apr 2002 20:52:51 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>d2 Subject: Re: Predictions - just for the hell of it, Message-ID: <3CABB1EA.A5FA11F6@videotron.ca>   Peter da Silva wrote: K > to understand, which is that for all its obvious and horrid flaws the x86.M > architecture is better designed to accept '90s-era performance enhancementso. > than any classic CISC like the VAX or 68000.  D In your opinion, how much longer can the 8086 move forwards and keep respectable performance ?,A Can its performance increase at about the same rate as the IA64 ?    ------------------------------   Date: 4 Apr 2002 02:37:01 GMTc( From: peter@taronga.com (Peter da Silva)2 Subject: Re: Predictions - just for the hell of it2 Message-ID: <a8ge8d$1sfg$1@citadel.in.taronga.com>  , In article <3CABB1EA.A5FA11F6@videotron.ca>,/ JF Mezei  <jfmezei.spamnot@videotron.ca> wrote:eE >In your opinion, how much longer can the 8086 move forwards and keeph >respectable performance ?  J As long as Intel wants it to. Especially since they're apparently going toE be using similar implementation techniques in the IA64 to convert its G baroque instruction set to something EV-8-ish, the exposed ISA of IntelrD CPUs (possibly excluding Xscale) seems likely to become more or less irrelevant.   G But, basically, I see the only end to the x86 at this point a politicals: and marketing choice by Intel. Like CHomPaq and the Alpha.  B >Can its performance increase at about the same rate as the IA64 ?  I I'd give reasonable odds that it'll increase faster. Because that's wheresD the money is. Well, once the IA64 gets past the "awful to only kinda sucking" stage.t  H One intriguing endgame is a common 64-bit core using EV-8 technology andI an internal EV-8-oid instruction set, with a front end that converts IA32e: or x86-64 or IA64 into a common opcode stream for the CPU.   -- s@ Rev. Peter da Silva, ULC.	                                 WWFD?  F "Be conservative in what you generate, and liberal in what you accept" 	-- Matthew 10:16 (l.trans)    ------------------------------  % Date: Wed, 03 Apr 2002 21:49:56 +0200,) From: labadie <labadie.gerard@wanadoo.fr>eG Subject: Re: Relative invulnerability of VMS to buffer-overflow attacks * Message-ID: <3CAB5CE4.735E5F80@wanadoo.fr>   Keith Parris wrote:t ...jG May I say that I am tempted to save all the posts from Keith Parris, asD< they are always highly valuable, as I learn much each time ?! Of course, google does it for me.    Many thanks Keith    Grard   ------------------------------  $ Date: Wed, 3 Apr 2002 14:47:20 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>eG Subject: RE: Relative invulnerability of VMS to buffer-overflow attacks2T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4016CED0E@kaoexc01.americas.cpqcorp.net>   Keith,   A definate "keeper".   Muchas gracias,2   :-)b  
 Kerry Main Senior ConsultantJ Compaq Canada Corp.m Professional Services  Voice: 613-592-46609 Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----; From: Keith Parris [mailto:KeithParris_NOSPAM@yahoo.com]=20s Sent: April 3, 2002 12:15 PM To: Info-VAX@Mvb.Saic.ComiC Subject: Relative invulnerability of VMS to buffer-overflow attacksa    D Some here have contended that because TCP/IP Services for OpenVMS isF based on Tru64 Unix code, it is thus subject to the same level of risk9 of buffer-overflow exploits as any Unix system out there.t  G After a bit of investigation, I've discovered that VMS on Alpha appears-E to be immune to these common smash-the-stack buffer overflow attacks.l  G To understand why, first one must understand how common buffer-overfloweF attacks work.  (A classic paper on such attacks is "Smashing the StackG for Fun And Profit" written by a hacker who goes by the name Aleph One.c You can read it atD http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/profit.html)  G A buffer-overflow exploit is done by passing an argument that is largeri> than the buffer size to code which fails to check its size.=20G The data is all stored, resulting in overwriting some memory beyond the2E end of the buffer.  Hackers know that C compilers often allocate dataeH space for buffers on the stack, and part of the data area overwritten onD the stack includes the return address in the call frame.  The hackerB writes a return address that points to his own code, which is also1 included in the area overwritten on the stack.=20 H The function then returns to his code instead of to the calling routine.F His malicious code then takes some dastardly action, like starting the. Unix shell and executing an arbitrary command.  H For a buffer-overflow exploit to succeed, then, the hacker must know theE address size of the the target architecture (for the return address), G the format of the stack frame used by the architecture and the compilereF (to know where to put that return address), the instruction set of theD target architecture (so he can create his small program), and enoughG about the innards of the operating system for his program to be able toc) do something useful once it is executing.   E Attacks most commonly target Windows, or Solaris or other common UnixdC variants, and because the attack must be so specific to a platform,tF these wouldn't affect VMS, because it has a different instruction set,F stack frame format, and so forth.  While that dramatically reduces theH statistical probability of an attack succeeding on VMS in practice, that< alone doesn't rule out the possibility of an attack tailored specifically for VMS on Alpha.  F Here is where excellent and fortuitous engineering design comes to theG rescue.  The Alpha memory management architecture provides some bits inhA the Page Table Entries (PTEs) that control what type of access is E allowed to memory.  For example, a read-only page can be protected bylD having the Fault-On-Write bit set, and any attempt to write the pageE causes a fault and results in a memory access violation error.  AlphadF also has a Fault-On-Execute bit, designed to prevent an errant program= from jumping off into the weeds and trying to execute data asdD instructions.  On Alpha/VMS, the user stack is mapped with PTEs thatE have the Fault-On-Execute bit set, so any attempt to branch into data G area on the stack results in an access violation, and the process dies.o  H So Alpha VMS is immune to common stack-smashing buffer-overflow attacks.  G While any code that fails to check data lengths against buffer sizes isiF arguably broken, and needs to be fixed, and Compaq has been doing thisD to TCP/IP code as buffer-overflow bugs are identified, such bugs are< much less critical on Alpha VMS compared with less-protected implementations.. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  % Date: Wed, 03 Apr 2002 21:51:22 +0200m- From: Didier Morandi <Didier.Morandi@Free.fr>tG Subject: Re: Relative invulnerability of VMS to buffer-overflow attacks'' Message-ID: <3CAB5D3A.6F7FF332@Free.fr>t  O May I say that for a piece of executable code embedded in an overflow buffer tocO be executed with VMS, it needs to either spawn a subprocess in which it will be-M self-image activated, or call a lib$do_command RTL service or other mechanismcQ for VMS to execute an image which binary code will be partly in memory somewhere.2  O I personally prefer to believe that this kind of programming is just unfeasibleED with VMS. But maybe we could ask Ruth (Goldenberg) or Larry (Kenah).   D.   labadie wrote: >  > Keith Parris wrote:u > ...aI > May I say that I am tempted to save all the posts from Keith Parris, aso> > they are always highly valuable, as I learn much each time ?# > Of course, google does it for me.s >  > Many thanks Keiths >  > Grard   ------------------------------  % Date: Wed, 03 Apr 2002 15:22:28 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>tG Subject: Re: Relative invulnerability of VMS to buffer-overflow attacks5, Message-ID: <3CAB646C.91F7DC3B@videotron.ca>  # Re: code that can branch to "data".   M Mr Parris has stated that on VMS, it is possible to protect memory from being<> executed so that one couldn't branch to a buffer for instance.  H Is 100% sure that all VMS compilers will generate code that enable thoseN protections, notably a program's inability to modify its own code or inability' to execute code residing on the stack ?p   ------------------------------  $ Date: Wed, 3 Apr 2002 16:43:39 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>hG Subject: Re: Relative invulnerability of VMS to buffer-overflow attacksd3 Message-ID: <iOKq8.1834$fL6.37310@news.cpqcorp.net>n  J There are a lot of issues in making data executable.  Ask the Java people.L With enough knowledge could you do it?  Maybe, but most likely along the wayI you'll stumble over problems that require a privledged operation to do it H outside of a formal system interface... or a "can't get there from here" problem.      = JF Mezei wrote in message <3CAB646C.91F7DC3B@videotron.ca>... $ >Re: code that can branch to "data". >nH >Mr Parris has stated that on VMS, it is possible to protect memory from being-? >executed so that one couldn't branch to a buffer for instance.u >iI >Is 100% sure that all VMS compilers will generate code that enable those E >protections, notably a program's inability to modify its own code orm	 inabilityR( >to execute code residing on the stack ?   ------------------------------   Date: 3 Apr 2002 17:44:03 -0800K( From: bob@instantwhip.com (Bob Ceculski)G Subject: Re: Relative invulnerability of VMS to buffer-overflow attackst= Message-ID: <d7791aa1.0204031744.7b6b1718@posting.google.com>e  v KeithParris_NOSPAM@yahoo.com (Keith Parris) wrote in message news:<6ec1251e.0204030914.7143730f@posting.google.com>...F > Some here have contended that because TCP/IP Services for OpenVMS isH > based on Tru64 Unix code, it is thus subject to the same level of risk; > of buffer-overflow exploits as any Unix system out there.  > A > After a bit of investigation, I've discovered that VMS on AlphagF > appears to be immune to these common smash-the-stack buffer overflow
 > attacks. > 9 > To understand why, first one must understand how common D > buffer-overflow attacks work.  (A classic paper on such attacks isF > "Smashing the Stack for Fun And Profit" written by a hacker who goes, > by the name Aleph One.  You can read it atF > http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/profit.html) > B > A buffer-overflow exploit is done by passing an argument that isE > larger than the buffer size to code which fails to check its size. nE > The data is all stored, resulting in overwriting some memory beyond F > the end of the buffer.  Hackers know that C compilers often allocate@ > data space for buffers on the stack, and part of the data areaB > overwritten on the stack includes the return address in the callC > frame.  The hacker writes a return address that points to his ownsE > code, which is also included in the area overwritten on the stack.  A > The function then returns to his code instead of to the callingaE > routine.  His malicious code then takes some dastardly action, like-= > starting the Unix shell and executing an arbitrary command.  > F > For a buffer-overflow exploit to succeed, then, the hacker must knowA > the address size of the the target architecture (for the return F > address), the format of the stack frame used by the architecture and> > the compiler (to know where to put that return address), theH > instruction set of the target architecture (so he can create his smallH > program), and enough about the innards of the operating system for hisA > program to be able to do something useful once it is executing.e > G > Attacks most commonly target Windows, or Solaris or other common UnixdE > variants, and because the attack must be so specific to a platform,oH > these wouldn't affect VMS, because it has a different instruction set,H > stack frame format, and so forth.  While that dramatically reduces theE > statistical probability of an attack succeeding on VMS in practice,wC > that alone doesn't rule out the possibility of an attack tailored   > specifically for VMS on Alpha. > H > Here is where excellent and fortuitous engineering design comes to theF > rescue.  The Alpha memory management architecture provides some bitsF > in the Page Table Entries (PTEs) that control what type of access isG > allowed to memory.  For example, a read-only page can be protected by0F > having the Fault-On-Write bit set, and any attempt to write the pageG > causes a fault and results in a memory access violation error.  AlphacH > also has a Fault-On-Execute bit, designed to prevent an errant program? > from jumping off into the weeds and trying to execute data as F > instructions.  On Alpha/VMS, the user stack is mapped with PTEs thatG > have the Fault-On-Execute bit set, so any attempt to branch into datanC > area on the stack results in an access violation, and the processh > dies.e > A > So Alpha VMS is immune to common stack-smashing buffer-overflowl
 > attacks. > F > While any code that fails to check data lengths against buffer sizesF > is arguably broken, and needs to be fixed, and Compaq has been doingG > this to TCP/IP code as buffer-overflow bugs are identified, such bugstB > are much less critical on Alpha VMS compared with less-protected > implementations.0 > ----------------------------------------------0 > Keith Parris | parris at encompasserve dot org   do you understand this Andrew?   ------------------------------  % Date: Wed, 03 Apr 2002 20:50:59 -0500p2 From: rdeininger@mindspring.com (Robert Deininger)G Subject: Re: Relative invulnerability of VMS to buffer-overflow attacks J Message-ID: <rdeininger-0304022050590001@1cust61.tnt6.nashua.nh.da.uu.net>  = In article <d7791aa1.0204031744.7b6b1718@posting.google.com>, ) bob@instantwhip.com (Bob Ceculski) wrote:g     >do you understand this Andrew?p  < Now THAT's the funniest thing I've read here in a long time!   ------------------------------   Date: 3 Apr 2002 17:54:59 -0800k( From: bob@instantwhip.com (Bob Ceculski)G Subject: Re: Relative invulnerability of VMS to buffer-overflow attackse= Message-ID: <d7791aa1.0204031754.3a1bc775@posting.google.com>@  v KeithParris_NOSPAM@yahoo.com (Keith Parris) wrote in message news:<6ec1251e.0204030914.7143730f@posting.google.com>...F > Some here have contended that because TCP/IP Services for OpenVMS isH > based on Tru64 Unix code, it is thus subject to the same level of risk; > of buffer-overflow exploits as any Unix system out there.s > A > After a bit of investigation, I've discovered that VMS on AlphamF > appears to be immune to these common smash-the-stack buffer overflow
 > attacks. > H > Here is where excellent and fortuitous engineering design comes to theF > rescue.  The Alpha memory management architecture provides some bitsF > in the Page Table Entries (PTEs) that control what type of access isG > allowed to memory.  For example, a read-only page can be protected by F > having the Fault-On-Write bit set, and any attempt to write the pageG > causes a fault and results in a memory access violation error.  AlphafH > also has a Fault-On-Execute bit, designed to prevent an errant program? > from jumping off into the weeds and trying to execute data asaF > instructions.  On Alpha/VMS, the user stack is mapped with PTEs thatG > have the Fault-On-Execute bit set, so any attempt to branch into dataeC > area on the stack results in an access violation, and the process  > dies.I > A > So Alpha VMS is immune to common stack-smashing buffer-overflowe
 > attacks. > 0 > ----------------------------------------------0 > Keith Parris | parris at encompasserve dot org    C and I have a perfect example of this ... from process softwares web  site,sD versions of tcpware/multinet on vms were either not affected or gave access, violations ... care to reply to this Andrew?    ( SNMP Inquiry - Cert Advisory CA-2002-03 P --------------------------------------------------------------------------------  	 Question:I  D Are either MultiNet or TCPware affected by CERT Advisory CA-2002-03A in Many Implementations of the Simple Network Management Protocol-  (SNMP), dated February 12, 2002?   Answer:   F These SNMP vulnerabilities do NOT pose security risks for MultiNet andF TCPware. MultiNet V4.4A is not vulnerable to these SNMP issues at all.D MultiNet 4.3A and TCPware have minor problems with access violationsA (resulting in the SNMP process dying), but pose no security risk.dC Patches for MultiNet 4.3A and TCPware V5.5-3 are available from thesE TCPware ECO Database and the MultiNet ECO database. Use the followingt
 kit names:   MultiNet V4.3A: SNMP-020_A043e TCPware V5.5-3: SNMPD_V553P011   ------------------------------  # Date: Thu, 04 Apr 2002 00:02:11 GMT-( From: "konabear" <maurert@ameritech.net>4 Subject: Re: Seek information on FAXSR and VMS 7.3-1? Message-ID: <7KMq8.13404$k5.5027826@newssvr28.news.prodigy.com>g  , This is a multi-part message in MIME format.  + ------=_NextPart_000_0240_01C1DB42.0F6AB360s Content-Type: text/plain;e 	charset="iso-8859-1" + Content-Transfer-Encoding: quoted-printablee   Briony,t  G Doesn't FAXSR use VAX mail as the way to get data to the product?  If =eH you test FAXSR on 7.3-1 and find it doesn't work, you might be able to =? leave a small box behind at 7.1-2 and let is to the FAXSR work.,   Todd5   <Briony.Schreiber@metavante.com> wrote in message =e: news:OF446AAE8F.EEF7F462-ON86256B8E.00614D07@midata.com...  =   Does anyone know if FAXSR 4.1-027 will run on VMS 7.3-1?=20n  I   We are currntly running FAXSR 4.1-027 on Alpha VMS 7.1-2.  We will be =nH upgrading to VMS 7.3-1.  OMTOOL no longer supports their FAXSR product =J for VMS, and will not answer any questions on it for the VMS platform.   =    E   If you have tried to use this product on VMS 7.3-1, please let me =r know.=20       Thank you,     Briony Schreiber    Briony.Schreiber@metavante.com    + ------=_NextPart_000_0240_01C1DB42.0F6AB360s Content-Type: text/html; 	charset="iso-8859-1"r+ Content-Transfer-Encoding: quoted-printable,  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD>7 <META http-equiv=3DContent-Type content=3D"text/html; =  charset=3Diso-8859-1">8 <META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR> <STYLE></STYLE>i </HEAD>e <BODY bgColor=3D#ffffff>5 <DIV><FONT face=3DArial size=3D2>Briony,</FONT></DIV>f4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>H <DIV><FONT face=3DArial size=3D2>Doesn't FAXSR use VAX mail as the way = to get data=20F to the product?&nbsp; If you test FAXSR on 7.3-1 and find it doesn't = work, you=20F might be able to leave a small box behind at 7.1-2 and let is to the = FAXSR=20 work.</FONT></DIV>4 <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>2 <DIV><FONT face=3DArial size=3D2>Todd</FONT></DIV> <BLOCKQUOTE=20C style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =A3 BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">t   <DIV>&lt;<A=20   =rJ href=3D"mailto:Briony.Schreiber@metavante.com">Briony.Schreiber@metavante= .com</A>&gt;=20s   wrote in message <A=20   =2J href=3D"news:OF446AAE8F.EEF7F462-ON86256B8E.00614D07@midata.com">news:OF4=H 46AAE8F.EEF7F462-ON86256B8E.00614D07@midata.com</A>...</DIV><BR><FONT=20I   face=3Dsans-serif size=3D2>Does anyone know if FAXSR 4.1-027 will run =t	 on VMS=20rJ   7.3-1?</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>We are currntly =
 running=20G   FAXSR 4.1-027 on Alpha VMS 7.1-2. &nbsp;We will be upgrading to VMS =t	 7.3-1.=20eI   &nbsp;OMTOOL no longer supports their FAXSR product for VMS, and will =  not=20;   answer any questions on it for the VMS platform. &nbsp; =e </FONT><BR><BR><FONT=20sG   face=3Dsans-serif size=3D2>If you have tried to use this product on =f
 VMS 7.3-1,=20n>   please let me know.</FONT> <BR><BR><FONT face=3Dsans-serif = size=3D2><BR>Thank=20s   you,<BR><BR>Briony=20 J Schreiber<BR>Briony.Schreiber@metavante.com<BR></BLOCKQUOTE></FONT></BODY= ></HTML>  - ------=_NextPart_000_0240_01C1DB42.0F6AB360--S   ------------------------------  # Date: Thu, 04 Apr 2002 02:06:34 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")% Subject: Re: Selling: DS10L's NEW !!!u8 Message-ID: <00A0BEC2.C0FA630A@SSRL04.SLAC.STANFORD.EDU>  c In article <PFFuAy7he3eU@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: d >In article <uakq55msc44t57@news.supernews.com>, "Island (hpaq.net)" <dbturner@islandco.com> writes: >> In stock  >> s& >> DS10L New with 1 Yr Island Warranty >> 512MB Island Memory >> High Speed CDROM and Floppy >> Dual 10/100 Ethernetn >> Dual IDE  >> Dual Serial Portl >> o, >> $1899 per system  (ship weight is 30Lb's) >> yJ >> Or the same as above with 9GB SCSI Ultra 2 + Ctr and VMS Keyboard $2499 >oD >Things have gotten considerably better than when I used to complainH >about irrelevant PC-related hardware pitches here from Island Software.> >What have things come to when the only basis for complaint is >grammar...  >w* >> Biggy the memory for an additional $500 >t >...or lack thereof :-)c  I I think we could complain about the DS10L not actually running VMS, if we 
 wanted to.   -- s  O ===============================================================================t0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056lM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210,O ===============================================================================i   ------------------------------   Date: 3 Apr 2002 19:25:51 -0000n= From: Doc.Cypher <Use-Author-Supplied-Address-Header@[127.1]>f= Subject: Re: Spring Forward, Fall Back - unfortunately not :-o5 Message-ID: <20020403192551.4589.qmail@gacracker.org>m  F On Mon, 01 Apr 2002, Mark Berryman <Mark.Berryman@Mvb.Saic.Com> wrote:. >> Yes, there is a DTSS$PROVIDER_NTP module in% >> SYS$COMMON:[SYSHLP.EXAMPLES.DTSS].-I >> Mark, care to tell us which version of OpenVMS and TCP/IP services youaF >> are running? I have used the example program for many years, but itH >> broke with TCP/IP V5.0. I have discussed this with TCP/IP engineeringH >> and they provided an updated version of the program, which works with >> VMS V7.3 and TCP/IP v5.1. >l= >VMS V7.3 and Multinet V4.4.  I have systems running with thetG >DTSS$PROVIDER_NTP module that came with VMS V7.1 and some with the onec> >that came with VMS V7.3 (use the one from V7.3, it's better). >aI >I was unaware that these broke with any version of TCP/IP services, theyn >haven't broken with Multinet. >gF >Doing things the way I do them allows the VMS system to act as a timeC >server using both DTSS and XNTP to the entire corporation.  If youaI >simply want to sync your VMS system, I'd follow Hoff's advice and follow 	 >the FAQ.t   Bah! Humbug!  H Put the system on GMT and let the users look at a wristwatch to see what the local time is ;-)g     Doc. -- -6 The bigger the humbug, the better people will like it.K ~ Phineas Taylor Barnum.                              http://vmsbox.cjb.netn   ------------------------------  # Date: Thu, 04 Apr 2002 00:28:36 GMTF) From: rob.buxton@wcc.govt.nz (Rob Buxton)e6 Subject: Re: TCPIP: no new default route when IP is ON2 Message-ID: <3cab9de8.1195215438@news.wcc.govt.nz>  / On Wed, 03 Apr 2002 15:24:47 GMT, Tim Llewellynd' <tim.llewellyn@blueyonder.co.uk> wrote:    >  >h >Roy Omond wrote:e >> e >> Tim Llewellyn wrote:dC >> > I sincerely hope most of you are mystified by this as it meanse, >> > Bob The Builder hasn't escaped the UK !  B I think bob the builder came over with the barmy army to watch the cricket downunder.   >> t< >> Yeah, but as to the original problem wrt Bob the Builder: >> e >> Can He Fix It ? >> r >K< >No, but he can bodge it, going by the sorry state of things >in this country at present. >g >:-) >s > G >Sorry if you see the post I just canceled with a spell checker induced- >spelling error. >, >--   >tim.llewellyn@blueyonder.co.uk  >iG >* tim.llewellyn@cableinet.co.uk address will cease to work June 2002 *f   ------------------------------  % Date: Wed, 03 Apr 2002 20:41:01 -0500c2 From: rdeininger@mindspring.com (Robert Deininger)6 Subject: Re: TCPIP: no new default route when IP is ONJ Message-ID: <rdeininger-0304022041010001@1cust61.tnt6.nashua.nh.da.uu.net>  0 In article <3CAB18E8.BBE80B0E@blueyonder.co.uk>,% tim.llewellyn@blueyonder.co.uk wrote:n  ? >I sincerely hope most of you are mystified by this as it meansy( >Bob The Builder hasn't escaped the UK !  M Nope.  I saw some kind of Bob the Builder reference in a store here recently.    ------------------------------  # Date: Thu, 04 Apr 2002 01:53:47 GMTn3 From: sy18889@rabbit.fmr.com (Bradford J. Hamilton)s6 Subject: Re: TCPIP: no new default route when IP is ON/ Message-ID: <LmOq8.23$M3.126@news-srv1.fmr.com>   H My children (and I) have watched "Bob the Builder" on the Nick Jr. cable@ channel here in the USA.  The kids know the theme song by heart.   In article <rdeininger-0304022041010001@1cust61.tnt6.nashua.nh.da.uu.net>, rdeininger@mindspring.com (Robert Deininger) writes:i1 >In article <3CAB18E8.BBE80B0E@blueyonder.co.uk>,.& >tim.llewellyn@blueyonder.co.uk wrote: >n@ >>I sincerely hope most of you are mystified by this as it means) >>Bob The Builder hasn't escaped the UK !l >tN >Nope.  I saw some kind of Bob the Builder reference in a store here recently. Bradford J. Hamilton& MAPSbradhamilton@MAPSattbi.com		(home)& sy18889MAPS@rabbit.MAPSfmr.com		(work)  ; "All opinions that I express are my own, not my employer's"- "Lose the MAPS"-   ------------------------------  % Date: Wed, 03 Apr 2002 21:57:13 +0200B- From: Didier Morandi <Didier.Morandi@Free.fr>l= Subject: TCPIP: remove host from local table generates ACCVIO2' Message-ID: <3CAB5E98.1655A0BE@Free.fr>   O I made a mistake today and removed by accident the host name of an Alpha system9O from its TCPIP V5.1 local table (I "thought" I was sethosting on another systemPO where I was doing (destructive) tests, but the SETHOST was not here anymore :-(a  / I did a TCPIP SET NOHOST mynode.bla.bla.bla.coma  M TCPIP complained with a set of error messages about invalid record length andh other messages, then exited.  ? When doing any other TCPIP commands, it crashed with an ACCVIO.k  O I stopped TCPIP without problem, then redefined the host in the local database,o/ then restarted TCPIP and the problem went away.   	 Just FYI.n   D.   ------------------------------  $ Date: Wed, 3 Apr 2002 14:12:29 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>oN Subject: RE: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1E17@kaoexc01.americas.cpqcorp.net>   Alan  F >>> A number of us have tried this before. Indeed Kerry was actually aH Compaq member of the group. He just  ignored us and passed us on down to Marcello ..<<<  B Just to clarify, it was not me that ignored you and I am certainly; nowhere near the level where I could pass you down to RM ..    :-)   G And in fairness, MC passed you to the VP that the questions applied to. D If I were a VP and my CEO started answering questions which directlyG applied to my division, without me at least having a first crack at it, & I would be a tad miffed at the CEO.=20   Regards,  
 Kerry Main Senior Consultant  Compaq Canada Corp.t Professional Serviceso Voice: 613-592-4660x Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----/ From: Alan Greig [mailto:a.greig@virgin.net]=20m Sent: April 3, 2002 10:08 AM To: Info-VAX@Mvb.Saic.Com H Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64e    F On Tue, 02 Apr 2002 16:55:57 GMT, "John Smith" <a@nonymous.com> wrote:   >e >nJ >I have a favor to ask - post the personal e-mail addresses of Capella,=20H >Winckler, et al in this forum and we'll all flood their inboxes with=20G >our complaints. Why? Because there aren't enough good guys like you=20  >calling onc  & Michael.Capellas@compaq.spamremove.com4 Michael.Winkler@compaq.spamremove.com (might just be# mike.winkler@compaq.spamremove.com)e  D Surprisingly both read and sometimes even respond to personal email.H I've had responses from both in the past. However it is probably Carly's1 address you need right now and I don't know that.o   dhH >theirs don't listen to them, give us the contact info and we'll tell=20H >Capellas to his face. If he doesn't like what his customers are saying,   >he   B A number of us have tried this before. Indeed Kerry was actually aH Compaq member of the group. He just  ignored us and passed us on down to Marcello  B >can fix it, or quit and give the job to somebody who will fix it. >f >t >d: >"Main, Kerry" <Kerry.Main@Compaq.com> wrote in message=20H >news:BE56C50EA024184DAF48F0B9A47F5CF401AB1DF5@kaoexc01.americas.cpqcorp >.net. >..i >John, >dH >>>> It's almost like trying to get somebody from Compaq to sell you VMS0 >when you say you want a reliable web server.<<< >x >Hey, that's easy. >t< >CSWS, OSU or WASD .. And perhaps even Purveyor (right Bob?) >eH >CSWS offers Galaxy shared memory support and file system support for=20H >saving state information, apache$specifc and apache$common cluster file   >access etc. >dH >Put a rack of DS10's in place and change 1 file in apache$common and=20I >they automatically all take advantage of this as it is the same file.=20gG >For server specific files, put the file in apache$specific. Put two=20rH >racks in place for multi-site load balancing (one at each site) against  > >a multi-site, load balanced active-active clustered database. >  >Surely you knew this - right? > 	 >Regards,- >- >Kerry Main- >Senior Consultant >Compaq Canada Corp. >Professional Services >Voice: 613-592-4660 >Fax  :  819-772-7036l >Email: Kerry.Main@Compaq.com  >f >o >-----Original Message----- ) >From: John Smith [mailto:a@nonymous.com]a >Sent: April 1, 2002 3:35 PM >To: Info-VAX@Mvb.Saic.ComI >Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha=20 	 >to IA-64e >a >tJ >Maybe if you go crawling on hands and knees to CA will they sell you a=20I >license for the latest version of Ingres on OpenVMS. It's almost like=20mG >trying to get somebody from Compaq to sell you VMS when you say you=20t >want a reliable web server. >k >  >s >- > : >"Main, Kerry" <Kerry.Main@Compaq.com> wrote in message=20H >news:BE56C50EA024184DAF48F0B9A47F5CF401AB1DF2@kaoexc01.americas.cpqcorp >. >net.7 >. >John, >g? >Your info on database support on OpenVMS is a tad out of date.e >o5 >Reference: (In addition to Oracle Server and Rdb)=20b@ >http://www3.ca.com/Press/PressRelease.asp?id=3D915 CA Ingres=20J >http://www.mimer.com/news/engnews_mar02_2.htm Mimer (see press release=20G >- potential migration option for Sybase users that want to maintain=20s* >high availability features of OpenVMS)=20F >http://developer.mimer.se/documentation/Mimer_SQL_OpenVMS/MIM_VMS.htmG >Mimer/OpenVMS Guide http://www.e-dbms.com/analysts/2000/benchmark.htmltG >Cache on OpenVMS benchmark (Intersystems also stated publicly their=20e- >plans to support OpenVMS on Itanium as well)  >p	 >Regards,  >  >i >Kerry MainO >Senior Consultant >Compaq Canada Corp. >Professional Services >Voice: 613-592-4660 >Fax  :  819-772-7036r >Email: Kerry.Main@Compaq.comt >- >c >-----Original Message-----a) >From: John Smith [mailto:a@nonymous.com]h >Sent: April 1, 2002 12:47 PMa >To: Info-VAX@Mvb.Saic.ComI >Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha=20c	 >to IA-64, >  >  >e> >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message=20' >news:3CA8939D.CDFE4ECA@videotron.ca...  >>C >> It makes sense if one is out to consolidate product lines and=20 A >> eliminate product overlaps. VMS overlaps both tandem and unix.e >>I >> It makes sense if one is told that it would be possible to retain a=20oD >> good portion of the VMS customers by proceeding in a certain way. >>E >> Carly has made a lot of promises. The minute she realises that the  >integrationF >> isn't going smoothly, she will start to play musical chairs, layoff >additional-F >> staff and cut additional products to rationalise the company and=20 >> focus >i >> onT >its >> core incompetancies.r >AH >The one other thing that will kill VMS if Compaq/HP doesn't do it first  H >is that now there is are only two commercially viable RDBMS that are=20H >sold to run on VMS, Rdb and Oracle, both sold by Oracle Corp. Sybase=20I >has killed their ASE product on VMS. DB2 doesn't run on VMS. Informix=20eJ >doesn't. Ingres doesn't. Not that every use of VMS is RDBMS dependent,=20 >but a huge number are.i >dH >So now a huge part of the VMS lifeboat is controlled by a 3rd party.=20F >Without Alpha, Oracle doesn't post such great performance numbers.=20J >IA-64 etc...just makes Compaq/HP OpenVMS on IA-64 just another average=20G >performer that doesn't appreciably add to sales of Oracle products.=20 D >Once Oracle figures out that there's no money to be made on VMS,=20I >they'll EOL the products and that'll be that for VMS. No new sales of=20sG >db servers to new customers =3D no reason to continue to develop for =_ VMS.   >No Oracle or Rdb =3D no VMS.o >nH >You'd be smoking and inhaling if you thought that Sybase, IBM, or CA=20G >would create a VMS port if VMS ever went production on IA-64/McKinley.g >dJ >Betcha Larry makes all concerned - Compaq, HP, and VMS customers, bend=20C >over and spread 'em even more, to take advantage of the situation.s >  >  >S >o >,   -- Alan   ------------------------------  # Date: Wed, 03 Apr 2002 20:04:11 GMT7* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64C Message-ID: <%eJq8.215506$2q2.19042539@bin4.nnrp.aus1.giganews.com>   6 "Main, Kerry" <Kerry.Main@Compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF401AB1E17@kaoexc01.americas.cpqcorp.net. ..   ...f  G And in fairness, MC passed you to the VP that the questions applied to.0    A Bullshit.  The main thrust of the document was VMS's place in thecF corporation's overall strategy, over Rich very clearly had very littleF influence.  Curly fobbed us off, and Rich did what he could (which was essentially nothing).P   - bill   ------------------------------  $ Date: Wed, 3 Apr 2002 15:41:53 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>DN Subject: RE: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1E1B@kaoexc01.americas.cpqcorp.net>  H >>> The main thrust of the document was VMS's place in the corporation's overall strategy...<<<  D Well, you can think whatever you like, but I would be willing to betE that if you sent an email to IBM CEO (Lou Gerstner or new guy) asking0H him about the relative importance of AIX within IBM, while he might makeF some apple pie type statements, I suspect he would also pass you on to5 the VP in charge of AIX for a more detailed response.>   Regards,  
 Kerry Main Senior ConsultantT Compaq Canada Corp.5 Professional ServicesA Voice: 613-592-46600 Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----2 From: Bill Todd [mailto:billtodd@metrocast.net]=20 Sent: April 3, 2002 3:04 PMs To: Info-VAX@Mvb.Saic.ComeH Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-642      6 "Main, Kerry" <Kerry.Main@Compaq.com> wrote in messageH news:BE56C50EA024184DAF48F0B9A47F5CF401AB1E17@kaoexc01.americas.cpqcorp. net. .    ..  G And in fairness, MC passed you to the VP that the questions applied to.n    A Bullshit.  The main thrust of the document was VMS's place in the F corporation's overall strategy, over Rich very clearly had very littleF influence.  Curly fobbed us off, and Rich did what he could (which was essentially nothing)./   - bill   ------------------------------  % Date: Wed, 03 Apr 2002 16:07:57 -0500o- From: JF Mezei <jfmezei.spamnot@videotron.ca>wN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64, Message-ID: <3CAB6F11.3AD661E2@videotron.ca>   "Main, Kerry" wrote:G > that if you sent an email to IBM CEO (Lou Gerstner or new guy) asking6J > him about the relative importance of AIX within IBM, while he might makeH > some apple pie type statements, I suspect he would also pass you on to7 > the VP in charge of AIX for a more detailed response.D  L But if you send a letter to Gerstner telling him that one of his division isG squandering profit potential and growth for one of their prime product,IH provide him with examples of how this squandering is happenning, I wouldH expect Gertsner to thank me and tell me he would personally investigate.  J By shuffling is down to people who are below the problem layer, the CEO is? essentially saying "this squandering of profits is OK with me".9   ------------------------------  # Date: Wed, 03 Apr 2002 21:16:02 GMT9# From: "John Smith" <a@nonymous.com>dN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64D Message-ID: <miKq8.782$_q1.669@news02.bloor.is.net.cable.rogers.com>  A To the best of my knowledge, neither is marketed/sold any longer.   E How much longer will it be before IBM dumps MQ for OpenVMS Alpha (akalK WebSphere MQ) from the supported list? That would drive a big nail in VMS'sn@ coffin too. Ask IBM if they will be porting MQ to IA-64 OpenVMS.    9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagei' news:87bsd0sny2.fsf@prep.synonet.com...  >s > > DB2 doesn't run on VMS.e > $ > Any more. It used to, as did CICS. > % > > Informix doesn't. Ingres doesn't.  >B/ > I thought there was a VMS version of Ingress.= >= > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda.0B >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.H > EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Wed, 03 Apr 2002 21:18:45 GMTY# From: "John Smith" <a@nonymous.com>lN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64D Message-ID: <VkKq8.786$_q1.740@news02.bloor.is.net.cable.rogers.com>  , You're asking for logic from the government.  E Shall we trot out the old standby oxymoron - 'military intelligence'?a      9 "Paul Repacholi" <prep@prep.synonet.com> wrote in messagei' news:87g02cso3r.fsf@prep.synonet.com...S' > "John Smith" <a@nonymous.com> writes:r >iG > > As to DII-COE - it's just a piece of paper, and would be subject towH > > some negotiation to make it go away. All they'd really have to do isG > > say, 'We'll port the code for you at no charge". They'll have a bigeH > > services organization that's partially sitting on its thumbs throughC > > the current corporate spending slowdown to put to work. Problemn > > solved.  >iE > I doubt it. Once DOD lets one vendor pull a stunt like that, it alllH > turns to ashes. What they do for one, they must allow another ot do as8 > well. And we all now who will take maximium advantage. >h > --> > Paul Repacholi                               1 Crescent Rd.,9 > +61 (08) 9257-1001                           Kalamunda. B >                                              West Australia 60760 > Raw, Cooked or Well-done, it's all half baked.H > EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Wed, 03 Apr 2002 21:19:18 GMT># From: "John Smith" <a@nonymous.com> N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64D Message-ID: <qlKq8.787$_q1.210@news02.bloor.is.net.cable.rogers.com>  
 Thank you.    2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:9d6mau0ji63aclkeffbhb5jl1idjpgnrea@4ax.com...H > On Tue, 02 Apr 2002 16:55:57 GMT, "John Smith" <a@nonymous.com> wrote: >  > >e > >iI > >I have a favor to ask - post the personal e-mail addresses of Capella,bK > >Winckler, et al in this forum and we'll all flood their inboxes with ourrJ > >complaints. Why? Because there aren't enough good guys like you calling on >h( > Michael.Capellas@compaq.spamremove.com6 > Michael.Winkler@compaq.spamremove.com (might just be% > mike.winkler@compaq.spamremove.com)w > F > Surprisingly both read and sometimes even respond to personal email.B > I've had responses from both in the past. However it is probably; > Carly's address you need right now and I don't know that.s >- > drG > >theirs don't listen to them, give us the contact info and we'll telleJ > >Capellas to his face. If he doesn't like what his customers are saying, he >ID > A number of us have tried this before. Indeed Kerry was actually aG > Compaq member of the group. He just  ignored us and passed us on downu
 > to Marcello  >aD > >can fix it, or quit and give the job to somebody who will fix it. > >p > >2 > >39 > >"Main, Kerry" <Kerry.Main@Compaq.com> wrote in messagen > L >news:BE56C50EA024184DAF48F0B9A47F5CF401AB1DF5@kaoexc01.americas.cpqcorp.net .1 > >..- > >John, > > J > >>>> It's almost like trying to get somebody from Compaq to sell you VMS2 > >when you say you want a reliable web server.<<< > >  > >Hey, that's easy. > >i> > >CSWS, OSU or WASD .. And perhaps even Purveyor (right Bob?) > >iG > >CSWS offers Galaxy shared memory support and file system support forbJ > >saving state information, apache$specifc and apache$common cluster file > >access etc. > >eG > >Put a rack of DS10's in place and change 1 file in apache$common andlH > >they automatically all take advantage of this as it is the same file.F > >For server specific files, put the file in apache$specific. Put twoJ > >racks in place for multi-site load balancing (one at each site) against@ > >a multi-site, load balanced active-active clustered database. > >-  > >Surely you knew this - right? > >7 > >Regards,r > >i
 > >Kerry Maini > >Senior Consultant > >Compaq Canada Corp. > >Professional Services > >Voice: 613-592-4660 > >Fax  :  819-772-7036e > >Email: Kerry.Main@Compaq.coma > >m > >b > >-----Original Message-----A+ > >From: John Smith [mailto:a@nonymous.com]  > >Sent: April 1, 2002 3:35 PM > >To: Info-VAX@Mvb.Saic.ComK > >Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to  > >IA-64 > >O > >nI > >Maybe if you go crawling on hands and knees to CA will they sell you a H > >license for the latest version of Ingres on OpenVMS. It's almost likeK > >trying to get somebody from Compaq to sell you VMS when you say you want  > >a reliable web server.  > >i > >  > >  > >a > > 9 > >"Main, Kerry" <Kerry.Main@Compaq.com> wrote in messageIK > >news:BE56C50EA024184DAF48F0B9A47F5CF401AB1DF2@kaoexc01.americas.cpqcorp.- > >net.m > >. > >John, > >yA > >Your info on database support on OpenVMS is a tad out of date.7 > >04 > >Reference: (In addition to Oracle Server and Rdb)= > >http://www3.ca.com/Press/PressRelease.asp?id=915 CA IngresnK > >http://www.mimer.com/news/engnews_mar02_2.htm Mimer (see press release -oI > >potential migration option for Sybase users that want to maintain highc$ > >availability features of OpenVMS)H > >http://developer.mimer.se/documentation/Mimer_SQL_OpenVMS/MIM_VMS.htmI > >Mimer/OpenVMS Guide http://www.e-dbms.com/analysts/2000/benchmark.html F > >Cache on OpenVMS benchmark (Intersystems also stated publicly their/ > >plans to support OpenVMS on Itanium as well)m > >i > >Regards,  > >  > > 
 > >Kerry Mainc > >Senior Consultant > >Compaq Canada Corp. > >Professional Services > >Voice: 613-592-4660 > >Fax  :  819-772-7036  > >Email: Kerry.Main@Compaq.com3 > >4 > >  > >-----Original Message-----r+ > >From: John Smith [mailto:a@nonymous.com]- > >Sent: April 1, 2002 12:47 PMg > >To: Info-VAX@Mvb.Saic.ComK > >Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha toy > >IA-64 > >  > >t > >4= > >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message ) > >news:3CA8939D.CDFE4ECA@videotron.ca...  > >>B > >> It makes sense if one is out to consolidate product lines andC > >> eliminate product overlaps. VMS overlaps both tandem and unix.s > >>H > >> It makes sense if one is told that it would be possible to retain aF > >> good portion of the VMS customers by proceeding in a certain way. > >>G > >> Carly has made a lot of promises. The minute she realises that the  > >integrationH > >> isn't going smoothly, she will start to play musical chairs, layoff
 > >additionalhK > >> staff and cut additional products to rationalise the company and focust > >  > >> on  > >its > >> core incompetancies.i > > J > >The one other thing that will kill VMS if Compaq/HP doesn't do it firstG > >is that now there is are only two commercially viable RDBMS that aresK > >sold to run on VMS, Rdb and Oracle, both sold by Oracle Corp. Sybase hasnD > >killed their ASE product on VMS. DB2 doesn't run on VMS. InformixI > >doesn't. Ingres doesn't. Not that every use of VMS is RDBMS dependent,r > >but a huge number are.  > >gG > >So now a huge part of the VMS lifeboat is controlled by a 3rd party.qK > >Without Alpha, Oracle doesn't post such great performance numbers. IA-64fC > >etc...just makes Compaq/HP OpenVMS on IA-64 just another averagevK > >performer that doesn't appreciably add to sales of Oracle products. OncerJ > >Oracle figures out that there's no money to be made on VMS, they'll EOLJ > >the products and that'll be that for VMS. No new sales of db servers toI > >new customers = no reason to continue to develop for VMS. No Oracle orc > >Rdb = no VMS. > >cG > >You'd be smoking and inhaling if you thought that Sybase, IBM, or CA I > >would create a VMS port if VMS ever went production on IA-64/McKinley.. > >tI > >Betcha Larry makes all concerned - Compaq, HP, and VMS customers, bendaE > >over and spread 'em even more, to take advantage of the situation.  > >S > >  > >n > >i > >i >? > -- > Alan   ------------------------------  # Date: Wed, 03 Apr 2002 22:07:35 GMTo* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-64B Message-ID: <H2Lq8.212632$Gf.19752528@bin2.nnrp.aus1.giganews.com>  6 "Main, Kerry" <Kerry.Main@Compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF401AB1E1B@kaoexc01.americas.cpqcorp.net. ..  H >>> The main thrust of the document was VMS's place in the corporation's overall strategy...<<<  % Well, you can think whatever you likee    L Given the degree to which the language in the document was my own, I *know*.   - bill   ------------------------------  % Date: Thu, 04 Apr 2002 00:42:11 +0200>B From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid>N Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-646 Message-ID: <3CAB8543.5C8@this.mailaddress.is.invalid>   Main, Kerry wrote: >  > Paul,  > 6 > >>> I thought there was a VMS version of Ingress. << >  > From an earlier post from me:/ > 3 > Reference: (In addition to Oracle Server and Rdb)p< > http://www3.ca.com/Press/PressRelease.asp?id=915 CA Ingres   More recent : 1  http://support.ca.com/techbases/ingres/4021.html.  ; Ingres for OpenVMS/VAX is unavailable, Alpha is still sold.e   -- i ME Posted by news://news.nb.nu/   ------------------------------   Date: 3 Apr 2002 21:28:53 -0600s+ From: young_r@encompasserve.org (Rob Young)pN Subject: Re: The Digital 7-year plan - from 1997 to 2004 - from Alpha to IA-643 Message-ID: <DntlWBuHjrV8@eisner.encompasserve.org>V  o In article <H2Lq8.212632$Gf.19752528@bin2.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes:F > 8 > "Main, Kerry" <Kerry.Main@Compaq.com> wrote in messageN > news:BE56C50EA024184DAF48F0B9A47F5CF401AB1E1B@kaoexc01.americas.cpqcorp.net. > .. > I >>>> The main thrust of the document was VMS's place in the corporation'sn > overall strategy...<<< > ' > Well, you can think whatever you like. >  > N > Given the degree to which the language in the document was my own, I *know*. >   9 	And very easily located if bystanders wish to peruse and  	form their own opinions:   S http://groups.google.com/groups?selm=921fl3%24pdv%241%40pyrite.mv.net&output=gplain    				Robi   ------------------------------  $ Date: Wed, 3 Apr 2002 14:33:35 -0500 From: Tym_Stegner@cca-int.comn' Subject: re: The Digital 7-year plan... A Message-ID: <OF2F45A211.A7B0B04E-ON85256B90.006AC83D@cca-int.com>t  % "John Smith" <a@nonymous.com> writes:   C > The one other thing that will kill VMS if Compaq/HP doesn't do itoC > first is that now there is are only two commercially viable RDBMS B > that are sold to run on VMS, Rdb and Oracle, both sold by Oracle3 > Corp. Sybase has killed their ASE product on VMS.b   Ahem.    Three.s  G System 1032 has been running on [Open]VMS since the original VAX 11/780xC days (1984-ish).   We've continued to operate on all VAXen & AlphaspI (running VMS) ever since.   (Had one customer running for years and yearsf& on a 725 - never wanted to upgrade...)  H We may not have the marketing arms that Oracle does, but like VMS, S1032 just runs and runs and runs...  I (Someday I'll have the right context to use my S1032@Digital story, but Id$ don't think I'm quite there, yet...)  ; p.s.  Kerry?  Can I get on the 'recommended software' list?=   -Tym Stegner
 S1032 Supportn   ------------------------------  % Date: Wed, 03 Apr 2002 22:09:46 +0200s- From: Didier Morandi <Didier.Morandi@Free.fr>M' Subject: Re: The Digital 7-year plan... ' Message-ID: <3CAB6189.EC78926E@Free.fr>u   System 1032?  O Is this a late aprilfool joke? I'm doing VMS support since 1982. I heard of DEClN Rdb, DEC DBMS, Oracle, Sybase and Informix (and I may forgot one or two) but IN never heard of System 1032. What is the name of the editor? Did they ever sell
 in Europe?   D.   Tym_Stegner@cca-int.com wrote: >  > Ahem.    Three.0 > I > System 1032 has been running on [Open]VMS since the original VAX 11/780R > days (1984-ish).   ------------------------------  $ Date: Wed, 3 Apr 2002 19:50:29 -0500, From: "Frank Sapienza" <sapienza@noesys.com>' Subject: Re: The Digital 7-year plan...r, Message-ID: <a8g81b02oik@enews1.newsguy.com>  * <Tym_Stegner@cca-int.com> wrote in message; news:OF2F45A211.A7B0B04E-ON85256B90.006AC83D@cca-int.com... J > We may not have the marketing arms that Oracle does, but like VMS, S1032  > just runs and runs and runs... >    ROTFL!  H Come on, that's a late April Fool's joke, right?  Oracle has a marketingL department?  When was the last time you saw an ad or *anything* marketing orL promoting Oracle RDB (nee DEC RDB) for OpenVMS?  They are as silent on their) OpenVMS product as Compaq is with the OS!u  1 That was funny.  You guys just kill me sometimes.4 :-)o   ------------------------------  $ Date: Wed, 3 Apr 2002 14:01:16 -0600- From: covMr Lasader <gsbPeterLasader@msn.com>r) Subject: The Latest Web Technologies jbmpc" Message-ID: <5062472@MVB.SAIC.COM>   <html> <head>  <title>Untitled Document</title>H <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head>)  ' <body bgcolor="#FFFFFF" text="#000000"> V I noticed your email address on a list serve related to next generation web services, @ applications, web development, and content management solutions.R <p>It's apparent that you already recognize which technologies have the potential O   to streamline your business and impact your bottom line. How about being the iO   first to know about new products and developments that are specific to these t   areas of interest?</p>Q <p>With your permission, we'd like to keep you informed of the best ways to stay nR   ahead of your competition. To opt-in to receive updates on cutting-edge content P   management and web tools, as well as an e-newsletter with the latest industry N   developments, <a href="http://195.235.97.200/personal8/toppromo1/dy/">click    here</a>.</p>lN <p>We look forward to sharing tomorrow's enterprise management solutions with    you...today!</p> <p>Cordially</p> <p>Victor Black</p>d </body>t </html>e   pohjrnpuofteteprhhsq   ------------------------------  $ Date: Thu, 4 Apr 2002 10:18:37 +1000* From: "Dale King" <dalek@forpresident.com>$ Subject: Re: UCX Routing Table grows& Message-ID: <a8g64u$u0$1@lore.csc.com>  , "Surd" <surd615@excite.com> wrote in message7 news:5fce3657.0204030917.2d4a8c95@posting.google.com....B > Why does the routing table in UCX contain entries that should beB > covered by the default route? This table expands to hundreds andB > hundreds of entries over days and eventually crashes the system.   Try also a TCPIP> netstat -rnp: which will show you which routes come from ICMP redirects.  O You appear to be getting these redirects because 10.200.78.20 is a better routetP to these destination networks.  You could either turn ICMP redirects off on yourL routers (not nice) or perhaps use .20 as your default route if a majority of traffic is going through it.   Hope this helps.   ------------------------------   Date: 3 Apr 2002 13:55:04 -0800p( From: bob@instantwhip.com (Bob Ceculski)3 Subject: VMS "unhackable" example just for Andy ... = Message-ID: <d7791aa1.0204031355.2a2872a8@posting.google.com>,  A this is off process softwares site ... you see Andy, us vms usersjA remain unhackable even w/cert advisories ... that's what we triedo? to tell you in other posts that most ip problems such as bufferr6 overflows don't affect vms ... they just error out ...    ( SNMP Inquiry - Cert Advisory CA-2002-03 P --------------------------------------------------------------------------------  	 Question:a  D Are either MultiNet or TCPware affected by CERT Advisory CA-2002-03A in Many Implementations of the Simple Network Management Protocole  (SNMP), dated February 12, 2002?   Answer:@  F These SNMP vulnerabilities do NOT pose security risks for MultiNet andF TCPware. MultiNet V4.4A is not vulnerable to these SNMP issues at all.D MultiNet 4.3A and TCPware have minor problems with access violationsA (resulting in the SNMP process dying), but pose no security risk.5C Patches for MultiNet 4.3A and TCPware V5.5-3 are available from the E TCPware ECO Database and the MultiNet ECO database. Use the following 
 kit names:   MultiNet V4.3A: SNMP-020_A043e TCPware V5.5-3: SNMPD_V553P011   ------------------------------  $ Date: Wed, 3 Apr 2002 13:57:29 -0500> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>> Subject: RE: VMS boottime - how to calculate # of days runningM Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D01602946@MBCALBEXC03.BENDER.COM>   9 I am sure someone will answer your question more exactly.   > However, I will offer $ SHOW SYSTEM/NOPROCESS if you want the 9 uptime info and a bit more.  It might satisfy your needs.e   :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadway  Albany, NY  12204  USAp 518-487-3255 John.C.Koska@lexisnexis.comt  ) I post personal opinion only, and all theh* disclaimers one could imagine apply.  That( includes, I speak for myself only and my) views in no way represent my employer(s).y+ One should also take note of the Electronicn) Communications Privacy Act of 1986, whichk+ imposes civil and criminal liability on anyn( person who intentionally intercepts "any( wire, oral or electronic communication."   > -----Original Message-----6 > From: BHALPERN@UMCAZ.EDU [mailto:BHALPERN@UMCAZ.EDU]) > Sent: Wednesday, April 03, 2002 1:52 PM  > To: Info-VAX@Mvb.Saic.Com1< > Subject: VMS boottime - how to calculate # of days running >  > C > I am wondering if there is a quick way to determine the number of0H > days/time since VMS was last booted.  I know I can get the boottime byF > using f$getsyi("boottime").  Not being a VMS guru, is there a way toB > subtract the current date/time from the boottime and display theE > number of days VMS has been running.  This would eventually be in a9= > daily report file.  If you can point me in the direction of0, > documentation, that would also be helpful. >  > Thanks >    ------------------------------  $ Date: Wed, 3 Apr 2002 11:08:42 -0800# From: "Tom Linden" <tom@kednos.com>A> Subject: RE: VMS boottime - how to calculate # of days running9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKEPEEKAA.tom@kednos.com>m   ODIN> sho symbol uptime 3   UPTIME == "write sys$output f$getsyi("boottime")"t   > -----Original Message-----E > From: Koska, John C. (LNG-MBC) [mailto:John.C.Koska@lexisnexis.com] * > Sent: Wednesday, April 03, 2002 10:57 AM > To: Info-VAX@Mvb.Saic.Coma@ > Subject: RE: VMS boottime - how to calculate # of days running >  > ; > I am sure someone will answer your question more exactly.  > @ > However, I will offer $ SHOW SYSTEM/NOPROCESS if you want the ; > uptime info and a bit more.  It might satisfy your needs.h >  > :) jck > John Koska > Matthew Bender & Co., Inc. -$ >   A Member of the LexisNexis Group > 1275 BroadwayI > Albany, NY  12204t > USAs > 518-487-3255 > John.C.Koska@lexisnexis.comv > + > I post personal opinion only, and all the , > disclaimers one could imagine apply.  That* > includes, I speak for myself only and my+ > views in no way represent my employer(s).o- > One should also take note of the Electronic + > Communications Privacy Act of 1986, whichi- > imposes civil and criminal liability on any4* > person who intentionally intercepts "any* > wire, oral or electronic communication." >  > > -----Original Message-----8 > > From: BHALPERN@UMCAZ.EDU [mailto:BHALPERN@UMCAZ.EDU]+ > > Sent: Wednesday, April 03, 2002 1:52 PM. > > To: Info-VAX@Mvb.Saic.Com > > > Subject: VMS boottime - how to calculate # of days running > >  > > E > > I am wondering if there is a quick way to determine the number of,J > > days/time since VMS was last booted.  I know I can get the boottime byH > > using f$getsyi("boottime").  Not being a VMS guru, is there a way toD > > subtract the current date/time from the boottime and display theG > > number of days VMS has been running.  This would eventually be in ar? > > daily report file.  If you can point me in the direction ofa. > > documentation, that would also be helpful. > > 
 > > Thanks > >  >    ------------------------------   Date: 3 Apr 2002 13:14:26 -0600y+ From: young_r@encompasserve.org (Rob Young)a> Subject: Re: VMS boottime - how to calculate # of days running3 Message-ID: <y4uWXTfNghSM@eisner.encompasserve.org>   h In article <dbcb2b6e.0204031051.6bd0aa1b@posting.google.com>, BHALPERN@UMCAZ.EDU (BRITT HALPERN) writes:C > I am wondering if there is a quick way to determine the number ofaH > days/time since VMS was last booted.  I know I can get the boottime byF > using f$getsyi("boottime").  Not being a VMS guru, is there a way toB > subtract the current date/time from the boottime and display theE > number of days VMS has been running.  This would eventually be in au= > daily report file.  If you can point me in the direction of , > documentation, that would also be helpful. >   8 	Assuming 7.1 or higher and borrowing a bit from Gotfryd- 	(by the way, it didn't like his f$trnlnm)...     
 $ type up.comy   $ !uO $ SetData       :==     (READ SYS$INPUT DATA ; DEFINE/JOB/NOLOG DATA_LOG &DATA) J $ GetData       :==     DATA_SYM == F$TRNLNM("""DATA_LOG""","""LNM$JOB""")5 $ !                                                  sB $ PIPE SHOW SYSTEM | SEARCH SYS$INPUT " uptime" | 'SetData'        $ 'GetData'o/ $ clean_data = f$edit(data_sym,"COMPRESS,TRIM")a $ !l2 $ days_up = f$integer(f$element(8," ",clean_data)) $ if days_up .lt. 2r $ then V $       s = "" $ else $       s = "s"t $ endif-C $ write sys$output  "This node has been up for ",days_up," day''s'"  $ @upy  ! This node has been up for 54 daysp   				Robp   ------------------------------  $ Date: Wed, 3 Apr 2002 14:30:19 -0500 From: William_Bochnik@acml.com> Subject: RE: VMS boottime - how to calculate # of days running> Message-ID: <OFF311FADE.3DB20E61-ON85256B90.006B1892@acml.com>  K Hmm... on my system write sys$output f$getsyi("boottime")  shows the bootedo time, not uptime...:      [                                                                                            r[                       Tom Linden                                                           v[                       <tom@kednos.com>                To:  Info-VAX@Mvb.Saic.Com           e[                                                       cc:                                  o[                       04/03/2002 02:08         Subject: RE: VMS boottime - how to          s[                       PM                       calculate # of days running                 >[                       Please respond                                                        [                       to Tom Linden                                                        s[                       <tom@kednos.com>                                                     s[                                                                                            e[                                                                                                    ODIN> sho symbol uptimea3   UPTIME == "write sys$output f$getsyi("boottime")"    > -----Original Message-----E > From: Koska, John C. (LNG-MBC) [mailto:John.C.Koska@lexisnexis.com]u* > Sent: Wednesday, April 03, 2002 10:57 AM > To: Info-VAX@Mvb.Saic.Como@ > Subject: RE: VMS boottime - how to calculate # of days running >W >o; > I am sure someone will answer your question more exactly.  >6? > However, I will offer $ SHOW SYSTEM/NOPROCESS if you want thev; > uptime info and a bit more.  It might satisfy your needs.  >c > :) jck > John Koska > Matthew Bender & Co., Inc. -$ >   A Member of the LexisNexis Group > 1275 Broadway  > Albany, NY  12204o > USAN > 518-487-3255 > John.C.Koska@lexisnexis.com= > + > I post personal opinion only, and all thec, > disclaimers one could imagine apply.  That* > includes, I speak for myself only and my+ > views in no way represent my employer(s). - > One should also take note of the Electronic + > Communications Privacy Act of 1986, whichp- > imposes civil and criminal liability on anyp* > person who intentionally intercepts "any* > wire, oral or electronic communication." >  > > -----Original Message-----8 > > From: BHALPERN@UMCAZ.EDU [mailto:BHALPERN@UMCAZ.EDU]+ > > Sent: Wednesday, April 03, 2002 1:52 PMj > > To: Info-VAX@Mvb.Saic.Comn> > > Subject: VMS boottime - how to calculate # of days running > >$ > >7E > > I am wondering if there is a quick way to determine the number ofcJ > > days/time since VMS was last booted.  I know I can get the boottime byH > > using f$getsyi("boottime").  Not being a VMS guru, is there a way toD > > subtract the current date/time from the boottime and display theG > > number of days VMS has been running.  This would eventually be in ah? > > daily report file.  If you can point me in the direction of-. > > documentation, that would also be helpful. > > 
 > > Thanks > >n >I   ------------------------------  % Date: Wed, 03 Apr 2002 20:41:42 +0100a' From: Elliott Roper <elliott@yrl.co.uk>o> Subject: Re: VMS boottime - how to calculate # of days running2 Message-ID: <030420022041426216%elliott@yrl.co.uk>  C In article <dbcb2b6e.0204031051.6bd0aa1b@posting.google.com>, BRITTf# HALPERN <BHALPERN@UMCAZ.EDU> wrote:o  C > I am wondering if there is a quick way to determine the number ofsH > days/time since VMS was last booted.  I know I can get the boottime byF > using f$getsyi("boottime").  Not being a VMS guru, is there a way toB > subtract the current date/time from the boottime and display theE > number of days VMS has been running.  This would eventually be in ap= > daily report file.  If you can point me in the direction of-, > documentation, that would also be helpful. >  > Thanks   Is parsing the output of $ sh sys /noproc too uncool?6   ------------------------------  # Date: Wed, 03 Apr 2002 20:21:26 GMTa" From: "Hans Vlems" <hvlems@iae.nl>> Subject: Re: VMS boottime - how to calculate # of days running/ Message-ID: <avJq8.283$o3.4286@typhoon.bart.nl>c  . Nice DCL procedure, one very small suggestion:3 The last IF statement should read $ if days_up.eq.1l   Hans  6 Rob Young <young_r@encompasserve.org> wrote in message- news:y4uWXTfNghSM@eisner.encompasserve.org...i? > In article <dbcb2b6e.0204031051.6bd0aa1b@posting.google.com>,t* BHALPERN@UMCAZ.EDU (BRITT HALPERN) writes:E > > I am wondering if there is a quick way to determine the number ofdJ > > days/time since VMS was last booted.  I know I can get the boottime byH > > using f$getsyi("boottime").  Not being a VMS guru, is there a way toD > > subtract the current date/time from the boottime and display theG > > number of days VMS has been running.  This would eventually be in ac? > > daily report file.  If you can point me in the direction ofq. > > documentation, that would also be helpful. > >o > 9 > Assuming 7.1 or higher and borrowing a bit from GotfrydM. > (by the way, it didn't like his f$trnlnm)... >a >h > $ type up.comS >r > $ !nJ > $ SetData       :==     (READ SYS$INPUT DATA ; DEFINE/JOB/NOLOG DATA_LOG &DATA)L > $ GetData       :==     DATA_SYM == F$TRNLNM("""DATA_LOG""","""LNM$JOB""") > $ !a= > $ PIPE SHOW SYSTEM | SEARCH SYS$INPUT " uptime" | 'SetData'e
 > $ 'GetData' 1 > $ clean_data = f$edit(data_sym,"COMPRESS,TRIM")t > $ !h4 > $ days_up = f$integer(f$element(8," ",clean_data)) > $ if days_up .lt. 2d > $ then > $       s = "" > $ else > $       s = "s"y	 > $ endiftE > $ write sys$output  "This node has been up for ",days_up," day''s'"  > $ @up  >t# > This node has been up for 54 daysT >S > Rob  >3   ------------------------------   Date: 3 Apr 2002 14:33:21 -06002+ From: young_r@encompasserve.org (Rob Young)r> Subject: Re: VMS boottime - how to calculate # of days running3 Message-ID: <x5wzCZPVDQ$h@eisner.encompasserve.org>?  T In article <avJq8.283$o3.4286@typhoon.bart.nl>, "Hans Vlems" <hvlems@iae.nl> writes:0 > Nice DCL procedure, one very small suggestion:5 > The last IF statement should read $ if days_up.eq.1  >    	Thanks.  A 	I knew that *after* I posted it (quick hack).  I leave it as an c
 	exercise :-):   				Robm   ------------------------------   Date: 3 Apr 2002 16:33:29 -0600h- From: koehler@encompasserve.org (Bob Koehler)-> Subject: RE: VMS boottime - how to calculate # of days running3 Message-ID: <sVv+kHIsL7x$@eisner.encompasserve.org>u   In article <3D35AD137AAAD411A6BA0008C7B1B12D01602946@MBCALBEXC03.BENDER.COM>, "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com> writes:; > I am sure someone will answer your question more exactly.h > @ > However, I will offer $ SHOW SYSTEM/NOPROCESS if you want the ; > uptime info and a bit more.  It might satisfy your needs.a > D    Also deals with the fact thjat the difference between the currentD    time and the bootime is not the uptime when you're clock changes.   ------------------------------   Date: 3 Apr 2002 15:55:13 -0800n( From: bhalpern@umcaz.edu (BRITT HALPERN)> Subject: Re: VMS boottime - how to calculate # of days running< Message-ID: <e9aa9fae.0204031555.cfa38a6@posting.google.com>  	 Thanks!!!o   sho sys/noproc e is exactly what I needed.:   ------------------------------  # Date: Thu, 04 Apr 2002 02:22:35 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>m. Subject: Re: VMS on 533au Ultimate Workstation& Message-ID: <3CABBB56.7086C69@fsi.net>   Didier Morandi wrote:" > Q > Find a Firmware update CD, boot from it, apply the patch and Bob should be your  > uncle :-))  < Is that a French expression that doesn't translate well into% English/American, or what did I miss?n   -- c David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  # Date: Thu, 04 Apr 2002 02:55:07 GMTtL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr"). Subject: Re: VMS on 533au Ultimate Workstation8 Message-ID: <00A0BEC9.897A2A0D@SSRL04.SLAC.STANFORD.EDU>  Z In article <3CABBB56.7086C69@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes: >Didier Morandi wrote: >> 0R >> Find a Firmware update CD, boot from it, apply the patch and Bob should be your
 >> uncle :-))r > = >Is that a French expression that doesn't translate well into>& >English/American, or what did I miss?  ? You missed Didier learning that phrase from an English speaker.e  O "and Bob's your uncle!" is an Anglicism that means "and you're all set" or "andcJ it should work now" or even "et voila!".  A semi-obsolete Americanism with= the same general meaning would be "and you're in like Flynn!"3   -- Alan9  O ===============================================================================s0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056hM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210tO ===============================================================================1   ------------------------------  % Date: Thu, 04 Apr 2002 13:01:54 +0930i/ From: Mark Daniel <Mark.Daniel@wasd.vsm.com.au>t. Subject: Re: VMS on 533au Ultimate Workstation. Message-ID: <3CABC92A.5000300@wasd.vsm.com.au>  * Alan Winston - SSRL Admin Cmptg Mgr wrote:Q > "and Bob's your uncle!" is an Anglicism that means "and you're all set" or "and)L > it should work now" or even "et voila!".  A semi-obsolete Americanism with? > the same general meaning would be "and you're in like Flynn!"o  N Now we'd all like to hear your explanation of the etymology of this phrase :^)    BTW. Flynn was an Australian ;^)   ------------------------------   Date: 3 Apr 2002 22:44 CST' From: carl@gerg.tamu.edu (Carl Perkins)r. Subject: Re: VMS on 533au Ultimate Workstation, Message-ID: <3APR200222444207@gerg.tamu.edu>  5 "David J. Dachtera" <djesys.nospam@fsi.net> writes...a }Didier Morandi wrote: }> PR }> Find a Firmware update CD, boot from it, apply the patch and Bob should be your
 }> uncle :-))t } = }Is that a French expression that doesn't translate well intoN& }English/American, or what did I miss? }  }--  }David J. Dachtera  
 Mea culpa.  C I used the (British) expression "and Bob's your uncle" in a post inCD a different thread a couple of days ago (when explaining how easy itC was to set up NTP - you put a few suitable lines in a configuration44 file on each node, start NTP, and Bob's your uncle).  E The (or one of, anyway) French expression that doesn't translate welleD into English is "et roule ma poule". I'm not exactly certain why one? would want to roll one's chickens (if that is, in fact, what it9A means - it's been a long time since I had French and you know howoD reliable Babelfish can be), but it aparently is something the French< do when they are finished doing what they were trying to do.  D Actually, someone British might be able to tell us if the "and Bob'sF your uncle" thing implies that it was easy to do, done well or poorly,D is unexpectedly finished when you thought there would be more to do,D or has any other implications other than just being done. I've neverF actually seen the source material - I've just seen the expression used in a few places.   --- Carl   ------------------------------   Date: 3 Apr 2002 20:02 CST' From: carl@gerg.tamu.edu (Carl Perkins)y) Subject: Re: VMS To Tru64 Migration Plans , Message-ID: <3APR200220020219@gerg.tamu.edu>  / young_r@encompasserve.org (Rob Young) writes...6l }In article <3CAB2AC9.8060400@sun.com>, Andrew Harrison <andrew_nospam.harrison_remove_this@sun.com> writes:= }> There is also a perception that Tru64 has had all the NUMA 9 }> tuning work done for it not all of which has been donet
 }> to OpenVMSr } " }	Perception?  By who, you?  Okay. } @ }	But you are talking out your hat once again and a quick Google }	lands many hits, for example:h } 3 }http://www.openvms.compaq.com/wizard/wiz_6984.htmlm } 4 }  "Spinning is also sensitive to non-uniform memoryI }  access (NUMA) memory organization, with processes local to the bitlockoC }  receiving substantially more preferential access to the bitlock. H }  (The kernel-mode OpenVMS spinlock primitives were explicitly modified; }  to account for this particular characteristic of NUMA.)"  }  }				Rob  = Which shows that that particular modifcation was done to VMS.-  = It does not show that all the modifcations done to Tru64 haveT< been done to VMS, or that VMS has had some that Tru64 hadn't9 gotten (which doesn't exactly counter the claim, but doesO8 show that Tru64 also didn't get all the tuning work that6 VMS did which would make them "even" in this respect).  > If you really want to shoot down a "not all" claim, giving one? example of something that was done for VMS won't be sufficient.,D You have to get the list of everything done for Tru64 and everything= done for VMS and show that everything on the former is on theo latter.l  D But that still does nothing for the "perception" claim. As for that,E I'd ask what poll he was looking at. Anythng sort of a professionallyiE run poll is pretty useless for knowing what the preception of people,&E in general, is (and even one of those is considerably more dubious in D quality than the polling organizations would have you think - but itF is still the best available option). It may be his impression and even@ the impression of everyone he works with or knows, but that is aB statistically insignificant sample of the relevant population (and? all, or at least almost all, located in one geographic region).   > It is easy to make a claim that is hard to refute. Here's one:  ?   There is the perception that Andrew lacks technical knowledgec?   and is employed by Sun for the sole purpose of spreading FUD.L  @ I seriously doubt that would find it easy to provide us with any" real evidence to refute the claim.  > Expending any significant effort over such nonsense is stupid.   --- Carl   ------------------------------   Date: 3 Apr 2002 20:22:22 GMTm) From: leslie@clio.rice.edu (Jerry Leslie) 1 Subject: Re: Why VMS is "unhackable" lesson 1 ... ' Message-ID: <a8fo9u$rbe$1@joe.rice.edu>g  4 Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote:: : I promise to apologize, say that you and Bill are Gods,   - Your choice of religion is your business. :-)   8 : and that Andy-Pandy is the smartest guy I never met -   3 That would be considered perjury in a court of law.e  5 : and will never write in this conference ever again.-  D Why punish everyone ?  There are still VMS customers who value your 
 expertise.  4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  $ Date: Wed, 3 Apr 2002 16:49:10 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>.1 Subject: Re: Why VMS is "unhackable" lesson 1 ... 3 Message-ID: <tTKq8.1835$fL6.37330@news.cpqcorp.net>h  = JF Mezei wrote in message <3CAB3FF4.20FDC812@videotron.ca>...n >Fred Kleinsorge wrote:s    F >its currently state where marketing isn't allowed. Look at how freely CompaqE >now talks about Alpha success since June 25. Since it is no longer aS threath, >it can talk about it.  K Not true.  It just happens that a lot of interesting high-profile sales all K have come through.  If you had been listening, you would have heard about a J lot of other ones long ago - like the various UNIX supercomputer sales, or the human genome project, etc.   ------------------------------  $ Date: Wed, 3 Apr 2002 16:55:25 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>"1 Subject: Re: Why VMS is "unhackable" lesson 1 ... 3 Message-ID: <kZKq8.1836$fL6.37312@news.cpqcorp.net>|  C IMHO - I have no belief that VMS will become the flagship OS of HP.a  F IHMO - I believe that VMS will fit into the overall plans, and will beK quietly sold and expanded as our financial performance merits.  If it is ineD decline, expect to see the focus on stablizing it or putting it intoK maintenance mode (subject to whatever legal committments exist).  If we can H resume the modest growth we had been seeing, then perhaps there might be some additional investment.i  J I believe that the port to IPF, and the UNIX compatabilty work, along withH O/S and I/O peformance improvments, plus the EV7 high-end - all combined have the ability to grow VMS.t    = JF Mezei wrote in message <3CAB4A21.BD0E0A9E@videotron.ca>...  >Rob Young wrote: A >>         Take him up on it... will it or won't it?  You seem torH >>         believe it won't.  You cleverly then prattle on about "properI >>         marketing" and "core product".  Nice try... not unlike our Sun  friend.- >@ >.L >As I have said, I do not equate the port to IA64 to VMS's survival/success. I L >equate it only to longer life. But I don't consider extending VMS's current >comatosed state to be "life". >tL >How can you be so confident that HP intends to market and grow VMS when you1 >have no idea what Carly intends to do with VMS ?  >aG >There is no question that HP is bound to continue its obligations with  regards J >to existing VMS customers, with DII-COE being a driving force for the fewK >customers who have paid/signed for such an agreement. You'll note that MPE  is) >getting similar support for a few years.  > J >But this does not say anything about maximizing VMS' potential, expanding its E >market, growing its installed base and working hard to put back some D >confidence that VMS is to be taken seriously as a serious long term
 contender. > A >Carly chose not to talk about VMS. Carly therefore is to be helda responsibleo+ >for the uncertainty about the fate of VMS.l   ------------------------------  $ Date: Wed, 3 Apr 2002 16:58:15 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>m1 Subject: Re: Why VMS is "unhackable" lesson 1 ...y3 Message-ID: <%%Kq8.1837$fL6.37190@news.cpqcorp.net>S  = JF Mezei wrote in message <3CAB4350.CF63CE07@videotron.ca>...f >Fred Kleinsorge wrote:jB >> What is with you?  Do you have some personal insight into Carly >eE >Even the media calls her "Carly". Her real name is Carleton Fiorina.8 >2L >> In fact, I don't really get the hostility against HP, let alone it's CEO.6 >> What exactly have they done to warrent such hatred? >l  G Since you ommitted the slanderous phrase, I'll omit part of your reply.eI Call her Carly, I call her Carly.  I can't say, let alone remember how toi spell Fiorina.  < But the personal and sexists insults are a bit over the top.   ------------------------------  $ Date: Wed, 3 Apr 2002 16:59:54 -05005 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>H1 Subject: Re: Why VMS is "unhackable" lesson 1 ...e3 Message-ID: <x1Lq8.1838$fL6.37346@news.cpqcorp.net>V  ! Jerry Leslie wrote in message ...o5 >Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote: : >: I promise to apologize, say that you and Bill are Gods, >b. >Your choice of religion is your business. :-) > 8 >: and that Andy-Pandy is the smartest guy I never met - >)4 >That would be considered perjury in a court of law. >t6 >: and will never write in this conference ever again. > D >Why punish everyone ?  There are still VMS customers who value your >expertise.o >f  K Thanks Jerry.  We'll have to have a big ex-DECie party to celebrate/observelG the end of Compaq and the rebirth of the DEC part of the company in HP.-   ------------------------------  # Date: Wed, 03 Apr 2002 22:16:56 GMTt2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)1 Subject: Re: Why VMS is "unhackable" lesson 1 ...43 Message-ID: <sbLq8.1839$fL6.37346@news.cpqcorp.net>0  } In article <3CA9DBCE.9080603@sun.com>, Andrew Harrison SUNUK Consultancy <andrew_nospam.remove_this.harrison@sun.com> writes:e :m : ) :Andrew Harrison SUNUK Consultancy wrote:a :bH :Sorry nice try but no cigar. In a number of cases OpenVMS was vunerableH :to IP stack exploits, Compaq had posted response to CERT for both Tru648 :and OpenVMS, OpenVMS was listed as not being vunerable. :eA :Except that Compaqs own patch reports then listed a patch to fixfG :the same vunerability. In otherwords the CERT response did not reflectb :OpenVMS's actual vunerability.r :g@ :Security through obscurity which you are apparently arguing for< :is one thing but this is not what has happened in the past.  K   Thanks to the repeated use of this topic in the on-going Sun marketeering K   campaigns, the frequency of this omission has largely and hopefully been oN   repaired.  If this omission should be encountered in future CERT advisories,K   please let me know directly or better, post it here -- the references to eH   this omission in the Sun marketing have been exceedingly useful in my K   efforts to reduce the frequency of the omission(s) of mention of OpenVMS eB   (whether or not it is vulnerable) in the Compaq CERT advisories.   	--   J   As for buffer overruns, I am aware of no operating system -- potentiallyI   short of one evaluated at something approaching NCSC Class A, of course K   -- that is not potentially vulnerable to buffer overruns.  This includes oM   Solaris, Tru64 UNIX, OpenVMS, Linux, Windows, and most any other operating fJ   system I am aware of.  This is simple business economics -- there is notL   yet a substantial market for the effort involved in NCSC Class A security L   or equivalent -- the effort in resolving this is cost-prohibitive and the I   market is accordingly limited.  Other folks far more cogent than I have/G   discussed and debated API-level changes and hardware protections thatMM   would be necessary to remedy this, and the effort involved in any of these  L   (and in the reviews and the proofs) is non-trivial.  Verified security as M   required for NCSC Class A is difficult -- the few folks that have achieved  N   NCSC Class A status have either a very bounded configuration, an impressive 0   operating system product achievement, or both.      N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Wed, 03 Apr 2002 17:32:49 -0500v- From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Why VMS is "unhackable" lesson 1 ...u, Message-ID: <3CAB82EE.B38D4474@videotron.ca>   Fred Kleinsorge wrote:L > I believe that the port to IPF, and the UNIX compatabilty work, along withJ > O/S and I/O peformance improvments, plus the EV7 high-end - all combined > have the ability to grow VMS.   N Is it correct to state that those who really need raw horsepower will choose a Unix solution on EV7 ?  K Would it be fair to state that a new customer would not likely invest in anBJ EV7 "wildfire" class system ($million) for a new VMS installation, knowingK that it would be a short term solution, needing another port in a couple of, years ?f  L What is the expectation with regards to those large shops that have investedE mega money in a Wildfire? Will they be able to continue to grow theiriG Wildfires with EV6 cpu modules, or are they expected to ditch their EV6h3 Wildfire and buy a brand new EV7 based "Wildfire" ?-  M Will HP make old Wildfires available to hobbyists ? I wouldn't mind upgrading) my microvax II :-)   ------------------------------  $ Date: Wed, 3 Apr 2002 17:49:35 -0500+ From: "Main, Kerry" <Kerry.Main@Compaq.com>o1 Subject: RE: Why VMS is "unhackable" lesson 1 ... T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF401AB1E1E@kaoexc01.americas.cpqcorp.net>   JF -  D >>> Is it correct to state that those who really need raw horsepower& will choose a Unix solution on EV7 >>>  ? No. Depends on application, politics, available skill sets etc.o  F >>> Will they be able to continue to grow their Wildfires with EV6 cpuC modules, or are they expected to ditch their EV6 Wildfire and buy ac# brand new EV7 based "Wildfire" ?<<<i  G The Wildfire systems were upgraded to 1Ghz modules. Given that WildfirerD systems have been available for 2 or 3 years now, how long would you6 expect Customers to keep doing in cabinet upgrades?=20  F Besides, the new EV7 systems can simply be added as an additional nodeG in the cluster. Same thing for new OpenVMS / IA64 systems whenever they0 become available.R  B Do you think Sun has any plans to offer upgrades to existing UE10K  systems with their latest chips?  B >>> Would it be fair to state that a new customer would not likelyA invest in an EV7 "wildfire" class system ($million) for a new VMS:E installation, knowing that it would be a short term solution, needing>& another port in a couple of years ?<<<  F Well, most Customers I know for mission critical systems expect that aG system will need replacing or upgrading after 5+ years. Most depreciate" HW over 3-5 year period.=20e  @ Since maintaining their investment in their current applications< infrastructure are their primary concern, Customers in theseF environments upgrade when their business requires it, not when vendors
 want them to.    Regards   
 Kerry Main Senior ConsultantD Compaq Canada Corp.l Professional Serviceso Voice: 613-592-46609 Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20= Sent: April 3, 2002 5:33 PM  To: Info-VAX@Mvb.Saic.Com-1 Subject: Re: Why VMS is "unhackable" lesson 1 ...m     Fred Kleinsorge wrote:J > I believe that the port to IPF, and the UNIX compatabilty work, along=20I > with O/S and I/O peformance improvments, plus the EV7 high-end - all=20 ( > combined have the ability to grow VMS.  E Is it correct to state that those who really need raw horsepower willr choose a Unix solution on EV7 ?t  H Would it be fair to state that a new customer would not likely invest inE an EV7 "wildfire" class system ($million) for a new VMS installation, G knowing that it would be a short term solution, needing another port in- a couple of years ?e  C What is the expectation with regards to those large shops that havecH invested mega money in a Wildfire? Will they be able to continue to growC their Wildfires with EV6 cpu modules, or are they expected to ditcha= their EV6 Wildfire and buy a brand new EV7 based "Wildfire" ?o  C Will HP make old Wildfires available to hobbyists ? I wouldn't mind  upgrading my microvax II :-)   ------------------------------   Date: 3 Apr 2002 22:56:50 GMTm) From: leslie@clio.rice.edu (Jerry Leslie)u1 Subject: Re: Why VMS is "unhackable" lesson 1 ...y' Message-ID: <a8g1bi$2tl$5@joe.rice.edu>e  4 Fred Kleinsorge (kleinsorge@star.zko.dec.com) wrote:M : Thanks Jerry.  We'll have to have a big ex-DECie party to celebrate/observehI : the end of Compaq and the rebirth of the DEC part of the company in HP.e :eE You're welcome. Can current & former VMS customers like me come too ?.  F Every time I hear the "HP Way", I think about the segment "60 Minutes"F aired on October 3, 1993, that ended with Lesley Stahl chasing the CEO$ of H-P. The transcript is online at:  @    http://www.zazona.com/ShameH1B/Library/Archives/60Minutes.htm?    CBS News "60 Minutes" October 3, 1993 'North of the Border' n    Lesley Stahl, reporting  G    "LESLEY STAHL: Those who oppose NAFTA, the North American Free Trade I    Agreement, argue that it will encourage American companies to go south G    of the border to replace American workers with cheap, foreign labor. G    Fact is, our government is already encouraging American companies tosH    do ostensibly that, not south of the border--right here, north of theH    border, in the good old US of A. At a time when thousands of AmericanE    computer programmers are having a tough time finding work, some of@G    America's biggest companies are hiring cut-rate, foreign programmersr    to take their jobs...    4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  # Date: Wed, 03 Apr 2002 23:21:35 GMTt( From: "konabear" <maurert@ameritech.net>1 Subject: Re: Why VMS is "unhackable" lesson 1 ...e? Message-ID: <38Mq8.13400$k5.5026400@newssvr28.news.prodigy.com>r  : I half to know how to spell Fiorina, I'm married to one... Todd@ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message- news:%%Kq8.1837$fL6.37190@news.cpqcorp.net...o > ? > JF Mezei wrote in message <3CAB4350.CF63CE07@videotron.ca>...  > >Fred Kleinsorge wrote:tD > >> What is with you?  Do you have some personal insight into Carly > >nG > >Even the media calls her "Carly". Her real name is Carleton Fiorina.p > >uI > >> In fact, I don't really get the hostility against HP, let alone it'sc CEO.8 > >> What exactly have they done to warrent such hatred? > >o >cI > Since you ommitted the slanderous phrase, I'll omit part of your reply. K > Call her Carly, I call her Carly.  I can't say, let alone remember how tow > spell Fiorina. >'> > But the personal and sexists insults are a bit over the top. >" >  >s >s >t   ------------------------------  # Date: Thu, 04 Apr 2002 02:10:21 GMTm1 From: "David J. Dachtera" <djesys.nospam@fsi.net>f1 Subject: Re: Why VMS is "unhackable" lesson 1 ...n' Message-ID: <3CABB877.A2CBF449@fsi.net>a   Fred Kleinsorge wrote: > C > David J. Dachtera wrote in message <3CAA7950.35775270@fsi.net>...p >  > >"G > >It isn't Carly's "baby" until the results of the HP votes are known.f > >oK > >...and at 20+ years, I believe that would constitute O.S.-cide, not justeI > >another spineless, unprincipled, morally bankrupt tramp exercising heri6 > >"right" to attack and destroy a defenseless unborn. > >n > M > What is with you?  Do you have some personal insight into Carly (and I only J > call her Carly because I can never remember how to spell her last name)?L > Where do you get off calling her (I don't see another subject you could beE > talking about) a "spineless, unprincipled, morally bankrupt tramp".a > K > In fact, I don't really get the hostility against HP, let alone it's CEO.a5 > What exactly have they done to warrent such hatred?t  H I think you're reading a context into that which doesn't actually exist.H Read it again and you'll find that nowhere do I actually refer to anyoneH by name. The entire statement, like the statement to which if refers, is metaphoric, not accusatory.    --   David J. DachteraM dba DJE Systemsc http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/$   ------------------------------  # Date: Thu, 04 Apr 2002 02:17:25 GMTtL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")1 Subject: Re: Why VMS is "unhackable" lesson 1 ...d8 Message-ID: <00A0BEC4.45323610@SSRL04.SLAC.STANFORD.EDU>  k In article <xpGq8.1815$fL6.36984@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:h; >Here's a deal JF (do you have a name or just initials?)...x >tI >If Carly confirms the committment to the OpenVMS Itanium port - then you-H >quietlly go away, or just become a read-only member of the community.    M Actually, that would be a loss.  JF posts with answers to technical questionssL and raises interesting technical questions himself.  You should modify this K bet to "never post on the _future_ of VMS again."  (In my opinion, anyway.)s   >IfiM >VMS gets "aborted" as you put it (put into maintenance, retired, outsourced,nL >or the IA64 port cancelled) - I promise to apologize, say that you and BillI >are Gods, and that Andy-Pandy is the smartest guy I never met - and wills+ >never write in this conference ever again.g  # And that would be a loss as well.  d   -- Alan   O ===============================================================================r0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056eM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================l   ------------------------------   Date: 3 Apr 2002 17:45:40 -0800t( From: bob@instantwhip.com (Bob Ceculski)- Subject: Why VMS is "unhackable" lesson 3 ...n= Message-ID: <d7791aa1.0204031745.51c9a23b@posting.google.com>e  D Some here have contended that because TCP/IP Services for OpenVMS isF based on Tru64 Unix code, it is thus subject to the same level of risk9 of buffer-overflow exploits as any Unix system out there.e  ? After a bit of investigation, I've discovered that VMS on Alpha D appears to be immune to these common smash-the-stack buffer overflow attacks.  7 To understand why, first one must understand how commontB buffer-overflow attacks work.  (A classic paper on such attacks isD "Smashing the Stack for Fun And Profit" written by a hacker who goes* by the name Aleph One.  You can read it atD http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/profit.html)  @ A buffer-overflow exploit is done by passing an argument that isC larger than the buffer size to code which fails to check its size. iC The data is all stored, resulting in overwriting some memory beyondrD the end of the buffer.  Hackers know that C compilers often allocate> data space for buffers on the stack, and part of the data area@ overwritten on the stack includes the return address in the callA frame.  The hacker writes a return address that points to his own C code, which is also included in the area overwritten on the stack. f? The function then returns to his code instead of to the callingeC routine.  His malicious code then takes some dastardly action, likey; starting the Unix shell and executing an arbitrary command.V  D For a buffer-overflow exploit to succeed, then, the hacker must know? the address size of the the target architecture (for the returneD address), the format of the stack frame used by the architecture and< the compiler (to know where to put that return address), theF instruction set of the target architecture (so he can create his smallF program), and enough about the innards of the operating system for his? program to be able to do something useful once it is executing.a  E Attacks most commonly target Windows, or Solaris or other common Unix C variants, and because the attack must be so specific to a platform,eF these wouldn't affect VMS, because it has a different instruction set,F stack frame format, and so forth.  While that dramatically reduces theC statistical probability of an attack succeeding on VMS in practice,yA that alone doesn't rule out the possibility of an attack tailored  specifically for VMS on Alpha.  F Here is where excellent and fortuitous engineering design comes to theD rescue.  The Alpha memory management architecture provides some bitsD in the Page Table Entries (PTEs) that control what type of access isE allowed to memory.  For example, a read-only page can be protected by6D having the Fault-On-Write bit set, and any attempt to write the pageE causes a fault and results in a memory access violation error.  Alpha1F also has a Fault-On-Execute bit, designed to prevent an errant program= from jumping off into the weeds and trying to execute data asoD instructions.  On Alpha/VMS, the user stack is mapped with PTEs thatE have the Fault-On-Execute bit set, so any attempt to branch into datarA area on the stack results in an access violation, and the processc dies.   ? So Alpha VMS is immune to common stack-smashing buffer-overflow  attacks.  D While any code that fails to check data lengths against buffer sizesD is arguably broken, and needs to be fixed, and Compaq has been doingE this to TCP/IP code as buffer-overflow bugs are identified, such bugst@ are much less critical on Alpha VMS compared with less-protected implementations.. ----------------------------------------------. Keith Parris | parris at encompasserve dot org   ------------------------------  $ Date: Wed, 3 Apr 2002 17:48:49 -0800# From: "Tom Linden" <tom@kednos.com>,1 Subject: RE: Why VMS is "unhackable" lesson 3 ...e9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEAFELAA.tom@kednos.com>s   > -----Original Message-----1 > From: Bob Ceculski [mailto:bob@instantwhip.com]s) > Sent: Wednesday, April 03, 2002 5:46 PMt > To: Info-VAX@Mvb.Saic.Com / > Subject: Why VMS is "unhackable" lesson 3 ...  >  > F > Some here have contended that because TCP/IP Services for OpenVMS isH > based on Tru64 Unix code, it is thus subject to the same level of risk; > of buffer-overflow exploits as any Unix system out there.  > A > After a bit of investigation, I've discovered that VMS on AlphanF > appears to be immune to these common smash-the-stack buffer overflow
 > attacks. > 9 > To understand why, first one must understand how common,D > buffer-overflow attacks work.  (A classic paper on such attacks isF > "Smashing the Stack for Fun And Profit" written by a hacker who goes, > by the name Aleph One.  You can read it atF > http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/profit.html) > B > A buffer-overflow exploit is done by passing an argument that isE > larger than the buffer size to code which fails to check its size. nE > The data is all stored, resulting in overwriting some memory beyonduF > the end of the buffer.  Hackers know that C compilers often allocate@ > data space for buffers on the stack, and part of the data areaB > overwritten on the stack includes the return address in the callC > frame.  The hacker writes a return address that points to his ownoE > code, which is also included in the area overwritten on the stack. -A > The function then returns to his code instead of to the callingiE > routine.  His malicious code then takes some dastardly action, likei= > starting the Unix shell and executing an arbitrary command.. > F > For a buffer-overflow exploit to succeed, then, the hacker must knowA > the address size of the the target architecture (for the returneF > address), the format of the stack frame used by the architecture and> > the compiler (to know where to put that return address), theH > instruction set of the target architecture (so he can create his smallH > program), and enough about the innards of the operating system for hisA > program to be able to do something useful once it is executing.- > G > Attacks most commonly target Windows, or Solaris or other common Unix E > variants, and because the attack must be so specific to a platform,mH > these wouldn't affect VMS, because it has a different instruction set,H > stack frame format, and so forth.  While that dramatically reduces theE > statistical probability of an attack succeeding on VMS in practice,0C > that alone doesn't rule out the possibility of an attack tailoredu  > specifically for VMS on Alpha. > H > Here is where excellent and fortuitous engineering design comes to theF > rescue.  The Alpha memory management architecture provides some bitsF > in the Page Table Entries (PTEs) that control what type of access isG > allowed to memory.  For example, a read-only page can be protected bysF > having the Fault-On-Write bit set, and any attempt to write the pageG > causes a fault and results in a memory access violation error.  AlphaiH > also has a Fault-On-Execute bit, designed to prevent an errant program? > from jumping off into the weeds and trying to execute data asdF > instructions.  On Alpha/VMS, the user stack is mapped with PTEs thatG > have the Fault-On-Execute bit set, so any attempt to branch into dataiC > area on the stack results in an access violation, and the processc > dies.s  G If the hacker is able to determine the stack frame slot with the return7I address, why couldn't he also modify the stack allocation instruction and = insert his trojan horse in code space and execute from there?-   > A > So Alpha VMS is immune to common stack-smashing buffer-overflowr
 > attacks. > F > While any code that fails to check data lengths against buffer sizesF > is arguably broken, and needs to be fixed, and Compaq has been doingG > this to TCP/IP code as buffer-overflow bugs are identified, such bugsaB > are much less critical on Alpha VMS compared with less-protected > implementations.0 > ----------------------------------------------0 > Keith Parris | parris at encompasserve dot org >    ------------------------------  # Date: Thu, 04 Apr 2002 03:20:04 GMT # From: ualski <ualski@earthlink.net> 1 Subject: Re: Why VMS is "unhackable" lesson 3 ...s- Message-ID: <3CABC655.505A5F39@earthlink.net>a   Tom Linden wrote:n >  > > -----Original Message-----3 > > From: Bob Ceculski [mailto:bob@instantwhip.com],+ > > Sent: Wednesday, April 03, 2002 5:46 PMn > > To: Info-VAX@Mvb.Saic.Comr1 > > Subject: Why VMS is "unhackable" lesson 3 ...r -- ker-snipeJ > > Here is where excellent and fortuitous engineering design comes to theH > > rescue.  The Alpha memory management architecture provides some bitsH > > in the Page Table Entries (PTEs) that control what type of access isI > > allowed to memory.  For example, a read-only page can be protected byoH > > having the Fault-On-Write bit set, and any attempt to write the pageI > > causes a fault and results in a memory access violation error.  AlphawJ > > also has a Fault-On-Execute bit, designed to prevent an errant programA > > from jumping off into the weeds and trying to execute data asuH > > instructions.  On Alpha/VMS, the user stack is mapped with PTEs thatI > > have the Fault-On-Execute bit set, so any attempt to branch into dataoE > > area on the stack results in an access violation, and the processq	 > > dies.p > I > If the hacker is able to determine the stack frame slot with the returnKK > address, why couldn't he also modify the stack allocation instruction andj? > insert his trojan horse in code space and execute from there?o  H It would be difficult to execute instructions to change memory in a codeH space using the described method. Should the cracker (ok, hacker if he'sI doing it on his own machine just for fun) somehow gets code to execute onp9 the stack, executable sections are not usually writeable.   K Try it with a C program, get a pointer to the entry point of a function andrG try to change that first byte.I haven't tried this but you might make atI small array or whatever on the stack, put some code in it and try to call( it. My bet is it won't work.   -- Aaron Sliwinski   ------------------------------  # Date: Thu, 04 Apr 2002 02:42:01 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 9 Subject: Re: [Q] How to set up flag pages on HP printers?f' Message-ID: <3CABBFE3.518E7054@fsi.net>w   "Stuart, Ed" wrote:E > N > Hello all; we're running a mixed version (6.2 --> 7.2-1) OpenVMS cluster andN > using TCPware V5.3-2.  We've been asked to configure one of our printers (anJ > HPLJ 5 Si) to print a banner page before each job.  We have followed theE > procedures for adding a flag page to the queue.  The results from aeM > show/queue/full command are below.  We're using TCP/IP to reach the printera > and it has a Jet Direct card.d > % > ES_VOLTS$ show queue/full tlc_40016r@ > Server queue TLC_40016, idle, on VOLTS::, mounted form DEFAULT+ >   <HPLJ5SI - room 400.16 -  TLC Building>hA >   /BASE_PRIORITY=4 /DEFAULT=(FLAG,FORM=DEFAULT) /OWNER=[SYSTEM]eH >   /PROCESSOR=TCPWARE_TSSYM /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR  >   /SEPARATE=(RESET=(HP_RESET)) > I > The problem that we're having is that the flag page is being printed incJ > portrait format and the info would look much better if it was printed inN > landscape format.  How can we configure the queue so the flag page prints inI > landscape and the rest of the output is in whatever format the user hasA$ > requested via the /FORM qualifier?  ) Wow! That's a tough one, but here goes...t  F First, try setting the printer to landscape by default, then make sureG that every form (where appropriate) has a page setup module that forcesn	 portrait.e  > If that doesn't work, - well, I dunno. I've never tackled that particular problem before.   -- o David J. Dachterae dba DJE Systemsd http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/n   ------------------------------  # Date: Thu, 04 Apr 2002 03:04:05 GMTe1 From: "David J. Dachtera" <djesys.nospam@fsi.net>e9 Subject: Re: [Q] How to set up flag pages on HP printers?-' Message-ID: <3CABC50C.99A00DCE@fsi.net>p   "David J. Dachtera" wrote: >  > "Stuart, Ed" wrote:. > > P > > Hello all; we're running a mixed version (6.2 --> 7.2-1) OpenVMS cluster andP > > using TCPware V5.3-2.  We've been asked to configure one of our printers (anL > > HPLJ 5 Si) to print a banner page before each job.  We have followed theG > > procedures for adding a flag page to the queue.  The results from awO > > show/queue/full command are below.  We're using TCP/IP to reach the printer ! > > and it has a Jet Direct card.  > >p' > > ES_VOLTS$ show queue/full tlc_40016 B > > Server queue TLC_40016, idle, on VOLTS::, mounted form DEFAULT- > >   <HPLJ5SI - room 400.16 -  TLC Building>iC > >   /BASE_PRIORITY=4 /DEFAULT=(FLAG,FORM=DEFAULT) /OWNER=[SYSTEM]eJ > >   /PROCESSOR=TCPWARE_TSSYM /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR" > >   /SEPARATE=(RESET=(HP_RESET)) > >lK > > The problem that we're having is that the flag page is being printed inlL > > portrait format and the info would look much better if it was printed inP > > landscape format.  How can we configure the queue so the flag page prints inK > > landscape and the rest of the output is in whatever format the user has:& > > requested via the /FORM qualifier? > + > Wow! That's a tough one, but here goes...K > H > First, try setting the printer to landscape by default, then make sureI > that every form (where appropriate) has a page setup module that forces  > portrait.k   For clarification:  F On DEFINE/FORM, /SETUP refers to JOB setup module(s) while /PAGE_SETUPC refers to page setup modules. Job setup is sent before any file(s),i1 while page setups are sent before each file page.b  D On INIT/QUEUE, /SEPARATE=RESET refers to job reset modules which are? sent after files or file trailers, but before any job trailers.m  < Experiment and see if you can find a combination that works.   --   David J. Dachterau dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------   End of INFO-VAX 2002.185 ************************