Checks on Cobol application

This is a Mainframe COBOL forum - you can post your queries on Mainframe COBOL, VS COBOL II, COBOL/370 , Enterprise COBOL

Moderators: dbzTHEdinosauer, Moderator Group

Post Reply
jeroc
Member
Posts: 17
Joined: Mon Dec 03, 2007 8:14 pm

Checks on Cobol application

Post by jeroc » Thu Mar 20, 2008 6:08 pm

Hello,

I have not a lot of experience on Cobol and I have to check a Cobol application that has a batch part and a transactional part under CICS. It makes access to VSAM files and DB2 databases.

According to your experience, what are the most important checks I should perform (on Cobol, JCL or other components) in order to detect potential outage (crash, data corruption, performance issues...)?

In other words, do you know some siutations that could create problems in production and how to find their cause?

Thank you in advance.

User avatar
Krishna
Site Admin
Posts: 1052
Joined: Fri Jan 27, 2006 7:50 am

Post by Krishna » Fri Mar 21, 2008 10:26 am

Hi,

There is no much difference between standard cobol, cobol-cics in relation to
crash, data corruption, performance.

If you want to improve performance, try to optimze db2 queries.

jeroc
Member
Posts: 17
Joined: Mon Dec 03, 2007 8:14 pm

Post by jeroc » Tue Mar 25, 2008 4:22 pm

Hi,

Ok, but what are the interesting checks I should perform to see if the application is ok and will not have potential problems in production ? Not only about performance but also robustness.


Thank in advance.

User avatar
DavidatK
Active Member
Posts: 65
Joined: Tue Mar 27, 2007 8:41 am
Location: Troy, MI USA

Post by DavidatK » Tue Mar 25, 2008 10:28 pm

Reviewing a program for functionality and efficiency are two different but related activities.

Let?s tackle the functionality side, which can be the most complicated in larger complex programs.

? You?ll need the original program specifications, plus all specification modifications that have been made to the program. Without this, how will you know what the program is intended to do?
? You should scan the program for obvious logic errors. i.e.
o Are all PERFORMs performing the correct range of code. The way I do this is to in edit ?X ALL? find all paragraph names, PERFORMs, ?GO TO?s etc in the program then do a visual check for reasonability. Did the author cut/paste a paragraph and forget to change the ?GO TO? in the new paragraph?
? You should set up a test script for every valid input condition the program is expected to handle, and test all of these to make sure the output is what is expected for each of the input conditions. ? This is the easiest, but can be time consuming as test data must be set up for each condition. ? Is the program doing what it?s expected to do for valid data.
? Now you need to test all of the exceptional conditions.
o If the program has an input file, can the input file be empty? Yes, test this condition. No ? test this condition. If yes, the program should treat the condition as it would a normal EOF during processing and terminate gracefully. If no, how does the program react? This is an error and needs to be reported, and the program should probably abend with an appropriate message.
o What about corrupted input data. Has ALL the data been edited so the data is appropriate for the input data type? If not, and especially if the data is client input, the program should be doing edits to ensure the data is valid.
o What about out of range data. This should be validated also.
o Does the program have any COBOL tables in it that will be variable in population %. If yes, does the program handle table overflow conditions? It need to check if the entry it?s about to add to the table is within the range of the table. What does it do if not?

Now this is just a flavor of what can and should be tested in a new program. Certainly no a comprehensive list of everything that should be tested.

In our shop, we can pretty well use the 20/80 rule for coding/testing. 20% of the time is spect coding and 80% testing the program, This means we spend, as an average 4 times as much time testing the program as it took to code it. Sometimes, even more time.

I hope this gives you a little taste of what you need,

Dave

jeroc
Member
Posts: 17
Joined: Mon Dec 03, 2007 8:14 pm

Post by jeroc » Fri Jun 20, 2008 6:37 pm

Hi,

Sorry to answer so late.

Thank you for your response. Do you know some "classical" troubles that can generate abends in production for Cobol programs ? And how to detect them by looking at the source code ?

Thanks.

Regards

jeroc
Member
Posts: 17
Joined: Mon Dec 03, 2007 8:14 pm

Post by jeroc » Wed Jul 30, 2008 1:26 pm

Hello,

You spoke about new program checking. But what about old programs or programs that have been developed by another team (for instance in a outsourcing context)?

Is it possible to use some specific checks in order to detect potential bugs? In your shop, what are the types of bugs you regularly face?

Regards

Post Reply

FREE TUTORIALS

Tutorials
Free tutorials from mainframegurukul
  • JCL Tutorial
    Covers all important JCL concepts.
  • Cobol Tutorial
    This tutorials covers all Cobol Topics from STRING to COMP-3.
  • DB2 Tutorial
    DB2 Tutorial focuses on DB2 COBOL Programming.
  • SORT Tutorial
    This Tutorial covers all important aspects of DFSORT with examples
  • CICS Tutorial
    This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions



Other References
Mainframe Tools and others