Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

OPEN DATASET error in Binary Mode in Unicode system

Former Member
0 Likes
1,799

Hi Experts,

We have done technical upgrade from 4.7 to ECC 6.0 version. We have a problem with the OPEN DATASET statement. In the 4.7 version of the code, the statement OPEN DATASET in BINARY mode was used to write the file. Now in ECC 6.0 system, as it is unicode enabled is altering the output. The ouput is altered becaused of the insertion of space between each character in the output. i know i can use statements like OPEN DATASET in TEXT mode ENCODING DEFAULT. But the requiement is to get the file in the same format (BINARY format) w/o altering the output as was in the 4.7 system. I have changed the code as OPEN DATASET in LEGACY BINAY mode. Can anyone confirm if this is the correct way of getting the output in BINARY format. If not, can you suggest an appropriate alternative.

Thanks!

Rupesh

rupesh_nitk

Posts: 1

Joined: July 22nd, 2010, 8:44 pm

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,043

Based on your comments it sounds to me that you actually had more like a text file in 4.7 than a binary file. I.e. I'm thinking for example of a flat file with fixed length records: In such a file you would still have text information (encoded probably with the default code page from your SAP system), yet you would have more control over what data should be written (no automated newline handling).

With your release upgrade to ECC 6.0 you probably also Unicode-enabled the system. On the application server all data is stored in [UTF-16|http://help.sap.com/abapdocu_70/en/ABENUNICODE_SYSTEM_GLOSRY.htm] and thus each character occupies 2 bytes. For some alternatives on how to do code page conversions you can check out the [wiki entry on character coding conversion|http://wiki.sdn.sap.com/wiki/display/ABAP/Characterencodingconversion].

<div style="text-align:left">Can anyone confirm if this is the correct way of getting the output in BINARY format.</div>

Nobody can answer this question. What you have to do is figure out which format and encoding should be used for the file and then adapt your coding to write the correct format. Obviously this doesn't necessarily have to be the same encoding as you had before. I.e. your SAP application server also changed from non-Unicode to Unicode, so it's possible that trying to produce the exact same file format/encoding as you had before is also not the right approach... (admitted most likely it is, but it's always better to evaluate such things).

3 REPLIES 3
Read only

Former Member
0 Likes
1,044

Based on your comments it sounds to me that you actually had more like a text file in 4.7 than a binary file. I.e. I'm thinking for example of a flat file with fixed length records: In such a file you would still have text information (encoded probably with the default code page from your SAP system), yet you would have more control over what data should be written (no automated newline handling).

With your release upgrade to ECC 6.0 you probably also Unicode-enabled the system. On the application server all data is stored in [UTF-16|http://help.sap.com/abapdocu_70/en/ABENUNICODE_SYSTEM_GLOSRY.htm] and thus each character occupies 2 bytes. For some alternatives on how to do code page conversions you can check out the [wiki entry on character coding conversion|http://wiki.sdn.sap.com/wiki/display/ABAP/Characterencodingconversion].

<div style="text-align:left">Can anyone confirm if this is the correct way of getting the output in BINARY format.</div>

Nobody can answer this question. What you have to do is figure out which format and encoding should be used for the file and then adapt your coding to write the correct format. Obviously this doesn't necessarily have to be the same encoding as you had before. I.e. your SAP application server also changed from non-Unicode to Unicode, so it's possible that trying to produce the exact same file format/encoding as you had before is also not the right approach... (admitted most likely it is, but it's always better to evaluate such things).

Read only

Former Member
0 Likes
1,043

Thanks!

It was solved using the same solution i discussed with you all.

Regards,

Rupesh

Read only

Former Member
0 Likes
1,043

Closing this thread.