I have tried all three and the result is the same…

Some time ago, I remember a similar problem.

What we did was to cut and paste the ‘|’ from a pc screen to the editor.
That symbol from the terminal emulator keyboard looked the same but had a different hex value.

Phil

The way I read your question, it looks like you are adding the pipe symbol to the flat file. I think this may be your problem.

Are you creating a flat file because you only need certain fields from the original file?
If not, let the CPYTOIMPF insert the pipe symbol for you.

CPYTOIMPF FROMFILE(MyFile) +
TOSTMF(‘/IFSFOLDER/FILENAME.TXT’) +
MBROPT(*REPLACE) STMFCODPAG(*PCASCII) +
RCDDLM(*CRLF) STRDLM(*NONE) FLDDLM(‘|’)

If you do only need certain fields from the original file, create a work file using DDS that contains only the fields you want. Then use the CPYTOIMPF command as illustrated above.

The reason why i used cpytoimpf is that i want the naming convention to have more than 15 characters.Also i have already used the pipe to seperare the fields in flat file.Now when am doing cpytoimpf there are options like field and string delimiter where i have given a pipe symbol still it reaches the other system as !

I also sent the flat file with pipe delimiter directly thr ftp without using cpytoimpf and the same problem occured.

Apparently you’re not the only one.
Ihttp://www.dynamoo.com/technical/ebcdic.htm

My vertical bar is EBSIDIC 4F and when I FTP a file with it to my PC I get the vertical bar.
I think you want to transmit ascii 124 (decimal).
So you’ll want to check the ASCII conversion table you’re using.
In the data structure you may want to load it as X’4F’ or whatever value the conversion table uses.

Phil

I tried transmitting the flat file without using cpytoimpf and there still is a problem.
I dont have much idea about things like the ASCII conversion table.A small sample would gretaly help.
As of now i have initialised the part of DS with a ‘|’ symbol.A solution would be greatly appreciated.

Well there seems to be trouble in them their translation tables.

I’m not sure which translation table you use
WrkTbl QASCII <– an obvious EBCDIC
The vertical bar in ASCII is 127 Hex 7c
The vertical bar in EBCDIC is 79 Hex 4f |
and 90 Hex 5a is !
and 106 Hex 6a is the broken vertical bar

My ASCII table shows EBCDIC 6a to 7c but my conversion for 4f works — I suspect my system isn’t using this table.

AND — HERE’S THE KICKER — 4f to 21 which happens to be … ! So QASCII will convert vert bar to !

So code your vertial var like this
D vert2 s 1 inz(X’6a’)

It will look like a vertical broken bar on your 400 screen but will convert to a real 7c vertical bar .. maybe.
Phil

I declared x’6A’ as suggested and it worked.That was a good one.Is 6A the hex value for spilt vertical bar?Am still confused as to why this happened?was it because of conversion from EBCDIC to ASCII.I think this is a rare case correct me if am wrong.

Yes. 6a is the split vert bar.
Anyone using the QASCII table as their default would get that conversion unless they change the table.
And wayback when I was using the cut and past I must have been on a system using those tables.

Phil