Write a string in EBCDIC

[John Leslie]

I need to write a string to a file in EBCDIC.

Do I need to do it character by character using a translation table,
or is there a function to translate the whole string?

(I am aware that I can convert a whole file using Unix utilities, but
this file will have only a few header records in EBCDIC)

[SM Ryan]

jo********@madasafish.com (John Leslie) wrote:
# I need to write a string to a file in EBCDIC.
#
# Do I need to do it character by character using a translation table,
# or is there a function to translate the whole string?
#
# (I am aware that I can convert a whole file using Unix utilities, but
# this file will have only a few header records in EBCDIC)

http://www.room42.com/store/computer...ranslate.shtml

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Don't say anything. Especially you.

[CBFalconer]

John Leslie wrote:

I need to write a string to a file in EBCDIC.

Do I need to do it character by character using a translation
table, or is there a function to translate the whole string?

If the system native char set is EBCDIC, just write the string.
The whole problem is system specific, not language specific, and
thus is off-topic in c.l.c. It requires knowing both the source
and destination char sets and their coding. I would create a
translation function, and customize it for each specific system.

Try a group that deals with your specific system.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SM Ryan wrote:
| jo********@madasafish.com (John Leslie) wrote:
| # I need to write a string to a file in EBCDIC.
| #
| # Do I need to do it character by character using a translation table,
| # or is there a function to translate the whole string?
| #
| # (I am aware that I can convert a whole file using Unix utilities, but
| # this file will have only a few header records in EBCDIC)
|
| http://www.room42.com/store/computer...ranslate.shtml

I'd be cautious in using that example. For one thing, it doesn't indicate
/which/ EBCDIC it is translating ASCII to, and for another, it performs at
least 256 improper ASCII-to-EBCDIC conversions, if not more.

For what it's worth, there are about 30 different EBCDIC variants, each with
differences in the order and codepoint of common characters, and the
assignment of codepoints to disparate characters. You might want to take a
look at the various characterset mappings at http://anubis.dkuug.dk/i18n/charmaps/


- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAy8VLagVFX4UWr64RAhUTAJwKsjG10yqHt3ekExcB3M h8e0TdWgCgsxnz
c4MlgfDNzFr6oh/JVg3ju9I=
=+wfr
-----END PGP SIGNATURE-----

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew Pitcher wrote:
| SM Ryan wrote:
| | jo********@madasafish.com (John Leslie) wrote:
| | # I need to write a string to a file in EBCDIC.
| | #
| | # Do I need to do it character by character using a translation table,
| | # or is there a function to translate the whole string?
| | #
| | # (I am aware that I can convert a whole file using Unix utilities, but
| | # this file will have only a few header records in EBCDIC)
| |
| | http://www.room42.com/store/computer...ranslate.shtml
|
| I'd be cautious in using that example. For one thing, it doesn't indicate
| /which/ EBCDIC it is translating ASCII to, and for another, it performs at
| least 256 improper ASCII-to-EBCDIC conversions, if not more.

Correction - I meant "at least 128 improper ASCII-to-EBCDIC conversions"
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAy8XnagVFX4UWr64RAvlCAJ4tuCL5Rb8GWKYZ6SmZgh 1MQ2NsoACfYhcz
hySLhMx4qKqqi+JjKfSeFnE=
=8/jR
-----END PGP SIGNATURE-----

[nospam]

CBFalconer <cb********@yahoo.com> wrote:

John Leslie wrote:

I need to write a string to a file in EBCDIC.

Do I need to do it character by character using a translation
table, or is there a function to translate the whole string?

If the system native char set is EBCDIC, just write the string.
The whole problem is system specific, not language specific, and
thus is off-topic in c.l.c. It requires knowing both the source
and destination char sets and their coding. I would create a
translation function, and customize it for each specific system.

Try a group that deals with your specific system.

Is it really off-topic? I'm not so sure. The problem can be solved
in a 100% portable way that is not system-specific at all:

void setup_xlate_table(void)
{
...

xlate['a'] = /* EBCDIC value for 'a' */;
xlate['b'] = /* EBCDIC value for 'b' */;
xlate['c'] = /* EBCDIC value for 'c' */;

...
}

Write a translate function and voila, you have a portable
native-charset-to-EBCDIC-charset conversion solution.

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

no****@nowhere.com wrote:

CBFalconer <cb********@yahoo.com> wrote:

John Leslie wrote:

I need to write a string to a file in EBCDIC.

Do I need to do it character by character using a translation
table, or is there a function to translate the whole string?

