To IOCB ~or~ Not To IOCB
Open communications with I/O Control Blocks
by MARK GRICE
Input/Output Control Blocks, commonly referred to as IOCB's, are probably the most versatile utilities the programmer has for extracting and storing information. Quite a few novice programmers shy away from them because they seem to be cumbersome and hard to understand, but they're really quite simple.
IT'S CHILD'S PLAY
When I think about IOCB's, I often recall a TV show I used to watch as a kid. It was called "Davy and Goliath." The main character, Davy, often communicated with his friends by using two Campbell's soup cans that were tied together with a string. I don't know if you've ever tried this method of communication, but I have. And in the process, I learned a number of interesting things about it:
1) Before you can talk, you need to give an end to each of the parties involved.
2) Only one person can talk at a time. Because of this, you must decide whether you will talk or listen before the communication starts.
3) Before someone else can use the cans to talk, the first two users must end their communications.
These may not appear to be startling revelations, but if you understand these three simple rules you will have no trouble using IOCB's.
THE ELEMENTS OF AN IOCB
An IOCB always starts with an OPEN command, and looks something like this: OPEN. #2,8,0,"C:". The elements that make up this sample command work as follows:
OPEN #2, -- This sets up a line of communication (think of it as one of the cans, along with the string) that originates in the computer. This is called line #2.
8, - This tells us that we will be outputting (or, as in the tin-can example, talking). A four in this position means we're inputting; a six means that we're inputting a disk directory; a nine means that we're appending a file that's already in existence; and a twelve can mean that we're either inputting or outputting.
0, -- This tells us nothing, in most cases. It's just there. I know alot of you are screaming, "Why?" but I'm going to hedge on this anyway. Suffice it to say that there is a purpose for this part of the command, but that it's used so seldom for this purpose that it's not worth going into. Over 98 percent of the time, this number will be zero.
"C:" - This is where the IOCB stops. It designates the other end of the IOCB channel -- who gets to use the can at the opposite end of the string, in a manner of speaking. (In disk operation we'd also need a filename here, so the command would look something like this: OPEN #2,8,0"D:FILENAME". In disk I/O, by the way, opening with the number eight will wipe out whatever was in the file previously, while opening the number nine will cause the program to start writing on the next available sector on the disk, regardless of how much room is left in the previous sector.)
A LINE OF COMMUNICATION
What we have now is a line of commucation from the computer to the cassette recorder (for the purposes of this article we'll assume that a cassette recorder is being used for output). Again, this is called LINE #2. The computer is doing the talking; the cassette is listening. A short subroutine using this line might look like this:
20 PRINT "ENTER THE STUDENT'S SCORE"
30 INPUT SCORE
40 PRINT "THE STUDENT'S SCORE IS:",SCORE
50 OPEN #2,8,0:"C"
60 PRINT #2;SCORE
70 END
Line 50 has already been explained, Lines 20 and 30 are pretty straight forward, and I don't think they require any further explanation. In line 40, we print the score in the regular fashion, to the screen. Line 60, however, prints the score to IOCB #2. This time, the information doesn't go to the screen - it goes to the cassette, instead. Why? Because we've told the computer to PRINT #2.
Going back to our example of the tin cans and string, the scenario would look like this:
Davy is holding the tin can. On the other end of the string is his friend Bob. With Davy is another friend, Jane. She is planning a picnic, and wants to invite Bob. So Jane asks Davy:
"What time should we hold the picnic?" (20 PRINT "WHAT TIME IS THE PICNIC?")
Davy thinks about it for a moment (30 INPUT ANSWER)
"Oh, about 3:30," he says. (40 PRINT "OH ABOUT,":ANSWER)
Then Jane says, "Better tell Bob." So Davy picks up the can (50 OPEN #2,8,0"C:") and says "Hey Bob, the picnic is going to be at 3:30." (6O PRINT #2;ANSWER)
I hope I haven't insulted anyone's intelligence with my examples, but honestly, that's all there is to it! Anything connected to your computer can have an IOCB attached to it. This includes printers, cassettes, disk drives, the keyboard, or even a TV (ever heard of a light pen?).
A FEW QUICK RULES
You can number your IOCB's using any number between one and seven (i.e, line #1, line #2, line #3), but you should avoid using the number 6, because it is sometimes used by the Operating System (OS). For example, have you ever seen a line like the following?
10 GR. 2: PRINT #6; "HELLO"
In this example, the OS opens an IOCB to the graphics screen rather than the text screen.
When you're finished within IOCB, close it. An END statement will close all IOCB's. This ensures that all of your transmissions will be received by the output device (in technical terms, it empties the buffer). If you don't close your IOCB, there is an excellent chance that some of your data will be lost. To close an IOCB without ending the program, use the CLOSE statement (e.g. CLOSE #2).
Finally, after an IOCB is closed you can open it again to another device, but you cannot have the same IOCB opened to two devices simultaneously (just as Davy couldn't have had one string attached to three cans). For more information on IOCB's, read your Reference manual.
A FINAL EXAMPLE
Here's one last example of how you can use IOCB's effectively. The situation is as follows: you have to create a menu program that is to be used by someone who is not terribly bright. There are two things he just can't seem to remember: 1) That when you ask for a number, he can't enter a letter; and 2) Where the [RETURN] key is located on the keyboard.
The first program you submitted looked like this:
10 ? "PLEASE MAKE SELECTION"
20 ? "1) CHOOSE ONE"
30 ? "2) CHOOSE TWO"
40 ? "3) CHOOSE THREE"
50 ? "ENTER NUMBER PLEASE"
60 INPUT CHOICE
70 IF CHOICE =1 THEN GOTO 100
80 IF CHOICE = 2 THEN GOTO 200
90 IF CHOICE = 3 THEN GOTO 300
However, you quickly discovered that this would never work, because every time your user ran the program, he either started a letter or forgot to press [RETURN]. An IOCB could help you tremendously:
10 ? "PLEASE MAKE SELECTION:"
20 ? "1) CHOOSE ONE"
30 ? "2) CHOOSE TWO"
40 ? "3) CHOOSE THREE"
50 ? "ENTER NUMBER PLEASE"
60 OPEN #1,4,0,"K:": GET #1,CHOICE
70 IF CHOICE = 49 THEN GOTO 100
80 IF CHOICE = 50 THEN GOTO 200
90 IF CHOICE = 51 THEN GOTO 300
95 GOTO 10
This method works like a charm! As soon as the user touches a key, the program takes off. No matter what the user does, he can only select a number. The explanation for this magic is that in line 60 we've opened up an IOCB for input (because the second number is a four) from the keyboard. The computer then treats this input in the same way that it treats any input: It simply waits until a key is pressed.
However, unlike the standard INPUT command, which must wait for a press of [RETURN] to tell it that an option has been selected, the GET command in this program takes effect after a single byte of information has been received. In this case, that single byte is always the ATASCII value of whatever key has been pressed by our hypothetical user.
By the way, using the IOCB GET command is not the same as PEEKing location 764, which I discussed in an earlier article (ANTIC, "I/O and You," page 16, July 1983). Location 764 gives you the interrupt value, which is the value you get before the OS gets its hot little hands on it. The IOCB GET command gets the value only after it is sent to the OS. This is why, in this case, the IOCB GET command returns the ATASCII value of any key that is pressed.
As a result, when we use this method we know for certain that we will end up with a number, rather than a letter, no matter what happens. So we can say goodbye to Error 8. Incidentally, if we want to print the selection that our user has made, we can do so easily by adding the following line:
65 PRINT CHR$(CHOICE)
In conclusion, if you want constant input that you can "grab on the fly," use location 764. If, on the other hand, you want simple input and you want the computer to wait for it, use an IOCB. Only after exhausting these two possibilities should you use an INPUT statement! Try them. I think you'll find that these two options will help make your programs much more "user-friendly."
Mark Grice, 22, is a self-taught programmer and computer tutor. He has trained more than one hundred students to program, and two of his former students are now professional software authors. Mark is also interested in robotics, and has built and programmed an Atari-controlled robot.