special character conversion

[sunilorg]

Hi,
I have a requirement to convert some spanish characters to english equivalent and i am using lib$movtc RTL function to accomplish this. But for some reason i am able to convert characters till the ascii value of 127 and beyond that its not working. Any help in this regard would be greatly appreciated.

[Hein van den Heuvel]

LIB$MOVTC works. Period. Case closed.
If it does not appear to work for you, then it is used incorrectly.

What translation table did you provide it?
What condition value does your call return?
Did you declare all variables properly? (Unsigned chars?!)
Why not provide a (short!) example as attachment to a reply, because there is literally nothing in the description so far what would allow us to help you.

Regards,
Hein.

[sunilorg]

HI Hein,

Thanks for your quick response. I am attaching the sample program. The program has been written in such a way that if the input is in lower case then it should convert to uppercase and this is working fine. Then i have some spanish characters where teh ascii values are 157, 158 etc and for these ascii values i am not getting the required output.Any help in this regard would be highly appreciated
Regards,
Sunny

[Hein van den Heuvel]

Cobol! Co(b)ol!
The table definition is broken.
It is also confusingly defined.
Maybe just sticking to the X(16) value throughout is more clear.

Here is how I tested, after changing the 35 byte buffer to 255 byte in the program:

$ pipe perl -e "print chr($_) for (32..255)" | run tmp > z.tmp
$ dump/recod z.tmp

Or broken into two parts, and the data edited to remove the hex from the dump:

$ defin/use sys$input x.tmp
$ defin/use sys$output y.tmp
$ run tmp
$ dump/reco x.tmp
$ dump/reco y.tmp

Dump of file X.TMP;
Record number 1

!"#$%&'()*+,-./ 000000
0123456789:;<=>? 000010
@ABCDEFGHIJKLMNO 000020
PQRSTUVWXYZ[\]^_ 000030
`abcdefghijklmno 000040
pqrstuvwxyz{|}~. 000050
................ 000060
................ 000070
.¡¢£¤¥¦§¨©ª«¬­®¯ 000080
°±²³´µ¶·¸¹º»¼½¾¿ 000090
à à à à à à à à à à à à à à à à 0000A0
à à à à à à à à à à à à à à à à 0000B0
àáâãäåæçèéêëìíîï 0000C0
ðñòóôõö÷øùúûüýþ. 0000D0
$

Dump of file Y.TMP
Record number 1
Name: .......... 000000

Record number 2
000000
0123456789 000010
ABCDEFGHIJKLMNO 000020
PQRSTUVWXYZ 000030
ABCDEFGHIJKLMNO 000040
PQRSTUVWXYZ 000050
A 000060
S n 000070
D ¥ 000080
F 000090
G 0000A0
HÃ 0000B0
J 0000C0
K 0000D0
0000E0
. 0000F0


If you do not have perl, then you can of course create this x.tmp with dcl.
Something like:

$i=0
$loop:
$x[i*8,8]=i+32
$i=i+1
$if i.lt.(265-32) then goto loop
$open/write x x.tmp
$write/symb x x
$close x

Good luck!
Hein.

[Hein van den Heuvel]

Hmm,

The forum ate my homework.
I should have asked "retain format", but the funny characters would still mess it up.
So I'll attach a txt file with the dumps.

My conclusing from the experiment is that LIB$MOVTC did exactly what you told it to do.

And it 'looks' like that is what you wanted it to do. More descriptive names for the 16 byte chunks might have helped.
Anyway, Please explain where, why, you expect a different translation?!

also... the 265 in the DCL alternative test data generater should of course be 256 (2**8).

And the dump shows 255 bytes, because that is how big I made the buffer in the cobol example.

Hein.

[sunilorg]

Hein,

Thank you. Probably i am asking a stupid question but excuse me. Below is a simple program which i wrote and my requirement is to convert the special characters like ¥ whose ascii value is 157 to english equivalent like N. But i get a space when i run the program. Is there any other way to handle these type of special characters.

IDENTIFICATION DIVISION.
PROGRAM-ID. TSTMOV.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.

01 WS-SOURCE-NAME PIC X(35).
01 WS-DEST-NAME PIC X(35).
01 FILL-CHAR PIC X VALUE "@".

01 TX-TABLE.
05 FILLER PIC X(16) VALUE " ".
05 FILLER PIC X(16) VALUE " ".
05 FILLER PIC X(16) VALUE " ".
05 FILLER PIC X(16) VALUE "0123456789 ".
05 FILLER PIC X(16) VALUE " ABCDEFGHIJKLMNO".
05 FILLER PIC X(16) VALUE "PQRSTUVWXYZ ".
05 FILLER PIC X(16) VALUE " ABCDEFGHIJKLMNO".
05 FILLER PIC X(16) VALUE "PQRSTUVWXYZ ".
05 FILLER PIC X(16) VALUE "$$$$$$$$$$$$ ".
05 FILLER PIC X(16) VALUE "%%%%%%%%%%%% ".

PROCEDURE DIVISION.
PGM-BEGIN.

DISPLAY "Name: " NO ADVANCING.
ACCEPT WS-SOURCE-NAME.
display ws-source-name.
CALL 'LIB$MOVTC' USING BY DESCRIPTOR WS-SOURCE-NAME,
FILL-CHAR,
TX-TABLE,
WS-DEST-NAME.
DISPLAY "WS-DEST-NAME", WS-DEST-NAME.
STOP RUN.

[Hein van den Heuvel]

Well, if I use the $$$ and %%% from the last example, and expand then to 16 characters each, then I get % returned for character 157 as expected.

Maybe you are NOT using a 8 bit character set, but a 7 bit extended?

Maybe you are using the "SPANISH 7-bit NRC set" (National Replacement Characters"

See for example the table in:
http://vt100.net/dec/ek-vt240-hr-002.pdf
(brings back memories :-)

Did you try with my test data which can prove the byte values?

When you write those 'funny characters', the expexted byte value 157 adn DUMP/RECORD that, then do you see byte value "9D" ?

Or in cobol... move the byte to a comp and 'display with conversion' to see the decimal. Be sure to verify with simple text first ("0" or "A" :-)

Cheers,
Hein.

http://www.lookuptables.com/