If the system native char set is EBCDIC, just write the string.
The whole problem is system specific, not language specific, and
thus is off-topic in c.l.c. It requires knowing both the source
and destination char sets and their coding. I would create a
translation function, and customize it for each specific system.

Try a group that deals with your specific system.

Is it really off-topic? I'm not so sure. The problem can be solved
in a 100% portable way that is not system-specific at all:

void setup_xlate_table(void)
{
...

xlate['a'] = /* EBCDIC value for 'a' */;
xlate['b'] = /* EBCDIC value for 'b' */;
xlate['c'] = /* EBCDIC value for 'c' */;

...
}

Write a translate function and voila, you have a portable
native-charset-to-EBCDIC-charset conversion solution.

1) /which/ EBCDIC?

2) How do you handle characters that exist in ASCII, but not in the target
EBCDIC? For instance, how do you translate 0x5d (ASCII ']') to EBCDIC-US?

3) How do you handle char values that are not ASCII to begin with? For
instance, how do you translate 0x9A (not an ASCII character) to EBCDIC-US?
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAy9ZPagVFX4UWr64RAlp+AJ459ha4S4Gyi46PK9ZOeR sDsWdNgwCfUHN4
3joRaeW+GWPREx/MQDjVBkM=
=ImUU
-----END PGP SIGNATURE-----

[Ralmin]

"Lew Pitcher" <lp******@sympatico.ca> wrote:

no****@nowhere.com wrote:

Is it really off-topic? I'm not so sure. The problem can be solved
in a 100% portable way that is not system-specific at all:

void setup_xlate_table(void)
{
...

xlate['a'] = /* EBCDIC value for 'a' */;
xlate['b'] = /* EBCDIC value for 'b' */;
xlate['c'] = /* EBCDIC value for 'c' */;

...
}

Write a translate function and voila, you have a portable
native-charset-to-EBCDIC-charset conversion solution.
1) /which/ EBCDIC?

Write a separate setup_xlate_table function for each EBCDIC you are
interested in.
2) How do you handle characters that exist in ASCII, but not
in the target EBCDIC? For instance, how do you translate
0x5d (ASCII ']') to EBCDIC-US?

3) How do you handle char values that are not ASCII to begin
with? For instance, how do you translate 0x9A (not an ASCII
character) to EBCDIC-US?

Simple answer: Replace it with a question mark, issue a warning.

Complex answer: Do whatever's appropriate for the particular type of file
you're translating.

--
Simon.

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralmin wrote:

"Lew Pitcher" <lp******@sympatico.ca> wrote:

no****@nowhere.com wrote:

Is it really off-topic? I'm not so sure. The problem can be solved
in a 100% portable way that is not system-specific at all:

void setup_xlate_table(void)
{
...

xlate['a'] = /* EBCDIC value for 'a' */;
xlate['b'] = /* EBCDIC value for 'b' */;
xlate['c'] = /* EBCDIC value for 'c' */;

...
}

Write a translate function and voila, you have a portable
native-charset-to-EBCDIC-charset conversion solution.
1) /which/ EBCDIC?

Write a separate setup_xlate_table function for each EBCDIC you are
interested in.

OK, so about thirty setup_xlate_table functions, and the /caller/ has to know
which EBCDIC to select. That means that the caller needs to incorporate the
infrastructure to determine which target EBCDIC is the one to use, and his
logic needs to encorporate some sort of user input query (cmdline options or
envvar checking or user-interactive options). From /my/ experience (and I've
had a lot of experience), it's not easy.

2) How do you handle characters that exist in ASCII, but not
in the target EBCDIC? For instance, how do you translate
0x5d (ASCII ']') to EBCDIC-US?

3) How do you handle char values that are not ASCII to begin
with? For instance, how do you translate 0x9A (not an ASCII
character) to EBCDIC-US?

Simple answer: Replace it with a question mark, issue a warning.

Bzzt. Wrong answer. Or, at least wrong replacement value. Tell me what the
correct replacement value should be. Also, issue a warning how, and to whom?

Speaking from experience, substitution is the 'correct' way to go, but also
the wrong way to go. Assume that the data the OP wants to translate looks like

#include <stdio.h>
int main(void)
{
char text[] = "2^3 = 8\n";
printf("%s",text);
return 0;
}

Will single character substitution result in an EBCDIC file that preserves the
meaning of the translated ASCII data? I can answer simply: no, it will not.
Square brackets do not exist in some EBCDIC variants, and exist with different
codepoints (varying in value from EBCDIC variant to variant) in others. The
caret symbol doesn't exist in most EBCDIC variants, and is typically
translated to the PL/1 'logical not' sign ( which sort of looks like: '-|' ).
Substituting '?' (or even the proper SUB character) for the untranslatable
characters would invalidate the meaning of the data being transferred. In this
case, with your suggested substitution, the data becomes

