13. The zip code file
One thing that bothers me is unnecessary work. If I’m at a web site and ordering some stuff to build a time machine, I’ll probably have to enter some address information so they’ll know where to send the materials. This includes street address, city, state and zip code. I can understand entering the street address, but wouldn’t just keying the zip code relieve me of inputting the city and state? This is so because each zip code is tied to one specific state and city. With that in mind, this means that our account number file need not have all three of these fields on file records.
Sly in accounting wants a simple online program – not the one we talked about earlier – to list account number, last name, and the address fields. The following program will do that using a new file, the zip code file. Our account number file no longer carries the state and city, so we have to get it from the zip file. The advantage of this extra read could be used in adding or changing records to our main file – especially if we changed city, state or zip code. Any specific change of this type could cause problems since modifying the city or state could mess up the zip code. Changing the city from Buffalo to Boston means that the zip that you had on the file is not appropriate for Boston. This means that a change to the city needs a modification to the zip code and perhaps to the state as well. Obtaining city and state from the zip code file can make things more precise and also save work for the operator – and the programmer, as well. Another advantage of accessing the zip code file is that the operator can’t input an invalid zip code on an add or an update.
You might say that the extra reads of the zip code file may slow down the system but file access these days is quite fast so it shouldn’t be a factor. If it is though, the city and state could be stored on the account file since disk space is so cheap and available and this may be preferable to extra I /O. It really depends on your system. You will note that the accuracy of the data on the zip code file is very important and someone is responsible for it. Once again the data is in the hands of individuals and we will assume some integrity on their part.
Another possibility is to put the zip code data into a large table, which our program can access. This method of getting information will be much faster than getting it from reading a file since the approach is internal as we have the city and state available already and need not do any I/O to an external file. Once again the table will change but many systems keep up with this change because the table is dynamic. This means that we bring it into our program as it currently exists so that all the latest changes to it are included. I’ll talk about a topic related to this in another chapter when I get into copy members.
This program is named after the requester.
program-name: acctsly
define file acctfile record account-record status acct-status structure
account-number integer(9)
last-name character(18)
field character(58)
zip-code integer(5)
field character(10)
define file zipfile record zip-record status zip-status key zip structure
zip character(9)
city character(15)
state character(2)
define error-msg character(60) value spaces
screen erase
screen(1,26) “Sly’s account number inquiry”
screen(4,20) “account number:”
screen(6,20) “last name:”
screen(8,20) “city:”
screen(10,20) “state:”
screen(12,20) “zip code:”
screen(22,20) “to exit, enter 0 for the account number”
input-number: input(4,36) account-number
screen(24,1) erase
if account-number = 0
go to end-program
end-if
read acctfile
if acct-status = 0
perform get-city-state
screen(4,36) account-number
screen(6,36) last-name
screen(8,36) city
screen(10,36) state
screen(12,36) zip-code
else
if acct-status = 5
screen(24,20) “the account # “account-number “ is not on the file”
else
error-msg = “account file read problem; program ending – press enter”
go to end-program
end-if
end-if
go to input-number
get-city-state: zip = zip-code
city = spaces
state = spaces
read zipfile
if zip-status = 5
screen(24,20) “that zip code ” zip “ is not on the file”
else
if zip-status > 0
error-msg = “zip file problem; program ending – press enter”
go to end-program
end-if
end-if
end-program: screen(24,1) erase screen(24,20) error-msg input
end
Everything should look familiar since we have no new keywords. The account number file has been defined a bit differently, but it’s still the same file. We’re using a new file that has three fields, the city, state and zip code. That’s the zip code file. Any read resulting in a not found record for either the account number or zip code file, will produce an error message, but allow another try for input. A problem other than that ends the program with an error message. Variables won’t be displayed on the screen as requested by Sly if there is a zip code problem other than a not found. That’s because the branch will be done to
end-program
first.
It’s time to return to our brain challenge of the previous chapter. To begin with, if you divide the tablets into 4 on each side of the scale, you will need three weighings, and not two. So why not place three pills on each side of the scale. If they do balance, it means that the poison pill is one of the two remaining so just put one each on the balance and now you know which is the bad one. However, if the three versus three match results in one side weighing more than the other, you know that the poison pill is on the side with the heavier ones. From those three take any two and place them on the scale. If one weighs more than the other, you have the culprit but if they weigh the same, the poison thing is the pill you left out of the last three. Thus you have found the undesirable pill in a mere two weighings.