Connecting your HP3000 to the Internet
By the numbers...

Almost everyone has heard of "the Internet." It's the world's largest computer network. Over 2 million computer systems and millions of users at last count; and growing so fast it's difficult to even get an intelligent estimate lately.

The Internet started out as primarily a network of Unix systems, since the first public domain TCP/IP stacks were available on those platforms (others as well, but for the sake of argument, the Unix world is where the Internet found its' roots). Even today, people assume the Internet is a network of "Unix" systems. While I don't know of any solid statistics, it's fair to say that the Internet is as diverse today as, well, as the world of computers. There's software out there to access the Internet for every platform from DOS, Windows, and Macs, to IBM's big iron, and almost every box in between. Yes, the day is here, even our HP3000s can "reach out and touch someone."

Why would we want to connect to the Internet?

Everyone knows that the shortest distance between two points is a straight line. But what about 5, 10, 100, or 1,000,000 points? That's a lot of lines. If each of those points is a business entity you deal with then it's easy to see that connecting more than one or two requires quite an infrastructure. Communications lines all over the place. And with each new line, comes a dozen new potential failure points. Even many relatively large organizations are realizing that maintaining such vast networks is not cost effective for them to do on their own. The talent, time, and resources required to keep these networks operational can really bury the bottom line.

Enter the Internet. The world's largest computer network. With hundreds of network providers all fighting for your business, and with all their networks already inter-connected. With the Internet reaching every country in the world, chances are wherever your organization is, there's a means of tying into the Internet.

No longer do you worry about maintaining multiple redundant network links. No more delayed production scheduled because some tractor jockey in Montana just plowed through your phone company's fiber cable. No, you have one short link per location to worry about. A "hop" from your site to the Internet provider; the provider worries about all that. Of course, since the Internet itself is made up of so many redundant links anyway, even they won't lose too much sleep over it. You have your redundant links, your network encompassing every business location; you even have a means for customers of associates to communicate with you electronically - without tapping into your "private" network!

If that's not enough, HP3000 shops should be particularly interested in the ability to contact your third party vendors for technical support, as well as hundreds or thousands of other HP3000 users out there encountering (and solving) the same problems you do every day. More vendors every day are discovering that the Internet provides a unique and very effective means of responding to customer (and potential customers) questions and problems. Electronic messages are a convenient and time-saving means of getting questions answered; much less disruptive and time-consuming for engineers than telephone conversations, and often more thorough. Written messages can be responded to point by point, and turnaround is often quicker than traditional technical support methods. Actual job listings or files can be attached to messages to aid in diagnosis, and both the vendor and customer can often save money by using an Internet link versus the traditional rounds of long-distance phone-tag. As an added bonus, sites with HP3000s reachable via the Internet can allow technical support engineers to "dial-in" through the network; saving a potential long-distance call for the vendor, eliminating the hassles of setting up modems for dial-in access, and often providing a higher-throughput line to speed up the engineer's access; especially useful if files need to be transferred.

If you still have any doubt, talk to someone that susbscribes to the HP3000-L discussion group. This is an ad-hoc user's group of HP3000 users, managers, and software vendors from around the world, all contributing questions and solutions to problems encountered or tasks delegated. The list is maintained by Jeff Kell at the University of Tennessee at Chattanooga and any person with access to the Internet is free to subscribe. Post a difficult question or just observe the questions and answers of others on the list. HP3000 experts from around the world, including some very innovative users, programmers, vendors, and many HP engineers and lab people all contribute frank and often invaluable solutions to each others problems. (For more information on the list or how to subscribe, contact myself; rcb@3kassociates.com, or Jeff Kell; jeff@utcvm.utc.edu and we'll be happy to provide you with any information we can).

To give you an idea of who's out there already, see the attached list of some of the HP3000 vendors currently on the Internet (the list is subject to change, but included all the vendors I knew of at the time of this writing. My apologies to any I missed).

What an HP3000 needs to go online