#include <stdio.h>
int main(void)
{
char text?? = "2?3 = 8\n";
printf("%s",text);
return 0;
}

Which results in a textual file that is /not/ equivalent to the original text
file.

Complex answer: Do whatever's appropriate for the particular type of file
you're translating.

Closer, but that's the whole point of this exercise. The OP wants to
"translate ASCII to EBCDIC"; that's the "particular type of file" he's
translating. What is appropriate for that?
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAzJLxagVFX4UWr64RAmsbAJ9d75Xv3Nsuepz8/FSgp0ITt5K3ygCgxCuD
etMA7J9MHahzBZ5RySpiajo=
=lBrZ
-----END PGP SIGNATURE-----

[CBFalconer]

Lew Pitcher wrote:

Ralmin wrote:
.... snip ...
Which results in a textual file that is /not/ equivalent to the
original text file.

Complex answer: Do whatever's appropriate for the particular
type of file you're translating.

Closer, but that's the whole point of this exercise. The OP
wants to "translate ASCII to EBCDIC"; that's the "particular
type of file" he's translating. What is appropriate for that?

Seems to me that one rule that the tables should observe is
uniqueness. I.e. whether or not the translation makes sense, the
result should be translatable back into the original without
loss. In a way this is what happens when you pack a text file
into a zip file. The algorithm is lossless.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[nospam]

Lew Pitcher <lp******@sympatico.ca> wrote:

<snip>

Closer, but that's the whole point of this exercise. The OP wants to
"translate ASCII to EBCDIC"; that's the "particular type of file" he's
translating. What is appropriate for that?

Maybe you should allow the OP to chime in with more details rather than
you inventing scenarios in order to poo-poo on everyone else's help.

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CBFalconer wrote:

Lew Pitcher wrote:

Ralmin wrote:

... snip ...

Which results in a textual file that is /not/ equivalent to the
original text file.

Complex answer: Do whatever's appropriate for the particular
type of file you're translating.

Closer, but that's the whole point of this exercise. The OP
wants to "translate ASCII to EBCDIC"; that's the "particular
type of file" he's translating. What is appropriate for that?

Seems to me that one rule that the tables should observe is
uniqueness. I.e. whether or not the translation makes sense, the
result should be translatable back into the original without
loss. In a way this is what happens when you pack a text file
into a zip file. The algorithm is lossless.

I've lived with this problem for about 6 years now, and have heard (and made)
a lot of different arguments about what should happen. This is one reason I've
not posted code to solve the OP's problem; there is no single piece of code
that can solve an ASCII-to-EBCDIC conversion correctly.

The two charactersets are sufficiently different that a 'correct' symmetric
translation is not possible. Yes, you can build an artificial symmetric
conversion, but it won't translate correctly, wrt the official definitions of
ASCII and EBCDIC. One side or the other will see values that are illegal in
it's interpretation, and (depending on how relaxed your criteria are) it can
be impossible to perform a symmetric translation. (ASCII only recognizes 128
characters out of the 256 expressable in an 8bit byte, OTOH, even the most
restricted EBCDIC recognizes about 200 characters. That means that there are
only about 56 8bit values on the EBCDIC side to be mapped to over 128 8bit
unassigned values on the ASCII side. It's not easy to get a 1-to-1 symmetrical
mapping under those conditions)

Additionally, depending on how strict the EBCDIC side is in processing the
translated data, illegal byte values pretending to be EBCDIC codepoints can
cause many problems with the host application that has to process the data.
Say our hypothetical ASCII-to-EBCDIC translation translates the ASCII '['
character to x'B0'. One host program that expects EBCDIC-US could reject the
datum out of hand because it doesn't fall within the range of codepoints
allowed in EBCDIC-US, while another host program (expecting a different
variant of EBCDIC) reads the codepoint as a "superscript 0". Not a pretty
sight when processing depends on the value presented.

To the OP: No, there is no 'standard' ASCII-to-EBCDIC translation in ISO C.
There is no 'standard' ASCII-to-EBCDIC anywhere, mostly because there is no
single thing known as EBCDIC. What you are looking for, by necessity, is
something that you will have to craft for yourself. To do it properly, you
will need to know
a) which variant of EBCDIC you are translating to,
b) what you are supposed to do with ASCII codepoints that have no equivalent
EBCDIC codepoint (the 'standard' says to use the EBCDIC 'SUB' character)
c) what you are supposed to do with source data that is not ASCII (i.e. values
< 0x00 and values > 0x7f)

