4.3.1.2. Julian Date problem 4

[tas1]

As it has been confirmed there is a problem with MIMS 4.3.1.2. and Julian Dates resulting in the application being 'unusable' sometime in May 2007 I was wandering if anyone had any additional information on this.

It would be good to know the following:

1. What is the problem and which parts of MIMS does it affect?
2. What is the exact date this problem occurs?
3. Will problems be encountered earlier, i.e. entering future date information in advance?
4. What is the likelihood of a fix to 4.3.1.2 considering the number of clients on this version? (This will be fixed in Ellipse!)

This, and any other information will be appreciated.

Thanks

 

[Glen]

Tas,

This isn't realy a Julian date problem, but a numeric limit problem. The MSF900-PROCESS-DATE (and other associated fields on the MSF901, MSF902, etc) is a number representing the number of days since the epoch (January 1, 1980). The field is a PIC 9(4) field, allowing values up to 9,999. As Mr. Wales explained to me, 10,000 days divided by 365 gives you about 27.39 years. Here is where your May 7th 2007 limit occurs. Note, however that some transactions have future dates, and problems could be encountered as early as 7 May, 2006.

(Info originally from Steve Wales at Rio Tinto)

The process date is a principal part of the transaction key and is used throughout the system. While remediation of this problem may be possible, it would not be a minor undertaking. Upgrading would be less painful, probably less expensive, and certainly less risky.


Glen

Glen Colbert
gcolbert@rag-american.com

 

[tas1]

Glen,

Thanks for the info you provide.

I cannot believe that Mincom will not provide a fix for this problem as surely they wouldn't/couldn't cope with all the forced upgrades to Ellipse in the required timescale - May 2006.

 

[AddOns1]

Tas,

I don't believe that Mincom will be providing a 4.3.1.2 solution, as the correction is made in 5.2.3.

I have to disagree with Glen (Glen and I do know each other) on the fact remediation being a major task and
risky.

The remediation is quite simple, and a very low risk change. (can be done over a weekend)

I would only recommend this type of change for those clients who have dropped Mincom support, or are converting to SAP / Peoplesoft, and need to extend their MIMS live beyond May 2007.

Jeff

 

[Glen]

Jeff truly does know more than I do about what would be involved in upgrading the MIMS database to deal with this change in the transaction file. From a technical perspective, his guys could most likely convert most systems in a weekend. If this is not a major task for AddOns, it is because they have already done the work and possibly even executed it in production environments. Any complex job, performed by competent professionals, looks much easier than it actually is.

We just have a different perspective on what constitutes a risk. Read his last sentance carefully.

Glen

Glen Colbert
gcolbert@rag-american.com

 

[AlanCWilson]

Hi, (I'm from Mincom's support group)

This is a long & complex subject which would really be best if you worked through it with your local Mincom Support group. Here are some quick answers to your questions and pointers of what to talk to your local support group about.

1. What is the problem and in what parts of MIMS?
The problem is pretty much as described above (but calculation is wrong). The problem mainly affects the date Financial transactions are processed on, the MSF900-PROCESS-DATE in MSF900 (and all the subsequent files this gets moved to). In the materials area MSF22A and in maintenance are MSF740 are the main files affected.

2. When will it happen?
It is 18th May 2007. That is transactions posted after that date, not the date the transaction relates to.

3. Entering future date information.
In simple terms during April 2007, you could create future dated transactions for June 2007. We have not tested this in detail, this is our summary from analysis of the changes we made. We tended to concentrate our testing on making sure the product worked properly after the changes.
It is only once the calendar rolls over to 19th May 2007 that issues will happen. The transactions would still process, they would just have a date back in Jan 1980.

4. Likelyhood of a patch for MIMS 4.3.1.2.
Mincom released MIMS 4.3 in 1998, with the majority of customers implementing it before Dec 1999. These customers have been live on MIMS 4.3 for approximately 4 years. In June 2003, under Mincom's normal support policy, we have started MIMS 4.3 into it's two year retirement phase, with support stopping in June 2005. That gives a total version lifecycle of 6 years for the majority of MIMS 4.3 customers. Mincom expects that all MIMS 4.3 customers would have migrated to the latest version of Ellipse, as part of the normal product lifecycle.

5. Size of the impact.
In 2002, Mincom made changes to Ellipse 5.2.3 to resolve the Julian date issue. This involved around 40 file changes, around 300 program changes and extensive regression testing. Needless to say, it took us a lot longer than a weekend


In 1998 Mincom wrote to all customers as part of the Y2K process, advising of date boundaries within our products.

