This is going to be a very very very long-running thread about standard error processing, a difficult subject that continues to trip up even the best, most experienced mumpsters.
I'll just start by saying that you really shouldn't combine vendor-specific error processing and standard error processing in the same MUMPS job. Not only are the rules for each one separately complex, not only are the standard features inadequately understood by any living mumpster, not only are there ambiguities and inconsistencies in the current standard's description of error processing, not only is that description among the tersest things I've ever read (as far as the ratio of meaning to words, i.e., the amount of unpacking needed to fully comprehend what it says), not only are the vendor-specific features different for every vendor - even when they use the same names for language elements like $ztrap - but in addition as I learned this week precisely how the vendor-specific elements interact with the standard ones varies from vendor to vendor and in some cases can even be modified by vendor switches to interact differently at differently times within the same implementation.
This came up when we found run-away jobs at Oroville hospital consuming 100% of the CPU. The trigger was a bug in George Lilly's ePrescribing package, which he fixed, but what should have happened is that his error should have been logged and the job halted. It was not George's fault that didn't happen. I'm still conducting an analysis of the problem, but it looks like it was the fault of Rob Tweed's EWD package, which instead of letting the Kernel handle error trapping tries to do so itself, using the nonstandard $ztrap intrinsic function, not noticing that the Kernel had already set up trapping with $etrap.
As I noted above, the interactions involved are very tricky and I'm fairly sure I don't know a single VISTA programmer (including myself and Wally) who has mastered them. When EWD modifies $ztrap, it inadvertently created a condition that led to an error loop, in which errors result in 100% CPU consumption as trapping an error leads to another error and another and another, all without triggering the standard MUMPS conditions that lead to the process being halted to avoid this exact condition.
There are also IHS programs that manipulate the error trap, and we've been intermittently having problems with runaway jobs from them, as well.
Later I'll more fully explore the specific scenario, but for now let's just start out our discussion of error handling by saying avoid it if you possibly can. If you're writing foundational software - in VISTA that would be Sign-on, Broker, Taskman, and possibly one or two other things - then you need to write error-processing code to protect the rest of the system. If not, there are very few situations in which you legitimately ought to be touching the stuff, and if you should then use the standard features only, not the vendor-specific ones. More generally, if the system you're working on is based on standard features, stick with them; if vendor-specific features, stick with those. Mixing and matching is asking for trouble. If you don't know what your foundational software uses, then you don't know enough about your system to be justified in touching the error-processing features.
This is not meant as a dig on anyone. Error handling is very complex in MUMPS, and is orthogonal to the way we usually think about software since it involves stack manipulation, interrupts, and code substitution, all at the same time. The standard's explanation is nearly impenetrable, and no published description of it to date gets into enough detail about it to ensure you can avoid getting into trouble. Worst of all, the trouble you can cause is bad enough that it forces people to drop everything they're doing, and is obscure enough in its causes that it is a nightmare to troubleshoot.
Like indirection, MUMPS error processing is a small step over a very deep chasm. Unlike indirection, I recommend you avoid error processing if you possibly can until we get some fuller accounts of it published.
I'll use this thread to get started on that project.
_________________ Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net "The hidden harmony is best." - Heraclitus of Ephesus
|