I'm going to describe the process of connecting your HP3000(s) (and/or the network they're attached to) to the Internet, and will guide you through a step by step process with examples from a working setup I installed myself (so YES, it CAN be done). And by the way, it DOESN'T cost a fortune. In fact the entire setup I used cost me $115 in hardware (I already had a PC running Windows that I shared), a $99 software package, a $99 installation fee, with a recurring monthly cost of $49 (with unlimited volume and up to two hours of connect time per day). I'll lay out some costs for other options as well, including the dedicated (dial) line with 24 hour/7 day access and unlimited traffic. Software charges vary depending on what you want to DO on the 'net, and I'll describe some of those figures as well.

First, the hardware you'll need. I'll assume you have an HP3000 system. If not, go pick one up. Really. They're a good deal.

If you're running MPE/iX version 5.0 or later, skip the requirements here. You have all the hardware and operating system software you need. For classic HP3000s (non RISC systems) you'll need a LANIC card if you don't have one already. They're relatively easy to find used, and can be had for under $500 if you shop around (I've bought cards for 37s, Micro/3000s, and 70s and never paid over $700). MPE/iX systems already come with a LANIC card (the card that plugs into your DTCs *is* a LANIC in case you didn't know). MPE/iX systems on current releases of the operating system (4.0 or later) can use that single LANIC to handle both DTC traffic AND an Internet/network link. You DON'T need a second card unless 1) you have a very old card and don't want to get its firmware upgraded for some reason, -or- 2) you have such a high volume of traffic on your DTCs (this would be ALOT of DTCs) that for performance reasons you want them separated, -or- 3) for security or operational reasons you want the network segments isolated (there ARE exceptional cases where this may apply).

Operating system software. You'll need the "LanLink" software. You can get it for both MPE/V and MPE/iX systems; delete the option for the hardware if you already have the card. If you already have NS/3000 -or- ARPA services (FTP) on your HP3000, then you already have it. So your pre-requisites here are (a) the Lanic card, and (b) the Lanlink software package. See illustration 1. After this, you can pick and choose the software packages/services you need. A note: HP's telnet on your HP3000 doesn't have anything to do with any of this - it's completely DTC resident and doesn't affect your HP3000 one way or the other (the contributed telnet client by Dave Elward for the HP3000 DOES require Lanlink however, and is a nifty, and free, program).

At this point, you have the physical link established and the low-level operating-system software that will let your HP3000 talk to the world (or at least your local network). Of course, you need a physical "link" (wire) that ties your network to the rest of the world. Now your "network" may be just a single HP3000 or it may be thousands of connected computers; whatever the case, somewhere on that network of wire, you need a device that links you to the "outside world" (the Internet). This device might be a dedicated "router", or it might be a computer which is running routing software of some sort in addition to other tasks. There are many options available, and many factors to consider in choosing a "router" if you don't already have one. I'll describe some of the major factors to consider.

Choosing the type of link

First, there are two general kinds of communication with the Internet: packet level routing, and UUCP batch file transfer. The choice between these two options also defines the types of services, or Internet access, you will be able to provide to users on your HP3000 (as well as other users on your network). In general, UUCP (Unix to Unix Copy Program) is not as flexible an option as it is a batch oriented protocol, and only allows file transfer, remote unix shell (not available from HP3000s anyway), and e-mail access; it is however often a very inexpensive means of connecting to the Internet, and can be very secure. Packet level routing on the other hand actually "extends" your network so that any network service (or program) can talk directly to any other computer directly connected to the Internet; the link is much more flexible, but requires special security considerations for sites that do not wish to be entirely "open" to the world.

UUCP is a protocol that comes with most Unix systems, and is also available for PCs and several other platforms. It was designed to work over dial-up links, but can also function over leased lines or network links. UUCP works by accepting files (data files or e-mail messages) to be transmitted, saves them in a special queue, then depending on the schedule established by the administrator, a physical connection is made (or an incoming connection is accepted from another system if so set up) and files are transmitted between the two systems. An important consideration in using UUCP to link your network to the Internet though is that the system you use to run UUCP must be able to "route" traffic between your other systems on your network (using whatever protocol they use) and translate that traffic to UUCP to be transmitted. Since UUCP is not the native transport of the Internet, you must work with a system on the other end that also translates UUCP back to native Internet protocols (see figure 2). The UUCP packages I know of on PC platforms will pass data between the PC (which runs the UUCP software) and another UUCP compatible system, but WON'T accept e-mail or files using the Internet standard for e-mail (SMTP) or file-transfer (FTP) and send it on out "onto the net." The only UUCP implementations I know of which do this are Unix implementations running multiple protocols. (Unix' "sendmail" package will route e-mail between UUCP and SMTP links if so configured and if the necessary links are available.)

