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.
Checks on Cobol application
Moderators: dbzTHEdinosauer, Moderator Group
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.
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.
Regards,
Krishna
Facebook --> http://www.facebook.com/mainframegurukul
Connect with RAMESH KRISHNA REDDY --> http://www.linkedin.com/in/rameshkrishnareddy
Twitter --> https://twitter.com/mainframegurkul
http://www.mainframetutorials.com
Krishna
Facebook --> http://www.facebook.com/mainframegurukul
Connect with RAMESH KRISHNA REDDY --> http://www.linkedin.com/in/rameshkrishnareddy
Twitter --> https://twitter.com/mainframegurkul
http://www.mainframetutorials.com
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
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
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
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
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
- Cobol Interview Questions
50+ Interview Questions - JCL Interview Questions
50+ Interview Questions - DB2 Interview Questions
100+ Interview Questions - CICS Interview Questions
70+ Interview Questions - VSAM Interview Questions
27 Interview Questions
Other References
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program - FILEAID Reference
Explains how to browse , edit and delete datasets - Change Man Reference
Quick Start tutorial on Changeman - Abend Reference
Important Abend codes explained - FaceBook Page
MainframeGurukul FaceBook Page - LinkedIn Page
MainframeGurkul Linkedin Page