Procedure Parameter Change (was Exported Variables)

Paul,

Thanks for sticking with me here.  I'm beginning to wonder if this is
really turning out to be a discussion of style, but ultimately I want to
explore it further and find the best method I should be programming with
(and understanding why it is best).

>Maybe it logs an error or sends a message about the problem.
Why allow the program to give a soft error about something that should
have been allowed in the first place if the coding was done?  Not to
mention it seems that having to code this check into every place the
procedure is called is far more tedious than actually modifying the
procedure parameter.

>Maybe passing back 'A' instead of 'ABC' is ok.
How would the program know?  What if 'A' and 'ABC' were valid, giving a
general situation, it couldn't know that it received 'A' when it should
have received 'ABC' because 'A' is a valid code.

I realize these are general statements, and it all comes down to what a
program is doing.

Say we have the following:

file:
FileA: FldA 1A 

Procedure:
D ProcA           PR                          
D  FldA                          1A   Const   
D  FldB                         10A            

Procedure call:
FileA( code_likeFldA : anotherfield );

Then the file was modified to be:
FileA: FldA 3A

My thought is: modify the procedure to be 3A instead of 1A (which I
think you're saying is wrong, or more prone to problems).

Me: modify ProcA to reflect the new field length, potentially modify
programs that call this procedure, and recompile programs that use the
module this procedure is in.

You (again, from my understanding): create ProcB to reflect the new
field length, recompile programs that use the module this procedure is
in.  Write code around ProcA to catch and send an error when attempting
to pass ProcA a value greater than it can accept... Or check the value
of the code field and move it into a 1a field (if the one
[code_likeFldA] in the proc call is defined with Like(FldA)) and call
ProcA, else call ProcB.

It looks to me that what you're saying is more work with results.  In
effect, it's like coding a bug and at the same time a patch over it, but
not really fixing it.  Or maybe I'm battling my own mindset of how to do
something and am blinding myself to what you're saying (which I hope I'm
not, because I really do want to understand).

Thanks again for sticking with me here.
I've been in ILE for not quite a year, and while I've learned a lot,
there's a lot more yet to learn.

Kurt Anderson

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Morgan
Sent: Friday, January 07, 2005 4:25 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Exported Variables (was Long Constant Names)

Kurt,

The subprocedure code that has both the 1A field in the procedure and
the 3A field in the file should be checking for 'ABC' being passed back
'A' if that's a problem.  Maybe it logs an error or sends a message
about the problem.  Maybe passing back 'A' instead of 'ABC' is ok.

Having a calling program that expects a 1A field suddenly get a 3A field
because the procedure interface has changed is a worse problem.  You
have more opportunities for error with an interface that changes than
you do with an interface that doesn't.  Instead of one accident waiting
to happen in your subprocedure you have many many accidents waiting to
happen in your calling programs.

Paul

--
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333
"Kurt Anderson" <kjanderson@xxxxxxxxxxxxx> wrote in message
news:89C301922C81C24D866BF970E48B00C203C01D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I see where you're coming from.
> My concern is this:
> We expand our Code field from 1A to 3A on a file.
> If I don't change the PI to reflect the new size, or if I create a new

> PI to reflect the new size and leave the old one out there, the old 
> one is an accident waiting to happen.
> The file could have codes: 'A' and 'ABC'.  If I leave the old PI out 
> there, 'ABC' could incorrectly be passed as 'A'.  Hence a loss of data

> integrity.
>
> Am I missing something?
> In the past I've read that you [general public] NEVER change a 
> procedure parameter (which I have done), and I guess I'm not convinced

> (except for the sake of ease and secured safety, as in your real-life 
> example) that I shouldn't.
>
> Thanks,
> Kurt
>
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of Paul Morgan
> Sent: Friday, January 07, 2005 3:13 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: Re: Exported Variables (was Long Constant Names)
>
> Kurt,
>
> ANY change to an interface is bad.  Look at the IBM APIs.  They may 
> extend the API with new optional parameters.  They may provide a 
> replacement API.
> They DO NOT modify an existing API.  You just can't break existing 
> code that relies on that API.  The same should appy to any procedures 
> you create.
>
> With your example maybe only some areas of your application will use 
> the extended 3A length of the code.  Other areas are just fine with 
> the 1A field length.  Create a new procedure with a different name 
> that uses the 3A length.  Use that procedure where needed.  Don't 
> change the existing programs that use the 1A field if it's not 
> necessary.  If the interface doesn't change those programs don't need 
> to be modified or tested.  It reduces the scope of the change.
>
> Maybe you want to phase in the change versus a big bang approach.  You

> can change the interfaces to the programs over time from the 1A 
> version to the 3A version.  Once all the programs are using the new 3A

> interface you can start using the expanded values.  You can't do that 
> if your base interface has changed with a LIKE definition.  You're 
> stuck making that interface change in all places at once (the big bang
method).
>
> A real world example.  Our most recent version of PkMS went from a 3.0

> company number to a 5.0 company number.  We never use anything except 
> company one (1).  If we had all our home grown programs (and we have a

> lot of them) that access PkMS data call procedures with a 3.0 company 
> parameter those procedures would not have needed to change to 5.0.  As

> a result the calling programs DON'T CHANGE and would not have needed 
> testing.  The only thing that would change would be the underlying 
> code below the interface that would convert the new 5.0 company fields

> in the PkMS file to the 3.0 company field in the procedures interface.
>
> In actuality we don't use procedure interfaces to access PkMS data.  
> We go directly at the data files.  We had 3.0 change to 5.0 all over 
> the place in every program that accessed PkMS.  As a result this was a

> nightmare upgrade that required many many program changes and months 
> of testing.
>
> Paul
>
> --
> Paul Morgan
> Senior Programmer Analyst - Retail
> J. Jill Group
> 100 Birch Pond Drive, PO Box 2009
> Tilton, NH 03276-2009
> Phone: (603) 266-2117
> Fax:   (603) 266-2333
> "Kurt Anderson" wrote
>
> > Paul,
> >
> > So I have an understanding about what you're suggesting if a 
> > variable in a procedure interface changes, can you give me an 
> > example of bad
> vs.
> > good?  So I'm clear in my understanding of a variable change, let's 
> > use the example of a 1A code field being changed to 3A to allow for 
> > more permutations and possibly a more mnemonic meaning within the 
> > code
>
> > (not looking to discuss the validity of such a change, just how it 
> > would be accommodated in the interface).
> >
> > Thanks!
> > Kurt Anderson
>
>
>
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing 
> list To post a message email:
RPG400-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a 
> moment to review the archives at http://archive.midrange.com/rpg400-l.
>
>
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing 
> list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, 
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a 
> moment to review the archives at http://archive.midrange.com/rpg400-l.
>
>



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.