Packet level routing on the other hand, only requires a router or device acting as a router to store and forward IP packets (there is no translation involved, with the exception of some packet-header reformatting and compression done by the SLIP and PPP protocols). Since the Internet is based on IP, if you implement any of the Internet services (applications) on your local network a router will allow any of these applications to communicate seamlessly with any corresponding application anywhere on the Internet.

Dial On Demand

For UUCP links, dial on demand is fine; in fact, UUCP was designed for this kind of link and is rarely used over full-time connections except in odd cases where a variation of UUCP is used that actually runs on top of TCP/IP. UUCP's batch orientation makes dial on demand (or dial up by schedule) a perfectly feasible means of linking networks for relatively low volume file transfer and e-mail transmission.

While TCP/IP links can also function very well on dial-up lines, relatively long initial connection delays in dial on demand links can be a bit of a nuisance. Link speeds are less of a problem since new V.fast technology can provide effective rates of up to 56kb over standard phone lines. One area that can be a problem for dial on demand TCP/IP links is that typically one side or the other is designated as the side that must dial up and establish the link; with most Internet providers, this would be on your end. This means that traffic out on the 'net that might be trying to reach your machines can be delayed or refused if you don't happen to be connected when they try to reach you. Of course, you may not WANT inbound traffic reaching your network, but at least in the e-mail world, if you want to be connected, you need to make arrangements for your e-mail to be accepted and held somewhere for you when you're not online. Some Internet providers take care of this for you, and set up mail receivers for you that accept e-mail on behalf of your network when you're not connected, then pass it all on to you when you do link up.

Leased or Dedicated Lines

For a true "full service" Internet link, you need a dedicated line of some sort between your network and your Internet service provider. This dedicated line need not be a "leased" phone circuit; many Internet service providers provide dial-in link speeds of up to 19.2kbps with some beyond that. The differences between dial-up and leased line links today comes down to cost and reliability. Full time dial-up links can provide close to the same quality as low-end leased-lines with today's high-speed error-correcting modem technology. Full time dial-up is a link using a regular non-dedicated phone line that dials up a particular number and stays connected all the time. A non-dedicated business line runs about $30 per month in my neighborhood with a $.10 per call charge, and in most areas of the country you can find an Internet provider with a local access number; barring power fails or other interruptions where the modem may have to dial back to reconnect the line, you should see the costs staying pretty static and reasonable.

A leased line on the other hand usually carries some manner of warranty with it, or a guaranteed service level, or at least a number to call and yell at if it breaks, along with a fixed price (albeit usually a relatively expensive one). Leased lines also can provide a "cleaner" link due to the lack of switching noise and other neat tricks, and can provide links capable of throughput higher than the best dial-up modems can support; in particular if your requirements are in excess of 19200 baud (or 28000 using V.Fast/V.34 modems) you're going to need to use a leased line (be it using a phone wire or a microwave link or satellite terminal). Your choices are numerous and cover a wide range; leased analog, leased digital, frame relay, and even ISDN. Line throughputs range from 9.6kb to several megabits per second (T1/T3).

If you do choose a dedicated link, an IP routing link is really the best choice. Though you can run UUCP over a dedicated line, doing so really only limits your options. UUCP will also run on top of TCP/IP, but not vice versa. With an IP routing link, you give yourself more options, and will probably see better throughput on the link.

Security

Finally, security is an important concern for some sites, and a device that allows some measure of security restrictions can be a critical factor. Almost everyone has heard horror stories of "hackers on the Internet", and these horror stories, typically recounted by those who don't understand the actual details of the situation, have dissuaded more than a few organizations from going "online". This is not to say there are not risks; nor is an HP3000 immune from all of them, but there ARE simple and effective ways to completely prevent unauthorized access (hackers!), and if they're implemented thoroughly they are very effective.

