Thanks to the following people for responding so quickly to my question(s):
mcrowley_at_mhc.mtholyoke.edu
jsurlow_at_hdra.acs.uci.edu
lynam_at_homer.qut.edu.au
yahoshi_at_osa.dec.com
alan_at_nabeth.cxo.dec.com
danno_at_rmi.net
soma_c_at_decus.fr
davet_at_raymond.acc.uri.edu
eidson_at_unix4.is.tcu.edu
NMH1_at_axprl1.rl.ac.uk
tpb_at_zk3.dec.com
hubcap_at_hubcap.clemson.edu
dgj_at_omega.rtpnc.epa.gov
sherwood_at_esu.edu
mahg_at_ucfv.bc.ca
de5_at_sws5.ctd.ornl.gov
snewton_at_oac.hsc.uth.tmc.edu
arthur_at_midir.ucd.ie
arne_at_Steinkamm.COM
RORY_O'CONNOR_at_US.WFL.COM
Original Posting:
---------------------
Please help me solve a raging debate going on at my site.
We are FTP'ing files from an Amdahl computer (no problem).
We obviously want the files in ASCII format (since we are
taking the files and loading them into an Oracle database).
The Amdahl programmers tell us there is no such thing as an
ASCII file on an Amdahl computer and the ftp is automatically
converting the EBCDIC file to ASCII when we ftp it to our
Alpha (DU 3.2c)
I'm telling them "it ain't so, the file ASCII on the Amdahl".
Anyway, I'm looking for some answers (so I [can] be humbled or
beat them up)
1. Does FTP "know" the diff character sets and convert on the fly?
2. Are there any DU utilities to convert EBCDIC chars to ASCII?
(In the event the Amdahl people want to get nasty and only make
EBCDIC files available to me).
Now, I am already pulling files down from other subsystems on the
Amdahl and they are ASCII, plain, simple, no debate. So I know the
Amdahl can spit out ASCII files / characters.
Summary of responses:
---------------------------
Amdahls don't know ASCII (which I knew, but probably didn't clarify).
Question 1: Yes, ftp can do the conversion on the fly.
The TCP/IP stack on the Amdahl does perform the conversion
to ASCII when ftp requests an ASCII file transfer. This
is one of the toggle options available during the ftp session
(enter at the ftp command line 'ascii'). This causes the
IP stack to convert using a built-in translation table
(Warning: there isn't a standard translation table and some
characters may not translate correctly).
The other toggle transfer mode is binary mode. It was
recommended I ftp the file as a binary file, which would
copy the file in the exact same format as it is stored on
the Amdahl (giving you the chance to examine the data to
determine the storage format).
Question 2:
There is a UNIX utility, dd, which can convert ascii to
ebcdic and vice versa. [Note: Before I asked this question,
I went digging through all sorts of manuals and other
resources. Nothing pointed to the dd command. Guess
it's one of those Unix treats, when you find it you can
use it to death, but finding it... well....]
Summary of tests:
----------------------
I ftp'd a test file, from the Amdahl to the Alpha, as a
binary xfer and an ascii xfer.
The binary xfer did indeed give me an ebcdic file.
I ran dd on the ebcdic file (dd -conv ascii) and
got a nice ascii file. One thing to note, the converted
ascii file does not contain carriage return / line feeds in
it. This is important to us since Oracle loader is looking
for <cr><lf> to determine the end of record. If we know
the record length, we can write a perl, sed, awk, or other
script to insert a <cr><lf> at the end of each record
(based on the known record length, but read on)...
The ascii xfer did indeed give me an ascii file.
The ascii xfer gave me an Oracle loader usable file,
but check the default cr actions on your ftp. DU ftp
defaults to stripping <cr>s from the file being
transferred. If you want to keep the <cr>s, then use
the cr toggle at the ftp command line to keep <cr>s
in the file.
In talking to our Amdahl system operations people,
they verified the IP stack is performing the conversion
for us (using ascii mode in the ftp).
So, again, thanks for everyone who responded. I would
like to extend special thanks to Rory O'Conner for
providing a very concise summary in terms that were
understandable to my non-technical team members.
They read his response and understood all the issues,
thanks Rory and thank you all.
Tim Householder
EXCEL Management Systems, Inc.
(916) 553-4824
houseti_at_diamond.mcclellan.af.mil
Received on Thu Jul 18 1996 - 22:49:57 NZST