The only way to truly understand the concepts described in earlier sections is have a look at the code that makes up the payroll application. If your code, there were two programs, paper gum and PAYBUS, that make up the presentation and business logic of our application. Pay program is the presentation logic program that collects information from the screen, which includes the users desired function and passes it to the business-logic program for processing using a click-links command. They communicate for our commarea, the communication area which will explode fast. The commarea, appears in the book and storage section of paper gum This field name specified under the linkage section of paper gum is a placeholder for future invocations. In papers to the fields appear under use through the linkage section. The reason for this is the paper gum will create the commarea out of working storage fast time three with the initial values. On subsequent requests paper gum will move the data from linkage to work in storage to process any of the field data. This is a standard that can be seen in many kicks programs. Looking at actual fields in commarea, the first-time buyers need to be collected and passed to the business-logic program PAYBUS. Most specifically the full byte request followed by a one-byte poly and a five by employee number. This makes up the data that needs to be collected from the user. The remainder of the commarea is either data from the record being retrieved and displayed on the screen or a set of one byte indicators to provide the state information. They are represented as flax and can either be an n or y. Initially that offset to be n. As we progress through the program logic, we will see when they change. Next, let's have a look at the first time three processing. This processing will be different depending on the program has preference or if commareas are not used. For example, if you use channels and containers instead, otherwise, it's most common popular method of determining fast entry into the program. The first bit of code is to get the time and the date using kicks demands. These are displayed on the screen every time the user presses a key, stay appear at the top of the procedure division. The EIB, or execute interface block, which was explored earlier on, is automatically inserted into kicks programs. It has many useful fields on entry. One is EIB, C-A-L-E-N, which contains the commarea length. If the commarea length is 0, there is no commarea. This is the first time through using commarea. Otherwise, the user ends this task with a commarea, which we will see. Then on subsequent cools, it will never be 0. The first time through this program, the BMS map is proact with the time, the date, and a message the user to enter some data and then the map is sent. This is the return command with trying ID and commarea option that is most interesting. You can see that the return is nominates in the next transaction to run using EIB trying ID, which is the current transaction ID. This means should they use a press enter or function key, the very same transaction PIY AGU run. You can see how the commareas be passed to the next implication of this program is coded. Now we will expose and standard programming founded a presentation logic program. We will start with an evaluation of the function requested and move on to receiving the data from the screen. As you can see from the evaluate statement, the key that the user process is passed to the kicks program in an EIB failed, put EIB AID. The program structure to evaluate the key and set the request based on the key pressed. Once done, subroutine routine code debug is performed. Then you can see a familiar kicks return segment that nominates the successor transaction with commarea in place. The dirac paragraph starts by getting the data, the use entitlement screen indicates received MAC command. In older versions of code an unrecorded map file will be possible if the user did not enter any data as kicks mounts were coded not to return fields that were empty. This was to avoid data transmission that blank fields. Today the number five transmission is considered so small is more efficient to send all the fields entered or not than it is to run through the code to test if the field was entered. The next section of code is all about food validation. Again, this program has been structured very simplistic validation. Most real-life examples will have various complex routines to validate data entered by the user. As this application requires a one-byte apartment number and a five by employee number to proceed, this program simply ensures that those fields have been entered and they are numeric. If I knew the fields are invalid or missing in the cursor is placed on the first invalid field. The screen is resent to the user with the message indicating a problem. Once the input validation is complete, this program will leave any fields that have been answered on the screen to the commarea. This is the business-logic can then process them. Keep in mind that most fields on the screen are protected not allowing user to enter data. However, depends on function we requested such as an add. The fields could have been unprotected, allow an input. The longest of if statements are simply checking to see if a field has been entered. The program accomplishes this by checking the length returned from the received mount issued earlier. If the length is greater than 0, there is data to update in the commarea. Notice other program also updates the flag associated with each new field from an N to Y. This would notify the business-logic program that the data is new. Last piece of the code is the code to the business-logic papers to process the request. Is it kicks link command where the data impulse is all commarea. We often explore the business-logic at this point. Let us see what the presentation logic program does once the business-logic returns to it. Keep in mind, the after the link is complete, we still need to check that the command executed properly. This screen starts by checking the time code from the link command of the prior screen to see if it executed successfully. If not, you can see some common logic to return the error to the user screen. If the command is self worked, we still need to check if the business-logic programmer tandem era by check-in and error indicator flag. If so, we return that business specific error message that was provided by the business-logic program. Achievement of thing about to this point, we simply have some presentation housekeeping to do prior to return and the results of the request back to the user. As mentioned earlier, most of the fields on the screen and protected until there is a need for the user to supply input. In our application, this is only required if the user updates and employee payroll record all adds a new employee. In their specific cases, we need to modify the screen or respondent unprotected fields. The current Hayek who's routine to do protection and protection of input fields as required by the processin. It then sends that result to the user.
