|
View previous topic :: View next topic
|
| Author |
Message |
RedDevil711
New User
.jpg)
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
Hi Guys,
Need a help related to FTP. There is a file being generated on Datastage, the file is in text format and is in format ISO8859-15.
We are working on a process to setup FTP of these files.
now when i tried setting up the FTP i am noticing the following discrepancy, the file is having @ symbols appended at the end. When i view the text file on my desktop it looks fine, also the file looks fine on the DS server.
Command used by me for FTP:
cd Server-Path
SITE RECFM=FB LRECL=53 sbdataconn=(ISO8859-15,ISO8859-15)
LOCSITE RECFM=FB LRECL=53 sbdataconn=(ISO8859-15,ISO8859-15)
GET DetailsInfo.txt +
'PXXX.DETAILS.INFO' (REPLACE
QUIT
There are basically three columns in this details file
the first column is 8 byte char, the second is 10 byte integer and third is 35 byte char |
|
| Back to top |
|
 |
Escapa
Senior Member
Joined: 16 Feb 2007
Posts: 1399
Location: IL, USA
|
|
|
|
| Show us one record of input file and output record on mainframe with Hex on. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Frequently @ signs at the end of the data set are spaces that didn't get translated and the spaces are not being truncated -- but this is generally for a variable length record. What you posted appears to have fixed length records.
Have you talked to your site support group about the issue and had them check the FTP parameters at your site? Site parameters could affect your results. |
|
| Back to top |
|
|
RedDevil711
New User
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
Sorry Guys, Injured for a while and hence resting.
Just returned to work
@Escapa
Sample records
| Code: |
3333332222222222222222222222333333333444444
0031490000000000000000000000B15A37A43000000
------------------------------------------
2222222222222222222222222222333333333444444
0000000000000000000000000000B16A06A23000000
------------------------------------------
3333332222222222222222222222333333333444444
0194930000000000000000000000B12A13A09000000 |
@Robert
The file may be varying as its structure is quite similar to a CSV.
I will check once with the site folks and update you.
Thanks for the help
Code'd |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
What you sent to us appears to be a screen shot from ISPF browse.
| Code: |
HI hi
CC4884
890890 |
Now this data has valid EBCDIC data. The letter H is represented by X'C8'; it is displayed as the C over 8 under the H so the hex representation stays under the character.
In your data we have a number of X'20' characters. In ASCII this is usually blank. I'm not going to try to guess or look up the non-blank ASCII characters in your data. I'm guessing the EBCDIC blank characters in your data is a side effect of your transmission.
I think what appears to be ASCII in your post resulted from transmission in "image" or "binary" mode.
And that's enough for nuthin'. |
|
| Back to top |
|
|
RedDevil711
New User
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
Hi Steve,
I have taken a hex view of my record.
I am ok with blanks coming in, its a char field what i wanted to remove was the '@' symbols getting added at the end, the hex value X'40'.
Not sure, no reply from my site guys yet |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
X'40' is EBCDIC space. X'40' is ASCII for @.
Something in your process has padded the records with EBCDIC space. When you look at the data on an ASCII system they will show as @.
The sample all look like fixed-length records, you say they can be variable.
If you read Robert's post again, you'll see you already know this.
We have nothing beyond that to go on. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
In ISPF, it can be difficult to discern whether the data is variable, fixed or undefined length records. For example -
| Code: |
00000100PROC 0
FFFFFFFFDDDC4F
00000100796300
-------------------
00000200CONTROL LIST
FFFFFFFFCDDEDDD4DCEE
00000200365396303923 |
An experienced MVS person would quickly determine these are not fixed length records, but could not immediately deduce whether the records are variable length or undefined length records. This person could also more than lilkly state the odds are the records are variable length records based on their visible contents. This is definitely RECFM=U data.
| Code: |
00000100PROC 0
FFFFFFFFDDDC4F
00000100796300
-------------------
00000200CONTROL LIST
FFFFFFFFCDDEDDD4DCEE
00000200365396303923 |
Now, if the data is presented differently -
| Code: |
*** RECORD 1
0000 0 00120000 F0F0F0F0 F0F1F0F0 D7D9D6C3 *....00000100PROC*
0010 16 40F0 * 0 *
*** RECORD 2
0000 0 00180000 F0F0F0F0 F0F2F0F0 C3D6D5E3 *....00000200CONT*
0010 16 D9D6D340 D3C9E2E3 *ROL LIST *
...
*** RECORD 1
0000 0 F0F0F0F0 F0F1F0F0 D7D9D6C3 40F0 *00000100PROC 0 *
*** RECORD 2
0000 0 F0F0F0F0 F0F2F0F0 C3D6D5E3 D9D6D340 *00000200CONTROL *
0010 16 D3C9E2E3 *LIST * |
It's immediately obvious the first data set contains variable length records and the second data set contains undefined length records. The first data set clearly has Record Descriptor Words before the text in each record. |
|
| Back to top |
|
|
RedDevil711
New User
Joined: 04 Jun 2010
Posts: 25
Location: Pune
|
|
|
|
| Thanks for the explanation Steve, I have asked the DS development team to check with the record they are sending for me to download on Mainframes, Thanks for all the help guys. |
|
| Back to top |
|
|
|
|
