RE: LDAP connections to the proper server, and unknown error??

Alan,

LDAP_Svr needs to be a pointer and not the actual value. In a program
that I wrote, I have:

LDAPserver                  100A
LDAPport                     10I 0

ld = ldap_init(%addr(LDAPserver): LDAPport)

The server name is just it's host name, you don't need the protocol.

Matt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Cassidy, Alan
Sent: Wednesday, July 05, 2006 11:50 AM
To: RPG programming on the AS400 / iSeries
Cc: Midrange Systems Technical Discussion; c400-L@xxxxxxxxxxxx
Subject: LDAP connections to the proper server, and unknown error??


Cross posted, because this is to solve an API issue for and RPG program
using Unix-type API's. 

Okay, I've (a)_studied IBM's materials on using LDAP on the i5,
(b)_studied a redbook on same, (c)_perused the archives (this helped the
most), (d) spoken to an IBM programming tech. And I'm still am against a
brick wall. The tech wasn't able to help me, what he said is that it is
the server that is ignoring the requested connection for some reason
(not his problem with that). He walked me through the ldapsearch command
in the Qshell before he got to that point. 

What I'm trying to do is to validate the left side of an email address,
meaning left of the at-sign @ and server name. Like within
myname@xxxxxxxxxx, I just need to validate "myname". 

That name is an entry on the company's LDAP server, which the Windows
guys are telling me is also the Active Directory (which I suppose is
told to answer calls to LDAP), and it is also the email directory. All
the email names are there. So part of the DN will be "mail=myname", or
possibly "mail=myname@xxxxxxxxxx", and I've tried permutations. 

But I'm not even getting that far at this point. 

I run ldap_init(servername: LDAP_PORT) and used the name for the server
that the Windows guy gave me. He uses VB by the way. I tried it with and
without the "ldap://"; prefix too. 

The ldap_init() runs okay but that's only because it doesn't actually
attempt to connect.

Next I run ldap_search(), because I just want to check the directory for
the entry, as opposed to log in. That's where it coughs up an error, and
the error code that this LDAP client API is returning to my program is a
-1. Great. "Unknown error". That explains everything, huh. 

Scott's program found the archives, cut and pasted, compiled "just like
that", "as is". Another round of thanks to Scott. 

But his program assumes the LDAP server is on the same system where one
runs the client API's. Not the case. There is an active LDAP server
running on the system, but it's empty. I need to know how to deactivate
it, and then how to reactivate it, but the docs are not very helpful on
this either. Real simple, I'm sure. 

I'll be grateful for any suggestions to get past my Ldap_search() at
this point....

My code: 

 ld = ldap_init(LDAP_Svr : LDAP_PORT) 

...where LDAP_Svr is a command parm, but it's exactly as they've told
me. Tried lowercase, tried uppercase. repsrv.com. Tried prefixing with
"ldap://"; and tried without it.  LDAP_PORT is the constant for the LDAP
port on the machine, and they've assured me that the port is correct. 

Next, it's: 

 ld = ldap_search( ld: mybasedn: LDAP_SCOPE_SUBTREE: Filter:
%addr(AttrPtr): 0) 

...where ld is the pointer returned by ldap_init(); 

mybasedn consists of the values they gave me: "DC=repsrv,DC=com". 

LDAP_SCOPE_SUBTREE is the appropriate constant from Scott's example,
plus confirmed in the QSYSINC library;

Filter is a field with VARYING. The prototypes are defined with "const"
and "string", so should be translated okay for the call. Not a malformed
filter, because I did get the message that it was until I corrected it: 
and it's just "(|(mail=*))". The VM programmer who has used these LDAP
searches has assured me this is correct for getting to the email
addresses. I was using the specific value, but changed it to the wild
card to just check the connection. 

I've tried the ldapsearch command which is explained in IBM's
too-cryptic document on LDAP, but the parameters are not clear enough,
and running that's not helping either. 

--Alan