The characterset tables at http://anubis.dkuug.dk/i18n/charmaps/ can help you
here. Each table shows the codepoint for the target characterset, it's
character, and the codepoint for the same character in Unicode. Remember, only
the first 128 Unicode characters are usefull here; all Unicode characters
below 0x0080 map 1-to-1 to ASCII, while the rest (Unicode above 0x007f) have
no ASCII equivalent. There are 46 EBCDIC variants listed (although, some are
duplicate mappings); select the variant that your host people expect you to
use (probably EBCDIC-US at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-US ,
EBCDIC-INT at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-INT , or
EBCDIC-CP-US at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-CP-US ) and code
up a simple translation table using the ASCII character as an index into the
table of EBCDIC codepoints.

Be prepared to determine what to do with out-of-bounds conditions (return an
error, or perhaps translate to the EBCDIC "SUBstitute" value) and characters
that have no EBCDIC equivalent (translate to the EBCDIC "SUBstitute" value).
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAzQAtagVFX4UWr64RAuDXAJsFR7tm7Fqz2Ncq2aROiv u/vTGZdgCgqEN2
t//g1Zc+eVl49iYoSYLX6bU=
=kOsX
-----END PGP SIGNATURE-----

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lew Pitcher wrote:
[snip]

To the OP: No, there is no 'standard' ASCII-to-EBCDIC translation in ISO C.
There is no 'standard' ASCII-to-EBCDIC anywhere, mostly because there is no
single thing known as EBCDIC. What you are looking for, by necessity, is
something that you will have to craft for yourself. To do it properly, you
will need to know
a) which variant of EBCDIC you are translating to,
b) what you are supposed to do with ASCII codepoints that have no equivalent
EBCDIC codepoint (the 'standard' says to use the EBCDIC 'SUB' character)
c) what you are supposed to do with source data that is not ASCII (i.e. values
< 0x00 and values > 0x7f)

The characterset tables at http://anubis.dkuug.dk/i18n/charmaps/ can help you
here. Each table shows the codepoint for the target characterset, it's
character, and the codepoint for the same character in Unicode. Remember, only
the first 128 Unicode characters are usefull here; all Unicode characters
below 0x0080 map 1-to-1 to ASCII, while the rest (Unicode above 0x007f) have
no ASCII equivalent. There are 46 EBCDIC variants listed (although, some are
duplicate mappings); select the variant that your host people expect you to
use (probably EBCDIC-US at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-US ,
EBCDIC-INT at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-INT , or
EBCDIC-CP-US at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-CP-US ) and code
up a simple translation table using the ASCII character as an index into the
table of EBCDIC codepoints.

Be prepared to determine what to do with out-of-bounds conditions (return an
error, or perhaps translate to the EBCDIC "SUBstitute" value) and characters
that have no EBCDIC equivalent (translate to the EBCDIC "SUBstitute" value).

Here's one example of an ASCII-to-EBCDIC characterset translation, based on
the EBCDIC-US table at http://anubis.dkuug.dk/i18n/charmaps/EBCDIC-US

char ASCII_to_EBCDIC_US(char ascii)
{
char to_EBCDIC_US[128] =
{ 0x00, 0x01, 0x02, 0x03, 0x37, 0x2d, 0x2e, 0x2f,
0x16, 0x05, 0x25, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
0x10, 0x11, 0x12, 0x13, 0x3c, 0x3d, 0x32, 0x26,
0x18, 0x19, 0x3f, 0x27, 0x1c, 0x1d, 0x1e, 0x1f,
0x40, 0x5a, 0x7f, 0x7b, 0x5b, 0x6c, 0x50, 0x7d,
0x4d, 0x5d, 0x5c, 0x4e, 0x6b, 0x60, 0x4b, 0x61,
0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
0xf8, 0xf9, 0x7a, 0x5e, 0x4c, 0x7e, 0x6e, 0x6f,
0x7c, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7,
0xc8, 0xc9, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6,
0xd7, 0xd8, 0xd9, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6,
0xe7, 0xe8, 0xe9, 0x3f, 0xe0, 0x3f, 0x3f, 0x6d,
0x79, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
0x88, 0x89, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96,
0x97, 0x98, 0x99, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6,
0xa7, 0xa8, 0xa9, 0xc0, 0x4f, 0xd0, 0xa1, 0x07
}

if (ascii > 127 || ascii < 0) return 0x3f;
return to_EBCDIC_US[ascii];
}
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAzTC3agVFX4UWr64RAsC0AKD0WLueR3RPRzDpaDawem KmZU8LswCdHYUO
UfMDzisQVbs+tku1M5sRtwI=
=Yria
-----END PGP SIGNATURE-----