Barbara, I worked for a software vendor and our average in problems were 80% configuration/installation and about 20% real bugs in code.
Regards, Scott IDF -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barbara Nitz Sent: Monday, March 31, 2008 4:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OCO, Requirements, etc >One of IBM's originally stated reasons for moving to OCO was to >help stop overburdening support teams with PMRs for "bugs" that >were actually code that was poorly modified by customers. I don't >know if that was every actually much of a problem, but it certainly >would be now with IBM's reduced support staff. Back in the ninetees, it wasn't so much poorly modified customer code, it was rather vendor code doing things it shouldn't. My memory starts getting cloudy on this, but problems reported in the BCP area were about 60% vendor code, 20% 'real' customer code which we called 'user error', 15% errors that already had an apar/ptf and only 5% really new bugs that were not reported before. These are not offical numbers, it is the relationship that I remember for the problems *I* worked on (as a BCP level2 for IBM). The lack of source code prevents me (as a customer) from finding out fast what might have gone wrong and how to find a bypass. And software support has gone down quite dramatically in quality, in my opinion. The usual country/EMEA support in many cases has no clue, and the customer is left to deal with level3/development directly. If source weren't OCO, it would be a lot easier to discuss a problem because we could check better if we're just brushed off or if it is really true what we're told. Assuming 'the customer' is able to see through the various brush-off tactics from the various support levels (IBM and vendors). >I've always felt that one of the worst parts of the OCO move was >elimination of PLM. IBM could have continued providing them and >still achieved everything they claimed OCO was supposed to do. True. Even for IBM support with OCO source code access that didn't have either a phone line to level3/development or a good enough history with them that a question 'why is that so' would get answered. You can see in the code comments that a certain return code is expected, but not *why*. >> A sore point with me is always "submit a requirement", but that's >>another topic. >Sometimes that's just a put-off, but sometimes it's an real request; >they need to show justification for working on something. Same here. My 'requirements' are usually bugs that IBM doesn't want to fix, even when they caused severe problems. Barbara Nitz -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.gmx.net/de/entertainment/games/free ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
