INFO-VAX Fri, 17 Aug 2007 Volume 2007 : Issue 449 Contents: Re: Free to good home. Microvaxes, Vaxstations, Alphas Fun with bugs Re: Fun with bugs Re: Fun with bugs Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? RE: Intel marginalizing Itanium even faster than expected? Re: Intel marginalizing Itanium even faster than expected? Re: Storageworks SAN Switches: possible to reset password ? To HP: How To Stop Negativity on C.O.V. Re: Which version of SSH? Re: Which version of SSH? Re: Which version of SSH? Re: Wonderful things happen to an OS when it has an internal champion RE: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion Re: Wonderful things happen to an OS when it has an internal champion ---------------------------------------------------------------------- Date: 16 Aug 2007 19:09:23 GMT From: healyzh@aracnet.com Subject: Re: Free to good home. Microvaxes, Vaxstations, Alphas Message-ID: Phillip Helbig---remove CLOTHES to reply wrote: > However, due to their small size and thus small power requirements, they > are also very low cost with respect to power consumption. Build a This is the part that interests me, the size and power consumption. For the job mine is doing it is just fine. Though it is not exactly small with a BA350 hooked up to it. I recently was going to upgrade it to a VS4000/60 or /90, until I realized that I couldn't, as I don't have the room. > cluster of such machines and configure a more powerful node as a > satellite and switch it on only when you need it. They would make a very attractive hobbyist cluster, especially coupled with a BA350 shelf or two, a DECserver capable of Reverse LAT for the console connections, and a single VT420 terminal. Zane ------------------------------ Date: Thu, 16 Aug 2007 17:57:42 -0700 From: DeanW Subject: Fun with bugs Message-ID: <3f119ada0708161757y56906ffdle0643bb040f39a03@mail.gmail.com> Or, differences from Alpha to IA64... Discovered on VMS I64 8.3, Pascal 5.9 This is an obvious gross simplification of the brick wall I've just finished beating my head on, which, having wiped the blood out of my eyes, is plainly visible. (No, it's not my code; yes, I think the guy who did write this owes me dinner & a couple beers.) Hopefully, I've got all this the right way round so it makes what I'm about to explain clear: FUNCTION MyFunc ( VAR ExtFlag as BOOLEAN ) : BOOLEAN; VAR MyFlag : BOOLEAN; BEGIN IF ( ExtFlag = TRUE ) THEN MyFlag := True; IF NOT ( MyFlag ) THEN BEGIN {...Do some stuff} END; MyFunc := MyFlag; END; On ALPHA, "Do some Stuff" will happen (or not) and the return value will vary, based on ExtFlag; apparently boolean variables that are declared but never explicitly given a value default to false. On IA64, the opposite is apparently the case- a boolean value appears to default TRUE. Hard to see that, when you're expecting the wrapper code to work and "Do some stuff" is what you're tyring to debug. Gaaaahh.... You're right- you should never rely on an undeclared variable. See above re: dinner and beers. Excuse me now, I need to bandage my forehead... -- Dean Woodward =o&o dean.woodward@gmail.com ------------------------------ Date: Thu, 16 Aug 2007 20:06:55 -0500 From: Ron Johnson Subject: Re: Fun with bugs Message-ID: On 08/16/07 19:57, DeanW wrote: [snip] > IF ( ExtFlag = TRUE ) THEN MyFlag := True; Whatever happened the simple MyFlag := ( ExtFlag = TRUE ); Works in C, DCL & Python. It should work in Pascal. -- 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! ------------------------------ Date: Thu, 16 Aug 2007 20:05:13 -0700 From: Bob Gezelter Subject: Re: Fun with bugs Message-ID: <1187319913.847478.295160@57g2000hsv.googlegroups.com> On Aug 16, 8:57 pm, DeanW wrote: > Or, differences from Alpha to IA64... Discovered on VMS I64 8.3, > Pascal 5.9 This is an obvious gross simplification of the brick wall > I've just finished beating my head on, which, having wiped the blood > out of my eyes, is plainly visible. (No, it's not my code; yes, I > think the guy who did write this owes me dinner & a couple beers.) > > Hopefully, I've got all this the right way round so it makes what I'm > about to explain clear: > > FUNCTION MyFunc ( > VAR ExtFlag as BOOLEAN ) : BOOLEAN; > > VAR MyFlag : BOOLEAN; > > BEGIN > IF ( ExtFlag = TRUE ) THEN MyFlag := True; > IF NOT ( MyFlag ) THEN BEGIN > {...Do some stuff} > END; > MyFunc := MyFlag; > END; > > On ALPHA, "Do some Stuff" will happen (or not) and the return value > will vary, based on ExtFlag; apparently boolean variables that are > declared but never explicitly given a value default to false. > > On IA64, the opposite is apparently the case- a boolean value appears > to default TRUE. Hard to see that, when you're expecting the wrapper > code to work and "Do some stuff" is what you're tyring to debug. > Gaaaahh.... > > You're right- you should never rely on an undeclared variable. See > above re: dinner and beers. Excuse me now, I need to bandage my > forehead... > > -- > Dean Woodward =o&o > dean.woodw...@gmail.com Dean, I would REALLY like to see the assembly language code for BOTH of these cases, it would be extremely illuminating (not too mention easier on your cranium and its contents). As a compiler (to be specific, code generator) developer in a galaxy far far away (not in the VMS space), and having had long experience with analyzing similar problems, I would suspect that the problem is not that the default for logical variables has changed. More likely, is that this variable is allocated on the stack, and the somewhat predictable artifacts remaining from things earlier in the control flow of the code has aligned differently on Itanium when compared to what how it aligned on Alpha. As for undefined variables, their contents are, as said, undefined. Unfortunately, because of the undefined variable, this really fits into the category of "illegal, but doesn't yet malfunction" (at least as it exists on Alpha). I would fix the code on Alpha also, because there are no guarantees that this state of affairs will persist. I would also recommend considering checking other code with a similar source, to see if this was a systematic presumption or a simple one- time error. I hope that I have not worsened your headache! - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 16 Aug 2007 17:56:28 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <5ijhecF3p7iadU1@mid.individual.net> In article , "Main, Kerry" writes: >> -----Original Message----- >> From: bill@triangle.cs.uofs.edu On >> Behalf Of Bill Gunshannon >> Sent: August 16, 2007 12:24 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: Intel marginalizing Itanium even faster than expected? >> > > [snip] > >> >> All the more reason to not use Linux for a commercial venture and >> use >> >> BSD instead and then just maintain your own kernel. >> >> >> >> bill >> >> >> > >> > But how many people have the ability to properly maintain SMP, >> clustering, >> > drivers, multi-threading, scheduling etc kernel code? >> >> In what? HP-UX? VMS? BSD? I would bet a lot more for BSD than >> either of the others. >> > > The point I was making is that it is very difficult for a company > who's primary focus is something other than OS platform support > to "maintain their own kernel" as you called it. And the point I was making is that they already do this for both HP-UX and VMS. Both of which are much harder to find truly guru status kernel engineers for than BSD. > > Once you start twiddling bits in the kernel on your own, you are > opening all sorts of potential future compatibility issues with > new releases, security patches, custom drivers etc. Then why does HP do it for both HP-UX and VMS? Might be better to stick to their "primary focus", Windows. > >> > >> > Also, how many companies want to risk not being able to point the >> finger >> > at someone if there is a major issue? What if the guru who maintains >> this >> > code leaves, is on vacation or becomes a disgruntled employee? >> >> Apply the same logic to the ogther contenders. Again, it would be a >> lot >> easier to replace a BSD guru than an HO-UX or VMS guru. I guess it's >> not >> as big a risk as you think. Actually, BSD would be much less of a >> risk. >> > > Again, no one twiddles kernel bits in OpenVMS or HP-UX or AIX or > z/OS on their own. They may apply patches from by the appropriate > vendors, but if it does not work, then that vendor is on the hook > to fix it - not the Customer. Oh, I am sure that no one is doing this at home, but surely HP does it. SO why is it not risky and good business to do it on proprietary OSes and not to do the same on BSD. > If the patch causes problems with a new release, the vendor is on the > hook to find a solution. As they are right now with HP-UX and VMS. Why is that acceptable in the one case, but not in another? > > In your scenario, a new security fix may come out that subsequently appears > to cause random crashing, but the Customer is on the hook to fix it > because they have modified numerous kernel bits here and there. It could be > timing or sequencing or any number of issues that are extremely hard to > troubleshoot - especially when downtime is hard to come by and/or complex > environments like clusters. Where did I say that? I specifically said that HP would state clearly and absolutlely exactly what kernel their stuff works with. Another reason for going with BSD as opposed to Linux is you don't have to give the customer the source to your modifications so he can't "twiddle the bits" in the kernel he gets from you. > >> > >> > Fwiw, companies today are focussing on reducing risk. They are not >> taking >> > any more risk on that will potentially hurt them big time - >> especially when >> > they are under a regulatory umbrella like FERPA, HIPPA, SOX etc. >> >> See above. Seems that the biggest risk along the lines you offered >> above are with VMS where replacing a "guru" could be nigh on >> impossible. >> And yet, HP happily got rid of a majority of those gurus. Guess they >> don't see it as a risk either. >> >> bill >> > > Unless I have misunderstood what you mean by "maintaining your own kernel", I think you certainly have. > you are missing the point. You are recommending maintaining your own > kernel which is exponentially more difficult to support once you start > twiddling SMP, Scheduling etc kernel bits on your own. Its not just > platform SysAdmin support any more, its kernel maintenance, compatibility > testing etc. All of which HP now does for HP-UX and VMS. So using BSD instead of HP-UX would be no different except to open up a whole bunch of already written and tested applications (there's that word again!) that HP-UX doesn't have now. And, actually eliminate the lost guru problem as you would be using an OS where finding another is much easier. 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: 16 Aug 2007 17:59:00 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: <5ijhj4F3p7iadU2@mid.individual.net> In article <%E%wi.48364$rH6.7962@newsfe22.lga>, Ron Johnson writes: > On 08/16/07 12:04, Main, Kerry wrote: > [snip] >> >> The point I was making is that it is very difficult for a company who's primary >> focus is something other than OS platform support to "maintain their own kernel" >> as you called it. >> >> Once you start twiddling bits in the kernel on your own, you are opening all >> sorts of potential future compatibility issues with new releases, security >> patches, custom drivers etc. > > Gah! I agree with Kerry!!!! > > (Does that mean I'm wrong?) Except that I never said the customer would be "twiddling bits" in the kernel but actually said the exact opposite. Twiddling bits in the kernel would be much harder to control under Linux than under BSD because under the GPL you have to give them all the bits to twiddle. Under BSD, you don't. You can, but you don't have to. In a commercial operation, that can be a plus. 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: 16 Aug 2007 13:18:27 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: In article <5ijhj4F3p7iadU2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > In article <%E%wi.48364$rH6.7962@newsfe22.lga>, > Ron Johnson writes: >> On 08/16/07 12:04, Main, Kerry wrote: >> [snip] >>> >>> The point I was making is that it is very difficult for a company who's primary >>> focus is something other than OS platform support to "maintain their own kernel" >>> as you called it. >>> >>> Once you start twiddling bits in the kernel on your own, you are opening all >>> sorts of potential future compatibility issues with new releases, security >>> patches, custom drivers etc. >> >> Gah! I agree with Kerry!!!! >> >> (Does that mean I'm wrong?) > > Except that I never said the customer would be "twiddling bits" in the > kernel but actually said the exact opposite. Twiddling bits in the kernel > would be much harder to control under Linux than under BSD because under > the GPL you have to give them all the bits to twiddle. Under BSD, you > don't. You can, but you don't have to. In a commercial operation, that > can be a plus. But for Kerry's case of "a company whose primary focus is something other than OS platform support" there is no particular disincentive to reveal changes due to commercial competition concerns. They are not in the business of selling their kernel twiddling results. ------------------------------ Date: Thu, 16 Aug 2007 18:31:03 +0000 From: "Main, Kerry" Subject: RE: Intel marginalizing Itanium even faster than expected? Message-ID: > -----Original Message----- > From: bill@triangle.cs.uofs.edu [mailto:bill@triangle.cs.uofs.edu] On > Behalf Of Bill Gunshannon > Sent: August 16, 2007 1:59 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Intel marginalizing Itanium even faster than expected? > > In article <%E%wi.48364$rH6.7962@newsfe22.lga>, > Ron Johnson writes: > > On 08/16/07 12:04, Main, Kerry wrote: > > [snip] > >> > >> The point I was making is that it is very difficult for a company > who's primary > >> focus is something other than OS platform support to "maintain their > own kernel" > >> as you called it. > >> > >> Once you start twiddling bits in the kernel on your own, you are > opening all > >> sorts of potential future compatibility issues with new releases, > security > >> patches, custom drivers etc. > > > > Gah! I agree with Kerry!!!! > > > > (Does that mean I'm wrong?) > > Except that I never said the customer would be "twiddling bits" in the > kernel but actually said the exact opposite. Twiddling bits in the > kernel > would be much harder to control under Linux than under BSD because > under > the GPL you have to give them all the bits to twiddle. Under BSD, you > don't. You can, but you don't have to. In a commercial operation, > that > can be a plus. > > bill > Bill - Here is your exact statement that I was responding to: "All the more reason to not use Linux for a commercial venture and use BSD instead and then just maintain your own kernel." The wording inferred that you were recommending Customers (not vendors) use BSD and simply maintain their own kernel. Based on your feedback, I think we are on the same page in that we both agr= ee this is not what you were recommending. You seem to have been referring to vendors supporting their own distribution like RH does. 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: Thu, 16 Aug 2007 15:46:29 -0500 From: Ron Johnson Subject: Re: Intel marginalizing Itanium even faster than expected? Message-ID: On 08/16/07 12:56, Bill Gunshannon wrote: > In article , > "Main, Kerry" writes: [snip] > > Then why does HP do it for both HP-UX and VMS? Might be better to > stick to their "primary focus", Windows. Ooooooo. That hurt. [snip] > > As they are right now with HP-UX and VMS. Why is that acceptable in > the one case, but not in another? Double standard. [snip] > > Where did I say that? I specifically said that HP would state clearly > and absolutlely exactly what kernel their stuff works with. Another > reason for going with BSD as opposed to Linux is you don't have to > give the customer the source to your modifications so he can't "twiddle > the bits" in the kernel he gets from you. And re-start the Unix War. [snip] > > All of which HP now does for HP-UX and VMS. So using BSD instead of > HP-UX would be no different except to open up a whole bunch of already > written and tested applications (there's that word again!) that HP-UX Especially because FreeBSD has a Linux-compatibility module. > doesn't have now. And, actually eliminate the lost guru problem as > you would be using an OS where finding another is much easier. -- 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! ------------------------------ Date: Thu, 16 Aug 2007 22:26:21 +0300 From: =?ISO-8859-1?Q?Uusim=E4ki?= Subject: Re: Storageworks SAN Switches: possible to reset password ? Message-ID: <46c4a38b$0$27828$9b536df3@news.fv.fi> R.A.Omond wrote: > Gentle colleagues, > > I have, ahem, "inherited" two SANswitches: > > Compaq StorageWorks SAN Switch 16 /158223-B21/DS-DSGGB-AB/158829-001 > Compaq StorageWorks SAN Switch 8 /158222-B21/DS-DSGGB-AA/158828-001 > > They appear to require a password in order to be able to reconfigure > them. Unfortunately I don't have the password, and the previous > owner is, ahem, "not reachable". > > Would anyone know if it's possible to reset them to factory settings > by some method (magic incantation ? biting-head-off-chicken ?). > > Many thanks (and a beverage of choice) to anyone who can help. You have tried all the other usernames, haven't you? "root" and "user" might have still the default password. If none of them work, then you have to get a password recovery tool from Brocade. If you have a Brocade connect account, you'll find the tool there. There is a document in the kit how to perform the password reset. Good luck! Regards, Kari ------------------------------ Date: Thu, 16 Aug 2007 21:27:47 -0500 From: David J Dachtera Subject: To HP: How To Stop Negativity on C.O.V. Message-ID: <46C507A3.631EBDB2@spam.comcast.net> Came across this while perusing AOL this eve. HP folks should especially read the third paragraph, "Now, you may think it's OK..." URL: Anger Management By Tom Hopkins, Posted: 2006-11-15 13:19:42 Have an angry client? Don't hide! Turn their frown upside down with these nine tactics for resolving disputes. Too many people, when faced with clients who range from dissatisfied to downright angry, choose the loser's path by putting off handling the situation. Worse yet, they handle it inappropriately. Postponement doesn't make the problem go away: It results in one of two things happening. Either the angry client decides the problem isn't worth the aggravation and cools down. Or the client gets so angry that the next time you hear from them is via some sort of official--and possibly legal--letter. Now, you may think it's OK to lose one client who's unhappy--but it's not. You see, when we have a good experience with a company, we tend to tell three other people about it. Positive word-of-mouth is great for business. However, someone who's displeased with a situation tells, on average, 11 people about it. Can you see how your business could be hurt by that? And there's an even bigger risk if you're a sole proprietor because you may learn more about your client's anger through legal channels. Naturally, no one wants to walk into a lion's den and face an angry client. However, you must consider the value of this client to you, your reputation and your company. In most cases, I'd guess that it'll be worth your while to face that angry customer and get the situation resolved as quickly as possible. I'd like to give you nine steps I've developed for facing and dispelling another person's anger. These tips work well in most situations mainly because you're giving the client the attention their dissatisfaction deserves. 1. Acknowledge the other person's anger quickly. Nothing adds more fuel to someone's fire than having their anger ignored or belittled. The faster you verbally recognize their anger, the better. 2. Make it clear that you're concerned. Tell them you realize just how angry they are. Let them know you're taking the situation seriously. Make notes of every possible detail they give you. 3. Don't hurry them. Be patient, and let them get it all out. Never try to interrupt or shut them up. In many cases, the best move is to simply listen. They'll wind themselves down eventually. In some cases, they'll realize they blew the situation out of proportion and feel foolish for it. They're then likely to accept nearly any solution you offer. 4. Keep calm. Most angry people say things they don't really mean. Learn to let those things pass and take them up after you've solved the present challenge--only if you feel it's necessary to do so. 5. Ask questions. Your aim is to discover the specific things that you can do to correct the problem. Try to get precise information about the difficulties the problem caused, rather than a general venting of hot air. 6. Get them talking about solutions. This is where you'll learn just how reasonable this client is. By the time you get to this step, their anger should have cooled enough to discuss the challenge rationally. If it hasn't, tell them you want to schedule a later meeting, even if it's in an hour, to come up with some reasonable solutions. Let them do the rest of their fuming on their time. 7. Agree on a solution. After you know exactly what the challenge is, you're in a position to look for some kind of action that will relieve the challenge. Propose something specific. Start with whatever will bring them the best and quickest relief. Don't get into a controversy over pennies at this point. 8. Agree on a schedule. Once you've agreed on a solution, set up a schedule for its accomplishment. Agree to a realistic time frame that you know you can handle. The biggest mistake you can make is to agree to something that can't be done. If you do, you'd better be ready to face another bout of this person's anger when you don't come through. 9. Meet your schedule. Give this schedule top priority. You've talked yourself into a second chance with this client, so make sure you don't blow it.Once you've satisfied the client with regard to this situation, you'll have earned another opportunity to serve their needs in the future...and the needs of those they'll tell about how well you handled it. -------------------------------------------------------------------------------- Tom Hopkins is the "Sales Basics" coach at Entrepreneur.com and is world-renowned as "the builder of sales champions." For the past 30 years, he's provided superior sales training through his company, Tom Hopkins International. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Thu, 16 Aug 2007 21:07:09 +0200 From: Gilles Pion Subject: Re: Which version of SSH? Message-ID: Ref: <1187268509.272494.307050@r29g2000hsg.googlegroups.com> de "hanblo {at} netscape.net" >Hello, >I'm setting up a connection from an OpenVMS machine to a Linux one. >The application owner wants to run sftp, so I said OK, no problem. But >I couldn't get it working until the firewall administrator allowed SSH >V1 traffic to pass. Strange since SSH V1 and SSH V2 use the same port by default (22) -- Gilles "Cool Raoul" - http://coolraoul.cvp-net.com/ ------------------------------ Date: 16 Aug 2007 20:01:01 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: Which version of SSH? Message-ID: <5ijontF3n3k53U1@mid.individual.net> In article , Gilles Pion writes: > Ref: <1187268509.272494.307050@r29g2000hsg.googlegroups.com> de "hanblo {at} > netscape.net" >>Hello, >>I'm setting up a connection from an OpenVMS machine to a Linux one. >>The application owner wants to run sftp, so I said OK, no problem. But >>I couldn't get it working until the firewall administrator allowed SSH >>V1 traffic to pass. > > Strange since SSH V1 and SSH V2 use the same port by default (22) Just guessing as I don't know what he is running there but, many of todays "firewalls" can identify the content of the trafiic and can block particular items. The University does it here to block peer-to-peer music sharing. I think our box is called "Packeteer". (Not advocating such behavior as this particular one with the way it is configured breaks many of the pieces of TCP/IP forcing me to find ways to beat their system. :-) 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: Thu, 16 Aug 2007 20:14:35 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: Which version of SSH? Message-ID: In article <5ijontF3n3k53U1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > > >In article , > Gilles Pion writes: >> Ref: <1187268509.272494.307050@r29g2000hsg.googlegroups.com> de "hanblo {at} >> netscape.net" >>>Hello, >>>I'm setting up a connection from an OpenVMS machine to a Linux one. >>>The application owner wants to run sftp, so I said OK, no problem. But >>>I couldn't get it working until the firewall administrator allowed SSH >>>V1 traffic to pass. >> >> Strange since SSH V1 and SSH V2 use the same port by default (22) > >Just guessing as I don't know what he is running there but, many of todays >"firewalls" can identify the content of the trafiic and can block particular >items. The University does it here to block peer-to-peer music sharing. >I think our box is called "Packeteer". (Not advocating such behavior as >this particular one with the way it is configured breaks many of the >pieces of TCP/IP forcing me to find ways to beat their system. :-) Exactly, which is why I said that his connection not successfully getting through as V2 might be falling back to V1 behavior. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" http://tmesis.com/drat.html ------------------------------ Date: Thu, 16 Aug 2007 12:12:10 -0700 From: Doug Phillips Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1187291530.629194.171260@q3g2000prf.googlegroups.com> On Aug 16, 8:38 am, "Main, Kerry" wrote: > > -----Original Message----- > > From: Paul Raulerson [mailto:p...@raulersons.com] > > Sent: August 16, 2007 12:54 AM > > To: Main, Kerry; Info-...@Mvb.Saic.Com > > Subject: RE: Wonderful things happen to an OS when it has an internal > > champion > > > If you get the chance, check out PSI running Windows 2008 on Itanium. > > The beginning of AppStacking under Windows for sure. > > > Sweet - add and take away processes dynamically. And Windows > > understands > > it happening. :) > > > -Paul > > > > Huh? Who said anything about "flocking to OpenVMS?" > > > > However, since you brought it up, the number one server consolidation > > > target by > > > far in almost every med to large company to today is Windows. > > > Unfortunately, > > > because of the one app, one server culture and platform technology > > > challenges, > > > it is not considered viable to consolidate with App stacking on > > > Windows, so prod's > > > like VMware are going through the roof. > > I am sure there will be technical enhancements in the future which will make App > stacking on Windows (and Linux) more feasible, but the biggest challenge they face > is the Windows culture and ISV's, end users, support types not wanting to share > apps on the same system. > If there's one thing MS does well, it's marketing. When they start spouting the *new* App-Stacking buzz-words in public, the Windows culture will buy into it. If VMS wants to be in the game as more than niche-player, it needs to be able to run the applications that the crowd wants to stack and be visible and vocal in the marketplace when the buzz-words become "fad." Of course, that's just my virtualization of the socio-techno interface paradigm. > And of course, one of the critical technologies associated with App stacking is > a good and reliable workload management sub-system - either in the kernel or via > some add-on product. This might also be called a class scheduler which I suspect > you likely know a thing or two about with experience from the mainframe world .. > > :-) > > For the benefit of others, workload balancing via class schedulers are designed > to ensure that one process does not do something dumb and take over the system > thus impacting other applications. > What a revolutionary new concept!;-) ------------------------------ Date: Thu, 16 Aug 2007 21:03:19 +0000 From: "Main, Kerry" Subject: RE: Wonderful things happen to an OS when it has an internal champion Message-ID: > -----Original Message----- > From: Doug Phillips [mailto:dphill46@netscape.net] > Sent: August 16, 2007 3:12 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Wonderful things happen to an OS when it has an internal > champion > [snip] > > > > I am sure there will be technical enhancements in the future which > will make App > > stacking on Windows (and Linux) more feasible, but the biggest > challenge they face > > is the Windows culture and ISV's, end users, support types not > wanting to share > > apps on the same system. > > > Well, its interesting, but it appears MS is losing some of its grip on the business world as companies are no longer jumping on their latest and greatest the way it used to be. Just look at VISTA - radically fewer companies adopting right now than was expected. Desktop PC vendors (IBM, HP, Dell etc) are now offering models with XP loaded - even after MS said VISTA was the only thing they could ship on new desktops. > If there's one thing MS does well, it's marketing. When they start > spouting the *new* App-Stacking buzz-words in public, the Windows > culture will buy into it. > > If VMS wants to be in the game as more than niche-player, it needs to > be able to run the applications that the crowd wants to stack and be > visible and vocal in the marketplace when the buzz-words become "fad." > Of course, that's just my virtualization of the socio-techno interface > paradigm. > > > > And of course, one of the critical technologies associated with App > stacking is > > a good and reliable workload management sub-system - either in the > kernel or via > > some add-on product. This might also be called a class scheduler > which I suspect > > you likely know a thing or two about with experience from the > mainframe world .. > > > > :-) > > > > For the benefit of others, workload balancing via class schedulers > are designed > > to ensure that one process does not do something dumb and take over > the system > > thus impacting other applications. > > > > What a revolutionary new concept!;-) What's old is new and what's new is old - DCE/NAS =3D=3D> SOA Common Data Dictionary =3D=3D> UDDI Timesharing =3D=3D> Shared Services Utility =3D=3D> Utility (still chasing same old utility concepts - even aft= er 20 years.) Any others ? Btw, Microsoft just announced it is now adopting a new architecture as well= . Reference: http://research.microsoft.com/~gbell/Digital/timeline/1981-4.htm :-) 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: Thu, 16 Aug 2007 16:06:59 -0700 From: Doug Phillips Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: <1187305619.700116.251090@j4g2000prf.googlegroups.com> On Aug 16, 4:03 pm, "Main, Kerry" wrote: > > Btw, Microsoft just announced it is now adopting a new architecture as well. > > Reference:http://research.microsoft.com/~gbell/Digital/timeline/1981-4.htm > > :-) :-)) Didn't Microsoft use VMS in-house for quite a few years or is my bad memory just giving search engines a new mis-information link? ------------------------------ Date: 16 Aug 2007 20:22:37 -0400 From: Rich Alderson Subject: Re: Wonderful things happen to an OS when it has an internal champion Message-ID: Doug Phillips writes: > On Aug 16, 4:03 pm, "Main, Kerry" wrote: >> Btw, Microsoft just announced it is now adopting a new architecture as well. >> Reference:http://research.microsoft.com/~gbell/Digital/timeline/1981-4.htm >> :-) > :-)) > Didn't Microsoft use VMS in-house for quite a few years or is my bad > memory just giving search engines a new mis-information link? Microsoft exclusively used Dec-10 and DEC-20 systems for cross-compilation of their language products until the late 80s or early 90s. They apparently had one or two 11/780 systems on the financial side of the house. -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ End of INFO-VAX 2007.449 ************************