× 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.


  • Subject: RE: Use of DUMP in production programs, WAS: RPG enhancement suggesti on
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Wed, 23 Jun 1999 14:14:31 -0400

Hans,

>Buck wrote:
>>Generally speaking, I'd rather that the end-user not see "white messages."
>>I would much rather trap the error myself, produce a post-mortem dump and
>>tell the user to call support for help.  My software looks much more
>>professional telling the user to call support than if an "Invalid array
>>index" error pops up.
>
>How professional does your s/w look if the user has
>to call support for help?  (Sorry, couldn't resist!)

With a straight line like that, I'd be disappointed if you had! ;-)

>I do see your point, though.
>
>A simple, one-liner for us would be to ignore the
>DEBUG keyword when deciding whether or not to
>extract an input field.  As a result, unreferenced
>fields would not appear on the dump, even with
>DEBUG(*YES) coded.  If a field is not used within
>a program, do you really care about its value?

Typically, no, but there are a few difficult, bizarre cases where being able
to see the entire record (referenced or not) is the difference between
finding the subtle bug or not.

>How about a quick vote on some alternatives:
>
>1) Don't show unreferenced fields on dump.
>2) Keyword DEBUG(*ALLOW) which would allow the
>   DUMP opcode to run, but unreferenced fields
>   wouldn't be extracted.
>3) Opcode DUMP *FORCE to force a dump to occur
>   even if DEBUG(*YES) is not coded.  (Again,
>   unreferenced fields would not be extracted.)

Great idea!  I'd vote to keep the existing DEBUG action, and add option
number 3 - DUMP *FORCE.  That way all my old programs work as designed (DUMP
showing unreferenced fields) but I can adopt the new technology in my new
stuff.

Buck Calabro
 --pseudo professional programmer :-)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.