ftp: ASCII to EBCDIC conversion
Darius Cooper
newsgroup and figured the experts would be in this group:
I want to transfer files from the PC to the mainframe using ftp.
The transfer involves an ASCII to EBCDIC conversion.
Most of the characters are translated correctly, but a few are not.
Some characters that are not being translated correctly are: the caret sign,
the square brackets, the thin vertical line (as distinct from the thick
vertical "pipe" symbol).
I repeated the ftp from AIX to the mainframe, using "type ascii" and "Type
ebcdic", but the result was the same.
I was wondering if there was any way to specify a translation table and then
point ftp to that table.
TIA,
- Darius Cooper
Alun Jones
> I want to transfer files from the PC to the mainframe using ftp.
> The transfer involves an ASCII to EBCDIC conversion.
> Most of the characters are translated correctly, but a few are not.
> Some characters that are not being translated correctly are: the caret sign,
> the square brackets, the thin vertical line (as distinct from the thick
> vertical "pipe" symbol).
Are you sure that those characters exist in EBCDIC? If they do, then
obviously there's a bug to report in the program performing the translation
(probably the FTP server on the mainframe). There's no general way to
specify a translation table for all FTP servers, so this is something you'll
want to address with the mainframe FTP server manufacturer.
Alun.
~~~~
---
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613 | us at al...@texis.com. VISA / MC accepted.
Fax +1 (512) 378 3246 | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*******-- Alpha processors now supported under Windows NT --*******
Jim Keohane
IBM's MVS FTP client and server make provisions for dynamically
specifying alternate translation tables. A remote client can tell
MVS server to use different translation table via SITE TRANSLATE
command, I think. MVS FTP client accepts option TRANS after left
parenthesis on cammandline or in PARM field. - Jim Keohane
John Pashley
>
> I realize this is not a strictly tcp/ip question, but I couldn't find a ftp
> newsgroup and figured the experts would be in this group:
>
> The transfer involves an ASCII to EBCDIC conversion.
> Most of the characters are translated correctly, but a few are not.
> Some characters that are not being translated correctly are: the caret sign,
> the square brackets, the thin vertical line (as distinct from the thick
> vertical "pipe" symbol).
>
> ebcdic", but the result was the same.
>
> I was wondering if there was any way to specify a translation table and then
> point ftp to that table.
>
> TIA,
>
> - Darius Cooper
Assuming you are on MVS TCPIP 3.2:-
Look in TCPIP.SEZTCPX (or whatever high level node your installation
uses. We use SYS1.TCPIP).
Create a new member 'DARIUS' (or whatever), copy the closest one
(probably 'US') and fix it up. As far as I can tell, the translations
you need are:
symbol EBCDIC ASCII
caret x'B0' x'5E'
left square bracket x'BA' x'5B'
right square bracket x'BB' x'5D'
vertical line x'6A' x'7C'
(I'm not sure if the last one is the one you are referring to, but its
the only one I could find in both EBCDIC and ASCII.)
Create a sequential dataset TCPIP.DARIUS.TCPXLBIN with the same
attributes as TCPIP.STANDARD.TCPXLBIN (RECFM=F,BLKSIZE=256,LRECL=256)
In TSO, execute the following command
CONVXLAT 'TCPIP.SEZATCPX(DARIUS)' 'TCPIP.DARIUS.TCPXLBIN'
Add a DD card to the FTP started task JCL
//DARIUS DD DSN=TCPIP.DARIUS.TCPXLBIN,DISP=SHR
Before FTPing, use the command
SITE XLATE=DARIUS
If everyone else using FTP on that MVS needs the changes anyway, just
CONVXLAT the table into TCPIP.STANDARD.TCPXLBIN. That way you won't need
the new dataset or the XLATE command.
John Pashley
Global Financial Products Division, EDS
john.p...@eds.com
Peter Schaeffer
10/08/98 12:25 PM
A few answers. The caret is x'b0' in EBCDIC. The square brackers are x'ba'
and x'bb'. The standard vertical bar is x'4f'. The split vertical bar is
x'6a'. The IBM FTP server support changing the ASCII <-> EBCDIC translation
tables.
Peter Schaeffer
NEON Systems, Inc.
281-491-4200
www.neonsys.com
Alun Jones <al...@TEXIS.COM> on 10/08/98 08:34:27 AM
Please respond to "IBM TCP/IP List" <IBMT...@VM.MARIST.EDU>
To: IBMT...@VM.MARIST.EDU
cc: (bcc: Peter Schaeffer/Dev/Neon)
Subject: Re: ftp: ASCII to EBCDIC conversion
In article <6vfg34$5m5$1...@news.megsinet.net>, "Darius Cooper"
<Darius...@Bigfoot.com> wrote:
> I want to transfer files from the PC to the mainframe using ftp.
> The transfer involves an ASCII to EBCDIC conversion.
> Most of the characters are translated correctly, but a few are not.
> Some characters that are not being translated correctly are: the caret
sign,
> the square brackets, the thin vertical line (as distinct from the thick
> vertical "pipe" symbol).
Are you sure that those characters exist in EBCDIC? If they do, then
obviously there's a bug to report in the program performing the translation
(probably the FTP server on the mainframe). There's no general way to
Peter Schaeffer
10/08/98 12:50 PM
Rich Greenberg is correct in stating that the "ascii caret (usually
shift+6) is usually converted to the ebcdic not
sign (x'5F' usually shift+6)". However, EBCDIC does have a caret (x'b0').
On my PC (using Attachmate EXTRA!) it even comes out correctly.
Siberian Huskies are great dogs. A bit hot for them down here in Houston.
Peter Schaeffer
NEON Systems, Inc.
281-491-4200
www.neonsys.com
Rich Greenberg <ric...@NETCOM.COM> on 10/08/98 01:26:31 PM
Please respond to ric...@netcom.com
To: IBMT...@VM.MARIST.EDU
cc: (bcc: Peter Schaeffer/Dev/Neon)
Subject: Re: ftp: ASCII to EBCDIC conversion
On Oct 8, 1:34pm, Alun Jones wrote:
} In article <6vfg34$5m5$1...@news.megsinet.net>, "Darius Cooper"
} <Darius...@Bigfoot.com> wrote:
} > Some characters that are not being translated correctly are: the caret
sign,
} > the square brackets, the thin vertical line (as distinct from the thick
} > vertical "pipe" symbol).
}
} Are you sure that those characters exist in EBCDIC? If they do, then
The ascii caret (usually shift+6) is usually converted to the ebcdic not
sign (x'5F' usually shift+6).
Ebcdic has 2 vertical bars, a solid one (use for "pipe" in CMS/TSO
pipelines) x'4F' and a broken one x'6A'.
Ebcdic has the square brackets at x'BA' & x'BB' (code page 037). Code
page 1047 has the right sq bkt at x'6D', but I don't see the left one
under cp 1047.
--
Rich Greenberg Work: PM0RMG atsign WSPVM1.worldspan.com +1
770-563-6656
N6LRT Marietta, GA, USA Play: richgr atsign netcom.com +1
770-321-6507
Eastern time. I speak for myself & my dogs only. VM'er since
CP-67
Canines:Val(Chinook,CGC,TT),Red(Husky,(RIP)),Shasta(Husky,TT)
Owner:Chinook-L
Atlanta Siberian Husky Rescue. Adopt a homeless Husky.
Jeffrey Altman
: newsgroup and figured the experts would be in this group:
: I want to transfer files from the PC to the mainframe using ftp.
: The transfer involves an ASCII to EBCDIC conversion.
: Most of the characters are translated correctly, but a few are not.
: the square brackets, the thin vertical line (as distinct from the thick
: vertical "pipe" symbol).
: I repeated the ftp from AIX to the mainframe, using "type ascii" and "Type
: ebcdic", but the result was the same.
:
: point ftp to that table.
:
: TIA,
:
: - Darius Cooper
:
:
Use Kermit. See http://www.kermit-project.org/
Kermit is designed to perform character set translation during the
file transfer and is available both on PCs and the mainframe operating
systems.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-...@kermit-project.org
Metz, Seymour
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Alun Jones [SMTP:al...@TEXIS.COM]
> Sent: Thursday, October 08, 1998 9:34 AM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: ftp: ASCII to EBCDIC conversion
>
> In article <6vfg34$5m5$1...@news.megsinet.net>, "Darius Cooper"
> <Darius...@Bigfoot.com> wrote:
> > I want to transfer files from the PC to the mainframe using ftp.
> > The transfer involves an ASCII to EBCDIC conversion.
> > Most of the characters are translated correctly, but a few are not.
> > Some characters that are not being translated correctly are: the caret
> sign,
> > the square brackets, the thin vertical line (as distinct from the thick
> > vertical "pipe" symbol).
>
> Are you sure that those characters exist in EBCDIC? If they do, then
André Pirard
But, generally speaking, how could an external client know what tables
a site has implemented, which one to use, or even that you're using EBCDIC.
That mainframe is supposed to send you ASCII or ISO 8859-1 without the need
to peek your nose into it, isn't it.
And SHARE has recommended general usage of CECP 1047 so that, in addition to
IBM mainframes being able to send data to each other in EBCDIC directly,
one site use one and that EBCDIC code and that an end be put to a story
similar to each US State having its own different version of ASCII.
The definite CECP-ISO translation, and hence character defintion, is on:
ftp://ftp/pub/docs/iso8859/iso8859.networking.txt
André.
André PIRARD ULgNet Coordinator, Adm. & Support
SEGI - Université de Liège IP: 139.165.0.0 - ulg.ac.be
B26 - Sart Tilman www.ulg.ac.be
B-4000 Liège 1 (Belgium)
mailto:A.Pi...@ulg.ac.be +32-4-3664932 Fax: 2920
Alan Altmark
>a site has implemented, which one to use, or even that you're using EBCDIC.
>That mainframe is supposed to send you ASCII or ISO 8859-1 without the need
>to peek your nose into it, isn't it.
>And SHARE has recommended general usage of CECP 1047 so that, in addition to
>IBM mainframes being able to send data to each other in EBCDIC directly,
>one site use one and that EBCDIC code and that an end be put to a story
>similar to each US State having its own different version of ASCII.
>The definite CECP-ISO translation, and hence character defintion, is on:
>ftp://ftp/pub/docs/iso8859/iso8859.networking.txt
André, you are correct that the client must know the translation table
names that have been installed. For mainframes, hopefully there will
be one that translates the workstation codepage to/from the user's
selected 3270 emulation codepage.
In the VM TCP/IP support for the euro to be made available later this year,
the new translation tables (more than 190 new tables) will be of the form
xxxxyyyy where xxxx and yyyy are codepage numbers. The VM FTP server will
also have support for SITE TRANSLATE. Tables are included to allow conversion
from all standard CECPs to/from ISO 8859-1 or ISO 8859-15, as well as
POSIX codepage 1047 and Windows codepage 1252.
Alan Altmark
IBM, VM Development
Jim Keohane
If the default or common or usual EBCDIC<->ASCII translation is
not to be used who else can make the choice other than the client
which is initiating the transfer? You can have server allow for additional
tables and the client can make its choice. The transaltion table, default
or otherwise, is only used needed (i.e. data sent as ASCII). - Jim Keohane
-----Original Message-----
From: André Pirard <pir...@VM1.ULG.AC.BE>
Newsgroups: bit.listserv.ibmtcp-l
To: IBMT...@VM.MARIST.EDU <IBMT...@VM.MARIST.EDU>
Date: Monday, October 12, 1998 7:51 AM
Subject: Re: ftp: ASCII to EBCDIC conversion
At 11:34 8/10/98 +0000, Jim Keohane wrote:
>Darius,
> IBM's MVS FTP client and server make provisions for dynamically
>specifying alternate translation tables. A remote client can tell
>MVS server to use different translation table via SITE TRANSLATE
>command, I think. MVS FTP client accepts option TRANS after left
>parenthesis on cammandline or in PARM field. - Jim Keohane
But, generally speaking, how could an external client know what tables
a site has implemented, which one to use, or even that you're using EBCDIC.
That mainframe is supposed to send you ASCII or ISO 8859-1 without the need
to peek your nose into it, isn't it.
And SHARE has recommended general usage of CECP 1047 so that, in addition to
IBM mainframes being able to send data to each other in EBCDIC directly,
one site use one and that EBCDIC code and that an end be put to a story
similar to each US State having its own different version of ASCII.
The definite CECP-ISO translation, and hence character defintion, is on:
ftp://ftp/pub/docs/iso8859/iso8859.networking.txt
André.
Keith Owens
=?iso-8859-1?Q?Andr=E9?= Pirard <pir...@VM1.ULG.AC.BE> wrote:
>The definite CECP-ISO translation, and hence character defintion, is on:
>ftp://ftp/pub/docs/iso8859/iso8859.networking.txt
That URL is invalid, //ftp/ is not a valid site name. Do you have a
mroe accurate URL?
André Pirard
Oops. That happens to namedroppers :-) Sorry.
ftp://ftp.ulg.ac.be/pub/docs/iso8859/iso8859.networking.txt
Other files in the same directory.
André Pirard
>Andre,
> If the default or common or usual EBCDIC<->ASCII translation is
>not to be used who else can make the choice other than the client
>which is initiating the transfer? You can have server allow for additional
>tables and the client can make its choice. The transaltion table, default
>or otherwise, is only used needed (i.e. data sent as ASCII). - Jim Keohane
At 09:27 12/10/98 -0400, Alan Altmark wrote:
>Andr‚, you are correct that the client must know the translation table
>names that have been installed. For mainframes, hopefully there will
>be one that translates the workstation codepage to/from the user's
>selected 3270 emulation codepage.
>
>In the VM TCP/IP support for the euro to be made available later this year,
>the new translation tables (more than 190 new tables) will be of the form
>xxxxyyyy where xxxx and yyyy are codepage numbers. The VM FTP server will
>also have support for SITE TRANSLATE. Tables are included to allow
conversion
>from all standard CECPs to/from ISO 8859-1 or ISO 8859-15, as well as
>POSIX codepage 1047 and Windows codepage 1252.
>
>Alan Altmark
>IBM, VM Development
My point is that more than one translation should be avoided.
On the EBCDIC side, that's using a single Latin-1 codepage, 1047 as per
SHARE requirement, being translated to only ISO 8859-1 on communication lines.
If the other side doesn't use ISO 8859-1, it's their problem, and THEY must
translate ISO 8859-1 to their internal code.
Indeed, as a practical example, you cannot expect all ftp clients to know
about and implement a VM TCP/IP SITE TRANSLATE command to do such things as
translating from CECP 500 to some special Macintosh code. It's not where a
Macintosh -- or whatever -- translation should happen. On the other hand, a
Macintosh software will be fully aware of its system-specific translations.
This said, I agree that VM translation can be very useful to solve
problems, but in a limited, site internal and ad hoc fashion.
Now, you can see that this discussion is limited to Latin-1, and that even
with Latin-1 and its lack of oe character and introduction of Euro currency
symbol etc, the key principle of using ISO 8859-1 exclusively on
communication lines can be questioned.
The only definite way out is to use ISO 10646 aka UNICODE in communication.
This would, for a start, allow to transmit such characters as oe that do
exist in 8-bit codes on Mac and Windows in a legal manner, whatever the
internal notion of such characters is in any particular system.
Maybe our children or grand children will enjoy 10646 communication one day.
In the meantime, my name is André and not Andr‚, which is CECP 850 ;-)
Jim Keohane
It is very easy to have EBCDIC-ASCII transaltion done at client end.
Just send data as EBCDIC and ensure client supports it. Then client
does all needed transaltion, not MVS/VM.
However, many ftp client implelementations do not support EBCDIC.
In that case what do you suggest other than MVS/VM giving user some
recourse? - Jim Keohane
David Alcock
character codes":
ftp://aix1.segi.ulg.ac.be/pub/docs/iso8859/iso8859.networking
I consider it to be the best guide for EBCDIC and ASCII translations
issues.
Andri Pirard
>Andre,
> It is very easy to have EBCDIC-ASCII transaltion done at client end.
>Just send data as EBCDIC and ensure client supports it. Then client
>does all needed transaltion, not MVS/VM.
> However, many ftp client implelementations do not support EBCDIC.
>In that case what do you suggest other than MVS/VM giving user some
>recourse? - Jim Keohane
I didn't mean that only one side must translate, quite the opposite, but
that (at least a given) VM/CMS should be limited to a single translation table
- by using a single EBCDIC code page, because you cannot expect the other
party to know about EBCDIC variations, even about EBCDIC at all, as you say,
- by not dealing with code variations in the peer for exactly the same reason.
The best way to put it, as I do in my document, is that every text octet on
a communication line must be encoded with ISO 8859-1 and that each side
deal with its own business of not using the interchange code and translate
this interchange code to its own.
To the extent that both parties impliciltly agree to be Latin-1.
If the only possible implicit agreement is to be both on earth, then a
so-called "universal" (?) encoding must be used. This is even true in order
to stop the everlasting discussions about what character is missing in
Latin-1 and which should be removed to make room in an 8-bit encoding. With
a wider encoding, if some thing as an Euro currency symbol is missing, you
just add it. If a new character is sent to some system, be it 8-bit or not,
it will simply be not recognized until that system supports it. It will not
be mistaken with the other symbol it would have replaced in an 8-bit encoding.
André.
>André Pirard wrote:
>> ...
>> My point is that more than one translation should be avoided.
>> On the EBCDIC side, that's using a single Latin-1 codepage, 1047 as per
>> SHARE requirement, being translated to only ISO 8859-1 on communication
lines.
>> If the other side doesn't use ISO 8859-1, it's their problem, and THEY must
>> translate ISO 8859-1 to their internal code.
>>...
Jim Keohane
MQSeries does something like you suggest with both ends of a message
transfer specifying CCSID (sp?). However, MQ does allow that to be
overridden because it cannot be guaranteed all data on a given host
fits a particular code page. I guess FTP allows for same flexibility.
I would assume that a host would use a default translation table for
the expected host ccsid and ascii client ccsid. - Jim Keohane
Metz, Seymour
being language chauvinists, so I am more than a little nonplussed to find
myself forced to accuse someone in another country of that failing. Since
you are posting from Belgium, I would expect you to be aware of the need to
support multiple languages, and you are not located that far from countries
for which 8859-1 is virtually useless. 8859-4 is bad enough, but mapping
between 8859-6 or 8859-8 and 8859-1 is hopeless. Until we are all using
10646, the ability for the client to select the translation is absolutely
mandatory.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: André Pirard [SMTP:pir...@VM1.ULG.AC.BE]
> Sent: Tuesday, October 13, 1998 6:50 AM
> To: IBMT...@VM.MARIST.EDU
> Subject: Re: ftp: ASCII to EBCDIC conversion
>
> My point is that more than one translation should be avoided.
> On the EBCDIC side, that's using a single Latin-1 codepage, 1047 as per
> SHARE requirement, being translated to only ISO 8859-1 on communication
> lines.
> If the other side doesn't use ISO 8859-1, it's their problem, and THEY
> must
> translate ISO 8859-1 to their internal code.
Sakthivel
>At 14:37 19/10/98 -0400, you wrote:
>>I certainly agree that the sooner we get away from 7 and 8 bit codes, the
>>better, but as long as we are stuck with 8 bit codes user control is
>>essential. If a shop has to support data from multiple countries, it is
>>likely to be using multiple code pages on the same system, and there is no
>>way for the software to determine what translation is appropriate. When one
>>file is in Flemish and one is in Hebrew, there is no "one size fits all"
>>translation table. Even within Europe, what translation do you use that will
>>fit, e.g., both Flemish and Icelandic?
>>
>>Shmuel (Seymour J.) Metz
>
>If an EBCDIC host had to support 8859-x and 8859-y as interchange character
>sets I would certainly consider fitting it with two TCP/IP addresses and
>sets of servers (using one corresponding translation table to EBCDIC each)
>and tell the users to go to different hostnames according to the language.
>
>André.
>
>
>
>André PIRARD ULgNet Coordinator, Adm. & Support
>SEGI - Université de Liège IP: 139.165.0.0 - ulg.ac.be
>B26 - Sart Tilman www.ulg.ac.be
>B-4000 Liège 1 (Belgium)
>mailto:A.Pi...@ulg.ac.be +32-4-3664932 Fax: 2920
>
>
we are running several servers using different ports each using its
own translationtable. the clients login in using these
ports. this allows the same hostname.
i.e ftp <same-hostname> <different-port>
...works with most clients.
wbr,
sakthi
=====================================================================
Swiss Federal Office of Information Technology and Systems
(Bundesamt fuer Informatik)
DKNV
Sakthivel Phone : +41-31-325-9440
Monbijoustrasse 74 Fax : +41-31-325-9375
CH-3003 Bern E-Mail: sakth...@fe21.bfi.admin.ch
Switzerland X.400 : g=sakthivel s=kandiah o=gw2
a=admin c=ch/@admin.ch
SMTP to X400 : sakth...@fe21.bfi.admin.ch
=====================================================================