next »

[.]

Hi,

I am finding with 2.11.10 BDL on linux that if we change how many parameters are passed to a function that we need to remake the .42r rather than just being able to run it after compiling the module as with previous versions.

This includes where the function is only called by the module it is in. This gets a bit annoying when you've made a very small change.

A typical example of the runtime error:
Program stopped at 'pos_prescs.4gl', line number 82.
FORMS statement error number -6200.
Module 'pos_prescs': The function pos_prescs.print_cl_lenses(36,0) will be called as print_cl_lenses(35,0)

Thanks

Jeff McFe

[Neil M.]

Hi Jeff,

This is expected and if you have an example of the runtime system not complaining
when a function's arg count has changed then it is actually a bug.

The runner and linker are actually the same program and all calls to a function must
pass the correct number of args.

Informix never checked this at link time and then would fail at runtime,  as opposed
to program-load time,  the result was normally a crash at the point of the call being made,
which is really not good because you can do basic testing and not hit the problem, then only
find out that it's wrong when the program is live.

Regards,
Neil

[Reuben B.]

There is a change of behaviour somewhere between 1.3x and 2.1x.

I recall in my previous job when I had real code to look after, that if the change was in the arg count of a 'private' function then you could simply recompile the .42m and deploy it to the customer site without needing to relink and send all the affected .42r's

Try this (just checked it still works in 1.33.2e)...

Code

-- 0305a.4gl
MAIN
   CALL a1(1)
   CALL b1(1)
END MAIN
 
FUNCTION a1(x)
DEFINE x INTEGER
   DISPLAY "a1"
END FUNCTION

Code

--0305b.4gl
FUNCTION b1(x)
DEFINE x INTEGER
   DISPLAY "b1"
   CALL b2(x,x)
END FUNCTION
 
-- Private function
FUNCTION b2(x,y)
DEFINE x,y INTEGER
   DISPLAY "b2"
END FUNCTION

fgllink -o 0305.42r 0305a.42m 0305b.42m
fglrun 0305

I could then make the following change to the 'private' function in 0305b.4gl ( added a 3rd argument)

Code

--0305b.4gl 
FUNCTION b1(x)
DEFINE x INTEGER
   DISPLAY "b1"
   CALL b2(x,x,x)
END FUNCTION
 
-- Private function
FUNCTION b2(x,y,z)
DEFINE x,y,z INTEGER
   DISPLAY "b2"
END FUNCTION

fglcomp 0305b.4gl
fglrun 0305

and it would run fine without the need for relinking.  My interpretation is that the runner first looked for the function inside the current .42m and if it found it, it then didn't need to look in the .42r for it.

From an ISV point of view this behaviour was quite desirable we could if needed make a change/bug-fix to the internals of a library/common routine and then deploy the affected .42m.  I don't recall us doing it that often (our deployment procedures never really caught onto the fact you could deploy a single .42m, I mean how do you communicate to the customer how to test it, especially when you tell them it could effect every single program) but as long as the function signature of the 'public' functions didn't change it was available. 

This was part of the reasoning behind my suggestions at the time of PRIVATE FUNCTION, and an ability to test if the function signature of 'public' functions had changed.  In this example there was no need for the 'private' function b2 to appear in the .42r

[.]

Hi Neil,

Reuben has got the interpretation right. If I add a parameter to a function and then change the call statement to match I still need to make the .42r fo it to recognize the change. Previously in 2.10 this was not a problem.

Thanks

Jeff

[Reuben B.]

Hi Neil,

Reuben has got the interpretation right. If I add a parameter to a function and then change the call statement to match I still need to make the .42r fo it to recognize the change. Previously in 2.10 this was not a problem.

Thanks

Jeff

Jeff,

Make sure you distinguish between what I call a private and public function.  For example if I had added the extra parameters to b1() and hence changed the call to b1() in 0305a.4gl.a1() then I would've had to recompile 0305a.4gl, 0305b.4gl and relink.  That has always been the case.

The difference in behaviour that need investigating is only with 'private' function, where the function is only called from within its own module.

Reuben

[.]

Hi Reuben.

This is happening on functions that you define as private. They are called only from within the module they reside in.

Added a new 'private function' and called without needing to compile .42r, then added one additional parameter and forced to remake .42r

Jeff