memories of code sabotage--was RE: Because it's there... (Was: Printer Overflow and BIF's) -- RPG400-L

I think it's happened to most of us.  I almost worked on a program a few
weeks ago that was cloned from one I wrote a few years back that had been
modified from the original clone job recently to allow a new program end
condition.

The program, a screen program, had had a main loop with a select statement
that set a flag when it was time to end the loop and go home.  The person
who modified it two years after the cloning replaced the select with if
statments and added the new end program condition by burying a seton lr and
unconditional return in a subroutine referenced in one of the if statements.
The original flag was still there, but it just wasn't used for anything any
more. 

Just when I was ready to start, the need for the modification I was to do
went away.  Some day I'm going to sneak in and repair the logic.  <g>  

> -----Original Message-----
> From: VIJI SETHURAMAN [mailto:VIJI.SETHURAMAN@dfs.com]
> Sent: Wednesday, May 02, 2001 10:27 AM
> To: RPG400-L@midrange.com
> Subject: Re: Because it's there... (Was: Printer Overflow and BIF's)
> 
> 
> 
> 
> It would bug me a lot.
> 
> 
> 
> 
> 
> Jim Langston <jimlangston@conexfreight.com> on 05/02/2001 09:11:15 AM
> 
> Please respond to RPG400-L@midrange.com
> 
> To:   RPG400-L@midrange.com
> cc:    (bcc: VIJI SETHURAMAN/US-SFO/USERS/DFSGL)
> 
> Subject:  Re: Because it's there... (Was: Printer Overflow and BIF's)
> 
> 
> 
> 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
+---