Webulator/400 and AOL's proxy server
AOL has added a proxy server to their Internet gateway in hopes of
improving throughput. It appears that this proxy server does not
properly handle Webulator/400 sessions. The problem stems from the
fact that the AOL proxy server will cache all URLs that do not contain
"cgi-bin". As you may know, the shipped Webulator/400 alias is
/WWW5250/. This means that Webulator/400 URLs by default do not
contain "cgi-bin". This results in the AOL's proxy server caching all
Webulator/400 screens and not returning them to the AS/400. In other
words, you will always get the same screen over and over again.
Fortunately, there is an easy fix for this. You simply need to create
a new *WEBULATOR alias named /cgi-bin/www5250/. You can do this by
running the WRKWWWALS command. You then type a 1 (to add) in the first
blank entry in the list and press ENTER. The Alias value needs to be
set to '/cgi-bin/www5250/' and the Source type value needs to be set
to *WEBULATOR. You can either set the Update executing RPs to *IMMED
or run the SETWWWCFG command for this change to take place.
If your current Webulator/400 root URL is: www.xyz.com/www5250/
You will now be able to access it through:
www.xyz.com/cgi-bin/www5250/
Please note that this new Alias may be needed by other proxy servers
other than AOL's.
Understanding directory based configuration.
Directory Based Configuration (DBC) was designed for Web Server/400
before Webulator/400 was developed. Its original purpose was to
provide a method of controlling access through host filtering and user
authentication to the various directories on your AS/400. For example,
a / directory entry refers to the root file system on your AS/400
while a /QDLS entry refers to the QDLS file system. The important
point is that DBC entries for Web Server/400 refer to a physical
directory entity on your AS/400. The Web Server/400 command to control
DBC entries is WRKWWWDIR.
During the Webulator/400 development, we decided to extend the DBC
concept to control the logical file system used by Webulator/400. This
logical file system is controlled by *META directory entries in the
DBC commands. The root Webulator/400 directory entry is named
/*META/WEBULATOR/. Webulator/400 contains a default (assumed) set of
configuration options for the /*META/WEBULATOR/ directory entry.
It may also be helpful to tie the directory entry back to the actual
URL. There are three components that make up a Webulator/400 URL. The
first is the HOSTNAME for the Web Server. At I/NET we use
WWW.INETMI.COM. The second component of the URL is the Webulator/400
alias. The alias shipped for Webulator/400 is WWW5250. Now our URL is
WWW.INETMI.COM/WWW5250. The last part of the URL is what Webulator/400
directory should be used. The designator for the root Webulator/400
directory is a /. This makes the URL to reach our Webulator/400 root
directory to be WWW.INETMI.COM/WWW5250/.
The real power of DBC is in its ability to inherit configuration
information from a parent directory entry. Each Webulator/400
directory entry can contain as many configuration options as
desired. Any configuration options not included will automatically be
inherited from the parent.
In hopes of understanding some of the important concepts of DBC, we
can look at the Webulator/400 directory entries at use at I/NET. I/NET
has the following Webulator/400 directories defined for our
WWW.INETMI.COM server.
Webulator/400 Directory URL
/*META/WEBULATOR/ WWW.INETMI.COM/WWW5250/
/*META/WEBULATOR/COLOR/ WWW.INETMI.COM/WWW5250/COLOR/
/*META/WEBULATOR/MONO/ WWW.INETMI.COM/WWW5250/MONO/
We include the majority of our configuration options that pertain to
appearance (e.g., parsing keywords, button layouts, footers, etc) in
the /*META/WEBULATOR/ directory. In addition, we disabled the URL by
setting the signon value to *DISABLED. This allows us to use the root
directory for setting appearance information without having to worry
about securing it. We were then able to override the terminal color
and signon attributes for the child directory entries to make them
available for use. If we ever decide to change an appearance related
option, we only have to change it in one place and not in multiple.
Hopefully, Webulator/400 DBC is a little clearer. We can now look at
how you can add your own directory entries through the WRKWWWDIR
command.
The first step is to take option 1 (Add) and press ENTER. You should
see a screen asking for the directory name. Remember to add a
Webulator directory entry, you must first include the Webulator/400
root name (/*META/WEBULATOR/) followed by the name of the new
directory entry. Let assume that you want to add a directory entry
named TEST.
You would then type /*META/WEBULATOR/TEST/ in the directory name field
and press ENTER.
Once you do that, you can take option 8, 9 or 10 to change the
Webulator/400 configuration options or option 6 to set host filtering
information for the new directory entry. Remember, any options you do
not set will be inherited from its parent directory.
After you have finished adding and configuring your new Webulator/400
directory entry, you must either restart or reconfigure your server
for the changes to take place. You would then be able to test the new
URL by access WWW.XXX.COM/WWW5250/TEST/.
Hand editing configuration files.
You can hand edit any of your Webulator/400 configuration
files. However you must do so with great care. The server will not
start if it encounters a line that it does not understand. The syntax
for all of the options are documented in the appropriate user guides.
Obtaining fixes (PTFs)
I/NET maintains a FTP site that has all of our available fixes. The
name of the site is FTP.INETMI.COM. This site supports anonymous
FTPing by typing anonymous for the user and your email address for the
password. In the PUB directory you will find the following product
directories:
- COMSERV - Commerce Server/400 PTFs
- WEBSERV - Web Server/400 PTFs
- WEBULATE - Webulator/400 PTFs
Each PTF will contain up to three files. The first file will have an
extension of .TXT. This file contains downloading and installation
instructions as well as a description of the fixes. The other files
will have an extension of .savf. These files are the actual binary
files that contain the fixes.
Our naming convention for PTFs is as follows:
PPPVVM999T
where:
PPP - Product Code
COM - Commerce Server/400
WWW - Web Server/400
WBL - Webulator/400
VV - Version Number (e.g., 10 is version 1.0)
M - Modification Number (currently not used)
999 - PTF Number (Sequential Number)
T - Machine Type (Blank - IMPI, R - RISC)
Running a specific application from a Webulator/400 URL.
You can easily setup a Webulator/400 URL to automatically signon a
user with a given user id and password. By doing this and ensuring
that the user profile will automatically call the desired application,
you limit the user to that one application when they access the
URL. The following example illustrates this concept:
Assuming:
- Your host name is xyz.com
- You have a *Webulator alias of WWW5250
- The application you want to run is SAMPLIB/SAMPAPP
- The URL that you want to return to after the user is finished is named www.xyz.com/sample.htm
You need to do the following steps:
- Create a new directory entry using the WRKWWWDIR command. Name the directory something like /*META/WEBULATOR/APP1/.
- Modify the new directory entry with Webulator options unique to this URL by choosing option 10 from the WRKWWWDIR command.
- Change the Sign-on method to *USER and provide the User Profile of the user that will run the interactive application.
- Change the Termination Confirmation to *NO. This will prevent the user from seeing a screen that will verify that they wish to end a Webulator session.
- Change the Termination URL to /sample.htm
- Make sure the user has a way to end a session.
- You can either provide them with a Close Session Virtual Keyboard Button using option 9 of the WRKWWWDIR command.
- You can define a parsed button (option 8 of the WRKWWWDIR command) that will convert a string (maybe F3=) to be associated with the Close Session button.
- Create the User Profile used in step 2 if needed. Make sure that the user profile will automatically call the sample application using the initial program to call and current library values.
- Include the URL www.xzy.com/www5250/app1/ as the link in your HTML and you should be all set.
Assigning Webulator/400 devices to their own subsystem.
Webulator/400 uses Virtual Terminal APIs which allow very little
control over the selection of the device that is used. You do have
several options of isolating Webulator/400 users but be aware that you
may not be able to differentiate between Webulator/400 users and users
of other applications that use the Virtual Terminal APIs.
The first option is to run the ADDWSE command to place all QPADEV*
devices into the desired subsystem.
The second option is to run the ADDWSE command to place devices based
on device type into the desired subsystem. Webulator/400 creates the
following device types:
- 3179-2 24 x 80 Color Session
- 3196-A1 24 x 80 Monochrome Session
- 3477-FG 27 x 132 Monochrome Sessions
- 3477-FC 27 x 132 Color Sessions
- 5555-C01 24 x 80 DBCS Sessions
Ending Webulator/400 sessions.
Accessing an AS/400 application through Webulator/400 is different
from a traditional green screen emulator in many ways. One of the
differences is how to determine if the session is still active (i.e.,
is the terminal still connected). A green screen emulator has a
physical connection to the AS/400 and therefore the AS/400 knows when
it loses its connection and can end the job and free up its
resources. A Webulator/400 session is very different from this. A
client browser makes a request for a Webulator/400 screen and breaks
the communications between the client and AS/400 once the screen is
received. It will then reestablish the connection when the user wants
a new AS/400 screen. We refer to this as a "connectionless"
session. Since the session is connectionless, the AS/400 cannot tell
whether a user is typing data in the HTML form or if the machine was
turned off.
Because of the connectionless characteristic of a Webulator/400
session, the Close push button is available for the user to specify
that they are finished with an AS/400 session. The pushing of the
Close button results in the virtual terminal that they were using to
be closed. This is similar to the user turning off a terminal or
closing a emulation window.
If the user neglects to close the session themselves, Webulator/400
provides a configurable timeout value. This value is the length of
time that Webulator/400 will allow a session to remain inactive. If
the event that the user does not close the session, this timeout will
occur and the terminal will be closed automatically. Webulator/400 is
shipped with a 5 minute timeout value.
Also, it is not possible for another Webulator/400 user to gain access
to a virtual terminal device that is in use by another user so there
is no potential security problem when a user does not properly close a
Webulator/400 session.
Redirecting the browser to the Termination URL when the user signs off.
Webulator/400 version 1.1 does not attempt to identify signon
screens. Therefore, there is no method available to automatically
redirect the user after signing off the system. We are seriously
considering adding this type of support to the product in the future.
| 
Keyboard plugin
