Email Bridges to the 21st Century

SNA Distribution Services (SNADS) is the email engine of Advanced Program- to-Program (APPC), allowing messages and files to be transported through the Advanced Peer-to-Peer Networking (APPN) network. Simple Mail Transfer Protocol (SMTP) is the Internet equivalent, available to Microsoft’s Internet Information Server, Microsoft’s Exchange Server, Lotus Notes, cc:Mail, and a growing number of email systems. The question facing many AS/400 SNADS administrators is a simple one: How can the AS/400 swap mail with these Internet-capable post offices? The answer is a SNADS/SMTP bridge. In this article, I’ll show you the step-by-step process of building this bridge.

A Little Background Music, Please

Starting with V3R1 of OS/400, mail-related processing on the AS/400 was rewritten to use a new tool called the AnyMail/400 Mail Server Framework (MSF). The MSF is an extendible set of routines tied to the Work Management function of OS/400. MSF provides exit points and APIs that allow separate programs to process and route mail messages and file attachments. Starting with V3R1, SNADS on the AS/400 was rewritten to use the MSF.

At the same time, OS/400 was provided with SMTP. It too uses the MSF to process messages. To create a SNADS/SMTP bridge, we’ll connect the services of SNADS and SMTP through the MSF using various specialized SNADS directory entries and SMTP alias configuration tables. The process takes only about 25 minutes of configuration, and no custom coding is required.

Is SMTP Loaded on the AS/400?

The first step is to ascertain that SMTP has been loaded on the AS/400. SMTP runs in the QSYSWRK subsystem, so the steps for finding it are simple. At an OS/400 command line type DSPSBSD *QSYSWRK. Select option 7 to display the routing entries contained in the QSYSWRK subsystem. What you will be looking for is a routing entry associated with the QCMD program with a Compare Value of SMTPROUT. The screen will look like the one shown in Figure 1. This indicates that SMTP is loaded on your system. If it’s not there, you’ll need to talk to IBM Support to see what PTFs you’ll need to get to a supportable level of OS/400.

Creating a SNADS/SMTP Distribution Queue

Next, you’ll need to create a distribution queue to send information between SNADS and SMTP. To accomplish this, branch to the main SMTP menu on the AS/400 by keying the Configure TCP SMTP (CFGTCPSMTP) command and pressing Enter. Then, select option 12 to configure your distribution services. At the submenu, select the option labeled 1=Distribution queues. This will display the Configure Distribution Queues screen, showing all of the distribution queues that have been created for your AS/400. To add a distribution queue, press the F6 key. This will bring up a prompt that looks like Figure 2.

The queue you’re creating is not a normal SNADS distribution queue, but one that is unique to SMTP. The distribution queue name must be QSMTPQ, and the type of queue must be *RPDS, which stands for Remote Process Distribution Services. Make the Remote location name TCPIPLOC and the APPC mode parameter *NETATR. The remote net ID should be *LOC, as should the local location name. Press Enter and a new distribution queue will be created.

Now, you’ll need to create a routing table entry to provide a conduit to the QSMTPQ distribution queue. By pressing F12 from the Configure Distribution Queues screen, you’ll be returned to the previously mentioned Distribution Services submenu. This time, select option 2=Routing table. This will display the Configure Routing Table screen. Again, press F6 to create a new routing table. In the System name/Group parameter field, key in TCPIP. Add a description, as shown in Figure 3. In the parameters under Service level, key QSMTPQ into each of the Queue name parameters. There should be four Queue name parms. Press Enter to add this new entry, and then press F12 to exit.

Beyond Queues and Routing Tables

You now have a basic mechanism for passing mail to SMTP: a distribution queue named QSMTPQ and a routing table connecting to it called TCPIP. What you need now is a means of sending your mail out of SNADS and directing it to this new QSMTPQ distribution queue. You’ll create that mechanism by using the SNADS directory.

In SNADS, every mail recipient must have a directory entry that references both a unique user ID and a user address. This is the same idea as an address book. In our example, you’ll want to set up in the SNADS Directory a new entry that will direct SNADS mail to the QSMTPQ.

At the Configure TCP SMTP menu, option 10 allows you to work with the SNADS directory entries. Here, add a new directory entry by placing a 1 in the OPT field of the Work With Directory Entries display and pressing Enter. Key in the user ID as *ANY and the user address as TCPHOST, as shown in Figure 4. By using the reserved word *ANY, you’re telling SNADS to use this directory entry for any mail the sender transmits to an address of TCPHOST. In other words, you want all mail that is destined for SMTP to pass through this single directory entry.

Key in an appropriate description for this directory entry, and then—most importantly—key TCPIP into the System name/Group parameter. As you’ll recall, TCPIP is the name of the routing table entry we created in the previous step. Press the Enter key, and your SNADS setup is complete.

A Rose by Any Other Name . . . Is an Alias

Now, you have a directory entry that allows your SNADS users to address mail (*ANY at TCPHOST), a routing table that intercepts and directs the mail (TCPIP), and a distribution queue that holds the mail until OS/400 sends it out the door.

But how, you may be asking, are the SMTP mail addresses (such as This email address is being protected from spambots. You need JavaScript enabled to view it.) mapped from the *ANY TCPHOST directory entry identified for SNADS? The answer lies in the AS/400’s implementation of alias tables.

