Re: Static Variables in a subprocedure

Ken Sims wrote:

...
Competent programmers pay attention to what they are doing ...

After all, isn't lying to the compiler a way that a program can "mess
with" a procedure? A procedure prototype with EXTPROC can be created
with different parameter types and lengths, with the potential for
decimal data errors, corrupted storage, etc. Shame, shame, shame! <G>

Competent programmers aren't perfect programmers. We can only try to reduce the amount of effort that has to be made by those competent programmers to ensure their changes are correct. If a variable is local, the checking is limited to that procedure; if global, the checking needs to be done for the whole module; if exported from a module in a program, the checking needs to be done for the whole program; if exported from a service program, the checking needs to be done for the whole system.

Creating the kind of additional prototype you suggest is the "work" of an incompetent or even malicious programmer. I don't think it's a natural extension of the special-purpose extra prototype that I suggested.

Anyway, I'm not particularly advocating the double prototype, just offering the technique as an alternative to using a global variable.

Also, you _could_ consider coding a should-be-private variable as a global variable to be lying to the compiler. You are telling the compiler that any procedure is free to use the variable.

This scenario has pointed up a weakness in the RPG language, since it doesn't allow RPG programmers to express the idea that a private static variable should be reset. RPG programmers have to work around this weakness one way or another.