INFO-VAX Sun, 01 Jul 2007 Volume 2007 : Issue 356 Contents: Re: EVA/ Itanium question Re: expanding shadow size Re: gSOAP on OpenVMS? VMS as Web Service *client* Re: OpenVMS - When downtime is not an option Re: OpenVMS - When downtime is not an option RE: Question to Kerry Main Re: Question to Kerry Main Re: Question to Kerry Main Re: Question to Kerry Main RE: SOA and VMS stuff Re: SOA and VMS stuff Re: SSH newbie question TCPIP$GET_MX: getmxrr() failed Re: TCPIP$GET_MX: getmxrr() failed ---------------------------------------------------------------------- Date: Sun, 01 Jul 2007 09:25:18 -0700 From: "Don.Zong@gmail.com" Subject: Re: EVA/ Itanium question Message-ID: <1183307118.230019.165560@q69g2000hsb.googlegroups.com> On Jul 1, 1:02 am, Baxt...@tessco.com wrote: > On Jun 26, 2:02 pm, "Don.Z...@gmail.com" wrote: > > > we have a system disk on eva say $1$dga21, now we snapcloned the > > system disk say $1$dga22, and we would like to test $1$dga22, can we > > just change the lun assignment $1$dga22 to $1$dga21, and boot the > > server as it usually does, is that simple? is there anything we need > > to change on EFI side ie re-config boot options etc ? > > when you look at your existing boot disk, and your new disk, in the > EFI shell, device mapping, to they appear the same except for the disk > unit number and the filesystem assignment (e.g. fs1:) ?? > > if they answer is yes, then I don't see any reason why it wouldn't > work. If the answer is no, then you might still give it a try (what > do you have to lose except 5 minutes for the attempt.) In the end > you might still need to run the "BOOT_OPTIONS" script. > > I am new to Itanium too, so my answer might be a load of dung > anyway. I would be interested to hear what the result is anyway. > > Dave. Just finished my upgrade. Changing LUN number works without EFI reconfiguration. Thanks for all the inputs ! ------------------------------ Date: Sun, 01 Jul 2007 03:41:52 -0700 From: Bob Gezelter Subject: Re: expanding shadow size Message-ID: <1183286512.476461.48610@n2g2000hse.googlegroups.com> David J Dachtera wrote: > Bob Gezelter wrote: > > > > On Jun 29, 8:55 pm, David J Dachtera > > wrote: > > > "Klaus-D. Bohn" wrote: > > > > > > > Hello all together, > > > > > > > I have an existing problem with a shadow disk. I would like to increase the > > > > shadow size without to dismount all the shadow members. > > > > [snip] > > > > What must i do to get the full volume size 17773524? > > > > > > As Hoff pointed out, can't be done without downtime. > > > > > > You'll need to negotiate a scheduled downtime with your customer. Be sure to > > > explain that this is necessary if they want to realize the desired benefit. > > > > David, > > > > A small note on the comment about downtime. > > > > If all that is needed is the SET VOLUME/LIMIT command, it is almost > > wrong to call it downtime. Planned properly (and executed with a > > command file) the downtime is limited to the availability of that > > volume for a matter of seconds. It will take longer to restart those > > applications that cannot quiesce and reacquire a file than it will > > take to do the actual change. It is, in my experience, far shorter > > than even a reboot (and if this is a data disk and not involved in the > > actual running of the cluster) will not be needed. > > > > It is true that even such a "blip" is a downtime, and needs to be > > handled appropriately, but there is a large difference between such a > > "blip" and a multi-hour downtime. Indeed, depending on what data is > > involved, it may not even meet the organization's definition of > > critical information, at least on the scale of a few minutes. > > > > Just my US$ 0.02 to ensure a clean record of the discussion. > > Well, it's generally considered that "downtime" means the application is not > available to the users, regardless of the cause. > > Large applications - and their underlying software infrastructure (databases, > etc.) can, indeed, impose extensive periods of unavailability just to allow a > single volume to be DISMOUNTed, MOUNTed privately, prepared for DVE, then > DISMOUNTed and reMOUNTed back to the system so that the software layers can be > restarted in the proper order. In my case, at work, it's two(2) hours, minimum. > > The OP simply stated that his client is downtime averse in that they will not > allow the steps needed to permit this. > > Hence, my comment, as it was. > > -- > 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/ David, Indeed. I have seen many systems where the minimum interruption is measured in hours. Then again, I have seen many environments, where that is not true. I have also seen many environments where the question is nuanced, in terms of which data is being spoken of. I posted the comment not to belittle the downtime issue but to emphasize the importance of treating it as a quantitative, not a qualitative question. When I am involved in design or modification of a system, I generally try to reduce the need for interruptions, and the impact of the inevitable disruptions that do occur, but I digress. Herr Bohn's original request does indeed refer to the fact that his client is downtime adverse, but I do not see any detailed background information upon which to judge the question of what degree of sensitivity this particular disk volume has. Thus my comment about the "blip" versus "downtime". IMHO, there is a significant difference between a blip on the order of seconds, done under the control of a script that once initiated, dismounts the volume, remounts the volume as private, does the needed SET VOLUME command, dismounts the volume, and remounts the volume to the cluster; and a multi-hour operation using BACKUP to save and restore the contents. Also note that since the MOUNTs are orderly (each following a controlled DISMOUNT rather than a crash), there will not be an extensive delay while rebuilding the data structures. Have I seen this situation in production environments that must otherwise maintain 24x7 availability: YES. An example is archives of online bills and statements. They frequently grow on an ongoing basis. However, they often do not grow on a minute to minute basis. It is often possible to prevent additions to the volume, interrupt access to the archive, and then re-allow access to the archive without ever having even interrupted the 24x7 parts of the application. In the end analysis, it is important to understand (and even more important to research in detail) each situation. I have seen far too many sites where the unverified presumption has been that if a volume is mounted at startup, it must be available continuously, forever. - Bob Gezelter, http://www.rlgsc.com ------------------------------ Date: 1 Jul 2007 14:06:36 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: gSOAP on OpenVMS? VMS as Web Service *client* Message-ID: <5epqncF38tqmfU2@mid.individual.net> In article <468717cc$0$90266$14726298@news.sunsite.dk>, Arne Vajhøj writes: > JF Mezei wrote: >> Malcolm Dunnett wrote: >>>> Same here. I currently do SOAP client >> >> We don't really to know what you do to your clients :-) >> >> I use SOAP in the shower every morning though :-) > > You don't capitalize all letters in that SOAP. Of course you do. People here have long said that mixed case is not necessary. That's why VMS only has uppercase. :-) 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: Sun, 01 Jul 2007 03:16:11 -0400 From: Bill Todd Subject: Re: OpenVMS - When downtime is not an option Message-ID: Paul Raulerson wrote: > The only answer to this is that anyone who believes it *is* only half > competent. Sorry: the answer is that anyone who believes your position in this matter is ignorant (and thereby incompetent, since the competent understand the limitations of their knowledge). It is very VERY important to keep patches up to date on the > Window server(s). The vast majority of the harmful and expensive virii, > Trojans, and worms that get in get in via the server. Then you're using it incompetently. > E-Mail, Please explain exactly how a virus, trojan, or worn can infect a server via any legitimate use of email on that server. Do you run email in an account without restricted privileges? That's incompetent. Do you allow execution of scripts, ActiveX, or even html in email on a server? That's incompetent. Do your users execute attachments without being sure where they came from? That's incompetent in a server environment even if you've already subjected the attachment to a virus/malware scan (the lack of which would also of course be incompetent). Using Microsoft email rather than a potentially safer alternative (which, incidentally, you can patch to your heart's content without fear of side-effects in other areas of your server) might be considered incompetent, for that matter. Similar comments apply to using Internet Exploder, for which virtually the only required use is during interactive Microsoft Update activity (though a well-managed server environment will instead collect the updates and then apply them locally rather than interactively in WU, eliminating the need to run IE in a privileged context): your server firewall shouldn't let IE talk to the outside world at all (in *or* out) without interactive user permission, and when such external interaction is allowed no script execution should be permitted without interactive user permission (and one can make a reasonable case for not allowing ActiveX execution under any circumstances: if you could get alone without it with a non-Windows alternative, why would you need it?). It's not clear why any other interactive browser use would require privileges either (not that general surfing is an appropriate server activity in any event) - and people who can't be trusted to use such resources appropriately can't be trusted with privileged accounts (though gentle reminders never hurt - e.g., eliminating privileged account browser and email access icons such that a user has to make an active effort to run a browser or email in such an account). In fact, the threat of infection even in a privileged account running completely unpatched software is minimal as long as browser and email components are buttoned down as described above and used responsibly (e.g., any threat from malicious Web sites is minimal, because there's no justification for encountering one in the normal course of server management), and when such applications run almost exclusively in non-privileged accounts the threat virtually disappears. > SQL Server, > IIS, Those are layered products: if they don't meet your safety criteria, use the alternatives that you'd use on a different OS (since most of them will run on Windows as well - and, again, you can patch them without fear that the patches will have unforeseen side-effects elsewhere in your server). etc. And yes, it is fact, for *whatever* reason, that the VAST majority > of Windows Server time is spent putting in patches and fixes and working > HooDoo on the Registry. Unless that registry twiddling is directly related to applying *necessary* patches it's irrelevant to the current discussion. Perhaps you're confusing the general overhead of managing a Windows environment (where I'd heartily agree that other platforms can be more cost-effective in terms of managerial overhead) with the very specific allegation that inability to secure the platform and/or the volume of Windows patches make Windows an untenable server choice. I just took a quick look back through our past 3 months' worth of Win2K patches, and couldn't find a single one that seemed of immediate importance to apply to a properly-managed, buttoned-down server. Some exposures required local log-on and explicitly running specially-crafted malware (or in one case running image software to view a corrupted EMF image file) to leverage. Others required a visit to a malicious Web page and running scripts there, resulting at worst in denial of service or the ability to run malicious software in the (appropriately restricted) privilege context of the current user. None involved any external threat that could not be parried by the kind of sensible procedures described above until such time as it might be convenient to apply a specific patch. > > Does not mean Windows is not deucedly useful though. > > Would you care to rethink your statement? Surely you could NOT have meant to > say what you actually said. As usual, I meant *exactly* what I said. - bill ------------------------------ Date: 1 Jul 2007 14:04:12 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: OpenVMS - When downtime is not an option Message-ID: <5epqirF38tqmfU1@mid.individual.net> In article , Bill Todd writes: > Paul Raulerson wrote: >> The only answer to this is that anyone who believes it *is* only half >> competent. > > Sorry: the answer is that anyone who believes your position in this > matter is ignorant (and thereby incompetent, since the competent > understand the limitations of their knowledge). > > It is very VERY important to keep patches up to date on the >> Window server(s). The vast majority of the harmful and expensive virii, >> Trojans, and worms that get in get in via the server. > > Then you're using it incompetently. > >> E-Mail, > > Please explain exactly how a virus, trojan, or worn can infect a server > via any legitimate use of email on that server. Do you run email in an > account without restricted privileges? That's incompetent. Do you > allow execution of scripts, ActiveX, or even html in email on a server? > That's incompetent. Do your users execute attachments without being > sure where they came from? That's incompetent in a server environment > even if you've already subjected the attachment to a virus/malware scan > (the lack of which would also of course be incompetent). Using > Microsoft email rather than a potentially safer alternative (which, > incidentally, you can patch to your heart's content without fear of > side-effects in other areas of your server) might be considered > incompetent, for that matter. > > Similar comments apply to using Internet Exploder, for which virtually > the only required use is during interactive Microsoft Update activity > (though a well-managed server environment will instead collect the > updates and then apply them locally rather than interactively in WU, > eliminating the need to run IE in a privileged context): your server > firewall shouldn't let IE talk to the outside world at all (in *or* out) > without interactive user permission, and when such external interaction > is allowed no script execution should be permitted without interactive > user permission (and one can make a reasonable case for not allowing > ActiveX execution under any circumstances: if you could get alone > without it with a non-Windows alternative, why would you need it?). > > It's not clear why any other interactive browser use would require > privileges either (not that general surfing is an appropriate server > activity in any event) - and people who can't be trusted to use such > resources appropriately can't be trusted with privileged accounts > (though gentle reminders never hurt - e.g., eliminating privileged > account browser and email access icons such that a user has to make an > active effort to run a browser or email in such an account). In fact, > the threat of infection even in a privileged account running completely > unpatched software is minimal as long as browser and email components > are buttoned down as described above and used responsibly (e.g., any > threat from malicious Web sites is minimal, because there's no > justification for encountering one in the normal course of server > management), and when such applications run almost exclusively in > non-privileged accounts the threat virtually disappears. > >> SQL Server, >> IIS, > > Those are layered products: if they don't meet your safety criteria, > use the alternatives that you'd use on a different OS (since most of > them will run on Windows as well - and, again, you can patch them > without fear that the patches will have unforeseen side-effects > elsewhere in your server). > > etc. And yes, it is fact, for *whatever* reason, that the VAST majority >> of Windows Server time is spent putting in patches and fixes and working >> HooDoo on the Registry. > > Unless that registry twiddling is directly related to applying > *necessary* patches it's irrelevant to the current discussion. Perhaps > you're confusing the general overhead of managing a Windows environment > (where I'd heartily agree that other platforms can be more > cost-effective in terms of managerial overhead) with the very specific > allegation that inability to secure the platform and/or the volume of > Windows patches make Windows an untenable server choice. > > I just took a quick look back through our past 3 months' worth of Win2K > patches, and couldn't find a single one that seemed of immediate > importance to apply to a properly-managed, buttoned-down server. Some > exposures required local log-on and explicitly running specially-crafted > malware (or in one case running image software to view a corrupted EMF > image file) to leverage. Others required a visit to a malicious Web > page and running scripts there, resulting at worst in denial of service > or the ability to run malicious software in the (appropriately > restricted) privilege context of the current user. None involved any > external threat that could not be parried by the kind of sensible > procedures described above until such time as it might be convenient to > apply a specific patch. > >> >> Does not mean Windows is not deucedly useful though. >> >> Would you care to rethink your statement? Surely you could NOT have meant to >> say what you actually said. > > As usual, I meant *exactly* what I said. I hope this doesn't give anyone a heart attack or anything but even given our differences of opinion in the past this is one time you and I are totally in agreement. Could this signal the arrival of the final times? :-) 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: Sun, 1 Jul 2007 08:51:49 -0400 From: "Main, Kerry" Subject: RE: Question to Kerry Main Message-ID: > -----Original Message----- > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > Sent: June 30, 2007 8:31 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Question to Kerry Main >=20 > Mr Main, your arguments on c.o.v. are often rebutted as part of normal > debating process. (And you rebutt other arguments with your own > responses). >=20 > In real life, do you also find customers and potential customers > having > similar questions ? Or do you conclude that we, in c.o.v. are a > sepcial > bunch living in a totally different universe without a clue of what is > happening in real life ? Those who participate in c.o.v. have passionate beliefs in OpenVMS or they would not be participating.=20 Hence, while I certainly do not agree with everything that happens or is stated here, I do believe the passion is a good thing.=20 Customers in real life are c.o.v. readers, and likewise there is a wide variety of personalities. All are very passionate about what they believe is the future. As an example, almost everyone in a Cust's IT organization typically has a view of how the future will unfold and that is no different than c.o.v. Hence, Cust's go through some of the bitter battles discussed here as well. "Windows is the future!", "Linux is the future!", "We can't deal with viruses and patches, we need stability and security like OpenVMS!", "Mainframe stability is what we need"...A good deal of this hype is also driven by outside consultants brought in for their technical experience which often means they promote what they know. Having stated this, the industry IT technologies and business drivers are constantly changing, so trying to determine where the future lies based on what happened last week or 5 years ago is a bit like trying to determine the weather 2 weeks from now. My $.02 is that if you look at general trends, and have a good understanding of what worked well in the past and what did not, then you have a better chance of understanding where the future lies for your company. Something else to consider on the changing drivers -=20 The industry went distributed computing because of BU's viewing central IT as not being responsive and CPU / network technologies not being able to handle all the loads and bandwidth. This was when Windows was at its peak as Windows is a pretty good distributed system (low cost, pt-click gui and off the shelf apps, local admin can just reboot it if it does not seem to be working and only a few are impacted).=20 However, the one app-many distributed server (prod/dev/test for each app env) model as emerged as being very difficult and very expensive to manage from an overall company perspective, so, as IT costs are being drastically cut, the BU's are again giving up control back to central IT - the consolidation stuff you read about. Part of the justification for this is that network costs have dropped through the floor and reliability is much better than the past, hence the network is not the issue it used to be. In addition, there is huge processing capacity available with todays servers, so it makes sense to make better use of these. Another driver is the sophistication of hackers, bots, virus, Trojan and worm challenges are exponentially higher today because of laptops, PDA's, memory sticks etc that were not as big a deal 5-10 years ago. Hence, while the BU's and local App developers ruled the roost in the distributed days, the industry is shifting back to centralized computing. Much lower costs using standards, reliability and stability is the new marching orders. Hence, imho, this makes centralized computing (albeit with central IT being much better plugged into BU's requirements) the model for the future.=20 Question - Are Windows and Linux good platforms for centralized computing?=20 I would say no, but I am sure there are many who would disagree with me, but that's fine - to each their own. I also know there will always be some exceptions in terms of a specific type of application being delivered centrally via Windows or Linux (aka google stuff), but these are not typical heavy lifting business driven app's that have huge batch environments. Google is also not under any pressure that I can see to drastically reduce IT costs either. Long winded response, but yes Cust's have the same passion as c.o.v. in terms of futures and directions the same issues get beat up in their meeting room environments as well. What happens on c.o.v. is a microism of the real world business environment. The real business world is actually exponentially worse. Can you imagine if we had passionate Linux vs Windows vs UNIX discussions on c.o.v. as well as the OpenVMS discussions? Now that would be an interesting newsgroup ... course, the signal to noise ratio would go through the roof. :-) Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sun, 01 Jul 2007 10:42:15 -0400 From: Stephen Hoffman Subject: Re: Question to Kerry Main Message-ID: JF Mezei wrote: > In real life, do you also find customers and potential customers having > similar questions ? Or do you conclude that we, in c.o.v. are a sepcial > bunch living in a totally different universe without a clue of what is > happening in real life ? comp.os.vms is a form of kabuki theatre. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sun, 01 Jul 2007 15:09:56 -0000 From: IanMiller Subject: Re: Question to Kerry Main Message-ID: <1183302596.369228.41560@q69g2000hsb.googlegroups.com> On Jul 1, 3:42 pm, Stephen Hoffman wrote: > > comp.os.vms is a form of kabuki theatre. > Complete with the music :-) ------------------------------ Date: Sun, 01 Jul 2007 11:50:02 -0500 From: David J Dachtera Subject: Re: Question to Kerry Main Message-ID: <4687DB3A.D77E86A6@spam.comcast.net> "Main, Kerry" wrote: > > > -----Original Message----- > > From: JF Mezei [mailto:jfmezei.spamnot@vaxination.ca] > > Sent: June 30, 2007 8:31 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Question to Kerry Main > > > > Mr Main, your arguments on c.o.v. are often rebutted as part of normal > > debating process. (And you rebutt other arguments with your own > > responses). > > > > In real life, do you also find customers and potential customers > > having > > similar questions ? Or do you conclude that we, in c.o.v. are a > > sepcial > > bunch living in a totally different universe without a clue of what is > > happening in real life ? > > Those who participate in c.o.v. have passionate beliefs in OpenVMS or > they would not be participating. That may be, at least in part, an over-generalization. For my part, yes - I find certain tasks much easier to accomplish in the VMS world than in the UN*X world. On the other hand, the reverse is also true. Certain tasks are much easier to accomplish in the UN*X world than on VMS. Searches using "regular expressions" are but one example, and hardly even the tip of the iceberg. A common theme here is that the doom artificially brought upon VMS by its proprietors threatens our livelihoods. Arguments about skills updating aside, the job market right now is nothing if not "challenging". Having what it takes to get another job pales in stature when measured against the challenge of actually "marketing" (there's that word AGAIN! DAMN!) those skills to propective new employers. ...and that doesn't begin to mention the challenges of assimilating into a new employer's organization. > Hence, while I certainly do not agree with everything that happens or is > stated here, I do believe the passion is a good thing. Indeed. As always, moderation is the key. -- 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, 1 Jul 2007 07:42:33 -0400 From: "Main, Kerry" Subject: RE: SOA and VMS stuff Message-ID: > -----Original Message----- > From: Arne Vajh=F8j [mailto:arne@vajhoej.dk] > Sent: June 30, 2007 11:15 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: SOA and VMS stuff >=20 > Richard Maher wrote: > > "Pete Dashwood" wrote in > message > > news:5edssuF37oamtU1@mid.individual.net... > > snip > >> You should also bear in mind that the SOAP protocol is already > obsolete > > and > >> will no longer be supported by MS after next year. It is being > replaced by > >> DotNet Web Services (which provide richer facilities and error > checking > > than > >> SOAP does...) > > > > I assume .NET Web Services still talk SOAP (but maybe that's like > saying > > Internet Explorer supports standards?) >=20 > .NET web services use SOAP and fully supports WS-I Basic. >=20 > The only .NET specific thingy I know about is the DISCO > protocol that complement/superseede UDDI (which was a > complete fiasco). >=20 > Arne Sounds like another kick at the common data dictionary can ..DISCO name = is appropriate as that was the name of the popular dance of the time = when common data dictionaries first started getting industry hype. :-) If it is, then good luck to them - as I mentioned before, the typical = failure of things like common data models being used effectively across = large companies are not technical.=20 To many conflicting priorities, lack of standards (or even desire to = have formal stds) and basically it would cost to much to implement (IT = is under huge pressure to reduce costs) and would take to long (IT = already has huge backlog of things they need to do). Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sun, 01 Jul 2007 10:34:44 -0400 From: Stephen Hoffman Subject: Re: SOA and VMS stuff Message-ID: Main, Kerry wrote: > Customer requirement - I need a swing so our programmers can have > something to do on their break. The smarter of the outfits I've dealt with over the years mandate (but do not require) some percentage of staffers' schedule time for research and development. This time and the project itself is coordinated with local management. There are rules and limits in place, but there is also encouragement. > Industry response - Those who stick with the simple swing are dinosaurs. Organizational evolution isn't necessarily a continuous and incremental process. So long as nothing changes in the business environment, you can get away with changing little. Whether overt organizational stability is a good strategy, well, you'd better have some sort of a legal or regulatory monopoly if you're planning on hanging out on that swing on your breaks. Stability is uncompetitive. Instability -- churn, organizational cavitation -- is bad. Individual organizations choose where between these two extremes is an appropriate model and an appropriate course. And whether the end-user site does its own work or buys or integrates, that depends on the business. > The new in thing and what you really want is this huge amusement park as > it is much better than a simple swing. Just think how happy your > programmers will be with this amusement park to play in on their > breaks... What's that? There are no guard rails on the roller coasters > to keep riders safe and secure?? Oh yeah, no problem, those will be > coming a future version. Being on the bleeding edge is called being the bleeding edge for a reason. You occasionally bleed. I'd rather be getting bloodied occasionally than sitting around, doing what I've always been doing. I view failure as a good thing. Failure means you're trying new stuff. Success is better, of course. But few manage success without a couple of failures in the process. Enterprise organizations do have large-scale requirements, and each organization approaches the requirements differently. In some organizations, hardware failures are to be avoided -- this is where you get very expensive and often very complex configurations -- and in others, hardware failures are to be expected and planned for -- these environments tend to replicate platforms; to expect and plan for and to even revel in the benefits of hardware failures. (Yes, there are benefits that can be derived here, either from planning for no failures, or even from hardware failures.) > Pure personal opinion, but this discussion reminds me of controversial > Burton report that came out about a year ago that stated J2EE days were > numbered (and he inferred .Net as I recall but cant remember for sure) > because the recent J2EE architecture updates had gotten so complicated > that only the most seasoned OO programmers could do any real high end > programming. Java and J2EE is one of many approaches. .NET is Microsoft's current name for their current marketing and development platform, and Microsoft has historically changed and shuffled its names and tools over the years. So long as Microsoft is around and in ascendance, some form and some descendant of .NET will be around. If you've bet on Microsoft, .NET (which subsumed the SOAP toolkit mentioned in a follow-up) is your platform. With Mac OS X, there are various choices including Xgrid and Web Objects. Linux and OpenVMS and all other platforms all have various portable interfaces, and platform-specific interfaces. There are many tools in the shed, and many choices in the market. (Arguably, too many. The numbers of choices can tend to "freeze" some folks. But I digress.) In some businesses, IT -- regardless of the tools chosen -- is uncompetitive and IT itself is not a competitive advantage. (qv: Nicolas Carr's Does IT Matter) In other businesses, IT is a central basis of the business and competitiveness. Individual businesses choose their targets, and whether they foresee benefits from a leading edge or an out-sourced IT model. Some businesses develop in-house. Some purchase. Some purchase companies or even competitors. Strategies vary. > Ah well, the amusement park sure sounds like a good idea to the > programmers though. Maybe in the kiddie end of the programming pool. In the businesses I've dealt with over the years, properly-led and properly-aggressive programmers can be a seriously competitive business resource. Misguided or unguided teams, or programmers only in the kiddie pool, on the other hand, can be a corporate-level business hazard. If you are a senior manager and your business and particularly your IT is in the position that Mr Carr or that Mr Main mentions, then I'd certainly suggest investigating outsourcing -- or purchasing an organization with more advanced IT, and migrating to it. Programmers with the appropriate tools, on the other hand, can generate applications faster, with fewer errors, and with easier support. What tool(s) and what platform(s) might be appropriate depends on the particular situation. While I have and use a nail gun, I also have and use a hammer. While I have C, I also have OO tools. While I have clusters and FC SANs, I also have grids and farms. While I have DCL, I also have php and bash. If I only had C or OpenVMS or DCL and as valuable as these are, I'd have less in my business toolbox. Oh, and "SOA" is a new marketing name for client-server computing. Nothing we haven't had for eons. Clients and Servers and details change, but the techniques remain the same. SOA is easily feasible with clusters, or with grids, or various other approaches -- which depends on the goals and requirements, and on who you have guiding you. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Sun, 1 Jul 2007 09:28:50 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: SSH newbie question Message-ID: In article , JF Mezei writes: > Bob Harris wrote: > > Telnet is not secured in anyway. The passwords and all the > > information you type and all the data displayed is sent in clear > > text. Anyone capturing your data will be able to see all. > > But does that really prevent break-in attempts ? When I telnet into my > switch, router etc, the folks on the internet do not see my data because > it remains on my lan. When you telnet into your router (presumably from outside your LAN), everything echoed on your screen is potentially available. > If SSH's only advantage is to prevent your ISP from snooping on your > packets, then it still doesn't prevent intrusion attempts from the rest > of the world. No PROTOCOL can prevent intrusion attempts. > BTW, is it normal when using SSH to connect to VMS, that > > "@SYS$MANAGER:ANNOUNCE.TXT" is displayed after the login instead of its > contents ? Yes. Known bug, err, feature. > And shouldn't it display the welcome.txt file instead of the announce > just before executing your login.com ? Ditto. ------------------------------ Date: Sun, 1 Jul 2007 10:23:23 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: TCPIP$GET_MX: getmxrr() failed Message-ID: In the last few days, I've started seeing this in TCPIP$SMTP_RECV_RUN.LOG: getmxrr: name = 87.139.7.213]) getmxrr: res_search() failed TCPIP$GET_MX: getmxrr() failed I haven't changed anything in the configuration (in fact, I was on holiday when it started happening---VMS fan that I am, I logged into my cluster from an internet café in the south of France!). I've never seen the error before. The address 87.139.7.213 is always the same. The error messages are always exactly as quoted above. Everything else seems to continue to work fine. Any ideas? ------------------------------ Date: Sun, 1 Jul 2007 10:42:42 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: TCPIP$GET_MX: getmxrr() failed Message-ID: In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: > In the last few days, I've started seeing this in > TCPIP$SMTP_RECV_RUN.LOG: > > getmxrr: name = 87.139.7.213]) > getmxrr: res_search() failed > TCPIP$GET_MX: getmxrr() failed > > I haven't changed anything in the configuration (in fact, I was on > holiday when it started happening---VMS fan that I am, I logged into my > cluster from an internet café in the south of France!). I've never seen > the error before. The address 87.139.7.213 is always the same. The > error messages are always exactly as quoted above. Everything else > seems to continue to work fine. It also seems that EVERY TCPIP$SMTP_RECV_RUN.LOG has these lines. ------------------------------ End of INFO-VAX 2007.356 ************************