Re: ILE Propoganda

I would agree with that.  Before a procedure goes into a service
program, I will test the bajeebies out of it, make sure there is 
no way it can bomb.

This makes them black boxes, I stick something into this black box,
and out comes my result, I don't care what it did in the mean time.

With /COPY members I do have to care, what variables is this declaring
that may mess with my program's variables?  Is it changing any indicators
that may mess with me, etc...  A procedure in a service program should
be 100% transparent to the program calling it, except for the advertised
variables it changes (the return parameter and maybe procedure parameters).

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

rob@dekko.com wrote:
> 
> And I bet you hate using operation codes like READ, or CHAIN since you
> don't have the internal code for these buried in the same program.  Instead
> you have to read an IBM manual to see how they work.  And believe me,
> they've changed over the releases.
> I feel that a well documented, and tested, subprocedure should be every bit
> as trusted/used as a good operation code.
> 
> Rob Berendt
> 
> ==================
> A smart person learns from their mistakes,
> but a wise person learns from OTHER peoples mistakes.
> 
> 
>                     "Bill Bynum"
>                     <bill.bynum@nucorcoldfin        To:     
><RPG400-L@midrange.com>
>                     ishsc.com>                      cc:
>                     Sent by:                        Subject:     RE: ILE 
>Propoganda
>                     owner-rpg400-l@midrange.
>                     com
> 
> 
>                     06/21/2001 12:29 PM
>                     Please respond to
>                     RPG400-L
> 
> 
> 
> >I can't tell you the number of times I've heard various junior
> >programmers
> >say something similar.  How about a more realistic scenario?
> 
> In my MANY years of programming,(mind you that MANY constitutes  a level
> much higher than Jr. programmer) every subroutine written in programs that
> are currently being used in a production environment have been previously
> tested(i.e. old code that is NOT broken). Granted, you may have to tweak
> the
> code(i.e. change indicator references, etc.) but it puts the code right in
> front of you rather than relying on a hardcopy, and/or an additional
> session, swapping back and forth from one to the other.
> 
> Talking about being realistic, when you are dealing with RPGII, RPGIII,
> RPG400, and RPGLE in one environment, and you know that there is a
> subroutine or a piece of code that is being used in an RPGII program that
> would help you in an RPG400 program, you better believe that I will go and
> copy that code and drop it into the new program. And the nice thing about
> it, it works every time.
> 
> Bill
> 
> -----Original Message-----
> From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
> Behalf Of Buck Calabro
> Sent: Thursday, June 21, 2001 12:15 PM
> To: RPG400-L@midrange.com
> Subject: RE: ILE Propoganda
> 
> >It seems to me that if it is code that has been
> >previously written in another program, the
> >simplest and quickest way would be to copy
> >and paste that part of the code to the new
> >program. Let's face it, for most every project
> >you are working on there is a deadline
> 
> I can't tell you the number of times I've heard various junior programmers
> say something similar.  How about a more realistic scenario?
> 
> "copy and paste that part of the code" versus
> 
> o Locate the code.  It's everywhere, so decide which version is closest.
> o Copy and insert the code.
> o Change the field names to fit the new code into the existing program.
> o Check the indicators to be sure there's no overlap.
> o Doing I/O? Check that we won't disturb the file pointers.
> o Manipulating text? Change the array size/field lengths to match the new
> requirements.
> o Manipulating numbers? Change the field sizes to match the new
> requirements.
> o Got work fields?  Don't want to miss them.
> o Test the new code to see if it works.
> o Test the old code to see that it isn't broken.
> 
> Integrating at the "copy the source code" level takes more than simply
> copying lines of text.  If it truly WERE that simple, wouldn't most of your
> code be /COPY statements?
> 
> Buck
> +---
> | 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
> +---
> 
> +---
> | 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
> +---
> 
> +---
> | 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
> +---

--
+---
| 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
+---