|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.
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * #
# HTTP CONFIGURATION #
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * #
Map /* /home/*
# *** DIRECTORY LISTINGS *** #
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * #
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:
||Authorative server for .com
||DNS server at your ISP
||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.
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.
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.
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:
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
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
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,
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*)
SNDDST to send a document or file to a network user, send to user INTERNET on
system SMTPRTE, using the INETADR field for the recipient - 'firstname.lastname@example.org'
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.
'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. email@example.com