There is no way in Hades I would support this unless it was done properly. I do not want an EHR written by the average John Doe Programmer who is doing his own error trapping. I was in the VA for 29 years, I know/knew many many of those programmers. There is no way I would trust them with error trapping. What I have suggested in the past, and obviously was never acted upon, was that the Kernel provide an API that would grade the severity of the error. The SACC would have a standard which would tell the developer what actions he is allowed to do for any particular grade of error. Also, I would prefer that the Kernel develop a generic error trap setting API instead of letting the average programmer do this. If VistA-M does end up using much much more individual developer designed error trapping, then the entire viability of VistA as a rock solid EHR would be seriously jeopardized.
Recent emails in this vehicle support this view point. One email talked about possibly having $D(^AUPNPAT(0))=0. Excuse me, if that is a true situation, then that system has an extremely serious database issue. On the surface it is easy to fix and normally an <UNDEF> error would not be considered a major system issue. But in this case it is. Where did this implementation of VistA come from? What was the cause of that file being undefined? Questions like these cannot be calculated in a simple error trap. When I was a VA CIO, if I saw that error in my error trap, I would have IMMEDIATELY shut all processes down including Taskman and denied all user access no matter what time of day it was. I would have an answer to the question to what happened to the file before anyone would be allowed access to the system, let alone the downtime to perform the appropriate database restore. Then I would have to investigate which records were incomplete and fix them before anyone had access to the system. There could be several reasons for the non-existence of this file all of which have very different basic root causes. Do you really want the average programmer out there setting his own error trap and making decisions as to whether or not he should allow processing to continue? Or is the current VA approach a more secure approach which is treat all errors as fatal, log them to the error trap, and disconnect that user? If every VA VistA programmer was a George Timson or a Michael Distaso then I would have such reservations. ----- Original Message ----- From: "Gregory Woodhouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, April 04, 2005 12:54 AM Subject: [Hardhats-members] Maintaining database integrity > I've noticed there's been a lot of discussion of dangling pointers and > other types of database integrity issues at the application level. My > experience has been that these sorts of problems are much more common > than problems at the global level (i.e., in the MUMPS subsystem). > > Part of the problem is that updating pointers when a record is deleted > is an expensive process, and when deleting records at the application > level, people often tend to skip it. A second issue is that Classic > Fileman uses a field by field (rather than a record at a time) model > for editing that is not always appropriate. In general, using the DBS > ("silent") interface can reduce the likelihood of introducing errors > (and, in fact, I use DBS calls almost exclusively). A more significant > issue is proper use of the MUMPS error trap. I've noticed that many > developers tend to look at setting an application level error trap as > an "extreme" measure and are loathe to make use of it. I don't believe > this a good practice and would argue that it should be used much more > than it is currently. One possible issue is that Kernel sets a default > error trap that logs errors and application programmers often forget to > call ^%ZTER to log the error (as appropriate) and so think that setting > the error trap will prevent errors from being logged when they should > be. Another issue is that trapping errors is a tool that can be misused > (simply ignoring errors like "disk full" can cause database problems). > A final issue is that the Standards and Conventions document (SAC) > currently does not provide any guidance or standardization in this > area. This is something I hope to address. > > > Gregory Woodhouse > [EMAIL PROTECTED] > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
