Someone once said that, in computers, the only three numbers that make sense are zero, one and infinity. This means that something should either never happen, happen once, or be allowed to happen an unlimited number of times. Although this is a good ideal to strive for, the limitations of the hardware often make infinity unrealistic.

Still, some limitations are so nonsensical that they irritate the user every time. I've been working with IBM computers for the past nine years, and in all this time I've accumulated a large stack of minor inconveniences and irritants caused by limitations, restrictions and inconsistencies in operating systems, programming languages and utilities created by IBM.

For example, when I wrote a program which uses the Start QM Query (STRQMQRY) command, it never occurred to me that IBM would plant one of its infamous limitations on me. I coded away merrily, creating a value for the SETVAR parameter of STRQMQRY that contained more than 1000 characters. No problem, right?

Wrong! IBM did plant one of its limitations, and a very short one at that, since SETVAR cannot accept more than 55 characters. Now, fellows, where do you think this 55 comes from? Is it the speed limit on the interstate? I could understand a limit such as 256, 512 or 1024, but fifty-five?

Another example just came to my attention recently. Among the enhancements for RPG in V2R2M0 is one which deals with the date edit code (Y). It has been expanded so it allows eight-digit fields to be edited; a date such as January 1, 1993 shows 1/01/1993. Well, it turns out that if you define a field using DDS, it doesn't allow edit code Y on numeric fields unless they have between three and seven digits. Worse yet, according to IBM's Level 2 technical support, there are no plans to rectify the discrepancy.

There are more problems:

o Why are the CMD and RQSDTA parameters limited to 256 characters in the Submit Job (SBMJOB) command? Command strings can be much longer than that.

o Why does the operating system have a problem with parameters greater than 32 bytes in length containing trailing blanks? When those parameters are passed via the CALL command, the program can end up with garbage beyond position 32.

o Who decided that commands could pass a maximum of 75 parameters to their processing programs, and why? CL can't accept more than 40, and RPG/400 allows as many as 255.

o Although DDS lets you define null-capable fields, what's the point if programming languages can't use them? Only SQL/400 can recognize a null value as such; all others read null values as blanks, zeros or whatever the default value for the field is.

o If you end all subsystems from the system console and mistakenly sign off, you lose the console-and the only way to regain control of the system is by IPLing from the control panel.

I could go on, but why bother? Some of these problems can be ignored easily, although they still annoy you like a splinter stuck in your thumb. Others are major problems that, amazingly, are never corrected. It's time IBM got its act together. IBM earned the Malcolm Baldrige award for quality, didn't it? IBM makes great hardware-there's no question about that. Although it's been said that IBM is only good at hardware, I still think that its software is decent; fixing these problems would actually make it good.

Ernie Malaga is a senior technical editor at Midrange Computing.