|
Having worked for a software vendor prior to my current position here with the City, I can see where your frustrations begin. During my period there however, I did create a "couple" bugs that were pointed out by a "few" intelligent customers and I accepted them with great thanks. However, my own experience with customers is that there are a few intelligent ones, but man were there ever a lot that should never step forth onto the iSeries. Thus you have the reason some of them talk to you as a 2 yr old. Unfortunate, but then again they should be smart enough to realize when an "intelligent" customer is calling them. I've lumped them into two categories over the years. Those customers that are programmers, and those that are wanna-bes. Just to give an example, one client had an in-house modification to one of our billing programs that was very complicated to begin with. On their own they added some "extra" billing code. One day we get a call and look at their data and after a billing cycle about 1,000,000 of their records were corrupted. Being assigned to the task of finding out what the he(( happened I began debugging our own code because no one mentioned anything about them having their own copy. Spent several hours trying various scenarios, etc, then I thought well maybe there's an old version of the pgm somewhere on the system and that's when I found this version in a library. Upon calling the client and discussing what the pgm was doing there I found the problem. A bug in their code. Went to my management then and it became a billable problem because it was client generated. Next thing I know I'm involved in a battle between client and company. Not pretty. In the end it took me about 3 full days to find the problem, write a fix pgm, correct the data and then correctly write their pgm. Never trusted that client again when they called in with an issue. Always checked that library for their mistakes and I have to say out of all their support calls about 75% were client generated. Anyway, I'm sure that's not the case here, but wanted to give you some insight from a "been there did that" type of perspective. But like I said, you can usually tell the good from the bad in the first 5 minutes of talking to them, and I'm pretty sure you are one of the good ones :) Thanks, Ron Power Programmer Information Services City Of St. John's, NL P.O. Box 908 St. John's, NL A1C 5M2 Tel: 709-576-8132 Email: rpower@xxxxxxxxxx Website: http://www.stjohns.ca/ ___________________________________________________________________________ Success is going from failure to failure without a loss of enthusiasm. - Sir Winston Churchill Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> Sent by: rpg400-l-bounces@xxxxxxxxxxxx 04/08/2004 04:09 PM Please respond to RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> To RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx> cc Subject Re: Array index nt valid Hi Buck, > It remains my opinion that when a program falls over with an array > index error, then there is a problem with the program. Even if the > input file has no records. As a consumer, I would never, ever accept > such a program into production I've researched many software packages, and for some odd reason, none of them say "Warning! Do not buy this software, it has array index errors in it!" in their product's sales information. Yet, after purchasing them, I've found that some of them do have this error. Since I've already paid for the software, management doesn't usually think it's acceptable to throw it away and buy something else. They seem to think that if I can work around the problem, I should. How do you convince them otherwise? Or better yet, how do you convince the software manufacturer to put "Warning! My code sucks!" in their product literature? Also, there are occasional times when I don't notice every bug in a piece of software that I bought. Some of them crop up AFTER I've put it into production. How do you ensure that this doesn't happen? Also, sometimes the software does something that solves a business problem, and does that admirably and economically. But then, there's this one bug that I have to work around. Perhaps alternative software does not solve the business problem as well, or perhaps not as economically. Is it realistic to expect me to dump the software just to avoid working around a bug? > and as a programmer, I would feel ashamed to let one like that out of > the test environment On that, I agree with you. > If this is working as designed, then have the author document that an > array index error is the expected output, and what to do when it > occurs. Get that in writing, and then give that note to your > management, who can then decide if the author should be paid for his > 'work' or not. If I go to a software vendor and tell them that I've encountered an error, the first thing they do is talk to me like a 2 year old. After maybe a day of going back & forth with their tech support, they'll tell me how to write my program so that I won't get the error. They sure as hell won't put "It's my fault" in writing so that I can give it to my management. If they do, what will my management say? They'll tell me to work around the problem. Do you seriously think my management understands that they shouldn't produce this error? Especially if the vendor has provided me with specific instructions to solve the problem by changing my own program? I just hate buying software from vendors. It never works as well as my own programs do. You never get good support or service. It's always overpriced. You never know what you're getting into until you've bought it and are stuck with it. I hate computers. -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. This OutBound email has been scanned for Viruses
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.