Re: Exported Variables (was Long Constant Names)

["Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>]

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