y2k countdown: New Dates for Year 2000 Projects: Part I

When doing an application remediation, adding a new extended version of a language willhave valued long term contributions for a fast start after Year 2000 is completed. Perhapsyour language strategy should be considered very carefully. It might just be in your bestinterest to skew your decisions in favor of completing your Year 2000 project on time.Nothing else is more important.

RULE #1: Minimize Change

RULE #2: Adhere to RULE #1

ILE and Date Data Types

Date Data Types bring many awesome advantages to the table. They allow the system andapplication programs to detect, manage, and manipulate values automatically. Doneproperly, concern for validity checking, calculation of date values, sequencing, andformatting virtually goes away for. With date data types and ILE these all belong to"the system".

You have to be aware of the strategy, dependencies and time for this implementation.The values for the future are a wonderful contribution to your future productivity andenhanced code. Is it truly for you and your environment today? Is there a half way housefor now and should you consider stopping there?

Something Old - Something New - Something Borrowed

There are a few concerns here. First, during remediation there is a possibility ofintroducing new variables, that in themselves without Year 2000, have the capability tointroduce their own errors at a less than timely moment in corporate history. Second,these new additions consume time, in and of themselves, that could be better utilized inthe primary mission -Year 2000.

Among this group one might argue the introduction of date data types, RPG/IV or RPG/ILEto obtain the new formats and ease of calculations. If introduction of the new improvedRPG [of the future] is a necessity, then consider establishing the source object modulematch prior to converting the RPG source to the new RPG format. Next, to minimize changeand unexpected data requirements - just convert the source - do not implement any newfunctions until the year 2000 project is done and proven. On the other hand it is verylikely okay to implement this method as long as there is a tool that automates the processand validates all the fields and data for you. Use caution and care before proceeding.

What you are sparring with here, is a second project. Think About It !! For as much aswe try for error free code, history has shown there are standard error rates for suchprojects. [An example might simply come from the fact that there is less supportedfunction at V3R2 or V3R7 then at a more current release. Thus what you read may not bewhat you get.] This second project concept strongly suggests another level ofincreased effort, complexity and extended implementation time. While the finished productwill position you well for 2000 and beyond, you could miss the prime target¾ Year 2000 compliance¾ before failuresand the additional unscheduled fire fighting that it creates.

Naturally, there is some education to be considered. Most of this can happen bybuilding on your prior language knowledge. Limit your Year 2000 use of the new featuresand functions to those that are absolutely necessary to the prime mission. Once yourcompany’s future (and your job) is secure, you can be more adventuresome.

For a moment let’s see what happens should one go forward with all these great newfeatures right now as we convert over to Year 2000 ready code. The objective here is touse all those nice new goodies to improve our code and become Year 2000 ready at the sametime. After all it would have to be done twice if it was not combined today.

First we locate each of the date fields in the database and convert them all over todate data type fields. I am suggesting converting all of them to be consistent, though wecould argue the pros and cons of that along with how many ways one can do datecomparisons, arithmetic, and database storage. Now create the new files with the date datatype and move all our dates over, while verifying their compliance to the new rules of thedate data type structures. Build it or buy it - it has to be done correctly!

Note: This all sounds like a possible tool driven process. If you locate a good onethat fits USE IT !

Glenn will continue this discussion in the June 7 issue.

Glenn Ericson is president and founder of Phoenix Consulting LLC, in East Elmhurst, NY. He specializes in Year 2000 and risk management issues. Glenn-Ericson@att.net.