Re: Assignment of ARG_VAL in Informix 6.0

In article <31E59C6E.413@weet.demon.co.uk>, Steve Weet <steve@weet.demon.co.uk> wrote: >MAIN > DEFINE l_date DATE > LET l_date = ARG_VAL(1) >END MAIN > >And the following command line :- > fglgo progname "update" > >I would have expected an assignment error in much the same way as I >know the following would error :- > > LET l_datevar = "SOMETIMES" Indeed. And they are both handled the same. If you have "normal" error scope in effect, conversion errors are ignored silently (as was the case in all versions of compiled 4GL except 4.00). This applies to both examples above (conversion of an argument or conversion via LET). If instead you had AnyError Error Scope in effect (by compiling or running with -anyerr, or by prefacing the code with WHENEVER ANY ERROR STOP), you would get the following: fglgo -anyerr junk Program stopped at "junk.4gl", line number 3. FORMS statement error number -1205. Invalid month in date >So why doesn't the ARG_VAL asignment error. This "feature" caused a >program to run in report only mode rather than update mode many times. > >Is this a bug/feature and is it limited to V6 4GL (AIX ) It's a feature, and it's documented in depth in the Release Notes: TOOLREL_6.0 (see attached portion). Look for the note that says "ALL 4GL USERS SHOULD READ THIS RELEASE NOTE CAREFULLY" in its Introduction. [-: ------------------------------------------------------------------------------ TOOLREL_6.0 Page 24 CHANGES IN 4GL ERROR HANDLING ============================= Introduction ------------ Several bug reports addressed for this release have revealed inconsistencies in 4GL error handling as well as incompatibilities between C-compiled 4GL and the 4GL Rapid Development System (RDS). For this release, both 4GL variants have been changed to what we believe is a more intuitive error handling regimen. These changes have some serious compatibility effects, especially for RDS users. To better understand the impact of these changes, we suggest that you first brush up on the concepts of error handling and the WHENEVER statement by reviewing pages 2-23 through 2-27 and 3-280 through 3-286 of Volume 1 of the 4GL 6.0 Reference manual, posting the corrections given below in the section called, "Documentation Clarifications and Errata: Version 6.0 Documentation." Then, read the rest of this article carefully to understand the impact of these changes on your applications' error handling techniques. In the following discussion, the term "Error Scope" will refer to whether the scope of error handling includes expression errors. "Normal" Error Scope includes SQL errors, validation errors discovered by the VALIDATE statement, and screen interaction statement errors, but it ignores expression errors. Expression errors do not initiate any action requested by a WHENEVER statement, and they do not set the STATUS variable. This behavior was the original 4GL behavior, and it was maintained through 4GL version 1.10.03. It was restored in 4.10 after customers encountered compatibility issues with the 4.0 release when their applications could not handle its more restrictive "AnyError" Error Scope (described in the next paragraph). In contrast, AnyError Error Scope means that expression errors also activate error logic, and STATUS will be set to an appropriate negative value after the statement that produced the expression error. This was the only Error Scope available with version 4.0 of 4GL. Now, however, it must be requested manually by using the WHENEVER ANY ERROR directive or by using the -anyerr flag when compiling or on the RDS runner or debugger command line. We recommend that all new 4GL code be written to work under AnyError Error Scope for maximum ease in preventing, locating, and correcting expression errors. With compiled 4GL, you can achieve this automatically by setting the C4GLFLAGS environment variable to include "-anyerr". With RDS, you can achieve this by setting the FGLPCFLAGS environment variable to include "-anyerr". Note that C4GLFLAGS was first supported in 4.12 and 6.00, but FGLPCFLAGS is newly supported by versions 4.13 and 6.01. The behavioral changes documented here represent fixes to a variety of overlapping bugs. For reference purposes, the affected bug numbers are: TOOLREL_6.0 Page 25 B11937, B13436, B13641, B13563, B16655, and B32594. ALL 4GL USERS SHOULD READ THIS RELEASE NOTE CAREFULLY. Again, it assumes that you are thoroughly familiar with the concepts of 4GL error handling and the WHENEVER statement -- you may wish to begin by reviewing the documentation sections appropriate for your version of 4GL as stated above. Resolving these bugs brought to light a number of related documentation errors and weaknesses. Please refer to the subsection "Documentation Clarifications and Errata" at the bottom of this section for a list of documentation errata, as well as the regular 4GLDOC* or RDSDOC* documentation note files included in $INFORMIXDIR/release. Errors and Inconsistencies in Previous Implementations ------------------------------------------------------ As most longtime users of 4GL know, the C-compiled version of 4GL (hereafter referred to as "C4GL") preceded the first release of the interpreted Rapid Development System version (hence referred to as "RDS") by several years. Therefore, there have always been some minor behavioral differences between C4GL and RDS variants of a given release. Most such behavior differences are considered bugs, and we endeavor to keep the two variants performing as "in sync" as possible. One key difference that has not been addressed until now is conversion errors in expressions. RDS performs most data type conversions internally without relying upon generic 4GL library calls. Before this release, the method RDS used to perform these internal expression conversions behaved as if AnyError Error Scope was always in effect. Therefore, RDS *appeared* to support only AnyError Error Scope, although with the exception of a brief note in the 4GL 4.1 Supplement manual, the documentation never indicated any intentional differences between C4GL and RDS in this regard. Only those expressions or conversions that required 4GL *library calls* would reveal this subtle but disturbing inconsistency. Example: DEFINE xd DATE LET xd = DATE("14/14/90") DISPLAY "status = ", status LET xd = "14/14/90" DISPLAY "status = ", status The LET statements are logically equivalent. However, when run in R