Protection from the Internet requires a basic knowledge of what you're up against. Basically, all Internet protocols communicate between two computer systems equipped with IP network software by specifying a source network address, a destination address, and select special "services" or "protocols" by providing a protocol number; all specialized Internet protocols have reserved numbers. (If you're new to this, there are several good books that will give you a more detailed explanation of the various protocols and how IP works.) Your primary defense from the Internet bad guys lies in the capability of most routing devices to "filter" the packets it lets through based on either addresses or protocols. In the HP3000 world, the configuration defaults also prevent much "foreign" access, and can also provide an effective barrier, though at this level it is an all or nothing barrier; the HP3000 has no capability to selectively enable or disable specific protocols other than turning them completely off to all (non-local) users, and has no capability whatsoever to disable or enable access by network address.

The primary concern of any commercial site connecting to the Internet is to prevent unauthorized access to the organization's internal resources (those that the organization does not wish to make available to the "general public"). There are two major concerns here that impact HP3000s in particular; virtual terminal (VT) access and telnet access.

Currently, telnet access to the HP3000 is only available if you specifically purchased that option on your DTC(s). Users use the Internet protocol called "telnet" to establish a network connection between their PC or local host and a suitably equipped DTC, which then makes a connection to the HP3000 for them. (The protocol the DTC actually uses to talk to the 3000 is a lower-level protocol that cannot be routed through the Internet so you need only be concerned with the higher level "telnet" protocol). Telnet is a VERY common protocol used throughout the world, and you can count on many millions of people out there having the capability to telnet to you if you don't take the necessary precautions.

