For a long time, one of the most interesting challenges facing AS/400 connectivity specialists was providing casual PC users temporary access to the AS/400. You know the type of user: executives who occasionally need a key piece of data or salespeople who want status reports but can't be bothered with learning all the ins and outs of the AS/400.
Back when the AS/400 was new, PC Support was the ticket: It provided PC access that was billed as easy and quick to install. But PC Support required users to obtain a 5250 emulation card or a synchronous modem along with an SDLC card for the PC, or it required us to implement an ASCII Workstation Controller, a protocol converter, or some form of PC gateway on the AS/400.
Even today, when Client Access/400 has replaced PC Support with a vast array of easy-to- configure access tools, there are still hardware and software considerations that make life complicated for these casual users. The end result today still requires us in MIS to analyze the cost of setting up the users and to weigh that level of complication against the benefits the user might get from casual, temporary access. It has always been a difficult cost/benefit ratio. That is, until now!
With the OS/400 tool called the Workstation Gateway, IBM has leveled the cost/benefit playing field for our casual AS/400 users. Now, a PC user can get direct access to the AS/400 with the same tools he uses to access the Web. On the AS/400 side, the cost is free with V3R2 and V3R7 of OS/400. There's no Client Access/400 license requirement for the user and no extraordinary hardware requirements, and most users find the interface as simple to use as their Web browsers. HowdidIBMdothismagic?
The Workstation Gateway is a service of OS/400's TCP/IP communications suite. It's a server program that is started on the AS/400; it dynamically converts the AS/400's 5250 data stream into a hypertext markup language (HTML) document, the standard format of the Web. These HTML documents are then transmitted as Web pages across the Internet or an intranet to a user's
Web browser (see Figure 1).
Command and Function keys are automatically converted into browser buttons and drop-down boxes. The user is presented with a nicely formatted Web page that allows him to navigate through the AS/400's menus or even standard custom programs. There's no required reprogramming of DDS, and the translation of any 5250 display is quick and consistent. Best of all, setting up the Workstation Gateway server is simple: If you already have TCP/IP configured, the Workstation Gateway can be configured and activated with a few quick commands. Let's take a look at how this service is configured.
The primary requirement of the Workstation Gateway is the installation of OS/400 V3R2 or V3R7 TCP/IP (see "Configuring Your AS/400 to Use TCP/IP," MC, October 1997). The gateway is a server program that uses this transport protocol to send the HTML formatted pages to the browser. Once you've installed TCP/IP on the AS/400 and configured it appropriately, the only tasks remaining are to enable the gateway with the Configure TCP Workstation Gateway (CFGTCPWSG) command and start it with a Start TCP Server (STRTCPSVR) command. Let's walk through those steps.
The process of configuring the Workstation Gateway is straightforward and easy. First, key in the CFGTCPWSG command and press Enter. This displays a menu of choices relating to the Workstation Gateway. Next, select option 1 to execute the Change Workstation Gateway Attributes (CHGWSGA) command. This will display the current attributes of the gateway and allow you to make changes (see Figure 2). These attributes control how the gateway performs and also provide some customization of the display of screens on the user's browser.
First and foremost is the AUTOSTART parameter. If you want the gateway to be automatically activated each time TCP/IP is initiated, change this attribute to *YES. Next, examine the Number of clients per server (NBRCLT) parameter. This may be a slightly confusing parameter if you're not used to working with server programs on the AS/400. It identifies how many active sessions can be simultaneously served by a single Workstation Gateway server program (the default is 20). However, unlike configuring a 5250 workstation controller to limit the maximum number of sessions accessing the AS/400, the NBRCLT parameter acts as a threshold. It identifies how many sessions the gateway will service before OS/400 spawns another copy of the Workstation Gateway server program. It also relates to prestart job entries within OS/400, so the system doesn't spend an inordinate amount of time initiating gateway sessions. In this way, you control the performance of each gateway program running on the AS/400.
The Inactivity timeout parameter (INACTTIMO) also controls performance. It specifies how many minutes the gateway will wait for activity from the user before automatically aborting the session. This parameter is important to prevent OS/400 from maintaining too many open abandoned sessions (a situation that could spell performance meltdown). The default for INACTTIMO is 10 minutes. A similar performance issue is defined by the Data request timeout (DTARQSTIMO) parameter. DTARQSTIMO monitors how long before an active request for data is received, in seconds. If the period between requests becomes too long, the gateway shuts off the session.
The Display sign-on (DSPSGNON) parameter offers a unique opportunity to customize how your Web-browsing users relate to the AS/400. At first glance, it appears to allow you to define
if the AS/400 sign-on screen will be transmitted across the Web. If you specify *YES, then anyone accessing the Workstation Gateway will be required to provide a user ID and password before any AS/400 programs will be available. However, if you specify a *NO, the gateway shifts to a mode that can allow the browser user to bypass individualized OS/400 security altogether.
Why would anyone want to do this? The most obvious purpose would be to send any user to a predefined set of screens that are completely secured through a secondary process called an exit program. An example of how this might be implemented would be a standard AS/400 display containing information about your company: You would want other Web sites to be able to link to this information using a standard URL without requiring each access to initiate a sign-on screen. IBM provides a sample of an exit program, written in C/400, to help you understand the potential of this unique customization feature.
Another means of customizing the workstation gateway is to use the Top banner URL (TOPBNRURL) and Bottom banner URL (BOTBNRURL) parameters. These parameters allow you to reference other URLs anywhere on the network to act as logos or informational displays. In the example shown in Figure 1, I've used MC's URL off our standard Web site. It isn't even on the AS/400 the gateway is running on; it's on the NT server, where we keep standard graphic information files. The result is a display that contains a banner that's consistent with all our other Web banners.
Incidentally, IBM has also provided support to allow you to optionally customize the way your in-house AS/400 programs display in the gateway. It's provided this support through a new DDS keyword called HTML. Using this keyword, you can add graphics and other HTML-specific elements to displays that are transmitted through the Workstation Gateway. At the same time, the effects of the keyword will remain invisible to those using standard 5250 displays.
Once you've set up the attributes of the Workstation Gateway using the CHGWSGA command, it's time to start the server program itself. Key in the STRTCPSVR command as STRTCPSVR *WSG. That's all there is to it. OS/400 will prestart the number of sessions specified in the NBRCLT parameter and then wait for the first Web browser to access the gateway's unique URL. When the user keys in that address, the AS/400 immediately sends back a sign-on screen as an HTML document. When the sign-on information has been provided, a second document is transmitted.
Page by page, document by document, each screen from the AS/400 is dynamically translated into HTML and sent across TCP/IP to the awaiting Web browser. All of the functions of the Web browser are supported, including the Page Back button. AS/400 function keys are managed by the browser as specific buttons that are displayed at the bottom of the screen. A user can easily learn how to navigate through the AS/400 screens using the easy point-and-click interface of the Web browser.
So what is the URL the user needs to know to access the gateway? There are a couple of different ways to describe it for the user. First of all, keying in the TCP/IP address of the AS/400 as http://AS/400_IP_Address: 5061/ wsg will directly connect to the gateway. Examine this address briefly to understand what's going on. The http:// tells the browser that you're looking for HTML pages. The AS/400_IP_Address tells the browser to send the request for pages directly to
a specific TCP/IP location. The :5061 is literally the TCP/IP port (port ID 5061) on the AS/400 where the Workstation Gateway is listening for activity. The /wsg tells the AS/400 that it needs to access the Workstation Gateway to dynamically translate the AS/400 displays into HTML pages.
However, this is a rather cumbersome address for your users to remember, so another means of accessing the URL might be by establishing this same address as a named server using your TCP/IP networks DNS service. Using DNS, the gateway might be given a more meaningful name, such as www.myas400.com. However, for reasons I'll discuss in a moment, placing the Workstation Gateway on the Internet might not follow the security requirements your organization has established.
We've mentioned some provisos about how the Workstation Gateway can send an AS/400 sign- on screen to the user's Web browser, but we need to mention something else: password security. Before you start up your Workstation Gateway on a direct connection to the Internet, you should be aware that passwords keyed into the sign-on screen are not secure. HTML doesn't natively encrypt passwords, and they're transmitted as plain HTML text from the user's sign-on screen across TCP/IP to the AS/400. This could represent some real exposure to your AS/400 site. Consequently, the Workstation Gateway should most logically be used only on intranets within your own company's TCP/IP network and not on the public Internet, where this exposure is more severe.
However, for intranet use, the Workstation Gateway may be just the ticket you're looking for to provide easy, cheap, and low-maintenance access to the AS/400 for your casual or temporary users. While it's not designed for heads-down keying or data entry, it's a good solution for many users who just need that occasional glimpse of the central information of your AS/400. Best of all, it's free with V3R2 and V3R7 of OS/400, and it doesn't require much work to get it up and running.
Thomas M. Stockwell is a senior technical editor for Midrange Computing and editor of Midrange Computing's Client Access/400 Expert newsletter. He has 25 years of experience as a programmer, systems engineer, and IS manager. He is also the author of two popular MC videos: Inside Lotus Notes and RPG Goes Visual. He welcomes your comments by email at
Figure 1: The AS/400 Main menu as an HTML page
 |
 |
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online