I think they know that the real OS/2 user community is also the Linux community. They are investing a lot and I think they're hedging their bets a little.
Open VMS has many of the same features that the old 3+Open NOS's had when they were trying to client-server between VMS boxes and DOS/Windows machines. It's just much more refined and much easier to architect.
Sort of like what Dec did with the 8400 Alphas and ATM (clustering), just it's all wrapped in one package. In short, makes the VMS environment more friendly with non-VMS systems using methodolgy from the old days.
They still have a customer base they need to support. I beleive they'll honor what they told you. They're just moving it to legacy status (no new development/product offerings) but they will still support the install base.
Going to Linux is a great move for them, it'll help their HW market immensely, I just hope the folks running the effort aren't the same yo yo's who were behind MCA.
There are a ton of government shops that still use it. Finance areas seem to be high on it also.
At the bottom of the article was this sniglet.
We were spending millions developing NT on Alpha, but when we looked at the value proposition when compared to NT on Intel, it didn't differentiate NT on Alpha,' he said.
The first such offering will be the one-to-eight way Alpha-server GS80, which will come with up to 32Gbytes of memory and up to 56 PCI slots
A beo. . Oh, never mind.
This is good news however, there are a lot of shops out there waiting on the OpenVMS releases and from all the corporate restructurings etc. have had to wait way too long. Very glad to see Compaq make good on it's promise to keep the OpenVMS track alive at least for a few more releases.
Buy every time if you have over 100 customers/users to support. The ROI will cover the cost very quickly and the dividends of escaping having to hassle with the homegrown legacy system will pay back ten fold.
We had 40K+ users spread out over the world and our approach was to intall it full bore and then pear back to nothing but basic submission and priority queues. As we got more familiar with it we added some features, trying to keep it simple.
We never hit it's capacity limits, we just threw more HW at it. Reporting was a little weak, but for a larger enterprise it was a solid investment. The ROI was positive, based upon it take a little over 100K a year to keep a FTE support headcount onboard, if we saved x hours by better prioritization and corrdination of support, it added up quickly and with capital credits thrown in we recovered our money in under 18 months.
If your managing a user base of anything over a couple hundred workstations, Clarify is not the right tool. Go with Bendata, Remedy, or even some of the IBM products that run on the OS/390's, but stay away from clarify, It's a major pain in the neck.
Having the right tools is only a part of the solution.
Building humanistic processes around product is not the right way to get better support, in this case support infrastructure, policies and procedures.
Mine for artifacts, get your requirements down, build or at least outline your process and THEN go get your tools.
Case and Point Take Clarify or Remedy, both great tools for their applications, but different in longer term functionality and flexibility. Many smaller shops get sucked in by marketeers and pick up a product like one of these two. Then their dot com IPO's and instantly they have a much larger company to support and the tools they had work cut it any longer. What do they do? They run our an buy more tools without re-engineering the processes. This results in IT headaches and much wasted time.
What happens next? They look to something like Web based support engines. Good in their own right, but very possibly wrong for the application they are trying to implement it for. Result is more poor service with unhappy customers/users and a overworked IT or support staff.
Build the process and then get the tools, don't let your customers/companies get sucked it by the latest cool thing they read about in Forbes. That's the way to seriously kill productivity in the support world.
Not a flame, but what kind of company do you work for? 3+ hours to get initial response to a segment outage is pretty bad. VRU's could help, but they're expensive. Sounds like Ops, Eng and IS/IT need a little better communication at the senior levels. Silo support in anything other that a little garage operation is just a recipe for disaster.
Firing the guy was unfortunate for two reasons.
1- The guy lost his job, I've been there, that sucks for anyone. 2- The real problem didn't get fixed by firing the guy. (not the segment)
The source of the problem is the processes in your IT and Ops worlds sound pretty broken, and although firnign the poor guy made a few people happy and inflated the egos, it did nothing to prevent the same scenerio from happening again. Thats too bad. The real problem was broken process, not the fact that some slacker was focused more on talking to his girlfriend than giving world class support. Midville School for the Gifted. Tell you exec's to stop trying the same things, yet expecting different results.
Heat from Bendata has a similar package tot he one you mentioned. Pretty comprehensive. It also has what they call "First Level Support" which is a feature that tracks problems/solution steps as you enter them the first time. Then when you have a similar problem, it will prompt the HD analyst through the steps.
I know there are many products that do this out there today, hoever this is the first one I've seen that does it dynamically and is pretty simple to navigate through.
Obviously I'd be partial to the PHB product. But I digress. ..
I've looked at several of these but the main thing that keeps my firm from using them is not the cost, or the service levels, it's the security.
Most want/need as a standard, port level senders and receivers, I'm not willing to open up the possibility of 31337 haxor type kiddies getting into my network.
Slashdot Mirror
I think they know that the real OS/2 user community is also the Linux community. They are investing a lot and I think they're hedging their bets a little.
Sort of like what Dec did with the 8400 Alphas and ATM (clustering), just it's all wrapped in one package. In short, makes the VMS environment more friendly with non-VMS systems using methodolgy from the old days.
Going to Linux is a great move for them, it'll help their HW market immensely, I just hope the folks running the effort aren't the same yo yo's who were behind MCA.
At the bottom of the article was this sniglet.
We were spending millions developing NT on Alpha, but when we looked at the value proposition when compared to NT on Intel, it didn't differentiate NT on Alpha,' he said.
Doh!
A beo. . Oh, never mind.
This is good news however, there are a lot of shops out there waiting on the OpenVMS releases and from all the corporate restructurings etc. have had to wait way too long. Very glad to see Compaq make good on it's promise to keep the OpenVMS track alive at least for a few more releases.
Buy every time if you have over 100 customers/users to support. The ROI will cover the cost very quickly and the dividends of escaping having to hassle with the homegrown legacy system will pay back ten fold.
We had 40K+ users spread out over the world and our approach was to intall it full bore and then pear back to nothing but basic submission and priority queues. As we got more familiar with it we added some features, trying to keep it simple.
We never hit it's capacity limits, we just threw more HW at it. Reporting was a little weak, but for a larger enterprise it was a solid investment. The ROI was positive, based upon it take a little over 100K a year to keep a FTE support headcount onboard, if we saved x hours by better prioritization and corrdination of support, it added up quickly and with capital credits thrown in we recovered our money in under 18 months.
If your managing a user base of anything over a couple hundred workstations, Clarify is not the right tool. Go with Bendata, Remedy, or even some of the IBM products that run on the OS/390's, but stay away from clarify, It's a major pain in the neck.
Building humanistic processes around product is not the right way to get better support, in this case support infrastructure, policies and procedures.
Mine for artifacts, get your requirements down, build or at least outline your process and THEN go get your tools.
Case and Point
Take Clarify or Remedy, both great tools for their applications, but different in longer term functionality and flexibility. Many smaller shops get sucked in by marketeers and pick up a product like one of these two. Then their dot com IPO's and instantly they have a much larger company to support and the tools they had work cut it any longer. What do they do? They run our an buy more tools without re-engineering the processes. This results in IT headaches and much wasted time.
What happens next? They look to something like Web based support engines. Good in their own right, but very possibly wrong for the application they are trying to implement it for. Result is more poor service with unhappy customers/users and a overworked IT or support staff.
Build the process and then get the tools, don't let your customers/companies get sucked it by the latest cool thing they read about in Forbes. That's the way to seriously kill productivity in the support world.
Firing the guy was unfortunate for two reasons.
1- The guy lost his job, I've been there, that sucks for anyone.
2- The real problem didn't get fixed by firing the guy. (not the segment)
The source of the problem is the processes in your IT and Ops worlds sound pretty broken, and although firnign the poor guy made a few people happy and inflated the egos, it did nothing to prevent the same scenerio from happening again. Thats too bad. The real problem was broken process, not the fact that some slacker was focused more on talking to his girlfriend than giving world class support. Midville School for the Gifted. Tell you exec's to stop trying the same things, yet expecting different results.
I know there are many products that do this out there today, hoever this is the first one I've seen that does it dynamically and is pretty simple to navigate through.
I've looked at several of these but the main thing that keeps my firm from using them is not the cost, or the service levels, it's the security.
Most want/need as a standard, port level senders and receivers, I'm not willing to open up the possibility of 31337 haxor type kiddies getting into my network.