HP3000-L Archives

January 1996, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Mon, 15 Jan 1996 15:13:57 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
On Fri, 12 Jan 1996 00:43:00 +-100 Leon Degeling said:
>Hi Stan,
>
>**** INTERNAL TRAP
>Data Memory Protection Trap
>[VSM] Undecoded status.info =3D -37
>ABORT: OP014MX0.X.WICS
>NM PROG 7c1.00136894 op014ms0s0025+s4d64
>
>When programming in cobol I get it in 2 situations.
>
>a.      when running out of a table.
>        to find out if you do add ,BOUNDS to the first $CONTROL statement
>        in your source and you should get a bounds violation in stead of a
>        data memory protection trap.
>
>b.      when calling subprogrammes where the buffersize in the subprogramme
>        is bigger then the buffer in the calling programme.
>        surprising results.
>
>If you have some source-debugger (eg trax) it really easy to track [...]
 
You can also add $control symdebug, recompile, :setdump, and re-run the
program.  This will enter debug at the failing location.  If you find that
you are in system code (excluding Cobol runtime) you likely have a bad
parameter in a call (see <b> above) and a stack trace should give you some
hints.  Otherwise you're likely to have problem <a>.  Once in debug, trace
back to find the failing location in your code, then open up a code window.
If you then look back from the current instruction you should find a
statement number label giving you the line number of the offending line
(whether you have a source-debugger or not - I don't think xdb/pxdb is
required for this; the statement labels are inserted by $control symdebug)
 
Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2