Securing your HP3000 from telnet access means securing your (telnet-equipped) DTC from outside access. Your most effective means of doing this is to 1) place the telnet-equipped DTCs on a secured subnet (not reachable from anywhere else), or 2) set up your router to either disable access for telnet services (protocol #23 decimal) entirely, or define access for specified network addresses only. It is also possible in some configurations to configure only specific HP3000 (or other) hosts to be reachable by the DTC itself, thus potentially allowing inbound telnet to the DTC, but restricting where users can go once connected to it.

Something else you should know about your DTCs; each DTC port is separately addressable via TCP/IP and a formula based on the card number and port number on the card. By establishing a TCP/IP connection to a DTC and specifying the protocol number (or service number) based on that formula, an outside user could "open" a link to a DTC port. The possibility for trojan horse programs exists here so caveat emptor. You may want to go so far as to allow only very specific protocols through your router (vs. many sites' default of letting anything not specifically excluded through).

Quite possibly more of a threat to HP3000s on the Internet is virtual terminal (VT) access. VT is the protocol used by HP3000 to HP3000 Network Services (aka :DSLINE) or by the popular terminal emulator's VT access. This protocol allows a user to get a prompt on an HP3000 via a network connection just like the Unix world's telnet capability. While VT is less common than telnet, it is more of a threat to HP3000 sites in that the capability to access an HP3000 via VT is a standard part of any HP3000 equipped with HP's Lanlink software (which you automatically have if you have either NS or Arpa Services on your HP3000). VT is especially a problem on MPE/iX systems since they, unlike MPE/V systems, don't even require the configuration of "VTERM" ports on your HP3000. MPE/iX kindly creates new logical device numbers for virtual terminal connections as needed; this means that securing logon access by logical device number is useless - you never know what device number will be used for a given person or system. On modem ports you can shut down a port after a certain number of invalid password attempts; you have no such option with VT sessions, short of manually shutting down your entire network link. Also, security packages with secondary password capability often have trouble distinguishing between VT sessions coming from interactive users and remote sessions originating from batch jobs (via :DSLINE/REMOTE HELLO commands). Secondary password prompts usually wreak havoc on virtual sessions created by remote jobs, and often end up being disabled. At present, HP still provides no means for applications to determine if their session was created by a remote job... Maybe someday.

Like telnet, if VT access is a concern, your best solution is to restrict access via that protocol to certain networks, or disallow it from coming through your router at all. The VT protocol comes in as protocol number 1537 (decimal). Remember that if your HP3000 is connected to the Internet and you haven't specifically disabled it, anyone can VT to your machine and get a login (":") prompt.

If you also have FTP (Internet's file transfer protocol) on your system, or SMTP (Internet's e-mail transport Simple Mail Transport Protocol) you may want to restrict those protocols as well. FTP uses protocol 21 (decimal) for control connections, and SMTP uses port 25 (decimal). E-mail is usually not a security problem and unless necessary for administrative reasons is not normally restricted. FTP access on the other hand can present problems if anonymous access is allowed or minimal security is in place and there is data on your system which you don't want "outsiders" to have access to (or to be able to write over as the case may be). The FTP server leaves you at the mercy of a single password; secondary password prompts or security systems are not applicable, and once access is gained, FTP clients have file access rights as defined by MPE's file access matrixes. Unless you're prepared to offer anonymous FTP access, securing FTP access to your local network (or at least specified networks) may not be a bad idea.

Other protocols like Gopher, NNTP (Network News Protocol), WAIS, and information access protocols like some of the new client-server database protocols might also warrant some security review, depending on the information you want (or don't want) to provide access to.

We would be remiss if we didn't mention the biggest threat to computer systems these days; viruses. Now, there has yet to be a (publicly) reported virus for the HP3000 system, though as MPE becomes more POSIX compliant, the possibilities increase. Viruses and worms (like the infamous Internet worm that affected Unix systems a few years back) are easily and rapidly spread through the Internet. If you give your users access to the Internet and the ability to retrieve files, then careless users are likely to bring back viruses despite your best administrative efforts. Mandatory or automatic virus scanning of servers and workstations can minimize damage, but education and comprehensive administrative policies are the best protection.

Being Sociable

Now that we've talked about how NOT to talk to those you don't want to talk to, we'll address some of the items you need to know to allow your system to talk to the ones you DO want to talk to.

There are two aspects to communicating with systems on the Internet. First, you have to be able to look up a computer's name and retrieve it's network address. Second, the computer has to be able to find a physical route to send information packets destined to that network address. The two steps are quite separate, and both need to be working together to achieve full Internet communication capability.

First, we'll discuss the address lookup; this is known in Internet circles as name resolution. There are several ways to provide name resolution, and we'll discuss them in order from least flexible to the most powerful.

If you're used to NS/3000 on your HP3000 you may be familiar with the NS/3000 network directory. It's the simplest (and least flexible) way to tell your system how to reach other systems. The network directory roughly corresponds to the Unix worlds' host tables. Using the NMMGR program you enter system names and Internet addresses for them. Not bad for one or two systems (once you get used to NMMGR's maze of screens), but definitely not a manageable way to communicate with the two million or so hosts on the Internet.

If your network has HP3000 and/or HP9000 systems, you may have noticed that you don't need any network directory entries for these hosts to find each other. HP's systems use the PROBE protocol to automatically find systems that support PROBE (at least those on the same subnet).

A welcome enhancement to MPE systems introduced with MPE/iX 4.0 was support for network nameservers. This allows an HP3000 to automatically "ask" a network nameserver for the correct network address for a given system name. Nameservers operate by their own network protocols, synchronize themselves automatically, and automatically pass "queries" on to nameservers responsible for the specified part of the network. In a network growing and changing as fast as the Internet, this is the only way to keep up with the changes and get accurate responses to name lookups.

And now, thanks to the volunteer efforts of Mark Bixby of Coast Community College, your HP3000 can *be* a nameserver. Mark ported the public domain "BIND" nameserver. It's only available for MPE/iX systems (not classic HP3000s) but it's free and can be downloaded off the Internet. See our main web page (www.3kassociates.com) for information on how to get it.

Internet Roadmaps

Now that you have a system's address, how do you (or your system) get there? Internet "packets" are sent on their way with merely a source network address, destination network address, protocol number, and data. Each packet may pass through a thousand machines before it gets to it's eventual destination, and the rapid changes on the Internet and traffic congestion mean that no two packets going from point A to point B necessarily take the same route.

Just "routing" data packets around the Internet is quite a task, and in fact involves some sophisticated software and Internet standard protocols to get the job done. While this is not the place to go into the routing algorityhms and protocols (especially since the HP3000 doesn't implement them!) we'll just assure you that there are many many systems out there whose job it is to get packets from one place to another, implementing protocols like "RIP", "EGP", "BGP", and several others. Since your HP3000 doesn't support any of these, in order for the HP3000 to communicate with the rest of the world, it basically hands this task off to another system on your network. This utilizes a feature called the "default route". All the complicated Internet routing protocols require keeping (and frequently updating) large network routing tables; systems that don't implement these protocols often simply designate another system that does as their "default route", sending all packets that it doesn't know how to otherwise route to this system to forward on its behalf.

In the case of your local HP3000, you're going to need to set up a "default" route (using NMMGR) that points to some other system on your network that supports full packet routing; this can be your router if it is capable, or a Unix system running the "gated" program, or most commercial Internet providers will provide you the address of such a system in their network as part of your subscription. MPE/V and MPE/iX systems can both designate default routes, and both are done in the same screen though MPE/V requires some special codes to enter in the screen. As shown in the accompanying illustration (figure 3), you designate a default route by designating a "gateway" system in NMMGR, and entering "@" for the list of reachable networks for that gateway (for MPE/V the values are not as straightforward; contact HP or myself for details if you need to do this). Once this is accomplished, and you restart your network (or at least :NETCONTROL UPDATE the routing information) your system can now "reach out and touch someone." A note; if you don't have the default route in place, you need to have individual routes to any system or network you need to reach - not very practical if you're connecting to the Internet. If you don't have a "route" defined for a given network, you might see that machines (or at least their message packets) can get to you, but your HP3000 can't respond (no TCP/IP service can be started without some response from the recipient, so though packets can get to you, if you can't send them back then no TCP/IP based service can work). This can well be an effective means of isolating your HP3000 from the world as well; if you don't set up the "default route", no outside networks can reach you.

Services

Your HP3000 is now speaking the same language as the rest of the computing world (TCP/IP) and knows how to reach any computer system out there; now you just need to give it something to say and tell it who you want it to talk to out there. This comes back to one of the classic questions "Why would I want to connect to the Internet; what would I do if I was connected?" The answer, for the HP3000 at least, is multiple choice, and any (or all) answers can be correct.

Telnet (Interactive host login access).

Telnet is the worldwide standard protocol for accessing computer systems (interactively logging on and performing tasks) over a network connection. The HP3000 can both act as a server (recipient of telnet connections) and a client (thanks to the recent telnet client developed and contributed by Dave Elward) where HP3000 users can connect to other computer systems that support telnet access. The telnet client is free; you can get it from Jeff Kell's ftp site (off the Internet) and probably from Interex's CSL as well. That's the good news. The telnet server capability requires special hardware in an HP DTC (distributed terminal controller). In actuality you telnet to the DTC, which then lets you connect to an HP3000 (or any other computer it's set up to talk to). Contact HP for details on telnet servers for your HP3000. (Rumor has it that HP is finally relenting, and plans to implement a telnet server residing entirely on the HP3000 but I have no details on that.)

Telnet clients are also readily available for almost all makes and models of PCs, Macs, and workstations, including several public domain (free) packages available (you guessed it; on the Internet). Remember though, that if you're telnet'ing to an HP3000 and expect to run all those nice applications on the HP3000 (like V/Plus blockmode applications perhaps?) that you'll need a telnet client that emulates HP terminals, and the only ones I've seen that do this are the commercial clients like WRQ's, Unison-Tymlabs', and Minisoft's.

FTP (File Transfer).

FTP is the Internet's file transfer protocol. It allows transfer to and from FTP servers from FTP "clients". HP provides both an FTP server and client for the HP3000 as part of their ARPA Services package - which comes bundled with MPE/iX 5.0. 3k Associates provides the Office Extend an FTP client and server for the HP3000, which among other things gives you much better security and access controls, and also supports anonymous ftp (which HP's server currently does not).

