Re: Using FTP on z/OS to get csv file from unix box running ipswitch ws_ftp.

[John S. Giltner, Jr.]

If the source file is actually using CRLF to terminate the records, that 
may be the problem.  Unix normally terminates files with CR.  If the 
file is stored with CRLF, then Unix is having problems, I am not sure 
how VSE would have handled this.

You may want to try running this on the Unix box:
   dox2unix -o originalfile  -n newfile

then getting the new file.

BillD wrote:
Hi John.  Thanks for your reply.
The remote FTP site is a UNIX box, I believe running WS_FTP and Novell
networking.

I removed the "SITE type I" but still did not get the desired result.
After many trials of various parameters and studying what is happening,
I can now describe it this way:
Each input record is variable in length terminated with a CRLF.  Each
is just over 40 characters, so if you look at the first 80 characters
of the input, you get a complete record and almost all of a second
record.
The number of records on the output is twice the number on the input.
The first output record is correct and is the first part of the first
80 bytes of input up to the CRLF.
The second output record appears to be the remainder of the first 80
bytes.
The third output record is the complete record that started after the
1st complete record in the 1st 80 bytes of input or the second input
record.

I tried the following also:
EZA1736I structure record
EZA1701I >>> STRU R
501 unsupported, structure set to FILE
EZA1735I Std Return Code = 36501, Error Code = 00002
EZA1701I >>> QUIT
Documents suggested STRU was supported, but apparently not.

I think I'll have to look into suggesting the user create a .PRN file
to upload rather than the CSV or figure out how to get FTP to properly
handle the variable input.

Any other ideas?

Thanks again,
BillD


John S. Giltner, Jr. wrote:

BillD wrote:

We're converting from VSE to z/OS.  I'm trying to upload a CSV file
that has worked on VSE but has problems with trunc/wrap, CRLF or
something else on Z/OS.

This is what works in VSE. The file dump below shows the second record
as part of the first then the third is part of the second, etc.

// EXEC BSTTFTPC,SIZE=BSTTFTPC   (Barnard Software)
ID 02
OPEN <snip>
USER <snip>
PASS <snip>
CWD /ASN2MRP
OUTPUT SAM FTPU1 BLKSZ 16000 RECSZ 80 RECFM FB
TYPE A
pad on
padchar 64
RETR poeta.csv
QUIT

REC NO 000000001  119457,20060907,15360,008-0393-00,04,10854


FFFFFF6FFFFFFFF6FFFFF6FFF6FFFF6FF6FF6FFFFF44444444444444444444444444444444444444

119457B20060907B15360B00800393000B04B1085400000000000000000000000000000000000000

1.......10........20........30........40........50........60........70........80
REC NO 000000002  119447,20060907,7680,008-0347-00,04,10854


FFFFFF6FFFFFFFF6FFFF6FFF6FFFF6FF6FF6FFFFF444444444444444444444444444444444444444

119447B20060907B7680B00800347000B04B10854000000000000000000000000000000000000000

1.......10........20........30........40........50........60........70........80
REC NO 000000003  119445,20060907,15360,008-0344-00,04,10854


FFFFFF6FFFFFFFF6FFFFF6FFF6FFFF6FF6FF6FFFFF44444444444444444444444444444444444444

119445B20060907B15360B00800344000B04B1085400000000000000000000000000000000000000

1.......10........20........30........40........50........60........70........80
REC NO 000000004  119453,20060907,7680,008-0390-00,04,10854


FFFFFF6FFFFFFFF6FFFF6FFF6FFFF6FF6FF6FFFFF444444444444444444444444444444444444444

119453B20060907B7680B00800390000B04B10854000000000000000000000000000000000000000

1.......10........20........30........40........50........60........70........80

FYI - these files aren't exactly the same.  One is on our VSE box, the
other on z/OS.
I started with this in z/OS but have tried numerous other options to no
avail.

//STEP0010 EXEC PROC=FTP
//FTPU1    DD  DSN=&HLQ.PO.XF.FTPD.PU240.INPUT(+1),
//             DISP=(NEW,CATLG,DELETE),
//             LRECL=80,
//             RECFM=FB
//SYSPRINT DD  SYSOUT=(X)
//SYSIN    DD  *
FS190
;CD /ASN2MRP
ASCII
site type i
get poeta.csv //DD:FTPU1
QUIT

Gives me this.
....+...10....+....20....+...30....+...40....+...50....+...60....+...70....+...80
119447,20060907,7680,008-0347-00,04,10854
119447,20060907,15360,008-0347-00,04,
119447,20060907,15360,008-0347-00,04,10854
119445,20060907,15360,008-0344-00,04
119445,20060907,15360,008-0344-00,04,10854
119453,20060907,7680,008-0390-00,04,
119453,20060907,7680,008-0390-00,04,10854
119457,20060907,15360,008-0393-00,04,
119457,20060907,15360,008-0393-00,04,10854
119442,20060808,15360,008-0340-00,04
119442,20060808,15360,008-0340-00,04,10854

Should be this.
119447,20060907,7680,008-0347-00,04,10854
119447,20060907,15360,008-0347-00,04,10854
119445,20060907,15360,008-0344-00,04,10854
119453,20060907,7680,008-0390-00,04,10854
119457,20060907,15360,008-0393-00,04,10854
119442,20060808,15360,008-0340-00,04,10854

What I'm looking for is a way to properly pad the output replacing the
CRLF with a string of blanks to make an 80 byte record.
Does anyone have an example of FTP subcommands required for a good
result under z/OS?
I also tried IND$FILE via Extra.  It created a VB file on z/OS that was
fine.  I couldn't get FTP to properly copy to a VB File.  This is a
tough one!


What OS is the FTP server on?

You have "ASCII" so that z/OS client thinks the file transfer will be
ASCII.  However you also issue the command "SITE TYPE I" which should
tell the server to do a binary tranfer.  This means that the server will
not put CRLF on the end of the record.

You should be able to remove the "site type i" command and as long as
the source records are less than 80 bytes you should get what you want,
using FB.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html