A directory is a listing of information about objects and their details arranged in a specific order. Examples are a telephone directory and a library card catalog. A computer directory is a specialized database usually optimized for search rather than for heavy updates.

Directories are mainly used for personal information such as email addresses or fax numbers, but directories are now also being used for authenticating a user to network services. Systems management applications are exploiting the directory for profile-based management of system resources, such as bandwidth utilization of a network or location of a nearby PostScript color printer.

Searching a directory is similar to looking up a name in a telephone directory, but it is more flexible. If the name of a particular individual object is not known, the directory can be searched by criteria for a list of objects that meet a certain requirement.

What Is AS/400’s Directory?

The history of OS/400’s System Distribution Directory (SDD) began with email addressing in Personal Services/36, the precursor to OfficeVision/400 (OV/400) for System/36, and is now an integral part of OS/400. It is stored in DB2/400 and provides full X.500 and Lightweight Directory Access Protocol (LDAP) standards support.

The SDD lists information about local and remote individuals. All users authorized to send and receive distributions and to access the document library (see below) must be enrolled in the SDD, and other local, remote, and external individuals may be enrolled. Certain system functions such as remote output queues can also generate an entry. All entries have a user ID, address, and description. Optional fields include first and last name, job title, company, location, department, telephone and fax numbers, full postal addresses, and user-defined fields. Email addresses may be formatted for SNADS (used by OV/400),
X.400, Simple Mail Transfer Protocol (SMTP), cc:Mail, or be user-defined.

Distribution lists, nicknames, departments, and locations are built using SDD function. A distribution list is a collection of directory entry descriptions used for emailing and other distribution, including fax. A nickname is an alias for a directory entry description and can be personal or public. A department is a collection of directory entries with a manager and can form an organizational hierarchy with “reports to” departments. A

location is the physical place where the person is based and can have a separately defined address to avoid rekeying all entries when an office moves.

Why Is the Directory Important?

The SDD is used by SNADS, OV/400, Client Access/400, NetServer, Mail Server Framework (AnyMail/400), SMTP, Facsimile Support/400, and OS/400 Document Library Services. These users will already be enrolled in the SDD, and so you probably have significant content in the directory before you start.

In addition, the SDD is often used as the basis for a Web-enabled corporate address and phone book application—for free—containing names, departments, job titles, reporting structures, locations, telephone and fax numbers for local, remote, or external people. This grows the range and breadth of the content. One major United Kingdom bank used an early version of the SDD to maintain the telephone list with fast search capability for a 2,000 person office—and only the receptionists could update the entries.

In some cases, the SDD APIs are used to provide an automatic update of the directory from a human resources application as staff members join and leave the company. This helps maintain data integrity.

A common version or subset can be shared between multiple AS/400s using OS/400’s directory shadowing function. This extends the reach to all AS/400 users in the organization.

Domino for AS/400 directory synchronization can automatically synchronize user information in the Domino directory with user information in the AS/400 SDD. Notes replication readily extends this capability to all Domino servers, extending the reach to all Notes and Domino users.

Domino designer facilities also enable you to build graphical views of the Directory, such as an organizational chart based on department structure. This creates more meaningful views of the data.

Because Domino is a native Web server you can automatically publish a list of contact details to an intranet or to the Internet. This adds Web browser access to the data.

The accuracy and completeness of the SDD is key to the success of an OV/400 migration to Lotus Notes. The SDD builds the Domino directory, registers users including creating mail files, enables calendar coexistence, and redirects the mail after migration. In fact, anyone doing large Domino-for-AS/400 projects should consider using the IBM OV/400 Migration Tools to save time and ensure accuracy of registration, whether OV/400 is involved or not.

SDD entries can be published to an LDAP server and kept synchronized with SDD changes. LDAP defines an Internet standard way of accessing X.500 directories over TCP/IP. LDAP is supported in most network operating systems, groupware, and network applications. OS/400 V4R3 AS/400 directory services, sometimes referred to as SecureWay directory for OS/400, includes an LDAP server and a complete set of LDAP clients for access from C, COBOL, RPG, Client Access, Java, and a command line. The LDAP server uses DB2/400 for storing the directory information.

This LDAP directory can then be used by any LDAP client such as email (Lotus Notes, Netscape Communicator, or Microsoft Exchange, for example) that access directory information using the ‘Search directory’ function. These email clients can be configured to extend their address books to search your AS/400 LDAP directory.

OS/400 also supports storing network hardware and software inventory in an LDAP directory. NetFinity for AS/400 publishes workstation and server inventory in an LDAP directory. You can search for network configuration information such as a workstation’s motherboard information or an AS/400’s software configuration. You can also add additional customer-defined data to the directory. These options extend the type of information you can store in the directory.

In the future, the directory will become a cornerstone of knowledge management (KM) frameworks. Lotus plans a suite of KM products under the code name of Raven.

Lotus explains that KM is all about people (employees, contractors, customers, and suppliers with roles and skills) coming together in meeting places (real and virtual) and using things (knowledge and documents). The directory puts the people into knowledge management’s “people, places, and things.” This lets you take a corporate, Internet-enabled list of people and use it to manage and exploit the intellectual property of the organization.

