1. a) I need to upload a dataset from 3rd party thru FTP. The below is the control I pass. The problem with this is it receives only 1 record of length 80 but third party sends more than 1000.
-r tls xxx.xxx.xxx.xxx (exit
cd in
GET op-file.txt 'XXXX.YYYY.AJ7J701' +
(REPLACE
quit
Can somebody guide me what is the problem here?
1. b) Otherwise it receives in ASCII format. Can anybody help me how to convert the ASCII format to EBCDIC format?
2. Sending dataset to 3rd party (record len is 145, last 12 bytes are spaces), it receives only 133 bytes in a record and ignores the spaces. Is there any way to resolve this issue?
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
I provided you with links to three chapters from the TCP/IP User's Guide that deal with configuring and using FTP. You'll need to spend some time reviewing them. I'm concerned that this post might be considered Off-Topic, since it seems to be a data problem caused by the 3rd party, not an FTP problem and not specifically a mainframe problem.
What type of OS is this 3rd party using? Is this file coming in from another IBM mainframe? Is it a VAX, Unisys, Unix, Linux, or Windows OS? Is the data properly formatted with all required record and EOF delimiters? Is the data text or is it binary? Is it EBCDIC or is it ASCII?
ashokakash wrote:
Sending dataset to 3rd party (record len is 145, last 12 bytes are spaces), it receives only 133 bytes in a record and ignores
the spaces. Is there any way to resolve this issue?
Refer to the manuals for the settings/commands used to preserve blank spaces at the end of the records (usually only needed when dealing with an EBCDIC-to-ASCII transfer to a Windows FTP server).
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
When I've encountered this type of situation in the past, I've always asked the 3rd party for a hex dump of at least a couple of records from their file.
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hello,
In addition to what Kevin has provided (and you really do want to spend time learning more about FTP if you are going to use it in a production environment), i believe you will be ahead if you pre-allocate the mainframe dataset.
I expect the transfer is being done in "binary" - if you are transferring "text" data, you should specify "ascii" for the transfer mode. Many ftp sessions default to "auto" or "binary" and both of these may result in unusable data on the receiving end.
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
dick scherrer wrote:
... i believe you will be ahead if you pre-allocate the mainframe dataset.
Why? I'd think you'd always be better off creating a new dataset (a GDG would be good) each time by specifying the disposition of the target DD with DISP=(NEW,CATLG,DELETE) in the FTP step.
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hello,
Quote:
Why? I'd think you'd always be better off creating a new dataset
Possibly my bad I guess i'd agree as long as the mainframe was "pulling" the data. I'm remembering problems that may not be an issue for this upload.
The file problems i've had to deal with came up when the remote system needed to "push" the data (which is over 95% of the uploads i've been involved with) and then there were often dcb problems with the uploaded data.
I have given the jcl that I use for TSL FTP. That uses fileaid utilities. I do not know the O/S of the 3rd party but the data is converted to/from ASCII from/to EBCDIC is for sure.
I believe this would greatly help you give a fix to this issue.
1. Transfer from MF to 3rd party
-------------------------------------
XYZ.CONTROL(XYZXC172) has the below information
---------------------------------
-r tls aaa.bbb.ccc.ddd (exit
cd out
PUT 'XYZE.C165.A&OCYCLE' input_order.txt
quit
Here the problem is 3rd party receives only file of rec length 133 since the dataset has spaces from 134 to 145.
XYZ.CONTROL(XYZXE172) has the below information
---------------------------------
-r tls aaa.bbb.ccc.ddd (exit
cd in
LOCSITE WRAPRECORD
GET output_report.txt 'XYZE.E101.A&OCYCLE' +
(REPLACE
quit
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
ashokakash wrote:
Transfer from 3rd party to MF
From the same document:
Quote:
Rules
Do not use an end-of-line sequence other than CRLF if the server is a z/OS FTP server. The z/OS FTP server supports only the CRLF value for incoming data
I should thank you for the support and help. It is almost all got over but I got a new requirement that the file from remote host should be deleted. For that I used the below command but that failed. Can you please correct me if it is wrong. Thanks in advance.
The new line included in the control card is as follows
r tls xxx.xxx.xxx.xxx (exit
cd in
LOCSITE WRAPRECORD
GET op-file.txt 'XXXX.YYYY.AJ7J701' (REPLACE
DELETE op-file.txt
quit
I guess i'd agree as long as the mainframe was "pulling" the data. I'm remembering problems that may not be an issue for this upload.
