Control Variables

, ,
1

Testing for modification using Natural 6.3.5 on an AIX platform.

It appears that if you test a control variable to see if it was modified that after a number of iterations, it does not think the field was modified even though it was.

We have had an obscure bug in a function that updates a status that is entered on a screen. Sometimes it does not update even though the user has entered a new value.

My testing has indicated that after a number of times, using the same data it doesn’t think that the status was entered and therefore does not update the data. Then on the next iteration it is fine again.

Any comments or suggestions, other than to not check the Control variable, of course…

2

Suggestion: when you think it is a bug - report it to SAG support :wink:

3

I have suggested as such to our DBAs who may do so eventually.

I was wondering if anyone else had experienced this and if there was a work around.

4

A Control Variable has a length of 2 byte. IIRC the last (=right) bit stands for modification (0 = NOT MODIFIED, 1 = MODIFIED). At the beginning of the INPUT-statement, Natural resets the correspondig bit to 0. At the end of the INPUT-Statement, Natural sets the MODIFIED bit if some of the regarding values was modified.

It’s very difficult for me to understand your problem. Could you post some code to demonstrate the bug?

5

Very simply; IF MODIFIED does not work the way most programmers think it works, and indeed, would want it to work.

I am attaching an issue of Inside Natural from eight years ago. The relevant discussion begins on Page 9. As you will note, if you read the article, REINPUT basically renders IF MODIFIED subject to two types of “errors”. Natural will tell you a variable was MODIFIED, when “logically” it was not modified. Why? The variable was modified twice; once via INPUT and once via REINPUT (back to the original value). Natural (see attached article) will tell you that the variable was modified, despite the fact that most people would like to be told “not modified”. Consider a Map I change a variable from ABC to XYZ. Before pressing enter I change it back to ABC. Natural will, very properly in my opinion, report “not modified”. Yet if there is a REINPUT in between, the verdict is modified.

As shown in the attached article, the converse is also possible. I change a variable from ABC to XYZ. Based on some other variable on the screen, my program does a REINPUT FULL. I leave the XYZ variable the same. Natural tells me (after the REINPUT screen) that the variable is “not modified”, when clearly it has changed from ABC to XYZ.

Yes, I have seen people play games with complicated code (lots of flags, etc) to get around this problem. I have chosen, in my code to go back to the “old way”; two sets of values for variables where changes must be tested. Then I can compare old values versus new values.

The real “problem” is the IF MODIFIED logic can be a time bomb in your program, waiting to go off. If a user never enters data that causes a REINPUT, the IF MODIFIED will work perfectly. Then, usually 2 am on a saturday morning, comes the dreaded call that a critical international online application, being run half way around the world (where it is 2pm), has blown up. Not fun.

steve

6

Whoops; forgot the attachment; here it is; in PDF format.

steve
IN Vol 12 No 4.pdf (229 KB)

7

Very interesting. I didn’t know that. :o So a Natural programmer should be very carefull to use REINPUT FULL + MODIFIED. Maybe that’s Stephen Webb’s problem…

8

Hi Matthias;

Read the Inside Natural article. It is not just REINPUT FULL that “disables” IF MODIFIED. A simple REINPUT can also wreak havoc.

steve

9

You’re right but this seems more logical to me.

OK, you can write a pretty infinite loop… but I think that’s not a “real” trap for a natural programmer.

10

Hi Matthias;

Try the following program:

DEFINE DATA LOCAL
1 #A (A3) INIT <‘ABC’>
1 #B (A3)
1 #C (C)
END-DEFINE
*
INPUT (AD=M) 5T ‘CHANGE #A TO XYZ, ENTER XXX FOR #B’
/ 5T #A (CV=#C) #B
*
IF #B = ‘XXX’
REINPUT ‘CHANGE #A TO ABC; #B TO ANYTHING BUT XXX’
END-IF
*
IF #C MODIFIED
WRITE 5T ‘#A WAS MODIFIED’
ELSE
WRITE 5T ‘#A WAS NOT MODIFIED’
END-IF
*
END

As per instructions, change #A to XYZ, enter XXX for #B.

You will be “caught” by the REINPUT.

Now change #A back to ABC; enter anything for #B except XXX.

Hit enter.

Should Natural report #A as MODIFIED or NOT MODIFIED. Remember, #A started as ABC, it is still ABC.

Natural will report #A as MODIFIED.

I personally feel it should report #A as NOT MODIFIED.

Not convinced?

Run the program again. Enter XYZ for #A (do not hit enter). Enter anything but XXX for #B (do not hit enter). Change #A back to ABC. Now hit enter.

What will Natural tell us? NOT MODIFIED.

The difference between the two runs? Getting caught by a REINPUT that has nothing to do with #A.

Yes, the infinite loop example is a bit of a stretch. The example above is a lot more likely to occur.

steve

11

When I worked for SPL back in the eighties that was the same conclusion that we cam to then.

Don’t bother with testing CVs for modified as it doesn’t work the way you would want it to.

12

Or to say it from the user’s point of view: ENTER was pressed.

I personally feel: I can live with it. To be honest: IF … MODIFIED is rarely used in our code. For example for so-called A1-Marks.

for example:

if #mark modified
  perform show-detail-screen
end-if

Maybe that’s why I think, this is not very critical.

REINPUT FULL → NOT MODIFIED seems to be more critical to me.