« Celebrating a Software Salvation | Main | Making Directories Do Up To Date Duty »

March 22, 2019

Making LDAP Do Directory Duty

DAP
Explore a 3000 feature to see how a little LDAP’ll do ya

NewsWire Classic

By Curtis Larsen

When you think of LDAP, what do you think of? You’ve probably heard about it — something to do with directories, right? — but you’re not quite sure. You’ve heard some industry buzz about it here and there, read a paper or two, but perhaps you still don’t quite know what it can do for you, or how it could work with an HP 3000. Hopefully this article will de-mystify it a bit for you, and spark some ways you could use it in your own organization.

MPE currently has limited support for LDAP, but the support is growing. Aside from the OpenLDAP source ported by Lars Appel, HP offers an LDAP “C” Software Development Kit for writing MPE/iX code to access directories, er, directly.

LDAP stands for “Lightweight Directory Access Protocol.” In a nutshell, it allows you to create directories of information similar to what you would see in a telephone book. Any information you want to store for later quick retrieval: names, telephone numbers, conference room capacities, addresses, directions — even picture or sound files. Using directories such as these is an incredible time-saver (can’t you think of company applications for one already?), but LDAP can do so much more. The directories you create are wholly up to you, so the sky’s the limit.

At this point you might be saying “Great, but why not use a database for this stuff?” That’s an excellent question, and in truth, there is some overlap in what you might want stored in a database versus being stored in a directory. The first and foremost difference between them is that a directory is designed for high-speed reading (and searching) — not writing.

The idea is that, generally speaking, a directory doesn’t change much, but quickly reading its information is a must. Understand that this doesn’t mean that directory writes are at all bad — they’re just not structurally designed to be as fast as reads are.

Databases also require more in the way of overhead: high-powered servers and disks, (usually) high-priced Database Management Systems — which one will be best for you? — and highly-skilled, highly-paid DBAs to keep it all happy. (Our DBA said I had to mention that part.)

LDAP directories are generally simpler and faster to set up and manage. LDAP is (also) a common client-server access standard across many different systems. You don’t have to deal with the outrageous slings of one DBMS, or the delightful syntax variations in SQL or ODBC implementations. LDAP directories can even be replicated. Copies of directories, or just sections of larger directories, can be stored on different servers and updated (or cross-updated) periodically. This can be done for security (“mirrored directories” — one here, one elsewhere), performance (all queries against local entries on a local server), or both.

Let’s dig more into what LDAP directories can do. I won’t get into any real technical details about syntax, history, specifications, etc. Better explanations of these things have already been written by folks far more knowledgeable than I am. You’ll find some links at the end of this article that you can use to understand more.

Practical LDAP ideas

For most, adding all the different network and systems logons can be a tedious task. Add to that the different options on each system (like VESoft security on e3000s) and you have a necessary, but time-consuming chore. With an LDAP directory maintained by your Human Resources folks, regular batch jobs can query that directory and perform the add/change/delete maintenance automatically. The jobs can even update the directory with the new logon information.

Wouldn’t it be nice to have different batch jobs send various e-mail (or faxes, or pages, or…) to different folks about something? Using that same HR LDAP directory, any job can look up someone’s current contact info and send them that message, page, fax, etc. Your Admins, Ops, and Help Desk folks are now on to bigger things, and no more need for maintaining separate KSAM or Image tables on the HP system.

Here’s a bit of a mind-bender: How about “personalized printing”? Same as the last example, but what if an LDAP directory stored the list of printers your new hire will (generally) use as well? Now all your systems — 3000 included -— can direct printed output based upon a person — not a destination. If they change locations, just change the directory entry. We can get even more esoteric and say “logical entity” instead of “person.”

Suddenly, you have the ability to address output to groups of people (“Accounting’s printer,” fax or e-mail addresses), other computer systems, etc. Get a little wilder and you can even have the LDAP directory describe the format for the addresses used. (Batch job to LDAP server: “I have this color print file on legal paper for ‘Bob’ — where should I send it?”) Really, it’s just a small step past device classes.

Interesting stuff, eh? All of these things are possible this very instant. Yes, they do require some preparation and support work (but then every new technology does). Let’s try another idea:

You say you want system-wide variables? How about enterprise-wide variables? Using LDAP, practically any type of system can share information with any other system. You would want those variables to be fairly static (that “reads are better” thing), but certainly a central repository for something like cross-system daily scheduling information (dates don’t change much) or summary totals could be a handy thing. “Variable” states can be retained as long as needed, too.

Okay, let’s explain a little more about that last one. LDAP directories are made up of basically three things: containers, variables and values. Containers can hold either variables or other containers, and variables have values. (There’s a little more to it than this, but it will hold us for now.) Using those elements, the LDAP directory you create looks very much like the classic tree structure used in most file systems (like Unix) or even DNS.

An example of this might be a “root” container for your company, holding a container object named “USA,, holding one named “New York.” In “New York” is a “dept.” container named “Accounting,” and in that is one named “P. Strings.” That object type might be “person,” and it, in turn holds all sorts of contact information. You could just as easily have a container named “Jobs,” holding one named “Schedule X,” wherein we could find lots of information on Schedule X, like its completion time and status.

For the object-oriented among you, you can also think of a container as an object, and variables as properties of that object. This makes LDAP very workable with OOP. Perl likes it, Python likes it — shucks, even C++ thinks it has class.

This idea is a bit stretched, but: persistent, cross-platform objects/object classes. You can use an LDAP directory as a base class template library and retrieve certain directory sections into a program for later use. Use them as a library of other things as well.

LDAP directories fit DOM fairly well, so you can use LDAP to store DTDs and other work with XML. (“Does anyone know where the DTD for getting EDI XML data from ‘Foobar, Inc.’ is?” “Yeah, It’s the LDAP directory under “DTDs, EDI, Foobar, or just do a search for ‘Foobar, Inc.’”.

I hope this article gives you some ideas about what you might want to do with an LDAP server or two accessed by your HP 3000. LDAP, like Samba and Apache before it, is yet another example of innovative technology working upon the rock-solid stability of the HP 3000 system. File and print server, web server, and now LDAP — who says the 3000 can’t share?

06:27 PM in Hidden Value, Homesteading, Newswire Classics | Permalink

Bookmark and Share

Use our search engine to find 20 years
of HP 3000 news and articles

Comments

Comments

The comments to this entry are closed.