process logs different between multiple shutdown commands

[Peter Heggie]

Just curious – I was cleaning up a pre-proc filter in a test environment, trying to get rid of errors like this:

[xlt :xlat:ERR /0:sms_invision_xlate:06/07/2011 00:19:10] Tcl error:

msgId = none

proc = ‘tpsGRV3_Allscrpts_ED_ADT_Filter’

args = ”

result = ‘can’t read “dispList”: no such variable’

errorInfo: ‘

can’t read “dispList”: no such variable

   while executing

“return $dispList”

   (procedure “tpsGRV3_Allscrpts_ED_ADT_Filter” line 172)

   invoked from within

“tpsGRV3_Allscrpts_ED_ADT_Filter {CONTEXT xlt_pre} {ARGS {}} {MODE shutdown} {VERSION 3.0}”‘

I moved the creation of the displist variable to a point outside the mode switch code and restarted the process.

The log then had none of this output. But I  only changed one filter, and several filters had the same problem. So why didn’t I see the error messages for the other filters which I had not changed, when I ran the shutdown a second time?

It seems like there was a lot more output in the log after the first shutdown. After the second shutdown command, the only output are INFO messages about checking for leaked handles, and then a few statements about the engine.

Just wondering,

Pete

Peter Heggie
PeterHeggie@crouse.org

Topic

[David Barr]

Maybe the first TPS proc in the stack returned an empty disposition list, so the following procs in the stack weren’t executed. Just a guess.

[Peter Heggie]

ok, but after several hours went by, I recycled the process again, and this time I saw all those error messages again.

I’m grasping at straws but maybe if a process is recycled multiple times with little or no message processing inbetween, then there is nothing in the cache to report on? But after some time has passed, with many different messages going through, more tps procs are loaded into memory, and any with ‘bad’ shutdown logic will force displays in the log?

Peter Heggie
PeterHeggie@crouse.org

[Michael Hertel]

Please post your proc ‘tpsGRV3_Allscrpts_ED_ADT_Filter’ here so we can troubleshoot for you.

[Peter Heggie]

Sure. Thats not really the question I had but I’d be glad to show it.

Maybe I should pick a simpler one. A lot of our procs generate this error message during shutdown. I’ll attach a simpler one which generates the same error message; also I have to say that this is an older filter that could be streamlined a bit, and the next time we modify it we will replace the date & time code with a simpler call to a subroutine.

Peter Heggie
PeterHeggie@crouse.org

[Michael Hertel]

You said shutdown and mentioned these are old procs.

There is a fix for this. I think there is a conversion routine you can run.

I’ll try to find it. Or someone else can chime in.

[Peter Heggie]

thank you – I just assumed that the tcl problem could be fixed by moving the ‘set displist “” ‘ statement above and outside of the ‘mode’ switch logic, basically ensuring that the variable is available for any of the modes, including ‘shutdown’, not just ‘run’. But again, I am assuming, and maybe returning a variable, even when empty, is not a good practise for ‘shutdown’ mode. Maybe instead the return statement should be moved to the end of the ‘run’ mode logic, and the ‘shutdown’ logic should not return anything.

Peter Heggie
PeterHeggie@crouse.org

[Michael Hertel]

I looked in your proc and saw shutdown mode there so it looks as though it was upgraded.

So I went thru your proc.

You need to move: set dispList “”

From inside the run portion to the beginning area of the proc.

proc tpsPharmFilter { args } {

[code]proc tpsPharmFilter { args } {

[Peter Heggie]

thank you – makes sense – that is what we will do. If I can persuade the team, we’ll do it sooner, otherwise we’ll get them as they are maintained. I just can’t stand to see error messages, or even warning messages, in the logs.

Peter

Peter Heggie
PeterHeggie@crouse.org

[Michael Hertel]

I agree, I don’t like these kind of errors either.

I describe it as “driving uphill with your muffler dragging on the ground” to my coworker.

Sure, it still works, and it’s not hurting anyone, but it’s not right!

Also, error logs should only contain real errors, not a lot of useless information. Too many of these types of errors reported tend to make one’s eyes glaze over and cause you to miss a “real” reported problem.

/endsoapbox

[Author]

Replies