× 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.




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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.