So, if you like the sound of what the directory can do for you, how do you get started?

Auditing the SDD

To get a clear picture of the existing condition of your SDDs before you start your planning, it is worthwhile to do an audit. Here are some of the things to look for and the sample commands to use to get the answers.

• Number of entries, split local vs. remote (Work with Directory Entry [WRKDIRE])

• Completion of descriptive fields

• Duplicate entries, e.g., for administrators on multiple systems

• Use of Internet (SMTP), cc:Mail, or X.400 addressing

• Number of Distribution Lists (Work with Distribution List [WRKDSTL])

• Number of Nicknames (Work with Nicknames [WRKNCK] or WRKDIRE, F9)

• Defined Departments (WRKDIRE, F13)

• Defined Locations (Work with Directory Location [WRKDIRLOC])

• Use as corporate directory

• Printed version in use

• Alternative telephone list in use outside of SDD

• Directory shadowing with other systems? OS/400 or customer code? Peer-to-peer or master/slave and which systems? (Work with Directory Shadowing [WRKDIRSHD])

• Program-based updates, e.g., from an HR application

• User-defined fields (WRKDIRE, 5=View any entry, F20=Display user-defined fields, note the field names)

• OV/400 Personal directories? Number? Main functions? OV/400 menu option 7 (Directories/distribution lists), then option 1 (Personal directories), then press F4 to list all of the personal directories that you have at least *USE authority. Look for additional sources of telephone lists.)

Directory Planning

Determine what applications use or will use the SDD, such as telephone directory or human resources. Decide what applications and data are best in the SDD, in Domino, or in LDAP,

remembering that SDD and Domino can publish to LDAP but not the reverse, and that the SDD and Domino are well suited to information about people but LDAP is also suited to additional information.

Define a standard directory format. Figure 1 illustrates a sample for a local user showing the default and optional field mapping for Domino and LDAP.

In the 5250 interface, the SDD Department and Location fields have F4 list prompts and hence can be predefined, so plan the list. Also plan for Location detail fields, such as Address, and Department detail fields, such as Manager.

Consider distribution list consolidation, especially if they have been separately maintained on different systems when they could be locally maintained and referenced remotely. Check all system directories to eliminate duplicate entries. Identify the real users of the systems.

Plan for Directory Shadowing

The pattern of shadowing may be peer-to-peer or master/slave, and there is provision to exclude specified records or fields. You may wish to make the directory, which replicates with Domino, into the master SDD server containing a full worldwide directory, if appropriate.

Plan for Domino Directory Synchronization

When SDD entries are copied to the Domino Directory, one selection criterion determines which entries are included or excluded. Ensure that this selection allows for all eventualities and mixes of users. The synchronization uses a unique key, usually first and last name combined, to identify matching records. This has two consequences. First, any entries not having these fields completed will not be synchronized. Second, any Notes person document with these parameters matching an SDD entry will have a conflict. The resolution of this will depend on which is the master directory. Since a number of the SDD fields are mapped to equivalent Domino Directory fields, consideration should be given to updating the SDD before running synchronization. Normally, you can use the default mapping options in the Directory Synchronization command.

Plan for Domino Directory Replication

This uses standard Notes replication techniques and Notes administrator skills, and it should be part of your Domino planning.

Plan for your LDAP directory. Information in an LDAP directory is organized as a tree, called a Directory Information Tree (DIT). Depending on what you use the directory for, the tree may be flat, it may follow your organization’s structure, or you may create your own tree. Information is stored in the directory as objects or directory entries.