In the first half of 2003, Mincom wrote to all MIMS 4.3 customers advising them of the availability of Ellipse 5.2.3 and the start of retirement of MIMS 4.3.


So in summary, talk with your local support group about how you upgrade to take advantage of the significant functional and technical enhancements in the Ellipse product.

Have a great day.

 

[tas1]

Thanks Alan - certainly food for thought.

I presume when you say the retirement of 4.3 you mean all versions, including 4.3.1.2

 

[AlanCWilson]

Yes, when I say MIMS 4.3 it means all versions of MIMS 4.3 (4.3.1, 4.3.1.1 and 4.3.1.2).

If you dont already have it, or havent seen it on the Mincom Support site, ask your local support group for the latest Supported Platforms document. For every release of MIMS/Ellipse it details the support dates, the supported databases & operating systems, etc.

Also on the Ellipse Support site is a copy of the letters we sent to customers in the first half of 2007. The FAQ in that document answers most of the questions you asked.

Cheers.

 

[Calator]

Hi guys,

I feel like there were 2 extreme unrealistic untrue ridiculous statements made here - please don't take offence!

1. that a patch to the Julian date problem would be more risky and more costly than an upgrade

2. That a patch could be implemented over a weekend

I feel the truth is somewhere in the middle as stated by the vendor (Alan).
You need to be aware that this is not only a database conversion issue, but also hundreds of programs that require changing if you wish to continue using the application. And changing the software is a manual process.
It's not just MSF900, but many other tables in areas you would not expect such as Production Statistics - to give just an example: extended text (comments) on MSF096 type 'DT' linked to downtime records on MSF420, includes a date as part of the primary key, and that date is in Julian format pic 9(4). Not only do you need to convert MSF096 records, but you also need to modify all the software which refers to MSF096 'DT'.

However, the problem is clearly delimited and could be delivered by Mincom as a patch if the intention existed, at a cost which should be many times less than an Ellipse upgrade!

 

[Calator]

And I would like to add one more idea:

The Julian date issue needs to be seen as a design fault in MIMS, which makes the product unusable past the fatal date in 2007.

When you buy a product, you buy it on the assumption that it works and it will continue to work in the future, without the obligation to buy upgrades.

In my opinion Mincom have a moral and commercial duty to supply a patch to clients, even if they choose not to upgrade and their version becomes desupported.

The fact that a program becomes desupported should not mean that it is ok to become totally or partially unusable due to bugs or design faults.

The Julian date is the same type of design fault as the Y2K bug. The diffrence with the two is that Y2k was a global issue, while Julian dates is a more limited issue and there is not the same pressure and hype involved.

Mincom were probably aware back in 1998 of the Julian date problem as they were looking at the Y2k bug (at least I was) and if they were aware, they should have implemented a fix at the same time as they fixed the Y2k bug. Further more, you would expect that Mincom would apply similar policy to delivering a patch for the Julian date, as they did with the Y2k bug.

This issue should not be used as a way to push expensive upgrades.

 

[Glen]

Calator,

I wasn't referencing the risk and cost if Mincom were to deliver a patch. My reference was to an individual client taking on the customizations of the unsupported Mincom code to make the dates work. For an individual client, if the choice were to upgrade or to hire in staff to perform the customizations and convert the data, I still believe that the risks of an upgrade would be more acceptable and the cost of an upgrade would be lower in the long term. I think your arguments support my position.

As to performing this over a weekend, I believe I indicated that it would only be possible if the work had already been done and tested. If it has been done and tested, the patch could be accomplished over a weekend. That is a mighty big if however.

You have been around MIMS for quite a while now. Right or wront, how 'unrealistic untrue ridiculous' are expectations that Mincom will backfit the changes to any 4.x release?



Glen Colbert
gcolbert@rag-american.com

 

[AlanCWilson]

Hi Calator aka Dan,

Your name sounded familar but its taken me a day to remember that you & I have spoken to each other before, it must have been somewhere during your companies upgrade from MIMS 3.10 to MIMS 4.1 back in 1998 or perhaps during 1999.

You are spot on with your description of the types of other fields & tables that are affected. That is exactly why we did so many files, many programs and so much regression testing.

