× 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: "Eric N. Wilson" <doulos1@xxxxxxxx>
  • Date: Wed, 23 Jun 1999 09:47:50 -0700

I personally favor the Debug(*Allow)

Thanks
Eric

______________________________________________
Eric N. Wilson
President
Doulos Software & Computer Services
2913 N Alder St
Tacoma WA 98407


----- Original Message -----
From: <boldt@ca.ibm.com>
To: <RPG400-L@midrange.com>
Sent: Wednesday, June 23, 1999 7:47 AM
Subject: Re: Use of DUMP in production programs, WAS: RPG enhancement
suggesti on


>
>
> 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!)
>
> 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?
>
> 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.)
>
> I'll add the results of the vote to our proposed
> enhancements list.
>
> Cheers! Hans
>
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
>
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * 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          *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

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

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.