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? Re: Marcello predicts 500% perfomance improvement Re: Marcello predicts 500% perfomance improvement Re: Marcello predicts 500% perfomance improvement Re: Marcello predicts 500% perfomance improvement 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 ---------------------------------------------------------------------- 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> We are trying to capture use of the Authorize and SYSGEN programs within our Open VMS 7.1 system. We currently have accounting enabled and set to record image however usage of these programs does not seem to be tracked. 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 From: Keith Cayemberg Subject: Re: Accounting Utility Message-ID: <41eeb794$0$822$9b4e6d93@newsread2.arcor-online.net> Andrew Butchart wrote: > We are trying to capture use of the Authorize and SYSGEN programs > within our Open VMS 7.1 system. We currently have accounting enabled > and set to record image however usage of these programs does not seem > to be tracked. > > Am I missing something or is there a setup in ACCOUNTING that needs to > be defined? > > Thanks > > andrew@floatingbear.ca I would suggest trying the SET AUDIT command and studying Alarm ACLs as well. Image accounting usually creates rapidly growing accounting files, be 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 Message-ID: In article <41eeb794$0$822$9b4e6d93@newsread2.arcor-online.net>, Keith Cayemberg writes: > Andrew Butchart wrote: > >> We are trying to capture use of the Authorize and SYSGEN programs >> within our Open VMS 7.1 system. We currently have accounting enabled >> and set to record image however usage of these programs does not seem >> to be tracked. >> >> Am I missing something or is there a setup in ACCOUNTING that needs to >> be defined? >> >> Thanks >> >> andrew@floatingbear.ca > > I would suggest trying the SET AUDIT command and studying Alarm ACLs as > well. In particular, someone might use system services to change the values 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 Message-ID: You might want to do this. INSTALL ADD /ACCOUNTING /ACCOUNTING /NOACCOUNTING (default) Enables image-level accounting for selected images even if image accounting is disabled on the local node (by using the DCL 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. Keith Cayemberg wrote on 01/19/2005 02:40:03 PM: > Andrew Butchart wrote: > > > We are trying to capture use of the Authorize and SYSGEN programs > > within our Open VMS 7.1 system. We currently have accounting enabled > > and set to record image however usage of these programs does not seem > > to be tracked. > > > > Am I missing something or is there a setup in ACCOUNTING that needs to > > be defined? > > > > Thanks > > > > andrew@floatingbear.ca > > I would suggest trying the SET AUDIT command and studying Alarm ACLs as > well. > > Image accounting usually creates rapidly growing accounting files, be > 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 Subject: Re: An Interview With Mr. OpenVMS Himself Message-ID: <1106168744.369097.66340@c13g2000cwb.googlegroups.com> Kenneth Farmer wrote: > ShannonKnowsHPC.com: > http://www.shannonknowshpc.com/stories.php?story=05/01/18/0435366 > > > > Ken > > OpenVMS.org > _____________________________________ > Kenneth R. Farmer <>< > SpyderByte: http://www.SpyderByte.com I certainly hope Terry is right ... but you need the marketing and solutions to be there for it to happen! ------------------------------ Date: Wed, 19 Jan 2005 15:39:13 -0500 From: Bill Todd Subject: Re: An Interview With Mr. OpenVMS Himself Message-ID: Kenneth Farmer wrote: > ShannonKnowsHPC.com: > http://www.shannonknowshpc.com/stories.php?story=05/01/18/0435366 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 Codes Message-ID: <1106176282.883764.114050@f14g2000cwb.googlegroups.com> 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 Codes Message-ID: In article <1106176282.883764.114050@f14g2000cwb.googlegroups.com>, errorcodeforum@gmail.com writes: > 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 From: David J Dachtera Subject: Re: Error log message Message-ID: <41EF0F1F.230D4E6E@comcast.net> johnhreinhardt@yahoo.com wrote: > > NI-SCS SUB-SYSTEM, _VX4500$PEA0: > > 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, > cables, switch/hub and the settings on all of these to see if something > has changed or gone bad. We had a similar problem here. Our dev. cluster was reporting errors 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" Subject: Re: GnuPG in batch Message-ID: "David Gray" wrote in message news:ccssu09lrehgkq3a6rik3nvdluhblah07p@4ax.com... > Hi all, > > OpenVMS 7.3-2 > GnuPG v1.2.3 > > Has anyone got an example of how to use the PASSPHRASE-FD command of > GnuPG when running in batch? I've searched the net but cannot find > any examples of it's use under VMS. > > I'm currently writing the GPG command into a temporay command file > with the passphrase on the second line but wondered if the > PASSPHRASE-FD would provide a 'neater' solution. > > > Thanks in advance > Dave. You can embed the passphrase in the command file as: $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) Subject: HAMMER down - apologies to Nugent (Was: Marcello blah blah blah) Message-ID: In article <41EF3B60.10805@tsoft-inc.com>, Dave Froble writes: > Rob Young wrote: > >> In article <41EDD151.7020004@tsoft-inc.com>, Dave Froble writes: >> >>>FredK wrote: >>> >>> >>>>"Dave Froble" wrote in message >>>> >> >>> >>>>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. >>>> >>> >>>What can I say. It's beyond anything I could have dreamed of. :-) >>> >>> >> >> VAX? Cough. It is dreaming. And uneconomical dreams at that. > > > Uh... Rob.... We were talking about back when it could have been significant. > 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. > > 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. > >> Is it any accident that Samsung and a host of others are partnering >> 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 >> how Paul has been edukatin Linux T over at realworld: >> >> http://tinyurl.com/52jdz >> >> Name: Paul DeMone (pdemone@igs.net) 1/19/05 >> >> Linus Torvalds (torvalds@osdl.org) on 1/19/05 wrote: >> --------------------------- >> >>>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 takers >>>>rather than bundled inside a system they sell. >>>> >>>That's what I assumed you have to mean, but the economic >>>importance you place on this still totally escapes me. >>> >> >> Let me make this as simple for you as possible. An MPU >> that costs $125 to fabricate will always be much more >> capable than a processor that costs $30 to fabricate, >> both being in the same technology. But the mass market >> (PCs) is happy with the $30 MPU and is willing to buy >> >>>100m of them a year at ~$150 ASP. >>> >> >> But some sockets demand more performance, RAS, and >> or scalability than a $30 mass market chip can provide. >> This high end market wants the $125 MPU and is willing >> buy >1.5m of them a year at $1500+ ASP. For nearly the >> last two decades this market has been serviced by five >> 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 >> making similar but incompatible MPUs, and the vendor >> lock-in effect with each ISA/platform. >> >> A merchant chip family like IPF will allow the market >> for high end chips/systems to consolidate around a >> single processor family and ISA. This eliminates the >> duplication of effort (effort which was starting to kill off >> the smaller players anyways with the escalating cost >> of high end MPU development). The reduction in the >> number of ISAs in the high end market improves ISV >> efficiency. And from the customer's perspective the >> move of high end systems market to merchant MPUs >> *increases* competition among OEMs because there >> is no longer an ISA-based lock-in effect. > > > 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. > >> VAX was doomed, Alpha was doomed. SPARC is doomed (shocka), Power is >> doomed (strong arguments here against that view, but hey it is a >> Tower of Babel IBM micro is building on ;-). > > > 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 much of a loser it was. A wonderful thing filings are: http://in.tech.yahoo.com/041231/137/2irbt.html IBM PC unit sold to Lenovo built up $1 bln deficit SAN FRANCISCO (Reuters) - IBM's PC unit piled up nearly $1 billion in cumulative losses in recent years, the company said in a filing on Thursday detailing the planned sale of the business to China's Lenovo Group. Guess what? IBM micro has been a big loser for years. Hold out? Nah. It's about business, therefore money. Here is an internal IBM exchange: "This is stupid, we are bleeding badly." "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." "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." > Who was it that killed off VAX and Alpha. We have > the likes of Palmer and Capalles. Did they really understand the technology? I > doubt it. Nor did they have the resolve to "do the right thing". Right. Vision was they needed a RISC. Fair enough vision circa 1980. But guess what? The vision is merchant circa 2005. > > Back in 1960 Ford motor company suffered under the incluence of a bean counter. > Their car sales suffered because of this. Only when they went back to people > who loved the automobile and wanted to build "good" cars did their fortunes > reverse. Then the asshole got into government, and was a significant part of > the total fiasco that was Vietnam. Okay... 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. > >> 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. > > > I see your consistant hate of Sun coming out again. Dude - every time some one trots out Sun, I point out the realities. Sun is a wanna-be and it is obvious. > I always like it when some know-it-all predicts what's going to happen, based > upon their wishes. Rob sure called it right on HAMMER, huh? Like they say in > 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 breakout of Opteron versus Itanium revenues (courtesy of Gartner via the Reg): http://www.theregister.co.uk/2004/08/30/opteron_itanium_sales_q2/ The Q2 market for IPF servers was 5665 units worth $319m and for Opteron servers was 60k units worth $191m. --- Servers - not CPUs. But you can see that Q2 2004 Itanium was 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/ After tracking Opteron sales throughout Europe's seven biggest economies, Context today said that sales growth collapsed during the early month of Q4 2004. [Early month of Q4? Sheesh - why not just come out and say October?] In Q3 2004, sales grew month on month by up to 50 per cent, but October sales were only 8.6 per cent up on September. In November, sales fell 18 per cent on the previous month. Numbers for December 2004 are not yet available. Context expects Opteron-based servers to take under one percentage point of x86 server market share in Europe during Q4 2004. --- Sales fell 18 percent in Europe November compared to October. Opteron 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. 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? Message-ID: <5fgtu0d5tc06cdqb1vaa8613bpkjhidvlm@4ax.com> I have been system manager at Digital for 10 years 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? Message-ID: In article <5fgtu0d5tc06cdqb1vaa8613bpkjhidvlm@4ax.com>, Ove Axelsson < m8742@abc.se> writes: > I have been system manager at Digital for 10 years > 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 as a forum where VMS-related jobs are discussed. ------------------------------ Date: Wed, 19 Jan 2005 22:36:44 GMT From: "Ransom Fitch" 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 "Ove Axelsson" < m8742@abc.se> wrote in message news:5fgtu0d5tc06cdqb1vaa8613bpkjhidvlm@4ax.com... >I have been system manager at Digital for 10 years > 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 Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: <41EECBF9.B56D4E10@teksavvy.com> FredK wrote: > The volume is better, even if it isn't the size of the x86 business. HP-UX > is a bigger business than Tru64 was. At what point in 2004 did revenus for IA64-HPUX surpass PARISC-HPUX ? 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. A a gazillion vendors of industry standard Linux running on industry standard servers. > SUN is the one who has not been able to at least squeek out break even. > POWER and Itanium will be the only 2 surviving RISC architectures. SPARC will outlive IA64. For one thing, it has a huge installed base compared to IA64 which is essentially a stillbirth. > I haven't seen "mission critical" Linux or Windows yet, The USA navy has had experience with mission critical Windows. The NASDAQ runs its primary web site on Windows. And I think there are plenty of examples of this. I pointed to an article where the biggest supplier of McDonalds in the USA was down for about 2 weeks because of windows viri. As far as Linux is concerned, it is now embedded in so many devices that I wouldn't be surprised if many VMS shops had some mission critical "device" on their network that runs linux inside. (think routers, disk storage etc). > We've (VMS) invested 3-1/2 years of time and money in Itanium, and > for the forseable future, I don't see large scale AMD 64 systems with > mission critical Windows and Linux. The issue here is that you have no installed base on IA64. The Installed base is on PA Risc and Alpha (and MIPS for Tandem). What you have to look at is a few years ahead, when the 8086 may be scalable to large systems. Consider that AMD will have an 8086 with dual cores out before IA64. Consider what the 8086 and Power will be like in the 2007-2008 timeframe compared to IA64. If the performance and scalability differences of 8086 versus IA64 will be small, how could Intel/HP/SGI continue to justify the huge expenditures required to have IA64 follow the other chips with its own very different core and own set of very different compilers ? Remember that AMD didn't die as predicted and now has a hot 8086 based product. This has forced Intel to also plan a 64 bit 8086 and will force Intel to develop the 8086 very fast to match AMD. Had AMD died, Intel would have had a much easier job of keeping IA64 for servers and 8086 for desktops since there woudln't be any pressuire to push the 8086 beyond its ability play 3D games very fast. But that isn't the case. And IA64 must compete not only against Sparc, Alpha, Pa-Risc, Power but also against the 8086 (I included PA-Risc and Alpha since for the next couple of years, they remain in the competition because the cost of converting to IA64 won't be worth the conversion costs, especially if the 3rd party software doesn't exist on IA64). > The latest public move with Itanium removes > any stigma of having HP (a system competetor) from controlling IA64, > or having an unfair inside advantage. Public saw this as HP cutting losses from the IA64 programme. It is also a way for HP to shift part of the partner costs to SGI. Since Intel now bears the full development costs, it should normally price IA64 to recuperate those costs based on current volumes. This means that 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. HP would brag about this still being less expensive than developing the chip in-house. But consider this: Digital had top notch engineers working in an environment that put Alpha in the forefront with relatively small budgets. So much so that even with unlimited budgets, Intel still had to steal from Alpha to make its 8086 perform faster. And I don't think that one can argue that Alpha was the result of only better brains. There must have been a better environment and a better mandate given to engineers to result is such a dramatic difference in team performance when you compare deliverables of Alpha during the 1990s vs deliverables from IA64 during the 1990s. If the whole premise of EPIC is flawed, no matter how hard and how manyt brains you put on it, it won't make it right. And you'll still be stuck with a low volume chip that requires specialized compilers to get the promised performance to a much greater extent than on Alpha or other platforms. > Just because there are dissapointed people out there mad about the > demise of Alpha, does not mean that Itanium cannot succeed as one > of the 2 premier high-end, mission critical, UNIX (and VMS) platforms. Look, VMS isn't exactly a success story. It isn't being marketed. VMS' success is that it isn't dead yet. (and it is a big accomplishement considering the self inflicted wounds over the last decade). > 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 competition from AMD which forced Intel to put all its resources into protecting the 8086. ------------------------------ Date: Wed, 19 Jan 2005 21:18:44 GMT From: "Kenneth Farmer" Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: This might be of interest. BigTux project shows Linux scaling to 64 processors http://news.zdnet.co.uk/0,39020330,39184546,00.htm Ken OpenVMS.org _____________________________________ Kenneth R. Farmer <>< SpyderByte: http://www.SpyderByte.com "JF Mezei" wrote in message news:41EECBF9.B56D4E10@teksavvy.com... > FredK wrote: >> The volume is better, even if it isn't the size of the x86 business. >> HP-UX >> is a bigger business than Tru64 was. > > At what point in 2004 did revenus for IA64-HPUX surpass PARISC-HPUX ? > 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. > > A a gazillion vendors of industry standard Linux running on industry > standard servers. > >> SUN is the one who has not been able to at least squeek out break even. >> POWER and Itanium will be the only 2 surviving RISC architectures. > > SPARC will outlive IA64. For one thing, it has a huge installed base > compared to IA64 which is essentially a stillbirth. > > >> I haven't seen "mission critical" Linux or Windows yet, > > The USA navy has had experience with mission critical Windows. The > NASDAQ runs its primary web site on Windows. And I think there are > plenty of examples of this. I pointed to an article where the biggest > supplier of McDonalds in the USA was down for about 2 weeks because of > windows viri. > > > As far as Linux is concerned, it is now embedded in so many devices that > I wouldn't be surprised if many VMS shops had some mission critical > "device" on their network that runs linux inside. (think routers, disk > storage etc). > > >> We've (VMS) invested 3-1/2 years of time and money in Itanium, and >> for the forseable future, I don't see large scale AMD 64 systems with >> mission critical Windows and Linux. > > The issue here is that you have no installed base on IA64. The Installed > base is on PA Risc and Alpha (and MIPS for Tandem). What you have to > look at is a few years ahead, when the 8086 may be scalable to large > systems. Consider that AMD will have an 8086 with dual cores out before > IA64. > Consider what the 8086 and Power will be like in the 2007-2008 timeframe > compared to IA64. > > If the performance and scalability differences of 8086 versus IA64 will > be small, how could Intel/HP/SGI continue to justify the huge > expenditures required to have IA64 follow the other chips with its own > very different core and own set of very different compilers ? > > Remember that AMD didn't die as predicted and now has a hot 8086 based > product. This has forced Intel to also plan a 64 bit 8086 and will force > Intel to develop the 8086 very fast to match AMD. > > Had AMD died, Intel would have had a much easier job of keeping IA64 for > servers and 8086 for desktops since there woudln't be any pressuire to > push the 8086 beyond its ability play 3D games very fast. > > But that isn't the case. And IA64 must compete not only against Sparc, > Alpha, Pa-Risc, Power but also against the 8086 (I included PA-Risc and > Alpha since for the next couple of years, they remain in the competition > because the cost of converting to IA64 won't be worth the conversion > costs, especially if the 3rd party software doesn't exist on IA64). > > >> The latest public move with Itanium removes >> any stigma of having HP (a system competetor) from controlling IA64, >> or having an unfair inside advantage. > > Public saw this as HP cutting losses from the IA64 programme. It is also > a way for HP to shift part of the partner costs to SGI. Since Intel now > bears the full development costs, it should normally price IA64 to > recuperate those costs based on current volumes. This means that > 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. > > > HP would brag about this still being less expensive than developing the > chip in-house. But consider this: Digital had top notch engineers > working in an environment that put Alpha in the forefront with > relatively small budgets. So much so that even with unlimited budgets, > Intel still had to steal from Alpha to make its 8086 perform faster. > > And I don't think that one can argue that Alpha was the result of only > better brains. There must have been a better environment and a better > mandate given to engineers to result is such a dramatic difference in > team performance when you compare deliverables of Alpha during the 1990s > vs deliverables from IA64 during the 1990s. > > If the whole premise of EPIC is flawed, no matter how hard and how manyt > brains you put on it, it won't make it right. And you'll still be stuck > with a low volume chip that requires specialized compilers to get the > promised performance to a much greater extent than on Alpha or other > platforms. > >> Just because there are dissapointed people out there mad about the >> demise of Alpha, does not mean that Itanium cannot succeed as one >> of the 2 premier high-end, mission critical, UNIX (and VMS) platforms. > > Look, VMS isn't exactly a success story. It isn't being marketed. VMS' > success is that it isn't dead yet. (and it is a big accomplishement > considering the self inflicted wounds over the last decade). > >> 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 > 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 Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: JF Mezei wrote: > As far as Linux is concerned, it is now embedded in so many devices that > I wouldn't be surprised if many VMS shops had some mission critical > "device" on their network that runs linux inside. (think routers, disk > storage etc). My Tivo... ;-) (Which will be networked with my VAX as soon as it's networked with anything.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 ------------------------------ Date: 19 Jan 2005 21:14:03 -0600 From: young_r@encompasserve.org (Rob Young) Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: <4Y6IDUr3xsxE@eisner.encompasserve.org> In article <41EDD151.7020004@tsoft-inc.com>, Dave Froble writes: > FredK wrote: > >> "Dave Froble" wrote in message > > >> 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. > > > What can I say. It's beyond anything I could have dreamed of. :-) > VAX? Cough. It is dreaming. And uneconomical dreams at that. Is it any accident that Samsung and a host of others are partnering 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 how Paul has been edukatin Linux T over at realworld: http://tinyurl.com/52jdz Name: Paul DeMone (pdemone@igs.net) 1/19/05 Linus Torvalds (torvalds@osdl.org) on 1/19/05 wrote: --------------------------- >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 takers >>rather than bundled inside a system they sell. > >That's what I assumed you have to mean, but the economic >importance you place on this still totally escapes me. Let me make this as simple for you as possible. An MPU that costs $125 to fabricate will always be much more capable than a processor that costs $30 to fabricate, both being in the same technology. But the mass market (PCs) is happy with the $30 MPU and is willing to buy >100m of them a year at ~$150 ASP. But some sockets demand more performance, RAS, and or scalability than a $30 mass market chip can provide. This high end market wants the $125 MPU and is willing buy >1.5m of them a year at $1500+ ASP. For nearly the last two decades this market has been serviced by five 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 making similar but incompatible MPUs, and the vendor lock-in effect with each ISA/platform. A merchant chip family like IPF will allow the market for high end chips/systems to consolidate around a single processor family and ISA. This eliminates the duplication of effort (effort which was starting to kill off the smaller players anyways with the escalating cost of high end MPU development). The reduction in the number of ISAs in the high end market improves ISV efficiency. And from the customer's perspective the move of high end systems market to merchant MPUs *increases* competition among OEMs because there is no longer an ISA-based lock-in effect. --- VAX was doomed, Alpha was doomed. SPARC is doomed (shocka), Power is doomed (strong arguments here against that view, but hey it is a Tower of Babel IBM micro is building on ;-). 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. Rob ------------------------------ Date: Thu, 20 Jan 2005 00:02:24 -0500 From: Dave Froble Subject: Re: Marcello predicts 500% perfomance improvement Message-ID: <41EF3B60.10805@tsoft-inc.com> Rob Young wrote: > In article <41EDD151.7020004@tsoft-inc.com>, Dave Froble writes: > >>FredK wrote: >> >> >>>"Dave Froble" wrote in message >>> > >> >>>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. >>> >> >>What can I say. It's beyond anything I could have dreamed of. :-) >> >> > > VAX? Cough. It is dreaming. And uneconomical dreams at that. Uh... Rob.... We were talking about back when it could have been significant. 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. Several other ifs would have had to occur, longer term, such as going after the high volume low cost market. > Is it any accident that Samsung and a host of others are partnering > 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 > how Paul has been edukatin Linux T over at realworld: > > http://tinyurl.com/52jdz > > Name: Paul DeMone (pdemone@igs.net) 1/19/05 > > Linus Torvalds (torvalds@osdl.org) on 1/19/05 wrote: > --------------------------- > >>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 takers >>>rather than bundled inside a system they sell. >>> >>That's what I assumed you have to mean, but the economic >>importance you place on this still totally escapes me. >> > > Let me make this as simple for you as possible. An MPU > that costs $125 to fabricate will always be much more > capable than a processor that costs $30 to fabricate, > both being in the same technology. But the mass market > (PCs) is happy with the $30 MPU and is willing to buy > >>100m of them a year at ~$150 ASP. >> > > But some sockets demand more performance, RAS, and > or scalability than a $30 mass market chip can provide. > This high end market wants the $125 MPU and is willing > buy >1.5m of them a year at $1500+ ASP. For nearly the > last two decades this market has been serviced by five > 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 > making similar but incompatible MPUs, and the vendor > lock-in effect with each ISA/platform. > > A merchant chip family like IPF will allow the market > for high end chips/systems to consolidate around a > single processor family and ISA. This eliminates the > duplication of effort (effort which was starting to kill off > the smaller players anyways with the escalating cost > of high end MPU development). The reduction in the > number of ISAs in the high end market improves ISV > efficiency. And from the customer's perspective the > move of high end systems market to merchant MPUs > *increases* competition among OEMs because there > is no longer an ISA-based lock-in effect. It's a bit sickening to think that once again the lowest common denominator is the people's choice. > VAX was doomed, Alpha was doomed. SPARC is doomed (shocka), Power is > doomed (strong arguments here against that view, but hey it is a > Tower of Babel IBM micro is building on ;-). IBM is a special case. As long as their resolve holds out, they will not give in and accept a lesser chip. Who was it that killed off VAX and Alpha. We have the likes of Palmer and Capalles. Did they really understand the technology? I doubt it. Nor did they have the resolve to "do the right thing". Back in 1960 Ford motor company suffered under the incluence of a bean counter. Their car sales suffered because of this. Only when they went back to people who loved the automobile and wanted to build "good" cars did their fortunes reverse. Then the asshole got into government, and was a significant part of the total fiasco that was Vietnam. Well, the likes of Palmer, curly, carly, and a few others are today's MacNamara, 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 to > 10 years for some to disappear, SPARC goes much faster. I see your consistant hate of Sun coming out again. They have lots of current customers. Opteron may end up in lots of their systems, but that hasn't played out yet. I always like it when some know-it-all predicts what's going to happen, based upon their wishes. Rob sure called it right on HAMMER, huh? Like they say in football, when upsets happen. "That's why they play the game." Well Rob, the game isn't over yet. Dave ------------------------------ Date: Thu, 20 Jan 2005 00:11:02 GMT From: "Kenneth Farmer" Subject: Mark G. Interview on Slashdot and OSNews.com Message-ID: Though everyone might want to go to Slashdot and check out the comments on Terry's interview with Mark Gorham. 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... http://www.osnews.com/story.php?news_id=9449 Ken OpenVMS.org _____________________________________ Kenneth R. Farmer <>< SpyderByte: http://www.SpyderByte.com ------------------------------ Date: Wed, 19 Jan 2005 21:41:38 -0500 From: JF Mezei Subject: Multi threaded cookbook ? Message-ID: <41EF1A47.A5D92226@teksavvy.com> Is there a nice compact cookbook/document on how to write multi threaded applications on VMS, including the various implications with regards to VMS specific routines, ASTs etc ? (C language) Also, in terms of X windows, there are a few routines which are usable from within an AST. (for instance, inserting an event). Would those automatically be usable from a different thread as well? 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... Message-ID: <1106179759.229349.26140@f14g2000cwb.googlegroups.com> Schroeder, AJ wrote: > Hello, > > I have a OpenVMS hobbyist system running 7.3-1. I have TCPIP 5.3 installed > and functional, however, I would like to start using this machine as an NFS > server. Whenever I run TCPIP$CONFIG.COM and go into the server setup menu, > the NFS server shows that I do not have a license. I loaded (and enabled) > the UCX-IP-NFS license, but that did not help. > > My question; does the hobbyist program have a license for an NFS server? If > so, what is the product called? I have looked through the license file that > was sent to me by DECUS and the above PAK is the only one with NFS in the > name. Here is a list of the licenses on my machine: > > BASIC > C > OPENVMS-ALPHA > OPENVMS-HOBBYIST > UCX-IP-CLIENT > UCX-IP-NFS > 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. > > AJ Schroeder Take a look to see if you have a plain UCX license and install that. 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. ------------------------------ Date: Wed, 19 Jan 2005 20:01:23 -0600 From: David J Dachtera Subject: Re: Newbie Hobbyist NFS Question... Message-ID: <41EF10F3.5990FDB3@comcast.net> jordan@ccs4vms.com wrote: > > Schroeder, AJ wrote: > > Hello, > > > > I have a OpenVMS hobbyist system running 7.3-1. I have TCPIP 5.3 > installed > > and functional, however, I would like to start using this machine as > an NFS > > server. Whenever I run TCPIP$CONFIG.COM and go into the server setup > menu, > > the NFS server shows that I do not have a license. I loaded (and > enabled) > > the UCX-IP-NFS license, but that did not help. > > > > My question; does the hobbyist program have a license for an NFS > server? If > > so, what is the product called? I have looked through the license > file that > > was sent to me by DECUS and the above PAK is the only one with NFS in > the > > name. Here is a list of the licenses on my machine: > > > > BASIC > > C > > OPENVMS-ALPHA > > OPENVMS-HOBBYIST > > UCX-IP-CLIENT > > UCX-IP-NFS > > > 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. > > > > AJ Schroeder > > Take a look to see if you have a plain UCX license and install that. > 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. Like he said - install the UCX base license and load it. See how that goes... -- 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: 19 Jan 2005 13:26:03 -0600 From: kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) Subject: Re: Next Gen Fabs & Itanium Message-ID: <7GWUHLPlFlZb@eisner.encompasserve.org> In article <354igbF4gp8quU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > kaplow_r@encompasserve.org.TRABoD (Bob Kaplow) writes: >> In article , Keith Parris writes: >>> JF Mezei wrote: >>>> My guess is that Alpha VMS sales will outlive IA64 VMS sales. >>> >>> As Alpha sales are slated to end next year, in 2006, your guess is very >>> unlikely. >> >> When was the last PDP-11 sold? > > You can't answer that one without a crystal ball. The question should > not be in the past tense yet. Forget about the Alpha, I expect PDP-11 > sales to outlive IA64 sales. Exactly my point. PDP-11s are still being sold. So are used VAXen. Bob Kaplow NAR # 18L TRA # "Impeach the TRA BoD" >>> To reply, remove the TRABoD! <<< Kaplow Klips & Baffle: http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf www.encompasserve.org/~kaplow_r/ www.nira-rocketry.org www.nar.org Voting for "the lesser of two evils" is still voting for evil. ------------------------------ Date: Thu, 20 Jan 2005 04:08:35 +0800 From: prep@prep.synonet.com Subject: Re: Next Gen Fabs & Itanium Message-ID: <87wtu9yyf0.fsf@prep.synonet.com> JF Mezei writes: > Robert Deininger wrote: >> Alpha systems absolutely cost more to make than similar Integrity >> 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. > 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 ? > Is it the connectors ? > Is it the type of memory ? > Are alpha servers built with gold solder instead of lead ? History. A large percentage of Vaxen and Alphas ended up at sites with fixed price maintainance contracts. NOTHING digs your gave faster than a reliability dog that YOU have to carry the pain and costs for! So DEC designs tended to aim high so as to save *DEC* money after the sale. -- Paul Repacholi 1 Crescent Rd., +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. EPIC, The Architecture of the future, always has been, always will be. ------------------------------ Date: Wed, 19 Jan 2005 20:00:46 GMT From: "John Vottero" Subject: Re: Paradigm Message-ID: "David J Dachtera" wrote in message news:41EDC5E1.214ABAA5@comcast.net... >I wasn't sure how to title this. > > The thought occurred to me today (told you I'm rather slow) that there > is perhaps a larger difference between the incumbent OpenVMS management > and the denizens of this group than is immediately obvious at the > surface. > > Quite possibly, the incumbents are "pacificists"; that is, play along, > 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 -0600 From: David J Dachtera Subject: Re: Paradigm Message-ID: <41EF104D.AB775A0@comcast.net> John Vottero wrote: > > "David J Dachtera" wrote in message > news:41EDC5E1.214ABAA5@comcast.net... > >I wasn't sure how to title this. > > > > The thought occurred to me today (told you I'm rather slow) that there > > is perhaps a larger difference between the incumbent OpenVMS management > > and the denizens of this group than is immediately obvious at the > > surface. > > > > Quite possibly, the incumbents are "pacificists"; that is, play along, > > 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. I'm talking about: o *TAKING ACTION*, not talking about taking action. o Agressively pursuing new customers. o Actively marketing and promoting VMS ...in short, all those imperatives that HP and VMS are reluctant to embrace ("Feared Things First"). -- 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:00:57 -0500 From: JF Mezei Subject: Re: Paradigm Message-ID: <41EF1ECD.C281465C@teksavvy.com> David J Dachtera wrote: > I'm talking about: > o *TAKING ACTION*, not talking about taking action. > o Agressively pursuing new customers. > o Actively marketing and promoting VMS In terms of Sue, I think she is fairly proactive, especially when you consider she is responsible for the VMS ambassadors programme. And I have never seen her defend the lack of VMS marketing here, unlike other VMS folks who have often stated that marketing VMS would be a waste of money. When Marcello was the head of VMS, I got the dictinct impression that he couldn't rock the boat too much. He did head a very succesful revival of VMS that lasted a few months, and that was just after he succeeded in sheving the plans to kill VMS. But as soon as HP can into the game, he went quiet and became a good quiet and obediant boy worthy of promotion. He got promoted and hasn't rocked the boat much. Remember that folks like Winkler and Stallard are atill at HP with influence. Gorham probably has to play it safe and not rock the boat. There are two questions in my mind: How widespread is the opinion in VMS management that marketing VMS would not yield results ? If VMS management aren't fighting to get marketing freedom, they won't get it. is Marcello slowly planting the seeds to change attitudes towards VMS ? or Is marcello being a good obediant puppy, worried about his carreer ? ------------------------------ Date: Thu, 20 Jan 2005 00:06:15 -0500 From: Dave Froble Subject: Re: Paradigm Message-ID: <41EF3C47.9030603@tsoft-inc.com> JF Mezei wrote: > David J Dachtera wrote: > >>I'm talking about: >>o *TAKING ACTION*, not talking about taking action. >>o Agressively pursuing new customers. >>o Actively marketing and promoting VMS >> > > In terms of Sue, I think she is fairly proactive, especially when you > consider she is responsible for the VMS ambassadors programme. And I > have never seen her defend the lack of VMS marketing here, unlike other > VMS folks who have often stated that marketing VMS would be a waste of money. > > > > When Marcello was the head of VMS, I got the dictinct impression that he > couldn't rock the boat too much. He did head a very succesful revival of > VMS that lasted a few months, and that was just after he succeeded in > sheving the plans to kill VMS. But as soon as HP can into the game, he > went quiet and became a good quiet and obediant boy worthy of promotion. > He got promoted and hasn't rocked the boat much. > > Remember that folks like Winkler and Stallard are atill at HP with > influence. > > Gorham probably has to play it safe and not rock the boat. > > There are two questions in my mind: > How widespread is the opinion in VMS management that marketing VMS > would not yield results ? > If VMS management aren't fighting to get marketing freedom, they won't > get it. > > is Marcello slowly planting the seeds to change attitudes towards VMS ? > or Is marcello being a good obediant puppy, worried about his carreer ? > Well, if he isn't there, he can never sieze any opportunities should they arise, can he. Think of where VMS would be if there was no counters to Winkler and such. ------------------------------ Date: 19 Jan 2005 17:54:49 -0800 From: "Kannan" Subject: pthread_create() call returning ENOMEM Message-ID: <1106186089.085908.324940@c13g2000cwb.googlegroups.com> I am running a server application that is heavily threaded. It creates threads to execute some tasks and exits out of the thread when the task completes. This happens on a periodic basis at a rate of probably about 2 to 4 threads per minute. I find that the application fails in the pthread_create() call after about 15 to 20 hrs of running with a return value of ENOMEM(12). I checked my account quotas and they all seem to be adequate even at the point of failure. Here's the process quotas just after the process has failed in the pthread_create() call: --------------- Process Quotas: Account name: 28916 CPU limit: Infinite Direct I/O limit: 30000 Buffered I/O byte count quota: 8767744 Buffered I/O limit: 30000 Timer queue entry quota: 607 Open file quota: 2340 Paging file quota: 7670192 Subprocess quota: 95 Default page fault cluster: 64 AST quota: 19994 Enqueue quota: 8178 Shared file limit: 0 Max detached processes: 0 Max active jobs: 0 --------------- The MAXTHREADS system parameter on the system is at 256, and I do observe that the running threads in my process is nowehere near that number. I instrumented some thread tracking info to keep track of how many threads are created and deleted. At the point of failure, I observe that 1810 threads had been created, and 1806 threads had completed, leaving only 4 threads running. This is also confirmed when I do a 'show task/all' in my debugger session and all of the 1806 threads show status 'terminated'. My thread stacksize is at 500K. Is it possible that this stacksize value might cause the ENOMEM problem? As I understand it, this is a per-thread stacksize problem, and shouldn't be a problem with respect to mem availability a long as my PAGFILQUO is sufficient. Any pointers would be appreciated. ------------------------------ Date: Wed, 19 Jan 2005 20:18:51 -0600 From: David J Dachtera Subject: Re: pthread_create() call returning ENOMEM Message-ID: <41EF150B.7844249F@comcast.net> Kannan wrote: > > I am running a server application that is heavily threaded. It creates > threads to execute some tasks and exits out of the thread when the task > completes. This happens on a periodic basis at a rate of probably about > 2 to 4 threads per minute. I find that the application fails in the > pthread_create() call after about 15 to 20 hrs of running with a return > value of ENOMEM(12). I checked my account quotas and they all seem to > be adequate even at the point of failure. Here's the process quotas > just after the process has failed in the pthread_create() call: > --------------- > Process Quotas: > Account name: 28916 > CPU limit: Infinite Direct I/O limit: 30000 > Buffered I/O byte count quota: 8767744 Buffered I/O limit: 30000 > Timer queue entry quota: 607 Open file quota: 2340 > Paging file quota: 7670192 Subprocess quota: 95 > Default page fault cluster: 64 AST quota: 19994 > Enqueue quota: 8178 Shared file limit: 0 > Max detached processes: 0 Max active jobs: 0 > --------------- > > The MAXTHREADS system parameter on the system is at 256, and I do > observe that the running threads in my process is nowehere near that > number. I instrumented some thread tracking info to keep track of how > many threads are created and deleted. At the point of failure, I > observe that 1810 threads had been created, and 1806 threads had > completed, leaving only 4 threads running. This is also confirmed when > I do a 'show task/all' in my debugger session and all of the 1806 > threads show status 'terminated'. > > My thread stacksize is at 500K. > > Is it possible that this stacksize value might cause the ENOMEM > problem? As I understand it, this is a per-thread stacksize problem, > and shouldn't be a problem with respect to mem availability a long as > my PAGFILQUO is sufficient. > > Any pointers would be appreciated. This is likely a resource leak. -- 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: 19 Jan 2005 19:59:31 -0800 From: "Kannan" Subject: Re: pthread_create() call returning ENOMEM Message-ID: <1106193571.191537.182880@z14g2000cwz.googlegroups.com> Could you give some pointers as to how to narrow down the source of the leak. What can I look for in the SDA for the process? ------------------------------ Date: Thu, 20 Jan 2005 00:17:25 -0500 From: Dave Froble Subject: Re: pthread_create() call returning ENOMEM Message-ID: <41EF3EE5.1050601@tsoft-inc.com> Kannan wrote: > Could you give some pointers as to how to narrow down the source of the > leak. What can I look for in the SDA for the process? > > I'd agree with David, the first place to look is for some memory leak. It's hard to give some help when we don't know the application and what it's doing. I'd start by determining whether a thread will allocate any resources, such as memory. If so, then attempting to trace both allocation and deallocation of resources. I've never had to do this. Hopefully someone who has will offer some tips. Dave ------------------------------ Date: Wed, 19 Jan 2005 15:31:12 -0500 From: Bill Todd Subject: Re: RMS Message-ID: Tom Linden wrote: > Just curious, was RMS part of the original VMS design or did come about > in order to support PL/I and Cobol? RMS was part of the original VMS design. As Fred noted, its main characteristics were inherited from the existing RMS products on the PDP-11 (RSX, IAS, and RSTS systems) - though in truth these PDP-11 products only preceded VMS by a year or so and had therefore evolved with an eye toward the needs of VMS as well. COBOL influenced the design of RMS most visibly in the areas of alternate indexes and the ordering of duplicate key values. The main initial RMS architect (Ed Marison) also had a background in MUMPS, which contributed to some aspects of the indexed-file design. - bill ------------------------------ Date: Wed, 19 Jan 2005 11:06:42 -0800 From: "Tom Linden" Subject: RMS (was: vms versus solaris) Message-ID: Just curious, was RMS part of the original VMS design or did come about in order to support PL/I and Cobol? On Wed, 19 Jan 2005 17:13:35 +0000 (UTC), Michael Kraemer wrote: > In article <41ee8a25$0$17600$9b4e6d93@newsread4.arcor-online.net>, Keith > Cayemberg writes: >> >> 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". >> >> RMS helps programmers to be disciplined, and to get their file >> definitions right. >> > > Funny. > In former times some of the VMS bigots in my field joked about > the - in their view - strange concept of record structured files on > IBM's mainframes. "No need for that, just open a file and be happy > bytewise". > Strange that VMS bigots nowadays bash Unix for exactly the opposite. -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 19:30:43 GMT From: "FredK" Subject: Re: RMS (was: vms versus solaris) Message-ID: RMS was part of the original design and came from RSX IIRC. "Tom Linden" wrote in message news:opsku51golzgicya@hyrrokkin... > Just curious, was RMS part of the original VMS design or did come about > in order to support PL/I and Cobol? > > On Wed, 19 Jan 2005 17:13:35 +0000 (UTC), Michael Kraemer > wrote: > > > In article <41ee8a25$0$17600$9b4e6d93@newsread4.arcor-online.net>, Keith > > Cayemberg writes: > >> > >> 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". > >> > >> RMS helps programmers to be disciplined, and to get their file > >> definitions right. > >> > > > > Funny. > > In former times some of the VMS bigots in my field joked about > > the - in their view - strange concept of record structured files on > > IBM's mainframes. "No need for that, just open a file and be happy > > bytewise". > > Strange that VMS bigots nowadays bash Unix for exactly the opposite. > > > > -- > 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) Message-ID: <2SS0j56EeOx5@eisner.encompasserve.org> In article , "Tom Linden" writes: > Just curious, was RMS part of the original VMS design or did come about > in order to support PL/I and Cobol? RMS was always part of the _design_, although VMS V1.5 did not have indexed files (they were furiously working on them). Some details, like reverse-order indexes, were added along the way. ------------------------------ Date: Thu, 20 Jan 2005 01:10:27 GMT From: reb Subject: satellite clusters Message-ID: From the VMS info linked to from yesterday's Webcast: "Drive continuous operations for your local, national, and international operations with full cluster functionality at distances up to 800 Km and up to 90,000 Km for disaster recovery" Looks like someone has been doing cluster comms bouncing off a satellite or two. Does the 'same time zone' requirement still apply ? reb ------------------------------ Date: Thu, 20 Jan 2005 00:09:31 -0500 From: Dave Froble Subject: Re: satellite clusters Message-ID: <41EF3D0B.50801@tsoft-inc.com> reb wrote: > > From the VMS info linked to from yesterday's Webcast: > > "Drive continuous operations for your local, national, and international > operations with full cluster functionality at distances up to 800 Km and > up to 90,000 Km for disaster recovery" > > Looks like someone has been doing cluster comms bouncing off a satellite > or two. Does the 'same time zone' requirement still apply ? > > > reb That's too far out for a geo-sync orbit, which is what I'd choose if I was going off-planet for disaster tollerance. :-) ------------------------------ Date: 19 Jan 2005 17:14:14 -0800 From: "Elie" Subject: VMS Filename/type length Message-ID: <1106183654.838144.164390@c13g2000cwb.googlegroups.com> Hi, Just want a clarification on VMS filename length. It's documented somewhere that VMS supports up to 255 characters long. Does that include device/directory? Because I am only able to create up to 39 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" Subject: Re: VMS Filename/type length Message-ID: <1106197441.602747.167050@z14g2000cwz.googlegroups.com> Elie wrote: > Hi, > > Just want a clarification on VMS filename length. It's documented > somewhere that VMS supports up to 255 characters long. Does that > include device/directory? Because I am only able to create up to 39 > characters of filename and 39 characters of filetype > (filename.filetype). I am using VMS v7.3-1 > > Any ideas? > > Thanks > --Elie On ODS-2 volumes -- which must be what you are using -- the name and type are each limited to a maximum of 39 characters. If you require more than that you will have to make an ODS-5 volume. VMS documentation is online at the www.hp.com Web site. There is also the 255-char limit for the length of any file-spec string for files that reside on ODS-2 volumes. You might want to start with the User's Manual for general info about VMS. This includes info about file specifications, but curiously doesn't mention the 255-char limit -- 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 which does mention the 255-char limit and also gives info about limits on ODS-5 file specifications. ------------------------------ Date: Wed, 19 Jan 2005 11:01:00 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 18:01:59 GMT, FredK wrote: > > "Tom Linden" wrote in message > news:opskuy70bkzgicya@hyrrokkin... >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg >> >> Actually, you could make all the same arguments as a case for using PL/I >> instead of C. > > I can make arguments for buying a caddy rather than a bimmer, but the > caddy > still remains an old fart car. Your metaphor is faulty, PL/I is the bimmer, C is a chevy nova (probably with liberal applications of duct tape:-) ). > > Kind-of like PL/I. Or VMS itself. Not a lot of appeal to anyone who > wants > to > appear young or cool. Now the interview with Mark leads oner to believe the GNV is going to make it possible to migrate Unix apps with no effort. So maybe VMS will also not be viewed as the old fart car. I have always had a disdain for ignorant fashion anyway. > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 11:02:32 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 18:01:24 +0100, Keith Cayemberg wrote: > Tom Linden wrote: > >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg >> wrote: >> >>> Bill Todd wrote: >>> >>>> Dave Weatherall wrote: >>>> .... >>>> As a >>>> >>>>> record-oriented user/programmer, it _is_ a decisive plus but then, >>>>> perhaps, I fall into the 'locked in' category (mentally or >>>>> philosophically). >>>> >>>> The point is that as a record-oriented user/programmer, you'd also >>>> have access to the kinds of packages I mentioned on Unix (or - blech >>>> - even to some extent on Windows) - in fact, to a considerably >>>> larger collection of options in this area than is available to you >>>> on VMS, many of them free or very low cost but still very functional >>>> and stable and quite a few of them also somewhat more technically >>>> current than RMS is (e.g., in their integral use of journaling to >>>> improve both performance and reliability). >>>> The fact that RMS is bundled and supported as part of the OS may be >>>> convenient and reassuring, but is hardly of *major* significance to >>>> most users (or applications, though not having a third-party >>>> dependency in this area is part of the convenience). >>>> - bill >>> >>> >>> It appears to me that everyone here fails to understand the >>> philosophy behind having an universal record handling service >>> integrated into the operating system. >>> >>> It's primary purpose within the context of professional programming >>> is not to make record handling "easier" or more "convenient" for the >>> programmer. >>> >>> It's primary purpose is to improve the quality and correctness of >>> record storage and transfer. >>> >>> This principle is similar to that which behind the use of Descriptors >>> and a defined Call Standard in OpenVMS, which are also excellent >>> unique quality features of the OpenVMS OS Architecture. >>> >>> By making this service "default" or for some purposes even >>> "mandatory" for the operating system, programmers are encouraged to >>> forego their artistic-license to make many common record-handling >>> errors, and provide a clear definition of the record structure of a >>> file. When another program tries to use the record service to read >>> the records in an erroneous format, this is quickly identified as an >>> error, before passing the incorrectly interpreted information to the >>> next application. >>> >>> 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". >>> >>> RMS helps programmers to be disciplined, and to get their file >>> definitions right. >> Actually, you could make all the same arguments as a case for using >> PL/I >> instead of C. > > Ah yes, another RMS design advantage I forgot to mention. The service > design is, as with most VMS integrated services, language neutral That > is what I consider responsible artistic freedom for the programmer. In > fact, it is quite desirable to integrate RMS into the native compilers. > I suppose your PL/I for OpenVMS already does this? Fully, and transparently, record i/o is part of the language semantics. Naturally C > programmers have a little more work to do here, which is probably helps > explain why I get the most complaints about RMS from C programmers. > >> >>> >>> Please note, that RMS also manages the access of files with the >>> stream-lf format. This protects, for instance, a program correctly >>> programmed for accessing a stream-lf file from accessing an >>> Indexed-Sequential file, or even an executable file erroneously. RMS >>> thus reduces the likelihood not only of programmer error, but user >>> error as well. >>> >>> I have over the years experienced countless cases where RMS has saved >>> our customers a lot of trouble. I am especially referring to a >>> complex CIM and Production Planning environment in which a diagram of >>> the interfaces between the processes controlling the various factory >>> processes looks like a 3D spider web. Information produced by one >>> process is often transferred to many other processes in that >>> processing web using some form of file transfer. Having an >>> undiscovered error in an interface would quickly propagate deeply >>> into many other systems. It would be a potentially create an >>> unrecoverable mess! This CIM environment also sends and receives >>> information from external systems, often programmed by external >>> companies or consultants using their own methods. By having a RMS >>> described file as a transfer medium, we have often caught these >>> external agencies that have quietly (perhaps unintentially through >>> their own programming errors) changed the format of these files, >>> before accepting their information in our complex CIM environment. >>> For us, this seems to happen regularly when information is >>> transferred from SAP systems which have had some sort of upgrade. The >>> SAP folks appear to be so isolated from the file details that they >>> don't always know the exact format of a file that will be produced >>> after a change. They could certainly use a service that implements >>> the principles found in RMS! >>> >>> Although, I agree that there are customers and applications with >>> design goals that would make the Unix minimalism desirable, I >>> respectfully disagree that this philosophy should be a goal within an >>> Enterprise or Mission-Critical oriented OS. The presence of such >>> universal (at least within the chosen OS) quality-oriented services >>> is clearly a desirable quality enhancement within the professional >>> Enterprise OS and Mission-Critical problem space. >>> >>> Cheers! >>> >>> Keith Cayemberg >> -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 11:24:10 -0800 From: "Tom Linden" Subject: Re: vms versus solaris Message-ID: On Wed, 19 Jan 2005 19:36:16 GMT, FredK wrote: > > "Tom Linden" wrote in message > news:opsku5rylkzgicya@hyrrokkin... >> On Wed, 19 Jan 2005 18:01:59 GMT, FredK > wrote: >> >> > >> > "Tom Linden" wrote in message >> > news:opskuy70bkzgicya@hyrrokkin... >> >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg >> >> >> >> Actually, you could make all the same arguments as a case for using > PL/I >> >> instead of C. >> > >> > I can make arguments for buying a caddy rather than a bimmer, but the >> > caddy >> > still remains an old fart car. >> >> Your metaphor is faulty, PL/I is the bimmer, C is a chevy nova (probably >> with >> liberal applications of duct tape:-) ). > > Spoken like the owner of an Oldsmobile defending why it's so great ;-) True, but no need for duct tape. Now, Fred, just to make you feel better, I am taking the next two days off, golfing at Spyglass tomorrow Monterey Peninsula CC on Fri, Spanish Bay on Sat and Pebble Beach on Sunday and the temp is upper 60s and not a cloud in the sky. I don't think I miss Boston too much. > >> > >> > Kind-of like PL/I. Or VMS itself. Not a lot of appeal to anyone who >> > wants >> > to >> > appear young or cool. >> Now the interview with Mark leads oner to believe the GNV is going to >> make >> it possible to migrate Unix apps with no effort. So maybe VMS will also >> not >> be viewed as the old fart car. I have always had a disdain for ignorant >> fashion >> anyway. >> > > Uh. Yeah. Right. > > GNV is a useful thing. I have a 3rd party that ported their code to VMS, > and > since they are all UNIX heads, I put GNV on the system so that they could > 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. > > The C RTL has a *lot* more UNIX stuff in it, as does some of the file > system (soft links, naming, etc). But it still *isn't* UNIX. There are > still > areas like fork(), select() and shared stream files that are problematic. > Some will be fixed sooner, and some will take more time. > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ ------------------------------ Date: Wed, 19 Jan 2005 14:27:24 -0500 From: JF Mezei Subject: Re: vms versus solaris Message-ID: <1106162210.62d7ecc2d06dbd7f1aaa4d87e05d4359@teranews> Neil Rieck wrote: > Your statement is true. But I think you'd agree that the current "open > source movement" is dominated by "C". While for VMS, I would tend to agree, is that truly the case ? Wouldn't C++ be very common for modern open sourced projects ? 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 of modern/current stuff is in C++. For instance, the Macromedia flash player open source is in C++. Software written for Symbian phones is either C++ or Java. What is open office written in ? ------------------------------ Date: Wed, 19 Jan 2005 19:36:16 GMT From: "FredK" Subject: Re: vms versus solaris Message-ID: "Tom Linden" wrote in message news:opsku5rylkzgicya@hyrrokkin... > On Wed, 19 Jan 2005 18:01:59 GMT, FredK wrote: > > > > > "Tom Linden" wrote in message > > news:opskuy70bkzgicya@hyrrokkin... > >> On Wed, 19 Jan 2005 17:26:13 +0100, Keith Cayemberg > >> > >> Actually, you could make all the same arguments as a case for using PL/I > >> instead of C. > > > > I can make arguments for buying a caddy rather than a bimmer, but the > > caddy > > still remains an old fart car. > > Your metaphor is faulty, PL/I is the bimmer, C is a chevy nova (probably > with > liberal applications of duct tape:-) ). Spoken like the owner of an Oldsmobile defending why it's so great ;-) > > > > Kind-of like PL/I. Or VMS itself. Not a lot of appeal to anyone who > > wants > > to > > appear young or cool. > Now the interview with Mark leads oner to believe the GNV is going to make > it possible to migrate Unix apps with no effort. So maybe VMS will also > not > be viewed as the old fart car. I have always had a disdain for ignorant > fashion > anyway. > Uh. Yeah. Right. GNV is a useful thing. I have a 3rd party that ported their code to VMS, and since they are all UNIX heads, I put GNV on the system so that they could 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. The C RTL has a *lot* more UNIX stuff in it, as does some of the file system (soft links, naming, etc). But it still *isn't* UNIX. There are still areas like fork(), select() and shared stream files that are problematic. Some will be fixed sooner, and some will take more time. ------------------------------ Date: Wed, 19 Jan 2005 14:45:00 -0500 From: JF Mezei Subject: Re: vms versus solaris Message-ID: <41EEB8BA.F5A15683@teksavvy.com> Tom Linden wrote: > The ISAM packaged developed to support PL/I under Ultrix was spun off as a > separately licensable package, but I don't think it ever sold very much > outside of PL/I usage. You have to realise that on Unix and Windows, the lack of RMS simply forced people to buy a database package. Had RMS been made available to 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. And you have to look back to the 1980s, when the big competitor was VMS with its built-in VSAM files. Now, the competition is Windows and Unix which do not have ISAM. Note that my trusty 1990s Psion Series 3 PDA with 2 meg of RAM has ISAM and the equivalent of DECnet on it. And like Digital, PSION no longer exists (except on paper, it is now a holding). ------------------------------ Date: Wed, 19 Jan 2005 14:51:50 -0500 From: JF Mezei Subject: Re: vms versus solaris Message-ID: <41EEBA53.1F827FF9@teksavvy.com> Keith Cayemberg wrote: > It's primary purpose within the context of professional programming is > not to make record handling "easier" or more "convenient" for the > programmer. I would also add "more secure" to the list. Consider how many OS required long volume/file rebuilds after a power failure because disks become corrupt when files are improperly closed. RMS does a very good job of this, especially when it comes to indexed files where file integrity is very good. Having RMS as a layered product just couldn't offer the same level of robustness, especially when it comes to multiple proicesses accessing the same file at the same time. It provides primitives such as automatic record locking, etc. ------------------------------ Date: Wed, 19 Jan 2005 15:03:01 -0500 From: JF Mezei 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 about > the - in their view - strange concept of record structured files on > IBM's mainframes. "No need for that, just open a file and be happy bytewise". > Strange that VMS bigots nowadays bash Unix for exactly the opposite. On MVS, the default for "text" files was fixed length records of 80 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. VMS, the default is variable lengh files, so when you edit, you don't have a artificial limit on how long a line can be (within reason, of course). So if you need to have a statement fit on one line, it is not a problem. Note that WML (the reduced HTML for handsets) requires tags to be on one line. Note that MVS did support variable length records. I had to teach some 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) application, and they were so surprised that a VAX guy could teach them something on their IBM turf. They were used to reading fixed lenght records. COBOL handles both fixed and variable length quite well, but they just had never used variable length ones. The same can be said of VMS. It is quite easy to teach someone about 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 -0800 From: Ken Fairfield Subject: Re: vms versus solaris Message-ID: Lots of good replies here. :-) I'd like to add a somewhat different emphasis to what Bob already wrote: Bob Koehler wrote: [...] > I have a fellow who refers to them as "logical symbols". I tell new ^^^^^^^^^^^^^^^ A very common mis-terminolgy, that! > users these are the most important: > > 1 they are both memory resident strings which stand for other strings > 2 symbols are per-process, but usually inherited by spawned processes > 3 symbols are global to all procs in a process or local to one proc > 4 logicals are per-process, job-wide, group-wide, system-wide, or > cluster-wide > 5 logicals are global to all procs > 6 DCL will use symbols like UNIX aliases, but not logicals > 7 the file system will automatically use logicals, but not symbols > > I don't bother new users with inner vs. outer mode, concealed, and > all those other attributes logicals can have. A. Symbols only exist under DCL, are confined to a process (tree) and disappear when the (master) process exits. B. Symbols are translated automatically by DCL. C. Logical names (created in tables other than the Process or Job tables) are non-volatile and remain defined until explicitly removed (or the system shuts down). D. Logical names in other than the Process table are accessible system-wide and changes made to them appear immediately to all processes which have access to them. E. Logical names are translated automatically by the file system, but their use is not confined to the file system. -Ken -- I don't speak for Intel, Intel doesn't speak for me... Ken Fairfield D1C Automation VMS System Support who: kenneth dot h dot fairfield where: intel dot com ------------------------------ Date: 19 Jan 2005 14:02:32 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: vms versus solaris Message-ID: <8s9COfca+LTP@eisner.encompasserve.org> In article , m.kraemer@gsi.de (Michael Kraemer) writes: > In former times some of the VMS bigots in my field joked about > the - in their view - strange concept of record structured files on > IBM's mainframes. "No need for that, just open a file and be happy bytewise". VMS has always had record structured files, so I don't know why they would complain. Or perhaps VMS languages are better at opening a record structured file and adapting to whatever record structure is found in the file definition, rather than having been coded in advance for a particular record size. Does VSAM on MVS provide carefree "variable length" records ? ------------------------------ Date: Wed, 19 Jan 2005 15:33:11 -0500 From: Bill Todd Subject: Re: vms versus solaris Message-ID: Keith Cayemberg wrote: > Bill Todd wrote: > >> Dave Weatherall wrote: >> >> .... >> >> As a >> >>> record-oriented user/programmer, it _is_ a decisive plus but then, >>> perhaps, I fall into the 'locked in' category (mentally or >>> philosophically). >> >> >> >> The point is that as a record-oriented user/programmer, you'd also >> have access to the kinds of packages I mentioned on Unix (or - blech - >> even to some extent on Windows) - in fact, to a considerably larger >> collection of options in this area than is available to you on VMS, >> many of them free or very low cost but still very functional and >> stable and quite a few of them also somewhat more technically current >> than RMS is (e.g., in their integral use of journaling to improve both >> performance and reliability). >> >> The fact that RMS is bundled and supported as part of the OS may be >> convenient and reassuring, but is hardly of *major* significance to >> most users (or applications, though not having a third-party >> dependency in this area is part of the convenience). >> >> - bill > > > It appears to me that everyone here fails to understand the philosophy > behind having an universal record handling service integrated into the > operating system. Not really. Some of us just recognize that it's manifestly not as important to the rest of the world as it appears to be to you. - bill ------------------------------ Date: Wed, 19 Jan 2005 21:57:50 +0100 From: Keith Cayemberg Subject: Re: vms versus solaris Message-ID: <41eec9ce$0$17618$9b4e6d93@newsread4.arcor-online.net> Bill Todd wrote: > Keith Cayemberg wrote: > >> Bill Todd wrote: >> >>> Dave Weatherall wrote: >>> >>> .... >>> >>> As a >>> >>>> record-oriented user/programmer, it _is_ a decisive plus but then, >>>> perhaps, I fall into the 'locked in' category (mentally or >>>> philosophically). >>> >>> >>> >>> >>> The point is that as a record-oriented user/programmer, you'd also >>> have access to the kinds of packages I mentioned on Unix (or - blech >>> - even to some extent on Windows) - in fact, to a considerably larger >>> collection of options in this area than is available to you on VMS, >>> many of them free or very low cost but still very functional and >>> stable and quite a few of them also somewhat more technically current >>> than RMS is (e.g., in their integral use of journaling to improve >>> both performance and reliability). >>> >>> The fact that RMS is bundled and supported as part of the OS may be >>> convenient and reassuring, but is hardly of *major* significance to >>> most users (or applications, though not having a third-party >>> dependency in this area is part of the convenience). >>> >>> - bill >> >> >> >> It appears to me that everyone here fails to understand the philosophy >> behind having an universal record handling service integrated into the >> operating system. > > > Not really. Some of us just recognize that it's manifestly not as > important to the rest of the world as it appears to be to you. > > - bill Well, the thread did run a long ways without anyone discussing quality. Should I then accept that the world isn't interested in quality mechanisms anymore then? I suppose with the horrid, and worsening quality of software development in the world I suppose I'll have to accept most are not interested. Get the contract, don't think about the design, program it PDQ, get paid, get paid more to fix it later. That does seem to be the sorry state of affairs in most of the IT industry. 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. I've carefully explained my reasoning, the world can take it, leave it, or explain to me why I'm wrong. Cheers! Keith Cayemberg P.S. I didn't intend to sound overly personal or global in saying "It appears to me that everyone here fails to understand". I know how most here appreciate VMS for it's quality. But I still suspect, from the 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 -0500 From: "Neil Rieck" Subject: Re: vms versus solaris Message-ID: "John Laird" wrote in message news:ej2tu0d1caqniah90aa3moqcv1c5puv8ge@4ax.com... > On Wed, 19 Jan 2005 06:25:24 -0800, "Tom Linden" wrote: > >>On Tue, 18 Jan 2005 23:16:19 -0500, JF Mezei >> wrote: >> >>> Is it correct to state that RUN/DETACHED image.exe will not give >>> image.exe access to any symbols for reading and writing ? >> >>What about lib$[s,g]et_symbol? > > They will return LIB-F-NOCLI. > You are 100% correct. But when I need to create a server process with an attached CLI, I run "SYS$SYSTEM:LOGINOUT.EXE" and pass it a "RUN image.exe" command through SYS$INPUT. Works like a charm. Neil Rieck Kitchener/Waterloo/Cambridge, Ontario, Canada. http://www3.sympatico.ca/n.rieck/links/cool_openvms.html ------------------------------ Date: Wed, 19 Jan 2005 17:44:15 -0500 From: "John Smith" Subject: Re: vms versus solaris Message-ID: Keith Cayemberg wrote: > JF Mezei wrote: > >> Tom Linden wrote: >> >>> The ISAM packaged developed to support PL/I under Ultrix was spun >>> off as a separately licensable package, but I don't think it ever >>> sold very much outside of PL/I usage. >> >> >> You have to realise that on Unix and Windows, the lack of RMS simply >> forced people to buy a database package. Had RMS been made available >> to 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. >> > Good, but what does the database package do for all those readily > available file creating and transfer capabilities on these platforms? > It's still too easy to go around these packages when transferring or > storing information, or corrupting someone else's files > unintentionally. Getting around RMS on VMS is not the default and it > it's not particularly easy or easier either, and even then the file > must generally have RMS recognizable attributes set to exist in an ODS > directory. Its eventually only easier to lie about the attributes with > $QIO and $QIOW. > > Enforcing the use of a DB package for all potential sources of record > error is easier said than done in large organisation with complex > systems and many contracted projects over multiple generations of > programmers. And as already hinted elsewhere, perhaps your life-saving > mission-critical program is only one part of a customer environment > where you don't have any control over their IT policies, other than > what platform your program runs on. Your application is going to be > very dependent on the quality of the chosen platform, and the > decisions that were made in it's design, such as the existence of a > default RMS-like service to guard whatever files your application > works with, including the DB file and the program file itself. > > Cheers! > > Keith Cayemberg Back when I used to trade bonds and do esoteric structured finance for a liv ing, I had a big sign stuck on my 160-line phone for all who passed by my desk could see that read "Data IS Money". If you can't trust your data then your application programs don't matter one iota. And trusting your data means knowing that it is properly and safely stored, accessed, and not munged. RMS and the common language calling standard on VMS meant we could use Apl, Cobol, and Fortran as the need arose within one app and still be sure that we had good data - of course we were careful too. ------------------------------ Date: Wed, 19 Jan 2005 18:13:19 -0500 From: Bill Todd Subject: Re: vms versus solaris Message-ID: Keith Cayemberg wrote: ... > Well, the thread did run a long ways without anyone discussing quality. > Should I then accept that the world isn't interested in quality > mechanisms anymore then? No, you should just learn that quality isn't a black-or-white issue which RMS provides and other platforms do not - any more than suggesting that anyone who doesn't program in Ada doesn't care about quality (I 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). - bill ------------------------------ Date: Thu, 20 Jan 2005 04:33:27 +0800 From: prep@prep.synonet.com Subject: Re: vms versus solaris Message-ID: <87oeflyx9k.fsf@prep.synonet.com> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > People running the systems have a very heavy impact. But we have > a group of people heavily trained in Solaris who can't keep the > things up. Meanwhile the VMS systems they admin just keep on > keeping on. "We really should learn more about the Vax, but it just keeps working." That is an exact quote from the head operator at a PPOE. Or as exact as memory allows over 15 years. Gulp... 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 a gravitational collapse disaster. And one 6xxx with HSC RA8x disks. -- Paul Repacholi 1 Crescent Rd., +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. EPIC, The Architecture of the future, always has been, always will be. ------------------------------ Date: Thu, 20 Jan 2005 04:40:48 +0800 From: prep@prep.synonet.com Subject: Re: vms versus solaris Message-ID: <87k6q9ywxb.fsf@prep.synonet.com> "Eitan" writes: > Is there any resamblance between vms and solaris os. They both run on things called a "computer" and are sold by thinks that if their lips move, are lying. > If so, then what are the main things that are simmiliar and what are > not (in brief) ? 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. -- Paul Repacholi 1 Crescent Rd., +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. EPIC, The Architecture of the future, always has been, always will be. ------------------------------ Date: Thu, 20 Jan 2005 04:44:06 +0800 From: prep@prep.synonet.com Subject: Re: vms versus solaris Message-ID: <87fz0xywrt.fsf@prep.synonet.com> "Neil Rieck" writes: > As some people have already mentioned to me by email, modern flavors > of UNIX do implement quota-based resource management. (most of my > UNIX experience came from BSD 4.4 on PDP-11/44 back in the mid > 1980's and lots of stuff has changed since then). It would be nice > if someone in this newsgroup with experience on both UNIX and > OpenVMS would set the record straight. If it was 4.4, it was probably a Vax. For any 11, you would be running BSD 2.x. -- Paul Repacholi 1 Crescent Rd., +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. EPIC, The Architecture of the future, always has been, always will be. ------------------------------ Date: Thu, 20 Jan 2005 04:56:38 +0800 From: prep@prep.synonet.com Subject: Re: vms versus solaris Message-ID: <87brblyw6x.fsf@prep.synonet.com> m.kraemer@gsi.de (Michael Kraemer) writes: > Relegate that to some library once and for all. If you allow `put it in a library' to define a high level language, then the front panel switches comply with that `definition'! -- Paul Repacholi 1 Crescent Rd., +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. EPIC, The Architecture of the future, always has been, always will be. ------------------------------ Date: Thu, 20 Jan 2005 05:04:33 +0800 From: prep@prep.synonet.com Subject: Re: vms versus solaris Message-ID: <877jm9yvtq.fsf@prep.synonet.com> bill@cs.uofs.edu (Bill Gunshannon) writes: > A stream of bytes seems to meet the needs of the Unix userbase just > fine. Anything beyond that can be layered on top of the existing > minimalist "stream of bytes". Not sure about what you mean by CLI > Architecture. Care to explain. (I looked the term up with Google > and none of the explanations I saw would seem to apply to VMS any > more than Unix.) Case example. User has a unix system and two apps he wants to run. Both are rather large and use `db' type packages, *different* packages, so they can't run together one the one sett of files. And neither vendor was interested in changing, or allowing it. -- Paul Repacholi 1 Crescent Rd., +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. 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> bill@cs.uofs.edu (Bill Gunshannon) writes: > 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 the > 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. Not quite. unix gives you type=undefined, no lock, and NOTHING else. Anything and everything above that has to be brought to the table, and if you want your apps to work with the same data, thay had better use the same access packages, or at least the same data formats. -- Paul Repacholi 1 Crescent Rd., +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. 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 solaris Message-ID: <358ajvF4jjdvmU1@individual.net> In article <877jm9yvtq.fsf@prep.synonet.com>, prep@prep.synonet.com writes: > bill@cs.uofs.edu (Bill Gunshannon) writes: > >> A stream of bytes seems to meet the needs of the Unix userbase just >> fine. Anything beyond that can be layered on top of the existing >> minimalist "stream of bytes". Not sure about what you mean by CLI >> Architecture. Care to explain. (I looked the term up with Google >> and none of the explanations I saw would seem to apply to VMS any >> more than Unix.) > > Case example. User has a unix system and two apps he wants to run. > Both are rather large and use `db' type packages, *different* > packages, so they can't run together one the one sett of files. And > neither vendor was interested in changing, or allowing it. One can always come up with contrived examples to prove any point no matter how silly. Let's see, customer has VMS, wants to run SAP. Oops. Vendor is not interested in running on VMS. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Wed, 19 Jan 2005 19:32:45 -0500 From: Dave Froble Subject: Re: Webcast and VMS Message-ID: <41EEFC2D.6040700@tsoft-inc.com> John Smith wrote: > Dave wrote: > >>You asked for suggestions for improving the perception of VMS in the >>marketplace. At least I think that's what you asked. >> >>I think you've already said what's required. A quote from the Q&A: >> >>"OpenVMS is one of the most powerful operating environments in the >>industry." >> >>All you need to do is continue to say this publically. Often. In >>advertisements. Every salesman should make this statement to a >>customer, at least once, regardless of what the customer is looking >>at. >> >>If a customer had to choose between a perceived "industry standard" >>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. >> >>It's my perception that HP makes more on a VMS sale than most other >> HP products. Most VMS customers buy lots of support. Good support, >>forget about India. >> > > > > Well put. try sending this to Ann (and Marcello) using the usual > fname.lname@CUTTHIShp.com, perhaps with 'OpenVMS' as the subject line to > escape spam filters. Also request a Read Reply receipt. Actually, the post to c.o.v was the second reciepient. Ann dot livermore at hp dot com was the first. I got a rather quick, if short, reply. She passed the info to Mark and Rich. I have to wonder about the quick response. Do executives have nothing better to do than read e-mail? Was there a staff handling her e-mail? Don't know. Still, because I have the scorch marks, it reminded me of another such message in the 1999-2000 time frame, hand delivered to Curly, who promptly handed it to Rich. How do you spell choir, cause it feels like that's all I'm preaching to. If Mark and Rich do have the capability of advertising VMS, and getting every HP salesperson to mention, just as an extra bit of data, the quote from above, then we have some serious ass to kick and now know who. Alas, I don't feel they have that authority. Dave ------------------------------ End of INFO-VAX 2005.039 ************************