× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Larry,
It is complex to call these and some other APIs which is why I created the
RPG ToolKit. If you have the RPG ToolKit (www.rpglib.com) you can call
either the ToEbcdic() procedure or the XLateCCSID() procedure to convert the
text. ToEbcdic() converts from ASCII to EBCDIC whereas XLateCCSID() allows
you convert anything to anything. They both use iconv() under the covers.
-Bob


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Larry
Sent: Monday, March 08, 2004 4:27 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Calling iconv() with the correct prototype definitions

Buck,
This is one of the non-examples that I was talking about.

For example; Look at the following call:  
** setup code page conversion ebcdic - ascii
c                   eval      #ToAscii  = IConvOpen(#p_Qascii:
c                                                   #p_Qebcdic)

The example code does not include a prototype definition for IConvOpen().
However, we can deduce by looking at the data-structures that the pointers
are pointing at, the creation of the conversion descriptor is achieved via a
call to Qtqiconv_open(), passing datatypes of the type Qtqcode_t. To muddy
the water, the IBM documentation suggests that the iconv_open() API should
now be used in place of QtqiconvOpen().

A second example is the call to iconv() itself:
** translate response to ASCII
C                   eval      #p_InBuff = %addr(#SocketData) + 2
C                   eval      #p_OutBuff = #p_InBuff
C                   eval      #InBytes = %len(#SocketData)
C                   eval      #OutBytes = %len(#SocketData)
C                   eval      #RC = IConv(#ToAscii:
C                                        %addr(#p_InBuff):
C                                        #p_InBytes:
C                                        %addr(#p_OutBuff):
C                                        #p_OutBytes)

Here, the passed variables are:
1)      The conversion descriptor
2)      A pointer to the address of a pointer containing the address of the
first byte in the input buffer to be translated.
3)      A pointer to a variable containing the number of bytes to translate.
4)      A pointer to the address of a pointer containing the address of the
first available byte in the output buffer to be written to.
5)      A pointer to a variable containing the number of bytes on the output
buffer left.

Now, the return value #RC is not defined in the example. According to the
IBM documentation it should be of type size_t (unsigned int) but many
examples I've seen have a return value set a int. Also, the third and fifth
variables point to the addresses of int datatypes. The IBM documentation
specifies that the fields should be of type size_t (unsigned int).

So, on balance, this example doesn't really help - it generates more
questions for me than answers. Basically, I'm at  the point where I think
the example should never ever work, and I'd probably cry if I used it and it
worked, because then it would mean that "I just don't get it". I'm not sure
what's worse - code that's not up to it or a coder that's not up to it. :-) 

Should the example work? If so, what am I missing here? 


On 8th March Buck wrote:
A serach of the archives turned up this one:
http://archive.midrange.com/rpg400-l/200108/msg00209.html

  --buck


 



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.