1 INFO-VAX	Sun, 10 Sep 2006	Volume 2006 : Issue 497       Contents:< Re: DISMOUNT foreign tape crashes with VMS83A_ADDENDUM-V0100< Re: DISMOUNT foreign tape crashes with VMS83A_ADDENDUM-V0100< Re: DISMOUNT foreign tape crashes with VMS83A_ADDENDUM-V0100& RE: HP announces new Integrity servers0 Making DECwindows more thin/trim (thinner menus)  F ----------------------------------------------------------------------   Date: 9 Sep 2006 22:44:12 -0700 / From: "Volker Halle" <volker_halle@hotmail.com> E Subject: Re: DISMOUNT foreign tape crashes with VMS83A_ADDENDUM-V0100 C Message-ID: <1157867052.137885.267170@b28g2000cwb.googlegroups.com>    JF,   C as I said, expect VMS83A_ADDENDUM-V0100 to be put on hold and a new . version of that patch to be released publicly.  F If you are in real need of a new IO_ROUTINES.EXE, then the fastest way( to get that would be via a support call.   Volker.    ------------------------------  % Date: Sun, 10 Sep 2006 01:37:16 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> E Subject: Re: DISMOUNT foreign tape crashes with VMS83A_ADDENDUM-V0100 , Message-ID: <4503A46D.490A30DD@teksavvy.com>   Volker Halle wrote:  > 6 > OpenVMS engineering has acknowledged this problem inE > VMS83A_ADDENDUM-V0100 and is going to provide a new IO_ROUTINES.EXE  > image on monday   H That is very good.  This type of response where VMS engineering providesF a patch within a couple of days of a problem being reported on the net7 should go into some of the marketing materials for VMS.   = - you need to log a support call with your HP support center.   F This is not something that needs to go into the marketing. ConsideringE 8.3 was released so recently, shouldn't the patch be freely available / without having to go through a support centre ?    ------------------------------  % Date: Sun, 10 Sep 2006 12:09:45 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> E Subject: Re: DISMOUNT foreign tape crashes with VMS83A_ADDENDUM-V0100 J Message-ID: <paul.sture.nospam-53780B.12094510092006@mac.sture.homeip.net>  , In article <4503A46D.490A30DD@teksavvy.com>,/  JF Mezei <jfmezei.spamnot@teksavvy.com> wrote:    > Volker Halle wrote:  > > 8 > > OpenVMS engineering has acknowledged this problem inG > > VMS83A_ADDENDUM-V0100 and is going to provide a new IO_ROUTINES.EXE  > > image on monday  > J > That is very good.  This type of response where VMS engineering providesH > a patch within a couple of days of a problem being reported on the net9 > should go into some of the marketing materials for VMS.  > ? > - you need to log a support call with your HP support center.  > H > This is not something that needs to go into the marketing. ConsideringG > 8.3 was released so recently, shouldn't the patch be freely available 1 > without having to go through a support centre ?   B Bzzt. It takes long longer to build, test and document a full ECO I replacement (i.e. take it through the full formal process), than issuing   just one executable.   --  
 Paul Sture   ------------------------------  % Date: Sun, 10 Sep 2006 12:48:34 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> / Subject: RE: HP announces new Integrity servers T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401A12216@tayexc19.americas.cpqcorp.net>   > -----Original Message-----4 > From: Bill Todd [mailto:billtodd@metrocast.net]=20! > Sent: September 9, 2006 8:36 PM  > To: Info-VAX@Mvb.Saic.Com 1 > Subject: Re: HP announces new Integrity servers  >=20 > Main, Kerry wrote:   [snip..]   > >=207 > > Sigh .. How many times does it need to be repeated?  > >=20D > > Customers are looking for supported, stable and highly available' > > solutions to run their business.=20  > >=20@ > > The ones making the business decisions are not burning up=20 > their meetings' > > talking about techie chip stuff.=20  >=20B > Exactly:  they are looking at *standardizing* (for reasons of=20
 > cost and=20 A > support complexity that have nothing to do with 'techie chip=20  > stuff') on=20 B > the *least expensive viable solution*.  And beyond any shadow=20 > of a doubt=20 A > that's x86-64 in any situation where that solution *is* viable.  >=20  F Again, you are in the weeds. Customers move to platforms like Windows,E or Linux or OpenVMS for many reasons other than the basic HW. That is D not the issue. When you choose a new std as you call it, you need toD look at the entire HW + OS + App work to move it. The HW is only one albeit small consideration.   H Every platform has strengths and weakneses and challenges. Having statedE this, look at the issues facing someone migrating to a totally new HW ) platform + a new OS on your beloved X86 -   H Windows - that means .Net which is an OO approach to programming that inH most cases means a total re-write of your current 3GL based application.H Heck, ask anyone who has even tried to move a Windows VB6 application toG Net. Try converting mountains of DCL batch code to something similar in H Windows. Throw away 10-15 years work and start over. Yes, tools can helpE but it's the carpenter that builds the house, the tools only help.=20   F Keep in mind re-testing and re-certifying your application will likelyG take longer than the actual porting, so 18+ months is likely very light H estimate (if you are lucky enough to find resources that understand bothA OpenVMS and Windows code). And of course, in production, it means F continually re-testing your App's with the monthly security patches onE your new platfiorm. And of course, unless you want to re-engineer the D architecture (as opposed to straight port), then get used to running8 everything on one system with fail-over clustering only.    B > That's up to 64 Xeon cores *today* in IBM's X3 line, up to 32=20 > Xeon cores=20 ? > from Unisys, up to 8 Xeon cores from HP.  Up to 16 Opteron=20  > cores *today*=20= > from Sun, up to 8 Opteron cores from HP and IBM).  Large=20  > enough in the=20G > case of Xeon for all but the very small niche of those whose needs=20 A > exceed 64-core systems (and they'll be able to get more from=20  > x86-64 next=20J > year, when Opteron will start supporting 32-core systems effectively;=20B > IBM's X3 systems may actually support 128-core configurations=20
 > as early=20 B > as the end of this year if Intel ships quad-core Xeon modules=20 > by then),=20I > and reliable enough for just about anyone who doesn't require *real*=20 0 > fault-tolerant redundantly-executing hardware. >=20 > ...  >=20B > >>> Its probably worth providing this link again for reflection:8 > >>> http://www.itjungle.com/tug/tug102005-story04.html9 > >>> "Stop Arguing About Cars and Start Managing Fleets" I > >> What an interesting citation for someone who purports to be a VMS=20 C > >> advocate.  That article states clearly, multiple times, and=20  > >> in multiple=20  > >> ways, that  > >>C > >> "We find ourselves living in a world of parity; at least as=20  > >> far as Unix,=20B > >> OS/400, and VMS servers are concerned. What I mean by this=20 > is that as=20 C > >> far as base technology goes, we have a level playing field.=20  > >> The Windows=20 @ > >> and Linux operating systems have made some progress, but=20 > >> still have to=20 E > >> make up some ground in terms of scalability, availability and=20  > >> workload=20E > >> management in order to compete head-to-head with the dominant=20 > > >> Unixes--Solaris, AIX, and HP-UX--or IBM's OS/400-based=20 > >> iSeries platform=20E > >> or Hewlett-Packard's OpenVMS platform, which may as well both=20  > >> be Unix in=20D > >> terms of its uptime, resiliency, security, and sophistication." > >>  F You can selectively cut and micro-analyze what you want, but the pointC of the article was all about not getting caught up with the Ghz, GB E techie and OS religion discussions and instead focus on real business < issues like how can IT help the business be more successful?  D > >> Think (if you are capable) of what that means:  that even as=20 > >> of today no=20 D > >> one needs VMS at all (given that just-as-good Unix expertise=20 > >> is so much=20C > >> easier to come by), that increasingly no one needs anything=20  > >> but x86-64=20D > >> (as scalable and reliable solutions on that platform already=20 > >> exist up to=20 B > >> quite reasonable system sizes - 64 cores from IBM, 16 - 32=20 > cores from=20 D > >> multiple sources for Opteron, and even larger configurations=20 > >> on the way=20A > >> for both), and that standardizing on that single platform=20  > >> (with all its=20 ? > >> commodity volume/cost advantages and upon which can run=20  > >> high-end Unix in=205 > >> the form or Solaris, dirt-common Windows, and=20 ! > >> intermediate-level Linux)=20 / > >> thus has become something of a no-brainer.  > >>  D The "we don't need mid or high end systems, we can run it all on ourE distributed systems!!" low end mantra has been around for the last 20  years. Give it a break.=20  A Yes, these lower end platforms are getting better, but the bar is C constantly being raised as well with other platforms. Customers are ? doing massive consolidation projects which requires very highly ' available, secure, stable back ends.=20   E Again you keep talking in the HW weeds. Customers need to think about - the whole package (HW, OS, App architecture).   H The low end mantra is still very much based on "one-app, one system", soE even if you could run multiple Apps on that high end commodity system @ you are talking about, what happens is that you end of having toG virtualize the heck out of to meet that one app, one system culture. As H an eexample, in addition to the technical challenges, try and run 3 or 4D different Windows Bus App's on the same OS and see if the ISV's will even support it!  ? Do you really think Customers are not much more concerned about : security, stability and availability than in the past? =20  C Lets look at this from a risk perspective - what Senior Managers do  think about btw.  G As opposed to your view, you can also run on a much cheaper HW platform E (IA64) than your current one (Alpha/VAX) with much reduced OS license G costs with much reduced App risks as the OS and App architecture is the E same. If you run multiple App's on the one system, you do not have to B break them up into separate VM's on the target system (see one-appC culture notes above). The new HW also meets all of your scalability G concerns - both up and out. Day to day tasks with this new platform can F be managed with Windows GUI's for junior operations staff not familiar with the platform.  Ref:B http://h71000.www7.hp.com/openvms/products/argus/ (scroll down for
 screen shots) > http://h71000.www7.hp.com/openvms/products/availman/index.html  G (+ add in Systems Insight Manager + OpenView agents + gui based console E managers + GUI based backups etc). Like all platforms, you still need ? more experienced staff doing the set-up for these junior types.   G In addition, the new HW can run in the current active-active cluster at E the same time with the old HW to gradually phase out the older HW. No F "big bang" migration required (and big bang migrations scares Mgrs bigF time). You also get to keep the same Ap + Ops support staff instead ofD having to replace the majority of them. And because you can keep theD existing staff, you do not need to worry that new Operations supportD staff will have zero understanding of the way your business actually works.   > >=20A > > Mmm... OpenVMS can certainly hold its own as those running=20  > banks, stockE > > exchanges, chip manufacturing and major health institutions know.  >=20I > Not for *new* users, it can't:  there's no pool of expertise to draw=20 < > from, because virtually all of that expertise has moved=20 > elsewhere save=20 B > for that which is still in place (and aging rapidly) from the=20 > days or yore.  >=20  ? See above, with UNIX CLI, Windows Mgmt GUI's, OpenView/SIM type C interfaces + Java / Script based programming styles, it is now much @ easier to train those less experienced. And lets not forget thatA experienced (not rookies) Windows and UNIX SysAdmins are not that F avaiable either. I know cause I have seen projects trying to find themC as well. Just try and find an experienced Windows resource that can G plan, design, install and integrate a Windows Active Directory project.   @ Imho, finding a proven, experienced .Net programmer who has realG experience writing highly scalable (SMP aware) .Net code is on par with H finding a senior Cobol resource with Web dev and integration experience.  J > Not exactly a recipe for growth, or for long-term confidence that its=207 > vendor will continue to do much to keep it even as=20  > competitive as it is=20  > today. >=20 > >=20J > > But feel free to keep harping on the techie Mhz and Ghz cool-aid ..=20 >=20B > You're the only one trying to divert the conversation in that=20 > direction,=20 A > Kerry:  I didn't say a word about *anything* technical, just=20  > about the=20A > kinds of high-level management issues that appeal to - well,=20  > high-level=20 B > management that makes the final decisions, as the article noted. >=20  G I'm not sure what Mgmt types you know, but you are talking about issues H (cores, X86-64 vs IA64 vs Power 5+) that techies talk about. Most seniorG Mgmt types would not know the difference between *any* Intel platforms. F To them, an Intel platform is an Intel platform. Or an IBM platform or an HP platform.=20   > >=20C > >> Of course, some people might dispute some of the underlying=20  > >> assumptions in the above  > >=20 > > You think? >=20I > The point, as I made clear in the continuation of that sentence that=20 G > you've even quoted just below, was that you cited an article which=20 I > directly stated that VMS no longer enjoyed any notable advantages as=20 9 > support for your position.  Are you withdrawing that=20  > recommendation now,=20I > or do you just want to pick and choose which portions of the article=20 D > people should consider authoritative and which they should ignore? >=20  F As stated already - You can selectively cut and micro-analyze what youF want, but the point of the article was all about not getting caught upH with the Ghz, GB techie and OS religion discussions and instead focus on> real business issues like how can IT help the business be more successful?    > >=20? > >> , but they follow very directly from combining your own=20 G > >> repetitive droning with the content of the article which you've=20 < > >> recommended we reflect upon.  As the adage goes, "Be=20 > careful what you=20  > >> wish for..."  > >> > >> - bill  > >> > >=20   [snip..]   > >=20? > > And remember that the initial server HW costs are one of=20  > the smallest# > > components of the overall cost.  >=20A > Exactly:  that's why platforms with dwindling popularity are=20  > generating=20 G > dwindling interest, while despite their limitations platforms like=20 ) > Windows and Linux are growing robustly.  >=20  E Tell that to almost all the med-large Customers who are doing massive G very aggressive server consolidation projects. The number one target by F far is Windows on x86 platforms. Typical HW consolidation goals ranges
 from 20%-40%.   D You really should get out more and talk to real med-large Customers.  ? > Between legacy platforms that people choose only when they=20  > have no other=20? > (short-term) choice, and robustly-developed platforms that=20  > people choose=20G > whenever those platforms can meet their needs, which do you really=20 F > believe have the better prospects?  If the owners of those legacy=20I > platforms had been a lot more aggressive in keeping them current and=20 @ > competitive, the situation might have been very different -=20 > but that's=20 ' > water under the bridge at this point.  >=20  H Give it a break with the "legacy" rhetoric will you?  Geeeze, you should know better.  F Microsoft calls Windows 2000 "legacy". Sun calls Solaris 7/8 "legacy".@ IBM calls AIX V4 and older "legacy". RH calls its older versions	 "legacy".   9 Are you saying Customers should drop all these platforms?   B You know as well as everyone here that every platform has "legacy"> versions. That does not means their current versions should be considered as legacy.=20  H Btw - I just love the news that Windows Vista is planning to provide theC capability to provide different users with some different levels of * security. What a great new novel concept!!   :-)      > >=20= > > Imho, as an example of the importance of benchmarks today  >=20B > Why do you continue to try to divert the conversation and set=20
 > up straw=20 B > men?  (That was a rhetorical question, of course:  anyone who=20 > knows you=200 > at all understands very well why you do that.) >=20  F Puuulease, you raised the point about OpenVMS and why it was importantC to have a benchmark on the new HW. I was simply responding to that. G Remember this statement you made - " That would be great, since I can't E remember the last time VMS's owners bothered to benchmark anything on  VMS."   A > When you're on the losing side of an argument, continuing to=20  > bluster for=20D > the benefit of the audience just gives them more opportunity to=20H > understand how full of shit you really are.  This is not doing your=20F > employer any favors:  just as with the current BoD fiasco, they'd=20@ > probably prefer just to minimize all conversation about the=20 > issue - they=20   ? And who is now trying to divert the conversation? Leave the BOD  discussion to another thread.   D Bill, here is a question for you - have you ever considered taking aE people relationship and communications course?  I think you will find @ that cursing at people in public places is likely not one of the/ recommended best practices for getting respect.   H > don't need to convince those who already understand and are already=20F > flocking to the *real* 'industry-standard' solutions that HP will=20I > happily sell them, and would just as soon those who don't understand=20 @ > remain in the dark and continue to pay through the nose for=20 > their legacy=20  > cash cows. >=20  ( What cool aid have you been drinking?=20  E Based on what you are saying, all mainframe Customers will be soon be % running on x86's as well - right? =20   H > Not that there are likely to be all that many people here who still=20B > don't understand, of course:  most of those who felt they had=20 > any viable=20 I > alternative to VMS have either left already or are waiting for their=20 < > current systems to become inadequate while alternatives=20 > continue to mature.  >=20 > - bill  F Yep, they can't wait to jump on this new magic commodity platform that' has all the answers to world hunger.=20   H Even if they have to spend 18-24 high risk filled months getting on to aC new magic platform with a one-app, one system culture that has 5-20 H security patches per month, they will love it as they are moving to a HW9 platform that is a few $'s less than the alternatives.=20   B Yep, that's what Senior Managers are thinking about alright ...=20   :-)    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  % Date: Sun, 10 Sep 2006 05:34:35 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> 9 Subject: Making DECwindows more thin/trim (thinner menus) , Message-ID: <4503DC2B.499D9396@teksavvy.com>  G While screens have moved from 24*80 to 640*480 to 1280*1024, we've made G greater use of the available screen real-estate by keeping more windows  opened at a time.   H In an effort to minimise screen clutter, I've set on a jihad to thin out" my windows. (This is on VAX-VMS).   L Using window manager menus, I can easily reduce the window border thickenes.B Using DEC$MWM.DAT , I was able to thin out the window titles with:  G Mwm*client*titke*fontList: -font specificcation for 10 point helevetica + bold.  (by default I think it is 14 point).   E My next battle is to get the default menubars to be much thinner. I'd @ like to remove any margins above/below the text in the menu, andE possibly reduce the default font used in the menu bar (but not in the  drop down menus).   D How do I go about with this ?  Which file should contain applicationF level standard definitions that apply to all applications ? (I realiseH this would have to be on each node that end up targetting a display on aG x-terminal, whereas the MWM definition applies to the node on which the  window manager executes).     F And while I am at it, is there a way to get one window (decw$clock) to1 always remain on top even if it is not in focus ?    ------------------------------   End of INFO-VAX 2006.497 ************************