IBM's got us all by the short hairs. We all live through it and probably by now accept it as a fact of life. We don't think twice about it anymore. We may not even know if it hurts.

Accepting IBM's control over your company probably starts with the acquisition of your first computer. How many of you asked, "What are my choices in an operating system?" Not many, I bet. I'm certainly not implying that OS/400 is not a good operating system. On the contrary, OS/400 is one of the better operating systems around. But, the fact remains, you have little choice of the operating system for your midrange and, therefore, the price of that operating system becomes less relevant and you can be charged more for it.

Now, with the implementation of security level 40, IBM is tightening its grip on you. Security level 40 does little for security; its main purpose is to deter competing software from the market. Let me explain. Some months ago, the trade journals were filled with stories about IBM becoming a much bigger player in the multi-billion dollar software industry. IBM is strategically planning that a majority of its future revenues be generated from software sales and service. Currently, the only worthwhile software IBM makes is operating systems and compilers, and I am not so sure about the latter but, again, there is little choice. It cannot sell any more of these unless it sells more machines, and that alone will not get it done. To succeed in its strategy, IBM must develop new software products for existing machines.

What does this have to do with level 40? Plenty! Presently, IBM's major midrange software product categories enjoy a virtually competitor-free environment. IBM knows it will be a different story with its future software products. So, IBM has effectively disabled the competition. And the weapon? Security level 40. With level 40 security now implemented, IBM has placed most of the competition at a different level, a level restricted to slower and less functional software. In many cases, developers can no longer use MI code to boost performance, while IBM is free to take full advantage of MI.

But weren't the APIs supposed to give back what level 40 took away? The APIs (A Propaganda Injection) were a cover-up. While the APIs do offer some flexibility to HLLs, there are too few, they are too slow and IBM is sluggish in responding to customers' needs for new ones. For developers to be able to do everything they did in the past at the MI level, the APIs must become a robust set of functions and their speed must be increased--a long way away from the current set of APIs.

IBM's definition of security level 40 is "operating system integrity." It assures that user-written programs do not read or modify objects at the MI level. It also guards against calls to most of the operating system routines (e.g., all those programs in QSYS). IBM's argument for level 40 is that it will keep hackers from gaining access to secured data, logically locking them out of files and other objects. However, this argument is not fool proof. If allowed physical access, a determined hacker will be able to hack his way around level 40 security. If IBM really wanted to protect you, it would have implemented object authority at the MI level; authority to an object would be checked when the MI program tried to read or modify data in the object.

Another argument for level 40 is to keep developers from accidentally modifying the wrong area of an object at the MI level and, thereby, jeopardize the integrity of the operating system. Speaking from experience, you can do just as much damage with an accidental DLTxxx, CLRPFM or an RPG DELET operation on the wrong record or file. As anyone who has programmed in assembler knows, accidentally changing one wrong bit can bring down the machine, but deleting one of those programs in QSYS could do the same. Besides, MI is almost a full level above common assembler and it would take a lot of intentional, devious work to bring down an AS/400 in MI.

The funny thing about level 40 is that it doesn't protect all objects. Only certain, albeit most, object types are protected from reads and modifies at the MI level. These objects are said to be in the system domain. Objects in the user domain are not protected. One object type that is in the user domain is *PGM (user-written programs). It is interesting to note that although that hacker cannot access your data files at the MI level, he can modify, damage or destroy the programs that operate on those files! Since user-written programs are in the user domain, they can be manipulated at the MI level, even at level 40.

Level 40 has not made the AS/400 much more secure, but it has--in essence--put the entire competition at a disadvantage. Let's look at a simple example. Say you are developing the "ultimate work with objects" utility. The first action the application will take after the user has started it will be to display the first screen full of object names. When done at the MI level, this action will consistently perform with subsecond response times. If you use an API to handle object name retrieval, response times will most likely range from 1-5 seconds or more, depending on the number of objects in the library. At the MI level, you can retrieve the first 13 or so object names directly from the library object (something like reading the file allocation table in DOS). That's it, 13 "reads," one screen. In fact, there is an MI operation code that handles the "reads." It is also impossible to modify anything with this operation code. Yet, it is not allowed at level 40.

The API version, on the other hand, will have to create a temporary place on disk to store data (a user space), call an external program (the API) that will read every object name in the library and write every object name to the user space, then retrieve the portion of the user space that contains the first 13 object names--all before displaying the first screen (a good analogy is filling up an entire subfile before displaying its first page). If the library contains a substantial number of objects, it should be plain to see the performance problem you will run into. Security level 40 has taken away a powerful MI op-code that is of no security threat and can in no way damage the integrity of the operating system!

Did IBM make the correct business decision? Well, yes and no. Objectively, implementing security level 40 was a brilliant business decision; one sure way of winning is to eliminate the competition. But subjectively, it may have gone a bit too far because one sure way of losing is to hurt your customers, and level 40 will severely limit your future software choices and the surviving software will suffer in performance. How many customers will IBM lose as a result remains to be seen but one thing is certain--IBM's got you by the short hairs, alright. The only question left is, "does it hurt yet?"