RE:     Legacy code.   Was:Dates

>Bob Cozzi writes:
>> Define a constant called NULL_DATE..
>>   <Snip bobs Null date routine & comments, sorry bob>

>Buck Said;
>Today seems like a good day to open a can of worms...
>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:
>>  <snip Bucks comments of living with yesterday and today while 
      trying to learn about tomorrow>
>Sooooo... The questions of the day to the group are:

>1. Who pays you to learn new stuff (as opposed to writing
>    deliverable product?)

How many of us out there have changed jobs in the last 3-5 years?
How many were downsized, squeeze out, Company moved, quit, out sourced, 
and otherwised found them selves on the street in the last 3-5 years?

What do these questions have to do with question #1 ?  YOU, not your 
employer, are responsible for your career/job continuing education
(ie Marketability). These are the days of the "commodity employee".
The only thing you can "offer/charge for" or "be of value because of"
to your current/future employer is your "Marketable Skill set". 
It is not(nor, never has been) in their "best/most economical" self interest
to pay for your education, period.  Indeed, Education has always
been one of the first things cut in a budget crunch.  Learning the new stuff
always has been and always will be "worth more to the employee than to 
the employer". (By the way, you must stay productive while you learn <BG>)

How many times have you heard people ask "where can I learn such and such"
because they are out of a job or only think of it when they are trying to 
change jobs? (Usually when it's too late.)

>2. Who pays for your learning curve as you come up to speed
>    with new techniques?
See Above.   Remember CARR's rule #1 that
"Tact,  is the art of letting the other person have your way"  <G>

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

Have a shop agreement as to the future direction of a particular standard.
Have a hit list of ways to attach the problem. 

CARR's rule #2

"If your going to the store to buy some milk,  It won't take you any
longer to pick up a loaf of bread" 

Take a browse though your source members sometime in SEU, and then window
over say about 40 or 50,  and look at some of the "Last change date"
of the lines of code.  These programs are "Opened up" and "Worked On"
ALL year long.  Your shop HAS to adopt a philosphy to make small
"benign" changes to the code while your fixing something else".

Like "Hey everybody are new standard is defining variables in the D-Spec
as standalone fields,  Instead of on the Calc. Lines OK?" 
So if you see a variable defined on a C-spec. while you're in 
programs fixing something else,  Move it's definition to to the D-Spec.
After a year or so, you would be amazed at how much your ENTIRE application
base has been upgraded.  Also You will NEVER sell it to upper management
or cost justify upgrading your standards as a project.  This is the only 
way I have seen it work( in 2-3 person mom & pop shops all the way up to 
Fortune 100 companies.   BTDT).

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

Alot of the time,  the critically correct thing to do for the organization
cannot be justified with a strict ROI equation.  

Remember; CARR's rule #3

People nearly ALWAYS buy what they want, NOT what they need.  If they WANT
it, it's amazing the dollar and cents justifications that can be created.
Even at the management or board room level.

Lets say you have a hole in your shoe and say to yourself " I guess 
I'm going to have to buy a new pair of shoes tonight".  Then when you
get home, you find the TV is not working.  You say "I can't afford both"
You will put a piece of cardboard in your shoe and take the TV to get fixed. 

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

Your shop must decide which new functions or additions to be embraced and
when.  RPGIV,  ILE,  TRIGGERS, etc. etc.  Which ones will serve you best 
for the least?   For a transitioning shop RPGIV yes,  ILE no.  
Start with the easy things first.   The move to the new language is a 
perfect time to implement a new set of revised set of "Shop Standards"  

Say "Starting from now on, in RPGIV programs we WILL do it this way" period. 
When is a good time to transition?  Are you still writing for the RPGII
crowd?  When did that change?  When did you start taking advantage of the
RPGIII functions like String Manipulation, Named Constants, after they are
2 years old? 5?
They were new once,  They ain't no more....  If not today,  When???

>I'm REALLY interested in hearing what other shops have to say on
>the matter or adopting new techniques!  
>Buck Calabro
>Commsoft, Rensselaer, NY

There's my thoughts Buck.  
Rensslaer, Hmm,  have you ever been to Rotterdam Junction?

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

This thread ...

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

This mailing list archive is Copyright 1997-2020 by 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].