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(a)phillipoux.net&gt; To: Francis, Steve (IHG) Cc: <openldap-technical(a)openldap.org&gt; <openldap-technical(a)openldap.org&gt; 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(a)ihg.com&gt; 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