Information

DB2 Consultants

This group is particularly for DB2 Consultants & Business Partners so that we can work closer together

Members: 64
Latest Activity: Jun 21, 2016

Discussion Forum

Welcome

Started by Guy Przytula Jun 21, 2016. 0 Replies

Julian Stuhler - IBM Gold Consultant

Loading… Loading feed

Comment Wall

Comment

You need to be a member of DB2 Consultants to add comments!

Comment by Surekha Parekh on November 22, 2013 at 10:37pm
If you are a Gold Consultant and would to create your own page on this site please send me an email.
Comment by Parvathavardhini on May 14, 2013 at 11:43am

Surekha, Thanks for your reply.

I just wanted to know about the DB2 consultants in India, and also I wanted to know how a person can become an IBM consultant or IBM Gold Consultant etc.

Also since I am form Chennai India, I thought it will be good to know about DB2 consultants in India.

Comment by Surekha Parekh on May 10, 2013 at 7:34pm
Thank you for your comment I am not aware of companies only aware of the System Integrators and consultants. Did you have a particular requirement
Comment by Parvathavardhini on May 6, 2013 at 1:20pm

Hi all,

I have seen that there are many independant DB2 for zOS consultants in other parts of the world. I would like to know if there are any consultants or consultant companies specifically working on DB2 for zOS in India.

I know about consulting companies like TCS have teams working on mainframe and DB2. But I would like to know if there is any firm working particularly on DB2 zOS in India like the Fillmore group  or The responsive systems.

Thanks

Parvathavardhini.

Comment by Roger Miller on January 6, 2010 at 7:54pm
Since we did V5 to V7, we have experience. Half the cost is a common but very inaccurate assumption. V5 to V7 projects were generally 50% longer and 50% more work. The costs for education and removing any obsolete function roughly double in a skip migration. A better estimate for the savings is 20% to 25% over two separate steps. The risk for skip version migrations was higher, with larger projects, more changes, and more problems. The biggest issue I remember was customers assuming that the project would save half the costs, so steps could be skipped. Skipped steps required recovery and proved the adage that multiple steps can be the best path.
Comment by Peter Prib on November 18, 2009 at 10:28am
It seems to me that some fundamentals of business have been ignored. Basically change brings risks and costs. Thus what is the cost justification of change and is it worth the risk. If a company can skip a release it halves the total costs and halves the total risk assuming appropriate testing is performed. So what if it performs faster, if resource capacity exists without additional expenditure to met SLAs or future load then the company isn't saving money. Besides improvements in hardware and reduction in their costs are continually changing the equations.

I established a Siebel environment on DB2 8 years ago for an major financial organisation. The other day I heard they haven't upgraded anything since. Still running V6. No intentions of upgrading. Apparently has run without outage and its their front line call centre system. Unlike hardware, software doesn't deteriorate with age. Their only issue is support. In theory the system is stable. No demand for change. The risk of failure, in theory, is insignificant. If they upgraded they are likely to have failure. More so as they would have to upgrade Siebel. Are they wrong? How much money have they saved?

The discussion on the cost of education amusing. One doesn't have have to use the new features. Using new features come from compelling arguments of cost savings, governances a company must meet or a new application using latest trends such as XML. For example, PCI security requirements have generated demand to move to V9.

Actually to establish a adequate fall back position sensible sites ban the use of new features for a significant period and role in the usage of new features in a controlled fashion. I know this is not always possible but its standard risk mitigation. That has been a major consideration of IBM with DB2 on z/OS. Better still run sysplex and have both versions operational at the same time. My point, the risk and problems are mainly related to how one plans the migration. Revolution or evolution.

Personally I like being on the forefront of technology. Actually most techos have the same mindset. Comes with the role. The real question is it right for the business. Sadly in many cases the answer is no and we love the excuse of "going out of support" to justify our desire to play with something new.
Comment by Cuneyt Goksu on November 18, 2009 at 7:12am
Most V8 customers in my region already started V9 Migration projects and We expect a lot V9s here next year. If Vnext have skip migration feature, I'm sure this will not stop them moving to V9 instead of waiting VNext. So my vote is skip "Skip Migration".
Comment by Ron Brown on November 17, 2009 at 8:45pm
From a pure technical point of view, jumping a version can have challenges including educating staff to take advantage of the change.
However, there can be many benefits which are picked up automatically (for example the general performance improvements through path length reduction in Vnext). I am hoping we can keep Access Path Regression under better control with V9 and later.

My last few customers have been on the "trailing edge", only upgrading DB2 to avoid going out of service! My current customer still has some subsystems in V8 CM now. What concerns them most is the cost, not really a lot of the new features that we find so exciting. This customer has a budget for 2010 which does NOT include a DB2 upgrade, but I can see a possible opportunity appearing for 2011 - upgrading to the then current DB2 rather than "version -1" in one migration rather than two (which saves them internal project money). With the current financial crisis I think there could be many more companies in a similar position.
Comment by Steve Thomas on November 17, 2009 at 5:52pm
If someone does attempt a skip migration (using whatever method, including migrating the data across which I've also heard discussed) then I'd expect the biggest issue to be how to handle Access Path regression. It's hard enough wiht one release, but working out what's caused a degradation across two releases is going to be worse.

I also agree with Julian about education. DB2 9's got a lot of new stuff, and DB2 X looks pretty big as well. Just learning about SQL differences for Developers is going to be hard enough. For DBAs it would be a big job.
Comment by Isaac on November 17, 2009 at 5:48pm
Ditto.
I did a V5 to V7 , V4 to V7! and now V7 to V9 (no V8).
The culture shock is high.
I'm sure some customers will use a V8 to Vnext path if it exist.
But again - doing that means you are stuck with old V8 and not getting the many V9 benefits.
 
 
 

Videos

  • Add Videos
  • View All

DB2 Analytics Accelerator

Photos

Loading…
  • Add Photos
  • View All

© 2017   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service