Dear Tandem geeks,
    I am having tough time using this API and I am getting "Illegal
address reference". Has any one succesfully used this API to convert
to native Tandem Kanji. Any help appreciated.

Thanks in advance.
Best Regards
Robo

Robo wrote:
> Dear Tandem geeks,
>     I am having tough time using this API and I am getting "Illegal
> address reference". Has any one succesfully used this API to convert
> to native Tandem Kanji. Any help appreciated.
> 
> Thanks in advance.
> Best Regards
> Robo

I have not used the MBCS routines, but I have lots of experience with the Tandem system.  If you show me the parts of the code where the call of MBCS_EXTERNAL_TO_TANDEM_ is and where the variables passed in the call are declared and set up, I have a feeling I could spot the problem, or at least tell you the most likely things to check.

I assume you are using C (you really should have said what language you are using), but I can help you whatever language you are using.

I took a quick look at the documentation for MBCS_EXTERNAL_TO_TANDEM_, and I see that the first two arguments are pointers to pointers, but the function prototype isn't declared that way.  (TAL doesn't have a way to declare pointers to pointers, and I guess the automatic tool used to produce the C headers from the TAL headers has no clue when the arguments really are pointers to pointer.)

So setting up those two arguments seems to me like the most likely thing you could have done wrong.  Make sure you show me how those two arguments are set up if you send me the code.  Or maybe if you just look over your code again with that thought in mind, you might find the problem yourself.

On Dec 2, 10:43=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> Robo wrote:
> > Dear Tandem geeks,
> > =A0 =A0 I am having tough time using this API and I am getting "Illegal
> > address reference". Has any one succesfully used this API to convert
> > to native Tandem Kanji. Any help appreciated.
>
> > Thanks in advance.
> > Best Regards
> > Robo
>
> I have not used the MBCS routines, but I have lots of experience with the=
 Tandem system. =A0If you show me the parts of the code where the call of M=
BCS_EXTERNAL_TO_TANDEM_ is and where the variables passed in the call are d=
eclared and set up, I have a feeling I could spot the problem, or at least =
tell you the most likely things to check.
>
> I assume you are using C (you really should have said what language you a=
re using), but I can help you whatever language you are using.
>
> I took a quick look at the documentation for MBCS_EXTERNAL_TO_TANDEM_, an=
d I see that the first two arguments are pointers to pointers, but the func=
tion prototype isn't declared that way. =A0(TAL doesn't have a way to decla=
re pointers to pointers, and I guess the automatic tool used to produce the=
 C headers from the TAL headers has no clue when the arguments really are p=
ointers to pointer.)
>
> So setting up those two arguments seems to me like the most likely thing =
you could have done wrong. =A0Make sure you show me how those two arguments=
 are set up if you send me the code. =A0Or maybe if you just look over your=
 code again with that thought in mind, you might find the problem yourself.

Keith,
   My apologies for not providing enough information. I am using C and
my OS is G06.32.
1) I am reading data from a SQL table which has one field defined as
VARCHAR(200) DEFAULT SYSTEM NOT NULL which contains Kanji character
transmitted from a Oracle database.
2) Hex value of the data looks same on both Oracle and SQL/MP however
when I change the display to Japanese (using windows Regional and
Language option) they don't look same and I believe this is due to
Tandem's internal representation of double byte characters.
3) I wrote a small program to test if I can convert data into Tandem=92s
internal format using this API. Here is what my code looks like

short error, sqlcode;
short length=3D200;
short max_length=3D200;
short fin_length=3D0;
char  to_convert[201];
char  converted[201];

 error =3D MBCS_EXTERNAL_TO_TANDEM_((long *) to_convert, (long *)
converted,
                                  length,&max_length,1,8);

If I pass the next argument to this API (short *finished-length), it
always abend. If I don't use this parameter than it doesn't abend.
After executing this instruction the converted array is all blank. I
have tried using different ways of using pointers (as far as my
knowledge goes) and also used different conversion options on this API
but it always comes back blank.

Regards
Robo

Robo wrote:
> On Dec 2, 10:43 pm, Keith Dick <KeithD...@earthlink.net> wrote:
> 
>>Robo wrote:
>>
>>>Dear Tandem geeks,
>>>    I am having tough time using this API and I am getting "Illegal
>>>address reference". Has any one succesfully used this API to convert
>>>to native Tandem Kanji. Any help appreciated.
>>
>>>Thanks in advance.
>>>Best Regards
>>>Robo
>>
>>I have not used the MBCS routines, but I have lots of experience with the Tandem system.  If you show me the parts of the code where the call of MBCS_EXTERNAL_TO_TANDEM_ is and where the variables passed in the call are declared and set up, I have a feeling I could spot the problem, or at least tell you the most likely things to check.
>>
>>I assume you are using C (you really should have said what language you are using), but I can help you whatever language you are using.
>>
>>I took a quick look at the documentation for MBCS_EXTERNAL_TO_TANDEM_, and I see that the first two arguments are pointers to pointers, but the function prototype isn't declared that way.  (TAL doesn't have a way to declare pointers to pointers, and I guess the automatic tool used to produce the C headers from the TAL headers has no clue when the arguments really are pointers to pointer.)
>>
>>So setting up those two arguments seems to me like the most likely thing you could have done wrong.  Make sure you show me how those two arguments are set up if you send me the code.  Or maybe if you just look over your code again with that thought in mind, you might find the problem yourself.
> 
> 
> Keith,
>    My apologies for not providing enough information. I am using C and
> my OS is G06.32.
> 1) I am reading data from a SQL table which has one field defined as
> VARCHAR(200) DEFAULT SYSTEM NOT NULL which contains Kanji character
> transmitted from a Oracle database.
> 2) Hex value of the data looks same on both Oracle and SQL/MP however
> when I change the display to Japanese (using windows Regional and
> Language option) they don't look same and I believe this is due to
> Tandem's internal representation of double byte characters.
> 3) I wrote a small program to test if I can convert data into Tandem�s
> internal format using this API. Here is what my code looks like
> 
> short error, sqlcode;
> short length=200;
> short max_length=200;
> short fin_length=0;
> char  to_convert[201];
> char  converted[201];
> 
>  error = MBCS_EXTERNAL_TO_TANDEM_((long *) to_convert, (long *)
> converted,
>                                   length,&max_length,1,8);
> 
> If I pass the next argument to this API (short *finished-length), it
> always abend. If I don't use this parameter than it doesn't abend.
> After executing this instruction the converted array is all blank. I
> have tried using different ways of using pointers (as far as my
> knowledge goes) and also used different conversion options on this API
> but it always comes back blank.
> 
> Regards
> Robo

