I have been a Natural programmer (UNIX) for a few years now and do not have much experience with arrays.
I have an array on a map with an upper bound of 8 and only 6 being displayed on the screen. All of the occurrences can be modified when the screen is in an UPDATE mode. Users can enter on any of them as long as the value is a valid code that. There is already validation to determine that and is working fine. The problem I am running into is trying to determine which array was modified because I need to to make sure that the value (2 character code entered) has not been used before. My approach was to compare what has already been stored in the table for the field, but I have not been able to figure out how to determine which occurrence of the array was modified. But I also need be able to validate if they enter the same code twice on the screen in update mode.
The brute force method would be to save the table and compare new values to old.
MOVE #TABLE (*) TO #SAVE (*)
INPUT ...
IF #TABLE (1) <> #SAVE (1)
THEN
...
IF #TABLE (2) <> #SAVE (2)
THEN
...
The Natural way would be to use Control Variables, attaching one to each table entry. Then you could test whether an entry was MODIFIED.
INPUT ...
IF #CV (1) MODIFIED
AND #TABLE (1) <> ' '
THEN
...
END-IF
IF #CV (2) MODIFIED
AND #TABLE (2) <> ' '
THEN
...
END-IF
Since the table is small, I probably would use more brute force to cross-check the entries. OR= of a list of entries is quite efficient.
IF #CV (1) MODIFIED
AND #TABLE (1) <> ' '
THEN
IF #TABLE (1) = #TABLE (2:#M)
THEN
REINPUT 'Dupe in entry 1' MARK *#TABLE (1)
END-IF
END-IF
IF #CV (2) MODIFIED
AND #TABLE (2) <> ' '
THEN
IF #TABLE (2) = #TABLE (1)
OR = #TABLE (3:#M)
THEN
REINPUT 'Dupe in entry 2' MARK *#TABLE (2)
END-IF
END-IF
...
Control variables are nice and I used to use them all over the place in map editors. One thing you have to watch out for though is if you issue a REINPUT, they get reset. If the user modifies the value for the 2nd occurrence of the array, the first pass checking IF #CV(2) MODIFIED evaluates to TRUE, but after the REINPUT, if the user doesn’t touch the 2nd occurrence again, even though the value of the 2nd occurrence differs from its original value, IF #CV(2) MODIFIED evaluates as FALSE. Because of that, I agree with considering Ralph’s brute force approach so you can tell if an occurrence was modified from its initial values no matter how many REINPUTs were performed.
Because of this, I would also advise that you not skip important edit checks based on control variables, but rather validate all input or modifiable data.
Thank you Ralph and Brian for your suggestions. I have been trying to do something similar to your suggestions in the map, however, I have only made baby steps. I just want to clarify that your suggestions are to be in the map or in the program?
In the days before the Map Editor, you would create a map with an INPUT statement and follow it with IF statements to apply the user’s data rules.
The Map Editor simplified map creation and introduced the concept of an external map module. External maps act internally just like a subprogram, so all the data on the map must be passed to it in a parameter list from the calling routine. Processing a parameter list introduces CPU overhead and each time the user presses ENTER, the parameter list is passed back to the calling routine where verification code invokes the map again to inform the user of the next error, again passing the parameter list.
To avoid the overhead of repeated calls, maps allow validations to be coded within them. The map is invoked only once regardless of how many times the user enters invalid data. Control is returned to the calling routine only when all validations are satisfied. Look for “verification rules” in the Map Editor documentation.
Then, Natural developers were presented with another complication - the Web. Natural’s maps, both in-stream and external, could not be used in a Web browser. So applications were “re-factored” for the Web by removing INPUT statements, replacing REINPUTs, and converting programs into subprograms for invocation from Web routines. Many shops introduced standards to separate presentation layer from business layer, effectively banning the use of verification rules.
After falling behind the rest of the industry for a while, Natural caught up with the introduction of WebIO, built-in with mainframe and LUW versions of Natural. This allows automatic, real-time conversion of maps to HTML for presentation in a browser.
Bottom line: follow shop standards, but if you want the best performance, use verification rules.
Since you are new to arrays, you might be unaware of a performance problem that can be found in many online systems that involve scrolling through lists (arrays) on a screen.
Many programs employ maps that display a “fixed array” of say ten items. If the user wishes to scroll down (or up), the logic to respond to a PF scrolling key is in the main program. Hence, every scroll operation involves going from the Map back to the program, which issues a REINPUT FULL after modifying the “fixed array”, thereby returning to the map.
Instead PF key Processing Rules can be employed within the map to enable such scrolling. Regardless of how much scrolling is requested, the map returns to the program only once.
I will check, but I believe I posted a program and Map with discussion on the Forum quite a few years ago. Will look for it and either post a link to it, or post such a program and Map.
I could not find the posting on the Forum. I was going to attach an article from my newsletter Inside Natural, called While Scrolling through the Park One Day, but I have apparently reached the limit of attachments. I will contact the Forum administrators to see if there is any way to relax this constraint
Upon further checking, I found a posting (actually two postings) I made to Natural for Mainframes on July 15, 2014. These have the aforementioned four pages attached.