OK. After all that bad publicity in the latest Z-News, I just had to dig into the flow control code and find out why "$1=//" was not the same thing as "//=$1" (we all know that equality is commutative, right!). Well, here is the scoop. The transient IF.COM flow processor for ZCPR33, called Z33IF, implements a large number of extended conditional tests. Among them are the following (run "IF //" for a full help screen listing them): IF > token1 token2 IF GT token1 token2 IF <= token1 token2 IF LE token1 token2 These tests follow the conventional testing syntax in which the test operator is given first and the operands follow. These tests perform any possible ordering test on two tokens using the ASCII ordering. The extended test that caused the trouble Frank reported is the pair IF = token1 token2 IF EQ token1 token2 The second form is quite unambiguous and reliable. The first form, however, can get confused with the older equality test using the syntax IF string1=string2 The latter form requires that there be no spaces between the strings and the equal sign, so that the entire expression will appear as a single token (group of characters without intervening spaces). The trouble arises when the first token is null (no characters at all). Then the test expression looks like IF =string2 To avoid confusion with the extended syntax, Z33IF10 looks for the equal sign beginning in the second character position of the first token in the command tail. With the null string1, the parser does not recognize the expression as the old equality syntax and treats the expression "=string2" as a condition and looks up the first two characters, the equal sign with the first character of the operand, in the condition table. Usually it will not find it and will report a "bad condition" error (if by chance it is recognized, things may be even worse). There are a number of ways to deal with this difficulty. Frank suggested a perfectly good one: put the non-parameter token in the first position and the parameter in the second. Another similar approach (one that I have to take on my IBM 3081 mainframe, which is incredibly dumb by micro standards) is to include a fixed character with each token, as in IF .$1=.// The trouble with those two solutions is that they are easy to forget. Slightly better is to simply and permanently forget the old syntax and always use the "IF EQ .." form. That is what I do. With that there is no doubt about its working. The real solution, of course, is to make Z33IF smarter. I am sure that could be done, but I did not have the energy (or think it was worth the trouble) to do that, so instead I performed a relatively quick hack. I made it possible to set an equate to specifically exclude "=" from the list of extended tests. For "GE" you can still alternatively use ">=" but for equality testing you must use the "EQ" form. The equal sign is reserved for the old syntax. This solution is implemented in Z33IF11. I hope this will restore my tarnished reputation among the ultra-alias hackers! Jay Sage, 08/31/87