ALTSEQ and german special characters
Moderators: Frank Yaeger, Moderator Group
ALTSEQ and german special characters
Hello,
i am using dfsort to create a csv-file from a file in PL/I format.
the source file is from DB2. In some datafields there occurs hex X'00' in the pl/I file, in case of original value in the db2-table was NULL.
I want to change the x'00' into x'40'.
For this purpose i used the ALTSEQ CODE (0040) statement in combination with e.g.
OUTREC BUILD=(1:CHAR_FIELD,1,15,TRAN=ALTSEQ).
That leaded to changing all X'00' into X'40' in my PL/I -file.
But this had the effect, that all german special characters changed vom e.g.
ü to u. München --> Munchen.
How can i avoid this? I assumed it has to do something with the locale.
As i did not manage to set the locale option, i tried to set the ALTSEQ CODE to (0040,DCDC). that did preserve the ü in the ouput.
Is there an easier solution, as with this method i had to code every special character.
I hope someone could give me an advice.
kind regards from Munchen odr München
i am using dfsort to create a csv-file from a file in PL/I format.
the source file is from DB2. In some datafields there occurs hex X'00' in the pl/I file, in case of original value in the db2-table was NULL.
I want to change the x'00' into x'40'.
For this purpose i used the ALTSEQ CODE (0040) statement in combination with e.g.
OUTREC BUILD=(1:CHAR_FIELD,1,15,TRAN=ALTSEQ).
That leaded to changing all X'00' into X'40' in my PL/I -file.
But this had the effect, that all german special characters changed vom e.g.
ü to u. München --> Munchen.
How can i avoid this? I assumed it has to do something with the locale.
As i did not manage to set the locale option, i tried to set the ALTSEQ CODE to (0040,DCDC). that did preserve the ü in the ouput.
Is there an easier solution, as with this method i had to code every special character.
I hope someone could give me an advice.
kind regards from Munchen odr München
- Frank Yaeger
- Moderator
- Posts: 812
- Joined: Sat Feb 18, 2006 5:45 am
- Location: San Jose, CA
- Contact:
1,15,TRAN=ALTSEQ with ALTSEQ CODE=(0040) will change any X'00' byte in positions 1-15 to a X'40' byte. I don't see how that has anything to do with the LOCALE or how it would change anything else unless it has a X'00' in it. For single-byte characters, that wouldn't make sense. So I can't really help you unless you show me your complete job and more importantly - what was originally in those 15 bytes (in hex) and what it got changed to (in hex) that you're trying to avoid.
Frank Yaeger - DFSORT Development Team (IBM) - yaeger@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Hello Frank,
thank you for your reply.
Here are the details of my Problem.
I insist to change low values in the input file to blanks, as in the input file there exist low values in char-fields from the unload from DB2, in case of nullvalues.
INPUT DATA
SORT STATEMENT
OUTPUT DATA
The Problem is, that in the second char field the german special ü is changed tos u, when i use the TRAN=ALTSEQ clause, in order to change low values to blanks.
With setting the ALTSEQ TABLE to ALTSEQ CODE=(0040,5A5A) the following output is the result:
the german special ü is now prevented.
Do you have an idea about this curious (for me) effect.
Kind regards
thank you for your reply.
Here are the details of my Problem.
I insist to change low values in the input file to blanks, as in the input file there exist low values in char-fields from the unload from DB2, in case of nullvalues.
INPUT DATA
Code: Select all
BAYERN MÜNCHEN REST
CCECDD44440D5DCCCD44400000D
218595000004A53855000000009
---------------------------
BAYERN NÜRNBERG REST
CCECDD44440D5DDCCDC4400000D
218595000005A95259700000009
---------------------------
BAYERN ?NÜRNBERG REST
CCECDD44446D5DDCCDC4400000D
2185950000F5A95259700000009
---------------------------
ÖSTERREICH ? REST
EEECDDCCCC0000000000060000D
023599593800000000000F00009
Code: Select all
//SYMNAMES DD *
POSITION,1
STR1,*,10,CH
IND1,*,01,CH
STR2,*,10,CH
IND2,*,01,CH
NUM1,*,04,BI
REST,*,54,CH
//SYSIN DD *
OPTION COPY
ALTSEQ CODE=(0040)
INREC BUILD(STR1,
IND1,
STR2,TRAN=ALTSEQ,
IND2,
REST)
Code: Select all
BAYERN MUNCHEN REST
BAYERN NURNBERG REST
BAYERN ?NURNBERG REST
ÖSTERREICH ?REST
With setting the ALTSEQ TABLE to ALTSEQ CODE=(0040,5A5A) the following output is the result:
Code: Select all
BAYERN .MÜNCHEN .REST
BAYERN .NÜRNBERG .REST
BAYERN ?NÜRNBERG .REST
ÖSTERREICH. ?REST
the german special ü is now prevented.
Do you have an idea about this curious (for me) effect.
Kind regards
- Frank Yaeger
- Moderator
- Posts: 812
- Joined: Sat Feb 18, 2006 5:45 am
- Location: San Jose, CA
- Contact:
Something does NOT add up here. I ran your job with your data as FB input records and the X'5A' characters were NOT changed. In fact, since you are using 12,10,TRAN=ALTSEQ and positions 12-21 in your input records DO NOT have any X'00' characters, nothing is changed. TRAN=ALTSEQ will NOT do what you say it's doing if used with the correct positions.
So there's something you're not telling me (perhaps you're not aware of it). I suspect that your input file has RECFM=VB, not RECFM=FB, so the first data position is 5 (after the RDW) rather than 1 and you need to adjust your job accordingly. If you can confirm to me that your input file has RECFM=VB, I will show you how to do what you want to do.
If that's not the problem, then there's something else you're not telling me and I can't guess what it is. So you'd need to tell me the RECFM and LRECL of your input file, show the input and output in hex, and the complete JES log for the run.
So there's something you're not telling me (perhaps you're not aware of it). I suspect that your input file has RECFM=VB, not RECFM=FB, so the first data position is 5 (after the RDW) rather than 1 and you need to adjust your job accordingly. If you can confirm to me that your input file has RECFM=VB, I will show you how to do what you want to do.
If that's not the problem, then there's something else you're not telling me and I can't guess what it is. So you'd need to tell me the RECFM and LRECL of your input file, show the input and output in hex, and the complete JES log for the run.
Frank Yaeger - DFSORT Development Team (IBM) - yaeger@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
again
sorry for the misunderstandable files.
i had problems to paste them correct into the message.
the input file was FB 80. same as the output.
and in the output file the hex 00 in the records with beginning österreich are changed to blanks, as it is considered.
is there a way to implement screenshots as upload?
i had problems to paste them correct into the message.
the input file was FB 80. same as the output.
and in the output file the hex 00 in the records with beginning österreich are changed to blanks, as it is considered.
is there a way to implement screenshots as upload?
- Frank Yaeger
- Moderator
- Posts: 812
- Joined: Sat Feb 18, 2006 5:45 am
- Location: San Jose, CA
- Contact:
Screenshots are NOT a good idea. Hex with code tags is fine.
So are you saying things are working as expected or not working as expected?
Where are we on this exactly?
So are you saying things are working as expected or not working as expected?
Where are we on this exactly?
Frank Yaeger - DFSORT Development Team (IBM) - yaeger@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
- Frank Yaeger
- Moderator
- Posts: 812
- Joined: Sat Feb 18, 2006 5:45 am
- Location: San Jose, CA
- Contact:
Oh, you're using Syncsort, not DFSORT. That's what you didn't tell me.i have tried in on an german mainframe installlation with syncsort version 1.4.
I believe Syncsort applies the ALTSEQ statement changes to the installation default ALTSEQ table, so if your site changed that table, you would get the changes from that table plus the ALTSEQ statement changes, e.g. if your site used ALTSEQ=(C1F1) for the installation default, and you used ALTSEQ CODE=(C2F2), you would get the equivalent of CODE=(C1F1,C2F2).
DFSORT applies the ALTSEQ statement changes to the EBCDIC ALTSEQ table. So with the same scenario, ALTSEQ=(C1F1) would give you the equivalent of ALTSEQ=(C1F1) as you would expect.
So it's Syncsort's method of processing the ALTSEQ statement that is causing the problem you see.
At any rate, I'm a DFSORT developer. DFSORT and Syncsort are competitive products. I'm happy to answer questions on DFSORT and DFSORT's ICETOOL, but I don't answer questions on Syncsort.
Frank Yaeger - DFSORT Development Team (IBM) - yaeger@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Hello Frank,
with your infos i understand the behaviour of the job. now i have to contact
the syncsort support or ask for the installation defaults of the running syncsort version.
meanwhile i have to do the workaround with setting each german special character manually in the altseq table.
thank you for your efforts.
with your infos i understand the behaviour of the job. now i have to contact
the syncsort support or ask for the installation defaults of the running syncsort version.
meanwhile i have to do the workaround with setting each german special character manually in the altseq table.
thank you for your efforts.
FREE TUTORIALS
Tutorials
Free tutorials from mainframegurukul
- JCL Tutorial
Covers all important JCL concepts. - Cobol Tutorial
This tutorials covers all Cobol Topics from STRING to COMP-3. - DB2 Tutorial
DB2 Tutorial focuses on DB2 COBOL Programming. - SORT Tutorial
This Tutorial covers all important aspects of DFSORT with examples - CICS Tutorial
This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions
- Cobol Interview Questions
50+ Interview Questions - JCL Interview Questions
50+ Interview Questions - DB2 Interview Questions
100+ Interview Questions - CICS Interview Questions
70+ Interview Questions - VSAM Interview Questions
27 Interview Questions
Other References
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program - FILEAID Reference
Explains how to browse , edit and delete datasets - Change Man Reference
Quick Start tutorial on Changeman - Abend Reference
Important Abend codes explained - FaceBook Page
MainframeGurukul FaceBook Page - LinkedIn Page
MainframeGurkul Linkedin Page