>Michael,
>
>I will stand by my comment that this is a indication of a badly designed function. Note I said "indication" not absolute proof. The indication is that teh function needs to know something that isn't part of its internal data and hasn't been passed as an argument, this indicates an external coupling of the function (again note the word indicates) and it warrants that the programmer review the function's desing to determine if, in fact, they have weakened the cohesion of the function. My comment was intended to elicit a review by the questioner sas to whether or not they have overly complicated the function and if, again in fact, the service would be better handled either by using multiple functions or by passing arguments.

It is not until the last line where you mention that it is only an indication of a possible problem, in your main paragraph you are most positive that it is a problem :-

"The issue is not whether you can find out who called, it is that needing to know who called weakens the internal cohesion of the called function. IOW, the called function must behave differently depending on who called. While this may not be an immediate problem it is certainly waiting to become a problem. As the system evolves, say a new function needs to call this one and it needs still a different functionality. With this approach, eventually, the called function will become a huge DO CASE construct with new cases being added for every new need. This will become a maintenance nightmare after a while."

I don't wish to argue with anybody here, I respect your views too much, but I don't think you should make assumptions about somebody's programming style/ability/whatever, without more detailed knowledge.