Post reply

Cheap way to import EBCDIC files

  • July 27, 2003 at 5:46 pm

    #106270

    I have a situation where my company needs to import EBCDIC files to SQL. These files contain multiple packed decimal fields, which are unreadable in windows. I am aware that there are several editors and drivers on the market, but the cost is not something the company is willing to swallow.

    The files can be exported in a display format which works fine, but this requires significant development time from COBOL programmers who don't have any spare time. It also does not tackle the problem of historical files, which are archived in the format in question.

    So...

    Is there any way to read these files without spending any money?

    Any help will be most appreciated.

    Regards

    Simon

  • July 27, 2003 at 6:09 pm

    #467193

    May help a bit

    http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=502&lngWId=5

    Have a look at "EBCDIC2ASCII"

    Interesting "A2ROMAN" -> Converts an arabic numeral to roman, as a string.

  • July 28, 2003 at 12:48 am

    #467203

    Be aware that the "EBCDIC2ASCII" will convert EBCDIC text only. The numbers have to be converted otherwise.

    You need to have the recordlayout of your EBCDIC file to convert properly.

    The numbers may be stored in different formats, but the more common is the packed decimal. In this format every digit is stored in a halfbyte, most significant digit first in the byte string. You will need to know from the recordlayout where to put the decimal point. The last half byte is the sign of the number.

    It would be nice, if I could put a routine to do the conversion here, but unfortunately I do not know of such a function.

  • July 28, 2003 at 6:37 am

    #467256

    Simon,

    Your programmers are pulling your leg or are just plain lazy. I'm a mainframe COBOL programmer and have been for quite some time. All they need to do is read a record in and write the record back out changing numeric fields from COMP, COMP-3, etc. to "SIGN IS LEADING SEPARATE" with EXPLICIT decimal points instead of IMPLIED decimal points. Write the record to a new file/tape then use the MAINFRAME's FTP to send the file/tape to a PC Network FTP server (let FTP do the EBCDIC/ASCII translation for you - why reinvent the wheel?) Now you have a fixed-width text file ready for import into anything from MS Excel to MS Access. All done. Shouldn't take an experienced Mainframe programmer any more than 2 or 3 hours (depending on # of numeric fields in record) to write a COBOL program, set up the JCL and get it done. Unless they are a contract programmer getting paid over $200-$300/hr you've already spend more money/salary looking for a way get around them and probably haven't found a solution yet.

  • July 28, 2003 at 8:56 am

    #467297

    I agree with Davidf, this is something that is very easy to do in COBOL and shouldn't take much time. However, you need to understand that the COBOL programmers probably do not want to help you because you represent their obsolescence. You will have to find a way to work with them to gain their cooperation. Maybe show them how the file can be imported using DTS or involve them in some SQL Server projects.

    Or you can research how the numeric fields are stored in the IBM documentation:

    http://www-1.ibm.com/servers/s390/os390/bkserv/find_books.html

    "No man is an island, entire of itself; every man is a piece of the continent, a part of the main. If a clod be washed away by the sea, Europe is the less, as well as if a promontory were, as well as if a manor of thy friend's or of thine own were: any man's death diminishes me, because I am involved in mankind, and therefore never send to know for whom the bell tolls; it tolls for thee" -John Donne, referring to how SQL DBA's need the cooperation of mainframe programmers

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply