[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

358.0. "INFO - debugging hints for MM developers" by TOOK::DITMARS (Pete) Thu Sep 27 1990 12:13

There are several restrictions imposed by the FCL PM on management module 
developers who are attempting to use the VMS debugger to debug their modules:
	1. broadcast message trapper thread may cause you to hang
	2. FCL's forms mode and VMS debugger's screen mode don't cooperate well
        3. terminal's keypad mode is set to NUMERIC
	
1. broadcast message trapper thread may cause you to hang

    The problem:
   
    While using MCC with the VMS debugger (MANAGE/ENTERPRISE/DEBUG), MCC can not
    perform its normal revectoring of certain system services to corresponding
    thread-synchronous routines. This is due to the fact that MCC and the VMS
    debugger use similar mechanisms to perform their respective functions, and
    the debugger prevents the MCC revectoring code from doing its job.

    Enabling forms mode of the FCL (USE MODE FORMS) can cause a thread to be
    created whose purpose is to wait for broadcast messages to be delivered to a
    mailbox.  If you are running in the debugger, the $QIOW that this thread 
    performs will block the process and may prevent you from being able to do 
    any useful work with MCC.

    The workarounds:

    There are several, any one of which will suffice:
	- Do not enable FCL's forms mode while debugging, i.e., avoid
	  doing a USE MODE FORMS in MCC while you are debugging.
	- Disable broadcast messages before starting your MCC debugging session:
	    $ SET TERM/NOBROADCAST
	- Define the FCL debugging flags as follows:
	    $ DEFINE MCC_FCL_PM_LOG 100
	  This will prevent the broadcast message trapping thread from being
	  created.  It will also cause the debugger to be signalled from within
	  FCL at startup.  You can simply type GO to proceed from FCL's 
          debugger breakpoint to your own breakpoints.  Note that if you're
          also interested in ILV dumps before and after FCL does mcc_call_fm's,
          the logical should be defined to be 108.

2. FCL's forms mode and VMS debugger's screen mode don't cooperate well

    The problem:
   
    The VMS debugger's screen mode and FCL's forms mode both use SMG.  If both
    attempt to use to the same terminal, output results will be difficult to
    interpret, and you may receive errors from either FCL or the debugger.

    The workarounds:

    There are several, any one of which will suffice:
	- Do not enable FCL's forms mode while debugging, i.e., avoid
	  doing a USE MODE FORMS in MCC while you are debugging.
	- Use the DECwindows interface to the VMS debugger.
	- Use separate devices for running MCC and the VMS debugger's
	  screen mode.  See the "Debugging Special Cases" chapter of the VMS
          Debugger manual for an example of how to debug screen-oriented
          programs.  It describes how to set the protection on a terminal so
          that you can allocate it for use as your debugger I/O terminal. 
          Another way to do this without resetting the protection on a terminal,
          but which requires BYPASS and SHARE privileges is as follows:

	  (from one terminal or terminal emulator on your workstation)
	  $ sho term		! make a note of the terminal, e.g. TWA12:
				! and the process name, e.g. DEVO
	  $ set proc/suspend	! suspend this process

	  (from another terminal or terminal emulator on your workstation,
	   which has privileges including BYPASS and SHARE)
	  $ set proc/priv=(BYPASS,SHARE)
	  $ define dbg$process NONE	! use single-process debugger
	  $ define dbg$decw$display " "	! don't use DECwindow debugger
	  $ define dbg$input twa12:	! point debugger at other terminal
	  $ define dbg$output twa12:	! point debugger at other terminal
	  $ manage/enterprise/debug	! invoke MCC with debugger

	  The debugger prompt should come up in the TWA12: terminal.

	  $ set proc/resume DEVO	! to allow the process in the debugger
					! window to resume, when you're finished
					! debugging
    
3. terminal's keypad mode is set to NUMERIC

    The problem:

    The FCL PM sets the terminal's keypad mode to be NUMERIC.
    Most developers who use the VMS debugger like the keypad mode to be
    APPLICATION.

    The workaround:

    There are two, either one of which will suffice:

	- Issue the following command at the debugger prompt:
	    DBG> SET MODE KEYPAD
            DBG> ! Or define a key to do this for you in your dbg$init
            DBG> define/key PF3 "SET MODE KEY" /TERMINATE/IF_STATE=BLUE/NOLOG
	- Use separate terminals for running MCC and the debugger, as described
	  above, in item 2.
T.RTitleUserPersonal
Name
DateLines
358.1TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Thu Sep 27 1990 12:4910
    re: .-1
    
    1) Make sure this info gets into the toolkit doc.
    
    2) Sheesh, and you complain to me that Ultrix, in its naive simplicity,
    provides no way to trap broadcast messages?   And that the Ultrix
    debugger is too basic (no screen mode?)
    
    Fancy features are fine if you can keep them from bumping into each
    other!
358.2TOOK::DITMARSPeteThu Sep 27 1990 13:178
re: -.1

1) that was one of the reasons of posting it here

2) the pitiable rantings of a fancy-feature-deprived unix-ite  ;^)

I hope to remove the worst restriction (the bit about the broadcast
thread blocking the process) when I have some spare time.