Again, FTP clients are available for most every hardware platform you can think of, including public domain clients and some nice commercial implementations with GUIs and drag/drop capability for Macs or Windows users.

SMTP (Electronic Mail).

There are several electronic mail packages that will get you connected to the Internet by going through another commercial network (like MCI Mail or AT&T Mail) but only two that give you direct SMTP capability for your HP3000; HPDesk with HPOpenmail or the NetMail/3000 FSC gateway, and the NetMail/3000 (standalone) mail system. HPDesk with Openmail passes messages from the HP3000 to an HP9000 system to handle SMTP, UUCP, or (optionally) X.400 mail transfer. NetMail/3000's FSC gateway operates entirely on the HP3000 and provides SMTP mail transfer for HPDesk users, and is also the only e-mail system for the HP3000 that supports the MIME standard (multimedia enhancements to SMTP that allow transport of binary attachments or 8-bit character set messages to any other platform). NetMail/3000's standalone system allows HP3000 users to send and receive Internet compatible e-mail, and also includes a POP2 server (POP is another Internet e-mail protocol for retrieving e-mail from a PC, Mac, or workstation client). With POP2, you can use any POP2 compatible client to manage your e-mail, while the HP3000 acts as a server accepting and holding your messages until you retrieve them.

Contact HP for information on Openmail and 3k Associates for information on NetMail/3000.

