Sorry, hopefully I am posting this in the correct location. I am using Natural within Windows:
Software AG Natural for Windows. – Version 6.3.14 PL 0
Mainframe vs Windows - Errors.
I have a Natural program that I am able to view either within my windows environment or on the mainframe. Both locations STOW correctly. However, when you view the program within the windows environment, the +/- for a FOR and IF statement are both highlighted in red.
Is it possible for a program to STOW ok, yet still have problems with a statement? I can’t find any other information for this indicator within the environment.
Attached & below is an example. So there may be problem with the way this - FOR and IF statement are setup that I am not seeing yet…? I’m assuming that is why there is a red box next to those parts of the code… Sorry, still new to this.
4860 - FOR #AA = 1 TO 6
4862 - IF #H-BUDGET(#AA) > ’ ’
4864 EXAMINE #BUDGET-ARRAY(*) FOR #H-BUDGET(#AA) GIVING INDEX #BB
4866 IF #BB > 0 AND
4868 #H-FUND(#AA) = #FUND-ARRAY(#BB) AND
4870 #H-OBJ-CAT(#AA) = #OBJ-CAT(#BB)
4872 ADD #H-OBJ-CAT-AMT(#AA) TO #OBJ-CAT-AMT(#BB)
4874 ** ADD #H-OBJ-CAT-AMT(#AA) TO #WORK-INCM.#AMNT-BUDG-ADJ(#BB)
4876 ELSE
4878 ADD 1 TO #CC
4880 MOVE #H-BUDGET(#AA) TO #BUDGET-ARRAY(#CC)
4882 MOVE #H-FUND(#AA) TO #FUND-ARRAY(#CC)
4884 MOVE #H-OBJ(#AA) TO #OBJECT-ARRAY(#CC)
4886 ** MOVE #H-OBJ(#AA) TO #WORK-INCM.#CODE-BUDG-ADJ(#CC)
4888 MOVE #H-OBJ-CAT(#AA) TO #OBJ-CAT(#CC)
4890 ADD #H-OBJ-CAT-AMT(#AA) TO #OBJ-CAT-AMT(#CC)
4892 ** ADD #H-OBJ-CAT-AMT(#AA) TO #WORK-INCM.#AMNT-BUDG-ADJ(#CC)
4894 END-IF
4896 ELSE
4898 ESCAPE BOTTOM
4900 END-IF
4902 END-FOR
You know the program’s syntax is correct, because it STOWed. The bug is in the colorization routine, whose logic is not as comprehensive as the compiler.
You can fix the coloring by removing the FOR keyword from the EXAMINE statement, but the EXAMINE won’t read as well.
Good morning. So the syntax is correct, however, there is a bug with the logic. This program gives us intermittent issues, I am assuming this is the spot. It will test ok, yet, something seems to creep up when we put it in to the production environment.
First - in the windows environment, the +/- functionality that allows me to shrink up statements. IF to END-IF, FOR to END-FOR… does not work in the code I posted here. If you try to shrink it up, it collapsed the entire balance of the program. Like it cannot find the end statement.
Also — You said “You can fix the coloring by removing the FOR keyword from the EXAMINE statement, but the EXAMINE won’t read as well.” Is there another way you can suggest to do this to make this work correctly?
This does not answer your question; but, if you go into Tools-Options and uncheck expand/collapse, all the boxes go away.
As Ralph said, if it Stows, the code is okay.
Looks like a problem with the expand/collapse feature. I cannot find anywhere which explains why there are two red boxes. Indeed, it does not appear to be any reason for even one red box.
Okay, decided to play a bit more now rather than later
0010 define data local
0020 1 #loop (n2)
0030 end-define
0040 for #loop = 1 to 5
0050 add 1 to #loop
0051 if #loop = 4
0052 add 1 to #loop
0053 end-for
0054
0060 end
The code above produces two two red blocks at lines 0040 and 0051.
The red block for 0051 would appear legitimate since there is no end-if. But why at 0040?
A bit strange.
I should have been more specific. The bug is in the “structure” logic which is simplistic and does not differentiate between a FOR statement and a FOR clause. The erroneous coloring of the structure indicator is a result.
You can live with it or you can contact SAG Support. This bug has been around for a while, but I consider it a minor one and would not want SAG giving it a high priority.
The structure routine sees the FOR and expects to see END-FOR. Then he sees IF and expects to see END-IF. When END-FOR is found and it doesn’t match the expected END-IF, the IF structure is marked as an error (red). Apparently he continues by looking for the next END-FOR, which is not found, so the FOR is marked as an error, too.
Of course it’s futile to try to debug code that we can’t see. We can only surmise.
What I find interesting is that JB’s issue is caused by the FOR clause of the EXAMINE, but the issue does not occur if the examined string is a scalar. Removing “(*)” also removes the red coloring from the structure indicator.
EXAMINE #BUDGET-ARRAY(*) FOR #H-BUDGET(#AA) GIVING INDEX #BB /* red
EXAMINE #BUDGET-ARRAY FOR #H-BUDGET(#AA) GIVING INDEX #BB /* not red
Inserting any non-blank character returns it.
EXAMINE #BUDGET-ARRAY gibberish FOR #H-BUDGET(#AA) GIVING INDEX #BB /* red
0010 define data local
0020 1 #a (a3)
0030 1 #b (a3)
0040 1 #loop (p3)
0050 end-define
0060 repeat
0070 if #a = #b
0080 move #a to #b
0090 else
0100 if #a = ‘q’
0110 move #a to #b
0120 else
0130 move ‘a’ to #a
0140 end-if
0150 for #loop = 1 to 5
0160 move ‘z’ to #a
0170 end-for
0180 move ‘s’ to #b
0190 end-if
0200 end-repeat
0220 end
The program above is “parsed” correctly, with white boxes at 0060, 0070, 0100 and 0150.
I commented out line 0170. So clearly the FOR loop at 0150 has been compromised.
I agree with your idea Ralph, that Natural might get to the END-IF at 0190 and turn not only 0150 red, but also 0070. That seems like a simple “bug” to fix. The END-IF at 0190 should serve a dual role, not only “activate” the red box at 0150, but also should then be “evaluated” as part of the code. This would avoid the “erroneous” red box at line 0070. Probably just a pointer that should have one subtracted from it, to let the END-IF function properly.
However, the problem is more involved than that. There is also a red box at line line 0060, the REPEAT loop.
Will play with this later, but it looks as if the parser continues to look for an END-FOR, marking all loops until the END as being compromised.
Usually this would be a “Friday topic”, but since we will be traveling to Ohio then, I will try to play before then.