On the AS/400, an alias table is a cross-reference list that associates SNADS directory entries with SMTP user IDs and SMTP domain names. There are two types of alias tables on the AS/400: a system alias table that is available to all users and a personal alias table that is available to only the current sender.

When the OS/400 MSF processes the mail sent to the QSMTPQ distribution queue, the TCPIP routing table we’ve just created tells it that this mail is destined for an *RPDS. The MSF then looks first to the user’s personal alias table to find an appropriate SMTP association and—if none is found—looks in the system alias table for an entry. When it finds a SNADS user ID and address that matches, it substitutes the SMTP user ID and the SMTP domain name. Finally, the MSF passes the resolved name and address onto the SMTP server program, which sends it out the door across the TCP/IP network.

To create an alias table entry, use option 1, Work with system alias table, or option 2, Work with personal alias table, from the Configure TCP SMTP menu. A sample alias table entry is shown in Figure 5.

Note that the SMTP user ID can be up to 24 characters in length, while the original SNADS user ID is limited to eight characters. This is the address translation that allows you to send mail to users on remote systems whose names exceed the SNADS limitation of eight characters. Second, note that SMTP domain names can be considerably longer—up to 255 characters in length. Keep in mind that the entire length of the address—SMTP user ID and SMTP domain combined—can be no longer than 255 characters.

Here, as in the SNADS directory entry, you could create an alias that maps all SNADS users to a single SMTP address if you wanted. To accomplish this, you’d enter a SNADS user ID/address of *ANY TCPHOST. You might want to create such an address and associate it with an SMTP address of postmaster@domain_name, so that the administrator on the SMTP host could sort through any unresolved addresses.

Finally, note the SMTP route field. You might want to use this field to set up a routing path on the TCP/IP network in order to get the mail to the appropriate TCP mail server.

The SMTP domain name is by far the most important piece of information in the alias table because it is used to route mail both to and from the SMTP host. This domain name must match the local domain and host name entries established for the TCP/IP protocol description. Otherwise, the SMTP server program will choke when it starts to process SNADS distributions.

Verifying Your Domain and Host Names

To verify that your alias table entries are using the correct domain name for the AS/400, you need to go to the Configure TCP menu. Do this by typing CFGTCP on an OS/400 command line and pressing Enter. Select option 12, Change local domain and host name. See Figure 6 to see a typical setup.

SMTP uses a concatenation of host name and domain name to find the associated mail recipients. So, if I’m sending mail through SNADS from my AS/400—which has a host name of MCEDIT and a domain name of midrangecomputing.com—my address in the alias table should be userid@ mcedit.midrangecomputing.com.

SMTP Server Start-up Parameters

No doubt, you’ll want to modify how SMTP is started and how often it sends mail out of the QSMTPQ distribution queue. To do this, key in CHGSMTPA and press Enter. You’ll be presented with a screen that controls the SMTP server program’s start-up program.

If you want the SMTP server program to be automatically loaded each time the TCP services are started, change the Autostart parameter to *YES. Here also is a spot to control how often SMTP will send or retry a mailing; this is shown in Figure 7.

Finally, to actually start SMTP for the first time, you’ll need to restart the AnyMail MSF. To do this, key in ENDMSF and press Enter. As soon as OS/400 tells you that the MSF has successfully ended, restart MSF by keying in STRMSF and pressing Enter. You should be warned, however, that ending MSF also automatically disables the entire SNADS system, interrupting the transfer of all distributions to and from your AS/400. Before you end and restart MSF, you should be certain that your users are aware that you will be tampering with their mail service for a short while.

After MSF has been restarted, you’ll want to start up the SMTP server and run a test. Key in STRTCPSVR *SMTP and press Enter. If your configuration is solid, SMTP should start without error. Look in the QSYSOPR message queue to be certain that it didn’t abort. If, for some reason, things didn’t go so smoothly, you’ll find a job log with appropriate error codes in the QEZJOBLOG outque.

Testing the Bridge

Testing the SNADS/SMTP bridge is pretty simple. Even if you don’t have OfficeVision, you can key in SNDDST and press F4. A sample display is shown in Figure 8. If your alias tables are configured properly and the SMTP server is started, you should be able to send a SNADS message to a person on the other side of the bridge. Figure 9 shows how the message is received by the Windows 95 Exchange Internet Mail client.

Some Final Thoughts

Iif you have trouble sending mail back across the bridge to SNADS, chances are the domain name and host name of your AS/400 are not known to your remote name server or your PC’s LMHOSTs file. Check again to make certain your alias tables are correctly concatenating your SNADS user ID and system name. This can take some time to debug.

SMTP on the AS/400 is a powerful tool. If you’re wondering how to get Internet mail to and from your SNADS users, a SNADS/SMTP bridge is the most cost- effective means. Best of all, it’s free on version 3 of OS/400.

Figure 1: Confirming SMTP in the QSYSWRK Subsystem Figure 2: Creating an SMTP Distribution Queue

Figure 3: Add Routing Table Entry Figure 4: Adding SNADS Directory Entry

Figure 5: A Sample Alias Table Entry Figure 6: Host and Domain Names on the AS/400

Figure 7: SMTP Configuration Figure 8: Sending a Simple *MSG with SNADS

Figure 9: Receiving a SNADS *MSG in Microsoft Exchange

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

RPG Academy - Database Modernization: Entity Relationship Diagrams

RPG Academy - Database Modernization: A Bit of Database Theory

Talking About Modernization Isn’t Good Enough