Not being well versed in the computer code remediation, I have a question that I hope someone can answer.

If a bank or financial institution "remediates" its code and claims compliance, can this code be corrupted by transmissions that are not corrected? Is this problem only on that transmission or does in have the potential to act almost like a virus?

Sorry for the ignorance, but I was wondering if the would be the potential for wide spread "relapses" or if this is easily preventable.

Archie

-- Archimedes (robin@icubed.com), February 28, 1999

Answers

Hi Archie. Bad data can't break fixed code. Once the instructions (code) are compiled they are permanent. The problem is bad data getting past an edit program, and making it into the system. Even if bad data is detected, what happens next? Is is bounced back to the sender, or is it sent to an "error list" that requires manual effort to fix it. Consider the number of transactions that happen every day. It wouldn't take much to swamp any manual effort. <:)=

-- Sysman (y2kboard@yahoo.com), February 28, 1999.

I think this generally has to do with "windowing". The problem with "bad" machines corrupting "good" machines has to do with dates of course. If a machine requires 4-digits years, it will not accept 2- digit years. End of that story.

But due to time constraints, some systems use "windowing". In windowing, you pick an arbitrary year - let's say 1930. So with 1930 as the cutoff, 0-29 means 2000-2029, and 30-99 means 1930-1999. The problem comes in when two systems (unknowingly) use different "cutoffs". Lets say another machine uses 1950 as the cutoff, and exchanges data with a machine using 1930 as the cutoff. This means data for years 1930-1950 will be mis-interpreted.

Personally, I think the biggest problem is embedded controllers going "belly-up".

-- Anonymous99 (Anonymous99@Anonymous.com), February 28, 1999.

Hey Anon, good point. I found a similar article on just this point (I'll try and dig it up again) a few weeks ago. This could have an impact, even in a single office. As far as banks, does anybody know if there is an establishid standard for transactions between banks? What if BANK A is using windowing, and BANK B is using expanded dates? Is there some sort of "flag" to indicate this? <:)=

-- Sysman (y2kboard@yahoo.com), February 28, 1999.

Sysman,

Banks do not have an established standard format for transactions between banks. It is the responsibility of each bank to determine the calendar rules used by programs that interface with their systems either internally or externally, and provide for a bridge program that correctly interprets the data coming from one program to another.

From what I've seen, this is an area that many banks are not focusing much attention on. I fully expect that there will be some data corruption problems due to the lack of attention being paid to this potential problem. However, the magnitude of this problem is uncertain at this time.

-- Nabi Davidson (nabi7@yahoo.com), February 28, 1999.

Thanks for the info Nabi. WOW, this is not good!

Can we get some more info on this folks? Don't the banks go thru a common "clearing house" now? I'm not doubting Nabi, but I can't believe this! The banks are regulated, and I would think this includes how transactions are made. Anybody out there working on a Y2K bank project??? <:)=

-- Sysman (y2kboard@yahoo.com), February 28, 1999.

Sysman,

I deal mostly with smaller banks ($150 million and less) that are using purchased application software packages. Therefore, I'm not certain what the data transfer situation is with the larger banks and their in-house systems.

In answer to your question, yes, most smaller banks use the Federal Reserve's Fedline software to perform ACH functions. While Fedline is currently still using 2-digit years, software vendors generally appear to be aware of this, and they are providing bridges to handle the data conversion. Therefore, there shouldn't be many problems in this area.

What I was referring to were internal and external data interfaces with the banks' vendor-supplied software that may have been remediated using different methods. I'm not seeing much cognizance of this potential problem in the smaller banks.

What I don't know is how big a problem there may be from data transfers between multiple systems (either in-house systems or external systems) that were remediated differently. But from what I've seen, the potential for problems certainly exists. Hope that clarifies what I was talking about a little better.

-- Nabi Davidson (nabi7@yahoo.com), February 28, 1999.

Out of curiosity, are there any environments (outside of maybe Java) that routinely exchange pieces of code? I've never worked with object oriented programs, but I can picture entire methods being exchanged. Does this happen anywhere?

-- Flint (flintc@mindspring.com), February 28, 1999.

Check this out.

Bad Data

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000Wyn

-- Andy (2000EOD@prodigy.net), February 28, 1999.

The concern about differences in windowing techniques is greatly overblown. Technically, it is true, that if one system uses '40' for a pivot, and another uses '50', that the years in between could be misinterpreted. But remember, pivot years are chosen based on the application, and the data it processes. That is, a pivot year of '50' would not be chosen, if the data being processed would include dates in the 1940's.

This is also the reason no 'standard' windowing can be used. Different applications may need different pivot years, based on the data being processed.

I think internal interfaces do pose a much more significant risk than external interfaces. External interfaces are well-defined, where internal interfaces may be "fuzzy". For example, systems may have grown over the years to read files from other systems, and this connection usually isn't well documented. For example, one recent project involved replacing an A/R system. All of the external interfaces, and those internal interfaces that relied on passing data files, were well-defined and accounted. But the existing Order Entry system read online the A/R files to determine the customers current credit exposure.

Where this type of "fuzzy" interface could cause problems is when windowing is not used, but date expansion is performed. If the interface was not identified, the reading system would be reading a file with an invalid record format. This type of problem is one of the main reasons date windowing is used as opposed to date expansion.

Hoffmeister

-- Hoffmeister (hoff_meister@my-ejanews.com), February 28, 1999.

As Sysman pointed out, bad data won't break compiled code. However, (and I realize non-programmers won't get this), there are situations where various Job Control languages sometimes use data from the first record of a file to create temporary filenames, decide on which programs to execute, dynamically change sort order, etc. This could be a serious problem if not recognized by the systems analysts/systems programmers.

-- RD. ->H (drherr@erols.com), February 28, 1999.

Thanks for the reminder link Andy. I put my $.02 in that thread, but didn't check it out since. Now I've got to take a day off just to read the rest of the thread! Thanks dude, and keep up the great job!!! <:)=

-- Sysman (y2kboard@yahoo.com), March 01, 1999.