Well, that is better information than you had in your first question, but it would have helped a little more had you shown exactly how the program looked when you passed the finished-length parameter in the call.  I'll give you some things to check and see how far we can get to solving the problem.

I notice that the C prototype printed in the Guardian Procedure Calls Reference manual seems to be incorrect.  It describes that parameter as 

   short finished-length 

but that doesn't make sense because that is a parameter in which a result is returned, so it should be a pointer.  I see that the TAL description says that parameter is INT .EXT:ref:1, which is a pointer to a 16-bit integer, so the C prototype should say 

   short *finished-length

When I check the description in the Guardian Programming Reference Summary for C, that parameter is described correctly, so it probably is only a mistake in the first manual.  But it would be good to check that, the prototype in CEXTDECS is correct.  Open the CEXTDECS file that you are using with your favourite editor, find the prototype for MBCS_EXTERNAL_TO_TANDEM_, and check to see whether the finished-length argument contains the * or not.  If it does contain the *, that's good.  If it does not contain the * you could try making a copy of CEXTDECS, correcting that mistake, and changing your program to #include the corrected CEXTDECS (and report the mistaken prototype to GCSC).

I believe the program that uses the finished-length parameter should look something like this:

short error, sqlcode;
short length=200;
short max_length=200;
short fin_length=0;
char  to_convert[201];
char  converted[201];

 error = MBCS_EXTERNAL_TO_TANDEM_((long *) to_convert, 
                                  (long *) converted,
                                  length, &max_length, 1, 8,
                                  &fin_length);

I'm making a guess that when you tried to use the finished-length parameter, you did not include the &, and that would result in a bad address being passed for that parameter.  I would expect that you would have gotten a compiler warning if you did that and the prototype was correct, but maybe not.

So I think correcting the above would get rid of the illegal address reference, assuming that it was the finished-length parameter that was the bad address.  But I think that is not likely to fix the problem that you are seeing blanks in the converted array.

The documentation for the first two parameters says they are supposed to be pointers to 32-bit integers which are to contain the addresses of the actual data buffers.  In other works, pointers to pointers.  I imagine those parameters are declared that way rather than as char **, as you would expect for a C function, because they were originally done in TAL, and TAL does not have a way to declare double pointers.  I imagine that CEXTDECS is generated by a program from the TAL declarations, so the cases that need pointers to pointers end up being declared as a C version of the TAL circumlocution for that.  Unfortunate, but we have to work with that.

I am not certain, but I am pretty sure that casting the array name to (long *) will not get the double pointer that you need.  When you use the array name, that is taken to be a pointer to the first element of the array, in this case it would be a (char *).  I think that the (long *) cast just tells the compiler that it is okay to take that (char *) to be acceptable as the (long *) argument.  So I believe what is being passed is pointers to the start of each array, not pointers to pointers to the start of the arrays.  

Actually, I am a bit surprised that you don't get an illegal address reference due to this.  If the MBCS_EXTERNAL_TO_TANDEM_ function really is expecting a pointer to a pointer in those parameters, I think it would try to use the first two bytes of your character buffers as pointers, and using character data as pointers usually gets a bad address.  You did not mention whether you checked the return value from the function call.  Perhaps it is finding something wrong and returning an error code before it attempts to use either of the character buffers.

There may be a prettier way to fix the problem, but this is the simplest way I can think of:

short error, sqlcode;
short length=200;
short max_length=200;
short fin_length=0;
char  to_convert[201];
char  converted[201];
long  to_convert_ptr;
long  converted_ptr;

 to_convert_ptr = (long) &to_convert[0];
 converted_ptr  = (long) &converted[0];
 error = MBCS_EXTERNAL_TO_TANDEM_(&to_convert_ptr, 
                                  &converted_ptr,
                                  length, &max_length, 1, 8);

Note that if you need to use the updated pointers that the function returns, you'll have to copy them from to_convert_ptr and converted_ptr into proper pointers.

I have a vague memory of seeing a manual about using the MBCS routines sometime long ago, but I searched a bit through the current manuals list, and I could not find one for them.  Maybe my memory is playing tricks on me.

I never have done any work that involved displaying multibyte characters, so I don't know what typically has to be done to get that working.  I hope this is enough to completely solve your problem.  If you still cannot get your data to display correctly, post again with more details, and I hope someone with more experience with that can answer.

On Dec 3, 1:55=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> Robo wrote:
> > On Dec 2, 10:43 pm, Keith Dick <KeithD...@earthlink.net> wrote:
>
> >>Robo wrote:
>
> >>>Dear Tandem geeks,
> >>> =A0 =A0I am having tough time using this API and I am getting "Illega=
l
> >>>address reference". Has any one succesfully used this API to convert
> >>>to native Tandem Kanji. Any help appreciated.
>
> >>>Thanks in advance.
> >>>Best Regards
> >>>Robo
>
> >>I have not used the MBCS routines, but I have lots of experience with t=
he Tandem system. =A0If you show me the parts of the code where the call of=
 MBCS_EXTERNAL_TO_TANDEM_ is and where the variables passed in the call are=
 declared and set up, I have a feeling I could spot the problem, or at leas=
t tell you the most likely things to check.
>
> >>I assume you are using C (you really should have said what language you=
 are using), but I can help you whatever language you are using.
>
> >>I took a quick look at the documentation for MBCS_EXTERNAL_TO_TANDEM_, =
and I see that the first two arguments are pointers to pointers, but the fu=
nction prototype isn't declared that way. =A0(TAL doesn't have a way to dec=
lare pointers to pointers, and I guess the automatic tool used to produce t=
he C headers from the TAL headers has no clue when the arguments really are=
 pointers to pointer.)
>
> >>So setting up those two arguments seems to me like the most likely thin=
g you could have done wrong. =A0Make sure you show me how those two argumen=
ts are set up if you send me the code. =A0Or maybe if you just look over yo=
ur code again with that thought in mind, you might find the problem yoursel=
f.
>
> > Keith,
> > =A0 =A0My apologies for not providing enough information. I am using C =
and
> > my OS is G06.32.
> > 1) I am reading data from a SQL table which has one field defined as
> > VARCHAR(200) DEFAULT SYSTEM NOT NULL which contains Kanji character
> > transmitted from a Oracle database.
> > 2) Hex value of the data looks same on both Oracle and SQL/MP however
> > when I change the display to Japanese (using windows Regional and
> > Language option) they don't look same and I believe this is due to
> > Tandem's internal representation of double byte characters.
> > 3) I wrote a small program to test if I can convert data into Tandem=92=
s
> > internal format using this API. Here is what my code looks like
>
> > short error, sqlcode;
> > short length=3D200;
> > short max_length=3D200;
> > short fin_length=3D0;
> > char =A0to_convert[201];
> > char =A0converted[201];
>
> > =A0error =3D MBCS_EXTERNAL_TO_TANDEM_((long *) to_convert, (long *)
> > converted,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 len=
gth,&max_length,1,8);
>
> > If I pass the next argument to this API (short *finished-length), it
> > always abend. If I don't use this parameter than it doesn't abend.
> > After executing this instruction the converted array is all blank. I
> > have tried using different ways of using pointers (as far as my
> > knowledge goes) and also used different conversion options on this API
> > but it always comes back blank.
>
> > Regards
> > Robo
>
> Well, that is better information than you had in your first question, but=
 it would have helped a little more had you shown exactly how the program l=
ooked when you passed the finished-length parameter in the call. =A0I'll gi=
ve you some things to check and see how far we can get to solving the probl=
em.
>
> I notice that the C prototype printed in the Guardian Procedure Calls Ref=
erence manual seems to be incorrect. =A0It describes that parameter as
>
> =A0 =A0short finished-length
>
> but that doesn't make sense because that is a parameter in which a result=
 is returned, so it should be a pointer. =A0I see that the TAL description =
says that parameter is INT .EXT:ref:1, which is a pointer to a 16-bit integ=
er, so the C prototype should say
>
> =A0 =A0short *finished-length
>
> When I check the description in the Guardian Programming Reference Summar=
y for C, that parameter is described correctly, so it probably is only a mi=
stake in the first manual. =A0But it would be good to check that, the proto=
type in CEXTDECS is correct. =A0Open the CEXTDECS file that you are using w=
ith your favourite editor, find the prototype for MBCS_EXTERNAL_TO_TANDEM_,=
 and check to see whether the finished-length argument contains the * or no=
t. =A0If it does contain the *, that's good. =A0If it does not contain the =
* you could try making a copy of CEXTDECS, correcting that mistake, and cha=
nging your program to #include the corrected CEXTDECS (and report the mista=
ken prototype to GCSC).
>
> I believe the program that uses the finished-length parameter should look=
 something like this:
>
> short error, sqlcode;
> short length=3D200;
> short max_length=3D200;
> short fin_length=3D0;
> char =A0to_convert[201];
> char =A0converted[201];
>
> =A0error =3D MBCS_EXTERNAL_TO_TANDEM_((long *) to_convert,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (long=
 *) converted,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lengt=
h, &max_length, 1, 8,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &fin_=
length);
>
> I'm making a guess that when you tried to use the finished-length paramet=
er, you did not include the &, and that would result in a bad address being=
 passed for that parameter. =A0I would expect that you would have gotten a =
compiler warning if you did that and the prototype was correct, but maybe n=
ot.
>
> So I think correcting the above would get rid of the illegal address refe=
rence, assuming that it was the finished-length parameter that was the bad =
address. =A0But I think that is not likely to fix the problem that you are =
seeing blanks in the converted array.
>
> The documentation for the first two parameters says they are supposed to =
be pointers to 32-bit integers which are to contain the addresses of the ac=
tual data buffers. =A0In other works, pointers to pointers. =A0I imagine th=
ose parameters are declared that way rather than as char **, as you would e=
xpect for a C function, because they were originally done in TAL, and TAL d=
oes not have a way to declare double pointers. =A0I imagine that CEXTDECS i=
s generated by a program from the TAL declarations, so the cases that need =
pointers to pointers end up being declared as a C version of the TAL circum=
locution for that. =A0Unfortunate, but we have to work with that.
>
> I am not certain, but I am pretty sure that casting the array name to (lo=
ng *) will not get the double pointer that you need. =A0When you use the ar=
ray name, that is taken to be a pointer to the first element of the array, =
in this case it would be a (char *). =A0I think that the (long *) cast just=
 tells the compiler that it is okay to take that (char *) to be acceptable =
