Kevin, I think the issue is being diluted somewhat. If you tie a process (to get into the VistA system) through ^ZU, it will not drop to the programmer mode. [In cache I set a username and password to tie directly to ^ZU in the VistA UCI (I won't try to address GT.M)]. On the other hand if as a programmer, you start from programmer mode prompt and receive an error you get dropped back to the programmer mode prompt you started from, with variables intact. This is exactly as it should work. As an analyst I often allow the error and then start tracing the variables/lines of code that caused the error.
Hope this helps. Robert DeWayne -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Toppenberg Sent: Thursday, November 03, 2005 9:59 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] Re: A troublesome and concerning error..... I am having a difficult time following this thread. It seems that Greg is demonstrating on a Cache system, and Bhaskar is answering with GTM examples. I don't understand how these two intersect on this issue. Anyway, I'm glad we have great minds on this list to sort these matters out.... Here is the .bashrc that I use for my users to log in. I don't have any method to trap ^C. Can someone suggest an appropriate trap, and point out any potential security issues? I don't want users to be able to drop to the GTM prompt. Thanks Kevin [EMAIL PROTECTED] vista]# cat .bashrc # .bashrc # User specific aliases and functions # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi #set up infinate loop while [ 1 -eq 1 ] do sh runvista ^ZU done exit On 11/3/05, Bhaskar, KS <[EMAIL PROTECTED]> wrote: > Greg -- > > Again, this seems consistent with the semantics of the JOB command. I don't see where killing a process with SIGKILL (9) drops you back to the direct mode. > > To me, what is interesting is that killing the process owning the lock doesn't allow the process waiting for the lock to eventually get the lock, and you have to hit ^C. In GT.M, the process waiting for the lock eventually gets the lock, as in the example below. > > Here is session 1: -snip- ------------------------------------------------------- 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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- 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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
