Prev: Changing a scripts parm value
Next: 182966 Constantly updated Free COmputer and business portal 94
From: Derek Schrock on 2 Feb 2010 08:26
On Feb 1, 9:42 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote:
> Derek Schrock wrote:
> >>>Make sure that what you are CALLing (if it is COBOL) has been compiled for
> >>>debugging.
>
> >>Jeez ! That WOULD be quite helpful, wouldn't it ? :-)
>
> > To All,
> > Thanks for the prompt replies.  IRC has been a drag for COBOL support
> > and Microfocus forums have maybe three users.
> > But yes it's COBOL calling COBOL; I'll check tomorrow on how to build
> > the calling program for debugging.  I remember seeing this option int
> > the man page.
> > However, what type of file is a CALL executing?  .int? .gnt? If I have
> > both in $PATH should I make sure to only have the .int to ensure the
> > debuggable one is executed.
>
> It's not that complicated - well it isn't once somebody spells it out
> for you. At this stage you are in the IDE, writing source and then
> compiling and testing.
>
> 1. Ensure the box at the top left of the IDE 'Type of Build' shows
> "Generic Debug Build" in the dropdown list.
>
> 2. The first program you want executed in the project should be the
> first one that you use this feature for : Dropdown Menu : Project---->
> "Add files to Project"------> gives you a list of files - select
> Program-1.
>
> 3. Having added that first program, you can now do the following.
> File----> Open----> and open Program-1. (Alternatively in the RIGHT Pane
> - alphabetical list of files - select the source you want. (Don't select
> the ***.int from the Left Pane Treeview - anyway the Left Pane 'is a
> pain' - doesn't show entries in alphabetical sequence).
>
> 4. Now go to Project----> and you should see Program-1 Specified against
> 'Compile', (or as a quickie you can use CTRL + F7 for a Build/Rebuild of
> Program-1).
>
> 5. You can follow Steps 3 and 4 for each program added, if you wish.
>
> 6. You are not quite sure what you have changed over time, then from
> Project----->select "Rebuild" which rebuilds all source which may have
> been changed.
>
> 6. At some stage at completion, (or earlier if you prefer), Project---->
> select "Rebuild ALL".
>
> 7. All these 'Builds' generate your ...INT and ....IDY files in the
> \DEBUG sub-folder for the Project. (They are used by the ANIMATOR). I
> recommend that for the developing stage, you ignore reference to files
> ....GNT - I've never specifically used them.
>
> 8. Running data tests against the whole shebang - you find a program
> croaks with a logic error. You may be aware of which programs or
> situation where the error occurs, so you can zero in on that source for
> correction. Establish where in the appropriate source, that the error
> occurs and set an Animator BREAKPOINT just before it goes awry. Use the
> 'EXAMINE' feature (Magnifying glass Icon) to see the values in variables
> causing you problems. As you get into the swing of things you can
> monitor variables or record fields and even put them into a temporary
> WatchList.
>
> 9. Building an executable - a different topic; you can read up on that
> later, but you have a fair bit to comprehend without worrying about that
> at this stage. When it comes to building the Executable(s) and support
> DLL libraries, you switch that Top Left 'Type of Build' ---> to read
> 'Generic Release Build'.
>
> I would recommend that you don't use the Release feature until you are
> more than satisfied that the project will work without any errors - that
> of course you can only find out by throwing spurious data at the
> project. But I might add, using the Animator feature EXAMINE you can
> change a value like "Tom Jones" to "Thomas Jones", '123.45' to '932.67',
> or just for fun put alphabetics into numeric fields.
>
> HTH
>
> Jimmy, Calgary AB

I'm not using an IDE; it's vim to edit and cob to compile.
From: Derek Schrock on 2 Feb 2010 10:27
On Feb 2, 8:25 am, Derek Schrock <derekschr...(a)gmail.com> wrote:
> On Feb 2, 3:44 am, CoboLero <cmari...(a)gmail.com> wrote:
>
> > On Feb 1, 10:34 pm, Derek Schrock <derekschr...(a)gmail.com> wrote:
>
> > > Any idea how I can step INTO a CALL's code block using Microfocus
> > > Server Express 4.0 SP2 on HP-UX B11.11?
> > > Right now when I step on the CALL statement the animator executes the
> > > CALL by stepping over and not into.
>
> > Just press F11 to step into the call or any other procedure, instead
> > of F10.
> > Christos.
>
> I don't have an F11 commannd
>
> http://supportline.microfocus.com/Documentation/books/sx40sp2/udpubb.htm

Ok so the problem was resolved! CALL is executing .gnt files hence
the reason why the debugger didn't step into the CALL's code. Moving
the .gnt file[s] allows the debugger to load the .int file and I am
now debugging the CALL's code.

Thanks for the help guys.
From: Michael Wojcik on 2 Feb 2010 10:55
Derek Schrock wrote:
> On Feb 1, 7:51 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote:
>> Pete Dashwood wrote:
>>> Derek Schrock wrote:
>>>> Any idea how I can step INTO a CALL's code block using Microfocus
>>>> Server Express 4.0 SP2 on HP-UX B11.11?

That's a rather old release, and I'm sure I don't remember everything
that's changed since then, so take this with a grain of salt.

>>>> Right now when I step on the CALL statement the animator executes the
>>>> CALL by stepping over and not into.

To summarize the other replies:

- Animator (like most debuggers) supports step-over and step-into.
Make sure you're using the latter.

- Animator only supports COBOL programs. If the target of the CALL
statement isn't COBOL, you can't debug it in Animator. (Actually,
there are mixed-language debugging options in Net Express, but I've
never looked at them, and I don't know that there's anything similar
in Server Express. Probably not, given the vagaries of debugging on
various Unix platforms.)

- Animator won't step into COBOL code that isn't compiled for debugging.

In short: the thing you're calling has to be a COBOL program compiled
for debugging, and you have to be sure you're using the correct
Animator command.

> However, what type of file is a CALL executing? .int? .gnt? If I have
> both in $PATH should I make sure to only have the .int to ensure the
> debuggable one is executed.

The target of a CALL statement can be any of:

- an entry point (including COBOL programs, ENTRY statements, and
public symbols in non-COBOL code) in the current process - ie,
statically linked or already loaded

- the name of a .gnt module that has not yet been loaded into the
current process, but is in the current directory, or on $COBPATH
(*not* $PATH), or in the directory containing the calling program, or
in $COBDIR/dynload. (Once it's loaded, the default entry point will be
called; this is discussed in more detail in the docs. Subsequent calls
to this name fall under the previous case.)

- the name of a .int module that has not yet been loaded into the
current process, but is found using the search order listed above for .gnt

- the name of a COBOL Shared Object (CSO) module that has not yet been
loaded into the current process, but is on the OS library loader path
($LD_LIBRARY_PATH, $SHLIB_PATH, and/or $LIBPATH, depending on Unix flavor)

The search order, and the preference for .gnt over .int, can be
modified using run-time tunables. See the SX documentation on Run-time
Configuration.

..gnt modules and CSOs can be built for debugging, by the way. Also,
note that .gnt is a deprecated format. It's still supported, but it's
inferior to CSO.

--
Michael Wojcik
Micro Focus
From: Derek Schrock on 3 Feb 2010 09:27
On Feb 2, 10:55 am, Michael Wojcik <mwoj...(a)newsguy.com> wrote:
> Derek Schrock wrote:
> > On Feb 1, 7:51 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote:
> >> Pete Dashwood wrote:
> >>> Derek Schrock wrote:
> >>>> Any idea how I can step INTO a CALL's code block using Microfocus
> >>>> Server Express 4.0 SP2 on HP-UX B11.11?
>
> That's a rather old release, and I'm sure I don't remember everything
> that's changed since then, so take this with a grain of salt.
>
> >>>> Right now when I step on the CALL statement the animator executes the
> >>>> CALL by stepping over and not into.
>
> To summarize the other replies:
>
> - Animator (like most debuggers) supports step-over and step-into.
> Make sure you're using the latter.
>
> - Animator only supports COBOL programs. If the target of the CALL
> statement isn't COBOL, you can't debug it in Animator. (Actually,
> there are mixed-language debugging options in Net Express, but I've
> never looked at them, and I don't know that there's anything similar
> in Server Express. Probably not, given the vagaries of debugging on
> various Unix platforms.)
>
> - Animator won't step into COBOL code that isn't compiled for debugging.
>
> In short: the thing you're calling has to be a COBOL program compiled
> for debugging, and you have to be sure you're using the correct
> Animator command.
>
> > However, what type of file is a CALL executing?  .int? .gnt? If I have
> > both in $PATH should I make sure to only have the .int to ensure the
> > debuggable one is executed.
>
> The target of a CALL statement can be any of:
>
> - an entry point (including COBOL programs, ENTRY statements, and
> public symbols in non-COBOL code) in the current process - ie,
> statically linked or already loaded
>
> - the name of a .gnt module that has not yet been loaded into the
> current process, but is in the current directory, or on $COBPATH
> (*not* $PATH), or in the directory containing the calling program, or
> in $COBDIR/dynload. (Once it's loaded, the default entry point will be
> called; this is discussed in more detail in the docs. Subsequent calls
> to this name fall under the previous case.)
>
> - the name of a .int module that has not yet been loaded into the
> current process, but is found using the search order listed above for .gnt
>
> - the name of a COBOL Shared Object (CSO) module that has not yet been
> loaded into the current process, but is on the OS library loader path
> ($LD_LIBRARY_PATH, $SHLIB_PATH, and/or $LIBPATH, depending on Unix flavor)
>
> The search order, and the preference for .gnt over .int, can be
> modified using run-time tunables. See the SX documentation on Run-time
> Configuration.
>
> .gnt modules and CSOs can be built for debugging, by the way. Also,
> note that .gnt is a deprecated format. It's still supported, but it's
> inferior to CSO.
>
> --
> Michael Wojcik
> Micro Focus

Thanks for the lengthy response Michael this is very valuable
information. However, some of the items you sited I don't have
control over only because I'm only a poor luser.

We're stuck in B11.11, and can't switch to CSO.

But making use of $COBCONFIG and runtime turnables should turn out
very well for testing.
From: Michael Wojcik on 4 Feb 2010 11:04
Derek Schrock wrote:
>
> Thanks for the lengthy response Michael this is very valuable
> information. However, some of the items you sited I don't have
> control over only because I'm only a poor luser.

Understood. It's rare to have complete control over the problem space,
and we're all subdued to what we work in, eh?

> But making use of $COBCONFIG and runtime turnables should turn out
> very well for testing.

Yes, I think you'll be able to control everything you need to, in
order to get your debugging to work.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Changing a scripts parm value
Next: 182966 Constantly updated Free COmputer and business portal 94