You can use LDAP as a mirror of the SDD, or you can extend the use of the directory in many ways through LDAP-enabled applications that you purchase or develop yourself. The types of objects you can create (object class) and the attributes associated with the object class are defined by a set of schema files. Refer to the AS/400 Information Center (http://publib.boulder.ibm.com/html/ as400/infocenter.html) for more information about the directory schema.

Plan for publishing SDD to LDAP. Changes made in LDAP are not published back to the system distribution directory. The types of users published from the system distribution directory are local users and remote users with a SMTP address. Shadowed users and remote users that do not have an SMTP address are not published. Publishing is to one LDAP server and one directory path.

Directory Housekeeping

After doing the audit and the plan, you should be in a position to tidy up and enhance the directory content. Here are some of the tasks you will need to perform.

• Review any existing directory shadowing and test.

• Count directory entries.

• Identify and delete redundant directory entries, such as staff members who have left the organization.

• Identify duplicate directory entries and the reasons for duplication and devise workarounds as appropriate and if possible. Here is an example:

1. To access/manage remote calendar. Use OV/400 remote calendaring.

2. To access documentation on remote system. Use BlueNotes Document Warehouse.

• Identify “genuine” distribution lists, confirm that entries are correct, and delete all others. If this can start before Directory deletions, it will speed them up.

• Review use of personal and private nicknames.

• Review the department structure.

• Review locations.

Implementing SDD Shadowing

OS/400 Directory shadowing allows you to synchronize entries in the SDDs on two or more AS/400 systems. For networks of AS/400s, all SDDs are likely to need OS/400 directory shadowing to be set up to provide a single set of directory data.

For information about directory shadowing, refer to OS/400 SNA Distribution Services V4R4.

SDD and Domino Directory Synchronization

The Domino for AS/400 directory synchronization function allows you to update a Domino directory from the SDD, the SDD from a Domino directory, or both, based on your specifications. By taking advantage of directory synchronization, you can avoid manually updating information for the same user in two places.

The Domino directory is then replicated between Domino servers via standard Notes database replication techniques. In this way, the SDD may become the basis for Notes user naming. A number of existing Notes users and Domino servers may be affected and should be considered.

Using this database document of the Directory Synchronization Database (NNDIRSYC.NSF) contains detailed implementation and configuration instructions.

OfficeVision/400 Migration to Domino

Because of the tight integration between OV/400 and the SDD, many OV/400 customers think that the SDD is part of OV/400, and that they will lose it when OV/400 reaches its ‘end-of-life’. Nothing could be further from the truth. The SDD is unaffected by the end of support of OV/400, but it has a key role to play in helping you upgrade from OV/400 to Lotus Notes.

The structure of the SDD directly affects the operation of the OV/400 to Notes migration tools, the registration of Notes users, the creation of Notes Groups, the routing

of internal and external email, the workings of LCCOV/400 calendar connectivity and the provision of document access for BNDW users.

The user’s OV/400 enrollment and system distribution directory information is used to register the user in Notes, including the creation of a mail file and personal address book. It is important to realize that the migration tools include a Notes registration process and that OV/400 users can be registered well in advance of their migration. This may be useful when Notes applications other than mail and calendars are to be implemented first.

Distribution lists and nicknames are optionally imported into the appropriate Notes databases as follows:

• Public nicknames and distribution lists to group documents

• Personal nicknames into the local address book as aliases

• Personal distribution lists into the local address book as groups

OV/400’s Personal directory function is not strictly a part of the main directory structure. It is simply a 5250-based tool for defining, creating, and reporting on simple database files. However, it is sometimes used for data such as corporate telephone lists that may be better placed in the SDD. For more information on OV/400 migration, go to www.dominodotoffice.com.

Implementing Domino Directory Replication

Domino servers can share directories via standard Notes replication function. A server’s primary Domino directory is the directory where you register the server and is associated with the server’s Notes domain. Each server stores its own primary Domino directory as NAMES.NSF but shares a common image across a domain.

Plan your replica strategy carefully, and create replicas on servers only when necessary. The more replicas, the greater the demand on server and network resources and the greater the need for additional maintenance. To prevent unnecessary proliferation of replicas, assign “Create Replica” server access to only a few administrators. Then tell users and application developers to send their requests for new replicas to these administrators. For detailed information, see the main Notes Help database.

Implementing LDAP

To install LDAP, first load OS/400 Directory Services (Licensed Program 5769SS1, option
32) and ensure that TCP/IP and SMTP are configured on your AS/400. You perform most setup and administering tasks of the LDAP server through the graphical user interface of Operations Navigator. Refer to the AS/400 LDAP home page (www.as400. ibm.com/ldap) for FAQs, links to articles, and presentations about getting your LDAP server up and running. Two Redbooks are also very useful: Understanding LDAP (SG24-4986-00) and LDAP Implementation Cookbook (SG24-5110-00).

REFERENCES AND RELATED MATERIALS

• “Configuring and Administering Your LDAP Directory Server,” AS/400 Magazine, June 1999

• LDAP Implementation Cookbook, Redbook (SG24-5110-00)
• OS/400 SNA Distribution Services V4R4 (SC41-5410-01)
• OV/400 to Lotus Notes Migration and Coexistence Web site: www.dominodotoffice.com
• Understanding LDAP, Redbook (SG24-4986-00)

SDD Domino LDAP Sample

User Profile Uid TAYLORJ Userid ShortName Cn TAYLORJ Address MailDomain TYPEXNCL Description Description Taylor, John Last name LastName sn, cn Taylor First name FirstName Givenname, cn John Middle name MiddleInitial Michael Pref. Name Cn
Full name Cn Taylor, John Michael Department Department Departmentnumber UK R&D
Job title JobTitle Title Technical Director Company CompanyName Typex (UK) Ltd Telephone 1 OfficePhoneNumber Telephonenumber +44 191 256 4406 Telephone 2 PhoneNumber Fax OfficeFax PhoneNumber Facsimile Telephonenumber +44 191 226 0252 Location Location Newcastle
Building Albany Court
Office RoomNumber Small
SMTP name InternetAddress Mail This email address is being protected from spambots. You need JavaScript enabled to view it. Text Comment

Figure 1: This local user sample shows the default and optional field mapping for Domino and LDAP.

Also Read

Practical Middleware: Architecting for the Future

Practical Middleware: Starting the Journey

IBM i 7.2: The Carrot Versus the Stick