Yes, only text fields need to be translated just to be readable. And
only few files would need to be translated back to original format.
So, no CF/LF issues, no RECFM issues, no packed decimal issues, no
binary issues, etc.
Simple byte by byte conversion, which can be also reversed using
"reversed" table.
In fact, the first thing that came to my mind was DFSORT, because I did
some partial conversion of selected byte values.
The second was my tiny Turbo Pascal tool which I forgot and maybe lost.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 29.12.2020 o 20:51, Charles Mills pisze:
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
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat. Przypominamy, że każdy, kto rozpowszechnia (kopiuje,
rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może
podlegać karze.
mBank S.A. z siedzibą w Warszawie, ul. Prosta 18, 00-850 Warszawa,www.mBank.pl,
e-mail: [email protected]. Sąd Rejonowy dla m. st. Warszawy XII Wydział
Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, NIP: 526-021-50-88.
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi
169.401.468 złotych.
Jesteśmy administratorem twoich danych osobowych, które podałeś w związku z
prowadzoną z nami korespondencją. Przetwarzamy te dane dla celów, które
wynikają z przedmiotu korespondencji, w tym związanych z prowadzoną
działalnością bankową.
Więcej informacji o tym jak chroniony i przetwarzamy dane osobowe znajdziesz w
Pakietach RODO (w wersji polskiej i angielskiej), które są na www.mbank.pl/rodo
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Prosta 18, 00-850
Warszawa,www.mBank.pl, e-mail: [email protected]. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.401.468 as at 1 January 2020.
We are the controller of your personal data, which you provided in connection
with correspondence with us. We process your data for purposes resulting from
the subject of correspondence, including those related to the banking services.
More information on how we protect and process personal data can be found in
the GDPR Packages (in English and Polish), which are on www.mbank.pl/rodo.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
