Environment Issue in COBOL Program

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

Hi,

I have a COBOL program. I have made few changes in the test environment. I have tested the code and everything worked fine. After the code has been deployed there was a problem in a specific scenario and I believe there is a problem in the code I wrote because the problem occurred only after I gave my code. However, when I try to test the same code again in test environment everything seems to be fine. All the records are processed fine unlike in the production. In production there is an SQL code 100 because of which the record is erroring. I ran the query but there are rows returning.

Please let me know what I could do check the problem. I ofcourse cannot debug in the production environment and in test there is nothing to debug because everything is fine.

PS: I used the same data in the tables and same code to reproduce the issue in test.

PeterHolland · Posted: Thu Aug 25, 2011 3:17 pm

SQL code 100 means no rows found.
Are the DB2 versions the same on test/production?

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

YES !!!
The versions are same. I have copied the rows from production and checked all the rows between test and production. They are all the same.

Bill Woodger · Posted: Thu Aug 25, 2011 3:26 pm

If you got 100 on production, and 100 means "not found", how could you have copied the data which was not found?

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

I copied the data available in production.
And when I run the test job, the same program works fine and returns rows.
Hence in test there are no error records.
I hope I am being clear.

gylbharat · Posted: Thu Aug 25, 2011 3:34 pm

May be now those records are not present in production table.

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

No. Its nothing like that. Those records are still there. The rows in test tables and prod tables are still the same.
I cant even debug this as there is no error in test environment to debug.

Bill Woodger · Posted: Thu Aug 25, 2011 3:41 pm

Something, somewhere along the way, and external to the "database" in that specific sense, drives your program in production to interrogate the database.

Have you got the condition which drives the look-up in your test set-up, or are you just tossing random tests at it. First, are you trying with the data that actually caused the failure. If that leades nowhere, are you trying with all the data up to that point. If you still get nowhere, perhaps, only perhaps, it might be an "environment thing".

Even before all of that, why in the program is the 100 not catered for? It will be important to test your fix, but first, why was it not coded for? What should the business process be when you get 100? If the answer is controlled abend, then you should have information for diagnostic investigation.

You have a program listing. You have some information. You know the code which went wrong. Why are you waiting to set it up in a debugger? What do you think we did before there were debuggers? Just give up and go home?

You seem to have done well by acknowledging that it is probably an error you have introduced, but then you try to get into all this "environment" stuff. Stick with the problem. If there are reasonable excuses for letting this escape into production with a bug in it, they will be obvious to anyone who matters (like your Boss).

dbzTHEdinosauer · Posted: Thu Aug 25, 2011 3:56 pm

well,
we have covered the 'are there the same rows in production as in test' scenario.

why don't we try a diiferent approach.

what did you change?

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

Hi Bill,
I have got to know where the exact problem is occurring.
The SQL 100 has also been handled and hence an error msg is given and it is not affecting the JCL.
In ideal case I should not be getting any errors.
And the problem about debugging which I have mentioned earlier was, there is a problem in the code, I can look closely into the code and follow the flow. But even if I do that in the test environment I am unable to progress because the program is going very smooth and fine without any errors msgs.

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

Hi Bren,

I have added a new scenario in the code. I have done the before and after code test and made sure that there is no deviation with the original results.
Now I get the error records in production. To test that, I have taken the production code and the production DB2 rows and everything is fine here.
I have no idea as to what a different approach can be.
I believe there is a problem with the code. But I still don't understand how it can work perfectly fine in test and not in prod with the same data.

Bill Woodger · Posted: Thu Aug 25, 2011 4:10 pm

dbzTHEdinosauer · Posted: Thu Aug 25, 2011 4:38 pm

Vishwaratha,

you still have not answered the question:
what did you change? (from the old to new production)

and, are these few rows that can not be found,
the only input/output data that is involved with this program.

you have a problem you can't fix.
you have tried all your methods and
are continually reaserting your views with your observations and making conclusions.

I don't want to hear about your observations and conclusions.
if they were correct, you would not have a problem.

now, if you want any help, provide the answer to the basic question:
what did you change.

Bill,

debuggers were not really designed to 'show the logic flow'.
debuggers were created so that each could insure that the data manipulation was going according to plan.

debuggers are not for fixing forests, there are for repairing trees.

Bill Woodger · Posted: Thu Aug 25, 2011 4:58 pm

dbz, maybe once-in-while, "SOAB, look at that twig there" :-)

I don't have a problem with anyone using a debugger in the right circumstances (and who'd care if I did?). I do have a problem with someone not able to support production without being able to run the debugger (but still no-one cares), so having to set up production in a test environment before taking step 1.

dbzTHEdinosauer · Posted: Thu Aug 25, 2011 5:30 pm

i don't think lack of debugger in production is the problem.

as an example, look at the topic. this is the TS's perspective.

Vishwaratha,

last time:

same program: fails in production, works in test
since the program is the same, what possibly could be different?
the rows that are sucessfully SELECTed in test and not in prod are the symptom.

There must be other data involved (input thru file?, other db2 select?)

Jose Mateo · Posted: Thu Aug 25, 2011 8:45 pm

Good day to all!

Dbz has a point, the program and the database is the same in both environment TEST & PROD. There's no problem with the SELECT except for the key or items you are using for the SELECT. The test input to your SELECT is different from the input used in production. Find the type of record that's receiving the SQL 100 in production then check your program to handle this type of record.

dick scherrer · Posted: Fri Aug 26, 2011 10:54 am

Hello,

Look very closely at the changed code. . .

This may be doing something to cause a problem with older code and not be seen only in the new code. Said differently, what you believe is runniing may not be exactly what is runniing.

vishwaratha · New User Joined: 08 Oct 2010 Posts: 7 Location: Hyderabad

Hi,

I have taken all the suggestions you have provided.
I could make out that in production and test, there is a difference creeping up in the fetch criteria of the SQL.
I believe I can now solve the issue.

Thank you very much for the help

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Could also be a compile difference. I got bit by the NUMPROC option once. In prod, a signed COMP-3 was being left as x'00000F', while in test, it was being converted to x'00000C'.

I didn't catch if TS is recompiling the program for testing though. If so, make sure the compiler options match up.

dbzTHEdinosauer · Posted: Wed Aug 31, 2011 2:08 am

i think that actually the problem is that the where clause host variables were different,
as the TS has sorta indicated:

dick scherrer · Posted: Wed Aug 31, 2011 2:55 am

Bill Woodger · Posted: Wed Aug 31, 2011 11:27 pm

GuyC · Posted: Fri Sep 02, 2011 7:35 pm

checking wrong tables because of different qualifiers was also a possibility.

Ed Goodman · Active Member Joined: 08 Jun 2011 Posts: 556 Location: USA

Bill,
The "shop standard" is NOPFD, so we changed our test compiler to be the same. Then we fixed the new code to work correctly (as expected) with that option active.

Bill Woodger · Posted: Sat Sep 03, 2011 1:22 am

Good-oh.

Do you remember how the field got to get an "F" sign in it? Just curious. PFD trips up (can) with the "F", NOPFD generate bus-loads of extra code. I'd like PFD, but if it can be too "easy" to get the "F"s, it is pretty useless.