[an error occurred while processing this directive]






How to set up your company intranet...
CUA Midrange Controller Stephen Way takes us round an intranet to understand where the AS/400 fits in.

Everyone is now used to using TCP/IP and seeing it become the lingua franca of communications. Now the protocols supported by TCP/IP are all available, together with their servers, on the AS/400, making the implementation of an intranet relatively cheap and straightforward for an AS/400 shop. In order to use the protocols effectively, an understanding of how the whole shebang hangs together is necessary, so this is by way of a brief guided tour.

A website does not an intranet make; however, it tends to be the bit that most people are familiar with, so we'll start there. If you're running an AS/400 at V3R2 or above, you've got a web server sitting on your network already, so all you need to do is switch it on. To do this, either use the Ops Navigator configurator or on a green screen session call WRKHTTPCFG. We're not going to get clever here, so you only need to change a couple of parameters to get the server up and running. Figure 1 shows the basic configuration. Start the server (STRTCPSVR *HTTP) and enter http://nnn.nnn.nn.nn/ (where nnn.nnn.nn.nn is the IP address of your AS/400) in your browser, and you'll see the IBM Default welcome screen. To add your own content, just build the site in the /home directory, and replace welcome.html with your own site home page.

I name this site

Of course, typing the numbers in is a bit of a pain, and not very memorable. What we need is a name for the site. To do this, we need to explore the protocol that is the human face of TCP/IP, Domain Name Serving, or DNS. The simplest way to give a name to your embryo website is by using the Hosts file that (if you're a Client Access user) already exists in your Windows directory. If you type 'http://name' you will reach your AS/400 web server. However, this is a little clumsy, as it relies on a file on each client being updated with the relevant host names each time a new server comes on line. What is really needed is a central database of the machine names, and this is in fact how DNS as a protocol evolved; as an amalgamation of hosts files.
Figure 1: HTTP Configuration

This is a very basic HTTP server configuration for the AS/400. In addition, you will need to put your own welcome.html file in the /home directory on the root of the IFS (Integrated File Server). Make sure that the QRMTSIGN system value is set to *VERIFY, rather than *FRCSIGNON, to prevent QTMHTTP and QTMHTP1 (the user profiles used by the browser when it connects to the HTTP server) having to sign on to the AS/400.

# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * #
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * #
HostName youras400.yourcompany.com
# #
Port 80
# #
# #
Map /* /home/*
Pass /home/*
DirAccess On
Welcome welcome.html
DirReadme Top
DirShowDate On
DirShowSize On
DirShowBytes On
DirShowOwner Off
DirShowDescription On
DirShowMaxDescrLength 25
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * #
BindSpecific Off
DNS-Lookup On
DirShowMinLength 15
DirShowMaxLength 25

The directory commands will give a directory list display in the browser, if you comment out the 'welcome' line.

DNS is, in effect, a hierarchical database of names and addresses, distributed across the entire Internet. For our purposes, we'll look at two alternatives: firstly extending the standard system down into your network, and then secondly building your own structure, completely separate from the outside world.

Extending the system:

.com Authorative server for .com
yourcompany.com DNS server at your ISP
youras400.yourcompany.com your local DNS server

In this example, any requests for yourcompany.com will be resolved from the right-hand end of the name, and result in a lookup being done on .com (assuming the request came from another domain) - this server will know about all the .com domains and so direct the request to the authoritative host for yourcompany.com - which is (probably) at your ISP. The traditional IP method of extending this would be for you to run your own DNS server, rather than your ISP, which would then know where youras400.yourcompany.com was, and direct the request there.

Of course, this means that your network has just become part of the Internet, and you probably gave up on this article back at line two, as something about grandmothers and sucking eggs comes to mind.

Sorting office

If we are going to use this method to set up an intranet, we'll need a DNS server that knows all about yourcompany.com, so it can forward the internal requests out to the Internet, but keep the *.yourcompany.com ones internal. In practice, the easiest way to do this would be to create something along the lines of internal.yourcompany.com, and then extend from there. A good example of this working is IBM, where I'm sure you're familiar with http://www.raleigh.ibm.com/, www.as400.ibm.com etc. To configure the clients to be able to see the servers in Windows (95 and later), go to the control panel, select 'Network', choose 'TCP' and 'Properties'. Enter your DNS sever address in the DNS information, and save it.

This is all good and classical IP stuff, but if you use a proxy server to access the Internet, there is another option which will cut down on the length of the internal names. It is possible to set up the Internet Options in Windows (95 and later) to avoid using the proxy for domain addresses. So if you set this option to avoid using the proxy for addresses ending *.yourcompany.com, and point the DNS entry in your networking parameters at your internal DNS server, you will resolve youras400.yourcompany.com to your internal web server we set up back in the second paragraph, but www.yourcompany.com to your external server. Using this method also allows you to set up clients so that they can see the internal servers, but not the big, bad Internet, by leaving off the proxy altogether.

What's in a name?

The second option is to set up your internal domain naming standards in such a way as to mirror the use of 'illegal' class3 IP addresses (192.168.x.x is the standard set-up). This, of course, gives belt and braces security, as you have not compromised your secure network by allowing entry using DNS. (Of course, your firewall would prevent that anyway..) To do this, you need to create a server that is the authorative host for your company's domain - continuing with the example we were using, Your Company may refer to itself as 'YC' internally, so that would be the obvious choice. Configuring the clients in the same way, (this time to ignore addresses ending *.yc) your users can then access an internal (via DNS) or external (via the proxy) server in the same way as before - but with short meaningful names. Something like:

Configuring clients with short meaningful names...

This obviously has advantages for the larger company, and is, in my opinion, easy to navigate. I would suggest each site has a 'www' server as the homepage for that site, to allow for news, maps of how to get there, and all that admin paraphernalia. Of course, it is possible to run the two systems side by side, allowing business partners to access the *.yourcompany.com servers, which may or may not be in the DMZ of your firewall, while keeping the *.yc servers for your internal network.

The AS/400, from V4R3 onward, has a DNS server. The catch is that it doesn't support BIND 8, the latest version of the standard DNS 'language'. However, it would work fine for an internal network. There is also a DNS server on Windows NT, and on Linux. If you intend to use DNS, then required reading is 'DNS and BIND', by Albitz and Liu (O'Reilly, ISBN 1-56592-512-2).

Once your DNS is up and running, you can then refer to all sorts of things by name - such as your proxy server, and your routers. Much easier than maintaining lists of numbers.

Pick and choose

So, we can now access the AS/400 web server by name. Pick a simple design for the site, and get some information onto it - there are plenty of web design packages out there. Of course, you may want to put AS/400 data onto the server, so that data in the public domain (like price lists, for example) can be accessed without the need to log on. There are several ways of doing this (for free) and plenty of packages (for a price), so let's look at the free options. The most basic is to use a cgi script, running from an ILE programme on the AS/400. This then allows you to call a legacy RPG (or other) programme to return data to the ILE programme, which then calls two APIs to format the data into an HTML table on the fly. The second method is to use net.data, which is, in effect, a macro query language. The golden rule with websites, internal or public, is to keep them current, and to get someone other than the IT department to supply the content!

The second, most familiar face of the Internet, and the one that you are most probably using in-house right now is email. If you do not currently have internal email the AS/400 comes equipped with both SMTP (simple mail transfer protocol) and POP (post office protocol). By using the POP server, users can access the AS/400 and read and reply to their email - very much in the manner of Microsoft's Hotmail service. SMTP allows the use of a mail client such as Outlook Express. Configuration of the POP3 server is very simple - just start it! You can then use POP3 to receive and read mail, but you still need SMTP as the send mail mechanism.

Figure 2: Configuring SMTP E-Mail on AS/400 for SNA distribution

Add Host Table Entry for SMTP Gateway
Option 10 from CFGTCP - add a host table entry for the SMTP gateway and call it something like 'SMTPGATE' and then CHGSMTPA to add the SMTP gateway as the router (MAILROUTER parm) and change firewall to 'YES'.

Change the AS/400 TCP/IP Domain
Option 12 from CFGTCP. Make sure your Host Name is the AS/400 name (e.g. MYAS400 or S103456) and the domain name conforms to your network standard e.g mycompany.com or London.yc (if you have your own intranet domain)
You may need a DNS server - if you don't have one, use your ISP's one.

Add a Directory Entry as Route to SMTP Gateway
Add a new entry to the system distribution directory to define the Route to SMTP gateway. The User ID and Address of this entry is later specified with the SMPTPRTE parameter for the Change Distribution Attributes (CHGDSTA) command.

The directory entry must specify the following:
The User ID and Address (USRID) can be anything, but should indicate that this entry refers to Internet or SMTP users. The suggested entry is:

Users do not need to know this address, but you must specify the same value when changing the Distribution Attributes in Configure Route to SMTP Gateway in Distribution Attributes later.

The User entry description (USRD) again can be anything, but should indicate that this entry refers to Internet or SMTP users. Suggestion:
USRD('User ID to route Internet addresses')

As User profile name (USER), \NONE should be specified
The System name (SYSNAME) can be anything different to this system's name or other system in the SNADS network (for example, you might choose: INTERNET).

The Network User ID (NETUSRID) must be the same as the User ID and Address (that is, specify USRID).

The Mail Service Level (MSFSRVLVL) must be \USRIDX. (that is, option 1 when using the Work with Directory Entries (WRKDIRE) command).

The Preferred address (PREFADR) must be:
Field Name = NETUSRID,
Product ID = *IBM,
Address Type = ATCONTXT.

Configure Route to SMTP Gateway in Distribution Attributes

The user ID and address for the system distribution directory entry added in Configure Route to SMTP Gateway in Distribution Attributes? now needs to be specified with the Change Distribution Attributes (CHGDSTA) command. In any AS/400 command line, type CHGDSTA and press F4.

Change Distribution Attributes (CHGDSTA)

Keep recipients . . . . . . . . *BCC
Use MSF for local . . . . . . . *NO
Route to SMTP gateway:
User ID . . . . . . . . . . . INTERNET
Address . . . . . . . . . . SMTPRTE


Authorities: You may need to GRTOBJAUT to the mail server framework objects in QSYS. (Try QMSF* and MSF*)

to send a document or file to a network user, send to user INTERNET on system SMTPRTE, using the INETADR field for the recipient - 'someone@somewhere.com'

Once you have email running across your network, it may be desirable to email notifications or reports directly from applications. The implementation of SMTP for the AS/400, linked into SNADS, has made this possible. There is not space to go through the entire details for this in this article, but a basic setup guide for SMTP is shown in Figure 2.

By setting up the AS/400 to send email and allowing the AS/400 web server to access data, you can allow users to generate reports and send them to themselves without logging on, always assuming that this is desirable.

And the rest

Apart from web serving and email, what else can we do on the intranet? There are many applications that are current on the Internet that may have some use within your organisation. For instance, if you wish to publish documentation, then the best way to control that is to publish it using the Portable Document Format, or .pdf. To read this, clients will need the latest version of Adobe Acrobat - so set up a software download site internally and cut down on the traffic through the firewall. The same can be done for the latest patches for client software.

One Internet protocol that does not appear to be supported on the AS/400 as yet is Network News Transport Protocol, or NNTP. NNTP allows discussion forums to exist, known as Newsgroups, or Usenet, on the Internet. Discussion groups like these may be useful in collaborative projects, and as technical forums, so it would be nice to be able to do something like this. Fortunately, it is possible to run chat room software on the AS/400 which will perform a similar function - there are (to my knowledge) two products that do this, PeekPlus from Bytware, Inc (which is really a helpdesk product, but contains a chat-room type environment) or, for Domino users, PlanetTalk.nsf is a Domino chat room environment. I have not used either product, so this is by no means a recommendation.

As you can see, the AS/400 has everything you need to dabble your toe in the intranet waters. Once you start publishing information and opening up communication in this way, you will find that many more applications will suggest themselves to the users. If the load gets too much for the AS/400, or you want to use DNS properly, the simplest and cheapest way is to load up a Linux server on an old 486 (which will be quite powerful and robust enough), and investigate the possibilities of that operating system, as it will complement the AS/400 nicely and provide both an industrial-strength DNS server, and the Apache web server to take the non-AS/400 data pages of your site. The most important thing is to never regard an intranet as 'finished', but as an immediate, changing medium; so publish and be damned.

Further Reading

IBM Redbooks
'A Cool Title about The AS/400 and the Internet' (SG24-4815-01)
'AS/400 e-Commerce: Internet Connection Servers (SG24-2150-00)
'AS/400 Electronic Mail Capabilities' (SG24-4703-00)
'More Cool Things than Ever' (SG24-5190-00)

Stephen Way is midrange controller of the IBM CUA and a senior IT manager with a major British multi-national manufacturer, responsible for AS/400 systems on three continents. He has worked with IBM midrange systems for fifteen years and is heavily involved in the implementation of Intranet and e-business applications. waysd@matthey.com