eServer i/net
eServer home Webulator Commerce Server Web Server Net Print Merchant Support i/net home

Webulator/400 FAQ


Appearance Topics

Useability Topics

Administration Topics

Programming Topics

Appearance Topics


Changing the default rows of Virtual Keyboard buttons.

All Virtual Keyboard buttons are configurable in regards to availability and location. Webulator/400 shipped configuration has the following rows of buttons:

  • TOP 1
    • Enter
    • Reset Fields
    • Close Session
  • BOTTOM 1
    • F1 through F12
  • BOTTOM 2
    • F13 through F24
  • BOTTOM 3
    • Help
    • Prev Page
    • Next Page

By default, all Webulator/400 directory entries will inherit these rows of buttons unless they override their values on a row by row basis.

You can modify the Virtual Keyboard buttons by running the WRKWWWDIR command and selecting option 9 for the desired Webulator/400 directory entry (/*META/WEBULATOR/ changes all Webulator/400 directory entries).

If you wanted to remove a row of buttons completely from the screen, you would have to add a new row entry to replaced the inherited row. For example, if you wished to remove the top row you would have to take option 1 to add a new row and set the LOCATION field to TOP and the ORDER field to 1. This will result in no buttons being displayed above the screen.

If you wish to redefine a row of buttons, you must first add the definition for the row as outlined above. You must then select option 5 to work with virtual keyboard buttons for the desired row. You must then add all of the button definitions to that row that you wish to appear on the screen.

Removing the horizontal rules from the screen.

Version 1.1 allows you to configure the existence of the horizontal rules.

You can change the default behavior of including a rule at the top and bottom of each screen by running either the CHGWBLCFG or WRKWWWDIR command.

You can set the HORIZRULE value to:

  • *NONE
  • *TOP
  • *BOTH

Setting input fields characteristics.

While HTML has many options available for setting the characteristics of output fields, there has been very little advancement in setting the characteristics of input fields.

Webulator/400 has the following constraints placed on it by HTML:

  • Characteristics such as font name, size and color cannot be set.
  • Text Areas cannot constrain the number of characters typed into it.

This constraints may be removed in the future as HTML and browser continue to be enhanced.

Seeing window borders.

Some AS/400 applications simulate windows through overlays and not through the DDS WINDOW keyword. These overlay screens typically have a reverse image space as its border. Since HTML preformatted text does not support the setting of text background, reverse image borders do not show up. Webulator version 1.1 has two solutions for this problem.

The first method is to set the reverse image replacement char (RICHAR) attribute to something like an *. This will instruct the Webulator to replace any reverse image space characters with an *. This will result in border of asterisks being displayed.

The second method is a little more complex and has some other ramifications. Version 1.1 support HTML tables in addition to HTML preformatted text. The main reason why HTML tables were added was to help insure that column data would line up properly. One additional benefit received by HTML tables, is that reverse image attributes are supported. There are a couple of side-effects associated with tables. The first is that you may notice added spaces between fields on the screen. This is caused by the browser calculating the pixel boundaries for each column. In other words, not all columns are the same width. The other side-effects include a larger HTML file being produced as well as a longer paint time by the browser. You may want to play with this to see if it is desirable for you. You can enable tables by setting the TABENABLE field to *YES.

Including custom headers and footers.

Webulator/400 allows you to configure stream files that contain information that should be used as either headers or footers on all screens for a given Webulator/400 URL. These files can contain either plain text or HTML data. Plain text files will result in the text being displayed as HTML Preformatted Text on the screen. HTML files allow you to specify any valid HTML objects to appear on the screen.

Below is an example of a sample custom HTML header and footer. The following sample assumes that your Web Server/400 document root is set to WWWSERV/WEBDOCS.

First you need to create a header file (header.htm) and a footer file (footer.htm) located in a directory off your document root. Let's assume that you create a directory named WBLHTML off of the WWWSERV/WEBDOCS directory that will contain these files. Below are samples files that you can use as a base for your own custom header and footer files.

Sample Header File (/wwwserv/webdocs/wblhtml/header.htm)

	<TITLE>Your title goes here</TITLE>
	<IMG SRC="/images/logo.gif">

Sample Footer File (/wwwserv/webdocs/wblhtml/footer.htm)

	<IMG SRC="/images/logo.gif">

Please note that the IMG SRC tag contains a reference to an image named "/images/logo.gif". You are required to include a leading slash (/) for all file references in custom header and footers. The file references in the sample header and footer require you to create a logo.gif file in the WWWSERV/WEBDOCS/IMAGES directory.

The header file will result in all Webulator/400 screens having the title of "Your title goes here" followed by the image "logo.gif" before any of the 5250 screen data. The footer file will result in the same "logo.gif" appearing after the 5250 screen data.

Next you must configure the Webulator directory entry or entries that will use these new files. You do this by running the CHGWBLCFG or WRKWWWDIR command and setting the following values: Header File (HEADFILE) /wblhtml/header.htm Footer File (FOOTFILE) /wblhtml/footer.htm

All that is left to do is to restart or reconfigure your server and start a new Webulator/400 session. You should at a minimum see your title at the top of the browser. If you see a broken link icon where the image should be, Webserver/400 is unable to find the image. Make sure that you have a leading / in the header and footer files. If you do not see your title or image, you may have not included the leading / in the header or footer file name or you may have created it in the incorrect directory.

Using HTML Tables to align subfile columns.

Version 1.1 can generate HTML Tables in addition to HTML Preformatted Text. Preformatted text guaranteed that the all output fields used a monospace font and therefore would be the same size. It unfortunately, did not take into account that input fields and submit buttons would take up more space on the screen than output fields. This could lead to alignment problems. For example, subfiles with input fields never aligned with their headings because the size of input fields are greater than output fields.

HTML Tables fix this problem by aligning all fields that start in the same column. One drawback is that you may see some extra space between fields that does not exist on the 5250 screen. In other words, the extra space taken up by input fields and submit buttons must be taken into account when aligning a field. In addition, HTML Tables support the setting of the text background color which means that reverse image attributes will be honored.

There are a few issues associated with HTML Tables. The first is that a Webulator/400 screen using HTML tables will be larger than one that uses Preformatted Text. HTML Tables also take a longer time to be displayed by the browser. In order to use HTML Tables, your browser must recognize the HTML Non Breaking Space (NBSP) character. There is a row of NBSP characters at the top of each screen to allocate space for each column of screen data. If you enable tables and see garbage at the top of your screen, it most likely means that your browser does not support the NBSP character.

Useability Topics


Using the Webulator/400 Keyboard Plug In.

Since Webulator/400 is a HTML based emulation program, it is dependent on the functionality of the browser to handle the keyboard interface. Unfortunately, browsers interpret keystrokes for their own purposes and not for the HTML forms that they are processing.

Because of this browser limitation, we had to develop a way of introducing new functionality into the browser to properly recognize action keys being pressed without requiring the user to press a browser submit button. We are able to accomplish this by writing a browser plug in.

A browser plug in is a platform specific piece of code that is loaded by the emulator whenever data of a certain type is accessed. Webulator/400 can embed a HTML tag that forces our keyboard plug in to be called everytime a Webulator/400 screen is displayed. The keyboard plug in monitors the keyboard for the user pressing any of the defined AS/400 AID keys (such as Enter and Function Keys). Whenever the plug in detects one of these keys being pressed, it will automatically return the HTML form to the AS/400.

The keyboard plug in is a feature that was introduced after version 1.1 was released. Because of this, we are unable to tightly integrate the functionality until the next release. This means that you can only enable the plug in support through the query string interface in version 1.1. Future versions will have the enablement of the plug in built into the standard Webulator/400 configuration commands.

Please see Webulator/400 Keyboard Plug In for more detailed information on installing and using the plug in feature.

Inserting the cursor in the proper input field.

Version 1.1 has added a new feature that instructs the browser to insert the cursor in the proper input field. This feature takes advantage of the JavaScript capabilities built into newer browsers. Browsers that do not support JavaScript will not insert the cursor properly.

This feature instructs the browser to automatically insert the cursor in the proper input field based on the data it receives from the 5250 data stream. For example, if a field contains an error, the cursor will be placed in the field containing the error (assuming that the AS/400 program actually sets the correct row and column location).

You must enable this feature by setting the SNDJAVASCR option to *yes by running either the CHGWBLCFG or WRKWWWDIR command.

Field level help.

Version 1.0 requires the user to type a ? inside the input field that they wished to get field level help before pressing the F4 submit button.

Version 1.1 has added a new feature that instructs the browser to report back to the AS/400 the row and column of the last input field that had focus. This removes the requirement of typing a ? inside an input field in order to get field level help. This feature takes advantage of the JavaScript capabilities built into newer browsers. Browsers that do not support JavaScript will not report the correct row and column information.

You must enable this feature by setting the SNDJAVASCR option to *yes by running either the CHGWBLCFG or WRKWWWDIR command.

Showing input fields in error.

Many applications set the attribute of an input field in error to reverse image. Version 1.1 now has the ability to highlight this error condition to the user.

The first feature available is the ability to show reverse image space characters. Webulator/400 retains the reverse image attribute for the space character before any input field in error. Depending on your configuration, the user may be able to see this reverse image character. Version 1.1 allows you to specify a replacement character to use whenever a reverse image space is encountered. If you specify a * as the reverse image replacement character, you will now see the * in the column before the input field.

The second feature available in version 1.1 is the ability to set the cursor position to the proper input field using JavaScript. If your AS/400 program properly sets the cursor position, you have JavaScript enabled and your browser supports JavaScript, the cursor will be placed in the input field in error.

Displaying international characters properly.

There are several areas that must be configured properly for Webulator/400 to properly display international characters. The areas that must be looked at are:

  • CCSID of the user profile signed onto the Webulator/400 session
  • CCSID of the server user profile (WWWUSER by default)
  • Web Server/400's CONTENT CCSID

The data originates in the application in the interactive job's CCSID. It then gets sent to the Webulator/400 which is running under the Server User Profile CCSID. If these two CCSIDS are not the same, some characters may get changed. Finally, the data is converted from the Server User Profile CCSID (EBCDIC) to the CONTENT CCSID (ASCII). If these two CCSIDs are not compatible, characters may get changed.

The opposite path is taken for any data entered into an input field. It starts out in the CONTENT CCSID (ASCII) and gets converted to the Server User Job CCSID (EBCDIC). This data then gets returned to the application which is running in the interactive job's CCSID. Again, all of these CCSIDs must be compatible or data may get changed.

Using the browser back button.

When you press the browser button, you are displaying a cached version of the form and the browser becomes out of sync with the AS/400 program. Whenever Webulator/400 detects this out of sync condition, it simply sends you the current screen of the AS/400 interactive job. The underlying communication protocol (5250 data stream) is very dependent on row and column positional values of input fields to indicate which input fields contain what data. If Webulator/400 accepted previously cached forms and tried to send its data to the AS/400, you would get very unpredictable results. We determined that it is better to resend the correct screen than to risk sending incorrect data to the AS/400. You must use the application logic to view previous pages and cannot use cached pages because this will cause the browser to be out of sync with the AS/400 application.

Session Settings Button.

The Session Settings button allows the user to set some limited settings for the current session only. Currently, they are limited to choosing the font size and determining if they wish to include blank lines. The purpose of this button is to give the individual user limited control over the screen appearance based on their hardware capabilities.

To include the Session Settings button, you can either run the WRKWBLROW or WRKWWDIR command. Either way you should get a list of row groups that are defined for that directory. Place a 5 (Work with virtual keyboard buttons) next to the group in which you want to add this button and press ENTER. Next you need add a new button using the value of 1 in the list of buttons. You can then supply the following information:

  • Key Name: SessionConfiguration
  • Key Seq: (Desired positional value)
  • Desc: (Desc that should appear on the screen)

Differences between I/NET's Webulator/400 product and IBM's WSG product.

  • Webulator/400 features not available in IC 5250 Gateway
  • Support for V3R1 and V3R6.
  • Extensive setup and configuration through AS/400 commands.
  • Webulator/400 is integrated with Web Server/400
    • Uses SSL, Host Filtering and User Authentication.
    • Shares same port (port 80 is default)
    • Automatic signon without exit programs.
  • Converts AS/400 menus into browser submit buttons.
  • Converts user defined keywords into browser submit buttons.
  • Control over the order and placement of virtual keyboard submit buttons.
  • Configurable on a per URL basis.
  • Configurable Background color and image.
  • Configurable text colors.
  • Input fields that extend more than one line can be a scrollable field or text area field. (IBM's is text area field only).
  • Supports redirecting to a new URL upon completion of terminal session.
  • Supports HTML and plain text headers and footers.
  • Supports enhanced DDS keywords:
    • Windows (WINDOW DDS Keyword)
    • Menu Bars (MNUBAR DDS Keyword)
    • Pull Down Menus (PULLDOWN DDS Keyword)
    • Selection Lists (SFLMLTCHC and SFLSNGCHC DDS Keywords)
    • Selection Fields (SNGCHCFLD and MLTCHCFLD DDS Keywords)
    • Push Buttons (PSHBUTTON DDS Keyword)
  • Support for HTML tables
  • Sets focus to proper input field
  • Returns row and column of last input field that had focus. (Allows for field level help)
  • Provides comprehensive keyboard mapping (Enter, Function Keys, Page Up, Page Down, Attention and System Request)

Not seeing data in an one byte field.

There appears to be a bug in Netscape Navigator version 2.02 that does not show the contents of any input field that is only one character in length. It appears that this is an one time bug and other versions of Netscape appear to work correctly.

Administration Topics


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:

You will now be able to access it through:

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/

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:


       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:


  • Your host name is
  • 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

You need to do the following steps:

  1. Create a new directory entry using the WRKWWWDIR command. Name the directory something like /*META/WEBULATOR/APP1/.
  2. Modify the new directory entry with Webulator options unique to this URL by choosing option 10 from the WRKWWWDIR command.
    1. Change the Sign-on method to *USER and provide the User Profile of the user that will run the interactive application.
    2. 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.
    3. Change the Termination URL to /sample.htm
  3. Make sure the user has a way to end a session.
    1. You can either provide them with a Close Session Virtual Keyboard Button using option 9 of the WRKWWWDIR command.
    2. 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.
  4. 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.
  5. Include the URL 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.

Programming Topics


Including graphical controls in my AS/400 application.

With the release of V3R1, IBM introduced a series of DDS keywords that result in a graphical look and feel for your AS/400 applications. Below is a list of the graphical DDS keywords that Webulator/400 supports:

  • WINDOW - Popup Window
  • MNUBAR - Menu Bar
  • PULLDOWN - Pull Down Menus
  • SFLMLTCHC - Multiple Selection Listbox
  • SFLSNGCHC - Single Selection Listbox
  • SNGCHCFLD - Radio Buttons
  • MLTCHCFLD - Check Boxes
  • PSHBUTTON - Push Buttons

Please refer to the IBM AS/400 DDS reference for more information on how to use there keywords in your application.

There are no special configuration values that need to be set to understand these controls.

There is a small sample application that uses some of these graphical DDS keywords available on I/NET's FTP site. Feel free to download and experiment with this application if you wish to learn more how to use these DDS keywords.

Below is some information on how to get the sample application:

File:    /pub/webulate/wbldemosav.savf
  1. You must first create a savf named wbldemosav.
  2. FTP the file to either your AS/400 or PC.
  3. If you FTP'd to a PC, you must now FTP it to the AS/400
  4. Get the save file from your AS/400 FTP area to the save file created in step #1.
  5. The save file will contain a WBLDEMOSRC source physical file that was saved from QGPL.

Embedding HTML in my AS/400 application.

Version 1.0 supports the embedding of the <A HREF ...> and <IMG SRC ...> HTML keywords directly in the DDS source. We recommend that you include these as hidden output fields so that non Webulator/400 session do not see the HTML tags.

Version 1.1 supports the HTML DDS keyword that is available on AS/400s running either V3R2 or V3R7. The DDS keyword has the following advantages:

  • It will only be sent to Web enabled emulation programs
  • It does not take up any screen space
  • Any valid HTML keyword can be used

There is one limitation associated with the HTML DDS keyword. It cannot be used within a subfile.

Please refer to IBM's DDS reference for more information concerning the use of the HTML DDS keyword.

AS/400 applications recognizing when a Webulator/400 session ends

In order for the program to be notified, you must set the system value QDEVRCYACN to *MSG. In addition you must check for errors on all reads and writes that involve the display file. A CPF5140 message is received whenever a Webulator/400 session is closed either through the user pressing the Close button or the session was automatically closed because of a timeout condition.

How Webulator/400 retains state information in a connnectionless environment.

HTTP is a connectionless environment but the concept of interactive AS/400 applications assumes constant communications between the AS/400 and the client. Webulator/400 adds a series of hidden fields to every form to help identify what session is making a request. In addition, we use the IP address and some unique identifiers to insure that the request is always coming from the same client. We take this information and resolve it to a user space name which contains all of our state information.

Obtaining client information from your AS/400 application.

There is currently no way for the interactive application to obtain information such as the IP address from the Webulator/400 session. The reason for this is that the interactive job is a different job than the server job. In addition, there is no direct connection between the Webulator batch job (Web Server/400 RP) and the interactive job. We are currently investigating various options to allow the interactive application to query select information from the Webulator/400 session and hope to include this functionality in a future release of the product.

How Webulator/400 tests for valid user profiles and passwords.

Webulator/400 uses a System API named Get Profile Handle (QSYGETPH). You can get more information on this API in the OS/400 System API Reference manual.

Unfortunately, it is not easy for a CGI script to perform the same checking. While it is possible for a CGI script to acquire the User ID and Password fields through Web Server/400 environmental variables, the password comes back encrypted. This renders the password unusable for the QSYGETPH API call. Webulator/400 is using some internal calls that gains access to the password before it gets encrypted.

We have discussed having Web Server/400 authenticate a URL using the QSYGETPH API call. If this was done, your CGI script URL could be protected using this new type of authentication and you would not have to worry about checking the validity of the user id and password entered. There is currently no time frame for this enhancement.

Webulator/400 and AS/400 drop down menus.

HTML does not support the drop down menus directly. Webulator/400 uses submit buttons to simulate menu choices. Horizontal menus would be represented by a series of submit buttons with the menu text on them lined up one after another across the width of the screen. Vertical menu would be represented by a series of submit buttons with the menu text line up one after another down the height of the screen. Pressing one of the submit buttons would be the equivalent of selecting the menu item on the AS/400.


^ Back to top