Rochester always has insisted on using ratings such as transactions per second to show the amount of work an AS/400 can perform. IBM Rochester has been a leader in helping to establish industry-standard benchmarks for transaction processing and has worked closely with the Transaction Processing Performance Council to create the TPC ratings for computer systems. These ratings also factor in the cost per transaction, based on the hardware and software prices for a given configuration. This lets a customer compare computer systems from various vendors on the basis of both cost and performance. Needless to say, the AS/400 has been one of the leaders both in cost/performance and raw performance using these benchmarks, because it is designed to do this type of processing well.

Interactive processing assumes terminals, such as the 5250, are attached to the AS/400. Functions such as updating the fields on a screen require many process switches, especially if there are hundreds or even thousands of these terminals attached. With the move to client/server computing in the early 1990s, much of this screen handling is processed in the PC (client), reducing the number of process switches needed in the AS/400 (server). But in client/server computing, many features still resemble interactive processing. With hundreds or thousands of users pressing keys or clicking mouses at the same time, each requesting some database I/O and then waiting for the response, rapid process switching is still needed in the AS/400. The AS/400 is able to leverage its strength in handling numerous simultaneous users (processes) with the data-transfer requirements of the client/server environment.

Other server applications are more compute-intensive. An example is a decision-support application where a large amount of data can be analyzed to create reports. Users are able to construct elaborate queries, answer “what if” questions, search for correlations in the data, and so on. The type of processing required for such an application looks more like a batch environment than an interactive environment.

Higher-performance processors were needed in an AS/400 for some of these server applications. For this reason, several years ago when we first introduced special models of the AS/400 designed especially for server performance, we put higher-performance processors and lots of memory into them. On various client/server benchmarks, the Advanced Server models have demonstrated that they are very competitive in the industry, both in price and performance. Not surprisingly, many customers find these models are also better machines for conventional batch applications.

Process switching is a heavily used function in either interactive or client/server applications, and a fast process switch is always better than a slow one. The single-level store not only improves process-switching performance, it also improves the performance of many functions by eliminating instructions to execute. Consider, for example, the file operations we discussed. A conventional server does many file opens and closes, causing extra disk activity, which reduces overall system performance. The AS/400 processes these files in place, eliminating the extra overhead. High-performance processors are important, but keep in mind that every instruction that does not need to be executed is equivalent to having an infinite-speed processor for that instruction. RISC processors are fast, but not that fast.

Pointers and Tags

Aside from performance, the biggest advantage of a single-level store is that everything can be shared; its biggest disadvantage is that everything can be shared. When every user in the system has access to the same single, large address space, some way must be found to guarantee that users cannot access or change something to which they are not authorized. In Chapter 5, we saw that pointers provide this protection in an AS/400. In this section, we look at pointers in more detail and see how they provide the protection.

The act of resolving a system pointer provides access to an object at the MI, as we saw earlier. Pointers are 16 bytes (128 bits) long. A resolved system pointer contains direct addressability to a system object, which means the 64-bit virtual address is contained in the pointer. Similarly, the other types of pointers (space, data, instruction, and procedure) each also contain a virtual address.

Pointers are contained in the associated space of a system object. Also contained in this space are data that an MI program can access and modify. Accessing and modifying the data in an associated space is legitimate; modifying a pointer is not. If an MI program could modify the contents of a pointer, we would have a potential security exposure. The address in the pointer could be changed to point to someone else’s object or to some other structure in the system where the program was not allowed to go. Of course, I am speaking here about a user-written program that directly specifies MI instructions; I am not talking about programs written in HLLs such as RPG or Cobol.

When we originally designed the pointer structure, we knew of ways to reduce this potential security exposure by eliminating the MI assembler, making certain instructions privileged, and taking the authority out of the pointer. As we saw in Chapter 7, we took these actions over time as we tightened the security levels of the AS/400. But even with these actions, a need still exists to protect the contents of a pointer from illegitimate modification.

We saw, again back in Chapter 5, that the associated space containing pointers occupies a separate segment in a system object. For the original System/38 design, we decided to use two segments, one for the data and one for the pointers. We were not happy about this approach, because it had an impact on system performance. Pages from both the data and the pointer segments had to be fetched when an object was used, and this increased our system overhead. Two segments also meant a slight increase in memory size requirements. The only reason we had planned to add the associated pointer segment was that we thought it could protect pointers from being modified by users. But we were wrong.

We soon discovered we could not protect the associated pointer segment from being modified. With the system security levels we had planned for the System/38 (up through level 30), a user who had authorization to an object could get into the object with the use of the MI assembler. Putting the pointers somewhere else in the object provided no additional protection, so we had to find another solution.