as the (long *) argument. =A0So I believe what is being passed is pointers =
to the start of each array, not pointers to pointers to the start of the ar=
rays. =A0
>
> Actually, I am a bit surprised that you don't get an illegal address refe=
rence due to this. =A0If the MBCS_EXTERNAL_TO_TANDEM_ function really is ex=
pecting a pointer to a pointer in those parameters, I think it would try to=
 use the first two bytes of your character buffers as pointers, and using c=
haracter data as pointers usually gets a bad address. =A0You did not mentio=
n whether you checked the return value from the function call. =A0Perhaps i=
t is finding something wrong and returning an error code before it attempts=
 to use either of the character buffers.
>
> There may be a prettier way to fix the problem, but this is the simplest =
way I can think of:
>
> short error, sqlcode;
> short length=3D200;
> short max_length=3D200;
> short fin_length=3D0;
> char =A0to_convert[201];
> char =A0converted[201];
> long =A0to_convert_ptr;
> long =A0converted_ptr;
>
> =A0to_convert_ptr =3D (long) &to_convert[0];
> =A0converted_ptr =A0=3D (long) &converted[0];
> =A0error =3D MBCS_EXTERNAL_TO_TANDEM_(&to_convert_ptr,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &conv=
erted_ptr,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 lengt=
h, &max_length, 1, 8);
>
> Note that if you need to use the updated pointers that the function retur=
ns, you'll have to copy them from to_convert_ptr and converted_ptr into pro=
per pointers.
>
> I have a vague memory of seeing a manual about using the MBCS routines so=
metime long ago, but I searched a bit through the current manuals list, and=
 I could not find one for them. =A0Maybe my memory is playing tricks on me.
>
> I never have done any work that involved displaying multibyte characters,=
 so I don't know what typically has to be done to get that working. =A0I ho=
pe this is enough to completely solve your problem. =A0If you still cannot =
get your data to display correctly, post again with more details, and I hop=
e someone with more experience with that can answer.

Your doing great so far - hope this helps!

From CEXTDECS:

_tal _extensible short MBCS_EXTERNAL_TO_TANDEM_ (
    __int32_t _far *,   /* IN/OUT OPTIONAL  */
    __int32_t _far *,   /* IN/OUT OPTIONAL  */
    short ,             /* IN  */
    short _far *,       /* IN/OUT  */
    short ,             /* IN OPTIONAL  */
    short ,             /* IN  */
    short _far *,       /* OUT OPTIONAL  */
    char _far *,        /* IN OPTIONAL  */
    char _far *         /* IN OPTIONAL  */
    );

mustlearntandem wrote:
> <snip>
> 
> 
> Your doing great so far - hope this helps!
> 
> From CEXTDECS:
> 
> _tal _extensible short MBCS_EXTERNAL_TO_TANDEM_ (
>     __int32_t _far *,   /* IN/OUT OPTIONAL  */
>     __int32_t _far *,   /* IN/OUT OPTIONAL  */
>     short ,             /* IN  */
>     short _far *,       /* IN/OUT  */
>     short ,             /* IN OPTIONAL  */
>     short ,             /* IN  */
>     short _far *,       /* OUT OPTIONAL  */
>     char _far *,        /* IN OPTIONAL  */
>     char _far *         /* IN OPTIONAL  */
>     );

Thanks for posting that.  The finished-length argument is properly described in CEXTDECS, so Robo does not have to check that.

On Dec 3, 5:34=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> mustlearntandem wrote:
> > <snip>
>
> > Your doing great so far - hope this helps!
>
> > From CEXTDECS:
>
> > _tal _extensible short MBCS_EXTERNAL_TO_TANDEM_ (
> > =A0 =A0 __int32_t _far *, =A0 /* IN/OUT OPTIONAL =A0*/
> > =A0 =A0 __int32_t _far *, =A0 /* IN/OUT OPTIONAL =A0*/
> > =A0 =A0 short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN =A0*/
> > =A0 =A0 short _far *, =A0 =A0 =A0 /* IN/OUT =A0*/
> > =A0 =A0 short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN OPTIONAL =A0*/
> > =A0 =A0 short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN =A0*/
> > =A0 =A0 short _far *, =A0 =A0 =A0 /* OUT OPTIONAL =A0*/
> > =A0 =A0 char _far *, =A0 =A0 =A0 =A0/* IN OPTIONAL =A0*/
> > =A0 =A0 char _far * =A0 =A0 =A0 =A0 /* IN OPTIONAL =A0*/
> > =A0 =A0 );
>
> Thanks for posting that. =A0The finished-length argument is properly desc=
ribed in CEXTDECS, so Robo does not have to check that.- Hide quoted text -
>
> - Show quoted text -

Keith and team,
   I really appreciate that we have people who are willing to share
knowledge and make this group like how people do it in other
technologies. I made changes as suggested and this is how my program/
output looks now

short error, sqlcode;
short length=3D200;
short max_length=3D200;
short fin_length=3D0;
char  to_convert[201];
char  converted[201];
long  to_convert_ptr;
long  converted_ptr;

 memcpy(to_convert,&msg_in.special_message,length);
 to_convert[length] =3D '\0';
 to_convert_ptr =3D (long) &to_convert[0];
 converted_ptr  =3D (long) &converted[0];

 error =3D MBCS_EXTERNAL_TO_TANDEM_(&to_convert_ptr, &converted_ptr,
                                  length,&max_length,1,8);

