Hello, this is Kevin. Welcome to testing and debugging. I was a new developer when the phone rang in the middle of the night, I heard the news that a production program had abended. The program stopped abnormally. I did not write the program but I was a person on call to fix it. I eventually discovered the logical error but let's just say I was not in a great mood the next morning at work. Testing is crucial. Thorough testing is often overlooked due to the pressure of finishing things on time or sometimes just laziness. Bugs are overlooked, programs are placed in production where mistakes eventually are discovered. It takes more time and expense to wait for this to happen. Testing is crucial unless you like bugs. During this lesson, we're going to learn about ten steps for proper testing. Three strategies for testing, unit, system and regression, describing several common errors and their solutions, utilizing forensic information from ABENDS that will show up in our JCL, and describing common abnormal end codes and their meanings. Now, the testing steps, we use ten steps for proper testing and we would encourage you to do the same. First, we design the program using structured COBOL. Second, we write the program and then third, we start to carefully review a program for errors. This is called desk checking. Just sitting at your desk and checking that, sometimes can save you a lot of trouble later on. Number four, design and create test data that is comprehensive and realistic. Then compile your program. If there's any syntax errors or other compile time errors, you've gotta go and fix them and try to compile again until it works just fine. Number six, what we want to do is we want to link the program. If unsuccessful in that process, we have to fix the errors and repeat. Then we want to plan a program walk-through, identify what success is going to look like, step through the logic of the program, predict and write out what the output results should look like before you actually run the program. Then when you execute the program, if it is unsuccessful, we've gotta fix some errors and repeat again. Number nine, we want to review the output to ensure correctness. If that's not successful, we return back to the walk-through or we go back a couple of steps and look at our design and see where we made some kind of a mistake. And then number ten, we want to prepare the program for production. If these steps are not followed, then you will likely encounter an abnormal end also known as an abend at some point in time. We don't want that to happen to you. Now, we're going to take a look at unit testing. When we mention testing, we're usually describing unit testing which involves these things, successfully compiling and linking a program, preparing test data that is correct along with anticipated errors and sometimes discovering unanticipated errors. Develop a testing plan describing how the program will be tested. Test the program with the goal of finding errors before you get into production. Critically review the output, correct errors if necessary, then retest as needed. Create and store program documentation and then place the program where it can be accessed for system testing. But there are two more strategies, testing strategies, system and regression. We're all aware of ecosystems. COBOL programs are part of a technological community that interacts with other programs in their physical environment. This is why we need system testing also known as integration testing. To put it briefly, system testing is understanding that the impact of my program is going to have an impact on other people's programs. The 3rd test that we want to run is regression testing. This is where we make some change to our COBOL code. And we need to ask ourselves the question, did the changes that I made in my program not on purpose, but did they adversely change the behavior of some other program downstream or the output data that's coming out. Now, the good news is that there's plenty of forensic information that's available to us when we have an abend. Now, I've learned a lot of things from my students. A student once told me of the five most likely mistakes he made when he was first learning COBOL. He called himself a rookie, we might want to call him a novice. But here's his list and you may want to keep track of it for your own use. Number one, trying to execute a mathematical command with non-numeric data. Creating a paragraph that processes in an endless loop. That happens to a lot of people when they first doing this. An incorrect description of a file, in other words, the wrong name to a file, the wrong length to a file. Typos, we all make them, we misspell things. And then logic that is illogical. Some other forensic information that we can get from an abend. When a program ab ends, the first dozen or so lines of your JCL will inform you sometimes more than once about what went wrong. On your screen is something difficult to read the first time. This information is in limited version of what you will see online. We just fit whatever we could get here on the screen. So let's take a look through it. There's line number one. The job number is 5197 and the date information is there. Line number two has our login ID and the time. The third line you'll see has something called dollar sign HASP373. Whatever that is, that's got a whole story of its own and that's for the third line. The fourth line shows the abend number 806 and the reason of 04. And on the previous slide, a lot of the information just repeats itself. Now, we're going to take a look at something called a system 806. The System 806 is that the program did not compile and link successfully. The program name could not be found, so therefore it probably was not spelled correctly or somebody thought they created a program but they didn't. And so you want to take a look at the JOBLIB and STEPLIB statement in JCL because sometimes it's not pointing to the correct library that does indeed contain the load module. On this screen we have something very famous. You might look at it as S0C7, most people call it SOC seven. It happens a lot and it happens because of an arithmetic calculation that's not working. So the first thing you want to do is review the first dozens of lines in your JCL to discover what went wrong. Consider some of the possible causes and use a display statement if necessary to see if the fields are indeed numeric. Let's continue with solving abends with listings. Number one is the Sysout is going to show you something called letter S followed by some numbers. And so getting the abend code is a good place to start. Second, you want to notice where it says name equals to see the program name, so you'll know which program has actually abended. Oftentimes there's several programs that are running in a JCL and you want to make sure you're looking at the right program. The third thing is to look up the system abend code to see what the abend means such as, I can't do a calculation because the number is not correct. Number four, develop some kind of a theory over why the operating system terminated your program. And then number five, try to find the offending verb, but that's not all. The JCL listing shows the hexadecimal address where the abend occurred. You might have been wondering why we're talking about hexadecimal things early in this course, but this is where some good things happen. When we get the information, the information is going to show us where the hex is happening. And in this situation, we have a hex lock of 000168 and that's pointing to a piece of code when you did a compile of your program and that's where the difficulty is coming from. So point number seven, once you have that information, you can go back to your compiler listing, go to the position called 168, and that's where the difficulty is happening that you can fix. Number eight, you want to find the verb closest to, that would be less than or equal to the abend location. That's the verb that actually caused the problem. And then number nine, you can always use a display statement and run your program again to see what the contents are of different fields. There's another category of abend codes, they begin with the letter U followed by four numbers. These are COBOL user abend codes and here are the ones that are most likely for you to encounter. You may want to pause and look at these for a few moments. I'll just mention a couple of them. The first one user 1020 is an invalid operation request made to file. In other words, what you're doing is you might be writing to an input file which the operating system is not going to let you do. Let's look at the last one, user 4038. You have a problem with either your input or your output. And usually there is a problem where maybe the logical record length is not correct or something like that. But again, feel free to take a look at these for a few seconds. Okay, during this lesson, we discovered that testing is crucial. So we need our ten steps for proper testing, the three strategies for testing, unit testing, system testing and regression testing to make sure that not only your program works, but if your program is sending information to another program that that works just fine too. We want to know several common errors and believe me, you'll memorize them [LAUGH] over time. We want to utilize forensic information that we have, that we get from abends and to know common abnormal end codes and their meanings. Hopefully, this will help you in the early parts of your career.
