Learn how I can make a difference #thatsIntelligence


read more @ www.agileatwork.co.uk

The 202 problem!

Hi Guys,

I don't think I've ever started a blog article off in such a casual way! but I've just returned from a brief Easter visit to the Isle of Wight so I'm probably feeling much more relaxed and casual than usual! - All I'll say about the Isle of Wight is that much fun was had... however under a self imposed 30year rule on telling stories about my personal life the details will have to remain a mystery... unless I choose to publish my memoirs earlier (I'm just waiting for that phone call and the all important cheque from a publisher) but what I will say is if they make a movie it will be hilarious... unlike the following blog!

Before you read any further... be warned, this is a boring blog entry and unless you have a love of COBOL - You probably shouldn't bother!

Anyway... the room I stopped in was room 202 which reminded me of a rather interesting IT problem I had to solve a number of years ago!

I was working with a client who had an elaborate system setup consisting of COBOL running on UNIX boxes and a nice .Net front end talking to it.. they were using a product which allowed the COBOL ISAM file system to be accessed using SQL via an ODBC connection.

COBOL had a nifty little invention called a Comp-3 field - COBOL dates back to that time where memory was precious and rare and expensive! a time where the collective memory on the planet was less than that currently available on your average smart phone (I have no idea if that it is true or not, but it sounds good and why let facts get in the way of a good anecdote? A bit like Birmingham having more canals than Venice.... that was completely made up! However when somebody actually did the sums it turned out to be true so perhaps my fact is also true?) I won't bore you with the details of the COMP-3 Field but basically they allowed numbers to be stored in a smaller format (They weren't stored in a display format such as  PIC 9999 would do but as the actual number which saved about half the storage space on disk) however would make viewing the files a pain!

COMP-3 fields could also produce the COBOL equivalent of a Null pointer exception! if you never initialised a COMP-3 field it would be stored on the disk as spaces.... or ASCII 32,32,32,32,32

The product being used to access the COBOL ISAM files (Transoft) would report these spaces back as 202 or 2020 or 202020 or 20202020?? Well Transoft converted ASCII 32 to HEX 20 (2 * 16 = 32) - Actually they already were - but most people know that the space is ASCII 32 (DEC) not as ASCII 20 (HEX) - not unless your a bit boring that is!

This potentially causes bit of an issue for the .Net system as un-initialised fields were being seen as containing 202, or 2020 or 20202 and so on and so on! so they devised a clever way of coping with this... hidden deep down in the ODBC data reader they told the system to convert any number starting 202 to be set to zero!

Strangely nobody saw the potential danger of this technique! no honestly they never! nobody! even when I pointed it out!!!! I only discovered it when a customer price update failed... why did it fail? because the ID of the item was 202... the system thought it should be zero and the update failed! how many other times had the 202 bug struck and not been spotted!

I must admit it took a while to fix... luckily the mapping files for Transoft allow for conditional logic and I was able to write an automated job to interrogate the COBOL FD's (File descriptions)  and produce a COMP-3 work-around! It also took a bit work on the .Net side but luckily that was localised to only a few locations in most of the code base.

Anyway... the trip to the Isle of Wight was very enjoyable if for nothing else giving me an excuse to talk about the 202 bug!

Christian Miles