Using the Unidata Debugger "OUT" Command w/ SB+ Debugging

[precisonline]

One of the coolest tricks for debugging complex SB+ applications on Unidata actually involves the Unidata debugger.  When a message appears and you're uncertain from whence it came, press <break> and enter a "?" and Unidata will show you the call stack of all of the subroutines that have been called up to this message.  Especially when debugging vendor apps that use an enormous amount of BASIC, this little trick can be a real time saver.

I've struggled, however, with finding a way to get past the error and back into the main program to check data values and the like.  The trick, I have learned today, is the debugger "OUT" command.

Inside of the SB+ application, everything's just a subroutine, so if you find yourself in the debugger inside of an SB+ routine (like the SB.DISP routine that displays messages), entering "OUT" at the debugger prompt will run the current subroutine until it returns back to it's caller and will then stop again.  If that caller is another SB+ routine, entering "OUT" again (and potentially again) will eventually return you to the originating BASIC subroutine that called SB.DISP to generate the message.  You can then examine variables and do all the other cool stuff available in the debugger to figure out why the message appeared in the first place.

If you've spent much time with the Unidata debugger, this may be old hat for you.  But if you're like me and try not to lean too heavily on the debugger, hopefully this tidbit will help you save some time someday.

[LasVegasSBUser]

Hey Kevin is there any better deguggin tools for SB? I don't like typing EXEC BASIC <<Dir> <<FileName>> -Z2 and Z <dir> <FileName>> each time I need to debug a program. I like doing it once and staying in debug mode but if you have a large program in SB calling another PROCESS you have to type the debug Syntax over again.
See Below

MED.WAIT.START.DATE = NIL
DENTAL.COVERAGE = "N"
DEN.CERT.START.DATE = NIL
DEN.CERT.END.DATE = NIL
EMPLOYEE.DIVISION = NIL
MED.DEPEN.IDS = NIL
DEN.DEPEN.IDS = NIL
READV INS.CLASS FROM BENEFIT.PLANS,SV.PLAN.ID,3 ELSE
          INS.CLASS = NIL
END
EMPLOYEE.BEN.ID = EH.CLIENT.ID:".":ACTUAL.EMPLOYEE.ID:".":SV.PLAN.ID
READ BENE.XREF.REC FROM EMPLOYEE.BEN.XREF,EMPLOYEE.BEN.ID THEN
     **Kevin when I jump to this process I have to type the DEBUG syntax again**
      CALL UTL.GET.XREF.DATE(BENE.XREF.REC,XTO.DATE,XREF.DATE)
     IF XREF.DATE = "" THEN
        XREF.DATE = BENE.XREF.REC
     END
END
READ EMPLOYEE.BEN.REC FROM EMPLOYEE.BEN,EMPLOYEE.BEN.ID THEN
     BENEFIT.STATUS = EMPLOYEE.BEN.REC<1>
     IF TERMS = "Y" THEN
        BEGIN CASE
         CASE INS.CLASS = "M"
              I.WAIT.START.DATE = EMPLOYEE.BEN.REC<2> - BENEFITS.WAIT.PERIOD
              WAIT.START.DAY = OCONV(I.WAIT.START.DATE,'DD')
              WAIT.START.MONTH = OCONV(I.WAIT.START.DATE,'DM')
              WAIT.START.YEAR = OCONV(I.WAIT.START.DATE,'DY')
Thanks

[precisonline]

If you step into the subroutine you shouldn't have to do anything more to re-enable the debugger.  Are you saying that it doesn't bring in the symbol table or code text when it jumps into the subroutine in debug mode?

[LasVegasSBUser]

Yeah Kevin when I jump to the UTL and try doing a /* to list all the vars in the calling BP I get the old "no symbolic table" error. I guess I can keep typing the BAISC Syntax its no big deal but I have to look somemore.

Thanks

[precisonline]

Interestingly, if the code was originally compiled with -D or -Z2 that shouldn't need to be done.  I don't believe SB+'s /SE does this automatically BUT I think if you go into /GC and press F7-Params there's a place where you can set the default compilation flags for /GC and I think it affects /SE the same.  Otherwise, just be sure to compile everything with -D or -Z2 (instead of via F8 in /SE) and you shouldn't need to jump thru these hoops.