Michael_Lowry

Y vs. J in attribute values

Discussion created by Michael_Lowry on Apr 15, 2016
Latest reply on Apr 15, 2016 by Michael_Lowry
Some object/task attributes take a yes/no value. E.g., ATTR_DLG and GEN_AT_RUNTIME. I noticed today a strange inconsistency in the way at least one of these attributes is stored internally.

I created a test JOBS object with the following statements in the pre-process:
:PUT_ATT ATTR_DLG = "Y"
:SET &ATTR_DLG# = GET_ATT(ATTR_DLG)
:PRINT ATTR_DLG: &ATTR_DLG#
:SET &GEN_AT_RUNTIME# = GET_ATT(GEN_AT_RUNTIME)
:PRINT GEN_AT_RUNTIME: &GEN_AT_RUNTIME#

The Activation log shows the following:

2016-04-15 09:58:18 - U00020408 ATTR_DLG: J
2016-04-15 09:58:18 - U00020408 GEN_AT_RUNTIME: Y
The documentation for ATTR_DLG states that its value can be either Y or N. As the above example makes clear however, even if the attribute is programmatically set to Y using :PUT_ATT, internally it is stored as J.

I presume that most boolean YES/NO attributes were updated from German to English abbreviations years ago (i.e., J/N → Y/N). Perhaps ATTR_DLG is simply one that was never completely updated. I wonder if this behavior is intentional or not.

If it’s intentional, then the documentation should probably be updated to make this clear. Otherwise, customers might write a script that reads the value of the attribute and expects it to be Y or N, when it fact it will be J or N.

Outcomes