net::ftp puttextfile to os/390

[dkmd_nielsen]

I'm sure you don't get too many mainframe related questions. First the
code, then my blather.

f = Net::FTP.open("wouldntyou.liketoknow.com","anonymous")
f.chdir("'#{prj.mainframe_prefix}'")
f.site("LOCSITE BLOCKS BLKSIZE=0 LRECL=124 RECFM=FB PRIMARY=500
SECONDARY=500")
f.puttextfile("#{prj.networkfolder}\\#{prj.deptrun}_flc_cards.txt","FLC")
f.site("LOCSITE BLOCKS BLKSIZE=0 LRECL=60 RECFM=FB PRIMARY=500
SECONDARY=500")
f.puttextfile("#{prj.networkfolder}\\#{prj.deptrun}_flc_cards.txt","PRTY")
f.close


I'm attempting to ftp a network based text file to the mainframe (ascii
to ebcdic). Everything operates without error, but only the first
record of the file is transmitted. I added a code block to the
puttextfile function and a puts to display everything being sent. Yep,
just one line. Each text line does have a CRLF at the end. I tried it
without the CRLF. That was no go, too.

I tried setting TYPE A and then using just put. put sent the file
binary, anyway. But atleast the binary gobbldee gook appears to have
sent all the records.

Your thoughts are appreciated,
dvn - I've googled everything I can possibly think of.
dvn

 

[dkmd_nielsen]

This is definitely a disconnect between my mainframe backgrounds and
ascii pc/network knowledge. When I create my file with Ruby, I append
a '\r' to the end of each record [io.syswrite(flc.build+"\r")]. I do
this so the file is displayed properly by text editors. When I go to
transmit this file, I get an extra 0d at the end of the record in
recieved file. That I can see that on the mainframe side. If I create
the file one byte longer than the actual data and use WRAP, then the
records write correctly with the x0d at the end. It is my thought that
the x0a0d should be truncated off the end of the record.

I'm assuming my problem is on the mainframe side. When I trace the FTP
on the Ruby end, it appears to send the entire file as one big chunk.
So that means it is up to the mainframe to perform the proper chomp.
(Which is interesting because Net::FTP does a chomp and appends a
CRLF.)

I have done the ftp transfer from the command line, using the same site
commands to setup the recieving file. It behaves the same. I must be
missing some site command to tell ftp to lose the extra byte.

dvn

 

[dkmd_nielsen]

OK. Here is the straight dope. I'm not the only one with the
mainframe/pc-network disconnect. FTP has the same disconnect. WHEN I
run FTP from the mainframe and get the data from network, everything is
ok. OS/390 TCP/IP understands all the CR/LF stuff and deals with it
properly.

On the other side is FTP on the network. This is mainly Unix based.
(We all know that DOS is just a dumbed down Unix variant.) It operates
in a LF or CR/LF world. When it is talking to the mainframe, it
doesn't know that. Sure, I setup the ASCII/EBCDIC notification (TYPE
A), but it still doesn't deal with the trailing characters.

I really only have two alternatives here: 1) live with the extra byte
on the mainframe side, or 2) live without the CR/LF on the network
side. 1) is not a possibility. So 2) will have to be it. Since the
data created on the PC side is extracted from an Excel spreadsheet, I
have the data in a usable format. So the text file is not for general
use.

I hope someone else can make use of this information, or correct me
where I am wrong.

Have a good one, all!
dvn