Legacy code. Was:Dates

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

>Bob Cozzi writes:
>
>> Define a constant called NULL_DATE..
>> Then you could do
>> D NULL_DATE        C                          Const(D'0001/01/01')
>> C            IF    myDate = NULL_DATE
>> C            /* do my null-date routine here */
>> C            endif
>
>We use *loval for that.  When the date is not known for update, we move
>*loval where we used to move *zero.  When checking for invalid dates, we
>check for *loval where we used to check for *zero.  Since we stored dates in
>yymmdd format, we always had to convert them to mmddyy for display or
>printing, so the fact that you have to move date data types to another field
>for display or printing makes no difference to us (although it would be nice
>not to have to sometimes).  Overall, date data types do not change any
>program logic for us and are no harder to use.  Any slow down in file access
>(we have not measured any) is compensated for by not having exteral program
>calls to routines for date validation, date comparison, duration
>calculations, etc.  I know *null is the right way to do this, and it is
>really no harder, but we set the standard before RPG could handle null dates
>and we have not revisited the subject yet.  Maybe when we go to V4r2.  Lance..

Today seems like a good day to open a can of worms...

Lance mentioned that "we set the standard before RPG could handle 
null dates and we have not revisited the subject yet."  Our company
has a LOT of legacy code: stuff that was written when RPGIII was 
new, and there were more S/36 programmers than AS/400...

I've followed the debates over the "L" data types very closely,
but we will probably never use them.  Why?  There's no way 
our clients will pay us money to re-do the database and the
supporting code simply to use the "L" data type.  They will
get no additional functionality for the expense they would incur.

The other side of the coin is to implement them as we write
new applications.  That's not quite so hopeless, but there are
significant obstacles even there:
1. Education.  Few on our staff have the luxury of taking the time
    (and billable hours) to learn about new developments like ILE
    and "L" data types.
2. Maintenance.  Do we REALLY want to implement yet another
    way to handle dates?  We already have: Julian (YYDDD),
    Gregorian (MMDDYY), Inverted Gregorian (YYMMDD),
    Inverted Gregorian plus century digit (CYYMMDD - Synon),
    Inverted full Gregorian (YYYYMMDD) All thanks to legacy
    code.  We have been focussing our maintenance efforts on
    using the YYYYMMDD form to store dates in the database
    because it is "natural;" Queries, EIS tools, Data warehouse
    tools, data interchange are all easier.  Any variety of RPG
    (or any language) can read this form and understand it.
3. Multiple systems.  Some clients are on V3R7, some are on
    V3R1.  We even have a few still on V2.  'nuff said.

Sooooo... The questions of the day to the group are:

1. Who pays you to learn new stuff (as opposed to writing
    deliverable product?)
2. Who pays for your learning curve as you come up to speed
    with new techniques?
3. How do you deal with the maintenance issues surrounding
    several incompatible ways of performing the same function?
    At issue here is having to re-engineer each application because
    one can't simply pick up code designed to find the difference
    between 2 dates and put it into another application UNLESS
    the two applications have the same data format.
4. Do you have a rigorous process in place to analyse the cost/
    benefit ratio of adopting new techniques, or do you use things
    like "L" data types because you just want to?
5. How do you train all your staff in the use of the new techniques?
    ILE is a perfect example.  I don't know ANY /400 programmers
    who can just step into the ILE paradigm and run with it.  ILE is
    much more OO than the Midrange world is used to seeing.  For
    that matter, I'd love to use RPG IV in my new code, but the folks
    who may have to maintain it after I'm gone will have a tough
    time with it.  Should I say "to heck with them... they'll catch on 
    sooner or later?"

I'm REALLY interested in hearing what other shops have to say on
the matter or adopting new techniques!  

Buck Calabro
Commsoft, Rensselaer, NY
mcalabro@commsoft.net

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---