The VistA error trap in ^%ZTER attempts to log errors in a global. If GT.M can't access the database then it can't save a record of the error, so there will be nothing to display.
In that case, it might have left a dump file or something else behind in its working directory, something like GTM_FATAL_ERROR.ZSHOW_DMP_nnnnn_1 (where nnnnn is a process number). Look for files that begin with GTM or any recently created files. Gregory wrote: >You can also D ^XTER and then ask to see ALL errors. The Kernel >(VistA) error handler does screen out certain errors by default, but >that's for display purposes only. You can display all errors if you >wish. > >=== >Gregory Woodhouse >[EMAIL PROTECTED] > >"One must act on what has not yet happened." >--Lao Tzu > > > >On Sep 20, 2005, at 5:14 PM, Bhaskar, KS wrote: > >> Try a mupip rundown and then a mupip integ to check for database >> structural integrity. If that's OK try running VistA again. >> >> Most likely, GT.M is generating an error message about being unable >> to access the database, but the VistA error handler is probably >> trapping and suppressing the error. >> >> To set up a database that can be recovered in an automated >> (scripted) fashion after a crash, you will need to run journalingm >> >> -- Bhaskar > > --------------------------------------- Jim Self Systems Architect, Lead Developer VMTH Computer Services, UC Davis (http://www.vmth.ucdavis.edu/us/jaself) ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
