× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Michael,

If you're debugging, then I'd strongly recommend that you just try using the
interactive source level debugger that is built into the OS on the iSeries.  You
have to compile your program a little differently, specifying source debugging.
Then, before you run your program test, just start the interactive debugger
(STRDBG).  During the start process, the source for your program will be
displayed; just press the F10 key to continue.  Then, run your program.  When
the program gets called, the actual source statement will be displayed and you
can use the F10 key to walk through the program on a step-by-step basis.  If you
want to view any of the variables, please the cursor over the variable and press
the F11 key.  This just gets you started, but it is a much better form of
program debugging.  If you want the program to run to a specific point, then you
can set a breakpoint and the program will run until it reaches that point and
then stop on the instruction that you set it for.  This, in my opinion, is the
best way to debug on the iSeries in COBOL.  I can get a lot done in a single
debugging session.  I came to iSeries COBOL years ago from mainframe COBOL and
once I learned how to use the source debugger, I never looked back.

Rich Loeber
Kisco Information Systems
http://www.kisco.com
  ------------------------------------------------------------------------

Michael Rosinger wrote:

List,

Another ILE/COBOL newbie question. I was running a test program where I was
issuing a lot of DISPLAY UPON SYSOUT messages for debug purposes. The job
was cancelled by the system because "the size of the message queue for job
xxx reached the maximum size". I see from the output that in addition to the
lines I was interested in seeing there were lots of system-generated stuff
that I did not care about.

In the mainframe world, we are used to using a lot of DISPLAY UPON SYSLST
(if need be) and they just get routed to a different spooled entry which is
separate from any of the other reports the program may generate. It's
readily accessible if you happen to need it to verify a problem and easily
discarded if you don't.

So, in the iSeries world, what is the "acceptable" way to create printed
output for debug and tracking purposes? Coding a DISPLAY UPON SYSOUT is, of
course, easier than defining and writing to a print file, but it's not a big
deal if that is what must be done.

Your suggestions please? TIA

--
Regards,

Michael Rosinger
Systems Programmer / DBA
Computer Credit, Inc.
640 West Fourth Street
Winston-Salem, NC  27101
336-761-1524
m rosinger at cciws dot com

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.