> If the input file contains not only text, but also binary and maybe decimal > packed fields, you need an external description of the record format,
I think he has "round trip" translation in mind. Non-printable fields end up as hash in the ASCII file, but get restored properly on re-translation to EBCDI"C. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Tuesday, December 29, 2020 11:36 AM To: [email protected] Subject: Re: EBCDIC-ASCII converter and other tools If the input file contains not only text, but also binary and maybe decimal packed fields, you need an external description of the record format, which can be interpreted by the conversion program (if the program should be able to work with all file formats and not be specific for a certain format). Characters - must be decoded (EBCDIC to ASCII) Binaries - must be converted (big endian - little endian, to be useful on Windows etc.) or converted to readable format (character) Decimal - does not exist on Windows, that is, it must be converted to character (readable format); if you do this, the field offsets will change. This means, that you need two descriptions (original and edited form) Hopefully the record lengths and offsets are fixed; no variable length fields ... I once wrote such a program for a customer of mine, in C, and I believe there was a open source tool, which I used as first start. But I didn't search it myself; my customer gave it to me. But it didn't do the job; I had to invest some hours (or days). It was written in ANSI C. OTOH: if the program only must handle one certain record format, a very simple Pascal program with a fixed record layout would do. Kind regards Bernd Am 29.12.2020 um 20:01 schrieb R.S.: > The input file contain some text and some other fields. CR/LF, > RECFM=FB/VB and other "end of line" issues are not relevant. > The idea is to convert it to readable format, analyze content and > maybe modify very few words or characters. Modified file should be > converted back to original format. Obviously conversion forward and > backward should give file equal to the source file. > Modification can be understood like replacement "Radek" to "Gil.." or > "AAAA" to "BBBB". No change of length, just byte to byte replacement. > ISPF browse/edit with proper codepage is not an option due to some > reasons I don't want to describe, technically irrelevant. > FTP translation is also not an option. And I would like to avoid Rube > Goldberg process like ftp put with no translation and then get with > custom translation. However this method can be run in batch and it is > feasible even for large files. > No, I'm not writing any tool - I want to avoid it and simply save > people's time spent on the process. > Maybe I'm naive, but I believed such tools simply exist and are > available for download - like many, many other small and useful > utilities. > > Regards ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
