Bullet-Proof Excuses

By Bob Green

When dealing with software vendors, I sometimes feel that some have developed a bullet-proof strategy for deflecting complaints. First line of defense seems to be that your problem is not really a problem: “That’s not a bug, that’s a feature.”

For example, the HPCICOMMAND intrinsic allows a user program to run other programs by executing a :Run command. However, if the program is one like Qedit that suspends on Exit when it detects that the parent is not the Command Interpreter (so that the parent process can reactivate it later), there is a big problem.

The Qedit child process is hung suspended and will never go away until the parent process is killed. You can try this yourself by running Qedit inside :Editor and doing :showproc to see what processes you have when you Exit back to :Editor. When we suggested that HPCICOMMAND should detect such hung processes and delete them, we were told that suspending was a feature of the Activate intrinsic.

If the user has the luck to find the spot in the manual showing that he is right, there is still a fall-back excuse: “That’s an error in the manual.”

With those two answers, a programmer can deflect any conceivable bug report.

Such a “feature” of MPE is responsible for the longest-running problem report at Robelle. A batch job can log onto another MPE system by doing aRemote Hello Command and creating a remote session. But, if the job runs Qedit (or any program) on the remote system, MPE tells Qedit it is in an interactive session, not a batch job. If you want to verify this for yourself, try #showvar HPINTERACTIVE in the remote part of your job stream.

Qedit cannot tell this phony session from a true session. So Qedit runs in interactive mode (prompts for answers, etc.). Of course, you can solve this by putting a Set Interactive Off command in your Qedit job, but to me it is still a problem.