and here is the output

-OBJKANJI(STEP 1 V)-d error
error =3D 0
-OBJKANJI-d to_convert in hex
to_convert[0] =3D 0 %HC8 %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
%HE7 %H9C
%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
%HA5 %H9E
%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
%H88 %HE5
%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
%HE7 %H9C
%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
%HA5 %H9E
%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
%H88 %HE5
%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
%HE7 %H9C
%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
%HA5 %H9E
%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
%H88 %HE5
%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
%HE7 %H9C
%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
%HA5 %H9E
%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
%H88 %HE5
%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 0

-OBJKANJI-d converted in h
converted[0] =3D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0
0 0 0 0 0 0 0 0 0

I hope when we resolved this issue, it will be a good reference for
future users of this API.
Thanks and Regards
Robo

In article <42677a63-ee6a-4253-bca5-12bb1a1a5e5d@s20g2000yqd.googlegroups.com>, 
mybase2008-download@yahoo.com says...
>
>On Dec 3, 5:34=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
>> mustlearntandem wrote:
>> > <snip>
>>
>> > Your doing great so far - hope this helps!
>>
>> > From CEXTDECS:
>>
>> > _tal _extensible short MBCS_EXTERNAL_TO_TANDEM_ (
>> > =A0 =A0 __int32_t _far *, =A0 /* IN/OUT OPTIONAL =A0*/
>> > =A0 =A0 __int32_t _far *, =A0 /* IN/OUT OPTIONAL =A0*/
>> > =A0 =A0 short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN =A0*/
>> > =A0 =A0 short _far *, =A0 =A0 =A0 /* IN/OUT =A0*/
>> > =A0 =A0 short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN OPTIONAL =A0*/
>> > =A0 =A0 short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN =A0*/
>> > =A0 =A0 short _far *, =A0 =A0 =A0 /* OUT OPTIONAL =A0*/
>> > =A0 =A0 char _far *, =A0 =A0 =A0 =A0/* IN OPTIONAL =A0*/
>> > =A0 =A0 char _far * =A0 =A0 =A0 =A0 /* IN OPTIONAL =A0*/
>> > =A0 =A0 );
>>
>> Thanks for posting that. =A0The finished-length argument is properly desc=
>ribed in CEXTDECS, so Robo does not have to check that.- Hide quoted text -
>>
>> - Show quoted text -
>
>Keith and team,
>   I really appreciate that we have people who are willing to share
>knowledge and make this group like how people do it in other
>technologies. I made changes as suggested and this is how my program/
>output looks now
>
>short error, sqlcode;
>short length=3D200;
>short max_length=3D200;
>short fin_length=3D0;
>char  to_convert[201];
>char  converted[201];
>long  to_convert_ptr;
>long  converted_ptr;
>
> memcpy(to_convert,&msg_in.special_message,length);
> to_convert[length] =3D '\0';
> to_convert_ptr =3D (long) &to_convert[0];
> converted_ptr  =3D (long) &converted[0];
>
> error =3D MBCS_EXTERNAL_TO_TANDEM_(&to_convert_ptr, &converted_ptr,
>                                  length,&max_length,1,8);
>
>and here is the output
>
>-OBJKANJI(STEP 1 V)-d error
>error =3D 0
>-OBJKANJI-d to_convert in hex
>to_convert[0] =3D 0 %HC8 %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
>%HE7 %H9C
>%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
>%HA5 %H9E
>%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
>%H88 %HE5
>%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
>%HE7 %H9C
>%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
>%HA5 %H9E
>%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
>%H88 %HE5
>%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
>%HE7 %H9C
>%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
>%HA5 %H9E
>%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
>%H88 %HE5
>%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
>%HE7 %H9C
>%H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
>%HA5 %H9E
>%HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
>%H88 %HE5
>%HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 0
>
>-OBJKANJI-d converted in h
>converted[0] =3D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0
>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>0 0 0 0 0
>0 0 0 0 0 0 0 0 0
>
>I hope when we resolved this issue, it will be a good reference for
>future users of this API.
>Thanks and Regards
>Robo