SMTP compatible mail packages or gateways are also available for almost every computer platform on the market. POP2 clients (both commercial and public domain) are also available for almost every platform.

HTTP (World Wide Web Servers).

Almost anyone who has had exposure to the Internet is familiar with the World Wide Web. Some even mistakenly refer to the Internet as the "web".

Not to be left out, there are several world wide web servers available for the HP3000 platform. The first was a port of the freeware NCSA httpd server back in 1994. Still available from several web servers on the Internet (see our public domain software area on www.3kassociates.com for details) it does an adequate job of serving up web (html) documents. Not very fast, nor with the bells and whistles of other servers, it often serves as a "test drive" server - something to show management that the 3000 can really be a web server. After the initial thrill wears off though, you'll need to look into other server options, as the NCSA server can be painfully slow and eats alot of cpu cycles on your 3000. A better long-term choice might be the OpenMarket server (sold by HP) which is 3 to 10 times faster and uses much fewer resources on the system. It also has better logging options, some page redirection capabilities (for example, as we do on our main www.3kassociates.com page, if your browser supports frames, you automatically get a frame-enabled page), and it's supported by someone (as opposed to the freeware options). There is even a version of the server (supposedly) that supports secure (encrypted) web transactions. The bad news is that support from OpenMarket has always been spotty and rumor has it that they will stop supporting the HP3000 port of their package altogether.

Another supported server option is the QWEBS server from QSS. This server is unique in that it (1) doesn't require posix (or MPE/iX) and (2) it can directly call HP3000 applications (even SL/XL routines). Also, since QSS is a long-time committed HP3000 vendor, they're not likely to stop supporting their product. (And at only about $500, it's a good deal anyway). We should note that while all the web servers will allow you to execute HP3000 applications, all the others only support posix/hfs files, which usually means you'll need to write some C or perl code to work with them.

Finally, the newcomer to the HP3000 arena (but not to the web) is the Apache web server, ported to the HP3000 by Mark Bixby. This server is the most popular web server on the Internet (immensely popular on Unix platforms) and has all the bells and whistles of the web-serving world. It's also an efficient (resource wise) server, and though there is no "official" support available, this server has alot of man-hour resources behind it, and enhancements come out on a regular basis. (Since Mark's port results were fed back to the people maintaining the official releases, all subsequent releases should compile and run on the HP3000 without modification). It's only downsides are that (1) it's a posix application, so be ready for some C or perl programming to integate your in-house applications, and (2) it's shell scripts only function on MPE/iX 5.5 or later, so it's not an ideal choice for even 5.0 systems (and not a choice at all for systems on releases earlier than that).

Gopher (Information retrieval protocol).

Gopher is an information retrieval protocol used to find resources or information on the network. Information is presented to the user as a simple menu, with each menu selection being either a new piece of information (file) somewhere on the network, or a pointer to a sub-menu. By traversing organized menus users can easily find indexed information from around the world (gopher allows each menu item to be on any computer system; local or remote). The only publicly available commercial gopher server is available from 3k Associates. There is also a public domain gopher client available via ftp from opus.admin.utc.edu or www.3kassociates.com.

Gopher clients (both commercial and public domain) are available for many other platforms.

Finger (User lookup/simple query protocol).

