(Patches 750-1 thru 750-5 were specific to certain custom subroutines-- READAT, DIV2, ZCLOSE, JPSORT, SARSEQ, MPSCOM--that don't warrant further documentation here. 750-6, however, is of more general interest.)
1. Correct a compiler 'bug' in the order of precedence between the unary plus/minus and exponentation operators. A-Shell was giving the unary plus/minus operators precedence, but under AMOS, exponentiation had higher precedence. For example:
A = -5^2
A-Shell was evaluating the expression as (-5)^2 = 25, whereas AMOS was evaluating it as -(5^2) = -25. A-Shell now matches AMOS. Note that this was a compiler problem and not a runtime problem, so you must recompile to take advantage of the fix.
2. The "^^^^" field in PRINT USING masks is now supported. This set of four caret symbols may be appended to a numeric mask to output a number in exponential format. Examples:
? 1234567 using ".####^^^^" prints .1235E+07 ? 1 using "###.#^^^^" prints 100.0E-02 ? -12.34 using "##.###^^^^" prints -1.234E+01
Note that the most significant digit is place at the far left of the mask (just mast any minus sign) and if necessary, zeroes are added to the right (as in the 2nd example above) or rightmost digit is rounded (as in the 1st example above), and the exponent is then adjusted accordingly.
3. A problem with GET and FIND statements (ISAMPLUS) relating to numeric key types has been fixed. The problem occurred when the key value was specified as an expression rather than a variable. For example,
FIND #CH, ISAM'KEY(0) >= REC[1,N], RKEY$
If the primary key type was binary or integer, the above statement did not work correctly because REC[1,N] evaluates to a string expression rather than a raw variable location. ISMUTL.LIT was using an expression similar to the above example to initiate the DUMP operation and thus was not always starting at the first key in the case of a numeric key type. (This is turn would have given the error warning that the number of records dumped did not match the number of records in the file.) This has now been fixed, although it is worth noting that you must specify a variable of the correct size and type when using GET or FIND with a numeric key type. (You may now also use a substring expression on an unformatted variable as in the example above, providing the length of the substring matches the key length.)
