× 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: Because it's there... (Was: Printer Overflow and BIF's)
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Wed, 2 May 2001 17:05:33 -0500 (CDT)


It wouldn't bug me that someone added new code, or even that they didn't
use the same coding style that I did.

However, when adding or removing parameters to a live program, I expect
them to make the parameters OPTIONAL, so that existing calls aren't
broken.  

If they can't do that, I expect them to carefully and methodically find
every place the program is called from, and make sure that it's updated
to match.




On Wed, 2 May 2001, Jim Langston wrote:

> I know what you mean, Jim.
> 
> I use new techniques in all my programs because I can, then I have to
> decide if they make for better programming or not.  I guess, to paraphrase
> an explorer who climbed Everest and I forget his name, because they're there.
> 
> I wrote a program lately that this list helped me on, dealing with subfiles,
> all in RPG IV (was no need to do any linking in this one) with subprocedures
> instead of subroutines, all variables declared in the D specs, the only MOVE
> statements having to do with validating dates, etc...
> 
> Then I got a call that my program was "broken".  Giving a pointer error when
> it started.  No way.  I run the program, pointer error.  Run it in debug, it's
> now expecting entry parms which I didn't code.  I find out that some other
> program in another site wanted to call this program with the invoice number to
> display.  So I looked at the changes she had made.
> 
> D              DS
> D inv#                1     8
> D inv2                2     8
> 
> C     *entry   plist
> C              parm          #inv#      8
> 
> C              move  #inv#   inv#
> C              movel inv2#   DFInv 
> 
> Blech!  You take my nice RPG IV program and stick this RPG II/PRG III junk 
>into
> it?  So I changed it.
> 
> D ParmInv#                 8A
> 
> C     *Entry  PList
> C             Parm        ParmInv#
> 
> C             Eval        DFInv# = %SubSt(ParmInv#: 2: 7)
> 
> then I fix it and the calling CL and, surprise surprise, I test it!
> 
> Everything worked and everyone was happy, especially me knowing my code was
> "clean" again.
> 
> Would this bug anyone else, or was this just a bee in my bonnet?
> 
> Regards,
> 
> Jim Langston

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| 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.