|
View previous topic :: View next topic
|
| Author |
Message |
tecnokrat
Warnings : 1
Active User
Joined: 22 May 2009
Posts: 160
Location: Bangalore
|
|
|
|
Hi
I have a requirement where my Mainframe JCL needs to pull a file from one of the server.
This file is of variable length and each records in the file is separated by a carriage return.
Now when I have executed my JCL to pull the file only the first record is being retrieved.
| Quote: |
| 6543478990378626920202873632097373949475578389367389478324738738373888888888888888888888888827238963412245423985794639536535374596875394975634538823647269126364923165782314652376782643827 |
my ftp control card has the parameters below:
| Code: |
server address
username
pwd
ascii
CD dir\Foldername
dir
LCD
GET Variablefile.txt 'MYID.PSFILE'
QUIT
|
The mainframe file MYID.FILE which is defined is with the LRECL of bytes 250.
In the first instance my JCL ran fine and all the records are in each separate line. This is because the text file is of length 170 bytes.
But now that the length of the text file has surpassed the LRECL only the first 250 bytes are copied whereas my JCL should have picked whole bunch of the contiguous file.
Please could you help me in getting the whole of the file as in without change in LRECL always and the file can be get without any data spill. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
First, the length of the data will NOT impact how the data is received in the FTP.
Second, if your data lines are longer than 250 bytes, why do you have the LRECL as 250?
Third, you did not post how MYID.PSFILE is defined -- variable? fixed? blocked? LRECL? BLKsize?
Fourth, you did not indicate if the data is coming from a Unix server or a Windows server or a z/OS server. Since you have a CR as the line terminator, if the server is a Unix server than your file would be received as one long record since Unix uses a line feed (LF) as the line terminator and does not recognize the CR.
| Quote: |
| Please could you help me in getting the whole of the file as in without change in LRECL always and the file can be get without any data spill. |
What you ask for may -- or may not -- be possible. There are too many unanswered questions to be able to say for sure (for example, if the data lines really exceed 250 bytes and you are receiving into a data set with LRECL 250, data truncation may occur; your choices are to accept the data truncation or change the LRECL). |
|
| Back to top |
|
|
tecnokrat
Warnings : 1
Active User
Joined: 22 May 2009
Posts: 160
Location: Bangalore
|
|
|
|
| Quote: |
First, the length of the data will NOT impact how the data is received in the FTP.
|
I agree with that.
| Quote: |
| Second, if your data lines are longer than 250 bytes, why do you have the LRECL as 250? |
I have defined a GDG where i'm placing all the files read from the server. I declared a maximum LRECL of 250 bytes.
| Quote: |
| Third, you did not post how MYID.PSFILE is defined -- variable? fixed? blocked? LRECL? BLKsize? |
The Mainframe file is defined as GDG FB and with LRECL of 250 bytes, tried using the option of VB but still the file is able to grab only the first line. BLKSIZE is not defined.
| Quote: |
Fourth, you did not indicate if the data is coming from a Unix server or a Windows server or a z/OS server. Since you have a CR as the line terminator, if the server is a Unix server than your file would be received as one long record since Unix uses a line feed (LF) as the line terminator and does not recognize the CR.
|
The text file is from a Unix server. Each of the records are separated by a CR so that when read by FTP to my mainframe file should be in each line. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
So basically the FTP is doing PRECISELY what you told it to do -- bring all the data across as a single record. Having a CR in a record on a Unix machine does NOT indicate the end of a record -- only the LF character will do that; hence as far as the system is concerned you are receiving ONE record.
What you need is
| Code: |
server address
username
pwd
ascii
CD dir\Foldername
dir
locsite sbsendeol=cr
GET Variablefile.txt 'MYID.PSFILE'
QUIT |
although if you're submitting JCL, this might not work since SBSENDEOL is for data going to a server. Note I removed the useless and unnecessary LCD in your FTP.
But the bottom line is that since your file does not have the standard and correct line terminator sequence for the platform it is on, FTP is not recognizing that there is more than one record in the file. Hence the mainframe only retrieves one record. Fixing this issue through FTP may or may not work (I don't have a way to test FTP right now); otherwise, your BEST option will be to fix the file on the other platform before the FTP so it has the correct line terminator sequence to allow records to be identified. |
|
| Back to top |
|
|
tecnokrat
Warnings : 1
Active User
Joined: 22 May 2009
Posts: 160
Location: Bangalore
|
|
|
|
Thanks Robert
I tried using the parameter
| Code: |
| locsite sbsendeol=cr |
But still the JCL is picking only the first 250 or n chars of the LRECL into the file.
When researched for different options on SBSENDEOL the file is with the same result of to pick only first 'n' chars.
| Code: |
| locsite sbsendeol=LF |
| Code: |
| locsite sbsendeol=CRLF |
Would there be an option where I no need to specify the file length and dump the whole of the file and then traverse for the records from the file. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
When you send text data through FTP, FTP automatically converts any line end character(s) in the input to the standard FTP line end character. The receiving FTP does not need to know what the line end character(s) was in the source because the receiving FTP will never see it or them.
Obviously this is not true for data sent as "binary" data. Then, any program that analyzes the data must be aware of the convention used on the source system. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
You could transfer the file to a Unix System Services file (which does not use record boundaries) and then split the record using a program in the language of your choice, transferring the converted file to an MVS data set.
As I said earlier, though, your best solution would be to get the application generating the file to put the correct line termination character in the file instead of what is there now. |
|
| Back to top |
|
|
tecnokrat
Warnings : 1
Active User
Joined: 22 May 2009
Posts: 160
Location: Bangalore
|
|
|
|
Tried by not declaring any parameters for the Input file.
The FTP has pulled the text file by declaring the PS file as a VB and the data is truncated.
| Code: |
EZA2802I Data was truncated.
EZA1460I Command:
EZA1736I QUIT
EZA1701I >>> QUIT
221 Goodbye. |
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| There's probably more going on than you are telling us. Your best bet at this point will be to work with your site support group to get the data transfer done. There may other ways to transfer the data besides FTP and your site support group will be aware of them. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| tecnokrat wrote: |
| ... FTP has pulled the text file by declaring the PS file as a VB and the data is truncated. ... |
What are the DCB attributes of the VB sequential data set? Another useful thing you can try yourself is to greatly increase the LRECL of the VB data set and see if you can receive the data as text
About the only additional suggestion I can make is to transfer the file as binary, dump the mainframe data set and figure out the line end sequence in the source system from the dump. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
On a somewhat related note, there is a new ISPF Edit command called LF that will break up a record that contains ascii linefeed characters x'0A.'
A contrived example:
| Code: |
EDIT DDST.LEAHYD2.CLIST(LF) - 0
Command ===>
****** ******************************
000001 This is line 1 This is line 2
E88A48A498984F0E88A48A498984F4
38920920395501A389209203955020 |
Type LF on the command line and you get:
| Code: |
EDIT DDST.LEAHYD2.CLIST(LF)
Command ===>
****** **************************
000001 This is line 1
000002 This is line 2 |
|
|
| Back to top |
|
|
|
|
