Thanks, I just figured it out. Somehow the ftp of the other ldif made it unusable. So I moved over my java program that creates the ldif file, and all is well.
Steve Francis
IHG - z/OS Technical Advisor
Sent from my BlackBerry

From: Jonathan Clarke <jonathan@phillipoux.net>
To: Francis, Steve (IHG)
Cc: <openldap-technical@openldap.org> <openldap-technical@openldap.org>
Sent: Tue Feb 23 17:21:50 2010
Subject: Re: Adding a schema to OpenLdap

On 23 févr. 2010, at 17:38, "Francis, Steve (IHG)" <Steve.Francis@ihg.com> wrote:

I have a schema that I have used on a z/OS Ldap server for over six years.  I received a NOID from IANA and have had no issues running ldapmodify commands on the z/OS ldap server to allow the objectclass's use.
 
Now, I'm working to port he application that uses this ldap server to Linux and can't seem to get OpenLdap to allow the use of my objectclass.  I have created my own schema file and have included it in the slapd.conf, which start with no errors; however, the ldapadd to process the ldif file fails with the famous "ldap_add:  Invalid syntax (21)  additional info:  objectclass: value #1 invalid per syntax" .  I know this to be my objectclass, since the following is my ldif file.
 
dn: cn=10.172.50.0, o=SAH
objectclass: top         
objectclass: saHolidex   
cn: 10.172.50.0          
sn: AADAL                
ou: HOTEL                
mtrStatus: N             
ipAddr: 10.172.50.0      
pqsStatus: MQSOFF        
subNetMask: 255.255.255.0


Make sure that you don't have any spaces trailing after your objectClass name in your LDIF file. This is a common source of this error.

If this doesn't solve your problem, start slaps with "loglevel config" in slapd.conf and make sure your objectclass is read in.

Hope this helps,
Jonathan

 
The z/OS ldap server had gotten away from including schema files and so I simply issued the ldapmodify command to update "cn=schema,o=sah" as my suffix was o=sah.
The  schema file I created looks like the following, as my IANA number is 15132:
 
attributetype ( 1.3.6.1.4.1.15132.0.1.2.4
        NAME 'mtrStatus'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        EQUALITY caseIgnoreMatch )
attributetype ( 1.3.6.1.4.1.15132.0.1.2.3
        NAME 'ipAddr'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
        EQUALITY caseExactIA5Match )
attributetype ( 1.3.6.1.4.1.15132.0.1.2.5
        NAME 'pqsStatus'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        EQUALITY caseIgnoreMatch )
attributetype ( 1.3.6.1.4.1.15132.0.1.2.6
        NAME 'subNetMask'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
        EQUALITY caseExactIA5Match )
objectClass    ( 1.3.6.1.4.1.15123.0.1.2.1
   NAME 'saHolidex'
       DESC 'IHG Sah'
   SUP top STRUCTURAL
       MUST ( cn $ sn )
       MAY ( ou $ mtrStatus $ ipAddr $ pqsStatus $ subNetMask ) )
 
The old ldif file for the z/OS systems looks like the following:
dn: cn=schema,o=SAH
changetype:modify
add:x
attributetypes: ( 15132.0.1.2.4 NAME 'mtrStatus' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch )
ibmattributetypes: ( 15132.0.1.2.4 ACCESS-CLASS normal)
attributetypes: ( 15132.0.1.2.3 NAME 'ipAddr' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseExactIA5Match )
ibmattributetypes: ( 15132.0.1.2.3 ACCESS-CLASS normal)
attributetypes: ( 15132.0.1.2.5 NAME 'pqsStatus' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 EQUALITY caseIgnoreMatch )
ibmattributetypes: ( 15132.0.1.2.5 ACCESS-CLASS normal)
attributetypes: ( 15132.0.1.2.6 NAME 'subNetMask' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 EQUALITY caseExactIA5Match )
ibmattributetypes: ( 15132.0.1.2.6 ACCESS-CLASS normal)
objectclasses: ( 15123.0.1.2.1 NAME 'saHolidex' SUP top MUST ( cn $ sn ) MAY ( ou $ mtrStatus $ ipAddr $ pqsStatus $ subNetMask ) )
Can anyone help me figure out why I can't get this objectclass to work.  It works fine with the z/OS Ldap Server, and has for many years, all the way back to the OS390 days, prior to z/OS.
 
Thanks, i advance,

Steve Francis
Technical Advisor - zSeries, zLinux, z/OS
IHG
Alpharetta Data Center
Ph:  770-442-7157
Cell:  770-906-3122
IM: francisihg