Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Environment Issue in COBOL Program
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Thu Aug 25, 2011 2:41 pm    Post subject: Environment Issue in COBOL Program
Reply with quote

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. icon_sad.gif

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. icon_sad.gif

PS: I used the same data in the tables and same code to reproduce the issue in test.
Back to top
View user's profile Send private message

PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Thu Aug 25, 2011 3:17 pm    Post subject:
Reply with quote

SQL code 100 means no rows found.
Are the DB2 versions the same on test/production?
Back to top
View user's profile Send private message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Thu Aug 25, 2011 3:21 pm    Post subject: YES !!!
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Thu Aug 25, 2011 3:26 pm    Post subject: Reply to: Environment Issue in COBOL Program
Reply with quote

If you got 100 on production, and 100 means "not found", how could you have copied the data which was not found?
Back to top
View user's profile Send private message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Thu Aug 25, 2011 3:29 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
gylbharat

Active Member


Joined: 31 Jul 2009
Posts: 565
Location: Bangalore

PostPosted: Thu Aug 25, 2011 3:34 pm    Post subject:
Reply with quote

May be now those records are not present in production table.
Back to top
View user's profile Send private message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Thu Aug 25, 2011 3:36 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Thu Aug 25, 2011 3:41 pm    Post subject: Reply to: Environment Issue in COBOL Program
Reply with quote

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).
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Aug 25, 2011 3:56 pm    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Thu Aug 25, 2011 3:58 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Thu Aug 25, 2011 4:05 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Thu Aug 25, 2011 4:10 pm    Post subject:
Reply with quote

vishwaratha wrote:
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.


Do you mean you know what the problem is and don't require more assistance?

What is "not affecting the JCL"? Haven't a clue what that means.

Certainly, in an ideal world I'd win the lottery every week. I don't code for winning the lottery every week, so I don't code for the ideal case. I code to "expect the unexpected". I still got the unexpected sometimes (that's one of the problems with "the unexpected") but not anywhere near so much as otherwise.

I never had a problem "following the code closely" without a debugger. If you want my opinion (and you don't) debuggers make you lazy. You don't have to think about program flow (actual, or what it should be) because the debugger keeps flipping it up on the screen.

Try this. Go for a month without using a debugger. If you still feel the need to use a debugger all the time after that...

Look at it this way. You can't use your debugger in production. You are now messing about trying to get your "test" to the "production" state before you even start looking at the problem. If you know how to operate without a debugger, then you can support production.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Aug 25, 2011 4:38 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7235

PostPosted: Thu Aug 25, 2011 4:58 pm    Post subject: Reply to: Environment Issue in COBOL Program
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Aug 25, 2011 5:30 pm    Post subject:
Reply with quote

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?)
Back to top
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Thu Aug 25, 2011 8:45 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Aug 26, 2011 10:54 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
vishwaratha

New User


Joined: 08 Oct 2010
Posts: 7
Location: Hyderabad

PostPosted: Tue Aug 30, 2011 2:09 pm    Post subject: Thank you
Reply with quote

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 icon_smile.gif
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Wed Aug 31, 2011 1:45 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Aug 31, 2011 2:08 am    Post subject:
Reply with quote

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

Quote:
there is a difference creeping up in the fetch criteria of the SQL.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts I can not compile my program PL1 V3.R... Miguel Fernandez PL/I & Assembler 13 Tue Dec 06, 2016 8:30 pm
No new posts IMS BMP program causes 878 system abend Artemk IMS DB/DC 7 Tue Nov 22, 2016 8:26 pm
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts DFHRESPONSE returns issue divated CICS 3 Wed Nov 02, 2016 6:32 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us