The business logic program is the core piece of it kicks application. It performs the functionality required by the application regardless of the user interface, and in most cases the data store. The business logic normally consists of a driver program that coordinates the execution of business logic, by invoking subsequent programs for different functions. In our case, it is all in one. This program is not only the entire business logic, but the data store as well. So let's have a look at what it does. PAYBUS receives data in its linkage section. This is passed by its cooler as a common area, in this case on an exact kicks Link Command. The first section of code in his program is special processing for 3270 presentation logic program. The program begins by resetting flacks, should be user interrupt function that is normally done in two sets using a 3270 screen. Data functions of add, update and delete. If the user starts an update, for example by pressing P, F4 on the 3270 screen, but then does not confirm the update with a second PF4, the flags in the command area need to be reset, to say we are no longer in the middle of an update. Once any special processing is complete, the business logic program will analyze the request and give control to the routine that process it, again, had this been a more complex application, this might be caused to other programs to process these requests. As we can see, the first step is an evaluation of the request. This is supplied by passing in a common area filled, based on the request type, the function is performed. The display routine is the first routine highlighted here. Is normally routine, that simply reads it backward and returns the content of the cooler. However, the if statement in the top implies it is also called from the forward and backward routine without first read new record. Therefore, this display routine is a generic routine for not only displaying record, but also used by other routines to move data read, from the visa on file into the common area to return to the corner. Lastly, know that an error from the brood commander assumes that the record was not found. Of course there are other errors to contend with, such as file not open as an example. We simplified the code here, however, it is good practice to consider all possible errors, and send a proper response. It is time to look at a more complex routine. It is recommended that before code in such a routine, a programmer should use the kicks application programmers reference manual, to determine the correct way to update a record on a V some file within kicks. The first complication with this routine, is that it's invoked twice. The first time will verify that record exists by calling the display routine, and present the record back to the cooler. This has two purposes. The first, we just mentioned, the second is simply to unlock the field on the 3270 display, so the user can update only those fields that they want to update. An example is reason a person's salary, the remainder of the record would remain unchanged, but only that filled would be updated. Clicks allows you to update your record by adding the attribute update from regular route command. When the update is coded, kicks expects the rewrite command to be issued next. Note that a key does not have to be passed as kicks assumes that you're updating the record from a previous read with the update attribute. The remainder of the code between the read, update and rewrite, is about only updating the fields that the user has changed. Leaving the remaining fields at the same as they were. This is accomplished by using and testing flags in some other cooler. There is also an additional piece of logic that collects and writes a timestamp into the record. Although not utilized in this piece of code, that idea is that if two people were trying to update the record at the same time, one of the users updates could be lost. In a production copy of this code, there would be an extra test to make sure that the timestamp of the record read and presented to the user, matches the timestamp of the record being updated. If it changed, the user be warned that the backward is change since they last saw written that the update would fail. The next question I would have as a programmer is what happens if the transaction bends or fails in the middle of an update? With the new data or the old data be displayed on it, look up. The answer is that it depends. The systems programmer controls whether it be some file was recoverable. If it is, any changes to the record of backed out a failure occurs, if this is not set, than the update will take place. Is therefore important to have discussion with the system programmer about an applications needs, when dealing with issues such as recovery. The next function is adding a record, it too is this two step process like an update, the first time through the app logic, the program simply checks if the record exists. If so, it sends back the record with the message that it's already on the file. If the record does not exist, this program will clear all the fields that required for adding a new record in return to the cooler. In the case of the 3270 presentation logic program, this gives it a chance to unlock the builds given the user the ability to enter the new fields. On the second request, it ask them are called presented by the user, now to also places a timestamp in the record as mentioned earlier for use with the update. As with an update, should a failure occur during the run of this transaction, the record may or may not be added, depending on the recoverability of the file. The next function to look at is a delete request. The delete request is also interesting as it's also two step process only user presses, Pier 6, to invoke a delete when entering in department, and an employee. First time through this, the program simply cause the display routine to return the record back to the cooler that they're about to delete. Press in PS six, the second time invokes the delete code. Interestingly, the first thing this program will do as part of step two, is a read with the update flag on the record about to be deleted. This is to ensure we lock the record, verifying that no other customers in the middle of an update. Once the read execute we have the record locked so you can subsequently delete it. Class, but code that we will look at in this program is the browse forward and backward, as code is practically identical between the two will describe the two together. The concept of browsing through keyed file is not new, but one that is used by many products, when accessing a keyed file. In the case of kicks, you can see that we start, with the start browse command. This command is presented with the key in which to stop browsing from, with the attribute GTE Q. GTE Q Means greater than or equal to. This allows the position of the pointer to the record requested or the next one, if this record does not exist. So, if a customer wanted department one, employee one and it does not exist, the system will automatically position the pointer to the next available record, for the browse forward and the previous record for the browse backwards, shouldn't not found conditionally returned, it means we're at the front or back of the file. So we will notify the user that there are no more records prior or after that key. The next step commands it finance fonts appear to be a bug. Why would a programming code, two of the exact same commands on one right after the other? Well, in this example they are rude prove commands, to browse backwards. However, you can check that if we're browsing forward, we still see two commands could read next. The answer in the case of reprieve, is that we already pointed to the next record to read. The first reprieve positions us at the current record, the next one backs up to the prior record. Had we not done two of these, we would end up leaving the same record over and over again. As you can imagine, read next works the same way, the first read next, reads the current record as hat is where we're positioned. The next read record, following the current record. Lastly, you can see then end file condition, means we're at the start or end of the flower depending on if we go forwards or backwards, so we return that error. Also a start browse holds a pointer to the file, is good code net cut to end the browse as soon as there are no more plans to browse the records. Ending the task would work as well, however, if someone added code this program and they didn't notice, we were still in the browse, it would cause problems in the future, therefore this program ends the browse it assumes it has no more needs to browse any more records.
