1 INFO-VAX	Sun, 16 Jul 2006	Volume 2006 : Issue 393       Contents:? Greenhorn question: XON/XOFF control chars (when in MicroEMACS) C Re: Greenhorn question: XON/XOFF control chars (when in MicroEMACS)  Ground Hog Day# RE: HP to cut down on telecommuting & Re: The possibility of vms opening up? Re: VMS and HPVM Re: VMS and HPVM Re: VMS and HPVME RE: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing) E RE: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing) E Re: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing)   F ----------------------------------------------------------------------    Date: 16 Jul 2006 07:11:24 -0700 From: sampsal@gmail.com H Subject: Greenhorn question: XON/XOFF control chars (when in MicroEMACS)B Message-ID: <1153059083.982684.77830@h48g2000cwc.googlegroups.com>   Hi,   B I just finished installing MicroEMACS 3.12 on my VMS box (7.3-1 if> relevant) and it works fine except for the fact that somethingG somewhere keeps grabbing the ^S chars sent, and the terminal connection E then locks up until I hit ^Q. I assume this is to do with incorrectly   interpreted XON/XOFF characters.  B I've played around with SET/TERMINAL but to no avail. The terminal4 program in use is Terminal.app on Mac OS X (10.4.7).   Thanks in advance,   Sampsa   ------------------------------  % Date: Sun, 16 Jul 2006 11:51:27 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> L Subject: Re: Greenhorn question: XON/XOFF control chars (when in MicroEMACS), Message-ID: <44BA607C.BF44FA06@teksavvy.com>   sampsal@gmail.com wrote:I > somewhere keeps grabbing the ^S chars sent, and the terminal connection G > then locks up until I hit ^Q. I assume this is to do with incorrectly " > interpreted XON/XOFF characters. > D > I've played around with SET/TERMINAL but to no avail. The terminal6 > program in use is Terminal.app on Mac OS X (10.4.7).  B How do you physically connect the mac to the VMS box ? Is it via a, serial port or some ethernet (lat, telnet ?)    0 For proper XON-XOFF in both directions, you need   $ SET TERMINAL /HOSTSYNC/TTSYNC   G If the scrolling stops but doesn't restart on its own, it could be that G something is eating yor control-Qs or that the terminal program doesn't D actually send a control-Q once its buffer has been emptied and it is ready again to receive.    ------------------------------  % Date: Sun, 16 Jul 2006 23:07:14 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com>  Subject: Ground Hog Day 1 Message-ID: <e9dkiq$aot$1@news-02.connect.com.au>   	 Hi Steve,   J >    I believe I indicated "not supported from inner mode", in conjunction > with "all RTL routines."  K 1) The sys$persona_create documentation says otherwise, and 2) The court is I still taking submissions on your "Expert Witness" status :-) Also, no one J seems exactly sure why your's should be either the final, or the official, say on the matter.  L As a man renowned for choosing his words wisely, you once again have rumagedI through your arsenal of  shifting goalposts and produced the deliberately ? vague, yet all encompassing, generalisation "all RTL routines".   = > As part of addressing this documentation request, I'll pass I > along a release note for inclusion into V8.3, specifically stating that 7 > no inner-mode calls into user-mode RTLs are supported   K There you go again :-( If you commit this crime against the VMS people then I I will have seriously lost much respect for you. (Try and go through life I with that hanging over your head :-) Alternatively, if you were to update 5 the documentation along the lines of the following: -   L "Unless explicitly stated otherewise, all OpenVMS Run-Time Library routines,J and other Shareable Image routines supplied with the Operating System, areI architected and supported to only function correctly at User-Mode, and at  IPL 0."   7 . . .then I, for one, would not have a problem with it.   F I know that you understand the distinction, but for the benefit of the viewers let me ellaborate.  A If I write a UWSS or User-Mode shareable (both of which have been J architected to function at Inner-Modes) and call it from another UWSS; areK you once more FUDding that this is unsupported? NO STEPHEN! I am not asking H VMS to warrant what happens in the routine itself but I do expect VMS toE warrant (and support) that my RTL will be activated both securely and I reliably as the offspring of a PROTECTed image. This Ladies and Gentlemen F *is* the functionality that we enjoy today. Whether a specific routineK itself in any given RTL, is capable of acting with decorum at inner-mode is I down to the authors of that particular routine. If it is X-Mode safe then H that should be published along with all other environmental restrictions such as privilege and quotas.   $ Let me spell it out for you again: -L ["It is perfectly possible, however difficult and dangerous the task may be,I to securely call out to an RTL routine that is architected to function at  inner-mode"]  @ >    I've not seen and not encountered any OpenVMS documentationB > indicating inner-mode calls to the user-mode RTLs are supported, :  > If such support H > documentation existed, I'm certain that it would have brought it to my > attention already, too  K If you'd care to remove your hands from your ears and stop singing "La, la, K la, I can't hear you!" for a moment, you can scroll up a few pages to where I I directly quoted from the VMS documentation on the web, about inner-mode 2 support by routines in bothe LIBRTL and SECURESHR.  @ >    Put another way, Mr Maher seeks an OpenVMS enhancement here  # Stephen, please! Call me Dickie :-)   I (Also, how do you know it's not just "from someone posting as Mr Maher"?)   D I *honestly* don't care one way or the other. Any enhancement or newK features will arrive too late for me and will not be back-ported to earlier G versions of VMS, so are limited in their application. (I'd be more than  happy to see them nonetheless!)   J As I have said before, the routines that concern me are sys$persona_createD and lib$*_vm. I can get around the $persona_create scenarion using aG combination of $p_eserve/$p_delegate/$p_delete. (This is also good 'cos I peviously a persona could get stale if the UAF had been modified. ie: you E would've had to have stopped and restarted the application to see the J changes. NOW, the persona will be created by the Communication Server whenI the client connects (logs-in) and disappears when they disconnect. ie: to I see the changes you simply log out and log back in again. Also, with only L one Tier3 persona/Execution Server, I no longer have to change the persona's  D account to T3$ACC to track my inventory. The lib*vm is replaced by a5 quasi-dynamic pool allocated at server start up time.   I But what does piss me off is the prospect of agenda-driven barrow-pushers L who, without pausing for breath, can say both "I'd expect its fairly easy toL get the UWSS code to tip over here (no more so than usual, for *application*J code," -and- "I haven't looked to see how Rdb secures the UWSS code withinL that product.". You get to FUD and brief against me while sucking up to yourL buddies at Rdb in a single bound and all without a single thread of evidenceF of substantiation either way! That's some top quality H2O right there.L That's real Himalayan Glacial shit! If we can stick to the facts in future I, think it would save everybody a lot of time.  ! How did your week pan out anyway?    Cheers Richard Maher  H PS. If any proactive VMS engineer out there really wants to do somethingJ useful they can pick up the phone to Rdb engineering and say "We're tryingJ to run down a potential VMS bug but it's shaping up to be a Rdb issue. TheI reference count on a persona gets incremented in $qio to stop the persona J from disappearing until the i/o has completed. Your read only transactionsE appear to leave an i/o outstanding after the commit which could delay J (indefinitely?) a cleanup of Tier3 personae in a timely fashion. Could youK please identify what that i/o is and that it does eventually complete (with  the next txn?)".  9 "Hoff Hoffman" <hoff-remove-this@hp.com> wrote in message * news:05Psg.316$na6.269@news.cpqcorp.net... > John Reagan wrote: > > Richard Maher wrote: > >  > >> > >> For example:  > >> > >> $GETUAI > >> > >> > >> REQUIRED ACCESS MODE  > >>& > >> Cannot be called from Kernel Mode > >> > > J > > $GETUAI/$SETUAI uses RMS to access SYSUAF.DAT.  That is the reason for8 > > the restriction about calling them from kernel mode. > J >    I believe I indicated "not supported from inner mode", in conjunctionJ > with "all RTL routines."  What individual programmers might choose to doE > here and whether or not the particular programmers involved require F > formal support is, however, obviously entirely up to the programmer. > @ >    I've not seen and not encountered any OpenVMS documentationH > indicating inner-mode calls to the user-mode RTLs are supported, and IF > do recall seeing some degree of consternation around out-bound callsH > from UWSS images earlier in the various threads -- this outbound-callsE > mechanism was implemented to specifically prevent casual calls into D > OpenVMS RTLs and such.  (As I've stated -- since April, within theI > context of this thread -- there ARE limitations here.)  If such support H > documentation existed, I'm certain that it would have brought it to myI > attention already, too -- this is far from the first similar discussion  > I've been in over the years. > J >    Put another way, Mr Maher seeks an OpenVMS enhancement here -- accessH > to RTL services from inner-mode code -- which is certainly an entirelyG > reasonable request, and thus fodder for a formal enhancement request, B > and (if accepted by the business management folks) the requisiteF > engineering efforts within the various RTLs that would be needed andJ > scheduled.  Work to ensure that this operates correctly would be needed. > D >    If received, I will certainly forward a formal request for thisH > enhancement along to OpenVMS business management, or Mr Maher can passJ > this request in via the support center or via whatever representative(s)I > of HP he would prefer to deal with.  Details on the particular services F > of interest would be useful -- obviously we're discussing one of theG > groups of services I've also had similar troubles with from one of my J > own UWSS images, the LOADSS family of OpenVMS security-related services.I >   There may well be other services needed, and these should be included 
 > as well. > G >    Again, I might add that this enhancement is an entirely reasonable H > request, both around better documentation, and around adding mode-safeE > calls.  As part of addressing this documentation request, I'll pass I > along a release note for inclusion into V8.3, specifically stating that F > no inner-mode calls into user-mode RTLs are supported -- it's alwaysG > troubled me that there is comparatively little inner-mode programming C > documentation available for OpenVMS, beyond the driver manual and I > related materials.  The release note -- if it makes it in in time to be H > reviewed and included in the V8.3 release notes -- will (re)confirm myF > statements (above), but it obviously and unfortunately won't address& > requirements to call these services. > C >    I'd also certainly personally prefer to see a way to call into E > various of these RTL and LOADSS routines (safely and securely) from F > within an inner-mode routine (probably from exec-mode non-AST at theF > highest), but I do expect that the RTL security review required hereH > will be non-trivial -- and ignoring any remediation and the associatedJ > testing that might be required as a result of concerns identified duringH > the security review.  Hence the formal request -- that is how projectsC > get into the review cycle, and (potentially) onto the engineering E > schedule.  (Again, I can pass a formal request along to the OpenVMS H > security business manager, as I expect he would be one of the managers2 > inevitably involved in this project discussion.) >  >    ------------------------------  % Date: Sun, 16 Jul 2006 09:06:13 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> , Subject: RE: HP to cut down on telecommutingT Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684017234E2@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Steve Matzura [mailto:number6@speakeasy.net]=20  > Sent: July 15, 2006 10:09 PM > To: Info-VAX@Mvb.Saic.Com . > Subject: Re: HP to cut down on telecommuting >=20E > This is a trend I'm finding is taking hold across the VMS board.  I C > was just recently let go from a job where I'd been asking for the H > ability to telecommute since '99. Unfortunately, it was 9/11 that gaveD > me that ability when the building in which my ofice was housed wasG > closed for three months thereafter while they cleaned it up. After it G > reopened in January, 2002, I worked at home at first two days a week, E > then three, then I got a new supervisor who permitted me to work at G > home full time.  It was the best possible situation for both sides--I G > was available for more hours per day, which was good for the company, F > and I got to lose a commute with which I really couldn't deal due toH > physical limitations, which was good for me.  Since my separation fromF > this company earlier this year, I've been looking for VMS work whereF > telecommuting is embraced, but there's a trend going on out there toF > bring everybody back into the ofice that very well may spell the endH > of this 25-year VMS professional's work life. And here I thought I had( > at least another decade or more to go. >=20. > On Mon, 05 Jun 2006 16:44:09 -0400, JF Mezei' > <jfmezei.spamnot@teksavvy.com> wrote:  >=20? > >http://www.mercurynews.com/mld/mercurynews/news/14732974.htm  > > ? > >About 1000 employess in the IT division will no longer be=20  > able to workD > >from home. Those who don't accept to work in one of 25 designated/ > >offices will be let go without severance.=20  > > 8 > >Not known if this is to spread to other divisions.=20 > > C > >HP had been a world leader in flexible work rules startting with E > >introduction of flextime back in 1967. Last July, they hired an ex H > >Walmast IT director and it seems he doesn't believe in telecommuting. >=20 >=20  D There is always going to be some debate which is better, but this isC only one division in HP doing this that I know of. Others have very E openly embraced the virtual work from home strategy. Indeed, facility F closures are usually based on this virtual work closure concept as theF cost of facilities is just way to big of a cost. It assumes a relativeG ratio of 3-5 (or higher) workers per virtual work "pod" and if everyone F had to go back into the office, then new facilities would be required.  A For DR scenario's, you need to have an established work from home B infrastructure as workers may not be able to physically get to theH backup site. In addition, if everyone is in the office at the same time,H it further raises the risk of a significant event impacting the majority of your workers.=20   E Think of a single person walking into your office facility and Health G authorities find out he/she was exposed to SARS. They may not even have D it - simply being exposed is enough to close the entire building andE send *everyone* in that entire building home for 10 days minimum. For G those who have not lived through SARS type events, that is the accepted  process.  B This SARS / pandemic worry is not theory - it actually happened inE Toronto. The entire facility was closed and everyone sent home for 10 G days. It just so happened that a data center was also in that building. F The DC had to be vacated immediately (no backups, no gathering tapes -G just leave now!) and closed to all physical access for 10 days as well. H Fortunately, the DC was part of a dual site design and the workers couldF continue working from home along with staff at the other facility, but? how many companies have this multi-site + remote work from home  capability today?   H It is also why new DC's being built today should be dedicated structuresC away from major centers and that do not have any shared access with  other tenants or office space.   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: 16 Jul 2006 07:27:50 -0700( From: "geletine" <adaviscg1@hotmail.com>/ Subject: Re: The possibility of vms opening up? C Message-ID: <1153060070.077955.255270@p79g2000cwp.googlegroups.com>    Richard B. Gilbert wrote: H > My experience with the CMU-TEK TCP/IP stack was ca. 1986-1994.  I haveI > had not contact with the stack or the developers since then.  My memory I > is DIMM. (sorry)  I know that it was, at that time, written (mostly) in G > BLISS-32.  ISTR an effort to use/convert to C.  Don't know if it ever G > really happened.  Google for CMU-TEK and follow the links you find to  > whatever exists now. > G > There was also BLISS-36 (PDP10/PDP20).  I think there may have been a 7 > BLISS-16 (PDP11) but I'm by no means certain of that.  There seems to be      * BLISS-100     * BLISS-11 - a cross compiler for the PDP-11     * BLISS-16)     * BLISS-16C - DEC version of BLISS-11      * BLISS-32     * BLISS-36     * BLISS-64$     * Common BLISS - portable subset   an a portable version for GCC & ftp://freevms.nvg.org/pub/vms/freevms/  : I am trying to find out more at http://h71000.www7.hp.com/3 when it is up, would you know if there is a mirror?    ------------------------------  + Date: Sun, 16 Jul 2006 10:23:56 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk Subject: Re: VMS and HPVM ) Message-ID: <e9d43s$j7q$2@news.mdx.ac.uk>   k In article <44b985ad$0$67255$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes:  >JF Mezei wrote:' >>>> Why would anyone want to do this ?  >>   >>  H >> Say you have a 64 CPU IA64 thing.  You load HP-UX on it. Create a VMSJ >> application/instance that only has 4 logical CPUs. VMS only sees 4 CPUsJ >> , as do your applications. So from a licencing point of view, you could? >> end up saving lots of money because you need not licence all $ >> applications on VMS for 64 CPUs.  >.... K >> Personally, I think this is more of a marketing scam than anything else, > >> but it CAN be of great value to certain specific customers. > J >And yet many companies have implemented features like that.  IBM has for J >years had VM on their zSeries machines.  HP has had Galaxy on Alpha, and H >so on.  AMD and Intel have been fighting to be the first with a useful A >set of features for virtualization on IA32.  It seems like many  G >customers consider this a useful feature.  On zSeries machines it has  D >been common to use one virtual machine for development and one for  >production. > H >Application Service Providers can let customers share the same machine I >while each customer is free to chose their own setup, e.g., a web hotel  J >can let each customer have its own set of Java scripts without and there H >will be little risk that a security in one customers setup will affect  >the other customers.   O Partitioning and running multiple versions of the same OS or different OS's ala L Galaxy I consider to be a good thing. However this is the first I have heardE that Galaxy wasn't going to be supported on Itanium high end systems. D Doing this running under HP-UX I consider very much a backward move.    
 David Webb Security team leader CCSS Middlesex University   ------------------------------  + Date: Sun, 16 Jul 2006 10:37:59 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk Subject: Re: VMS and HPVM ) Message-ID: <e9d4u6$jpr$1@news.mdx.ac.uk>   J In article <e9d43s$j7q$2@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:l >In article <44b985ad$0$67255$157c6196@dreader2.cybercity.dk>, Karsten Nyblad <nospam@nospam.nospam> writes: >>JF Mezei wrote: ( >>>>> Why would anyone want to do this ? >>>  >>> I >>> Say you have a 64 CPU IA64 thing.  You load HP-UX on it. Create a VMS K >>> application/instance that only has 4 logical CPUs. VMS only sees 4 CPUs K >>> , as do your applications. So from a licencing point of view, you could @ >>> end up saving lots of money because you need not licence all% >>> applications on VMS for 64 CPUs.   >>....L >>> Personally, I think this is more of a marketing scam than anything else,? >>> but it CAN be of great value to certain specific customers.  >>K >>And yet many companies have implemented features like that.  IBM has for  K >>years had VM on their zSeries machines.  HP has had Galaxy on Alpha, and  I >>so on.  AMD and Intel have been fighting to be the first with a useful  B >>set of features for virtualization on IA32.  It seems like many H >>customers consider this a useful feature.  On zSeries machines it has E >>been common to use one virtual machine for development and one for  
 >>production.  >>I >>Application Service Providers can let customers share the same machine  J >>while each customer is free to chose their own setup, e.g., a web hotel K >>can let each customer have its own set of Java scripts without and there  I >>will be little risk that a security in one customers setup will affect   >>the other customers. > P >Partitioning and running multiple versions of the same OS or different OS's alaM >Galaxy I consider to be a good thing. However this is the first I have heard F >that Galaxy wasn't going to be supported on Itanium high end systems.E >Doing this running under HP-UX I consider very much a backward move.  > H Just found this post in comp.os.vms from Fred Kleinsorge in January 2004   " H OpenVMS provides software partitions (Galaxy) on Alpha.  We also plan toA migrate this capability to IPF using the same underlying firmware F capabilities that HP-UX will use for fPars.  The schedule and externalF coimmunication/commitment for this has not yet been published, but the preliminary work is underway.    "   J and I thought I'd seen this in some of the published roadmaps in the past.        
 David Webb Security team leader CCSS Middlesex University   >    ------------------------------   Date: 16 Jul 2006 15:40:04 GMT( From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: VMS and HPVM + Message-ID: <4hv4ukF1dp9iU1@individual.net>   , In article <44B99B26.F3EAFF79@teksavvy.com>,0 	JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Karsten Nyblad wrote: K >> And yet many companies have implemented features like that.  IBM has for , >> years had VM on their zSeries machines.   > H > IBM went from VM (a software solution on 360s and 370 ) to firmware in! > its mainframes. (390 and later)  > I > VMS is going from firmware (in GS series machines) to software (HP-UX). C > In the case of VM, it was designed specifically to host different G > operating systems and was "lightweight".   With HP's scheme, HP-UX is H > far from lightweight and VMS will run as an application/process on it.  E And far from new.  VMWare has been around for a while (although up to B the point where we abandoned it the performance was terrible and IF doubt it ever got good enough to be considered as a serious commercialD contender) and Microsoft has VirtualPC.  I use VirtualPC quite a bitG with more than satisfactory reults.  And, I  have actually used systems E in a lab at Ft. Gordon that I didn't even know were running VirtualPC D until the end of the course when we reloaded everything for the nextF class. (That was running Server2003 on the VirtualPC on top of Win2K.)   >  >  > I >> so on.  AMD and Intel have been fighting to be the first with a useful . >> set of features for virtualization on IA32. > I > Yes, because Windows is too often only able to run one application. So  I > having a "VM" on an 8086 allows you to run multiple applications on the I > same box. (one VM, and then multiple instanmces of widows, each running  > one app).   : See above, Microsoft has had a solution for some time now.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  % Date: Sun, 16 Jul 2006 09:36:45 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> N Subject: RE: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing)T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684017234E5@tayexc19.americas.cpqcorp.net>   > -----Original Message-----E > From: johnhreinhardt@yahoo.com [mailto:johnhreinhardt@yahoo.com]=20  > Sent: July 15, 2006 5:00 PM  > To: Info-VAX@Mvb.Saic.Com @ > Subject: Re: VMS and HPVM (was: Parsec webinar (2006-07-12)=20 > OpenVMS Licensing) >=20 >=20 > Larry Kilgallen wrote:0 > > In article <e9b33l$shr$1@news.mdx.ac.uk>,=20" > david20@alpha2.mdx.ac.uk writes: > > A > > >>Folks at the boot camp last month had the chance to view=20  > my demonstrationE > > >>of a VMS guest on top of HPVM; the VMS guest was clustered with B > > >>another VMS guest and several other Alpha and I64 systems=20 > (and a VAX thrown in? > > >>for good measure).  We still have a lot of work to do,=20  > but features like ? > > >>shadowing are working with no problem.  It is expected=20  > that this will be 0 > > >>shipping and supported at the end of 2007. > > >> > > > ( > > > Why would anyone want to do this ? > > B > > Some people want to subdivide a large machine into multiple=20 > operating B > > systems or multiple instances of a single operating system.=20 >  On Alpha G > > that is done with Galaxy.  On Itanium it is possible to do it fully G > > in software, since (I gather) the Itanium instruction set design is ? > > such that it can be virtualized, like OS360 and unlike VAX.  > >  >=20B > In addition it gives you a bit more flexibility in dividing yourA > system.  If I am not mistaken, the cell-based Integrity servers D > (Superdome, rx74xx,rx84xx) all support running multiple OSs on the5 > different cells of the same server.  However, to=20  > re-distribute the CPUsC > between the cells requires the machine be downed and the hardware A > configuration changed.  With the HPVM it seems like it would be G > possible to make such changes without downing the whole server - only F > the affected virtual machines.  Possibly it could be done on the fly5 > without requiring a shutdown of any virtual server.  >=20 >=20  G Note that the reason for doing partitioning to begin with is usually to 6 make better use of fewer, but larger server resources.  A Keep in mind that most Customers today are faced with the average E utilization of their Windows systems being 5-15% busy in *peak* times H (only 5-10% of servers ever exceed 80-90%). For UNIX servers, this ratio4 is a bit higher, but not much higher (10-25% range).  F This grossly under utilized server problem is also why many Cust's areF not impressed with performance benchmarks of new systems. They alreadyE have huge imbalance of under-utilized server resources. It is why the - whole VM/consolidation topic is so hot today.   C The analogy I use with Customers considering consolidation is "what F would you do if your IT staff was only 5-20% busy at peak times? Would' you not want to do something about it?"   @ With most OpenVMS Customers, if they wanted to consolidate theirE workloads, they would simply run the app's on a single system/cluster F i.e. App sharing because that is accepted culture/practice for OpenVMSG Customers. It is quite common for example to run the DB and middle tier G business logic on the same OpenVMS system/cluster. They have been doing  that for years.   F However, there are some areas where local politics means that having aC VM capability to keep the OpenVMS apps from different BU's separate F would be beneficial. Every Cust typically has those internal political challenges.   C With Windows/Linux and many UNIX environments, the same App sharing D culture/practice is not as accepted for both technical and political< reasons, and the "one app, one server" mentality makes those3 environments more ripe for VM type environments.=20   D Keep in mind that VM's reduce HW requirements, but not OS licensing,@ hence the reduction of SysAdmins is minimal since FTE ratios areE typically built of OS instance per SysAdmin ratio's. Each OS instance G still needs to be monitored, managed, licenses, updated. The main focus G is HW reduction. With App sharing, you reduce not only HW, but also the " number of OS instances as well.=20  E The other challenge with VM's is that some ISV's are much better than G others when it comes to VM licensing and support. ISV licensing of VM's H can be a topic all of its own. As an example, Microsoft does not supportC Cust's where their application is running on VMware. Their std line A (unless it has changed) is "reproduce the problem on a standalone ' machine and we will take a look at it".   F Bottom line is that that there are pro's and con's with VM strategies.H Each needs to be reviewed to determine if it is right for you or not.=20  E However, unless you also reduce the OS instances, the IT dept will be H able to reduce HW costs, but not likely be able to reduce their IT staffG much. And IT Staff is the single biggest slice of IT expenses (by far).    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: 16 Jul 2006 09:38:44 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen) N Subject: RE: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing)3 Message-ID: <im0gVaCvSEDg@eisner.encompasserve.org>   ~ In article <FA60F2C4B72A584DBFC6091F6A2B8684017234E5@tayexc19.americas.cpqcorp.net>, "Main, Kerry" <Kerry.Main@hp.com> writes:  B > With most OpenVMS Customers, if they wanted to consolidate theirG > workloads, they would simply run the app's on a single system/cluster H > i.e. App sharing because that is accepted culture/practice for OpenVMSI > Customers. It is quite common for example to run the DB and middle tier I > business logic on the same OpenVMS system/cluster. They have been doing  > that for years.  > H > However, there are some areas where local politics means that having aE > VM capability to keep the OpenVMS apps from different BU's separate H > would be beneficial. Every Cust typically has those internal political
 > challenges.   D One such challenge is a top manager who looks at how the company hasD dealt with Windows and determines to take that path with VMS.  It isE important that VMS be able to play in that fashion, even if it is not  required for technical reasons.    ------------------------------  % Date: Sun, 16 Jul 2006 11:48:06 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> N Subject: Re: VMS and HPVM (was: Parsec webinar (2006-07-12) OpenVMS Licensing), Message-ID: <44BA5FB5.3E1C8F33@teksavvy.com>   "Main, Kerry" wrote:C > Keep in mind that most Customers today are faced with the average G > utilization of their Windows systems being 5-15% busy in *peak* times J > (only 5-10% of servers ever exceed 80-90%). For UNIX servers, this ratio6 > is a bit higher, but not much higher (10-25% range).  G But HP's IA64 solutions are not of any use for those since they are not 8 likely to be able to run their apps on that IA64 thing.     H > However, there are some areas where local politics means that having aE > VM capability to keep the OpenVMS apps from different BU's separate H > would be beneficial. Every Cust typically has those internal political
 > challenges.   G Those very politics would also likely preclude runing both instances on F the same hardware because of hardware management issues.  Remember theH 1980s debates between departments who wanted autonomy from the "MIS data centre" ????   ------------------------------   End of INFO-VAX 2006.393 ************************                                                                                                                                                                                                                                                                                            