Posted: Thu Mar 20, 2008 6:08 pm Post subject: Checks on Cobol application
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?
Joined: 27 Mar 2007 Posts: 65 Location: Troy, MI USA
Posted: Tue Mar 25, 2008 10:28 pm Post subject:
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,
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum