0 INFO-VAX	Thu, 20 Jan 2005	Volume 2005 : Issue 39      Contents: Accounting Utility Re: Accounting Utility Re: Accounting Utility Re: Accounting Utility) Re: An Interview With Mr. OpenVMS Himself ) Re: An Interview With Mr. OpenVMS Himself  Error Codes  Re: Error Codes  Re: Error log message  Re: GnuPG in batch@ HAMMER down - apologies to Nugent (Was: Marcello blah blah blah) job anyware? Re: job anyware? Re: job anyware?1 Re: Marcello predicts 500% perfomance improvement 1 Re: Marcello predicts 500% perfomance improvement 1 Re: Marcello predicts 500% perfomance improvement 1 Re: Marcello predicts 500% perfomance improvement 1 Re: Marcello predicts 500% perfomance improvement , Mark G. Interview on Slashdot and OSNews.com Multi threaded cookbook ? # Re: Newbie Hobbyist NFS Question... # Re: Newbie Hobbyist NFS Question...  Re: Next Gen Fabs & Itanium  Re: Next Gen Fabs & Itanium  Re: Paradigm Re: Paradigm Re: Paradigm Re: Paradigm& pthread_create() call returning ENOMEM* Re: pthread_create() call returning ENOMEM* Re: pthread_create() call returning ENOMEM* Re: pthread_create() call returning ENOMEM Re: RMS  RMS (was: vms versus solaris) ! Re: RMS (was: vms versus solaris) ! Re: RMS (was: vms versus solaris)  satellite clusters Re: satellite clusters VMS Filename/type length Re: VMS Filename/type length Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: vms versus solaris Re: Webcast and VMS   F ----------------------------------------------------------------------    Date: 19 Jan 2005 11:09:14 -0800. From: andrew@floatingbear.ca (Andrew Butchart) Subject: Accounting Utility = Message-ID: <6d5df73f.0501191109.41c7904c@posting.google.com>   A We are trying to capture use of the Authorize and SYSGEN programs E within our Open VMS 7.1 system.  We currently have accounting enabled E and set to record image however usage of these programs does not seem  to be tracked.  F Am I missing something or is there a setup in ACCOUNTING that needs to be defined?    Thanks   andrew@floatingbear.ca   ------------------------------  % Date: Wed, 19 Jan 2005 20:40:03 +0100 0 From: Keith Cayemberg <keith.cayemberg@arcor.de> Subject: Re: Accounting Utility @ Message-ID: <41eeb794$0$822$9b4e6d93@newsread2.arcor-online.net>   Andrew Butchart wrote:  C > We are trying to capture use of the Authorize and SYSGEN programs G > within our Open VMS 7.1 system.  We currently have accounting enabled G > and set to record image however usage of these programs does not seem  > to be tracked. > H > Am I missing something or is there a setup in ACCOUNTING that needs to
 > be defined?  >  > Thanks >  > andrew@floatingbear.ca  H I would suggest trying the SET AUDIT command and studying Alarm ACLs as  well.   F Image accounting usually creates rapidly growing accounting files, be G careful about leaving such a configuration on in an active system over   night.   Cheers!    Keith Cayemberg    ------------------------------    Date: 19 Jan 2005 14:08:55 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Accounting Utility 3 Message-ID: <atvy+ANVMRvN@eisner.encompasserve.org>   s In article <41eeb794$0$822$9b4e6d93@newsread2.arcor-online.net>, Keith Cayemberg <keith.cayemberg@arcor.de> writes:  > Andrew Butchart wrote: > D >> We are trying to capture use of the Authorize and SYSGEN programsH >> within our Open VMS 7.1 system.  We currently have accounting enabledH >> and set to record image however usage of these programs does not seem >> to be tracked.  >>  I >> Am I missing something or is there a setup in ACCOUNTING that needs to  >> be defined? >>  	 >> Thanks  >>   >> andrew@floatingbear.ca  > J > I would suggest trying the SET AUDIT command and studying Alarm ACLs as  > well.   E In particular, someone might use system services to change the values H that Authorize and SYSGEN change.  It would be a mistake to only monitor the unclever people.   ------------------------------  % Date: Wed, 19 Jan 2005 15:23:21 -0500  From: norm.raphael@metso.com Subject: Re: Accounting Utility Q Message-ID: <OF0F594DE2.D3E78A0D-ON85256F8E.006FF557-85256F8E.00703635@metso.com>    You might want to do this.   INSTALL      ADD        /ACCOUNTING              /ACCOUNTING !           /NOACCOUNTING (default)   G        Enables image-level accounting for selected images even if image A        accounting is disabled on the local node (by using the DCL C        command SET ACCOUNTING/DISABLE=IMAGE). When image accounting @        is enabled on the local node, it logs all images, and the-        /NOACCOUNTING qualifier has no effect.   K Keith Cayemberg <keith.cayemberg@arcor.de> wrote on 01/19/2005 02:40:03 PM:    > Andrew Butchart wrote: > E > > We are trying to capture use of the Authorize and SYSGEN programs I > > within our Open VMS 7.1 system.  We currently have accounting enabled I > > and set to record image however usage of these programs does not seem  > > to be tracked. > > J > > Am I missing something or is there a setup in ACCOUNTING that needs to > > be defined?  > > 
 > > Thanks > >  > > andrew@floatingbear.ca > I > I would suggest trying the SET AUDIT command and studying Alarm ACLs as  > well.  > G > Image accounting usually creates rapidly growing accounting files, be H > careful about leaving such a configuration on in an active system over > night. > 	 > Cheers!  >  > Keith Cayemberg    ------------------------------    Date: 19 Jan 2005 13:05:44 -0800 From: bob@instantwhip.com 2 Subject: Re: An Interview With Mr. OpenVMS HimselfB Message-ID: <1106168744.369097.66340@c13g2000cwb.googlegroups.com>   Kenneth Farmer wrote:  > ShannonKnowsHPC.com:C > http://www.shannonknowshpc.com/stories.php?story=05/01/18/0435366  >  >  >  > Ken  > 
 > OpenVMS.org ' > _____________________________________  > Kenneth R. Farmer <>< ' > SpyderByte: http://www.SpyderByte.com   4 I certainly hope Terry is right ... but you need the5 marketing and solutions to be there for it to happen!    ------------------------------  % Date: Wed, 19 Jan 2005 15:39:13 -0500 ( From: Bill Todd <billtodd@metrocast.net>2 Subject: Re: An Interview With Mr. OpenVMS Himself= Message-ID: <kYOdnclDOoTzWHPcRVn-1g@metrocastcablevision.com>    Kenneth Farmer wrote:  > ShannonKnowsHPC.com:C > http://www.shannonknowshpc.com/stories.php?story=05/01/18/0435366   F What a disappointment:  I thought you meant that Terry had snagged an  interview with Cutler.   - bill   ------------------------------    Date: 19 Jan 2005 15:11:22 -0800 From: errorcodeforum@gmail.com Subject: Error CodesC Message-ID: <1106176282.883764.114050@f14g2000cwb.googlegroups.com>   G Please help with my new site. Post all of your error codes and fixes to  www.ErrorCodeForum.com Thanks Spyro    ------------------------------    Date: 19 Jan 2005 22:24:33 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: Error Codes3 Message-ID: <AZR2l3UD+mJJ@eisner.encompasserve.org>   d In article <1106176282.883764.114050@f14g2000cwb.googlegroups.com>, errorcodeforum@gmail.com writes:I > Please help with my new site. Post all of your error codes and fixes to  > www.ErrorCodeForum.com  ' The complaint address for that spam is:   ( X-Complaints-To: groups-abuse@google.com   ------------------------------  % Date: Wed, 19 Jan 2005 19:53:35 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: Error log message+ Message-ID: <41EF0F1F.230D4E6E@comcast.net>    johnhreinhardt@yahoo.com wrote:  > " > NI-SCS SUB-SYSTEM, _VX4500$PEA0: > E > Would seem to indicate it was using a LAN interface for the cluster  > interconnect, wouldn't it?     Quite so, yes!  - > If so, start checking the networking cards, I > cables, switch/hub and the settings on all of these to see if something  > has changed or gone bad.  D We had a similar problem here. Our dev. cluster was reporting errorsG complaining about a bad cluster password, when it really was a bad NIC.    --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/    Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Wed, 19 Jan 2005 22:01:54 -0600 ' From: "Tom M" <kryios@spam.comcast.net>  Subject: Re: GnuPG in batch 0 Message-ID: <LKWdnVEwj7tgsHLcRVn-jg@comcast.com>  2 "David Gray" <police@spamcop.net> wrote in message2 news:ccssu09lrehgkq3a6rik3nvdluhblah07p@4ax.com...	 > Hi all,  >  > OpenVMS 7.3-2  > GnuPG  v1.2.3  > F > Has anyone got an example of how to use the PASSPHRASE-FD command ofE > GnuPG when running in batch?  I've searched the net but cannot find % > any examples of it's use under VMS.  > D > I'm currently writing the GPG command into a temporay command file< > with the passphrase on the second line but wondered if the2 > PASSPHRASE-FD would provide a 'neater' solution. >  >  > Thanks in advance  > Dave.   4 You can embed the passphrase in the command file as:  5 $gpg --batch --passphrase-fd 0 --decryptfile 'pgpfile 
 passphrase  . Don't know if thats what you were looking for.   ------------------------------    Date: 20 Jan 2005 00:23:57 -0600+ From: young_r@encompasserve.org (Rob Young) I Subject: HAMMER down - apologies to Nugent (Was: Marcello blah blah blah) 3 Message-ID: <hfTguZDyU8z8@eisner.encompasserve.org>   T In article <41EF3B60.10805@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes: > Rob Young wrote: > Y >> In article <41EDD151.7020004@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes:  >>   >>>FredK wrote:  >>>  >>> 8 >>>>"Dave Froble" <davef@tsoft-inc.com> wrote in message >>>> >>   >>> B >>>>Alpha, Itanium.  Doesn't really matter much if it isn't a VAX.< >>>>Alpha was a pain in the ass to be honest - and only it's@ >>>>speed made it worth the pain.  Itanium is a pain in the ass,> >>>>but it will result in lower prices and higher performance.? >>>>Could we be building Alphas that outperform Itanium?  Sure, < >>>>probably.  But with enough money and enough smart people; >>>>we could probably be building VAX (or VAX-like) systems  >>>>that outperform Alpha. >>>> >>> F >>>What can I say.  It's beyond anything I could have dreamed of.  :-) >>>  >>>  >>  C >> 	VAX?  Cough.  It is dreaming.  And uneconomical dreams at that.  >  > Q > Uh...  Rob.... We were talking about back when it could have been significant.  R > If VAX hadn't had a period when it's performance vs other CPUs sucked, then VMS ; > might not have lost market share at the rate that it did.  > R > Several other ifs would have had to occur, longer term, such as going after the  > high volume low cost market. >   = 	And if you would have read the whole thing, prior to posting @ 	perhaps you would have stumbled upon the merchant CPU argument.   > G >> 	Is it any accident that Samsung and a host of others are partnering E >> 	with IBM for next-gen FAB?  Reports are 45nm will cost $3 billion @ >> 	plus per FAB.  IBM micro-electronics gets to lose money much >> 	faster, imagine that!  >>  = >> 	It's all about merchant MPU it appears.  At least that is 9 >> 	how Paul has been edukatin Linux T over at realworld:  >>   >> http://tinyurl.com/52jdz  >>  . >> Name: Paul DeMone (pdemone@igs.net) 1/19/05 >>  7 >> Linus Torvalds (torvalds@osdl.org) on 1/19/05 wrote:  >> --------------------------- >>  2 >>>Paul DeMone (pdemone@igs.net) on 1/18/05 wrote: >>> ; >>>>A merchant processor is a processor offered by a vendor < >>>>whose business model is selling processors to all takers2 >>>>rather than bundled inside a system they sell. >>>>; >>>That's what I assumed you have to mean, but the economic 9 >>>importance you place on this still totally escapes me.  >>>  >>  9 >> Let me make this as simple for you as possible. An MPU 8 >> that costs $125 to fabricate will always be much more8 >> capable than a processor that costs $30 to fabricate,9 >> both being in the same technology. But the mass market 8 >> (PCs) is happy with the $30 MPU and is willing to buy >>  $ >>>100m of them a year at ~$150 ASP. >>>  >>  5 >> But some sockets demand more performance, RAS, and : >> or scalability than a $30 mass market chip can provide.9 >> This high end market wants the $125 MPU and is willing 9 >> buy >1.5m of them a year at $1500+ ASP. For nearly the 9 >> last two decades this market has been serviced by five 3 >> major OEMs each with their own RISC MPU families : >> that each shipped in its own systems. But this tower of; >> babel is inefficient because of the multiplicity of ISAs ; >> slicing up the same market, the duplication of effort in 7 >> making similar but incompatible MPUs, and the vendor ) >> lock-in effect with each ISA/platform.  >>  8 >> A merchant chip family like IPF will allow the market5 >> for high end chips/systems to consolidate around a 7 >> single processor family and ISA. This eliminates the ? >> duplication of effort (effort which was starting to kill off 7 >> the smaller players anyways with the escalating cost 5 >> of high end MPU development). The reduction in the 5 >> number of ISAs in the high end market improves ISV 6 >> efficiency. And from the customer's perspective the3 >> move of high end systems market to merchant MPUs 3 >> *increases* competition among OEMs because there , >> is no longer an ISA-based lock-in effect. >  > N > It's a bit sickening to think that once again the lowest common denominator  > is the people's choice.  >   = 	Sometimes its about money and sometimes it is about whatever ) 	you care to get.  Money mostly wins out.    > J >> 	VAX was doomed, Alpha was doomed.  SPARC is doomed (shocka), Power is E >> 	doomed (strong arguments here against that view, but hey it is a  2 >> 	Tower of Babel IBM micro is building on ;-).   >  > L > IBM is a special case.  As long as their resolve holds out, they will not # > give in and accept a lesser chip.   ? 	That's funny.  Funny because IBM ditched their money losing PC ; 	business.  It wasn't revealed until after they sold it how 8 	much of a loser it was.  A wonderful thing filings are:  . http://in.tech.yahoo.com/041231/137/2irbt.html  2 IBM PC unit sold to Lenovo built up $1 bln deficit  E SAN FRANCISCO (Reuters) - IBM's PC unit piled up nearly $1 billion in K cumulative losses in recent years, the company said in a filing on Thursday D detailing the planned sale of the business to China's Lenovo Group.   B 	Guess what?  IBM micro has been a big loser for years.  Hold out?A 	Nah.  It's about business, therefore money.  Here is an internal  	IBM exchange:  ) 	"This is stupid, we are bleeding badly." 7 	"Maybe we can get others to help us prop up this pig?" $ 	"Yeah, how about Samsung and Sony."$ 	"Any other suckers, I mean takers?" 	"See what we can do."  7 	"But you know this will only stem the bleeding a bit." ' 	"So when do we knife micro and Power?"  	"Not yet, I like Power" 	"Like?  We are bleeding"  	"I like Power" $ 	"You gonna continue to pay for it?") 	"Uhh.... can I get back to you on that?"    	And then one day:  ; 	"You know, this is a lot like that PC division pig we just 
 	off-loaded." % 	"Can we dress up micro and sell it?" " 	"Can't find a sucker - just yet."  6 >  Who was it that killed off VAX and Alpha.  We have S > the likes of Palmer and Capalles.  Did they really understand the technology?  I  C > doubt it.  Nor did they have the resolve to "do the right thing".   A 	Right.  Vision was they needed a RISC.  Fair enough vision circa ; 	1980.  But guess what?  The vision is merchant circa 2005.  > R > Back in 1960 Ford motor company suffered under the incluence of a bean counter. R >   Their car sales suffered because of this.  Only when they went back to people N > who loved the automobile and wanted to build "good" cars did their fortunes P > reverse.  Then the asshole got into government, and was a significant part of $ > the total fiasco that was Vietnam.   	Okay...  B 	But you can't compare to autos.  As one gent pointed out a single= 	FAB cost more than the entire Manhattan Project.  The monies @ 	are incredible.  IBM micro can hold out so long.  Sun is doomed 	early.  > A >> 	I'd gander the shake-out will leave IPF, x86 (no-brainer) and @ >> 	x86-64 or whatever the ISA is.  The shakeout will take up to; >> 	10 years for some to disappear, SPARC goes much faster.  >  > 5 > I see your consistant hate of Sun coming out again.   E 	Dude - every time some one trots out Sun, I point out the realities. % 	Sun is a wanna-be and it is obvious.   P > I always like it when some know-it-all predicts what's going to happen, based Q > upon their wishes.  Rob sure called it right on HAMMER, huh?  Like they say in  Q > football, when upsets happen.  "That's why they play the game."  Well Rob, the   > game isn't over yet.  ? 	I still don't see it in a Dell box.  I don't see it doing well ? 	at all.  And yeah, I guess I did nail HAMMER - but it is still 
 	playing out.   ( 	Intel is a $153 billion dollar company,? 	AMD is an $8 billion dollar companty (market cap).  In Q2 2004 A 	breakout of Opteron versus Itanium revenues (courtesy of Gartner  	via the Reg):  A http://www.theregister.co.uk/2004/08/30/opteron_itanium_sales_q2/   3 	The Q2 market for IPF servers was 5665 units worth 9 	$319m and for Opteron servers was 60k units worth $191m.    ---   > 	Servers - not CPUs.  But you can see that Q2 2004 Itanium wasA 	about double the size of Opteron in revenue.  Sure, more Opteron : 	boxes about.  1, 2-way boxes.  Certainly not making money# 	at that run rate and those prices.   " 	Opteron is sliding badly already:  = http://www.theregister.co.uk/2005/01/13/amd_euro_share_slide/   I After tracking Opteron sales throughout Europe's seven biggest economies, K Context today said that sales growth collapsed during the early month of Q4 L 2004.  [Early month of Q4?  Sheesh - why not just come out and say October?]  M In Q3 2004, sales grew month on month by up to 50 per cent, but October sales N were only 8.6 per cent up on September. In November, sales fell 18 per cent onD the previous month. Numbers for December 2004 are not yet available.  O Context expects Opteron-based servers to take under one percentage point of x86 . server market share in Europe during Q4 2004.    ---   G 	Sales fell 18 percent in Europe November compared to October.  Opteron A 	lost its traction in Europe.  I'll bet it is losing its traction ? 	here too.  Come back in 6 months and tell me a HAMMER story.   C 	Fact is, Opteron is sinking, and you know it.  Or are learning it.  	  	Grin ->  B^)      				Rob    ------------------------------  % Date: Wed, 19 Jan 2005 21:31:09 +0100 # From:  Ove Axelsson < m8742@abc.se>  Subject: job anyware? 8 Message-ID: <5fgtu0d5tc06cdqb1vaa8613bpkjhidvlm@4ax.com>  2 I have been system manager at Digital for 10 years3 I have also been in charge of approx 80 VMS systems     Please have a look at my webpage( http://www.abc.se/~m8742/english/abc_eng any suggestion appreciated.  I am prepared to relocate.   Regards  Ove    ------------------------------    Date: 19 Jan 2005 15:31:47 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: job anyware? 3 Message-ID: <QAJUraocjDp4@eisner.encompasserve.org>   ^ In article <5fgtu0d5tc06cdqb1vaa8613bpkjhidvlm@4ax.com>,  Ove Axelsson < m8742@abc.se> writes:4 > I have been system manager at Digital for 10 years5 > I have also been in charge of approx 80 VMS systems  > " > Please have a look at my webpage* > http://www.abc.se/~m8742/english/abc_eng > any suggestion appreciated.    I recommend   + 	http://www.openvms.org/phorum/list.php?f=2   0 as a forum where VMS-related jobs are discussed.   ------------------------------  # Date: Wed, 19 Jan 2005 22:36:44 GMT , From: "Ransom Fitch" <rlf_vms@earthlink.net> Subject: Re: job anyware? @ Message-ID: <0iBHd.385$YD5.205@newsread3.news.pas.earthlink.net>  # Post resume as HTML as well as PDF.    Regards, Ransom Fitch    0 "Ove Axelsson" < m8742@abc.se> wrote in message 2 news:5fgtu0d5tc06cdqb1vaa8613bpkjhidvlm@4ax.com...3 >I have been system manager at Digital for 10 years 5 > I have also been in charge of approx 80 VMS systems  > " > Please have a look at my webpage* > http://www.abc.se/~m8742/english/abc_eng > any suggestion appreciated.  > I am prepared to relocate. > 	 > Regards  > Ove    ------------------------------  % Date: Wed, 19 Jan 2005 16:07:13 -0500 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> : Subject: Re: Marcello predicts 500% perfomance improvement, Message-ID: <41EECBF9.B56D4E10@teksavvy.com>   FredK wrote:M > The volume is better, even if it isn't the size of the x86 business.  HP-UX ' > is a bigger business than Tru64 was.    F At what point in 2004 did revenus for IA64-HPUX surpass PARISC-HPUX ? C Last I heard, IA64 revenus hadn't even reached the target of 20% of  enterprise server revenus.  $ > The UNIX world is shrinking to the; > point of only having 2-3 serious vendors HP, IBM and SUN.   D A a gazillion vendors of industry standard Linux running on industry standard servers.   I > SUN is the one who has not been able to at least squeek out break even. D > POWER and Itanium will be the only 2 surviving RISC architectures.  D SPARC will outlive IA64. For one thing, it has a huge installed base3 compared to IA64 which is essentially a stillbirth.     9 > I haven't seen "mission critical" Linux or Windows yet,   B The USA navy has had experience with mission critical Windows. TheB NASDAQ runs its primary web site on Windows. And I think there areE plenty of examples of this. I pointed to an article where the biggest F supplier of McDonalds in the USA was down for about 2 weeks because of
 windows viri.     H As far as Linux is concerned, it is now embedded in so many devices thatC I wouldn't be surprised if many VMS shops had some mission critical F "device" on their network that runs linux inside. (think routers, disk
 storage etc).     D > We've (VMS) invested 3-1/2 years of time and money in Itanium, andG > for the forseable future, I don't see large scale AMD 64 systems with ' > mission  critical Windows and Linux.    H The issue here is that you have no installed base on IA64. The InstalledD base is on PA Risc and Alpha (and MIPS for Tandem). What you have toD look at is a few years ahead, when the 8086 may be scalable to largeH systems.  Consider that AMD will have an 8086 with dual cores out before IA64. H Consider what the 8086 and Power will be like in the 2007-2008 timeframe compared to IA64.   G If the performance and scalability differences of 8086 versus IA64 will = be small, how could Intel/HP/SGI continue to justify the huge F expenditures required to have IA64 follow the other chips with its own= very different core and own set of very different compilers ?   F Remember that AMD didn't die as predicted and now has a hot 8086 basedH product. This has forced Intel to also plan a 64 bit 8086 and will force2 Intel to develop the 8086 very fast to match AMD.   H Had AMD died, Intel would have had a much easier job of keeping IA64 forF servers and 8086 for desktops since there woudln't be any pressuire to9 push the 8086 beyond its ability play 3D games very fast.   F But that isn't the case. And IA64 must compete not only against Sparc,G Alpha, Pa-Risc, Power but also against the 8086 (I included PA-Risc and H Alpha since for the next couple of years, they remain in the competitionD because the cost of converting to IA64 won't be worth the conversionC costs, especially if the 3rd party software doesn't exist on IA64).     - > The latest public move with Itanium removes F > any stigma of having HP (a system competetor) from controlling IA64,' > or having an unfair inside advantage.   H Public saw this as HP cutting losses from the IA64 programme. It is alsoH a way for HP to shift part of the partner costs to SGI.  Since Intel nowB bears the full development costs, it should normally price IA64 to@ recuperate those costs based on current volumes. This means thatE development costs will be passed on to all buyers of IA64, notably HP : and SGI. So more expensive IA64 chips for both HP and SGI.    G HP would brag about this still being less expensive than developing the A chip in-house. But consider this: Digital had top notch engineers > working in an environment that put Alpha in the forefront withG relatively small budgets.  So much so that even with unlimited budgets, D Intel still had to steal from Alpha to make its 8086 perform faster.  F And I don't think that one can argue that Alpha was the result of onlyE better brains. There must have been a better environment and a better E mandate given to engineers to result is such a dramatic difference in H team performance when you compare deliverables of Alpha during the 1990s+ vs deliverables from IA64 during the 1990s.   H If the whole premise of EPIC is flawed, no matter how hard and how manytG brains you put on it, it won't make it right. And you'll still be stuck E with a low volume chip that requires specialized compilers to get the O promised performance to a much greater extent than on Alpha or other platforms.   D > Just because there are dissapointed people out there mad about theC > demise of Alpha, does not mean that Itanium cannot succeed as one H > of the 2 premier high-end, mission critical, UNIX (and VMS) platforms.  F Look, VMS isn't exactly a success story. It isn't being marketed. VMS'C success is that it isn't dead yet. (and it is a big accomplishement < considering the self inflicted wounds over the last decade).  J > Will x86 be able to be grown "up" into this role?  Time will tell.  With  > enough thrust, a pig will fly.  = The problem is that the 8086 has plenty of thrust, and it has E competition from AMD which forced Intel to put all its resources into  protecting the 8086.   ------------------------------  # Date: Wed, 19 Jan 2005 21:18:44 GMT 6 From: "Kenneth Farmer" <kfarmer@NOSPAM.spyderbyte.com>: Subject: Re: Marcello predicts 500% perfomance improvement= Message-ID: <U8AHd.5521$K72.1236302@twister.southeast.rr.com>    This might be of interest.  3 BigTux project shows Linux scaling to 64 processors 2 http://news.zdnet.co.uk/0,39020330,39184546,00.htm     Ken    OpenVMS.org % _____________________________________  Kenneth R. Farmer <>< % SpyderByte: http://www.SpyderByte.com       ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  & news:41EECBF9.B56D4E10@teksavvy.com... > FredK wrote:H >> The volume is better, even if it isn't the size of the x86 business.  >> HP-UX' >> is a bigger business than Tru64 was.  > G > At what point in 2004 did revenus for IA64-HPUX surpass PARISC-HPUX ? E > Last I heard, IA64 revenus hadn't even reached the target of 20% of  > enterprise server revenus. > % >> The UNIX world is shrinking to the < >> point of only having 2-3 serious vendors HP, IBM and SUN. > F > A a gazillion vendors of industry standard Linux running on industry > standard servers.  > J >> SUN is the one who has not been able to at least squeek out break even.E >> POWER and Itanium will be the only 2 surviving RISC architectures.  > F > SPARC will outlive IA64. For one thing, it has a huge installed base5 > compared to IA64 which is essentially a stillbirth.  >  > : >> I haven't seen "mission critical" Linux or Windows yet, > D > The USA navy has had experience with mission critical Windows. TheD > NASDAQ runs its primary web site on Windows. And I think there areG > plenty of examples of this. I pointed to an article where the biggest H > supplier of McDonalds in the USA was down for about 2 weeks because of > windows viri.  >  > J > As far as Linux is concerned, it is now embedded in so many devices thatE > I wouldn't be surprised if many VMS shops had some mission critical H > "device" on their network that runs linux inside. (think routers, disk > storage etc).  >  > E >> We've (VMS) invested 3-1/2 years of time and money in Itanium, and H >> for the forseable future, I don't see large scale AMD 64 systems with' >> mission  critical Windows and Linux.  > J > The issue here is that you have no installed base on IA64. The InstalledF > base is on PA Risc and Alpha (and MIPS for Tandem). What you have toF > look at is a few years ahead, when the 8086 may be scalable to largeJ > systems.  Consider that AMD will have an 8086 with dual cores out before > IA64. J > Consider what the 8086 and Power will be like in the 2007-2008 timeframe > compared to IA64.  > I > If the performance and scalability differences of 8086 versus IA64 will ? > be small, how could Intel/HP/SGI continue to justify the huge H > expenditures required to have IA64 follow the other chips with its own? > very different core and own set of very different compilers ?  > H > Remember that AMD didn't die as predicted and now has a hot 8086 basedJ > product. This has forced Intel to also plan a 64 bit 8086 and will force3 > Intel to develop the 8086 very fast to match AMD.  > J > Had AMD died, Intel would have had a much easier job of keeping IA64 forH > servers and 8086 for desktops since there woudln't be any pressuire to; > push the 8086 beyond its ability play 3D games very fast.  > H > But that isn't the case. And IA64 must compete not only against Sparc,I > Alpha, Pa-Risc, Power but also against the 8086 (I included PA-Risc and J > Alpha since for the next couple of years, they remain in the competitionF > because the cost of converting to IA64 won't be worth the conversionE > costs, especially if the 3rd party software doesn't exist on IA64).  >  > . >> The latest public move with Itanium removesG >> any stigma of having HP (a system competetor) from controlling IA64, ( >> or having an unfair inside advantage. > J > Public saw this as HP cutting losses from the IA64 programme. It is alsoJ > a way for HP to shift part of the partner costs to SGI.  Since Intel nowD > bears the full development costs, it should normally price IA64 toB > recuperate those costs based on current volumes. This means thatG > development costs will be passed on to all buyers of IA64, notably HP < > and SGI. So more expensive IA64 chips for both HP and SGI. >  > I > HP would brag about this still being less expensive than developing the C > chip in-house. But consider this: Digital had top notch engineers @ > working in an environment that put Alpha in the forefront withI > relatively small budgets.  So much so that even with unlimited budgets, F > Intel still had to steal from Alpha to make its 8086 perform faster. > H > And I don't think that one can argue that Alpha was the result of onlyG > better brains. There must have been a better environment and a better G > mandate given to engineers to result is such a dramatic difference in J > team performance when you compare deliverables of Alpha during the 1990s- > vs deliverables from IA64 during the 1990s.  > J > If the whole premise of EPIC is flawed, no matter how hard and how manytI > brains you put on it, it won't make it right. And you'll still be stuck G > with a low volume chip that requires specialized compilers to get the G > promised performance to a much greater extent than on Alpha or other   > platforms. > E >> Just because there are dissapointed people out there mad about the D >> demise of Alpha, does not mean that Itanium cannot succeed as oneI >> of the 2 premier high-end, mission critical, UNIX (and VMS) platforms.  > H > Look, VMS isn't exactly a success story. It isn't being marketed. VMS'E > success is that it isn't dead yet. (and it is a big accomplishement > > considering the self inflicted wounds over the last decade). > K >> Will x86 be able to be grown "up" into this role?  Time will tell.  With ! >> enough thrust, a pig will fly.  > ? > The problem is that the 8086 has plenty of thrust, and it has G > competition from AMD which forced Intel to put all its resources into  > protecting the 8086.     ------------------------------  # Date: Thu, 20 Jan 2005 01:37:30 GMT   From: John Santos <john@egh.com>: Subject: Re: Marcello predicts 500% perfomance improvement& Message-ID: <uXDHd.34$BL3.14@trnddc01>   JF Mezei wrote:i  J > As far as Linux is concerned, it is now embedded in so many devices thatE > I wouldn't be surprised if many VMS shops had some mission critical H > "device" on their network that runs linux inside. (think routers, disk > storage etc).o   My Tivo...  ;-)o  D (Which will be networked with my VAX as soon as it's networked with 
 anything.)   -- v John Santosa Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 19 Jan 2005 21:14:03 -0600+ From: young_r@encompasserve.org (Rob Young)i: Subject: Re: Marcello predicts 500% perfomance improvement3 Message-ID: <4Y6IDUr3xsxE@eisner.encompasserve.org>e  V In article <41EDD151.7020004@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes: > FredK wrote: > 7 >> "Dave Froble" <davef@tsoft-inc.com> wrote in messagei   >  > A >> Alpha, Itanium.  Doesn't really matter much if it isn't a VAX.); >> Alpha was a pain in the ass to be honest - and only it'sN? >> speed made it worth the pain.  Itanium is a pain in the ass,w= >> but it will result in lower prices and higher performance.e> >> Could we be building Alphas that outperform Itanium?  Sure,; >> probably.  But with enough money and enough smart people : >> we could probably be building VAX (or VAX-like) systems >> that outperform Alpha.  >  > E > What can I say.  It's beyond anything I could have dreamed of.  :-)s >   @ 	VAX?  Cough.  It is dreaming.  And uneconomical dreams at that.  D 	Is it any accident that Samsung and a host of others are partneringB 	with IBM for next-gen FAB?  Reports are 45nm will cost $3 billion= 	plus per FAB.  IBM micro-electronics gets to lose money much  	faster, imagine that!  : 	It's all about merchant MPU it appears.  At least that is6 	how Paul has been edukatin Linux T over at realworld:   http://tinyurl.com/52jdz  + Name: Paul DeMone (pdemone@igs.net) 1/19/05-  4 Linus Torvalds (torvalds@osdl.org) on 1/19/05 wrote: ---------------------------e0 >Paul DeMone (pdemone@igs.net) on 1/18/05 wrote: >>9 >>A merchant processor is a processor offered by a vendor : >>whose business model is selling processors to all takers0 >>rather than bundled inside a system they sell. > 9 >That's what I assumed you have to mean, but the economice7 >importance you place on this still totally escapes me.N  6 Let me make this as simple for you as possible. An MPU5 that costs $125 to fabricate will always be much moree5 capable than a processor that costs $30 to fabricate,k6 both being in the same technology. But the mass market5 (PCs) is happy with the $30 MPU and is willing to buyr" >100m of them a year at ~$150 ASP.  2 But some sockets demand more performance, RAS, and7 or scalability than a $30 mass market chip can provide.W6 This high end market wants the $125 MPU and is willing6 buy >1.5m of them a year at $1500+ ASP. For nearly the6 last two decades this market has been serviced by five0 major OEMs each with their own RISC MPU families7 that each shipped in its own systems. But this tower ofl8 babel is inefficient because of the multiplicity of ISAs8 slicing up the same market, the duplication of effort in4 making similar but incompatible MPUs, and the vendor& lock-in effect with each ISA/platform.  5 A merchant chip family like IPF will allow the market-2 for high end chips/systems to consolidate around a4 single processor family and ISA. This eliminates the< duplication of effort (effort which was starting to kill off4 the smaller players anyways with the escalating cost2 of high end MPU development). The reduction in the2 number of ISAs in the high end market improves ISV3 efficiency. And from the customer's perspective the 0 move of high end systems market to merchant MPUs0 *increases* competition among OEMs because there) is no longer an ISA-based lock-in effect.h   ---u  G 	VAX was doomed, Alpha was doomed.  SPARC is doomed (shocka), Power is sB 	doomed (strong arguments here against that view, but hey it is a / 	Tower of Babel IBM micro is building on ;-).  a  > 	I'd gander the shake-out will leave IPF, x86 (no-brainer) and= 	x86-64 or whatever the ISA is.  The shakeout will take up tom8 	10 years for some to disappear, SPARC goes much faster.   				RobS   ------------------------------  % Date: Thu, 20 Jan 2005 00:02:24 -0500 ' From: Dave Froble <davef@tsoft-inc.com>e: Subject: Re: Marcello predicts 500% perfomance improvement* Message-ID: <41EF3B60.10805@tsoft-inc.com>   Rob Young wrote:  X > In article <41EDD151.7020004@tsoft-inc.com>, Dave Froble <davef@tsoft-inc.com> writes: >  >>FredK wrote: >> >>7 >>>"Dave Froble" <davef@tsoft-inc.com> wrote in message  >>>u >  >>A >>>Alpha, Itanium.  Doesn't really matter much if it isn't a VAX.m; >>>Alpha was a pain in the ass to be honest - and only it'sn? >>>speed made it worth the pain.  Itanium is a pain in the ass,a= >>>but it will result in lower prices and higher performance.l> >>>Could we be building Alphas that outperform Itanium?  Sure,; >>>probably.  But with enough money and enough smart people/: >>>we could probably be building VAX (or VAX-like) systems >>>that outperform Alpha.  >>>u >>E >>What can I say.  It's beyond anything I could have dreamed of.  :-)n >> >> > B > 	VAX?  Cough.  It is dreaming.  And uneconomical dreams at that.    O Uh...  Rob.... We were talking about back when it could have been significant. tP If VAX hadn't had a period when it's performance vs other CPUs sucked, then VMS 9 might not have lost market share at the rate that it did.t  P Several other ifs would have had to occur, longer term, such as going after the  high volume low cost market.    F > 	Is it any accident that Samsung and a host of others are partneringD > 	with IBM for next-gen FAB?  Reports are 45nm will cost $3 billion? > 	plus per FAB.  IBM micro-electronics gets to lose money much- > 	faster, imagine that! > < > 	It's all about merchant MPU it appears.  At least that is8 > 	how Paul has been edukatin Linux T over at realworld: >  > http://tinyurl.com/52jdz > - > Name: Paul DeMone (pdemone@igs.net) 1/19/05c > 6 > Linus Torvalds (torvalds@osdl.org) on 1/19/05 wrote: > ---------------------------_ > 1 >>Paul DeMone (pdemone@igs.net) on 1/18/05 wrote:  >>: >>>A merchant processor is a processor offered by a vendor; >>>whose business model is selling processors to all takersb1 >>>rather than bundled inside a system they sell.- >>>-: >>That's what I assumed you have to mean, but the economic8 >>importance you place on this still totally escapes me. >> > 8 > Let me make this as simple for you as possible. An MPU7 > that costs $125 to fabricate will always be much moreo7 > capable than a processor that costs $30 to fabricate,s8 > both being in the same technology. But the mass market7 > (PCs) is happy with the $30 MPU and is willing to buyt > # >>100m of them a year at ~$150 ASP.- >> > 4 > But some sockets demand more performance, RAS, and9 > or scalability than a $30 mass market chip can provide..8 > This high end market wants the $125 MPU and is willing8 > buy >1.5m of them a year at $1500+ ASP. For nearly the8 > last two decades this market has been serviced by five2 > major OEMs each with their own RISC MPU families9 > that each shipped in its own systems. But this tower ofc: > babel is inefficient because of the multiplicity of ISAs: > slicing up the same market, the duplication of effort in6 > making similar but incompatible MPUs, and the vendor( > lock-in effect with each ISA/platform. > 7 > A merchant chip family like IPF will allow the market 4 > for high end chips/systems to consolidate around a6 > single processor family and ISA. This eliminates the> > duplication of effort (effort which was starting to kill off6 > the smaller players anyways with the escalating cost4 > of high end MPU development). The reduction in the4 > number of ISAs in the high end market improves ISV5 > efficiency. And from the customer's perspective thei2 > move of high end systems market to merchant MPUs2 > *increases* competition among OEMs because there+ > is no longer an ISA-based lock-in effect.     O It's a bit sickening to think that once again the lowest common denominator is h the people's choice.    I > 	VAX was doomed, Alpha was doomed.  SPARC is doomed (shocka), Power is nD > 	doomed (strong arguments here against that view, but hey it is a 1 > 	Tower of Babel IBM micro is building on ;-).  e    O IBM is a special case.  As long as their resolve holds out, they will not give pQ in and accept a lesser chip.  Who was it that killed off VAX and Alpha.  We have  Q the likes of Palmer and Capalles.  Did they really understand the technology?  I oA doubt it.  Nor did they have the resolve to "do the right thing".-  P Back in 1960 Ford motor company suffered under the incluence of a bean counter. P   Their car sales suffered because of this.  Only when they went back to people L who loved the automobile and wanted to build "good" cars did their fortunes N reverse.  Then the asshole got into government, and was a significant part of " the total fiasco that was Vietnam.  Q Well, the likes of Palmer, curly, carly, and a few others are today's MacNamara, s or however it was spelled.    @ > 	I'd gander the shake-out will leave IPF, x86 (no-brainer) and? > 	x86-64 or whatever the ISA is.  The shakeout will take up top: > 	10 years for some to disappear, SPARC goes much faster.    O I see your consistant hate of Sun coming out again.  They have lots of current aP customers.  Opteron may end up in lots of their systems, but that hasn't played  out yet.  N I always like it when some know-it-all predicts what's going to happen, based O upon their wishes.  Rob sure called it right on HAMMER, huh?  Like they say in oO football, when upsets happen.  "That's why they play the game."  Well Rob, the e game isn't over yet.   Dave   ------------------------------  # Date: Thu, 20 Jan 2005 00:11:02 GMT56 From: "Kenneth Farmer" <kfarmer@NOSPAM.spyderbyte.com>5 Subject: Mark G. Interview on Slashdot and OSNews.com0= Message-ID: <qGCHd.5551$K72.1274170@twister.southeast.rr.com>   K Though everyone might want to go to Slashdot and check out the comments on t# Terry's interview with Mark Gorham.l  3 Soooo many Linux weenies still wet behind the ears.   @ http://it.slashdot.org/it/05/01/19/2236202.shtml?tid=190&tid=218   It's on SNews.com also...a  , http://www.osnews.com/story.php?news_id=9449   Kenu   OpenVMS.orgc% _____________________________________e Kenneth R. Farmer <><t% SpyderByte: http://www.SpyderByte.comb   ------------------------------  % Date: Wed, 19 Jan 2005 21:41:38 -0500e- From: JF Mezei <jfmezei.spamnot@teksavvy.com>o" Subject: Multi threaded cookbook ?, Message-ID: <41EF1A47.A5D92226@teksavvy.com>  H Is there a nice compact cookbook/document on how to write multi threadedG applications on VMS, including the various implications with regards toa. VMS specific routines, ASTs etc ? (C language)  F Also, in terms of X windows, there are a few routines which are usableC from within an AST. (for instance, inserting an event). Would thosed8 automatically be usable from a different thread as well?  H If a thread does a SYS$DCLAST, will the AST be queued to execute under a% single AST queue in the main thread ?,   ------------------------------    Date: 19 Jan 2005 16:09:19 -0800 From: jordan@ccs4vms.com, Subject: Re: Newbie Hobbyist NFS Question...B Message-ID: <1106179759.229349.26140@f14g2000cwb.googlegroups.com>   Schroeder, AJ wrote: > Hello, >pB > I have a OpenVMS hobbyist system running 7.3-1. I have TCPIP 5.3	 installedtF > and functional, however, I would like to start using this machine as an NFSF > server. Whenever I run TCPIP$CONFIG.COM and go into the server setup menu,oB > the NFS server shows that I do not have a license. I loaded (and enabled)0 > the UCX-IP-NFS license, but that did not help. >-B > My question; does the hobbyist program have a license for an NFS
 server? IfC > so, what is the product called? I have looked through the licenseo	 file thatsG > was sent to me by DECUS and the above PAK is the only one with NFS ind then5 > name. Here is a list of the licenses on my machine:d >u >  BASIC >  C >  OPENVMS-ALPHA >  OPENVMS-HOBBYISTc >  UCX-IP-CLIENT
 >  UCX-IP-NFSe  C > Thanks in advance for any help on this one, I'm sure it's an easyP one. But$ > google doesn't offer much on this. >m > AJ Schroeder    D Take a look to see if you have a plain UCX license and install that.D The UCX-IP-CLIENT license doesn't allow you to run NFS and (I think); DNS servers; I'm not sure what the UCX-IP-NFS license does.5   ------------------------------  % Date: Wed, 19 Jan 2005 20:01:23 -0600 2 From: David J Dachtera <djesys.nospam@comcast.net>, Subject: Re: Newbie Hobbyist NFS Question...+ Message-ID: <41EF10F3.5990FDB3@comcast.net>y   jordan@ccs4vms.com wrote:  >  > Schroeder, AJ wrote:
 > > Hello, > >nD > > I have a OpenVMS hobbyist system running 7.3-1. I have TCPIP 5.3 > installedaH > > and functional, however, I would like to start using this machine as > an NFSH > > server. Whenever I run TCPIP$CONFIG.COM and go into the server setup > menu,tD > > the NFS server shows that I do not have a license. I loaded (and
 > enabled)2 > > the UCX-IP-NFS license, but that did not help. > > D > > My question; does the hobbyist program have a license for an NFS > server? IfE > > so, what is the product called? I have looked through the licensea > file thattI > > was sent to me by DECUS and the above PAK is the only one with NFS int > thes7 > > name. Here is a list of the licenses on my machine:c > >i
 > >  BASIC > >  C > >  OPENVMS-ALPHA > >  OPENVMS-HOBBYIST  > >  UCX-IP-CLIENT > >  UCX-IP-NFSs > E > > Thanks in advance for any help on this one, I'm sure it's an easy*
 > one. But& > > google doesn't offer much on this. > >o > > AJ Schroeder > F > Take a look to see if you have a plain UCX license and install that.F > The UCX-IP-CLIENT license doesn't allow you to run NFS and (I think)= > DNS servers; I'm not sure what the UCX-IP-NFS license does.c  E Like he said - install the UCX base license and load it. See how that  goes...S   --   David J Dachtera dba DJE Systemsm http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page:o" http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t  " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/.   Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------    Date: 19 Jan 2005 13:26:03 -06004 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow)$ Subject: Re: Next Gen Fabs & Itanium3 Message-ID: <7GWUHLPlFlZb@eisner.encompasserve.org>c  W In article <354igbF4gp8quU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:s5 > In article <Zi8QSRu9Yr8w@eisner.encompasserve.org>,u9 > 	kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) writes:'i >> In article <UxQGd.5962$Fp4.5589@news.cpqcorp.net>, Keith Parris <keithparris_NOSPAM@yahoo.com> writes:u >>> JF Mezei wrote:eB >>>> My guess is that Alpha VMS sales will outlive IA64 VMS sales. >>> L >>> As Alpha sales are slated to end next year, in 2006, your guess is very 
 >>> unlikely.s >> n! >> When was the last PDP-11 sold?a > H > You can't answer that one without a crystal ball.  The question shouldH > not be in the past tense yet.  Forget about the Alpha, I expect PDP-11 > sales to outlive IA64 sales.  B Exactly my point. PDP-11s are still being sold. So are used VAXen.  1 	Bob Kaplow	NAR # 18L	TRA # "Impeach the TRA BoD" & 		>>> To reply, remove the TRABoD! <<<K Kaplow Klips & Baffle:	http://nira-rocketry.org/LeadingEdge/Phantom4000.pdflL     www.encompasserve.org/~kaplow_r/    www.nira-rocketry.org    www.nar.org  ? 	Voting for "the lesser of two evils" is still voting for evil.e   ------------------------------  % Date: Thu, 20 Jan 2005 04:08:35 +0800e From: prep@prep.synonet.comn$ Subject: Re: Next Gen Fabs & Itanium- Message-ID: <87wtu9yyf0.fsf@prep.synonet.com>u  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:    > Robert Deininger wrote:   D >> Alpha systems absolutely cost more to make than similar IntegrityE >> systems.  You'd lose your bet if the numbers were available to the @ >> public.  Since they're not, you're safe with your wild public >> speculations.  6 > Why should an Alpha box cost more than an IA64 box ? > Is the the power supply ?  > Is it the case ? > Is it the disk drives ?u > Is it the connectors ? > Is it the type of memory ?  = > Are alpha servers built with gold solder  instead of lead ?   A History. A large percentage of Vaxen and Alphas ended up at sitese? with fixed price maintainance contracts. NOTHING digs your gaveb= faster than a reliability dog that YOU have to carry the painw and costs for!  E So DEC designs tended to aim high so as to save *DEC* money after the  sale.r   -- t< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Wed, 19 Jan 2005 20:00:46 GMT.% From: "John Vottero" <John@mvpsi.com>. Subject: Re: Paradigmw> Message-ID: <O%yHd.17049$_X7.13434@newssvr33.news.prodigy.com>  @ "David J Dachtera" <djesys.nospam@comcast.net> wrote in message % news:41EDC5E1.214ABAA5@comcast.net...m! >I wasn't sure how to title this.  >OH > The thought occurred to me today (told you I'm rather slow) that thereI > is perhaps a larger difference between the incumbent OpenVMS management C > and the denizens of this group than is immediately obvious at thes
 > surface. >uH > Quite possibly, the incumbents are "pacificists"; that is, play along,J > don't rock the boat, get into retirement position then quietly slip into > VMS history.  : Apparently, you haven't met Mark or Sue (and many others).   ------------------------------  % Date: Wed, 19 Jan 2005 19:58:37 -0600p2 From: David J Dachtera <djesys.nospam@comcast.net> Subject: Re: Paradigmg* Message-ID: <41EF104D.AB775A0@comcast.net>   John Vottero wrote:x > A > "David J Dachtera" <djesys.nospam@comcast.net> wrote in message ' > news:41EDC5E1.214ABAA5@comcast.net...n# > >I wasn't sure how to title this.  > > J > > The thought occurred to me today (told you I'm rather slow) that thereK > > is perhaps a larger difference between the incumbent OpenVMS management E > > and the denizens of this group than is immediately obvious at the  > > surface. > >eJ > > Quite possibly, the incumbents are "pacificists"; that is, play along,L > > don't rock the boat, get into retirement position then quietly slip into > > VMS history. > < > Apparently, you haven't met Mark or Sue (and many others).   Actually, yes I have.h   I'm talking about:  3 o *TAKING ACTION*, not talking about taking action.e  % o Agressively pursuing new customers.l  & o Actively marketing and promoting VMS  C ...in short, all those imperatives that HP and VMS are reluctant to0  embrace ("Feared Things First").   -- . David J Dachtera dba DJE Systemsg http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page:t" http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/p   Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------  % Date: Wed, 19 Jan 2005 22:00:57 -0500m- From: JF Mezei <jfmezei.spamnot@teksavvy.com>j Subject: Re: Paradigm , Message-ID: <41EF1ECD.C281465C@teksavvy.com>   David J Dachtera wrote:0 > I'm talking about:5 > o *TAKING ACTION*, not talking about taking action. ' > o Agressively pursuing new customers.o( > o Actively marketing and promoting VMS  F In terms of Sue, I think she is fairly proactive,  especially when youE consider she is responsible for the VMS ambassadors programme.  And I G have never seen her defend the lack of VMS marketing here, unlike otherwM VMS folks who have often stated that marketing VMS would be a waste of money.       H When Marcello was the head of VMS, I got the dictinct impression that heH couldn't rock the boat too much. He did head a very succesful revival ofE VMS that lasted a few months, and that was just after he succeeded inaF sheving the plans to kill VMS. But as soon as HP can into the game, heH went quiet and became a good quiet and obediant boy worthy of promotion.0 He got promoted and hasn't rocked the boat much.  B Remember that folks like Winkler and Stallard are atill at HP with influence. w  : Gorham probably has to play it safe and not rock the boat.  # There are two questions in my mind:eC 	How widespread is the opinion in VMS management that marketing VMS  would not yield results ? G 	If VMS management aren't fighting to get marketing freedom, they won't5 get it.m  I 	is Marcello slowly planting the seeds to change attitudes towards VMS ? :H 	or Is marcello being a good obediant puppy, worried about his carreer ?   ------------------------------  % Date: Thu, 20 Jan 2005 00:06:15 -0500i' From: Dave Froble <davef@tsoft-inc.com>U Subject: Re: Paradigm4, Message-ID: <41EF3C47.9030603@tsoft-inc.com>   JF Mezei wrote:r   > David J Dachtera wrote:r >  >>I'm talking about:5 >>o *TAKING ACTION*, not talking about taking action.N' >>o Agressively pursuing new customers.t( >>o Actively marketing and promoting VMS >> > H > In terms of Sue, I think she is fairly proactive,  especially when youG > consider she is responsible for the VMS ambassadors programme.  And IeI > have never seen her defend the lack of VMS marketing here, unlike other O > VMS folks who have often stated that marketing VMS would be a waste of money.o >  >  > J > When Marcello was the head of VMS, I got the dictinct impression that heJ > couldn't rock the boat too much. He did head a very succesful revival ofG > VMS that lasted a few months, and that was just after he succeeded iniH > sheving the plans to kill VMS. But as soon as HP can into the game, heJ > went quiet and became a good quiet and obediant boy worthy of promotion.2 > He got promoted and hasn't rocked the boat much. > D > Remember that folks like Winkler and Stallard are atill at HP with
 > influence. e > < > Gorham probably has to play it safe and not rock the boat. > % > There are two questions in my mind:aE > 	How widespread is the opinion in VMS management that marketing VMSw > would not yield results ?dI > 	If VMS management aren't fighting to get marketing freedom, they won't6	 > get it.a > K > 	is Marcello slowly planting the seeds to change attitudes towards VMS ? aJ > 	or Is marcello being a good obediant puppy, worried about his carreer ? >   Q Well, if he isn't there, he can never sieze any opportunities should they arise, 0R can he.  Think of where VMS would be if there was no counters to Winkler and such.   ------------------------------    Date: 19 Jan 2005 17:54:49 -08000 From: "Kannan" <kannan.s.viswanathan@oracle.com>/ Subject: pthread_create() call returning ENOMEMoC Message-ID: <1106186089.085908.324940@c13g2000cwb.googlegroups.com>r  F I am running a server application that is heavily threaded. It createsG threads to execute some tasks and exits out of the thread when the task4G completes. This happens on a periodic basis at a rate of probably aboutDC 2 to 4 threads per minute. I find that the application fails in the G pthread_create() call after about 15 to 20 hrs of running with a returnuE value of ENOMEM(12). I checked my account quotas and they all seem touC be adequate even at the point of failure. Here's the process quotas ? just after the process has failed in the pthread_create() call:s ---------------c Process Quotas:u Account name: 28916mE CPU limit:                      Infinite  Direct I/O limit:     30000 E Buffered I/O byte count quota:   8767744  Buffered I/O limit:   30000'E Timer queue entry quota:             607  Open file quota:       2340 E Paging file quota:               7670192  Subprocess quota:        95 E Default page fault cluster:           64  AST quota:            19994nE Enqueue quota:                      8178  Shared file limit:        0tE Max detached processes:                0  Max active jobs:          0e ---------------l  A The MAXTHREADS system parameter on the system is at 256, and I douD observe that the running threads in my process is nowehere near thatE number. I instrumented some thread tracking info to keep track of howH@ many threads are created and deleted. At the point of failure, I@ observe that 1810 threads had been created, and 1806 threads hadF completed, leaving only 4 threads running. This is also confirmed whenA I do a 'show task/all' in my debugger session and all of the 1806i! threads show status 'terminated'.    My thread stacksize is at 500K.   ? Is it possible that this stacksize value might cause the ENOMEMlD problem? As I understand it, this is a per-thread stacksize problem,E and shouldn't be a problem with respect to mem availability a long asu my PAGFILQUO is sufficient.   " Any pointers would be appreciated.   ------------------------------  % Date: Wed, 19 Jan 2005 20:18:51 -060092 From: David J Dachtera <djesys.nospam@comcast.net>3 Subject: Re: pthread_create() call returning ENOMEMt+ Message-ID: <41EF150B.7844249F@comcast.net>c  
 Kannan wrote:l > H > I am running a server application that is heavily threaded. It createsI > threads to execute some tasks and exits out of the thread when the taskuI > completes. This happens on a periodic basis at a rate of probably about,E > 2 to 4 threads per minute. I find that the application fails in thehI > pthread_create() call after about 15 to 20 hrs of running with a returncG > value of ENOMEM(12). I checked my account quotas and they all seem tonE > be adequate even at the point of failure. Here's the process quotasfA > just after the process has failed in the pthread_create() call:o > ---------------o > Process Quotas:. > Account name: 28916,G > CPU limit:                      Infinite  Direct I/O limit:     30000dG > Buffered I/O byte count quota:   8767744  Buffered I/O limit:   30000sG > Timer queue entry quota:             607  Open file quota:       2340eG > Paging file quota:               7670192  Subprocess quota:        95eG > Default page fault cluster:           64  AST quota:            19994eG > Enqueue quota:                      8178  Shared file limit:        0tG > Max detached processes:                0  Max active jobs:          0  > ---------------o > C > The MAXTHREADS system parameter on the system is at 256, and I do_F > observe that the running threads in my process is nowehere near thatG > number. I instrumented some thread tracking info to keep track of howmB > many threads are created and deleted. At the point of failure, IB > observe that 1810 threads had been created, and 1806 threads hadH > completed, leaving only 4 threads running. This is also confirmed whenC > I do a 'show task/all' in my debugger session and all of the 1806h# > threads show status 'terminated'.d > ! > My thread stacksize is at 500K.r > A > Is it possible that this stacksize value might cause the ENOMEMnF > problem? As I understand it, this is a per-thread stacksize problem,G > and shouldn't be a problem with respect to mem availability a long as  > my PAGFILQUO is sufficient.o > $ > Any pointers would be appreciated.   This is likely a resource leak.t   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  ) Unofficial OpenVMS Hobbyist Support Page:a" http://www.djesys.com/vms/support/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/a   Coming soon:& Unofficial OpenVMS Marketing Home Page   ------------------------------    Date: 19 Jan 2005 19:59:31 -08000 From: "Kannan" <kannan.s.viswanathan@oracle.com>3 Subject: Re: pthread_create() call returning ENOMEM C Message-ID: <1106193571.191537.182880@z14g2000cwz.googlegroups.com>o  G Could you give some pointers as to how to narrow down the source of theh6 leak. What can I look for in  the SDA for the process?   ------------------------------  % Date: Thu, 20 Jan 2005 00:17:25 -0500 ' From: Dave Froble <davef@tsoft-inc.com>m3 Subject: Re: pthread_create() call returning ENOMEMt, Message-ID: <41EF3EE5.1050601@tsoft-inc.com>  
 Kannan wrote:r  I > Could you give some pointers as to how to narrow down the source of thed8 > leak. What can I look for in  the SDA for the process? >  >   F I'd agree with David, the first place to look is for some memory leak.  M It's hard to give some help when we don't know the application and what it's  O doing.  I'd start by determining whether a thread will allocate any resources, lE such as memory.  If so, then attempting to trace both allocation and o deallocation of resources.  K I've never had to do this.  Hopefully someone who has will offer some tips.o   Dave   ------------------------------  % Date: Wed, 19 Jan 2005 15:31:12 -0500h( From: Bill Todd <billtodd@metrocast.net> Subject: Re: RMS= Message-ID: <kYOdnc9DOoQQXnPcRVn-1g@metrocastcablevision.com>    Tom Linden wrote:6I > Just curious, was RMS part of the original VMS design or did come aboutl% > in order to support PL/I and Cobol?y  B RMS was part of the original VMS design.  As Fred noted, its main E characteristics were inherited from the existing RMS products on the hC PDP-11 (RSX, IAS, and RSTS systems) - though in truth these PDP-11 pE products only preceded VMS by a year or so and had therefore evolved c, with an eye toward the needs of VMS as well.  @ COBOL influenced the design of RMS most visibly in the areas of F alternate indexes and the ordering of duplicate key values.  The main I initial RMS architect (Ed Marison) also had a background in MUMPS, which t7 contributed to some aspects of the indexed-file design.I   - bill   ------------------------------  % Date: Wed, 19 Jan 2005 11:06:42 -0800n# From: "Tom Linden" <tom@kednos.com>o& Subject: RMS (was: vms versus solaris)( Message-ID: <opsku51golzgicya@hyrrokkin>  G Just curious, was RMS part of the original VMS design or did come aboutf# in order to support PL/I and Cobol?S  ; On Wed, 19 Jan 2005 17:13:35 +0000 (UTC), Michael Kraemer  o <m.kraemer@gsi.de> wrote:u  L > In article <41ee8a25$0$17600$9b4e6d93@newsread4.arcor-online.net>, Keith  . > Cayemberg <keith.cayemberg@arcor.de> writes: >>A >> I have been told several times by programmers, that they found  >>> >> 	"RMS is a frustrating obstacle to my programming freedom",
 >> or that< >> 	"RMS is very finicky about file and record definitions". >> >> I then tell them... >>> >> 	"That is why RMS exists, to be finicky and frustrate you". >>A >> RMS helps programmers to be disciplined, and to get their filea >> definitions right.o >> >t > Funny.@ > In former times some of the VMS bigots in my field joked aboutE > the - in their view - strange concept of record structured files onrF > IBM's mainframes. "No need for that, just open a file and be happy   > bytewise".F > Strange that VMS bigots nowadays bash Unix for exactly the opposite.       -- eC Using Opera's revolutionary e-mail client: http://www.opera.com/m2/w   ------------------------------  # Date: Wed, 19 Jan 2005 19:30:43 GMTs* From: "FredK" <fred.nospam@nospam.dec.com>* Subject: Re: RMS (was: vms versus solaris)2 Message-ID: <DzyHd.6152$T56.2584@news.cpqcorp.net>  ; RMS was part of the original design and came from RSX IIRC.   . "Tom Linden" <tom@kednos.com> wrote in message" news:opsku51golzgicya@hyrrokkin...I > Just curious, was RMS part of the original VMS design or did come aboute% > in order to support PL/I and Cobol?  >s; > On Wed, 19 Jan 2005 17:13:35 +0000 (UTC), Michael Kraemer' > <m.kraemer@gsi.de> wrote:  >'L > > In article <41ee8a25$0$17600$9b4e6d93@newsread4.arcor-online.net>, Keith0 > > Cayemberg <keith.cayemberg@arcor.de> writes: > >>C > >> I have been told several times by programmers, that they foundt > >>? > >> "RMS is a frustrating obstacle to my programming freedom",  > >> or that= > >> "RMS is very finicky about file and record definitions".p > >> > >> I then tell them... > >>? > >> "That is why RMS exists, to be finicky and frustrate you".- > >>C > >> RMS helps programmers to be disciplined, and to get their fileS > >> definitions right.j > >> > >r
 > > Funny.B > > In former times some of the VMS bigots in my field joked aboutG > > the - in their view - strange concept of record structured files ondF > > IBM's mainframes. "No need for that, just open a file and be happy > > bytewise".H > > Strange that VMS bigots nowadays bash Unix for exactly the opposite. >s >i >  > -- gE > Using Opera's revolutionary e-mail client: http://www.opera.com/m2/    ------------------------------    Date: 19 Jan 2005 14:04:39 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) * Subject: Re: RMS (was: vms versus solaris)3 Message-ID: <2SS0j56EeOx5@eisner.encompasserve.org>r  N In article <opsku51golzgicya@hyrrokkin>, "Tom Linden" <tom@kednos.com> writes:I > Just curious, was RMS part of the original VMS design or did come about0% > in order to support PL/I and Cobol?s  C RMS was always part of the _design_, although VMS V1.5 did not have-4 indexed files (they were furiously working on them).  C Some details, like reverse-order indexes, were added along the way.    ------------------------------  # Date: Thu, 20 Jan 2005 01:10:27 GMT. From: reb <natron@ntlworld.com>  Subject: satellite clustersr0 Message-ID: <opskvmurwvaqvj2s@news.ntlworld.com>  6  From the VMS info linked to from yesterday's Webcast:  H "Drive continuous operations for your local, national, and internationalJ   operations with full cluster functionality at distances up to 800 Km and(   up to 90,000 Km for disaster recovery"  H Looks like someone has been doing cluster comms bouncing off a satellite< or two.  Does the 'same time zone' requirement still apply ?     rebo   ------------------------------  % Date: Thu, 20 Jan 2005 00:09:31 -0500s' From: Dave Froble <davef@tsoft-inc.com>l Subject: Re: satellite clusters * Message-ID: <41EF3D0B.50801@tsoft-inc.com>  
 reb wrote:   > 8 >  From the VMS info linked to from yesterday's Webcast: > J > "Drive continuous operations for your local, national, and internationalK >  operations with full cluster functionality at distances up to 800 Km and-) >  up to 90,000 Km for disaster recovery"m > J > Looks like someone has been doing cluster comms bouncing off a satellite> > or two.  Does the 'same time zone' requirement still apply ? >  >  > reba  Q That's too far out for a geo-sync orbit, which is what I'd choose if I was going m( off-planet for disaster tollerance.  :-)   ------------------------------    Date: 19 Jan 2005 17:14:14 -0800  From: "Elie" <elie.uy@gmail.com>! Subject: VMS Filename/type lengthbC Message-ID: <1106183654.838144.164390@c13g2000cwb.googlegroups.com>    Hi,i  A Just want a clarification on VMS filename length. It's documentedh@ somewhere that VMS supports up to 255 characters long. Does thatC include device/directory? Because I am only able to create up to 39i4 characters of filename and 39 characters of filetype* (filename.filetype). I am using VMS v7.3-1  
 Any ideas?   Thanks --Elie   ------------------------------    Date: 19 Jan 2005 21:04:01 -0800$ From: "AEF" <spamsink2001@yahoo.com>% Subject: Re: VMS Filename/type lengthpC Message-ID: <1106197441.602747.167050@z14g2000cwz.googlegroups.com>u   Elie wrote:p > Hi,o >SC > Just want a clarification on VMS filename length. It's documentedsB > somewhere that VMS supports up to 255 characters long. Does thatE > include device/directory? Because I am only able to create up to 39e6 > characters of filename and 39 characters of filetype, > (filename.filetype). I am using VMS v7.3-1 >t > Any ideas? >f > Thanks > --Elie    D On ODS-2 volumes -- which must be what you are using -- the name andC type are each limited to a maximum of 39 characters. If you require G more than that you will have to make an ODS-5 volume. VMS documentatione% is online at the www.hp.com Web site.s  G There is also the 255-char limit for the length of any file-spec stringtD for files that reside on ODS-2 volumes. You might want to start withF the User's Manual for general info about VMS. This includes info aboutE file specifications, but curiously doesn't mention the 255-char limita: -- at least I couldn't find it in my cursory glance at it.  ; For your particular question, see Section 5.4 on this page:   < http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_015.html  F which does mention the 255-char limit and also gives info about limits on ODS-5 file specifications.0   ------------------------------  % Date: Wed, 19 Jan 2005 11:01:00 -0800M# From: "Tom Linden" <tom@kednos.com>o Subject: Re: vms versus solaris0( Message-ID: <opsku5rylkzgicya@hyrrokkin>  K On Wed, 19 Jan 2005 18:01:59 GMT, FredK <fred.nospam@nospam.dec.com> wrote:w   >:0 > "Tom Linden" <tom@kednos.com> wrote in message$ > news:opskuy70bkzgicya@hyrrokkin...6 >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg >>K >> Actually, you could make all the same arguments as a case for using PL/Ii >> instead of C. >tI > I can make arguments for buying a caddy rather than a bimmer, but the  l > caddye  > still remains an old fart car.  J Your metaphor is faulty, PL/I is the bimmer, C is a chevy nova (probably   with' liberal applications of duct tape:-) ).  >lI > Kind-of like PL/I.  Or VMS itself.  Not a lot of appeal to anyone who    > wants> > to > appear young or cool.dJ Now the interview with Mark leads oner to believe the GNV is going to makeJ it possible to migrate Unix apps with no effort.  So maybe VMS will also   notaJ be viewed as the old fart car.  I have always had a disdain for ignorant   fashions anyway.n   >  >e >P       -- tC Using Opera's revolutionary e-mail client: http://www.opera.com/m2/    ------------------------------  % Date: Wed, 19 Jan 2005 11:02:32 -0800e# From: "Tom Linden" <tom@kednos.com>  Subject: Re: vms versus solarism( Message-ID: <opsku5uiiyzgicya@hyrrokkin>  5 On Wed, 19 Jan 2005 18:01:24 +0100, Keith Cayemberg   ! <keith.cayemberg@arcor.de> wrote:i   > Tom Linden wrote:  >e9 >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg   u$ >> <keith.cayemberg@arcor.de> wrote: >> >>> Bill Todd wrote: >>>u >>>> Dave Weatherall wrote:l
 >>>>  .... >>>>    As a >>>>K >>>>> record-oriented user/programmer, it _is_ a decisive plus but then,   (C >>>>> perhaps, I fall into the 'locked in' category (mentally or     >>>>> philosophically).e >>>>L >>>>   The point is that as a record-oriented user/programmer, you'd also   K >>>> have access to the kinds of packages I mentioned on Unix (or - blech  tF >>>> -  even to some extent on Windows) - in fact, to a considerably  J >>>> larger  collection of options in this area than is available to you  L >>>> on VMS,  many of them free or very low cost but still very functional  I >>>> and stable  and quite a few of them also somewhat more technically  lI >>>> current than RMS  is (e.g., in their integral use of journaling to  t0 >>>> improve both  performance and reliability).L >>>>  The fact that RMS is bundled and supported as part of the OS may be   K >>>> convenient and reassuring, but is hardly of *major* significance to   iC >>>> most users (or applications, though not having a third-party  t: >>>> dependency  in this area is part of the convenience). >>>>  - bill >>>o >>>rA >>> It appears to me that everyone here fails to understand the   D >>> philosophy  behind having an universal record handling service  * >>> integrated into the  operating system. >>>sI >>> It's primary purpose within the context of professional programming  kL >>> is  not to make record handling "easier" or more "convenient" for the    >>> programmer.k >>>fG >>> It's primary purpose is to improve the quality and correctness of  a! >>> record  storage and transfer.i >>>sL >>> This principle is similar to that which behind the use of Descriptors   F >>> and a defined Call Standard in OpenVMS, which are also excellent  < >>> unique  quality features of the OpenVMS OS Architecture. >>>n@ >>> By making this service "default" or for some purposes even  J >>> "mandatory"  for the operating system, programmers are encouraged to  H >>> forego their  artistic-license to make many common record-handling  J >>> errors, and provide  a clear definition of the record structure of a  I >>> file. When another  program tries to use the record service to read  oK >>> the records in an  erroneous format, this is quickly identified as an  oK >>> error, before passing  the incorrectly interpreted information to the  a >>> next application.e >>>iB >>> I have been told several times by programmers, that they found >>>eB >>>     "RMS is a frustrating obstacle to my programming freedom", >>> or thatp@ >>>     "RMS is very finicky about file and record definitions". >>>  >>> I then tell them...a >>>sB >>>     "That is why RMS exists, to be finicky and frustrate you". >>>eE >>> RMS helps programmers to be disciplined, and to get their file     >>> definitions right.J >>   Actually, you could make all the same arguments as a case for using   >> PL/Ih >> instead of C. >pI > Ah yes, another RMS design advantage I forgot to mention. The service  fJ > design is, as with most VMS integrated services, language neutral That  J > is what I consider responsible artistic freedom for the programmer. In  K > fact, it is quite desirable to integrate RMS into the native compilers.   4 > I suppose your PL/I for OpenVMS already does this?  G Fully, and transparently, record i/o is part of the language semantics.i   Naturally C K > programmers have a little more work to do here, which is probably helps  nE > explain why I get the most complaints about RMS from C programmers.t >r >> >>>oF >>> Please note, that RMS also manages the access of files with the   I >>> stream-lf format. This protects, for instance, a program correctly    B >>> programmed for accessing a stream-lf file from accessing an   K >>> Indexed-Sequential file, or even an executable file erroneously. RMS   eH >>> thus reduces the likelihood not only of programmer error, but user   >>> error  as well.e >>>,L >>> I have over the years experienced countless cases where RMS has saved   D >>> our customers a lot of trouble. I am especially referring to a  L >>> complex  CIM and Production Planning environment in which a diagram of  L >>> the  interfaces between the processes controlling the various factory   H >>> processes looks like a 3D spider web. Information produced by one   B >>> process is often transferred to many other processes in that  A >>> processing  web using some form of file transfer. Having an  sH >>> undiscovered error in an  interface would quickly propagate deeply  C >>> into many other systems. It  would be a potentially create an  -G >>> unrecoverable mess! This CIM  environment also sends and receives  mF >>> information from external systems,  often programmed by external  H >>> companies or consultants using their own  methods. By having a RMS  F >>> described file as a transfer medium, we have  often caught these  I >>> external agencies that have quietly (perhaps  unintentially through  iG >>> their own programming errors) changed the format  of these files,  fI >>> before accepting their information in our complex CIM  environment.  aA >>> For us, this seems to happen regularly when information is   rL >>> transferred from SAP systems which have had some sort of upgrade. The   H >>> SAP folks appear to be so isolated from the file details that they  I >>> don't  always know the exact format of a file that will be produced  uI >>> after a  change. They could certainly use a service that implements  2! >>> the  principles found in RMS!  >>>rF >>> Although, I agree that there are customers and applications with  D >>> design  goals that would make the Unix minimalism desirable, I  L >>> respectfully  disagree that this philosophy should be a goal within an  G >>> Enterprise or  Mission-Critical oriented OS. The presence of such  sJ >>> universal (at least  within the chosen OS) quality-oriented services  I >>> is clearly a desirable  quality enhancement within the professional  h6 >>> Enterprise OS and  Mission-Critical problem space. >>>c >>> Cheers!a >>>o >>> Keith Cayembergs >>       --  C Using Opera's revolutionary e-mail client: http://www.opera.com/m2/i   ------------------------------  % Date: Wed, 19 Jan 2005 11:24:10 -0800S# From: "Tom Linden" <tom@kednos.com>S Subject: Re: vms versus solarisU( Message-ID: <opsku6ukjtzgicya@hyrrokkin>  K On Wed, 19 Jan 2005 19:36:16 GMT, FredK <fred.nospam@nospam.dec.com> wrote:    >i0 > "Tom Linden" <tom@kednos.com> wrote in message$ > news:opsku5rylkzgicya@hyrrokkin...G >> On Wed, 19 Jan 2005 18:01:59 GMT, FredK <fred.nospam@nospam.dec.com>h > wrote: >> >> >3 >> > "Tom Linden" <tom@kednos.com> wrote in message-' >> > news:opskuy70bkzgicya@hyrrokkin...19 >> >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayembergn >> >>oI >> >> Actually, you could make all the same arguments as a case for using1 > PL/I >> >> instead of C.  >> >J >> > I can make arguments for buying a caddy rather than a bimmer, but the
 >> > caddy# >> > still remains an old fart car.e >>K >> Your metaphor is faulty, PL/I is the bimmer, C is a chevy nova (probablyg >> withh* >> liberal applications of duct tape:-) ). >PH > Spoken like the owner of an Oldsmobile defending why it's so great ;-)    True, but no need for duct tape.  K Now, Fred, just to make you feel better, I am taking the next two days off, I golfing at Spyglass tomorrow Monterey Peninsula CC on Fri, Spanish Bay on K Sat and Pebble Beach on Sunday and the temp is upper 60s and not a cloud ine/ the sky.  I don't think I miss Boston too much.n   >  >> >J >> > Kind-of like PL/I.  Or VMS itself.  Not a lot of appeal to anyone who
 >> > wants >> > toc >> > appear young or cool.J >> Now the interview with Mark leads oner to believe the GNV is going to   >> make K >> it possible to migrate Unix apps with no effort.  So maybe VMS will also. >> notK >> be viewed as the old fart car.  I have always had a disdain for ignoranto
 >> fashion
 >> anyway. >> >X > Uh.  Yeah.  Right. >.K > GNV is a useful thing.  I have a 3rd party that ported their code to VMS,N > andrK > since they are all UNIX heads, I put GNV on the system so that they couldtH > use the bash shell and have familiar tools.  This helped them a *huge*@ > amount (although I think GNV would be more useful with a EMACSB > editor configured too).  But it didn't port their code for them. >nG > The C RTL has a *lot* more UNIX stuff in it, as does some of the file J > system (soft links, naming, etc).  But it still *isn't* UNIX.  There are > still:K > areas like fork(), select() and shared stream files that are problematic. : > Some will be fixed sooner, and some will take more time. >o >T       -- KC Using Opera's revolutionary e-mail client: http://www.opera.com/m2/Z   ------------------------------  % Date: Wed, 19 Jan 2005 14:27:24 -0500,- From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: vms versus solarisnB Message-ID: <1106162210.62d7ecc2d06dbd7f1aaa4d87e05d4359@teranews>   Neil Rieck wrote:i  H > Your statement is true. But I think you'd agree that the current "open' > source movement" is dominated by "C".e  G While for VMS, I would tend to agree, is that truly the case ? Wouldn't 5 C++ be very common for modern open sourced projects ?,  H One VMS, we are sort of accustomed to older software since we don't have> the bleeding edge ported to VMS. But seems to me that a lot ofC modern/current stuff is in C++.  For instance, the Macromedia flashl player open source is in C++.o  ; Software written for Symbian phones is either C++ or Java. n    What is open office written in ?   ------------------------------  # Date: Wed, 19 Jan 2005 19:36:16 GMTT* From: "FredK" <fred.nospam@nospam.dec.com> Subject: Re: vms versus solariso2 Message-ID: <QEyHd.6153$666.1919@news.cpqcorp.net>  . "Tom Linden" <tom@kednos.com> wrote in message" news:opsku5rylkzgicya@hyrrokkin...F > On Wed, 19 Jan 2005 18:01:59 GMT, FredK <fred.nospam@nospam.dec.com> wrote: >8 > >02 > > "Tom Linden" <tom@kednos.com> wrote in message& > > news:opskuy70bkzgicya@hyrrokkin...8 > >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg > >>H > >> Actually, you could make all the same arguments as a case for using PL/I > >> instead of C. > >lI > > I can make arguments for buying a caddy rather than a bimmer, but thee	 > > caddy>" > > still remains an old fart car. >eJ > Your metaphor is faulty, PL/I is the bimmer, C is a chevy nova (probably > with) > liberal applications of duct tape:-) ).   F Spoken like the owner of an Oldsmobile defending why it's so great ;-)   > >iI > > Kind-of like PL/I.  Or VMS itself.  Not a lot of appeal to anyone whoa	 > > wants  > > to > > appear young or cool.VL > Now the interview with Mark leads oner to believe the GNV is going to makeJ > it possible to migrate Unix apps with no effort.  So maybe VMS will also > notiJ > be viewed as the old fart car.  I have always had a disdain for ignorant	 > fashion 	 > anyway.r >    Uh.  Yeah.  Right.  I GNV is a useful thing.  I have a 3rd party that ported their code to VMS,  and I since they are all UNIX heads, I put GNV on the system so that they couldaF use the bash shell and have familiar tools.  This helped them a *huge*> amount (although I think GNV would be more useful with a EMACS@ editor configured too).  But it didn't port their code for them.  E The C RTL has a *lot* more UNIX stuff in it, as does some of the filemH system (soft links, naming, etc).  But it still *isn't* UNIX.  There are stillnI areas like fork(), select() and shared stream files that are problematic. 8 Some will be fixed sooner, and some will take more time.   ------------------------------  % Date: Wed, 19 Jan 2005 14:45:00 -0500u- From: JF Mezei <jfmezei.spamnot@teksavvy.com>r Subject: Re: vms versus solarise, Message-ID: <41EEB8BA.F5A15683@teksavvy.com>   Tom Linden wrote:mL > The ISAM packaged developed to support PL/I under Ultrix was spun off as aI > separately licensable package, but I don't think it ever sold very muche > outside of PL/I usage.  D You have to realise that on Unix and Windows, the lack of RMS simplyG forced people to buy a database package. Had RMS been made available to0H Windows and various Unixes, Oracle wouldn't be where it is today because@ most people's needs would be handled nicely with RMS/ISAM files.    G And you have to look back to the 1980s, when the big competitor was VMSw with its built-in VSAM files.   @ Now, the competition is Windows and Unix which do not have ISAM.  G Note that my trusty 1990s Psion Series 3 PDA with 2 meg of RAM has ISAMeE and the equivalent of DECnet on it. And like Digital, PSION no longern. exists (except on paper, it is now a holding).   ------------------------------  % Date: Wed, 19 Jan 2005 14:51:50 -0500h- From: JF Mezei <jfmezei.spamnot@teksavvy.com>l Subject: Re: vms versus solarist, Message-ID: <41EEBA53.1F827FF9@teksavvy.com>   Keith Cayemberg wrote:H > It's primary purpose within the context of professional programming isC > not to make record handling "easier" or more "convenient" for thea
 > programmer.i  + I would also add "more secure" to the list.   E Consider how many OS required long volume/file rebuilds after a powertF failure because disks become corrupt when files are improperly closed.E RMS does a very good job of this, especially when it comes to indexed ( files where file integrity is very good.  E Having RMS as a layered product just couldn't offer the same level ofeE robustness, especially when it comes to multiple proicesses accessingeH the same file at the same time. It provides primitives such as automatic record locking, etc.   ------------------------------  % Date: Wed, 19 Jan 2005 15:03:01 -0500m- From: JF Mezei <jfmezei.spamnot@teksavvy.com>j Subject: Re: vms versus solaris-, Message-ID: <41EEBCF2.A2DF0620@teksavvy.com>   Michael Kraemer wrote:@ > In former times some of the VMS bigots in my field joked aboutE > the - in their view - strange concept of record structured files onaO > IBM's mainframes. "No need for that, just open a file and be happy bytewise". F > Strange that VMS bigots nowadays bash Unix for exactly the opposite.  C On MVS, the default for "text" files was fixed length records of 80lE bytes.  So you couldn't cheat by having a line of code longer than 80 . bytes to avoid having the split the line in 2.  E VMS, the default is variable lengh files, so when you edit, you don'ttD have a artificial limit on how long a line can be (within reason, ofG course).  So if you need to have a statement fit on one line, it is noto
 a problem.  F Note that WML   (the reduced HTML for handsets) requires tags to be on	 one line.n  F Note that MVS did support variable length records. I had to teach someG IBM Cobol programmers how to generate a variable length file that would > later be transfered to the VAX to be read by the ST400 (SWIFT)G application, and they were so surprised that a VAX guy could teach themeC something on their IBM turf. They were used to reading fixed lenghttE records. COBOL handles both fixed and variable length quite well, but . they just had never used variable length ones.  D The same can be said of VMS. It is quite easy to teach someone aboutB using fixed, variable or whatever from C. But if you don't do this> simple step, the newbie will be lost and hate the file system.   ------------------------------  % Date: Wed, 19 Jan 2005 11:51:12 -0800E, From: Ken Fairfield <my.full.name@intel.com> Subject: Re: vms versus solaris + Message-ID: <csmdng$1p3$1@news01.intel.com>,  : Lots of good replies here. :-)  I'd like to add a somewhat- different emphasis to what Bob already wrote:o   Bob Koehler wrote: [...]oI >    I have a fellow who refers to them as "logical symbols".  I tell newe<                                              ^^^^^^^^^^^^^^^'     A very common mis-terminolgy, that!S  ( >    users these are the most important: > J >    1 they are both memory resident strings which stand for other stringsJ >    2 symbols are per-process, but usually inherited by spawned processesH >    3 symbols are global to all procs in a process or local to one procF >    4 logicals are per-process, job-wide, group-wide, system-wide, or >       cluster-wide' >    5 logicals are global to all procst? >    6 DCL will use symbols like UNIX aliases, but not logicals G >    7 the file system will automatically use logicals, but not symbolsc >     G >    I don't bother new users with inner vs. outer mode, concealed, andn2 >    all those other attributes logicals can have.  F      A. Symbols only exist under DCL, are confined to a process (tree)6         and disappear when the (master) process exits.4      B. Symbols are translated automatically by DCL.F      C. Logical names (created in tables other than the Process or JobD         tables) are non-volatile and remain defined until explicitly+         removed (or the system shuts down).dD      D. Logical names in other than the Process table are accessibleB         system-wide and changes made to them appear immediately to0         all processes which have access to them.F      E. Logical names are translated automatically by the file system,9         but their use is not confined to the file system.a          -Keno -- u6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield8! D1C Automation VMS System Supports" who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------    Date: 19 Jan 2005 14:02:32 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)p Subject: Re: vms versus solaris 3 Message-ID: <8s9COfca+LTP@eisner.encompasserve.org>   _ In article <csm4fv$t7$1@lnx107.hrz.tu-darmstadt.de>, m.kraemer@gsi.de (Michael Kraemer) writes:a  @ > In former times some of the VMS bigots in my field joked aboutE > the - in their view - strange concept of record structured files oneO > IBM's mainframes. "No need for that, just open a file and be happy bytewise".-  D VMS has always had record structured files, so I don't know why they would complain.i  B Or perhaps VMS languages are better at opening a record structuredC file and adapting to whatever record structure is found in the file E definition, rather than having been coded in advance for a particular  record size.  = Does VSAM on MVS provide carefree "variable length" records ?4   ------------------------------  % Date: Wed, 19 Jan 2005 15:33:11 -0500h( From: Bill Todd <billtodd@metrocast.net> Subject: Re: vms versus solarisc= Message-ID: <kYOdnc5DOoSeWXPcRVn-1g@metrocastcablevision.com>e   Keith Cayemberg wrote: > Bill Todd wrote: >  >> Dave Weatherall wrote:a >> >> ....e >>	 >>   As an >>G >>> record-oriented user/programmer, it _is_ a decisive plus but then, o? >>> perhaps, I fall into the 'locked in' category (mentally or , >>> philosophically).h >> >> >>F >> The point is that as a record-oriented user/programmer, you'd also J >> have access to the kinds of packages I mentioned on Unix (or - blech - G >> even to some extent on Windows) - in fact, to a considerably larger  G >> collection of options in this area than is available to you on VMS, cD >> many of them free or very low cost but still very functional and I >> stable and quite a few of them also somewhat more technically current tJ >> than RMS is (e.g., in their integral use of journaling to improve both   >> performance and reliability). >>G >> The fact that RMS is bundled and supported as part of the OS may be sG >> convenient and reassuring, but is hardly of *major* significance to t@ >> most users (or applications, though not having a third-party 7 >> dependency in this area is part of the convenience).h >>	 >> - billt >  > I > It appears to me that everyone here fails to understand the philosophy oI > behind having an universal record handling service integrated into the   > operating system.t  C Not really.  Some of us just recognize that it's manifestly not as f> important to the rest of the world as it appears to be to you.   - bill   ------------------------------  % Date: Wed, 19 Jan 2005 21:57:50 +0100 0 From: Keith Cayemberg <keith.cayemberg@arcor.de> Subject: Re: vms versus solarisnB Message-ID: <41eec9ce$0$17618$9b4e6d93@newsread4.arcor-online.net>   Bill Todd wrote:   > Keith Cayemberg wrote: >  >> Bill Todd wrote:e >> >>> Dave Weatherall wrote: >>>I >>> .... >>>u
 >>>   As a >>>uH >>>> record-oriented user/programmer, it _is_ a decisive plus but then, @ >>>> perhaps, I fall into the 'locked in' category (mentally or  >>>> philosophically). >>>  >>>  >>>a >>>aG >>> The point is that as a record-oriented user/programmer, you'd also uI >>> have access to the kinds of packages I mentioned on Unix (or - blech dJ >>> - even to some extent on Windows) - in fact, to a considerably larger H >>> collection of options in this area than is available to you on VMS, E >>> many of them free or very low cost but still very functional and hJ >>> stable and quite a few of them also somewhat more technically current F >>> than RMS is (e.g., in their integral use of journaling to improve & >>> both performance and reliability). >>>nH >>> The fact that RMS is bundled and supported as part of the OS may be H >>> convenient and reassuring, but is hardly of *major* significance to A >>> most users (or applications, though not having a third-party a8 >>> dependency in this area is part of the convenience). >>>i
 >>> - bill >> >> >>J >> It appears to me that everyone here fails to understand the philosophy J >> behind having an universal record handling service integrated into the  >> operating system. >  > E > Not really.  Some of us just recognize that it's manifestly not as u@ > important to the rest of the world as it appears to be to you. >  > - bill  H Well, the thread did run a long ways without anyone discussing quality. B   Should I then accept that the world isn't interested in quality C mechanisms anymore then?  I suppose with the horrid, and worsening yD quality of software development in the world I suppose I'll have to H accept most are not interested. Get the contract, don't think about the F design, program it PDQ, get paid, get paid more to fix it later. That F does seem to be the sorry state of affairs in most of the IT industry.  D Sorry, I claim to be an expert in building quality mission-critical > systems, and I can't operate that way even if it means my job.H I've carefully explained my reasoning, the world can take it, leave it,  or explain to me why I'm wrong.    Cheers!    Keith Cayembergm  F P.S. I didn't intend to sound overly personal or global in saying "It G appears to me that everyone here fails to understand". I know how most oD here appreciate VMS for it's quality. But I still suspect, from the F preceding discussion, some were not fully realizing how fundamental a   role RMS plays in VMS's quality.   ------------------------------  % Date: Wed, 19 Jan 2005 16:36:28 -0500a) From: "Neil Rieck" <n.rieck@sympatico.ca>d Subject: Re: vms versus solarisa; Message-ID: <IpAHd.49062$W33.1126907@news20.bellglobal.com>t  ; "John Laird" <nospam@laird-towers.org.uk> wrote in message  2 news:ej2tu0d1caqniah90aa3moqcv1c5puv8ge@4ax.com...J > On Wed, 19 Jan 2005 06:25:24 -0800, "Tom Linden" <tom@kednos.com> wrote: >e. >>On Tue, 18 Jan 2005 23:16:19 -0500, JF Mezei' >><jfmezei.spamnot@teksavvy.com> wrote:S >>D >>> Is it correct to state that RUN/DETACHED image.exe will not give= >>> image.exe access to any symbols for reading and writing ?d >>  >>What about lib$[s,g]et_symbol? >u > They will return LIB-F-NOCLI.  >t You are 100% correct.s  G But when I need to create a server process with an attached CLI, I run sH "SYS$SYSTEM:LOGINOUT.EXE" and pass it a "RUN image.exe" command through  SYS$INPUT. Works like a charm.  
 Neil Rieck Kitchener/Waterloo/Cambridge,e Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html e   ------------------------------  % Date: Wed, 19 Jan 2005 17:44:15 -0500 # From: "John Smith" <a@nonymous.com>  Subject: Re: vms versus solaris , Message-ID: <Zc2dneC7adZcf3PcRVn-gg@igs.net>   Keith Cayemberg wrote: > JF Mezei wrote:d >d >> Tom Linden wrote: >>E >>> The ISAM packaged developed to support PL/I under Ultrix was spun0E >>> off as a separately licensable package, but I don't think it ever ) >>> sold very much outside of PL/I usage.r >> >>G >> You have to realise that on Unix and Windows, the lack of RMS simplyfG >> forced people to buy a database package. Had RMS been made available0F >> to Windows and various Unixes, Oracle wouldn't be where it is todayD >> because most people's needs would be handled nicely with RMS/ISAM	 >> files.i >>C > Good, but what does the database package do for all those readilypG > available file creating and transfer capabilities on these platforms?yF > It's still too easy to go around these packages when transferring or9 > storing information, or corrupting someone else's files>F > unintentionally. Getting around RMS on VMS is not the default and itE > it's not particularly easy or easier either, and even then the filetH > must generally have RMS recognizable attributes set to exist in an ODSH > directory. Its eventually only easier to lie about the attributes with > $QIO and $QIOW.r > G > Enforcing the use of a DB package for all potential sources of recordyC > error is easier said than done in large organisation with complexeC > systems and many contracted projects over multiple generations oftH > programmers. And as already hinted elsewhere, perhaps your life-savingE > mission-critical program is only one part of a customer environmentjE > where you don't have any control over their IT policies, other than4E > what platform your program runs on. Your application is going to be ? > very dependent on the quality of the chosen platform, and thesE > decisions that were made in it's design, such as the existence of agC > default RMS-like service to guard whatever files your applicationb@ > works with, including the DB file and the program file itself. >'	 > Cheers!m >g > Keith Cayemberg     L Back when I used to trade bonds and do esoteric structured finance for a livI ing, I had a big sign stuck on my 160-line phone for all who passed by mye) desk could see that read "Data IS Money".t  L If you can't trust your data then your application programs don't matter oneI iota. And trusting your data means knowing that it is properly and safely>! stored, accessed, and not munged.   K RMS and the common language calling standard on VMS meant we could use Apl,hJ Cobol, and Fortran as the need arose within one app and still be sure that1 we had good data - of course we were careful too.e   ------------------------------  % Date: Wed, 19 Jan 2005 18:13:19 -0500 ( From: Bill Todd <billtodd@metrocast.net> Subject: Re: vms versus solarise= Message-ID: <M4GdncELwfIRdHPcRVn-iQ@metrocastcablevision.com>    Keith Cayemberg wrote:   ...b  J > Well, the thread did run a long ways without anyone discussing quality. C >  Should I then accept that the world isn't interested in quality - > mechanisms anymore then?  D No, you should just learn that quality isn't a black-or-white issue I which RMS provides and other platforms do not - any more than suggesting eE that anyone who doesn't program in Ada doesn't care about quality (I dH programmed for many years in assembler, for example, and RMS-11 did not ; suffer for it - nor did later projects which I wrote in C).d   - bill   ------------------------------  % Date: Thu, 20 Jan 2005 04:33:27 +0800e From: prep@prep.synonet.comy Subject: Re: vms versus solariss- Message-ID: <87oeflyx9k.fsf@prep.synonet.com>t  = koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:0  F >    People running the systems have a very heavy impact.  But we haveD >    a group of people heavily trained in Solaris who can't keep theB >    things up.  Meanwhile the VMS systems they admin just keep on >    keeping on.  G "We really should learn more about the Vax, but it just keeps working."a  D That is an exact quote from the head operator at a PPOE. Or as exact' as memory allows over 15 years. Gulp...   D BTW, she was no slouch, they had MVS, OS/400, NCRs back to Centurys,@ Honeywells runnning OS/9 I think, DGs. Place was a museum, and aB gravitational collapse disaster. And one 6xxx with HSC RA8x disks.   -- t< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.o@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 20 Jan 2005 04:40:48 +0800m From: prep@prep.synonet.com  Subject: Re: vms versus solaris'- Message-ID: <87k6q9ywxb.fsf@prep.synonet.com>h  + "Eitan" <no_spam_please@nospam.com> writes:   6 > Is there any resamblance between vms and solaris os.  ; They both run on things called a "computer" and are sold byJ* thinks that if their lips move, are lying.  F > If so, then what are the main things that are simmiliar and what are > not (in brief) ?  B You know the joke about the papacy, world history and one page?...  > Almost everything is different all the way from the underlying comcepts to the implentation.t   -- d< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.f@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 20 Jan 2005 04:44:06 +0800p From: prep@prep.synonet.coml Subject: Re: vms versus solarish- Message-ID: <87fz0xywrt.fsf@prep.synonet.com>t  + "Neil Rieck" <n.rieck@sympatico.ca> writes:d  F > As some people have already mentioned to me by email, modern flavorsC > of UNIX do implement quota-based resource management. (most of myI@ > UNIX experience came from BSD 4.4 on PDP-11/44 back in the midD > 1980's and lots of stuff has changed since then). It would be nice? > if someone in this newsgroup with experience on both UNIX andu( > OpenVMS would set the record straight.  F If it was 4.4, it was probably a Vax. For any 11, you would be running BSD 2.x.   -- s< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 20 Jan 2005 04:56:38 +0800o From: prep@prep.synonet.com1 Subject: Re: vms versus solaris2- Message-ID: <87brblyw6x.fsf@prep.synonet.com>   * m.kraemer@gsi.de (Michael Kraemer) writes:  1 > Relegate that to some library once and for all.   C If you allow `put it in a library' to define a high level language,o< then the front panel switches comply with that `definition'!   -- 0< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.e@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 20 Jan 2005 05:04:33 +0800r From: prep@prep.synonet.comu Subject: Re: vms versus solarish- Message-ID: <877jm9yvtq.fsf@prep.synonet.com>s  * bill@cs.uofs.edu (Bill Gunshannon) writes:  E > A stream of bytes seems to meet the needs of the Unix userbase just C > fine.  Anything beyond that can be layered on top of the existingiD > minimalist "stream of bytes".  Not sure about what you mean by CLID > Architecture.  Care to explain.  (I looked the term up with GoogleC > and none of the explanations I saw would seem to apply to VMS any  > more than Unix.)  B Case example. User has a unix system and two apps he wants to run.= Both are rather large and use `db' type packages, *different*1D packages, so they can't run together one the one sett of files.  And: neither vendor was interested in changing, or allowing it.   -- d< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Thu, 20 Jan 2005 05:08:53 +0800' From: prep@prep.synonet.com> Subject: Re: vms versus solaris>- Message-ID: <873bwxyvmi.fsf@prep.synonet.com>p  * bill@cs.uofs.edu (Bill Gunshannon) writes:  D > But which is the default when I say "OPEN" in Pascal or some other@ > language? Yes, you can get around RMS, but VMS starts with theD > everything including the kitchen sink.  Unix starts with the least> > and lets the user add on additional requirements.  Different@ > approaches to the same problem caused by the difference in the= > underlying paradigm of the OS.  Neither one is better, just  > different.  D Not quite. unix gives you type=undefined, no lock, and NOTHING else.F Anything and everything above that has to be brought to the table, andE if you want your apps to work with the same data, thay had better usec< the same access packages, or at least the same data formats.   -- -< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.a@                                              West Australia 6076* comp.os.vms,- The Older, Grumpier Slashdot. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   Date: 19 Jan 2005 23:59:59 GMT( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: vms versus solarisi, Message-ID: <358ajvF4jjdvmU1@individual.net>  - In article <877jm9yvtq.fsf@prep.synonet.com>,i 	prep@prep.synonet.com writes:, > bill@cs.uofs.edu (Bill Gunshannon) writes: > F >> A stream of bytes seems to meet the needs of the Unix userbase justD >> fine.  Anything beyond that can be layered on top of the existingE >> minimalist "stream of bytes".  Not sure about what you mean by CLIeE >> Architecture.  Care to explain.  (I looked the term up with GooglerD >> and none of the explanations I saw would seem to apply to VMS any >> more than Unix.)n > D > Case example. User has a unix system and two apps he wants to run.? > Both are rather large and use `db' type packages, *different*rF > packages, so they can't run together one the one sett of files.  And< > neither vendor was interested in changing, or allowing it.  tA One can always come up with contrived examples to prove any pointmD no matter how silly.  Let's see, customer has VMS, wants to run SAP.2 Oops.  Vendor is not interested in running on VMS.   bill   -- yJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   h   ------------------------------  % Date: Wed, 19 Jan 2005 19:32:45 -0500g' From: Dave Froble <davef@tsoft-inc.com>y Subject: Re: Webcast and VMS, Message-ID: <41EEFC2D.6040700@tsoft-inc.com>   John Smith wrote:M  
 > Dave wrote:i > F >>You asked for suggestions for improving the perception of VMS in the7 >>marketplace.  At least I think that's what you asked.l >>D >>I think you've already said what's required. A quote from the Q&A: >>D >>"OpenVMS is one of the most powerful operating environments in the >>industry." >>D >>All you need to do is continue to say this publically.  Often.  InA >>advertisements.  Every salesman should make this statement to acE >>customer, at least once, regardless of what the customer is looking, >>at.M >>E >>If a customer had to choose between a perceived "industry standard"pD >>and "the best", how many people do you know that want second best.@ >>All you have to do is make sure that they know that "the best"# >>exists, and is available from HP.r >>E >>It's my perception that HP makes more on a VMS sale than most othereG >>  HP products. Most VMS customers buy lots of support.  Good support,x >>forget about India.e >> >  >  > D > Well put.   try sending this to Ann (and Marcello) using the usualJ > fname.lname@CUTTHIShp.com, perhaps with 'OpenVMS' as the subject line to9 > escape spam filters. Also request a Read Reply receipt.o    P Actually, the post to c.o.v was the second reciepient.  Ann dot livermore at hp O dot com was the first.  I got a rather quick, if short, reply.  She passed the t info to Mark and Rich.  Q I have to wonder about the quick response.  Do executives have nothing better to cI do than read e-mail?  Was there a staff handling her e-mail?  Don't know.b  O Still, because I have the scorch marks, it reminded me of another such message nP in the 1999-2000 time frame, hand delivered to Curly, who promptly handed it to  Rich.   M How do you spell choir, cause it feels like that's all I'm preaching to.  If eN Mark and Rich do have the capability of advertising VMS, and getting every HP Q salesperson to mention, just as an extra bit of data, the quote from above, then mQ we have some serious ass to kick and now know who.  Alas, I don't feel they have r that authority.p   Dave   ------------------------------   End of INFO-VAX 2005.039 ************************