845.3.1. Fix a longstanding (since day 1) bug in all variations of the compiler, which permitted an unmatched ELSE statement to be compiled without error. The most common form of this occurred when forgetting the & in the following:
IF A=B THEN PRINT "A=B"
ELSE PRINT "A<>B"
Without an & at the end of the first line to continue it, it should have produced an error on the ELSE, but didn't. Instead, the ELSE clause was always executed, as if it was associated with a null IF clause that was never true.
845.2.1. Fix a display issue in the TRACE=LOCKS display of pending LOKSER-style locks in which it would report CH -1 and FILE ? for certain ISAM locks. The problem did not affect the program operation but undermined the value of the trace display for those situations.
*NOTE: The version of this patch posted on 7-Oct (and showing 7-Oct as the Release date in the About box) was incomplete. It fixed part of the problem but failed to link in the part the applied to locks placed during the opening of an ISAM file. Please replace with this version (which shows 8/Oct/2004 in the About box).
845.1.1. (UNIX) TCP-related adjustments to deal with the problem of zombie children accumulating in certain kinds of AlphaBasic server programs that use SUBMIT to fork children. Also, receipt of an external signal while waiting for a connection no longer aborts the wait.
845.1. 2. (UNIX) New miame.ini switch SBR=SUBMIT2 causes SUBMIT to use the "double-fork" method when creating child processes which run directly (rather than through the 'at' queue). In the "double-fork" method, a child is created, and then that child creates another child (grandchild of the original job) to run the submitting job. The advantage of this technique is that if original job exits before the submitted job, the submitted job will be adopted by the init process and thus saved from becoming a zombie when terminates. The main downside of this technique is that it makes it more difficult to match up submitted processes to their owners, so it probably should only be used in cases where you are having trouble with submitted jobs becoming zombies due the parent exiting too soon. (Note that submitting a job with the /NEXT or /AFTER switch will send it to the 'at' queue, which eliminates the dependency on the parent job. But it takes slightly longer to get started, which may be one reason not to use that approach in a TCP server where you want to service requests as quickly as possible.
