RE: Exported Variables (was Long Constant Names)

["Kurt Anderson" <kjanderson@xxxxxxxxxxxxx>]

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.