Finger is a network protocol where a user can provide a simple user name or search string and a server responds with the user's information (name, phone#, mailbox name, etc.) or a response to the query. A few (contributed) finger clients and servers are available from the folks on the HP3000-L list on the Internet as well as Interex's CSL. 3k Associates also provides a free finger client as well, and bundles a finger server with NetMail/3000.

Finger servers and clients are also available for many platforms, both as public domain programs and as part of commercial packages.

A Sample Configuration

Just to show you it can be done and doesn't have to cost a fortune, I'll outline an actual configuration I set up to get our network of HP3000s talking to the Internet. While this example doesn't apply to everyone, I provide it as an example to show how easy it can be.

First, the ingredients. A local area network (ethernet using coax cable). A couple MPE/V HP3000s and an HP3000/917lx. A couple of PCs on the network also, though only one is directly involved. Figure 4 demonstrates the network.

The important piece here is that lowly PC running MS Windows and NetManage's Chameleon TCP/IP for Windows. The PC happened to be equipped with a 14,400 baud external modem. Chameleon lets this PC perform all its normal tasks, while also managing a SLIP or PPP link in the background. Not only this, but it also acts as a simple router, routing TCP/IP traffic between any machines on the local network and the Internet, and all this for $99 (actual list price for their package is about $400 I believe, but I picked up a copy at their booth at a trade show for $99). The package also includes a telnet client, bind domain nameserver, network news client, gopher client, ftp client and server, ping client, finger client, POP2 compatible mailer, whois client, and many other useful utilities.

To be honest, getting Chameleon configured to perform this routing was not trivial, and in fairness they don't advertise the package as a router (in fact, I appeared to have surprised their technical support people when I got it working). Chameleon requires the link be opened manually, which is no problem for full time Internet connections, but can be a concern for part-time connections. Once opened however, it routes nicely and automatically re-dials and logs back in if the connection drops. There are several "tricks" to get the link configured to operate correctly (like configuring a separate network address for the link itself, among others) as well as several requirements on the Internet service provider's end (PPP compression options, routing table entries, and nameserver entries).

Once Chameleon was up and running, I configured our 3000s to point to it as their "default route" and entered it as a nameserver on the 917 (in the RESLVCNF.NET.SYS file). Presto --- we're on-line. Telnet on our 3000s can reach out anywhere in the world, and our e-mail processes send and receive messages from all over. Reflection's network software on our PCs can reach out to log into customer sites for technical support, and our gopher and ftp servers are available for public access; anytime, anywhere. *Note; for some of the reasons mentioned we only used this configuration for a short time. As our Internet useage became more demanding, we soon upgraded to a dedicated router (a Telebit NetBlazer in fact) and our full-time dialup link is soon to become a dedicated 56Kb frame relay link.

For those interested in higher-end solutions, dial-up routers such as Compatible System's, Rockwell's NetHopper and Telebit's Netblazers provide SLIP or PPP dial-on-demand access with the capability for higher speed modems. Above that, dedicated routers from Cisco and others can handle T1 data rates and above, with sophisticated filtering and automated management capabilities.

By the way, shop around for Internet providers as well. Prices range widely even in the same areas, and the quality of the links as well as technical support can make a big difference in your success on the 'net. A full-time dial-up PPP link to the Internet in my neighborhood ranges from about $100 per month to over $300 per month with unlimited traffic and baud rates up to 56kb available. Leased lines range from about $300 for 56k to around $2000 per month for T1, and several thousand per month for T3 and higher. The book "Connecting to the Internet" (ISBN: 1-56592-061-9) from O'Reilly & Associates, Inc. is a good place to start if you're looking for a vendor in your area; find it in your local computer bookstore, call them at (800) 998-9938, or e-mail them on the Internet at order@ora.com. If you're interested in using the Internet for your business, or just curious about the possibilities, another title to look for is "Doing Business on the Internet" (ISBN 0-442-01770-7) by Mary J. Cronin. In any case, advice is free, and you can contact me on the 'net or otherwise as well, and the HP3000-L mailing list is an invaluable resource (email to hp3000-l@raven.utc.edu). See you on the 'net.

*****************************
Chris Bartram
3k Associates technical support
Phone: 646-820-7619
e-mail: rcb@3kassociates.com

Connecting your HP3000 to the Internet By the numbers...