• Subject: Re: Legacy code. Was:Dates
  • From: DAsmussen@xxxxxxx
  • Date: Sat, 13 Sep 1997 19:54:12 -0400 (EDT)


In a message dated 97-09-12 17:31:57 EDT, you write:

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

And you indeed have!

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

Why have both of you waited TEN years to upgrade your standards?

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

No, but there's nothing stopping you from using them in all future

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

If you are taking this attitude toward education, then your company is doomed
to failure along with the 7 (now nonexistent) consulting companies on MY
resume.  If your staff are generating an average billable rate, then you are
FOOLISH not to provide them additional education -- regardless of billable
hours lost.  If management is greedy enough to keep THAT close a tab on
billable hours, I'd personally find another job (Lord knows I should have
done that at least seven times previously).  If your company is one of those
"low-ballers" out there that hurts the rest of us, then you DESERVE to go out
of business.  You will NOT be able to keep decent employees without a
commitment to education.

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

Sorry, but Lillian is now the standard.  It's not a question of WANT, it's a
question of NEED.  Yes it's a pain in the gludious maximus, yes it provides
no perceived value to the client, and yes we NEED to do 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?)

DAMN IT, YOUR COMPANY DOES!!!  If you're lucky enough to work for clients
like I do, then sometimes the client pays.  Otherwise, your company NEEDS to
recognize the value of education and pay for it THEMSELVES.  I'm sorry, but
I've attended EVERY COMMON conference that I could since going independant,
and have occasionally paid for my contractors to go as well.

>  2. Who pays for your learning curve as you come up to speed
>      with new techniques?

YOUR COMPANY!!!  Doggone it, can you not see that a Synon-Certified employee
can bring in $10-50/hour more than a traditional RPG programmer?  Education
pays for itself!

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

You create a standard date API, install it in all of your client sites, and
force all of your employees to USE IT.

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

Large companies do.  Small ones must analyze the benefit to their company in
the area of operation.  If you're a consulting firm, new techniques increase
your overall value to the community.  If you're a software provider, then you
MUST analyze the benefits of using new techniques against the range of OS/400
releases that you plan to provide support for.

>  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?"

The same way we used to do with CASE before it failed in its promise.  Hire
knowledgeable professionals to help you with it, and glean all that you can
from them during their term of employment.  I don't know what you mean by
"the folks who may have to maintain it after I'm gone", but you have a
RESPONSIBILITY to bring folks at a client site up to speed on what you've
done.  Yes, you should say "to heck with them...they'll catch on sooner or
later", and you'll be doing them a favor by forcing them to do so.

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

Most take a cautious stance, and THAT is advisable.  I work primarily for
Fortune 100 companies, and have both a WIN 3.1 and a WIN NT computer to
support them.  Most of my clients waited on WIN '95 and determined it to be
an unacceptable business platform.  Despite the hype from IBM, most are
waiting to see if JAVA becomes a viable BUSINESS development tool.  A few
adopted CASE, and are now paying the price.  Consulting firms CANNOT afford
to wait on ILE -- it is rapidly becoming the standard (above JAVA), and more
companies demand it every day.  You should be cautious, but you should also
be AWARE of new techniques...


Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"Man is still the most extraordinary computer of all." -- John F. Kennedy
| 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

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].