RPC: Different Parameter handling?

, , ,
1

Hello all!

Here’s a sample subprogram:

define data parameter
1 #a-dyn       (A) dynamic
end-define
compress numeric *TIMX to #a-dyn
end

It’s called via RPC by the following program:

define data local
01 #a-dyntab (A/1:2) dynamic
01 #i1 (I1)
end-define
for #i1 = 1 to *UBOUND(#a-dyntab)
callnat 'RPCTESTN' #a-dyntab(#i1)
display #i1 #a-dyntab(#i1) (AL=50)
end-for
end

Output:

#I1                      #A-DYNTAB
---- --------------------------------------------------

   1 14:05:11
   2

:shock:
Is this some different parameter handling or is this a bug?

RPC-client: Nat 6.3.9@Solaris
RPC-Server: Nat 6.3.9@Win2003

Regards

Matthias

2

It should definitely behave alike when called interactively or via RPC,
so I’d say time to raise an incident.

3

Agree with Wolfgang - Empower Time !

Also reproes under nat6.3.10 and exx821 on windows

4

Thank you for reproducing. Incident is raised.

BTW: Here’s another one:

define data parameter
1 #N1-tab (n1/1:*)
end-define
expand array #n1-tab to (1:3)
#N1-tab(1) := 1
#N1-tab(2) := 2
#N1-tab(3) := 3
end
define data local
1 #struct(1:*)
  2 #rpc-struct
    3 #n1 (N1)
  2 #other-struct
    3 #a1 (A1)
end-define
* expand array #struct to (1:2)  /* works if this line is uncommented
callnat 'RPCTESTN' #rpc-struct(*)
write 'OCC #n1' *OCC(#n1)
write 'OCC #a1' *OCC(#a1)
* display #struct(*) /* would throw NAT1257 here
end

output:

OCC #n1           3
OCC #a1           0
5

hehe - but this is different :wink:
Here you are cheating Natural into allowing something “un-natural” :wink:
If you run this one locally you will get a nat1255 because you try to allocate a sub-part of a structure.

So if this is a bug - it is a parser bug for allowing a x-array sub-part as a parameter - or what do you say ?

Finn

6

On Nat6.2@Windows you can reproduce it locally…

7

SAG-support replies, that the first example looks like a bug.
But the second one “is not an error”.
I think you’re right. NAT1255 would be correct.