INFO-VAX Mon, 17 Sep 2007 Volume 2007 : Issue 507 Contents: best site for hacking tricks , computer tweak Re: despair Re: despair Re: despair Re: despair RE: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: despair Re: problem in TCPIP configuration Re: read DVD capacity code Re: TCP/IP tz88 - green-brick for BA350 shelf Re: VMS as hypervisor ? RE: VMS as hypervisor ? Re: VMS as hypervisor ? RE: VMS as hypervisor ? ---------------------------------------------------------------------- Date: Sun, 16 Sep 2007 11:47:40 -0700 From: "e.expelliarmus@yahoo.com" Subject: best site for hacking tricks , computer tweak Message-ID: <1189968460.241547.301200@22g2000hsm.googlegroups.com> check this out buddies... a kool site for anti hacking and hacking tips and tricks , computer tweaks to enhance ur pc,small virus creation ,etc.... it's the best site ... www.realm-of-tricks.blogspot.com ------------------------------ Date: Sun, 16 Sep 2007 13:56:31 -0700 From: "David P. Murphy" Subject: Re: despair Message-ID: <1189976191.317084.178250@22g2000hsm.googlegroups.com> On Sep 16, 8:39 am, AEF wrote: > I've been at my current job for 7 years and have been a VMS admin for > 13 years and have not had any problems like this. I don't write code > like this. I did inheret some code I wasn't happy with, and I fixed > what I could with what time I had (what I could get authorized by > management to do) and things have been okay. Let me clear this point: I am a little upset that this code was written, but I am much more upset that it has been in place for over ten years without being corrected. ok dpm ------------------------------ Date: Sun, 16 Sep 2007 14:00:27 -0700 From: "David P. Murphy" Subject: Re: despair Message-ID: <1189976427.971698.8390@y42g2000hsy.googlegroups.com> On Sep 16, 8:39 am, AEF wrote: > So you're there now, you've found a problem, so fix it > and be done with it!!! I am not authorized to fix code without an Incident Report, and no one _with_ authority will sign one, because (altogether now) "It works fine the way it is". Despair. ok dpm ------------------------------ Date: Sun, 16 Sep 2007 14:06:52 -0700 From: "David P. Murphy" Subject: Re: despair Message-ID: <1189976812.212156.220690@22g2000hsm.googlegroups.com> On Sep 16, 8:39 am, AEF wrote: > On Sep 15, 10:47 pm, "David P. Murphy" wrote: >> followed by the inevitable >> >> %SYSTEM-F-DEVMOUNT, device is already mounted >> >> and immediately thereafter >> >> %BACKUP-F-POSITERR, error positioning $1$MUA400:[000000]DAILY.BCK; >> -SYSTEM-F-SERIOUSEXCP, serious exception detected by TMSCP >> controller > AHA!!!!! Withholding evidence!!! Sloppy, sloppy, sloppy! And you > complain about the code author!!! ... HAH! > > This is like when Tom and Ray on Car Talk are trying to diagnose a > caller's car problems and after struggling for 5 minutes, the caller > finally mentions, "Oh, by the way, the engine check light came on" or > "It only does it when..." No, it's much more like getting dozens of errors from a compiler when they're all due to a single missing variable declaration. They're called "fallout errors", because they don't mean a damn and disappear once you fix the actual problem upstream . . . just like the BACKUP fatal messages are completely misleading and would not have occurred if the command procedure had properly handled either the failed ALLOCATE or INITIALIZE commands. In what way do you consider these messages "evidence"? The warning should have been enough for anyone. ok dpm ------------------------------ Date: Sun, 16 Sep 2007 14:03:05 -0700 From: "David P. Murphy" Subject: Re: despair Message-ID: <1189976585.575015.12940@19g2000hsx.googlegroups.com> On Sep 16, 8:39 am, AEF wrote: > So why don't you ask why the ALLOCATE command > only gives a W when it fails? In the second place, because Digital ^W Compaq ^W HP isn't going to change it. In the third place, even if they did, it wouldn't matter to most sites for a long time, so you'd still have to check for W anyway. And in the *first* place, because W is good enough, either an ON WARNING beforehand or testing $STATUS after. ok dpm ------------------------------ Date: Sun, 16 Sep 2007 17:36:29 -0500 From: "Paul Raulerson" Subject: RE: despair Message-ID: <001b01c7f8b2$066fdd10$134f9730$@com> > -----Original Message----- > From: David P. Murphy [mailto:dpm_google@myths.com] > Sent: Sunday, September 16, 2007 3:57 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: despair > > On Sep 16, 8:39 am, AEF wrote: > > > I've been at my current job for 7 years and have been a VMS admin for > > 13 years and have not had any problems like this. I don't write code > > like this. I did inheret some code I wasn't happy with, and I fixed > > what I could with what time I had (what I could get authorized by > > management to do) and things have been okay. > > Let me clear this point: I am a little upset that this code was > written, but I am much more upset that it has been in place for > over ten years without being corrected. > > ok > dpm It's a little wasteful to expend effort being irritated with that. You should see some of the legacy stuff from Mainframes. Stuff going back to 1964/1965 in some cases, and with the source lost for a couple decades or so. ;) VMS is nice... :) -Paul ------------------------------ Date: Sun, 16 Sep 2007 20:38:40 -0500 From: David J Dachtera Subject: Re: despair Message-ID: <46EDDAA0.C2022C4C@spam.comcast.net> "David P. Murphy" wrote: > > Real code at the beginning of the "daily backup" batch job: > > $ ON ERROR THEN CONTINUE > $ ALLOCATE 'tape_drive' > $ INIT 'tape_drive' 'label' > $ BACKUP/IMAGE/REWIND/'quals' - > 'disk' - > 'tape_drive'DAILY.BCK/SAVE > > I have lost what little faith in humanity remained in me. I wouldn't abandon hope just yet. Maybe a forehead slap would be in order, though ... or handful of headache pills... It's possible, given the way some folks think, that the missing pieces may be provided in the (BACKUP) account's LGICMD, or may be acquired through some other magic. I've seen enough "goofy stuff" that such things make me say, "Uh-oh!" and then go hunting for possible sources of the missing pieces. Some folks groove to make life interesting... -- 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: Sun, 16 Sep 2007 18:49:17 -0700 From: "David P. Murphy" Subject: Re: despair Message-ID: <1189993757.781982.92350@n39g2000hsh.googlegroups.com> On Sep 15, 11:29 pm, Ron Johnson wrote: > However... why shouldn't I rely on LOGINOUT.EXE to deallocate my > tape drives or free my VM? #1 Why _shouldn't_ you close/deallocate/free/release a resource explicitly? There is no good reason. #2 What if another, less experienced, programmer decides to copy your code? He won't realize that you're relying on LOGINOUT. #3 My first reason is so good that I'm going to repeat it. In fact I'm trying sincerely to think of any justification at all for skipping that code, and I cannot. ok dpm ------------------------------ Date: Sun, 16 Sep 2007 19:02:24 -0700 From: AEF Subject: Re: despair Message-ID: <1189994544.164306.62440@o80g2000hse.googlegroups.com> On Sep 16, 4:56 pm, "David P. Murphy" wrote: > On Sep 16, 8:39 am, AEF wrote: > > > I've been at my current job for 7 years and have been a VMS admin for > > 13 years and have not had any problems like this. I don't write code > > like this. I did inheret some code I wasn't happy with, and I fixed > > what I could with what time I had (what I could get authorized by > > management to do) and things have been okay. > > Let me clear this point: I am a little upset that this code was > written, but I am much more upset that it has been in place for > over ten years without being corrected. > > ok > dpm Management is often hesitant to change anything. "If it ain't broke, don't fix it!" Well, you still have to do your periodic oil changes and inspections. And of course, sometimes it is "broke" even if things have been running smoothly for a while. Two jobs ago I was finding problems and struggling for permission to fix them. One was a DCL code snippet that one of the handover admins added at the last minute thinking he missed an iteration of calculating what day monthly reports should be scheduled for. I analyzed it and told mgmt that the next time such and such falls on a Tuesday (I think such and such was the first of the month) a repeat of the near disaster I saved us from from home at the last minute on a previous occasion would occur: the flaw would start report jobs before the "run commit" had finished or something like that (I don't presently recall the details), which would of course corrupt the database, resulting in the need to do a shift-long restore from 8mm tapes. I was told to leave it alone. Finally, several months later, when it was getting close to the "doomsday month", I said such and such will do so and so next month. Will you please let me fix it? Mgmt. then said yes. Our client was safe again. [The handover admins -- who were actually also the previous admins -- told us that the admins prior to them told them it was too complicated to automate the report jobs and Run Commits and such. I guess they took this as a challenge and, well, missed a few things here and there that would only crop up later at unexpected times. Hence the illusion of "working system" I mention below.] I remember when starting this same job mgmt told me "You're getting a working system. Don't mess with it." (My title _was_ senior operator, but I did know _some_ system manager stuff at the time.) Well, I had to several times to save the day and prevent other fires. Another time the header of INDEXF.SYS filled up on an a certain critical non- database non-system disk. I was there at 6:30 in the morning by myself and I was able to determine that the system couldn't be opened for the end users at 7:00 a.m. because of this. I couldn't reach mgmt or the handover admins (who were training us on the system and app). So on my own initiative I copied it to tape and back. It took a long time, but it worked. While the restore was going, I was told I shouldn't have done that. I said I had no choice and I was sure it would fix the problem. (Well, I _did_ "cross my fingers"!) The restore completed, the app worked fine, and I had saved the day. One of the handover admins told me that whenever that happened they would archive some invoices. Well, I was very new to the job and didn't know about that manual task yet. I didn't know which files were "expendable" or archive-able. So I did what I thought was best. The handover admins who used to run the system apparently didn't know how to fix the dreaded HEADERFULL problem for good. (I've never had a "repacked" disk experience a subsequent HEADERFULL event.) One job ago I was pretty much given a free hand on most things but the boss insisted that the VAX be rebooted every Friday evening before the backups were run!!! He was very insistent and must have thought that disaster would strike if the VAX wasn't rebooted every week. They had always done that, I think, and were afraid to stop (this was before Windows took over the desktop at this place). I was told that this was something carried over from something with their IBM mainframe. I don't recall any more details. In fact, the head operator said once that he was worried no one could reboot the machine during Christmas week. I said, look, it doesn't matter. It doesn't have to be rebooted. I won't tell anyone. No one will know. It'll be fine. I said if the operator wants the time off, fine. If he wants to come in to reboot it to make some overtime, fine. I forget which happened, but I know at least once it didn't get rebooted and I finally had an uptime of over 7 days. Of course nothing bad happened because of it. There are probably more similar stories I can't think of offhand. I feel your pain! BREAKING NEWS!!! or FOX NEWS ALERT!!! (imagine the FOX Gong here): I just thought of another disaster I saved at the two-jobs-ago job! Later, I've got to get back to other things. But I'll say at this point that it involved tape drives!!! And it was a fascinating time- bomb bug!!! Before you go blaming me for all these problems: ***I didn't write the code. I inherited it!*** OK? Back to a Paul Lynde question. AEF ------------------------------ Date: Sun, 16 Sep 2007 19:04:28 -0700 From: AEF Subject: Re: despair Message-ID: <1189994668.866554.151640@n39g2000hsh.googlegroups.com> On Sep 16, 5:00 pm, "David P. Murphy" wrote: > On Sep 16, 8:39 am, AEF wrote: > > > So you're there now, you've found a problem, so fix it > > and be done with it!!! > > I am not authorized to fix code without an Incident Report, > and no one _with_ authority will sign one, because > (altogether now) "It works fine the way it is". Been there, done that, more than once, as you can see from my last post. So please excuse me if I'm a little numb to the phenomenon. > Despair. Yeah, well... > > ok > dpm AEF ------------------------------ Date: Sun, 16 Sep 2007 19:26:51 -0700 From: AEF Subject: Re: despair Message-ID: <1189996011.648131.314640@19g2000hsx.googlegroups.com> On Sep 16, 9:49 pm, "David P. Murphy" wrote: > On Sep 15, 11:29 pm, Ron Johnson wrote: > > > However... why shouldn't I rely on LOGINOUT.EXE to deallocate my > > tape drives or free my VM? > > #1 Why _shouldn't_ you close/deallocate/free/release a resource > explicitly? There is no good reason. > > #2 What if another, less experienced, programmer decides to copy > your code? He won't realize that you're relying on LOGINOUT. (1) Comment your code!!! (2) Caveat emptor. You can't be expected to save the world. You can't be responsible for every possible misuse of your code. If a knife is used to murder someone, is the knife manufacturer responsible? (3) The inexperienced programmer will most likely screw something else up that's even worse anyway. > > #3 My first reason is so good that I'm going to repeat it. > In fact I'm trying sincerely to think of any justification > at all for skipping that code, and I cannot. Your going to miss your train if you don't skip it and the next train isn't for three hours. :-) > > ok > dpm AEF ------------------------------ Date: Sun, 16 Sep 2007 19:35:59 -0700 From: AEF Subject: Re: despair Message-ID: <1189996559.886364.126960@k79g2000hse.googlegroups.com> On Sep 16, 5:03 pm, "David P. Murphy" wrote: > On Sep 16, 8:39 am, AEF wrote: > > > So why don't you ask why the ALLOCATE command > > only gives a W when it fails? > > In the second place, because Digital ^W Compaq ^W HP > isn't going to change it. In the third place, even You're "buddy" isn't going to change your bad code snippet either. And now we know even you aren't going to change it due to mgmt. > if they did, it wouldn't matter to most sites for a > long time, so you'd still have to check for W anyway. > > And in the *first* place, because W is good enough, > either an ON WARNING beforehand or testing $STATUS after. > > ok > dpm What about the fact that $ DIR/VERS=2 file takes long enough to find, but not displya, all n versions, not just the first two? What about another resource waster: $ DIR:==DIR/DATE/SIZE/PROT $ DIR/TOTAL blah $ DIRECTORY/TOTAL blah Assuming DIRECTORY is not a symbol, if you time the two TOTAL commands, you'll see that the former takes a lot longer to run than the latter. Hey, as great as VMS is, it isn't perfect. And I think failure to allocate should AT LEAST be an E error. It clearly didn't do what you asked at all. How could that not be an error? A warning is for when what you asked was done, but something there's something you may not have expected that may or may not be a problem happened and you are being WARNED about it. I think the line between E and F is somewhat blurrier. [Maybe some of these were fixed since VMS V6.2.] AEF ------------------------------ Date: Sun, 16 Sep 2007 19:41:31 -0700 From: AEF Subject: Re: despair Message-ID: <1189996891.522844.254280@57g2000hsv.googlegroups.com> On Sep 16, 5:06 pm, "David P. Murphy" wrote: > On Sep 16, 8:39 am, AEF wrote: > > > > > On Sep 15, 10:47 pm, "David P. Murphy" wrote: > >> followed by the inevitable > > >> %SYSTEM-F-DEVMOUNT, device is already mounted > > >> and immediately thereafter > > >> %BACKUP-F-POSITERR, error positioning $1$MUA400:[000000]DAILY.BCK; > >> -SYSTEM-F-SERIOUSEXCP, serious exception detected by TMSCP > >> controller > > AHA!!!!! Withholding evidence!!! Sloppy, sloppy, sloppy! And you > > complain about the code author!!! ... HAH! > > > This is like when Tom and Ray on Car Talk are trying to diagnose a > > caller's car problems and after struggling for 5 minutes, the caller > > finally mentions, "Oh, by the way, the engine check light came on" or > > "It only does it when..." > > No, it's much more like getting dozens of errors from a compiler > when they're all due to a single missing variable declaration. > They're called "fallout errors", because they don't mean a damn > and disappear once you fix the actual problem upstream . . . > just like the BACKUP fatal messages are completely misleading > and would not have occurred if the command procedure had properly > handled either the failed ALLOCATE or INITIALIZE commands. > > In what way do you consider these messages "evidence"? The warning > should have been enough for anyone. I meant the totality of the error messages as evidence. I was saying that no one else puts tapes in the machine, probably things will run more or less okay -- at least not disasterously. Only LATER do you show that there was an actual resultant problem. That's all I meant. I mean, my whole point is that context matters. Are you running a nuclear power plant or playing stupid video games? When I have some time at work I'll check the sequence of events you report on my test box. > ok > dpm AEF ------------------------------ Date: Sun, 16 Sep 2007 18:13:36 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: problem in TCPIP configuration Message-ID: In article <93269$46ed6cb9$cef8887a$19605@TEKSAVVY.COM>, JF Mezei writes: > Does your VMS host have its onw DNS server, or is it just a client ? Just a client. > If you are using DHCP No, no DHCP on the VMS side. > If you have a fixed config (SET NAME /SERVER= ) remember that you may > need to restart some/all applications that use TCPIP so that they get > the new definitions. Indeed, but I would have thought that restarting all of TCPIP would do the trick. Things seem to work now. Depending on the node, there is a delay after which they just start working. Is the list of name servers checked in a particular order until one responds? If so, what is that order? ------------------------------ Date: Sun, 16 Sep 2007 20:43:05 -0500 From: David J Dachtera Subject: Re: read DVD capacity code Message-ID: <46EDDBA9.FBE9548B@spam.comcast.net> Eberhard Heuser wrote: > > Hi, > > Here's the code. Far from being perfect, but at least a starting point. > > If you have built the executable, define the symbol dvdcap: > > $ dvdcap:==$dvdcap.exe > > Usage: > $ dvdcap DVD-drive: > > The result is stored in the symbol DISCCAP: > > $ dvdcap:==$DSA3:[DVDWRITE_V10.V6_6-1.READ_CAPACITY]dvdcap.exe > $ dvdcap dqa0: > Accessing target "DQA0:" Result: OK > DVD read capacity Version 1.00 > Medium capacity: 9180416 blocks. > $ sh symbol disccap > DISCCAP = "9180416" > [snip] I've put the source and Alpha and IA64 .OLBs in a kit on my freeware site: http://www.djesys.com/freeware/vms/ as http://www.djesys.com/freeware/vms/dvdcap.zip DCL proc.'s to build from source and LINK from .OLBs are provided. The BUILD.COM builds .OLBs for both .EXE's (non-debug and debug), then it invokes the LINK.COM to produce the .EXEs. I was only able to test that the compile and LINKs go through cleanly. I lack facilities to test Eberhard's code any further. I also do not have a VAX running at present. -- 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: Sun, 16 Sep 2007 20:58:02 -0500 From: David J Dachtera Subject: Re: TCP/IP Message-ID: <46EDDF2A.31D97C73@spam.comcast.net> David Goodwin wrote: > > In a few days I will finally get my hands on a machine to learn > OpenVMS on (an AlphaServer 1200). Before then I must figure out what > TCP/IP stack to use. I know almost nothing about any of them and dont > know very much about how to use OpenVMS in general. > > Multinet and TCPware seem to be made by the same company and their > website pages seem almost identical. I assume there must be some major > difference between them - I dont see any reason why one company would > make two seemingly identical products for the same platform. > > Could anyone tell me which TCP/IP stack I want to use and what are the > major differences between them? Well, Process Software's products are bit more straight-forward to manage, though the management interface takes a bit of learning. The code is functional and robust and provides 100% compatibility with .EXEs LINKed against the UCX libraries. UCX (now known as "TCP/IP Services for OpenVMS" - hence the preference for the shorter, if older, name) has rather a bizarre management interface and is really intended to be more consistent with the UN*X approach to management of the IP stack. UCX also has a major "gotcha": when multiple interfaces are assigned to the same subnet the loss of any one interface will render the entire subnet unusable. This is due to a UCX feature where in it "round robins" the outgoing traffic among the available interfaces on a subnet. This feature cannot be defeated, and although most folks recommend "failSAFE-IP" as a remedy, this does not work because UCX cannot properly detect connectivity failure above the physical layer. Performance wise, ... PSC's products still use Direct I/O for the network. Hence, each network I/O generates an interrupt. This can result in CPU saturation in extreme cases, mostly with huge databases and other applications with tens of thousands of active connections. UCX uses Buffered I/O for the network resulting in more CPU time being available in User Mode; hence, more actual work gets done than when the CPUs are busy performing interrupt service. It depends on what you need: raw performance or manageability and functionality. Tough call, at best. -- 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: Mon, 17 Sep 2007 02:36:31 GMT From: Michael Austin Subject: tz88 - green-brick for BA350 shelf Message-ID: Does any one have one of these old devices they want to get rid of - cheaply? I have one that flashes all lights on the front after a power glitch. I had 2 in this shelf - and luckily only one of them got hit. I have tried re-seating and following the instructions to clear the error, but it looks like it is toast. Or if you just have the drive - I am sure my former DEC FS skills can take care of placing it into the canister. Michael Austin my address in the from: field is obviously bogus. m a u s t i n AT f i r s t d b a s o u r c e DOT c o m ------------------------------ Date: 16 Sep 2007 13:58:05 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: VMS as hypervisor ? Message-ID: In article <46ED540F.3040006@comcast.net>, "Richard B. Gilbert" writes: > Larry Kilgallen wrote: >> In article , Ron Johnson writes: >>>In the Linux world, the only answers I can think of are: >> >> >>>(b) Upgrading one app might require an upgrade to, for example, >>> libc. That would entail certifying all of the (possibly many >>> apps on the box. With VMs, only that one VM would need libc6 >>> upgraded and so only that single app would need to be certified. >> >> >> That applies for VMS as well, if you need two different versions of >> VMS and prefer to have only one hardware box. > > When did this happen? It used to be that images linked on a VAX ca. > 1978/79 would run without problems on any later version. That is the plan, but sometimes it does not work out that way. Try switching volumes in an ISO 9660 volume set. If the machine crashes, you are not running Alpha VMS V6.1. > Now if you have third party software, the vendor might not it support it > on all versions of VMS but it should still WORK on the version it was > built on and all later versions unless someone is doing something very > strange. Like reading ISO 9660 volume sets ? ------------------------------ Date: Sun, 16 Sep 2007 19:00:09 +0000 From: "Main, Kerry" Subject: RE: VMS as hypervisor ? Message-ID: > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: September 16, 2007 1:55 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS as hypervisor ? > > Richard B. Gilbert wrote: > > Now if you have third party software, the vendor might not it support > it > > on all versions of VMS but it should still WORK on the version it > was > > built on and all later versions unless someone is doing something > very > > strange. > > There are many types of applications (think heavy duty financial stuff) > which a bank will absolutely not run an on unsupported platform. They > need 100% support from the vendor and no reason for any excuses for the > vendor not to provide a fix to a problem within 10 minutes of the app > going down. JF, While I certainly do not disagree with you, keep in mind that Microsoft doe= s not support any of its applications running in a VMware environment and the popularity = of VMware for Windows/Linux has still gone through the roof. And financial institutio= ns are heavy, heavy VMware users. 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: Sun, 16 Sep 2007 14:42:00 -0500 From: Ron Johnson Subject: Re: VMS as hypervisor ? Message-ID: On 09/16/07 14:00, Main, Kerry wrote: [snip] > > While I certainly do not disagree with you, keep in mind that Microsoft does not support > any of its applications running in a VMware environment and the popularity of VMware > for Windows/Linux has still gone through the roof. And financial institutions are > heavy, heavy VMware users. How much of Banks' "real" data is on Windows, and how much is on IBM and Unisys mainframes? -- 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: Sun, 16 Sep 2007 22:57:37 +0000 From: "Main, Kerry" Subject: RE: VMS as hypervisor ? Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: September 16, 2007 3:42 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: VMS as hypervisor ? > > On 09/16/07 14:00, Main, Kerry wrote: > [snip] > > > > While I certainly do not disagree with you, keep in mind that > Microsoft does not support > > any of its applications running in a VMware environment and the > popularity of VMware > > for Windows/Linux has still gone through the roof. And financial > institutions are > > heavy, heavy VMware users. > > How much of Banks' "real" data is on Windows, and how much is on IBM > and Unisys mainframes? > > -- > 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! Don't know. Even though a lot of bank back end stuff is also on OpenVMS, I = suspect most banks do not even know themselves the % of app's per OS platform. Most= do not even have a complete list of all their applications - let alone what OS pla= tform they are running on. Even though it might seem strange, banks are not real good examples of how = one should be managing their IT environment. At one large bank on West coast of USA, we did consolidation / DC study tha= t had approx 6600 servers in 4 main sites. In total, they had approx 500 servers= where they not only did not know what App's they were running, but they could not even= identify the BU owners. I have done a few other financial / bank engagements as well - while they w= ere better than the West coast engagement, they still had many asset mgmt issues as we= ll. Btw, even though they have many regulatory, security and audit type pressur= es, Banks are just as susceptible to the many hype bugs floating around these days as oth= er companies. To their credit, some banks are trying to re-gain control of their IT envir= onment by consolidating Linux/UNIX environments to more centralized mainframe style e= nvironments. 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. ------------------------------ End of INFO-VAX 2007.507 ************************