Looking back to the Y2K days, Mincom (like all software vendors) documented and made public to all customers all known date issues in all its products (including the julian date). This is still available in the "Mincom MIMS Y2K readiness white paper" which you could get again from the Australian support group. Mincom also made commercial decisions about which versions of product to release a Y2K patch for (MIMS 3.10 wasnt one of them because it was at the end of it's product lifecycle).

Mincom has a moral and commercial duty to look after it's customers long term whilst balancing up the commercial reality of product lifecycles with product functionality investment decisions. You are right in saying the julian date problem is clearly delimited, could be delivered as a significant patch and we know what the cost to Mincom would be in making this patch available. Internally we have done the business cases, made the commercial decisions in late 2002 on which versions would be released and communicated this to the affected customers in early 2003.

For me the issue of delivering a patch for the Julian date issue comes down to one main question from a customers point of view -

Given I have been on this version of the product for some years now, the latest version of the product has moved ahead significantly in terms of technology & functionality, would I rather :
a) Spend money on installing a significant patch, which gives no tangible business benefit other than to allow me to stay as I am for another year or two.
b) Spend money installing the latest version, which has significant improvements, can deliver tangible business benefits and gives a solid platform for up to the next 5 years.

The idea of Mincom forcing customers to take patches/upgrades which do not deliver any tangible customer benefit makes no long term commercial sense for Mincom or for our customers. Mincom invests in its products with significant R&D every year (last year was about AUD$13M) which you end up seeing as improved functionality. Overall customers, would rather we spent that money giving improved business value.

The underlying message in the letters to customers in early 2003 was that as part of your normal product lifecycle, your next upgrade during the next 4 years will resolve the julian date issue. The julian date issue is not the reason to upgrade, one of the consequences of your next normal upgrade is the julian date is resolved.

MIMS 4.1 was released in early 1997, your company went live end 1998, so your company will have had 6 1/2 year life span (assuming your Ellipse 5.2.3 implementation goes live mid 2005). In my opinion, thats a pretty good time to squeeze your maximum return on investment out of the last set of upgrade costs. In the next few months your company will be installing Ellipse 5.2.3 with the new Reporting Solution (using Business Objects).

I think it's time to look to the future.

Cheers.

 

[Calator]

Alan,
I am very keen on upgrading to Ellipse. We were discussing the options for other organisations, that may consider not upgrading, or delaying the upgrade. Rhetoric aside, if you don't upgrade your MIMS by 2007 it will go terribly wrong.

 

[AddOns1]

To All,

Like others, I feel the need to address some issues raised by Calator & Alan Wilson.

The idea of changing the code to extend the life of a 4.x/5.3.1.2 system, is really only practical for those clients who have already dropped Mincom support, or will be converting off of MIMS/ELLIPSE due to a corporate mandate, and need to extend the lifespan a couple of years.

For those who are happy with the Mincom product/support, there is no real reason to delay the upgrade to Ellipse. (Unless the company is having financial problems)
---

A little background for those that don't know. Mincom converted the process date from a 4 character Julian date to a 8 character date field. (It seems redundant having this field and creation-date)

Had Mincom done this at the same time they did the Y2K changes, we wouldn't be talking about it now. For those of us who worked with MIMS 2, this has been a known issue for some time. There were discussions at Mincom about this back in 1992.

---

The Patch (not the method we used, but an option)

Process date in MIMS is a 4 character field consisting of 4 numbers, with a limit of 9999, with most (but not all) calculations handled by calls to MSSDAT.

As far as data in the MSF096 table and others, the key fields are actually defined as character fields not numeric fields.

If one were to use a 4 character hex (0 -> F) field, we now have 65,536 possibilities - well past the lifetime of any current MIMS users. (9999 becomes 270F)

So we are talking about a couple of user exits to MSSDAT, and a few more to other select programs.

I've seen patches from Mincom that effect more programs than what's needed here.
---

Timing to convert

As with any change such as a changing of the Chart of Accounts, Employee Id's, Application of a Service or an Version upgrade, there is always the testing/acceptance phase.

The actual conversion of the production data, can easily occur over a weekend.

---

Now, why didn't Mincom choose this method, Because it won't work for all clients!!

On the IBM mainframe, the sort sequence is characters then numbers, so the above solution only works for the Unix/NT/Vax platforms.

Now will Mincom provide a general distribution patch, No because (And I agree here), Mincom needs to maintain a single set of source code.

---

Identification of the tables that contain 'PROCESS-DATE'' can be accomplished with a 'grep' command on a Unix platform. The tricky part (but not hard), is the identification of the fields that contain the process date, but are called something else such as 'FIRST-TRAN-ID'.

From there you grep the source code.

---

As for the 'New Reporting solution - Business Objects', this is hardly new. There is a client here in the USA, that has been using it against MIMS tables for close to 10 years now.

... Jeff


Jeff Sullivan
AddOns Inc
jeff@addonsinc.com