|
View previous topic :: View next topic
|
| Author |
Message |
ashokakash
New User
Joined: 15 Nov 2006
Posts: 21
Location: Chennai
|
|
|
|
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? |
|
| Back to top |
|
 |
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
| Back to top |
|
|
superk
Global Moderator
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). |
|
| Back to top |
|
|
superk
Global Moderator
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. |
|
| Back to top |
|
|
ashokakash
New User
Joined: 15 Nov 2006
Posts: 21
Location: Chennai
|
|
|
|
| Thanks Superk. I will try going thru this and will ask the same questions to the 3rd party. I hope this will help me. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
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. |
|
| Back to top |
|
|
superk
Global Moderator
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. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
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. |
|
| Back to top |
|
|
ashokakash
New User
Joined: 15 Nov 2006
Posts: 21
Location: Chennai
|
|
|
|
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
-------------------------------------
| Code: |
//XYZDC171 EXEC PGM=UTYPSYM,REGION=512K,TIME=1,
// PARM=('FTP,INPUT,OCYCLE=&OCYCLE'),
//UTYVSYS DD DSN=XYZ.CONTROL(XYZXC171),DISP=SHR
//*INPUT WITH RESOLVED FTP COMMANDS
//INPUT DD DISP=(,DELETE,DELETE),
// UNIT=TEMPDA,
// BLKSIZE=0,
// SPACE=(80,(1,1))
//OUTPUT DD DSN=XYZE.C172.A&OCYCLE,
// DISP=(,CATLG,DELETE),
// UNIT=SYSD@,AVGREC=U,
// DCB=(RECFM=FB,LRECL=160,BLKSIZE=0),
// SPACE=(160,(1000,100),RLSE),
// LABEL=RETPD=0030
//NETRC DD DSN=XYZ.CONTROL(XYZXC172),DISP=SHR
//* BELOW CONTAINS SYSTEM TCP AND FTP PARMS
//SYSTCPD DD DSN=SYS7.TCPPARMS(TCPDATA),DISP=SHR
//SYSFTPD DD DSN=SYS7.TCPPARMS.SFTP(SFTP0002),DISP=SHR
//SYSOUT DD SYSOUT=A
//SYSPRINT DD SYSOUT=A
//SYSUDUMP DD SYSOUT=(A,,DUMP),HOLD=YES
|
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.
2. Transfer from 3rd party to MF
| Code: |
//XYZDE102 EXEC PGM=UTYPSYM,REGION=512K,TIME=1,
// PARM=('FTP,INPUT,OCYCLE=&OCYCLE'),
//UTYVSYS DD DSN=XYZ.CONTROL(XYZXE102),DISP=SHR
//*INPUT WITH RESOLVED FTP COMMANDS
//INPUT DD DISP=(,DELETE,DELETE),
// UNIT=TEMPDA,
// BLKSIZE=0,
// SPACE=(80,(1,1))
//OUTPUT DD DSN=XYZE.E102.A&OCYCLE,
// DISP=(,CATLG,DELETE),
// UNIT=SYSD@,AVGREC=U,
// DCB=(RECFM=FB,LRECL=160,BLKSIZE=0),
// SPACE=(160,(1000,100),RLSE),
// LABEL=RETPD=0030
//NETRC DD DSN=XYZ.CONTROL(XYZXE103),DISP=SHR
//* BELOW CONTAINS SYSTEM TCP AND FTP PARMS
//SYSTCPD DD DSN=SYS7.TCPPARMS(TCPDATA),DISP=SHR
//SYSFTPD DD DSN=SYS7.TCPPARMS.SFTP(SFTP0002),DISP=SHR
//SYSOUT DD SYSOUT=A
//SYSPRINT DD SYSOUT=A
//SYSUDUMP DD SYSOUT=(A,,DUMP),HOLD=YES
|
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 |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
| ashokakash wrote: |
Here the problem is 3rd party receives only file of rec length 133 since the dataset has spaces from 134 to 145.
|
The FTP sub-command you need is TRAILingblanks:
TRAILingblanks Specifies that the FTP client preserves the trailing blanks in a fixed format data set when the data is sent to a foreign host.
You can permanently add this parameter to your SYSFTPD DD, or by using the LOCsite sub-command:
>LOCSIte TRAILingblanks |
|
| Back to top |
|
|
superk
Global Moderator
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
|
|
|
| Back to top |
|
|
ashokakash
New User
Joined: 15 Nov 2006
Posts: 21
Location: Chennai
|
|
|
|
Hi SuperK/Dick,
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
The errorlog contained the below
EZA1736I DELETE op-file.txt
EZA1701I >>> DELE op-file.txt
450 deletion failed
EZA1735I FTP Return Code = 13450, Error Code = 00002
EZA1701I >>> QUIT
221 Good-Bye |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
You might have someone check that the id being used has permission to delete the dataset on the remote system. |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
| dick scherrer wrote: |
| You might have someone check that the id being used has permission to delete the dataset on the remote system. |
Yup. It's rare that it does. |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
