|
View previous topic :: View next topic
|
| Author |
Message |
raj_mainframe08
New User
Joined: 11 Sep 2007
Posts: 65
Location: Gurgaon
|
|
|
|
I have following file record as input
| Code: |
00U0001|00U0001|086|20100415|20120415
|
Between every field, there is a | as separator.
Now when i am zipping the above file and emailing it through JCL i am getting as follows
| Code: |
00U0001³00U0001³086³20100415³
|
| replaced by '
Can anyone helped me what's the problem..
Following is the JCL i used
| Code: |
To zip the file
000129 //PKZIP01 EXEC PGM=PKZIP,REGION=0M,TIME=(50,00)
000130 //INFILE DD DSN=SS5482.G5482.PART188A.DATA(+1),DISP=SHR
000131 //OUTFILE DD DSN=SS5482.G5482.PART188A.DATA.ZIP,DISP=SHR
000132 //SYSIN DD *
000133 -INDD(INFILE)
000134 -ARCHOUTDD(OUTFILE)
000135 -METHOD(MAXIMUM)
000136 //SYSPRINT DD SYSOUT=(,)
000137 //SYSOUT DD SYSOUT=(,)
000138 //SYSUDUMP DD SYSOUT=(,)
below step to send the zipped file through email
000140 //XMIT01 EXEC PGM=IKJEFT01
000141 //SYSPROC DD DSN=SYSUSER.TSO.COMMON.CLIST,DISP=SHR
000142 //STEPS DD DSN=SS5482.G5482.STEPS4.DATA,DISP=SHR
000143 //ADDR DD DSN=SS5482.G5482.RAJIV.ADDR.DATA,DISP=SHR
000144 //SYSTSPRT DD SYSOUT=(,)
000145 //PART188A DD DSN=SS5482.G5482.PART188A.DATA.ZIP,DISP=SHR
000146 //SYSTSIN DD *
000147 %XMITIP * -
000148 FROM (TEST@TEST.COM) -
000149 SUBJECT 'TEST PART 1A' -
000150 MSGDD STEPS -
000151 ADDRESSFILEDD ADDR -
000152 FORMAT BIN/ZIP -
000153 FILEDD (PART188A)
000154 //*
|
|
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| What is the hex code of each seperator please. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
well,
i can only assume PKZIP is doing the replacement.
what does the PKZIP doumentation say about such characters
this is what the 256 char look like on my machine:
| Code: |
0000000000000000111111111111111122222222222222223333333333333333
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
----------------------------------------------------------------
â{àáãåçñÄ.<(+!&éêëèíîïì~Ü$*);^-/Â[ÀÁÃÅÇÑö,%_>?øÉÊËÈÍÎÏÌ`:#§'="
4444444444444444555555555555555566666666666666667777777777777777
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
----------------------------------------------------------------
Øabcdefghi«»ðýþ±°jklmnopqrªºæ¸Æ€µßstuvwxyz¡¿ÐÝÞ®¢£¥·©@¶¼½¾¬|¯¨´×
88888888888888889999999999999999AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
----------------------------------------------------------------
äABCDEFGHI ô¦òóõüJKLMNOPQR¹û}ùúÿÖ÷STUVWXYZ²Ô\ÒÓÕ0123456789³Û]ÙÚ
CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDEEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF
|
|
|
| Back to top |
|
|
raj_mainframe08
New User
Joined: 11 Sep 2007
Posts: 65
Location: Gurgaon
|
|
|
|
| I am adding the Seperator | in my input file as ALPHABET. So its should be considered as Alphabet i beleive |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Can you find the hex code of at least the 2nd seperator? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| I am adding the Seperator | in my input file as ALPHABET. So its should be considered as Alphabet i beleive |
This makes absolutely no sense. An alphabetic character is normally considered A-Z and a-z only -- so where do you get the idea that a vertical bar would be alphabetic? And what language or utility are you using the term with -- SORT, COBOL, SAS, IDCAMS, IEBGENER, PKZIP, or something else?
Assuming you are not using any package on the receiving side except unzip (and if you are, then that package could be changing the characters), there's only two possibilities -- either PKZIP is changing the characters, or the unzip package you are using on the other end of the connection is changing them. You need to research (AS IN READ THE MANUALS) of the PKZIP as well as the unzip package you are using to find out how to fix this. |
|
| Back to top |
|
|
raj_mainframe08
New User
Joined: 11 Sep 2007
Posts: 65
Location: Gurgaon
|
|
|
|
| I created flat file using FOCUS code. I defined an alphanumeric variable and move | in it and then used it in file. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Look, you say comma in your first post, but show something in the code-block which is not a comma.
What is the hex code of that something? We chase a square box the other day, the important thing about it was not the box but the hex code which something was displaying as a box.
Your character is not standard EBCDIC. So what is its damn code?
| Code: |
| ' (quote) VS ³ (your seperator) |
|
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| raj_mainframe08 wrote: |
| I created flat file using FOCUS code. I defined an alphanumeric variable and move | in it and then used it in file. |
why do you think that is an appropriate response?
Robert made several statements/posed a few questions
and you answered the least important.
hopefully you are doing some testing/manual reading.
one thing that I always do when I have to transfer data from one platform to another.
I create a file with all 256 ebcdic chars - in collating sequence.
I then transfer the file and see what the results are.
for every character
It may turn out that the easiest thing to do is use a different field terminator - then you won't even have to investigate and learn the reason for the 'bad' char conversion. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Apparently, the PKZIP translation table (PKZIP automatically converts the data between EBCDIC and ASCII) does not convert the vertical bar as it should.
I would go for an easy solution and try to use something standard, like a comma (,) or a tab char (x'05').
For the receiving party, such files can be directly opened in Excel. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Marso, are you back? |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| The superscript 3 is the solid vertical bar (Alt Gr+`) as opposed to the broken vertical bar (shifted \). (Both UK keyboard.) In a DOS box on windoze it displays correctly. The code is decimal 179. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Thanks Nic for answering the question I asked the TS 10 minutes after he first posted. He's been too lazy to answer it all day, despite being asked three times.
And the answer, as partly expected, it is the same value, just displays differently on what are presumably two different systems.
And, TS, get glasses. A "superscript 3" is not a quote.
When transferring data to a non-mainframe the two most likely things, when you see "invalid characters" are 1) it is the same code, just displays differently (many, many reasons for this) 2) there has been EBCDIC/ASCII conversion on a "non-text" file. By "non-text" I include the less-common keyboard characters.
If you do it exactly like Dick suggests you will save yourself many problems.
If you have problems, next time answer all the damn questions, even if they seem too simple for you. If you are just lazy, next time you get no answer from me. Three damn times, and you just let someone else do the work. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| No work for me - I'd been playing with box characters in a DOS bat file the day before! |
|
| Back to top |
|
|
gylbharat
Active Member
.jpg)
Joined: 31 Jul 2009
Posts: 565
Location: Bangalore
|
|
|
|
Hi All,
when we are zipping in binary format and unzipping it at the other end... I think then character replacement should not happen as binary format is standard format in every system.
Please correct me if I am wrong? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| gylbharat wrote: |
Hi All,
when we are zipping in binary format and unzipping it at the other end... I think then character replacement should not happen as binary format is standard format in every system.
Please correct me if I am wrong? |
Do computers use binary? Yes. What does that mean as far as being able to look at/use data? Not a lot. What is the international standard for the binary representation of data? Does everyone use it? What about 7-bit binary?
IBMs use EBCDIC. How many EBCDICs are there? UK, Italy, US, India - all will be different. Who makes your comms gear? Important too.
Do it Dick's way, and you'll be OK. Assume that "all computers are binary" and you'll get problems, maybe which you'll blame on something else. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
when we are zipping in binary format and unzipping it at the other end... I think then character replacement should not happen as binary format is standard format in every system.
Please correct me if I am wrong? |
Boy, are you ever wrong.
Binary is NOT a format -- with FTP it indicates every byte is to be transferred exactly as is; the opposite is text transfer where ASCII / EBCDIC translation occurs.
A PC or Unix machine uses ASCII as its native code set and a space, for example, is hex '20'. A z/OS machine uses EBCDIC as is native code base and a space is hex '40'. If you take a z/OS text file and transfer it IN BINARY to a PC / Unix machine, the data will be completely unreadable. Yet the binary data is EXACTLY the same -- hex '40' is still hex '40'. The difference is that the PC / Unix platform does not interpret the x'40' the same way as z/OS.
Furthermore, there are variations of ASCII and EBCDIC so just specifying you want translation does NOT mean the data will look readable upon the other system. EBCDIC did not include square brackets originally, so any ASCII square brackets could not be translated correctly. And now there are multiple definitions of the square brackets in EBCDIC so whether they are converted to hex 'BA' and 'BB' or 'AD' and 'BD' will depend upon which variety of EBCDIC is being used. And using one when the other is needed causes strange characters to appear on the screen when you look at them. |
|
| Back to top |
|
|
|
|
