On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote:
>>
>I have seen the very misleading 451 message when attempting this with a USS
>file in which the last line does not end with hex 15.
>
I tried the following script (on Solaris):
550$ cat bin/longline
#! /bin/sh -x
# Doc: create a large file consisting of only a single line.
target=$HOME/work/bigline
# On ASCII system, "\n" is '\012'
: && { tr -d '\012' </dev/random |
ssh $MVS_USER@$MVS_HOST "set -x
{ dd bs=1000 count=1000; echo; } |
tee $target | wc"; }
cd $TMPDIR
ftp $MVS_HOST <<eod
verbose
ascii
cd $HOME/work
get bigline long1
site encoding=mbcs
site mbdataconn=(IBM-1047,UTF-8)
get $target long2
quit
eod
... with the results:
...
+ dd bs=1000 count=1000
+ wc
FSUM6384 844+156 records in
844+156 records out
+ echo
1 17014 863161
... Why not 1000001? That's for MVS-OE.
...
Verbose mode on.
200 Representation type is Ascii NonPrint
250 HFS directory .../work is the current working directory
200 Port request OK.
125 Sending data set .../work/bigline
250 Transfer completed successfully.
local: long1 remote: bigline
862162 bytes received in 0.037 seconds (22973.67 Kbytes/s)
200 SITE command was accepted
200 SITE command was accepted
200 Port request OK.
125 Sending data set .../work/bigline
451 File transfer failed. Multi-byte data conversion error occurred
221 Quit command received. Goodbye.
There's *no* character that can't be converted from IBM-1047 to UTF-8.
I suspect that when doing a MBCS conversion, FTP attempts to break the
input data into lines and convert them one at a time. Perhaps it is done
this way from concern that a buffer might otherwise contain an incomplete
character. In:
http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.bpxbd00/iconvp.htm
iconv() — Code conversion
z/OS XL C/C++ Runtime Library Reference
SC14-7314-00
...
If the input buffer ends with an incomplete character or shift sequence,
conversion stops
after the previous successfully converted bytes, and iconv() sets errno to
EINVAL.
There's a straightforward technique to recover from this that does not require
breaking
the input data into lines nor a priori knowedge of where the data may be
separated
into characters.
They could have done better.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
