X-Arrays with negative indexes as parameters for Subprograms

Matthias1 · April 25, 2006, 8:33pm

First of all: Sorry for the maybe confusing title of this post…

Please try out the following program and subprogram and you will understand what I mean.

The code of the Subprogram:

define data parameter
01 #param1  (A1/0:*)
01 #param2  (A1/-10:*)
01 #param3  (A1/-2:*)
end-define
expand array #param1 to (0:5)
expand array #param2 to (-10:-5)
expand array #param3 to (-2:2)
end

This is the regarding main program to test the X-Arrays:

define data local
01 #array1 (A1/0:*)
01 #array2 (A1/-10:*)
01 #array3 (A1/-2:*)
end-define
*
callnat 'XARRAY-N' #array1(*) #array2(*) #array3(*)
* expand array #array1 to (0:5)
* expand array #array2 to (-10:-5)
* expand array #array3 to (-2:2)
*
write notitle '*OCC(#array1)    = ' *OCC(#array1)
if *OCC(#array1) ne 0
  write
    '*LBOUND(#array1) = ' *LBOUND(#array1) /
    '*UBOUND(#array1) = ' *UBOUND(#array1)
end-if
*
write / '*OCC(#array2)    = ' *OCC(#array2)
if *OCC(#array2) ne 0
  write
    '*LBOUND(#array2) = ' *LBOUND(#array2) /
    '*UBOUND(#array2) = ' *UBOUND(#array2)
end-if
*
write / '*OCC(#array3)    = ' *OCC(#array3)
if *OCC(#array3) ne 0
  write
    '*LBOUND(#array3) = ' *LBOUND(#array3) /
    '*UBOUND(#array3) = ' *UBOUND(#array3)
end-if
*
end

If I run the program I get the following Output:

*OCC(#array1)    =            6
*LBOUND(#array1) =            0
*UBOUND(#array1) =            5
                               
*OCC(#array2)    =            0
                               
*OCC(#array3)    =            5
*LBOUND(#array3) =           -2
*UBOUND(#array3) =            2

Obviously, the expand on #array2 didn’t work. But it works if I do that expand in the program and not in the subprogram.

Strange …

I think, this is a compilers bug

Can anyone reproduce this? I did this on Natural 6.1.1.17 for Windows and Solaris.

Wilfried_B · April 25, 2006, 9:34pm

First of all: I have not yet worked with X-Arrays. But my shot from the hip:
It is not necessary that the exact array boundaries match in the calling and called program. With normal arrays only the number of occurences per dimension must match. So passing an array(1:10) to a parameter defined as p-array(0:9) is valid, but array(1:11) is not.

Matthias, if you define the array #param2 (A1/0:*) and expand it in the subprogram to (0:5), what results do you get then? I would expect:

*OCC: 6
*LBOUND: -10
*UBOUND: -5

btw. I would have expected same results with your programs! Maybe it is a compiler bug.

Matthias1 · April 26, 2006, 12:07pm

[quote="Wilfried B

Matthias1 · April 26, 2006, 12:55pm

I found a workaround:
As per Natural Documentation RESIZE should work in both directions (EXPAND and REDUCE).
If I use RESIZE instead of EXPAND the results are correct.
Now, the subprogram looks like that:

resize array #param1 to (0:5)
resize array #param2 to (-10:-5)
resize array #param3 to (-2:2)

But the initial question (regarding EXPAND) still remains…

system · April 26, 2006, 1:30pm

If you suspect a compiler bug, can you please report it to SAG support via the proper channels ?

Wilfried_B · April 26, 2006, 1:42pm

Ok, I think you have found another flaw in Natural: EXPAND/REDUCE/RESIZE. Three new statements and when you read the documents you’ll get the impression that two of them are superfluous: RESIZE does exactly the same as EXPAND and REDUCE.

But you have found out that, where EXPAND does not work correctly, RESIZE does the job.

How do the Syntax people at Software AG think to define such statements?
What did the compiler programmers program that EXPAND does not work correctly whereas RESIZE does?

Sometimes I get the impression that some people have very good ideas how to modernize the NATURAL-language, implement the first steps and then someone comes and says: “That’s enough guy, we have more important problems to solve!”

Matthias1 · April 26, 2006, 1:51pm

[quote="Wilfried B

Matthias1 · April 26, 2006, 2:00pm

This will be done by our system administrator. But he’s on vacation at the moment…

But before I report a so called “compiler bug” to the official support, I want to make sure, that it isn’t my fault. Because in most cases the old programmer’s wisdom “I found a compiler bug!” turned out to be “I found a programmer bug!”.

So it would be interesting for me, if you can reproduce the outputs of my programs and if you can find any tipps in the Natural Documentation. I didn’t.

Wilfried_B · April 26, 2006, 7:56pm

That’s it again! Why can’t RESIZE ARRAY set the number of occurences to 0? RESIZE DYNAMIC can set the allocated space of a variable to 0. That’s syntax-tohuwabohu!

Matthias1 · April 26, 2006, 9:06pm

[quote="Wilfried B

Wilfried_B · April 26, 2006, 11:08pm

Downward compatibility? EXPAND/REDUCE/RESIZE are new statements (introduced with Nat4 MF / Nat5 OS) and dynamic variables. I can give you lots of examples of syntax-tohuwabohu in Natural. It sometimes makes me angry, what SAG does to such a pretty and simple to learn programming language :?

Matthias1 · April 27, 2006, 12:03pm

[quote="Wilfried B

Wilfried_B · April 27, 2006, 1:32pm

Aha, bugs, whether in syntax, compiler, runtime or documentation issued in this forum must be posted in servline24? Do the SAG developers/supporters not read in this forum? If I was a SAG developer/supporter I would proof the (in)correctness of the statement posted in this forum. And if I could reproduce it I would open an internal request not waiting for any customer to do this. Even for misunderstandings I would do it as I would look upon it as a documentation flaw/bug.

system · April 27, 2006, 6:18pm

As has been pointed out earlier on in this thread, ServLine24 is the official method of reporting problems and Software AG can only give a guarantee to fix such problems which have been reported via ServLine24. Our internal processes and workflows are geared to making this process as efficient as possible.

Obviously Software AG does monitor this Forum and will, wherever possible, attempt to correct any problems reported, however such corrections will only be made available via ServLine24.

Matthias1 · April 27, 2006, 7:03pm

Hello Stephen Wild!

As I mentioned in one of my posts above, even I have to go a certain way here at my company. The following steps have to be done:

I have to report my problem to the system administrator (who is on vacation at the moment)
I have to explain my problem to the system administrator (because he’s not a programming freak)
The system administrator calls Software AG (maybe via ServLine24, maybe by phone, I don’t know it exactly).
Some days later, the system administrator gets a response from SAG (that is maybe not understandable for him, because he’s not a programmer)
The system administrator tries to explain me what SAG told him

So maybe you can understand, why it makes a very good impression to me if some things are handled directly. Here’s a good example:
http://adabas.forums.softwareag.com/viewtopic.php?t=851 :D:D:D

Anyway: In two weeks, I will go the official way. Our system administrator is back then.

BTW: I don’t know ServLine24…

Matthias1 · May 10, 2006, 8:29pm

As promised, I told the whole thing to our system administrator.

Let’s see …

Matthias1 · May 12, 2006, 3:07pm

My system administrator told me, that the Software AG answered to his request:
“You’re right. The EXPAND in your example should work, but it doesn’t.”

Now I’m really proud! This is the very first time for me, that I have discovered a bug in a COMPILER. I’ll print me a certificate entitled “Discoverer of a real compiler bug”

Finally, I hope that it doesn’t turn out to be a programmer’s bug.

Matthias1 · May 19, 2006, 7:27pm

Today, I got the following reply: