Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Is EBCDIC support gone?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 20 Jul 2022 14:39:50 +0200
On 7/20/22 12:55, Stephan Mühlstrasser via curl-library wrote:
> Am 20.07.2022 um 12:29 schrieb Patrick Monnerat via curl-library:
>> This is true: libcurl internally only works on ASCII-based character
>> sets.
>>
>> However the OS400 platform interface still implements EBCDIC wrappers
>> to the API that are completely independent of the late
>> CURL_DOES_CONVERSION code.
>>
>> This approach is less-error prone for libcurl's code as it
>> concentrates code conversion efforts to a single place. In addition,
>> it offers (on the OS400) at runtime the choice among using several
>> EBCDIC variants and to mix them.
>
> Thanks, I was not aware of this wrapper. It looks like it is quite
> OS400-specific,
Yes, it is specific and uses IBM proprietary API for conversions.
In addition, you must have a C compiler that you can put in ASCII mode
(a mode in which source literal strings and characters generate ASCII
data).
OS400 uses CCSIDs (integer coded character set identifiers) to identify
encodings. I don't think they exist or are important in z/OS.
> so making this work on z/OS would require probably some effort.
When I ported libcurl to OS400, I did these efforts! I studied the
ability to use CURL_DOES_CONVERSION but this was not satisfactory.
OS400 has a limited C ASCII support (QADRT API libraries) that are used
by libcurl. Unsupported C/system API are provided by the libcurl
implementation. If you don't have such a support library in z/OS, you
will probably have to write some additional internal ASCII wrappers for
C/system API.
See https://github.com/curl/curl/blob/master/packages/OS400/README.OS400
for more details. If you don't know IBM i, you might also need
https://www.ibm.com/docs/en/i/7.1?topic=programming
Patrick
Date: Wed, 20 Jul 2022 14:39:50 +0200
On 7/20/22 12:55, Stephan Mühlstrasser via curl-library wrote:
> Am 20.07.2022 um 12:29 schrieb Patrick Monnerat via curl-library:
>> This is true: libcurl internally only works on ASCII-based character
>> sets.
>>
>> However the OS400 platform interface still implements EBCDIC wrappers
>> to the API that are completely independent of the late
>> CURL_DOES_CONVERSION code.
>>
>> This approach is less-error prone for libcurl's code as it
>> concentrates code conversion efforts to a single place. In addition,
>> it offers (on the OS400) at runtime the choice among using several
>> EBCDIC variants and to mix them.
>
> Thanks, I was not aware of this wrapper. It looks like it is quite
> OS400-specific,
Yes, it is specific and uses IBM proprietary API for conversions.
In addition, you must have a C compiler that you can put in ASCII mode
(a mode in which source literal strings and characters generate ASCII
data).
OS400 uses CCSIDs (integer coded character set identifiers) to identify
encodings. I don't think they exist or are important in z/OS.
> so making this work on z/OS would require probably some effort.
When I ported libcurl to OS400, I did these efforts! I studied the
ability to use CURL_DOES_CONVERSION but this was not satisfactory.
OS400 has a limited C ASCII support (QADRT API libraries) that are used
by libcurl. Unsupported C/system API are provided by the libcurl
implementation. If you don't have such a support library in z/OS, you
will probably have to write some additional internal ASCII wrappers for
C/system API.
See https://github.com/curl/curl/blob/master/packages/OS400/README.OS400
for more details. If you don't know IBM i, you might also need
https://www.ibm.com/docs/en/i/7.1?topic=programming
Patrick
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-07-20