ALTSEQ and german special characters

In this Mainframe Forum - You can post your queries on DFSORT, ICETOOL , SyncSort & JCL Utilities

Moderators: Frank Yaeger, Moderator Group

Post Reply
hosti2011
Member
Posts: 6
Joined: Fri Sep 02, 2011 10:06 am

ALTSEQ and german special characters

Post by hosti2011 » Sun Sep 04, 2011 12:28 pm

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 :wink:

User avatar
Frank Yaeger
Moderator
Posts: 812
Joined: Sat Feb 18, 2006 5:45 am
Location: San Jose, CA
Contact:

Post by Frank Yaeger » Tue Sep 06, 2011 11:01 pm

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

hosti2011
Member
Posts: 6
Joined: Fri Sep 02, 2011 10:06 am

Post by hosti2011 » Thu Sep 08, 2011 12:59 pm

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

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

SORT STATEMENT

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)            
OUTPUT DATA

Code: Select all


BAYERN     MUNCHEN    REST
BAYERN     NURNBERG   REST
BAYERN    ?NURNBERG   REST
ÖSTERREICH           ?REST

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:

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

User avatar
Frank Yaeger
Moderator
Posts: 812
Joined: Sat Feb 18, 2006 5:45 am
Location: San Jose, CA
Contact:

Post by Frank Yaeger » Thu Sep 08, 2011 10:03 pm

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.
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

hosti2011
Member
Posts: 6
Joined: Fri Sep 02, 2011 10:06 am

again

Post by hosti2011 » Thu Sep 08, 2011 11:20 pm

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?

User avatar
Frank Yaeger
Moderator
Posts: 812
Joined: Sat Feb 18, 2006 5:45 am
Location: San Jose, CA
Contact:

Post by Frank Yaeger » Thu Sep 08, 2011 11:37 pm

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?
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

DikDude
Moderator
Posts: 1001
Joined: Fri Jul 22, 2011 8:39 am
Location: usa

Post by DikDude » Fri Sep 09, 2011 12:30 am

When posting data from a 3270 screen, use copy/paste and then "Code" the screen data. Do not do any typing - copy/paste & Code will preserve the alignment.
Have a good one

hosti2011
Member
Posts: 6
Joined: Fri Sep 02, 2011 10:06 am

Post by hosti2011 » Fri Sep 09, 2011 10:38 am

Things are working excpectet, despite of the fact that the german special characters are changed from e.g. ü to u when INREC the character fields with the TRAN=ALTSEQ CODE with the (00,40) Table.
i have tried in on an german mainframe installlation with syncsort version 1.4.

User avatar
Frank Yaeger
Moderator
Posts: 812
Joined: Sat Feb 18, 2006 5:45 am
Location: San Jose, CA
Contact:

Post by Frank Yaeger » Fri Sep 09, 2011 9:51 pm

i have tried in on an german mainframe installlation with syncsort version 1.4.
Oh, you're using Syncsort, not DFSORT. That's what you didn't tell me.

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

hosti2011
Member
Posts: 6
Joined: Fri Sep 02, 2011 10:06 am

Post by hosti2011 » Sat Sep 10, 2011 11:15 am

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.

Post Reply

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



Other References
Mainframe Tools and others