4.14 changes (LONG) (was Re: 4GL/SQL 4.13 Compatibilities)

In article <806232756snz@excelsis.demon.co.uk>, Sally Woolrich <Sally@excelsis.demon.co.uk> wrote: >> My question is, 'What do I have to do to make my old programs work >> with 4GL/SQL 4.13 ? Do I have to re-compile everything with 4.13 ?' > >You most certainly do with RDS as 4.13 p-code version 8 is different to >earlier versions! Well, it's the same as 4.12.UC1 pcode, but different from 4.12.UE1 and 4.11 and 4.10. Ugh. This was caused by an ill-advised internal attribute expansion, recorded as bug 37801. It was fixed in 4.12.UE1 (maybe even UD1) but was re-broken with the merge for 4.13/6.01. I've fixed for good (I hope) in 4.14, and in a more dramatic way: the 4.14 (and beyond) runners will accept *either* form of pcode automatically, with a few rare exceptions (which can be worked around via an environment variable). I wrote an explanation of the problem issues and the resolution methodology for the 4.14 release notes, the pertinent parts of which I've attached below. I hope it's clear enough. >earlier versions! I would also do so for compilled 4GL applications >for '#include' files. > Better idea: use the c4gl script!!!! >Sally Woolrich | This mail contains my personal >sally@excelsis.demon.co.uk | views not those of my employer! One other potentially nasty 4.13/6.01 bug to watch out for: B39476, which erased the user's field buffer if an ON KEY key was struck and that ON KEY logic resulted in another INPUT/CONSTRUCT being run. The 4.14/6.02 release was held a bit so that its fix could be included: 39476 MALFUN FIELD CONTENTS REINITIALIZED AFTER ON KEY BLOCK WHEN DOING ANOTHER INSTANCE OF INPUT/CONSTRUCT "WITHIN" THE ON KEY LOGIC If an ON-KEY action is done (to see remarks, for instance) after input has already begun in a field, the characters entered will be gone after the ON-KEY action is finished. The user will have to re-enter the characters. Attachment: snippets of the 4.14 Release Notes TOOL_REL4.14 Page 1 ... III. SPECIAL CONSIDERATIONS FOR DEVELOPERS USING 4.14/6.02 RELEASE 3 SOFTWARE NOTATION 3 INSTALLATION 3 COMPATIBILITY 4 NEW FEATURES 8 BUG FIXES OF SPECIAL NOTE 13 ... III. SPECIAL CONSIDERATIONS FOR DEVELOPERS USING 4.14/6.02 RELEASE SOFTWARE NOTATION ======== I4GL refers to (compiled) Informix-4GL. RDS refers to the Informix-4GL Rapid Development System. ID refers to the Informix-4GL Interactive Debugger. 4GL refers to any of the Informix-4GL products. ISQL refers to Informix-SQL. ESQL/C refers to Informix-ESQL/C. I4GL/PE I4GL Programmer's Environment R4GL/PE RDS Programmer's Environment C4GL I4GL Shell script that invokes the compilers. INSTALLATION ============ It is recommended that the 4.14/6.02 Tools are installed in a new directory, along with the appropriate Engines, rather than being installed on top of previous versions of Informix products. Many files have been relocated or renamed. It will be much easier to remove redundant files if the old $INFORMIXDIR directory can be removed completely (after testing the new installation, of course) than if you have to spend time removing old files manually. If you are using the 6.02 Tools with 7.xx server products, the 6.02 Tools should be installed first, followed by the 7.xx server products. COMPATIBILITY ============= The 4.14/6.02 Tools release introduces several new features (itemized below in the "NEW FEATURES" section) which in turn introduce new 4GL syntax. We recommend, therefore, that users recompile and relink all 4GL programs with the new release the next time they make any source changes wherever possible. In very rare scenarios, RDS users will be *required* to either recompile their programs with the new pcode compiler (fglpc) or to utilize a newly-provided mechanism for controlling pcode interpretation; this section describes those situations in detail. Generally speaking, old RDS pcode programs will continue to run properly with a corresponding new RDS runner (4.14 runners for 4.xx-compiled pcode; 6.02 runners for 6.xx-compiled pcode). As with all previous releases, 6.xx- compiled pcode cannot be executed by 4.xx RDS runners, and 4.xx-compiled pcode cannot be executed by 6.xx RDS runners. If the new features itemized in the REPORT/RUN/OPTIONS functionality section under NEW FEATURES are used, new-format pcode is produced by fglpc, and only new 4.14/6.02 runners will be able to execute programs including the new pcode. If these new features are *not* used in a given program, older runners will still be able to execute 4.14/6.02 -compiled pcode, with some significant exceptions for 4.1x users who have migrated from a 4.12 or earlier release of RDS. The RDS 4.12 and 4.13 releases in particular suffered from internal structural changes that introduced some accidental pcode incompatibilities; these in turn forced users to recompile with an exactly-matching version of fglpc. The remainder of this section applies only to the 4.14 release (and subsequent 4.xx releases) of RDS; it describes in detail the compatibility issues relating to 4.1x pcode structural changes with respect to the DISPLAY ... AT, DISPLAY ... TO, and DISPLAY BY NAME. 4.1x users who cannot or choose not to recompile all pcode under 4.14 should read the rest of this section carefully. Scope of Effects of the Pcode Structural Changes ------------------------------------------------ The <attribute> field that can be optionally added to any DISPLAY BY NAME, DISPLAY TO <fields>, or DISPLAY AT <location> was expanded from a short to a long integer effective with the 4.12.UC1 release. This change was fixed in a backward-compatible fashion effective with the 4.12.UD1 release, but it was again expanded to a long integer effective with 4.13. We therefore ended up with two incompatible "families" of pcode formats between versions 4.11 and 4.14: "Family 2" "Family 4" creates/expects 2-byte attribute creates/expects 4-byte attribute Version Pcode Ver Version Pcode Ver -------------------------------- -------------------------------- 1.10.* 6 4.00.* 7 4.10.* 8 4.11.* 8 4.12.UC* 8 4.12.UD* 8 4.12.UE* 8 4.13.UC1 8 4.14.* 414