RE: Debugging service pgm - eval vs F11

I'm not sure why that is, but I think I've seen the same thing.  I just
assumed this was a quirk of V5R1, and fixed in later releases.  I'd think
that entering Eval NNN from the command line would assume the context of the
current line the program is stopped on, and know to look for this field in
that context...  Did you break on a line in your sub-procedure?  

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Peter Dow (ML)
Sent: Tuesday, October 04, 2005 12:40 PM
To: Midrange Systems Technical Discussion
Subject: RE: Debugging service pgm - eval vs F11


Hi Eric,

Yes, it is a DS subfield that didn't get initialized, but it's a global DS,
and the error occurred in a subroutine, not a subprocedure, and that's
what's puzzling.  I fixed the initialization problem, but I don't understand
why debug couldn't find it when I used the EVAL command, but could find it
when I used F11.

There is one subprocedure in the program, but it does not reference the
field in question.

Peter Dow
Dow Software Services, Inc.
www.dowsoftware.com
909 793-9050 voice
909 793-4480 fax

> -----Original Message-----
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of DeLong, Eric

> That looks like a local DS subfield that never got initialized.
> By default,
> data structures are initialized to blanks (hex '40').  In this case, your
> FLD field is defined as packed decimal.  Since it seems to be local to a
> procedure, debug has trouble knowing where to look for the
> storage for this
> field.

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.9/118 - Release Date: 10/3/2005