The August 14, 1998, At Your Service indicates the dates MC tested.

MC has received several calls asking what they should test.

What Should I Test?

TEST WHAT YOU DO ON A DAILY BASIS THROUGHOUT THE YEAR.

We recommend each customer test using the MB Operating Schedule Guide and the LS Operating Schedule Guide for a starting point. If there is something they do not do on a normal basis, like paying interest on escrows, of course they should skip it or use their own adjusted guide.

Do I Have to Test Every Date MC Tested?

That is the call of each customer. You are not limited to these suggested dates MC tested nor to the operating schedule guides, you may test more dates if you want to. Testing MUST be done in chronological order. DO NOT change date back after advancing during testing.

Customers need to be aware of potential problems outlined in the Tips in Loan Servicing Y2K Testing. They have to test just a few loans because it would be difficult to do their entire portfolio. Customers should do 10 or 15 loans and go through the daily, weekly and monthly features they use on those particular dates (chronological order) they select. The Tips in Loan Servicing Y2K Testing (pink) went out with the release.

Read all documentation before testing.

The Command Date

You cannot update anything beyond the command date. For instance, if they are running interest accrual payable on a monthly basis, then the date is only a month ahead. If not running accruals, the date is set at 12-01-99. As soon as they advance beyond, it is not going to let them update anything. Refer to the Command Date section of the Tips in Loan Servicing Y2K Testing.

If a customer were calling me, the tip I would give them would be to make sure they look to see the procedure is 01. There is a SYS for the origination (meaning the system in control). If they try to put in 00 as a procedure, the system will not recognize the entry.

Question: What kind of error do they get?

Answer: Update not allowed. Interest accrual... what ever verbiage they have keyed into their command date.

Cutoffs

If the customers want to skip months, the dates are not going to be advanced automatically in your investor master record. The customers must modify the master investor record and set it forward (03.25.04). Not only do that have to change line 7, which is the day of the month you want the cutoff, but you have to change lines 12 and 13 to be the ending of the month of the previous cycle. Make sure there is always a logical 30 day cutoff for the report.

Remember, the program will not let you go ahead and post payments in the next month until you have run the cutoff for last month. This function is program controlled. If the customer wants to skip and go from February to December, they have to modify the dates in order to proceed. The dates have to be consistent.

Escrow Analysis

We do not recommend analyzing the entire portfolio. Select a few (maybe 10 or 15 loans) and set Field 92, and do the analysis for those loans. Remember to change the dates (in order); do not go backward then move forward, and try to jump back again. You should start your analysis 45-60 days prior to the date entered in Field 92. (ONLY MOVE FORWARD AND NOT BACK.)

The Year End Save Procedure

The program only allows you run this procedure once per year. If this procedure cannot be run, it means it has already been run. Y2K testing can be confusing, so be careful not to run this out of order, and run everything before you change dates.

Lock Loans

All the same rules apply with testing that apply with regular day-to-day procedures. Make sure no one else is in a modification or update screen when doing an update or the year end procedure. You will still get a locked loan. EXIT that loan on the other terminal and then press <NL> to proceed. They should not break out of any update routines, even in testing, because it will still corrupt files and they will have to stop and run an ISAM before they can proceed.

ICHOST/ICOBOL

The MC Y2K Compliant Certificate is just for MC Software. The customers will need to certify all software used including ICHOST and/or ICOBOL, which are not Mortgage Computer programs. ICHOST is not Y2K compliant and a few ICOBOL versions are not Y2K compliant. The customer who wants to have the ICOBOL Certificate can be referred to ICOBOL's Web site.

We have encouraged our customers to upgrade to ICOBOL. Support on ICHOST was dropped a year and a half ago. We have talked to the developers of ICHOST and ICOBOL and we were told there should not be a problem with ICHOST, but they were not going to test it and not planning to certify it. If an MC customer wants to be 100% sure they are compliant, they need to install ICOBOL.

The Y2K version of ICOBOL is available for the Data General AViiON, IBM RS/6000, DOS, Novell, and Windows NT. They do NOT have it available for the Motorola systems. All customers on Motorola are aware they need to change machines.

If an MC customer has MC's Y2K Compliant version and the ICOBOL's Y2K compliant version, you still need to test. Customers could still encounter problems during testing, with their operating systems, their hardware (computers, printers, etc.). Hardware could affect MC Software. MC will not be able to support or help customers with any hardware issues. They need to work through their manufacturers.

Customers that have Microsoft products, the only certified operating system is Windows 98. Windows 95, DOS, NT, are NOT certified. Refer to Microsoft's Web site. They have published information on what is and is not Y2K compliant.

The Ideal Way to Test

The ideal way to do your Y2K test is you have another machine, completely separate from the first or live machine. Backup and Restore the mcadata directory. Make arrangements with marketing for an ICOBOL license for the other machine. This will make changing the system date possible for testing without messing up live data.

If a seperate system is not an option, customers will have to Backup their mcadata directory. Restore the backup in another location and guarantee your Backup is good. DO NOT BEGIN Y2K TESTING WITHOUT A CONFIRMED BACKUP. It is very important to verify by restoring the backup that your back up is good. This backup will be very valuable after testing. The only way to guarantee the data files are really valid is to go to another machine (or directory) and restore the backup data. Verify the same number of files and the same disk spaced used. Actually using the backup is the best test.

If the customer must use their live system. The customer will have to advance the date forward. After the customer has completed the testing, they MUST DELETE (not overwrite, this is why the verified backup is important) the mcadata directory. Then restore mcadata from the backup. Make sure you DO NOT restore over the top of the Y2K test data. Many programs create files like transaction groups. The system builds a tran group and history files, etc., you restore the back up over the Y2K test and these files REMAIN there. They do not match the rest of the files that index to the system.

Those testing on the same system may use a separate directory. The ideal and recommended procedure is to Restore the Backup in another directory and change the logins to point to the Y2K test directory or create a special Y2K login. We suggest, so the customer can use all the same logins, Backup mcadata, rename to livedata and Restore mcadata, and test in your mcadata directory. This verifies your Backup is valid with no files missing. After your Y2K testing, DELETE mcadata and rename livedata to mcadata. Most customers will have enough space to do this; however, they should confirm this before starting to ensure reporting will function when creating temp files.

Many use their CU backup, but the vendor is not backing up MC software programs and data. We strongly recommend a separate Backup. MC will provide any assistance requested. However, this assistance is billed at $100 per hour 7:00 a.m. to 6:00 p.m. Outside these hours, the cost will be $150 per hour.

Customers may want to test on several terminals. However, testing on one terminal should be sufficient.

MC does not have any CU Vendor Software and cannot test the Interface (Mailbox) to a third-party vendor. MC has tested the MC Interface Software by creating the teller file, DDA, and others to our record structure. Everything will work if the CU vendor is using the same record structure, but if they have changed something in their software for Y2K compliance and/or modified the layout, then it is not going to work correctly.

One of the business partners has asked MC if we were going to change the Mailbox. The indication to them was "no we are not." We are using the window method with our software, so as not to change the size, shape, or color of any of the files. The files are the same structure. In other words, in the date field it is not necessary for a four-digit year. We use the window method with 60 as the pivot year.

Updated August 22, 2002 at 6:48 a.m.