On Tuesday we learned that the binary numbering system was the basis for something called "bytes" which, in turn, made half-words (two bytes), full words (four bytes) and double words (no nibbles). A byte was eight bits of individual binary digits. Two hex numbers could be used to show the value of any byte which, therefore, ranged from 00 to FF. The binary number 1111 1111 was equal to FF in hex and 255 in decimal. So far, so good.
At this point our text wanted us to add and subtract in hex. To prove the solution, the book would transform the hex numbers to decimal numbers, perform the math, and transform the decimal back to hex. I don't know about the other students, but that's the way I learned it. It was just like speaking French. I translated the French to English, decided on a response in English, and then translated my response back to French. When I performed hex mathematics, I transformed the operators to decimal, did the math, and then transformed the answer back to hex. It wasn't the fastest or the best way, but it worked for me. Having instructed us on binary and hexadecimal numbers, bits, bytes and words; our text was programmed to proceed to the study of the IBM 360 Assembler Language, itself.
A BAL operation code, we learned, was one byte long. That meant that there were a maximum of 255 operation codes. Looking at the list of op codes, it seemed that they had used most of the 255 possibilities. But at least one operation was missing. Where was the Read? How was I going to get an 80-column card into memory? The text was silent. Instead, before teaching us about individual operation codes, it told us that there were two types of instructions. One type of instruction was privileged and the other type was normal. Aside from deciding that I really wanted to write only privileged instructions, the whole idea was lost on me. It was something to ask the expert.
As it happened, our expert had taught me Physics in high school a few years earlier. He didn't remember me and it was just as well that he didn't. I had been an uninspired physics student. He left teaching physics, joined IBM and, later, went on to lead IBM's development of OS/360. There could hardly have been anyone better to ask about privileged instructions running in something called the supervisory state.
In response to my questions, the expert introduced us to the supervisor call instruction (SVC). We could enter the supervisory state of machine operations, the place where privileged instructions were executed, be issuing an SVC and indicating the purpose of the call. For instance, if we wanted to read a card, we could write an SVC and request an input/output operation. With that, our problem programs were put on hold and a higher-level entity took over for us. Privileged instructions, it seemed, primarily dealt with input and output. In rapid succession, the expert mentioned PSWs (Program Status Words), CSWs (Channel Status Words), CCWs (Channel Control Words), and CAWs (Channel Address Words). All these words were needed to read cards, or any other device, for that matter. With a knowing wink, the expert assured us that we problem programmers didn't really need to worry about such things.