[MUSIC] The signal instruction causes and unusual transfer of control in your exec is used to set traps for certain types of conditions. When the condition occurs, the trap is sprung and control is immediately transferred to a label of the same name as the condition trap. To turn the trap on, the instruction is signal on, to turn the truck off, it's yep, signal off. Multiple conditions may be set at once, but each one must be turned on or off by separate signal instruction. Typically, conditioned traps are turned on at or near the beginning of the program. But they may be turned on and off whenever and wherever you wish. When the trap is sprung in the middle of a control structure such as a do loop or an ear for a select structure, REXX forgets about the control structure when control is fence transferred to the trap label name. This means that if after handling the error condition you transfer control back up into that control structure, REXX will issue an error when it encounters an instruction it doesn't expect. So for example, if a trap condition is sprung in the middle of a do loop and you transfer back into the loop after handling the error, REXX won't know what to do when it sees the end instruction because it forgot that it was inside a loop. For this reason and some others, these error handling routines typically report errors, cleanup and exit the exec with a non zero return code. Here are the five condition trap names. NoValue, springs its trap when an uninitialized variable is encountered. In other words, a variable whose value is the variable's name in upper case. Error, springs its trap when a non-zero return code is issued by a host command. REXX instructions do not issue return codes, host commands parsed outside the REXX interpretive execution do set return codes. Failure, springs its trap when a negative return code is issued by a host command. If both the error and failure traps are set, then error will catch return codes greater than zero and failure will catch return codes less than zero. Hold, springs its trap when someone tries to interrupt the exec by pressing the PA one key and then entering the HI command. Syntax, that says signals is trapped whenever a REXX syntax error or a runtime error is encountered. As REXX was originally defined uninitialized variables were given a default value which is the same as the variable name in upper case. Use of this rule, it can lead to logic errors and sometimes perplexing program flow. These errors are often hard to diagnose as the system may detect an error and point to somewhere else from the true error location. So the signal on NoValue instruction was provided to remove this situation and replace it with a new rule. All variables must be assigned a value before they are used. A reliable exec always checks every return code that is issued by host commands executed from within the exec. The REXX interpreter does not check return codes automatically. And if a command fails, the exec keeps running. Of course, the output or result of the command is normally useless, so the exec will probably encounter some unpredictable failure because of this. The REXX special variable rc, is automatically assigned the return code from a host command. This is a volatile variable it will be overlaid with the next return code that is set. This means that if a return code is important to you or you want to check it later, you must save it in another non-volatile variable before the next host command is issued. The Signal On Error instructions springs it error trap whenever a non zero return code is encountered. So it can be a great deal of help here. But be aware though that there are commands that you will issue where you're expecting nonzero return codes. In those cases, you must turn off the trap before issuing these commands then. Turn the train track back on again afterwards. Now, here we show the IBM conventional return codes for IBM products and ZOS. As you can see, the higher the number, the worse the error, of course with return code zero, optimistically titled complete on ambiguous success. That does not mean that you've got the results that you were really looking for. What it really means is that you didn't violate any of the operating system rules of execution. In your own race exists, you do not need to restrict yourself to the values shown here on the visual. There are different rules restricting return codes depending on your software environment. If you do use unconventional return codes, you should put comments into your exec to describe what the return code means and also issued meaningful error messages describing the error. Now, that we've written some examples in the next video, we will be asking how much recovery and integrity should we worry about building into them. [MUSIC]
