[MUSIC] The path that a program takes is sometimes referred to as its logic. Does the user want to enter more data? If yes, then we'll jump to the part of our code where we'll let them put in more data. If they're done, then we'll jump to the part of our code where we're going to process that data. It's kind of like hitting a fork in the road, and we use what we know to inform that decision. Maybe you want to look at a bunch of accounts and find the ones that haven't been been updated in the last 60 days. In that case, we're taking the difference between the most recent update and today's date, and comparing that difference to 60. Presumably, if the difference is greater than 60, then we're going to do something special with that account. That's all logic. And unless we insert our own logic, a program is going to run from the top to the bottom until it's done. So we need to learn how to express what we want to happen in a program's logic. Three of the most common types of COBOL conditional expressions are general relation conditions, class conditions, and sign conditions. And a lot of these are fairly simple. It's taking two operands, comparing them to one another, and saying, is this greater than that? Or is this equal to that? Or saying, is this numeric? Is this lowercase? Sometimes because of the way our logic is structured, we'll want to say, is this not numeric? Because maybe we asked the user for a number and we got back something like XX. And we need a way of saying, if this is not numeric, go and prompt that user again and remind them we're looking for a numeric answer. So whenever you're writing a conditional expression, they typically start out with is, and then there's a test or a comparison afterwards. And you can, between the test and the comparison, throw in a not to flip that logic around. There's another important and powerful tool you have in writing program logic known as conditional names. These are used primarily to say the input we're taking needs to pass this test. A conditional name is declared in the working storage section with an 88 level number. In this case, it has to be an 88 level number. We use a conditional name to say the variable that I'm under needs to match this. And it can be a literal, a series of literals, or a pattern, or anything like that. And it's a good way of verifying user input. And again, it always has to be an 88. Take a look at this example. We move AZ into USA-STATE. Then we enter this if statement, IF STATE. The only way this will pass as true is IF STATE evaluates as true, which in this case will only pass if it's equal to TX. So we're going to say the state is not Texas. Then here we're moving TX to USA-STATE. That will pass because it matches that 88 conditional statement, it equals TX. Why would we do something like this? Well, imagine instead of just putting in one state, we put in all 50. Then make sure somebody didn't put in something like ZZ or 1 2 as their state, or something like that that didn't make any sense. So we can use conditional names as a way of validating or limiting data before we try and do something with it. There are other ways of implementing this type of logic, but being able to have one place to define the scope of the data for a test is quite handy. If we're comparing values like if this is greater than that, we use conditional operators, and those include is greater than, which can be written out as > sign. Remember those alligator mouths. Or is equal to, which can be written out with the = sign. We can also say is greater than or equal to with >=. We can take that concept and put it to use in conditional expressions. That's where we put those if-then-else statements to use. And you're probably already familiar with those concepts, either from another programming language or just from everyday talking logic. If it's nice out, then I'm going to go for a hike. Else, I'm just going to stay inside and play video games again. We've defined two possible outcomes and what will inform that decision, the weather. In code, we might write something like this. If facial expression is happy, then say hey, I'm glad you're happy. Otherwise, say, what can I do to make you happy? Obviously, we would want this program to actually do stuff if you're happy or not happy, maybe clap your hands, [SOUND] but this shows a basic if-then-else statement. We have another way of doing this that's more useful if there's more than two paths, and that's an evaluate statement. We set that up like this. First, we evaluate facial expression. When it's happy, we do this. When it's sad, we do this. When it's perplexed, we do this. And we can keep on going until we've run out of possibilities. And then we hit the end, where we just say END-EVALUATE. This comes in handy for menu type items, like press 1 to show account balance, press 2 to make a withdrawal, press 3 to transfer money, etc. Each one of those could be a when in this big evaluate statement. Another thing that happens quite often in programming is performing some sort of function or a set of steps until something happens. Maybe it's processing files until we've reached the end, or adding stops to this truck driver's route until the truck is full. If we're iterating over data, specifically, tables, trying to find a specific entry, we can use search statement. That syntax looks like this. Search the facial expression table until you found the index marked happy, then presumably, we do something with that record. Although in this example, we issue a STOP RUN. So I guess they found happiness and there's nothing left to do. Let's get back to those conditions. You know we can say if this number is equal to that number. That's a test of the relationship between two operands, which can be numeric or text. We can also use conditions to test the content of a data item, like, is numeric, or is not alphabetic lower, or even is kanji. And for numbers, we can say is positive, is negative, and is zero. And just so you know, we're really only skimming the surface here. To read more about all these conditions, visit the IBM Knowledge Center for Enterprise COBOL. There's links for that in your material. We're coming up on that time, time to put what you've learned to use in a lab. And we're still working on those reports. This time, we're going to add in a special case if we happen to be in the state of Virginia, which will result in a special entry in the last line of your report. Good luck, and I'll see you back here when you're done. [MUSIC]
