INFO-VAX Mon, 01 Oct 2007 Volume 2007 : Issue 536 Contents: Re: Article of Interest. Re: Article of Interest. Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems RE: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Re: lexical for terminal attributes? Re: lexical for terminal attributes? Re: lexical for terminal attributes? Re: Time to PAK it in? ---------------------------------------------------------------------- Date: Mon, 01 Oct 2007 06:46:05 GMT From: "John Wallace" Subject: Re: Article of Interest. Message-ID: "Ron Johnson" wrote in message news:%lWLi.3247$pX5.1984@newsfe14.lga... > On 09/30/07 18:19, Dr. Dweeb wrote: > [snip] > > > > Thank the DoJ and the monopolies case for that. MS has gotten (oops, > > american english there) better, but only slightly. The bottom line is that > > whatever MS wants to force down the user's throats, then that is what they > > can buy. > > > > It appears that massive pressure from the OEMs has moved MS a bit, for a > > while, but a steamroller will not be denied, and eventually Vista will crush > > everyone. Vista is about DRM and there are big vested interests involved > > and it's where MS sees the future big bucks involved - Vista is a > > pre-requisite for the MS game plan - it ain't ever going away (sadly) > > because XP does not have the DRM hooks that are necessary for MS and the > > RIAA etc to be in bed together. > > While I agree with your general intent, and definitely that MSFT, > the RIAA and MPAA want DRM, the problem is that no one knows how it > implement it properly without creating onerous and backlash-creating > "issues" for consumers (who are, in the end, their final source of > income). > > And the backlash is upon them. Most of the music download services > are dropping DRM, and I bet that the video services will do the same. > > -- > Ron Johnson, Jr. > Jefferson LA USA > > Give a man a fish, and he eats for a day. > Hit him with a fish, and he goes away for good! Consumers are the folks who ultimately pay for most things, but in the case of MS the relationship with the retail consumer is (imo) far less important than the relationship with the volume PC builders and the wider IT world. MS don't really need to care much about consumers, direct consumer spend with MS isn't traditionally big enough to affect the bottom line by much. But MS may have to give the appearance that consumers matter, and as we have recently seen, if the people that *do* matter to MS start pushing because of consumer feedback, *then* (and only then?) MS will react. The anti-Vista push from a few volume PC builders is quite remarkable, but is it significant? Real "consumers" still have no choice of OS when they buy a PC (and that's the main time that consumers "buy" an OS). Whatever conclusions the US DoJ and the EU may have reached, and whatever actions they may have imposed, they haven't been effective, MS are still exploiting their OS monopoly to make sure that Windows is what the punter pays for when they buy a new PC (unless the PC is a Mac). Real consumers *can* choose OpenOffice if they wish, and indeed would probably be mad not to, but the business world until recently was clearly focused on MS Office. Office gives (gave?) MS a nice guaranteed revenue stream as IT departments OS upgrade cycles mean they are also locked-in to upgrading the Office stuff every couple of years too. DRM is largely irrelevant to the big spenders in the IT department. "Trusted computing" *could* have been interesting to the IT department, if it hadn't been translated to mean not much more than the RIAA/MPAA could trust MSFT. Whether the limited Vista-related backlash is a sign of things to come, and whether it also gives OpenOffice an opportunity in the IT world, remains to be seen. 2p John ------------------------------ Date: Mon, 01 Oct 2007 15:52:18 +0200 From: "P. Sture" Subject: Re: Article of Interest. Message-ID: In article <%lWLi.3247$pX5.1984@newsfe14.lga>, Ron Johnson wrote: > On 09/30/07 18:19, Dr. Dweeb wrote: > [snip] > > > > Thank the DoJ and the monopolies case for that. MS has gotten (oops, > > american english there) better, but only slightly. The bottom line is that > > whatever MS wants to force down the user's throats, then that is what they > > can buy. > > > > It appears that massive pressure from the OEMs has moved MS a bit, for a > > while, but a steamroller will not be denied, and eventually Vista will > > crush > > everyone. Vista is about DRM and there are big vested interests involved > > and it's where MS sees the future big bucks involved - Vista is a > > pre-requisite for the MS game plan - it ain't ever going away (sadly) > > because XP does not have the DRM hooks that are necessary for MS and the > > RIAA etc to be in bed together. > > While I agree with your general intent, and definitely that MSFT, > the RIAA and MPAA want DRM, the problem is that no one knows how it > implement it properly without creating onerous and backlash-creating > "issues" for consumers (who are, in the end, their final source of > income). I'll observe that by not providing sound with Itanium systems, HP has neatly avoided this issue for VMS. > And the backlash is upon them. Most of the music download services > are dropping DRM, and I bet that the video services will do the same. -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ Date: Mon, 01 Oct 2007 07:23:36 GMT From: "John Wallace" Subject: Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Message-ID: "mjjerabek" wrote in message news:1191208221.617101.167830@g4g2000hsf.googlegroups.com... > > We want to continue VMS long after Alphas are available from HP, > Island Computer, or ebay. A fine ambition. >IA64 is the answer. Well that's what one part of HP HQ says, although others within HP HQ are perfectly happy with AMD64 and its Intel clones as server platforms, and the next generation of IA64 will even have common socket-level electronics with its x86-derived brothers, which will make brotherly competition even more interesting. Perhaps the people who sign the cheques/checks at your company and its customers might like HP HQ to comment on how affordable IA64 will be in the future vs AMD64 and clones, and what the plans are for avoiding IA64 going down the same death spiral as allegedly killed Alpha (low volumes and no important "unique selling point" = high development costs and exit from market). Basically this centres on how significant IA64 is to Intel's overall business plans. One benchmark of "significance" to the Intel world is the amount of coverage a chip family gets at Intel Developer Forum. An IDF has recently been held, so there may be a recent answer. (I think I know what the answer is, but it's better that you hear it from HP). Meanwhile, briefly back to Java performance investigations... I don't see the word "alignment" mentioned explicitly in this thread so far. I do hear alignment issues mentioned reasonably frequently as cause for major performance concern on IA64, more concern even than on Alpha, so if you aren't already planning to do so, you may want to plan to have a look at that as a possible factor in your picture. How you'd address that if it is the problem is a different matter, but that's something for later. Best of luck, John ------------------------------ Date: Mon, 01 Oct 2007 04:15:48 -0400 From: JF Mezei Subject: Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Message-ID: <52f5d$4700acba$cef8887a$20362@TEKSAVVY.COM> John Wallace wrote: > overall business plans. One benchmark of "significance" to the Intel world > is the amount of coverage a chip family gets at Intel Developer Forum. An > IDF has recently been held, so there may be a recent answer. CNET reported on the keynote speech from Intel being devoid of any mention of IA64. It isn't a question of "IF", it is a question of "WHEN". Back in 2004 when Carly and iNtel started to send out strong signals, it looked like IA64's demise would happen in 2007. But since CSI is late, so is the demise of IA64. Intel will not make the same mistake HP/Compaq did by killing Alpha before its replacement was ready. Intel will wait for the 8086 to be cleraly equal/superior to IA64 before formally announcing it. And there may be a year or two before this happens. In the end, this will probably spell the end of VMS, at which point it won't matter if software X runs on IA64 or not since thevast majority of the remaining VMS installed base will still be on VAX and Alpha. ------------------------------ Date: Mon, 1 Oct 2007 16:43:07 +0000 From: "Main, Kerry" Subject: RE: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems Message-ID: > -----Original Message----- > From: John Wallace [mailto:johnwallace4@yahoo.spam.co.uk] > Sent: October 1, 2007 3:24 AM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Guidance with OpenVMS IA64 8.3 with Java 1.5 Problems > [snip..] > > Meanwhile, briefly back to Java performance investigations... I don't > see > the word "alignment" mentioned explicitly in this thread so far. I do > hear > alignment issues mentioned reasonably frequently as cause for major > performance concern on IA64, more concern even than on Alpha, so if you > aren't already planning to do so, you may want to plan to have a look > at > that as a possible factor in your picture. How you'd address that if it > is > the problem is a different matter, but that's something for later. > > Best of luck, > John John's note on alignment is a good point. Alignment of data is something th= at can impact any platform migration. Here are a few additional links that may be of some= assistance: Guy Peleg (now at Bruden) presentation on Alpha to IA64 porting/performance considerations- (excellent presentation) http://www.hp-interex.be/wiki/images/4/48/Porting_real_applications.ppt Note that Bruden also does performance analysis of applications and may be = able to assist with this initial analysis. http://www.brudenossg.com/ Other Tech Journals: http://h71000.www7.hp.com/openvms/journal/index.html (see Java and OpenVMS = article) http://h71000.www7.hp.com/openvms/journal/v9/index.html#faults (alignment f= aults) Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT) OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 1 Oct 2007 07:49:46 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: lexical for terminal attributes? Message-ID: In article <1191031786.524350.276810@g4g2000hsf.googlegroups.com>, AEF writes: > > When is it not? Sometimes the terminal may different from the SET > TERMINAL width, but the defbufsiz always gives the latter, no? > I have seen the defbufsiz vary from the actual width, which matched the width reported by "show terminal". I don't know under what circumstances this occurs, I just remember seeing it and realizing I could not rely on defbufsiz in sylogin. ------------------------------ Date: 1 Oct 2007 07:52:08 -0500 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: lexical for terminal attributes? Message-ID: In article <46FEC06D.BB9DAE3A@spam.comcast.net>, David J Dachtera writes: > > In Reflection, I can change the screen width (Reflection's paradigm) without > notifyting VMS (SET TERM/WIDTH). I can do that on a real VT, or on just about any terminal emulator I've used. The issue then becomes how VMS, or an application, treats the terminal. I've seen a terminal emulator (don't recall which one) and all the applications I tried (such as EVE), as well as the "show terminal" output agree to one size while the defbufsiz showed a different value. ------------------------------ Date: Mon, 01 Oct 2007 08:16:55 -0700 From: AEF Subject: Re: lexical for terminal attributes? Message-ID: <1191251815.518433.133240@y42g2000hsy.googlegroups.com> On Oct 1, 8:49 am, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) wrote: > In article <1191031786.524350.276...@g4g2000hsf.googlegroups.com>, AEF writes: > > > > > When is it not? Sometimes the terminal may different from the SET > > TERMINAL width, but the defbufsiz always gives the latter, no? > > I have seen the defbufsiz vary from the actual width, which matched > the width reported by "show terminal". I don't know under what > circumstances this occurs, I just remember seeing it and realizing I > could not rely on defbufsiz in sylogin. I just got them to be different with putty. And DEVBUFSIZ agrees with SHOW DEVICE/FULL TT while SET TERMINAL can be different. I haven't the time to narrow it down but I was SET HOST and changed the font sizes and the screen size to get it to do it. Don't know which one. But after running EVE and confirming that it paid attention to the SHOW DEVICE/FULL number I found that the SHOW TERM result then had changed to agree with the SHOW DEVICE/FULL result. Apparently, whatever SHOW TERMINAL is getting the width from is not always being updated, but I think you can still depend on F$GETDVI("TT","DEVBUFSIZ"), at least based on this quick experiment. (VMS V6.2). Attempting to narrow it down seems to be that SET HOST is needed and the values this time just get corrupt sometime. Don't have the time to track it down further. AEF ------------------------------ Date: Mon, 01 Oct 2007 15:58:02 +0200 From: "P. Sture" Subject: Re: Time to PAK it in? Message-ID: In article , John Santos wrote: > VAXman- @SendSpamHere.ORG wrote: > > In article <3pgLi.8087$Im1.3525@trnddc01>, John Santos > > writes: > >>Holy Cow! I just realized all the DSPP licenses on my Itanium (from the > >>porting > > > > > > http://www.tmesis.com/holycow.html > > > > > > Must be one a them there Swiss cows! LOL > This is what Swiss cows look like at this time of year, on their way down from the mountains to their winter quarters, fancy hats 'n' all :-) http://walking.about.com/od/traileurope/ig/Swiss-Cows/Swiss-Cows-Lauterbr unnen.htm -- Paul Sture Sue's OpenVMS bookmarks: http://eisner.encompasserve.org/~sture/ovms-bookmarks.html ------------------------------ End of INFO-VAX 2007.536 ************************