[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: EBCDIC

It is possible to have LDAP run 100% EBCDIC in USS on z/OS and OS/390

You need to perform EtoA and AtoE as the data is read/written to the
TCP/IP socket.

This allows all config files, schema files, etc to stay in EBCDIC and
not have to play games to work in ASCII in an EBCDIC world.

Mitch


-----Original Message-----
From: jean-frederic clere [mailto:jfrederic.clere@fujitsu-siemens.com] 
Sent: Monday, March 03, 2003 5:30 AM
To: Howard Chu
Cc: openldap-devel@OpenLDAP.org; Martin Kraemer
Subject: Re: EBCDIC

Howard Chu wrote:
> I ported OpenLDAP, OpenSSL, Berkeley DB 4.1, and part of Cyrus SASL to
> OS/390. Aside from Cyrus, all of these packages were fully functional
but
> OpenLDAP and OpenSSL operate with ASCII internally. In addition to
using
> IBM's libascii, I wrote stdio stubs to handle ASCII/EBCDIC translation
for
> parsing commandline args, reading config files, and writing log files.
These
> are the only interfaces between the software and the host OS that
needed
> work, given the presence of libascii.

I already have OpenSSL, Berkeley DB 4.1 and a lot more libraries
prepared to use 
  EBCDIC APIs. I do not think I will be able to have a special ASCII
version of 
those for OpenLDAP.

> 
> A lot of what I went thru is in the FAQ-o-Matic now
> http://www.openldap.org/faq/data/cache/719.html
> 
> The slapd that I built with this approach interoperates correctly with
any
> other LDAP server or client, does not need to do character-set
translation in
> the protocol transactions, and thus has no performance degradation
compared
> to a native server.

I am not able to locate in the CVS the modifications you describe in the

FAQ-o-Matic. How could I get them?

> 
> If you need to build a slapd that uses EBCDIC strings in the protocol
layer,
> you're not talking LDAP. That is not worth any further discussion
here.

That is not what I need.

> 
> If you need to use libldap from other applications, and they're
passing in
> EBCDIC strings, you have a lot of hard work ahead of you. Since the
client
> library doesn't have ready access to the schema, you don't have an
easy way
> of identifying binary values that must be left unmodified, vs string
values
> that should be translated.

I am afraid that what I have to do.

> 
> By the way, I am putting together a small presentation on the OS/390
port for
> the OpenLDAP Developer Day conference on March 21. Perhaps we can
discuss
> more of the issues there.

Would be nice but I am based in Europa.

> 
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
> 
> 
>>-----Original Message-----
>>From: owner-openldap-devel@OpenLDAP.org
>>[mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of jean-frederic
>>clere
>>Sent: Friday, February 28, 2003 7:41 AM
>>To: openldap-devel@OpenLDAP.org
>>Subject: EBCDIC
>>
>>
>>Hi,
>>
>>After a long time doing other things I am returning to port
>>OpenLDAP to an
>>EBCDIC machine.
>>I have done the following:
>>  - check out the tag OPENLDAP_REL_ENG_2.
>>  - patch build/ltmain.sh (attached).
>>  - use libregex from Apache-1.3 and snprintf/sockaddr_ip_get
>>from APR (Apache
>>Portable Runtime).
>>  - use getgrnam and  initgr specific to the machine.
>>And now I have a slapd that starts but does nothing else has
>>he speaks EBCDIC.
>>
>>I have to integrate OpenLDAP in an EBCDIC environment
>>(strings _have_ to be
>>EBCDIC strings). So I will convert the data in input/output
>>as I have to link
>>OpenLDAP with other API that are prepared to work that way.
>>
>>The EBCDIC topic appaired last year in the dev list but I do
>>not know what is
>>the actual status of the porting.
>>
>>Any comments or hints?
>>
>>Cheers
>>
>>Jean-frederic
>>
> 
> 
>