I am trying to convert a string of hexadecimal values into their relevant ascii characters.
Oconv(HexString,"MY") where HexString = "414243"
The above works fine returning ABC as expected.
Oconv(HexString,"MY") where HexString = "00414243"
This however returns nothing. I assume the 00 returns a null which triggers the whole answer to return as null. Is this correct and is there a way round it?
Use of 'MY' functionality to pack data
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
This behaviour is correct, because in C the \0 character represents "end of string". So what's being returned is a zero-length string ("") rather than NULL.
The very lowest levels of the engine are written in C.
Where are the data coming from? You ought not to be able to get a character string beginning with, or even containing, the 0x00 byte.
Try it with Iconv(TheString, "MX0C") rather than "MY". Let us know what happens.
The very lowest levels of the engine are written in C.
Where are the data coming from? You ought not to be able to get a character string beginning with, or even containing, the 0x00 byte.
Try it with Iconv(TheString, "MX0C") rather than "MY". Let us know what happens.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Thanks for the help Ray.
Using Iconv(TheString, "MX0C") rather than "MY" returns the same result.
The data is in a sense manufactured. What I was trying to do was to create a flat file to transfer to mainframe (using binary mode), parcelling up one of the fields containing signed values into pack decimal (the non pack fields protected using the EBCDIC function).
Rather than re-engineer a routine on DS I found that unpacks I thought the "MY/MX" route might be quicker.
I am looking to extract a value of format DECIMAL (13,2) from DB2 and pass it to mainframe so it can be picked up by a cobol copybook using format S9 (11) V9 (2) COMP3.
My initial thought was extract the value, say -41414142424.25, remove the sign, if the sign is '-' concat 'D' on the end else concat 'C', remove the period, insert the necessary leading zeros to create a string that would equate to seven bytes in hex (its maximum length).
This would leave me with "4141414242425D". I then apply 'MY' functionality which would hopefully return the relevant Ascii chars to match the hex bytes. This does return correctly the ascii chars 'AAABBB]'. The file can then be transferred in binary mode to mainframe.
This appears to work as long as after applying the leading zeros the value does not commence with '00' (ie -1.23 to "0000000000123D" will not return the correct ascii chars).
Does this make any sense? Apologies for the convoluted explanation!
Using Iconv(TheString, "MX0C") rather than "MY" returns the same result.
The data is in a sense manufactured. What I was trying to do was to create a flat file to transfer to mainframe (using binary mode), parcelling up one of the fields containing signed values into pack decimal (the non pack fields protected using the EBCDIC function).
Rather than re-engineer a routine on DS I found that unpacks I thought the "MY/MX" route might be quicker.
I am looking to extract a value of format DECIMAL (13,2) from DB2 and pass it to mainframe so it can be picked up by a cobol copybook using format S9 (11) V9 (2) COMP3.
My initial thought was extract the value, say -41414142424.25, remove the sign, if the sign is '-' concat 'D' on the end else concat 'C', remove the period, insert the necessary leading zeros to create a string that would equate to seven bytes in hex (its maximum length).
This would leave me with "4141414242425D". I then apply 'MY' functionality which would hopefully return the relevant Ascii chars to match the hex bytes. This does return correctly the ascii chars 'AAABBB]'. The file can then be transferred in binary mode to mainframe.
This appears to work as long as after applying the leading zeros the value does not commence with '00' (ie -1.23 to "0000000000123D" will not return the correct ascii chars).
Does this make any sense? Apologies for the convoluted explanation!