/*----------------------------------------------------------*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <cextdecs>

typedef long int32_t;
typedef unsigned long uint32_t;

short orig_len;
unsigned char orig_buf[400] =
{0x00 ,0xC8 ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 
,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 
,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 
,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 
,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C 
,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 
,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 
,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 
,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 
,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5
,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C 
,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 
,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7
,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 
,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 
,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 
,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 ,0x9C ,0x8C 
,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 ,0x9D ,0xE7 
,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 ,0xE5 ,0xB7 
,0x9D ,0xE7 ,0x9C ,0x8C ,0xE7 ,0xA5 ,0x9E ,0xE5 ,0xA5 ,0x88 
,0x00};


short xlated_len;
unsigned char xlated_buf[400];

long orig_buf_addr;
long xlated_buf_addr;
short intermediate;
short max_len;
short erc;
short external_form ;

short hextable[] =
{
 0x3030,0x3031,0x3032,0x3033,0x3034,0x3035,0x3036,0x3037,
 0x3038,0x3039,0x3061,0x3062,0x3063,0x3064,0x3065,0x3066,
 0x3130,0x3131,0x3132,0x3133,0x3134,0x3135,0x3136,0x3137,
 0x3138,0x3139,0x3161,0x3162,0x3163,0x3164,0x3165,0x3166,
 0x3230,0x3231,0x3232,0x3233,0x3234,0x3235,0x3236,0x3237,
 0x3238,0x3239,0x3261,0x3262,0x3263,0x3264,0x3265,0x3266,
 0x3330,0x3331,0x3332,0x3333,0x3334,0x3335,0x3336,0x3337,
 0x3338,0x3339,0x3361,0x3362,0x3363,0x3364,0x3365,0x3366,
 0x3430,0x3431,0x3432,0x3433,0x3434,0x3435,0x3436,0x3437,
 0x3438,0x3439,0x3461,0x3462,0x3463,0x3464,0x3465,0x3466,
 0x3530,0x3531,0x3532,0x3533,0x3534,0x3535,0x3536,0x3537,
 0x3538,0x3539,0x3561,0x3562,0x3563,0x3564,0x3565,0x3566,
 0x3630,0x3631,0x3632,0x3633,0x3634,0x3635,0x3636,0x3637,
 0x3638,0x3639,0x3661,0x3662,0x3663,0x3664,0x3665,0x3666,
 0x3730,0x3731,0x3732,0x3733,0x3734,0x3735,0x3736,0x3737,
 0x3738,0x3739,0x3761,0x3762,0x3763,0x3764,0x3765,0x3766,
 0x3830,0x3831,0x3832,0x3833,0x3834,0x3835,0x3836,0x3837,
 0x3838,0x3839,0x3861,0x3862,0x3863,0x3864,0x3865,0x3866,
 0x3930,0x3931,0x3932,0x3933,0x3934,0x3935,0x3936,0x3937,
 0x3938,0x3939,0x3961,0x3962,0x3963,0x3964,0x3965,0x3966,
 0x6130,0x6131,0x6132,0x6133,0x6134,0x6135,0x6136,0x6137,
 0x6138,0x6139,0x6161,0x6162,0x6163,0x6164,0x6165,0x6166,
 0x6230,0x6231,0x6232,0x6233,0x6234,0x6235,0x6236,0x6237,
 0x6238,0x6239,0x6261,0x6262,0x6263,0x6264,0x6265,0x6266,
 0x6330,0x6331,0x6332,0x6333,0x6334,0x6335,0x6336,0x6337,
 0x6338,0x6339,0x6361,0x6362,0x6363,0x6364,0x6365,0x6366,
 0x6430,0x6431,0x6432,0x6433,0x6434,0x6435,0x6436,0x6437,
 0x6438,0x6439,0x6461,0x6462,0x6463,0x6464,0x6465,0x6466,
 0x6530,0x6531,0x6532,0x6533,0x6534,0x6535,0x6536,0x6537,
 0x6538,0x6539,0x6561,0x6562,0x6563,0x6564,0x6565,0x6566,
 0x6630,0x6631,0x6632,0x6633,0x6634,0x6635,0x6636,0x6637,
 0x6638,0x6639,0x6661,0x6662,0x6663,0x6664,0x6665,0x6666
};


void hexdump(char *buffer, int32_t  size)
{
   short    msglen = 0;
   int32_t  byteIndex = 0;
   unsigned char *pBuffer;
   unsigned char *p1;
   char   *pAscii;
   char message[132];

   pBuffer = (unsigned char *)buffer;
   pAscii = &message[60];

   p1 = (unsigned char *)pAscii;
   memset(message, 0, 90);
   for (byteIndex=0; size > 0;  size--, pBuffer++, byteIndex++, p1++)
   {
      if ( byteIndex == 20 )
      {
         byteIndex = 0;
         msglen = 0;
         printf("%-50.50s | %s\n",message, pAscii);
         memset(message, 0, 90);
         p1 = (unsigned char *)pAscii;
      }
      if ((byteIndex % 2) == 0)
      {
         message[msglen] = ' ';
         msglen += 1;
      }

      memcpy(&message[msglen], &hextable[*pBuffer], 2);
      msglen += 2; 
      if (isprint( (*pBuffer & 0xff) ) )
      {
         *p1 = *pBuffer;
      }
      else
      {
         *p1 = '.';
      }
   } /* for */

   if ( byteIndex > 0)
   {
      printf("%-50.50s | %s\n", message, pAscii);
   }

   return;
} /* hexdump */


int main(int argc, char *argv[])
{
  orig_len = 200;
  intermediate = 1;
  external_form = 8;

  xlated_len = (short)(sizeof(xlated_buf) / 2);
  max_len = xlated_len;

  orig_buf_addr =   (long)orig_buf;
  xlated_buf_addr = (long)xlated_buf;

  erc = MBCS_EXTERNAL_TO_TANDEM_ (&orig_buf_addr,
                                  &xlated_buf_addr, 
                                  orig_len,
                                  &max_len, 
                                  intermediate,
                                  external_form,
                                  &xlated_len,
                                  /* shift_to_mbcs     */, 
                                  /* shift_to_one_byte */);
  if (erc)
  {
     printf("MBCS_EXTERNAL_TO_TANDEM_ error %hd\n", erc);
     return(0);
  }

  printf("\nOrig\n");
  hexdump(orig_buf, orig_len);

  printf("\nXLated\n");
  hexdump(xlated_buf, xlated_len);

  return(0);
} /* main */

Robo wrote:
> On Dec 3, 5:34 pm, Keith Dick <KeithD...@earthlink.net> wrote:
> 
>>mustlearntandem wrote:
>>
>>><snip>
>>
>>>Your doing great so far - hope this helps!
>>
>>>From CEXTDECS:
>>
>>>_tal _extensible short MBCS_EXTERNAL_TO_TANDEM_ (
>>>    __int32_t _far *,   /* IN/OUT OPTIONAL  */
>>>    __int32_t _far *,   /* IN/OUT OPTIONAL  */
>>>    short ,             /* IN  */
>>>    short _far *,       /* IN/OUT  */
>>>    short ,             /* IN OPTIONAL  */
>>>    short ,             /* IN  */
>>>    short _far *,       /* OUT OPTIONAL  */
>>>    char _far *,        /* IN OPTIONAL  */
>>>    char _far *         /* IN OPTIONAL  */
>>>    );
>>
>>Thanks for posting that.  The finished-length argument is properly described in CEXTDECS, so Robo does not have to check that.- Hide quoted text -
>>
>>- Show quoted text -
> 
> 
> Keith and team,
>    I really appreciate that we have people who are willing to share
> knowledge and make this group like how people do it in other
> technologies. I made changes as suggested and this is how my program/
> output looks now
> 
> short error, sqlcode;
> short length=200;
> short max_length=200;
> short fin_length=0;
> char  to_convert[201];
> char  converted[201];
> long  to_convert_ptr;
> long  converted_ptr;
> 
>  memcpy(to_convert,&msg_in.special_message,length);
>  to_convert[length] = '\0';
>  to_convert_ptr = (long) &to_convert[0];
>  converted_ptr  = (long) &converted[0];
> 
>  error = MBCS_EXTERNAL_TO_TANDEM_(&to_convert_ptr, &converted_ptr,
>                                   length,&max_length,1,8);
> 
> and here is the output
> 
> -OBJKANJI(STEP 1 V)-d error
> error = 0
> -OBJKANJI-d to_convert in hex
> to_convert[0] = 0 %HC8 %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> %HE7 %H9C
> %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> %HA5 %H9E
> %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> %H88 %HE5
> %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> %HE7 %H9C
> %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> %HA5 %H9E
> %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> %H88 %HE5
> %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> %HE7 %H9C
> %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> %HA5 %H9E
> %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> %H88 %HE5
> %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> %HE7 %H9C
> %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> %HA5 %H9E
> %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> %H88 %HE5
> %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 0
> 
> -OBJKANJI-d converted in h
> converted[0] = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> 0 0 0 0 0
> 0 0 0 0 0 0 0 0 0
> 
> I hope when we resolved this issue, it will be a good reference for
> future users of this API.
> Thanks and Regards
> Robo

I notice that the very first byte of the input buffer is 0.  Is that valid input?  Might it stop the processing (analogous to how C string routines stop on a null byte)?  I have no idea.  

This probably is not the problem, but if I were you, I would verify that the values in to_convert_ptr and converted_ptr actually are the addresses of the start of the arrays.  I think you can do that with the following commands in Inspect:

d to_convert_ptr in h
d &to_convert[0] in h

Do this BEFORE the call -- remember that the call stores back into the first two parameters.

I'm not certain of the second command, so you might have to change it a bit.  The two values should be the same.  If they are right, check the other pointer, too.  If the values in to_convert_ptr or converted_ptr are not the address of the buffers, try to figure out what the C statement to set them up should be.

But that probably isn't the problem.  I found this in the Considerations for the MBCS_EXTERNAL_TO_TANDEM_ proc:

If any of the optional formal parameters are omitted, the procedure returns, in
maximum-length, the maximum possible length in bytes for the destination data
buffer. In general, translations to external text formats yield text strings of
increased length. The maximum possible finished length for the specified
conditions will be returned. If less than this amount of space is allowed, the
translation procedure might fail due to insufficient space in the destination string.

I believe this tells us that there are some circumstances in which the function doesn't try to convert the buffer, but just returns a value that says how long the longest the output could possibly be.  Perhaps this test program is triggering that "don't do it, just tell me how big" behaviour, but the description about what triggers that behaviour doesn't make sense to me.  "If any of the optional formal parameters are omitted ..." it does this calculate-only thing.  Really?  That means they aren't really optional.  I'm sure the developer was a bit sloppy in the description or the tech writer messed it up somewhere along the way.  But what makes sense?  I don't know.  Oh, I just see that in the description of maximum-length, it gives a more believable description of when the calculate-only mode is triggered.  It seems that your test program does not fit those conditions, but whose knows?  Maybe that description is inaccurate, too.

One way you could test this is check the value in max_length after the call.  If it is anything other than 200, that calculate-only thing is probably what happened.

And you could experiment by setting up values for all the the parameters and see whether that makes the function work.  The manual appears to say what the default values of those last two parameters are, so you should be able to use those values and not mess up the conversion.

That's all I can think of right now.
 

On Dec 3, 8:57=A0pm, Keith Dick <KeithD...@earthlink.net> wrote:
> Robo wrote:
> > On Dec 3, 5:34 pm, Keith Dick <KeithD...@earthlink.net> wrote:
>
> >>mustlearntandem wrote:
>
> >>><snip>
>
> >>>Your doing great so far - hope this helps!
>
> >>>From CEXTDECS:
>
> >>>_tal _extensible short MBCS_EXTERNAL_TO_TANDEM_ (
> >>> =A0 =A0__int32_t _far *, =A0 /* IN/OUT OPTIONAL =A0*/
> >>> =A0 =A0__int32_t _far *, =A0 /* IN/OUT OPTIONAL =A0*/
> >>> =A0 =A0short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN =A0*/
> >>> =A0 =A0short _far *, =A0 =A0 =A0 /* IN/OUT =A0*/
> >>> =A0 =A0short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN OPTIONAL =A0*/
> >>> =A0 =A0short , =A0 =A0 =A0 =A0 =A0 =A0 /* IN =A0*/
> >>> =A0 =A0short _far *, =A0 =A0 =A0 /* OUT OPTIONAL =A0*/
> >>> =A0 =A0char _far *, =A0 =A0 =A0 =A0/* IN OPTIONAL =A0*/
> >>> =A0 =A0char _far * =A0 =A0 =A0 =A0 /* IN OPTIONAL =A0*/
> >>> =A0 =A0);
>
> >>Thanks for posting that. =A0The finished-length argument is properly de=
scribed in CEXTDECS, so Robo does not have to check that.- Hide quoted text=
 -
>
> >>- Show quoted text -
>
> > Keith and team,
> > =A0 =A0I really appreciate that we have people who are willing to share
> > knowledge and make this group like how people do it in other
> > technologies. I made changes as suggested and this is how my program/
> > output looks now
>
> > short error, sqlcode;
> > short length=3D200;
> > short max_length=3D200;
> > short fin_length=3D0;
> > char =A0to_convert[201];
> > char =A0converted[201];
> > long =A0to_convert_ptr;
> > long =A0converted_ptr;
>
> > =A0memcpy(to_convert,&msg_in.special_message,length);
> > =A0to_convert[length] =3D '\0';
> > =A0to_convert_ptr =3D (long) &to_convert[0];
> > =A0converted_ptr =A0=3D (long) &converted[0];
>
> > =A0error =3D MBCS_EXTERNAL_TO_TANDEM_(&to_convert_ptr, &converted_ptr,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 len=
gth,&max_length,1,8);
>
> > and here is the output
>
> > -OBJKANJI(STEP 1 V)-d error
> > error =3D 0
> > -OBJKANJI-d to_convert in hex
> > to_convert[0] =3D 0 %HC8 %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> > %HE7 %H9C
> > %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> > %HA5 %H9E
> > %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> > %H88 %HE5
> > %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> > %HE7 %H9C
> > %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> > %HA5 %H9E
> > %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> > %H88 %HE5
> > %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> > %HE7 %H9C
> > %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> > %HA5 %H9E
> > %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> > %H88 %HE5
> > %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D
> > %HE7 %H9C
> > %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7
> > %HA5 %H9E
> > %HE5 %HA5 %H88 %HE5 %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5
> > %H88 %HE5
> > %HB7 %H9D %HE7 %H9C %H8C %HE7 %HA5 %H9E %HE5 %HA5 %H88 0
>
> > -OBJKANJI-d converted in h
> > converted[0] =3D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =
0
> > 0 0 0 0
> > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0 0
> > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0 0
> > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0 0
> > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > 0 0 0 0 0
> > 0 0 0 0 0 0 0 0 0
>
> > I hope when we resolved this issue, it will be a good reference for
> > future users of this API.
> > Thanks and Regards
> > Robo
>
> I notice that the very first byte of the input buffer is 0. =A0Is that va=
lid input? =A0Might it stop the processing (analogous to how C string routi=
nes stop on a null byte)? =A0I have no idea. =A0
>
> This probably is not the problem, but if I were you, I would verify that =
the values in to_convert_ptr and converted_ptr actually are the addresses o=
f the start of the arrays. =A0I think you can do that with the following co=
mmands in Inspect:
>
> d to_convert_ptr in h
> d &to_convert[0] in h
>
> Do this BEFORE the call -- remember that the call stores back into the fi=
rst two parameters.
>
> I'm not certain of the second command, so you might have to change it a b=
it. =A0The two values should be the same. =A0If they are right, check the o=
ther pointer, too. =A0If the values in to_convert_ptr or converted_ptr are =
not the address of the buffers, try to figure out what the C statement to s=
et them up should be.
>
> But that probably isn't the problem. =A0I found this in the Consideration=
s for the MBCS_EXTERNAL_TO_TANDEM_ proc:
>
> If any of the optional formal parameters are omitted, the procedure retur=
ns, in
> maximum-length, the maximum possible length in bytes for the destination =
data
> buffer. In general, translations to external text formats yield text stri=
ngs of
> increased length. The maximum possible finished length for the specified
> conditions will be returned. If less than this amount of space is allowed=
, the
> translation procedure might fail due to insufficient space in the destina=
tion string.
>
> I believe this tells us that there are some circumstances in which the fu=
nction doesn't try to convert the buffer, but just returns a value that say=
s how long the longest the output could possibly be. =A0Perhaps this test p=
rogram is triggering that "don't do it, just tell me how big" behaviour, bu=
t the description about what triggers that behaviour doesn't make sense to =
me. =A0"If any of the optional formal parameters are omitted ..." it does t=
his calculate-only thing. =A0Really? =A0That means they aren't really optio=
nal. =A0I'm sure the developer was a bit sloppy in the description or the t=
ech writer messed it up somewhere along the way. =A0But what makes sense? =
=A0I don't know. =A0Oh, I just see that in the description of maximum-lengt=
h, it gives a more believable description of when the calculate-only mode i=
s triggered. =A0It seems that your test program does not fit those conditio=
ns, but whose knows? =A0Maybe that description is inaccurate, too.
>
> One way you could test this is check the value in max_length after the ca=
ll. =A0If it is anything other than 200, that calculate-only thing is proba=
bly what happened.
>
> And you could experiment by setting up values for all the the parameters =
and see whether that makes the function work. =A0The manual appears to say =
what the default values of those last two parameters are, so you should be =
able to use those values and not mess up the conversion.
>
> That's all I can think of right now.- Hide quoted text -
>
> - Show quoted text -

Thanks every one for getting this code done. It helped me a lot. One
thing surprising is that this API doesn't support UTF-8. This really
stopped me from getting my end result done. Just putting this comment
here so that future users will know it.