1414.7 |
Compiler refinement (edit 744): Attempting to define a local dimx byref array without the required initial subscript value of -1 is now flagged as an error. Previously, no error was generate but the pass-by-reference mechanism would not have worked correctly. |
1414.6 |
ISAM 1.x bug fix: Close a loophole through which a bogus illegal record # error may have occurred after an automatic expansion of the IDA. |
1414.5.1 |
PDFX/Email (Type 4) bug fix and refinements. Close obscure loophole in which an error during the file attachment operation might have led to a domino effect whereby the To: address of the failed email got carried over to the next email. Improve error detection and logging. Note: to get the full effect of the refinements/fixes, you should also update ASHNET.DLL at the same time (see next). |
1414.5.2 |
ASHNET.DLL 1.7.152 closes a loophole in which certain attributes of a failed email request (PDFX Type 4) might get carried over to the next email. |
1414.4 |
Compiler bug fix (edit 743): MAP statements with initial values, when part of a DEFSTRUCT, were generating improper assignments in the RUN file. Typically these were benign, but in some cases they were causing the program to abort with a nonsensical error code during the initialization. |
1414.3 |
PDFX / APEX refinement: in some cases, the PDFX Save As dialog was getting covered by the APEX preview window, leaving some users with the impression that the program was hung. |
1414.2.1 |
XCALL RENAME refinement: Under Windows, XCALL RENAME will now overwrite an existing destination file. It was never documented what it should do here, but this matches the way it has always worked under UNIX. The motivation for the change now is that it has been determined that Windows file sharing networks can sometimes yield false positives—i.e. they report that the destination file exists when it doesn't—causing applications to fail unexpectedly and returning an error in the STATUS parameter of XCALL RENAME. Note that this does not affect RENAME.LIT, nor does it affect the MX_COPYFILE function, which can also be used to rename a file, but which offers an explicit option of whether to replace an existing file. |
1414.2.2 |
ISMBLD.LIT compatibility fix: ISMBLD.LIT 2.1(141) fixes a discrepancy between the AMOS and A-Shell behavior of the /D switch, which is used to change the IDA device. Previously, hitting ENTER to the "Enter new device name" prompt was causing an existing explicit device specification to be set to blank, meaning that the IDA is on the same device as the IDX. In contrast, the AMOS version was leaving the existing device specification alone in this case. Instead, you were expected to enter "." to remove an existing device specification. While the A-Shell version was treating "." as an invalid device. The updated ISMBLD.LIT 2.1(141) now matches the AMOS behavior, although the prompt has been enhanced to clarify the ENTER and "." options. While on the subject of the ISAM IDA device, please take note to remember why the feature existed in the first place: it was a workaround to the 32MB limitation of the original AMOS disk devices. In the modern world, it makes no sense to split the IDX and IDA across different devices. It is strongly recommended that you keep the IDX and IDA on the same device under A-Shell—i.e. leave the the data file device option blank. |
1414.1.1 |
Fix problem failure of .ISNULL(x) to detect the null condition on ordmap(varstr;varx) maps. |
1414.1.2 |
COMPIL.LIT, OCMPIL.LIT, and COMPLP.LIT 1.1(129) fixes a conflict between /L and /LI, and also fixes the broken /13 switch. This is not related to or dependent on any particular version of A-Shell. |
1414.0.1 |
Add new Dot Function .ISNULL for use with ordered maps to test for the .NULL condition, edit 742. |
1414.0.2 |
Add support for Binary Elements in Ordered Maps. |
1414.0.3 |
APN compiler updated to edit 742. |
1414.0.4 |
Windows compatibility enhancements: the internal mechanism for detecting the version of Windows—and thereby dealing with differences between them—has been upgraded to better support Windows 8.1 and beyond. The only outward change will be in the MX_OSVER function, which now reports the OS platform more explicitly for Win8, Win8.1, WinSvr2008 and WinSvr2012. |