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