TM Webulator/400 User's Guide Version 1.1 COPYRIGHT c 1996 I/NET, INC. Revision B Copyright c 1996 I/NET, Inc. All Rights Reserved. No part of this book may be reproduced in any form or by any means, electronic or mechanical, including photocopying without written permission from I/NET, Inc. Webulator/400 is a trademark of I/NET, Inc. Other brand and product names are trademarks or registered trademarks of their respective holders. Webulator/400 User Manual Table of Contents Table of Contents 1. GETTING STARTED ........................................6 1.1 INSTALLATION .........................................7 1.1.1 Installing Webulator/400 .........................7 1.1.2 Objects Installed ................................8 1.2 INITIAL WEBULATOR/400 SETUP ..........................9 1.3 TESTING THE SETUP ...................................12 1.4 WHAT'S NEW WITH VERSION 1.1 .........................14 1.4.1 New Configuration Values ........................14 1.4.2 Changes to Existing Configuration Values ........14 1.4.3 New Features ....................................15 1.5 VIEWING WEBULATOR/400 DOCUMENTATION FROM A BROWSER ..16 1.5.1 Accessing Document Files Directly ...............16 1.5.2 Accessing Documentation through Web Server/400 and Commerce Server/400 ...................................16 2. USING WEBULATOR/400 ...................................17 2.1 WHAT IS WEBULATOR/400? ..............................18 2.1.1 A 5250 Emulator for the World Wide Web ..........18 2.2 WEBULATOR/400 SECURITY TOPICS .......................19 2.2.1 Sign On Methods .................................20 2.2.2 User Profile Considerations .....................22 2.2.3 AS/400 Virtual Terminal Considerations ..........23 2.2.4 AS/400 Programming Considerations ...............24 2.2.5 AS/400 System Values ............................28 2.2.6 AS/400 System Auditing ..........................29 2.2.7 Other Security Tips .............................29 2.3 CUSTOMIZING WEBULATOR/400 ...........................32 2.3.1 Query String Options ............................32 2.3.2 Preformatted Text or HTML Tables ................34 2.3.3 JavaScript Usability Enhancements ...............35 2.3.4 AS/400 Display Types ............................36 2.3.5 Screen Background ...............................37 2.3.6 Choosing a Header ...............................37 2.3.7 Virtual Key Buttons .............................39 2.3.8 Input Field Characteristics .....................42 2.3.9 Output Characteristics ..........................43 2.3.10 Screen Text Colors .............................44 2.3.11 Graphical Menus ................................45 2.3.12 Identifying Screen Keywords ....................46 2.3.13 Choosing a Footer ..............................47 2.3.14 Termination Options ............................48 2.3.15 Embedding HTML in the 5250 Data Stream .........48 2.3.16 Default Configuration Values ...................50 2.3.17 Sample Directory Based Configuration Files .....55 2.3.18 Reconfiguring Webulator/400 ....................59 2.3.19 Supported AID Keys .............................59 2.4 DIFFERENCES BETWEEN WEBULATOR/400 AND OTHER 5250 EMULATORS ...............................................61 2.4.1 Webulator/400 Client Software ...................61 Page 3 Webulator/400 User Manual Table of Contents 2.4.2 Known Browser Limitations .......................61 2.5 DIRECTORY BASED CONFIGURATION .......................66 2.5.1 A New Method of Configuration ...................66 2.5.2 A Simple Example ................................66 2.5.3 A Further Example ...............................66 2.5.4 How to Change the Configuration .................68 2.5.5 Related Information .............................68 3. COMMANDS ..............................................69 3.1 WEBULATOR/400 COMMANDS ..............................70 3.1.1 Webulator/400 Commands ..........................70 3.1.2 WRKWBLPRS .......................................71 3.1.3 WRKWBLROW .......................................72 3.1.4 CHGWBLCFG .......................................74 3.1.5 WRKWBLUSR .......................................76 3.1.6 ADDWBLUSR .......................................76 3.1.7 CHGWBLUSR .......................................77 3.1.8 DLTWBLUSR .......................................77 4. CONFIGURATION VALUES ..................................79 4.1 DEVICE CAPABILITIES .................................80 4.1.1 Send Javascript .................................80 4.1.2 Terminal Color ..................................80 4.1.3 Terminal Size ...................................81 4.2 SCREEN APPEARANCE ...................................83 4.2.1 Virtual Keyboard Row End ........................83 4.2.2 Virtual Keyboard Row Start ......................83 4.2.3 Background Color ................................85 4.2.4 Background Image ................................86 4.2.5 Color Conversion ................................86 4.2.6 Extended Input Field ............................88 4.2.7 Field Level Prompting ...........................89 4.2.8 Font Size .......................................89 4.2.9 Footer File .....................................90 4.2.10 Light Pen Image ................................91 4.2.11 Virtual Keyboard Button ........................92 4.2.12 Header File ....................................93 4.2.13 Horizontal Rule Location .......................94 4.2.14 Menu Type ......................................94 4.2.15 Parsed Button ..................................95 4.2.16 Reverse Image Space Character ..................96 4.2.17 Show Blank Lines ...............................97 4.2.18 Table Font Name ................................98 4.2.19 Table Width ....................................99 4.2.20 Tables Enabled .................................99 4.2.21 Termination Confirmation ......................100 4.2.22 Termination URL ...............................101 4.3 SESSION LIMITS .....................................102 4.3.1 Terminal Timeout ...............................102 4.4 ACCESS METHODS .....................................103 4.4.1 Signon Method ..................................103 4.4.2 Webulator User Entry ...........................104 Page 4 Webulator/400 User Manual Table of Contents 5. CONFIGURATION FILES ..................................106 5.1 RULES ABOUT CONFIGURATION FILES IN GENERAL .........107 5.2 AUTHORITY ..........................................108 5.3 SPECIFIC CONFIGURATION FILES .......................109 5.4 WEBULATOR/400 USER FILE ............................110 5.4.1 Example Entry ..................................110 5.4.2 Commands to Work With This File ................110 6. INDEX ................................................111 Page 5 Webulator/400 User Manual 1.0 Getting Started 1. Getting Started Page 6 Webulator/400 User Manual 1.0 Getting Started 1.1 Installation 1.1.1 Installing Webulator/400 1.1.1.1 Important Pre-Installation Instructions One of the following products must be installed on the system before installing Webulator/400 Version 1.1: . Version 1.3 or greater of Web Server/400 . Version 1.0 or greater of Commerce Server/400 1.1.1.2 Installing Webulator/400 requires the following steps: 1.Sign on the AS/400 as QSECOFR or another user profile with a user class of *SECOFR. Special authorities are required to successfully install Webulator/400 objects (Objects Installed on page 8). 2.End all currently running Web servers with the ENDWWW command. Also ensure that no product commands or menus are running. Use the WRKACTJOB command to verify there are no servers and commands running. 3.Ensure the system value QALWOBJRST is set to either *ALL or *ALWPGMADP. The Webulator service program WWWVAUTSRV adopts authority for the purpose of validating user profiles and passwords. The Webulator documentation; sign on methods (section 2.2.1 on page 20), includes more information on this topic. QALWOBJRST can be reset, if needed, after the installation is successfully completed. 4.Run the system command LODRUN to install Webulator/400 from the supplied product tape. Note: Prompt the command to change the tape device if the default is not appropriate. The install should take approximately 5 to 15 minutes depending on the tape device and AS/400 model (NOTE: RISC AS/400s may take longer if not using a RISC installation tape due to the extra time it takes to convert IMPI programs to RISC programs). The install program displays a message when it is finished indicating the install was successful. If any problems occur during the install: 1. Check the joblog to determine the cause of the error. 2. Correct the problem. 3. Re-run the installation command. Page 7 Webulator/400 User Manual 1.0 Getting Started 4. If problems persist, please contact support. 1.1.2 Objects Installed The following objects were created/restored on the AS/400 by the installation program: . Webulator/400 objects were restored to the Web server's product library (WWWSERVER). Product commands, a message file, menus, and panel groups were copied into library QSYS. . A directory named WWWServ was restored into the root of the IFS file system. WWWServ contains many other directories and stream files that are used by Web Server/400 or Commerce Server/400. Webulator/400 publications were restored into the WWWServ/WebDocs/Shipped/Pubs/Webulate directory. Important note: Webulator/400's sample content and publications will always be shipped in the 'Shipped' directory. Users should not place content in this directory for it may be deleted or over-written in the future. Page 8 Webulator/400 User Manual 1.0 Getting Started 1.2 Initial Webulator/400 Setup The following steps must be performed before running the Webulator/400 Version 1.1 for the first time. 1.Install Web Server/400 Version 1.3 or Commerce Server/400 Version 1.0 Webulator/400 requires either Web Server/400 Version 1.3 or Commerce Server/400 version 1.0. If you have not already done so, install it first. 2.Install Webulator/400 Version 1.1 (section 1.1 on page 7) After the server has been installed, you are ready to install the Webulator/400 Version 1.1 code. 3.Start Web Server/400 or Commerce Server/400 If you are reading the documentation online, you may want to start the server in order to get access to the links pointed to by this file. Otherwise you can restart the server after the initial setup has been completed. 4.Create a Webulator/400 Alias If you are migrating from Web Server/400 Version 1.0 or 1.1, you must add a new Web Server/400 alias that will allow users access to Webulator/400 URLs. If you are not migrating from an earlier release, both Web Server/400 and Commerce Server/400 ship a default Webulator/400 alias named /WWW5250/. To add a new alias you can run the WRKWWWALS command and provide a name such as WWW5250 for the Alias field and the value *WEBULATOR for the Source type field (the Value field may be left blank). 5.Run the CHGWWWCFG command to enable Webulator/400 . Set the Directory Based Configuration File (ACCGBLFILE) Field The Web Server/400 and Commerce Server/400 configurations allow you to specify a Directory Based Configuration file. While this entry was optional in earlier versions of the Web Server/400, it is now required if you wish to run Webulator/400. The easiest way to setup Webulator/400 is to use the sample Directory Based Configuration file that is shipped with the Webulator/400 product. You can use this file by setting the Directory based configuration field to /WWWSERV/CFG/WBLMACC.CFG. Page 9 Webulator/400 User Manual 1.0 Getting Started If you already have an entry in the Directory based configuration field, it is recommended that you temporarily replace your current configuration file with the Webulator/400 sample Directory Based Configuration file to test and get familiar with the functionality of Webulator/400. After you feel comfortable with its functionality, you can then modify your existing Directory Based Configuration file to include the desired new entries for Webulator/400. All Webulator/400 configuration values will be set to their default values (section 2.3.16 on page 50) when using this file. . Set the Webulator/400 User File Path (WBLUSRFILE) Field You must set the path of the Webulator/400 user file if you plan to take advantage of the automatic signon capabilities (section 2.2.1 on page 20) of Webulator/400. The easiest way to setup Webulator/400 to use automatic signon is to reference the sample User File that is shipped with the Webulator/400 product. This file can be used by setting the Webulator/400 User File Path field to /WWWSERV/CFG/AUTH/WBLUSR.CFG. This file is shipped with no entries since it is not possible to know the user ids or passwords on your system. You must add your own entries to this file using the WRKWBLUSR (section 3.1.5 on page 76) command before it will be useable by Webulator/400. It is beneficial to use the sample user file because of the authority settings that are shipped with this file. . Set the Maximum Webulator/400 Sessions (WBLMAXSSN) Field You can optionally set the maximum number of simultaneous Webulator/400 sessions that will be allowed. If you do not specify this entry, a default of 20 sessions will be used. . Set the Disable Webulator/400 (DISABLEWBL) Field You must set the Disable Webulator/400 entry to *NO to configure the server to automatically start Webulator/400 during its startup process. 6.Evaluate Signon Method The sample Directory Based Configuration file (/WWWSERV/CFG/WBLMACC.CFG) that is shipped with Webulator/400 contains a root directory entry with a signon method (section 2.2.1 on page 20) of signon Page 10 Webulator/400 User Manual 1.0 Getting Started screen. "Signon screen" was chosen because of its ease of setup, but it does have some potential security considerations. If you are not comfortable having a signon screen available even for a short period of time, you should change the signon type to a different value before restarting or reconfiguring Web Server/400. This value can be set through the Sign-on method field through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG (section 3.1.4 on page 74) command. 7.Add Additional Webulator/400 Directory Entries The sample Directory Based Configuration file (/WWWSERV/CFG/WBLMACC.CFG) that is shipped with Webulator/400 contains only the Webulator/400 root directory entry and no child directories. You can optionally add more Webulator/400 directory entries by running the WRKWWWDIR command. Please note that all Webulator/400 directory entries must start with /*META/WEBULATOR/. Therefore, the Webulator/400 root directory will always be named /*META/WEBULATOR/. If you want to add a new directory entry off of the Webulator/400 root, you can add an entry such as /*META/WEBULATOR/STATUS/. By creating additional directories, you can have multiple URLs that will have different characteristics (such as which user will automatically be signed on). 8.Check AS/400 Virtual Terminals (section 2.2.3 on page 23) Verify that the AS/400 system value QAUTOVRT is at a large enough number so that Webulator/400 can automatically create additional virtual terminal devices if needed. 9.Start your Web Server Start either Web Server/400 or Commerce Server/400. It will start Webulator/400 during its startup process. If your server is already started, then you may run the Set WWW Configuration Values (SETWWWCFG) command which will reconfigure the server which in turn will start Webulator/400. Please note that in the future when you reconfigure Webulator/400, the new configuration values will take effect for all new sessions only. Please refer to Reconfiguring Webulator/400 (section 2.3.18 on page 59) for more information. Page 11 Webulator/400 User Manual 1.0 Getting Started 1.3 Testing the Setup The following steps will help you determine if Webulator/400 has been configured properly for access. The intention of the list is to check the basic areas of access and should not be considered to be a comprehensive set of tests. Please note that you must have followed the steps in the Initial Webulator/400 Setup (section 1.2 on page 9) section for these tests to be valid. In order to perform the following tests, either Web Server/400 or Commerce Server/400 must be started on the AS/400 and a Web browser must be running on a workstation connected to the AS/400 using TCP/IP. The value of the signon method will determine what you will see when you successfully access a Webulator/400 URL. If the signon method is SCREEN, you will receive a standard AS/400 signon screen. If the method is USEAUTHENTICATION, you will receive a browser window asking for your user id and password. If the method is USER, you will see the first screen for that AS/400 user profile. Please note that if the method is DISABLED, you will receive an error message when you try to access that URL. Access the Webulator/400 Root URL. Try to access the Webulator/400 root URL through http://your.system.name/WblAliasName/ where: your.system.name is your AS/400 system's TCP/IP host name or IP address. /WblAliasName is an alias whose SRCTYPE is *WEBULATOR. You can view all of your current aliases by running the WRKWWWALS command. For example, assume that your HOSTNAME is www.xyz.com and your *Webulator alias name is /WWW5250/. The name of your Webulator/400 root URL would be http://www.xyz.com/WWW5250/. Access the Remaining Webulator/400 URLs. If you added additional Webulator/400 directory entries using the WRKWWWDIR command, you should try to access their URLs also. To determine how to access child URLs, you must look at the names of your directory entries. Since all Webulator/400 directory entries must start with the Webulator/400 root directory name of /*META/WEBULATOR/, you can ignore all entries that do not Page 12 Webulator/400 User Manual 1.0 Getting Started meet this criteria. For example, assume that you have the following Webulator/400 directory entries: /*META/WEBULATOR/ /*META/WEBULATOR/STATUS/ The first entry is the Webulator/400 root directory and the second directory is a child off the root directory. In order to determine the name of the URL to access this child directory, you need to strip off the Webulator/400 root component from the directory name. This leaves us with the name of the child directory entry (STATUS/). You must append the name of the child directory entry to the URL of the Webulator/400 root to get the correct URL for the child directory entry. Assuming that the root directory URL is http://www.xyz.com/WWW5250/, the URL for the child would be http://www.xyz.com/WWW5250/STATUS/. Check for expected configuration values. Ensure that the Webulator/400 URLs are using the configuration values you are expecting. If any are not, they are either using a default value (section 2.3.16 on page 50) or are inheriting a value from one of their parent directories. If a directory entry is inheriting an undesirable configuration value, you must define a new value in the current directory to override the inherited value. These values can be set through options 8, 9 and 10 of the WRKWWWDIR command or directly using the WRKWBLROW (section 3.1.3 on page 72), WRKWBLPRS (section 3.1.2 on page 71) and CHGWBLCFG (section 3.1.4 on page 74) commands. Page 13 Webulator/400 User Manual 1.0 Getting Started 1.4 What's new with Version 1.1 1.4.1 New Configuration Values Webulator/400 Version 1.1 has added several new configuration values: . HTML Tables (section 4.2.20 on page 99) - Allows you to specify whether Prefomatted Text or HTML Tables should be used when building the 5250 screens. See the Preformatted Text or HTML Tables (section 2.3.2 on page 34) for more information. . JavaScript (section 4.1.1 on page 80) - Allows you to enable a set of usability enhancements implementing using JavaScript. See the JavaScript Usability Enhancements (section 2.3.3 on page 35) for more information. . Horizontal Rules (section 4.2.13 on page 94) - Allows you to specify whether horizontal rules should be shown. . Reverse Image Spaces (section 4.2.16 on page 96) - Allows you to specify a replacement character for blank output fields with a display attribute of reverse image. . Blank Lines (section 4.2.17 on page 97) - Allows you to specify if blank lines should be shown. . Font Size (section 4.2.8 on page 89) - Allows you to specify the initial font size. 1.4.2 Changes to Existing Configuration Values Virtual Keyboard Keyword Parsing The Virtual Keyboard parsing logic (section 2.3.12 on page 46) has been changed to allow more control over the text that will appear in the buttons. Version 1.0 used program logic to determine if the keyword or the description that followed the keyword would appear in the submit button. Version 1.1 uses configuration values to determine the button contents. This new format allows you to specify either DESCRIPTION (default) or KEYWORD for each parsing button entry. Please note that since Version 1.1 always uses either the DESCRIPTION or the KEYWORD for each entry while Version 1.0 programatically determined the appearance, the parsing buttons may appear different using Version 1.1 than when using Version 1.0. Please check the appearance of your Page 14 Webulator/400 User Manual 1.0 Getting Started parsing buttons to ensure that they appear to your satisfaction. Graphical Menu Field Selection The Menu Type (section 4.2.14 on page 94) value has been enhanced to allow for the inclusion of the location of the input field that should receive the menu selection value. Version 1.0 restricted graphical menus to screens with only one input capable field. Please see the Graphical Menus (section 2.3.11 on page 45) section for more information. Query String Overrides The Signon Method (section 4.4.1 on page 103) has been enhanced to allow for the parsing of query string keywords that will help initialize the AS/400 interactive job. Please see the Query String Options (section 2.3.1 on page 32) section for more information. DBCS Terminal Support The Terminal Size (section 4.1.3 on page 81) value has been enhanced to allow for the inclusion of DBCS terminals connected to a DBCS capable machine. Please see the AS/400 Display Types (section 2.3.4 on page 36) section for more information. 1.4.3 New Features Secured Transactions Webulator/400 transactions are secured when used in conjuction with Commerce Server/400. Enhanced V3R2 Support The V3R2 HTML DDS keyword is supported. Please see the Embedding HTML into the 5250 data stream (section 2.3.15 on page 48) section for more information. Page 15 Webulator/400 User Manual 1.0 Getting Started 1.5 Viewing Webulator/400 Documentation from a Browser All of the documentation is written in HTML (Hyper Text Markup Language) which will allow you to view it through a Web browser in one of two ways: 1.5.1 Accessing Document Files Directly Connect to the AS/400 through a network drive and use a web browser which is written to work with Microsoft Windows or OS/2. Upon installation, the Webulator/400 user guide documentation is located in the directory /WWWServ/WebDocs/Shipped/Pubs/Webulate. Most web browsers have the ability to load and view HTML files directly from a disk. Therefore, if your browser has this ability you can load the files through this means. The Client Access/400 for Windows 3.1 or Client Access/400 Optimized for OS/2 software packages allows you to connect to the IFS Root file system through a network drive definition. In order to reach the drive necessary you can either connect a drive directly to the /WWWServ/WebDocs/Shipped/Pubs/Webulate directory or you can connect to the ROOT of the IFS file system and work your way through the path (/WWWServ/WebDocs/Shipped/Pubs/Webulate) to reach the documentation. Since the documentation is an HTML marked up document there are many files which make up the entire documentation. The base document is named usrguide.htm. Access this file to start at the beginning of the document. 1.5.2 Accessing Documentation through Web Server/400 and Commerce Server/400 Once the server is started, the documentation is available through the server. Upon installation, the Webulator/400 user guide documentation is located in the directory /WWWServ/WebDocs/Shipped/Pubs/Webulate. If the server is started with the shipped configuration the documentation can be accessed through the following URLs: /Shipped/pubs/Webulate/ or /Shipped/pubs/Webulate/usrguide.htm Page 16 Webulator/400 User Manual 2.0 Using Webulator/400 2. Using Webulator/400 Page 17 Webulator/400 User Manual 2.0 Using Webulator/400 2.1 What is Webulator/400? 2.1.1 A 5250 Emulator for the World Wide Web Do you know what an Internet script is? Many AS/400 programmers don't. Most Web servers require that you write scripts to create interactive applications for the Web. For AS/400 software developers, this can mean learning new languages, tools and procedures if they want to tap the resources of the Web. Not so anymore!!! With Webulator/400, used in conjunction with Web Server/400, you can now use your current development tools (RPG, Cobol, DDS, ILE C, etc.) for creating Web applications. You can use your AS/400 applications to access the Internet's global presence to create new marketing, public relations and customer support opportunities. Even existing AS/400 applications will run on the Web without re-coding. Just install and configure Webulator/400 and the applications on your AS/400 are ready to go! Here's how it works. AS/400 applications generate screens that are sent out in a 5250 data stream to a workstation or emulator, which displays the screen to the user. Webulator/400 intercepts this 5250 data stream and converts it into HyperText Markup Language (HTML), the language of the Web. Any Web browser (Netscape, Mosaic, etc.) will be able to run the application . Webulator/400 means your business doesn't need to rely on one specific client platform anymore. Any platform (Windows, OS/2, Macintosh, UNIX, etc.), that has a Web browser available can run your AS/400 applications. There's no additional connection configuration. Just point your Web browser to any AS/400 application, and you're in business! If your business writes AS/400 applications, then Webulator/400 means a wealth of new applications on the Internet without retraining your programmers. In summary, Webulator/400 in conjunction with Web Server/400, gives you the following benefits: . Instant Web access for thousands of existing AS/400 applications without re-coding . Ability to run AS/400 applications using Web browsers running on multiple platforms . Use of existing application development tools to develop applications for the Internet Page 18 Webulator/400 User Manual 2.0 Using Webulator/400 2.2 Webulator/400 Security Topics Webulator/400 should be considered a secure means of delivering access to 5250 applications and data across the Internet when configured properly. This section is intended to help explain and assist in the setup of the security for both the Webulator/400 product and the AS/400 running Webulator/400. The topics covered should not be considered the only security areas to address nor the only material to consider. These suggestions are intended to compliment the security that you already have set up on your AS/400 and TCP/IP network. There are two different categories of TCP/IP networks, secured and non-secured. A secured network would be a network which does not have a connection to the Internet (also termed an intranet) where all of the machines and users with TCP/IP access on the network are secured or trusted with access of an AS/400 sign on screen. A non- secured network would be a network with connectivity to the Internet (where the public has access to your Web Server/400 port running Webulator/400) or an intranet which has non- secured machines and users with TCP/IP access on the network. Prior to running Webulator/400, the network may have been considered secure if the only access to a 5250 terminal was through a twinax connection, a controlled telnet environment, or a secure SNA network (auto creation of controller was disabled). Once the Webulator/400 product is placed on this network (regardless of Internet or intranet network), if there are users on your LAN with TCP/IP access they may have access to a 5250 screen which they previously did not. The presence of these users on the LAN could define the network as being a non-secured intranet network. If your network has been defined as a non-secure network then it would be advisable to consider the security assistance provided within this section to compliment the security procedures that you already have in place. If you are running Webulator/400 within a secure intranet, it should require no additional security beyond your traditional 5250 connection currently available on the LAN. However, if your secure network has consisted of solely twinax connected 5250 terminals up to this point it would be advisable to consider these security topics. . Sign On Methods (section 2.2.1 on page 20) . User Profile Considerations (section 2.2.2 on page 22) . AS/400 Virtual Terminal Considerations (section 2.2.3 on page 23) Page 19 Webulator/400 User Manual 2.0 Using Webulator/400 . AS/400 Programming Considerations (section 2.2.4 on page 24) . AS/400 System Values (section 2.2.5 on page 28) . AS/400 System Auditing (section 2.2.6 on page 29) . Other Security Tips (section 2.2.7 on page 29) The IBM OS/400 Security - Reference publication (document number SC41-3302-00) is an excellent source for AS/400 security information. 2.2.1 Sign On Methods Webulator/400 requires a user profile and password to sign on to the AS/400. The sign on process can be configured (section 4.4.1 on page 103) within the directory based configuration (section 2.5 on page 66) using one of three methods. Each Webulator URL specified within the directory based configuration file allows one of the following methods to be configured: Automatic Sign On This method keeps all user profile names and passwords hidden from the user. The directory based configuration file allows the WebMaster to configure a user profile name associated with a *WEBULATOR URL. In addition to specifying the user profile name within the directory based configuration file, the person configuring the Webulator/400 product would also add the user profile name and the corresponding password to the Webulator User Configuration (section 5.4 on page 110) file (the WRKWBLUSR (section 3.1.5 on page 76) or ADDWBLUSR (section 3.1.6 on page 76) commands can be used to add these values). Since the password in this file is the AS/400 password, ensure that whenever the password is changed for this user profile that it is also changed within the Webulator/400 User Configuration file. If it is not, the URL will fail, the invalid sign on attempt will be logged in the system journals (if enabled), the user profile may be revoked (if the system values are enabled to do so), and the virtual terminal device will be varied off (if the system values are enabled to do so). Note that the password in this file is stored in plain text and should be protected from the Web Server/400 user profile and other non-authoritative (*PUBLIC) user profiles using AS/400 security. You may allow the user to specify the initial program, menu or library through a query string if you enable the AllowSignonOverride option of the Signon Method (section 4.4.1 on page 103) configuration entry. Please refer to Query String Options (section 2.3.1 on page 32) for more information and ramifications of allowing signon values to be overridden using query string keywords. Page 20 Webulator/400 User Manual 2.0 Using Webulator/400 User Authentication This method uses the User Authentication user ID and password sent on the request from the browser as the AS/400 user profile name and password. The user ID and password are encoded using the base64 encoding of MIME (UUENCODED). Essentially it is the same algorithm used to encode an FTP or Telnet user ID and password. If you are not using the Commerce Server/400, this should not be considered a secure encoding algorithm, however it is better than sending the password across the network in plain text. The Webulator/400 contains a service program (WWWVAUTSRV) that checks the password and user profile passed from the browser to ensure that they are valid for your AS/400. This service program adopts QSYS authority to be able to call AS/400 system security APIs. If you choose to change this service program to no longer adopt authority you should do the following in order to keep the same Webulator/400 functionality with regards to the User Authentication signon method: 1. Give the server user profile specified within the Web Server/400 configuration (default value WWWUSER) *USE authority to the following programs: 1.QSYS/QSYGETPH 2.QSYS/QSYRLSPH 2. Change the owner of the WWWVAUTSRV service program to WWWUSER and remove authority adoption by using the following AS/400 commands: 1.CHGOBJOWN OBJ(WWWSERVER/WWWVAUTSRV) OBJTYPE(*SRVPGM) NEWOWN(WWWUSER) 2.CHGSRVPGM SRVPGM(WWWSERVER/WWWVAUTSRV) USRPRF(*USER) In normal circumstances this method will not show the sign on screen during session initialization. Please note that a signon screen will appear when a valid user profile and password are used but the user profile is restricted from signing on to a virtual terminal. In this case, the signon screen will appear with an error message explaining that the user profile is not authorized to the workstation. This would occur if you have configured your AS/400 virtual terminal devices to only allow user profiles with limited authority to signon (limit QSECOFR QLMTSECOFR system value is a recommended security consideration (section 2.2.5 on page 28)). User profiles attempting to signon that have *ALLOBJ or *SERVICE special authorities would be the only users with this problem. You may allow the user to specify the initial program, menu or library through a query string if you enable the AllowSignonOverride option of the Signon Method (section Page 21 Webulator/400 User Manual 2.0 Using Webulator/400 4.4.1 on page 103) configuration entry. Please refer to Query String Options (section 2.3.1 on page 32) for more information and ramifications of allowing signon values to be overridden using query string keywords. Sign On screen This method initializes the virtual terminal and displays the sign on screen to the user through their browser. The user would fill in the user profile name and password. If you are not using Commerce Server/400, these values are sent across the network as plain text and therefore this method creates the most exposure to your system's user profile names and passwords. Access to each of the Webulator URLs can be protected using the access control directives within the Directory Based Configuration File (section 2.5 on page 66). However, it is worthy to note that if the access control directives are used in conjunction with the User Authentication sign on method, the user name and password must match a valid AS/400 user profile name and password. Both the access control directives and the Webulator/400 sign on would use the same authentication user ID and password passed on the request from the browser. 2.2.2 User Profile Considerations The security of your system may be strengthened by making some changes to the user profiles configured to run from the Webulator/400 product. Depending upon your system's security requirements these changes may apply system wide. Specify "*NONE" for ATNPGM user profile parameter The ATNPGM user profile parameter specifies the attention key handling program for this user. The attention key handling program is a program that is started when the attention key is pressed. If not properly configured, this program may allow the user to get outside the realm of the initial sign on program specified for the user. If *SYSVAL is specified for this parameter, the attention key handling program set up for all users on the system will be available to the user running through Webulator/400. By specifying *NONE for this parameter using the CHGUSRPRF command, the attention key is disabled for this user. Another way to disable this function is within the Webulator/400 button configuration (section 2.3.7 on page 39). However, by doing it through the user profile you are disabling the attention key for the user no matter which URL the user obtains access through. Page 22 Webulator/400 User Manual 2.0 Using Webulator/400 Revoke authority to SYSREQ (QSYS/QGMNSYSR) If the user has the ability to invoke the system request (SYSREQ) menu, they have the ability to carry out requests that, from a security point of view, you may not want them to do. For example, they would be able to sign off which would present them with a sign on screen. If you have configured this user profile name to be an auto sign on URL then you may not want the user to be able to get to a sign on screen, allowing them to guess at user IDs and passwords. Or, they would have the ability to view the system operators messages, or send messages to other users on the system, (which, if nothing else may be an annoyance). To revoke the authority to the system request menu, change the authority on the QSYS/QGMNSYSR object. Set the user profile's limit capabilies (LMTCPB) user profile parameter The user profile's limit capabilities parameter allows or disallows the user's ability to enter commands and change the initial menu, initial program, or current library during sign on. There are three different values the LMTCPB can be set to: *NO, *PARTIAL, or *YES. *YES is the most limiting and *NO is not at all limiting. Set the expiration date in the user profile to *NOMAX When setting password expiration times, you should keep in mind that the AS/400 allows the user to change their password when the expiration time is drawing near (7 days before expiration). It is best to set Webulator/400 users who will be using automatic sign on or user authentication sign on to process password expiration in one of the following ways: 1. Set the password for the user profile of the user to never expire. This can be done using the PWDEXPITV(*NOMAX) parameter on the CHGUSRPRF or CRTUSRPRF commands. 2. Manually change the password for the user prior to the expiration time warning period. 2.2.3 AS/400 Virtual Terminal Considerations Webulator/400 uses virtual terminals to execute the HTML 5250 session. As a result, some virtual terminals need to be created for this use. Webulator/400 will automatically create these devices if there are devices available to be created (system value QAUTOVRT has not yet been reached). These devices will be created starting in the QPACTL01, QPACTL02, or QPACTL03 virtual control units and will be named QPADEVnnnn (where nnnn is a number between 0001 and 0250). Page 23 Webulator/400 User Manual 2.0 Using Webulator/400 If the number contained in the system value QAUTOVRT has been reached or exceeded by the maximum number of virtual devices, it is your responsibility to manually create the devices (using the CRTDEVDSP command) needed for Webulator/400 access. These devices must have the following device types based on the capabilities desired: . 3179-2 for 24x80 color . 3477-FC for 27x132 color . 3196-A1 for 24x80 monochrome . 3477-FG for 27x132 monochrome . 5555-C01 for 24x80 DBCS (double byte terminal) For example, to create a device to provide the screen size of 24x80 characters that is color, you would enter the command CRTDEVDSP DEVD(QPADEV0001) DEVCLS(*VRT) TYPE(3179) MODEL(2) CTL(QPACTL01) TEXT('Webulator/400 virtual device - 24x80 color'). In addition, if you have implemented an interactive subsystem policy that involves specific work station entries for each display device or device type, it may be necessary for you to add these new virtual devices (or device types) as work station job entries to be controlled by your interactive subsystem. This is done by using the ADDWSE (Add Work Station Entry) command. Additional information about AS/400 virtual terminals can be found in the AS/400 Work Management manual. 2.2.4 AS/400 Programming Considerations There are a few things you should keep in mind when preparing to include your AS/400 application on the World Wide Web. They all involve the access and availability of your system and its objects to the general Internet public. Keep in mind that this applies only if you are planning to allow access outside your enterprise (via the global Internet, or any other means). If you are maintaining a closed intranet system, you could follow your normal security precautions. First of all, you probably want to restrict users who will be signing on via Webulator/400 to the applications that you have selected for their use. This means that the user should not be presented with a command line. The command line allows users to enter commands, including commands that you may not want them to execute - such as the CALL command to call a program, or STRPASTHR to access another system. At minimum, the SNDMSG command in the wrong user's hands can be a real nuisance. This includes the availability of the command line on some IBM provided displays. An operation as simple as the WRKJOB command (to allow the user to view and Page 24 Webulator/400 User Manual 2.0 Using Webulator/400 affect aspects of their individual job), while automated as part of a menu, still has a command line associated with it. Inquiries and simple data entry that is run through a verification and authentication process are probably the best applications for global Internet access. These applications allow users the ability to view information about your company and its products, as well as enter limited information to order products or request more detailed inquiries. They also allow for the entry of order requests that can easily be followed up or verified after the fact. If you have chosen to perform automatic sign on or user authentication sign on for the user, you probably do not want them to get back to a real AS/400 Sign On display. Access to the Sign On display defeats the work you have done in restricting access to the userid that you have defined for web access. It also gives the user the opportunity to begin "guessing" the userids and passwords on your system. As a result, it is best not to include an option to sign off from your menus (usually option 90) and application screens presented to the public. Keep in mind that this also includes the ability to sign off via help panels, whether they were written for your application or are supplied by IBM as generic help for the AS/400. The inability to sign off presents us with a very reasonable question - How do I end the application and the job when the Webulator/400 session is closed by the user? Interestingly, the answer to that question is to issue the "SIGNOFF" command. This will not be available to the user, but from within the application when a screen or display error occurs - identifying that the session has been closed. Basically, you will monitor for errors whenever a screen is written to the 5250 display from your program. This can be done using MONMSG in CL programs following any SNDRCVF statements. The contents of the EXEC parameter would simply be the command "SIGNOFF". An illlustration of this procedure, as well as RPG and COBOL logic can be found in the following examples. Page 25 Webulator/400 User Manual 2.0 Using Webulator/400 CL Program Example PGM DCLF FILE(DSPFILE) . . . SNDRCVF RCDFMT(SCREEN1) MONMSG MSG(CPF0000) EXEC(SIGNOFF) . . . RPG Program Example .....CL0N01N02N03Factor1+++OpcdeFactor2+++ResultLenDHHiLoEqC omment . . . C EXMFT SCREEN1 99 C *IN99 IFEQ '1' C MOVEL'SIGNOFF' SGNOFF 7 C Z-ADD7 SGNLEN 155 C CALL 'QCMDEXC' C PARM SGNOFF C PARM SGNLEN C END . . . Page 26 Webulator/400 User Manual 2.0 Using Webulator/400 COBOL Program Example ENVIRONMENT DIVISION. . . . INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT DISPLAY-FILE ASSIGN TO WORKSTATION ORGANIZATION IS TRANSACTION FILE STATUS IS WS-FILE-STATUS. . . . DATA DIVISION. . . . WORKING-STORAGE SECTION. 01 WS-FILE-STATUS PIC X(2). 01 WS-SIGNOFF-VARIABLES. 05 WS-SIGNOFF-CMD PIC X(7) VALUE "SIGNOFF". 05 WS-SIGNOFF-LEN PIC 9(10)V9(5) COMP-3 VALUE 7. . . . PROCEDURE DIVISION. . . . WRITE DISP-RECORD FORMAT IS SCREEN1. READ DISPLAY-FILE. IF WS-FILE-STATUS IS NOT EQUAL "00" THEN CALL "QCMDEXC" USING WS-SIGNOFF-CMD WS-SIGNOFF- LEN, STOP RUN. . . . These examples show the logic that you may wish to include in your application to ensure the closeout of the application and completion of the job. Obviously, other steps that may be required to complete or close a transaction in your application are not shown here. The contents of the QDEVRCYACN system value also determines how the application program is informed of the session termination and may inhibit the return of error indications to the program. Page 27 Webulator/400 User Manual 2.0 Using Webulator/400 2.2.5 AS/400 System Values The following are recommendations for changes to AS/400 system values for use with Webulator/400. Security level of 30 minimum (QSECURITY) (recomended 40) Security level 30 forces the use of passwords when signing on to the AS/400 and also enables object based security. This allows you to specifically authorize (or not authorize) users to work with objects on the AS/400. This allows you to control access to the AS/400 and access to individual objects on the AS/400. Limit QSECOFR (and other key users) to specific devices (QLMTSECOFR) By changing the QLMTSECOFR system value to indicate that explicit device access is needed, you can specify the devices where users with *SERVICE or *ALLOBJ special authority are allowed to sign on. Part of this limitation could be the denial of access at virtual terminals that are to be associated with Webulator/400. Keep in mind that you must grant authority to the QSECOFR user profile, and any others with the noted special authorities, to the devices they will be using (such as DSP01). Limit invalid signons (QMAXSIGN) By setting the QMAXSIGN system value, you limit the number of attempts a user can make to successfully sign on at a workstation. Once the limit is reached, the action defined in the QMAXSGNACN system value will be performed on the device and user profile. Set QMAXSGNACN to disable the profile When the limit defined in the QMAXSIGN system value is reached, the AS/400 system automatically reacts and performs the action defined in the QMAXSGNACN system value. It is possible to disable the user profile, the device, or both. Obviously, the option to disable both is the most secure. Limit dynamic creation of *VRT devices (QAUTOVRT) By controlling the virtual devices used for Webulator/400, you can control what users and functions are allowed at each of those workstations. The value of this system value also affects other AS/400 products and programs that require automatic virtual device configuration. This includes TCP/IP TELNET, 5250 display station pass-through, Client Access/400, and other programs that may use the virtual terminal APIs. Page 28 Webulator/400 User Manual 2.0 Using Webulator/400 Additional information about AS/400 system values can be found in the AS/400 Work Management manual. 2.2.6 AS/400 System Auditing While the Webulator/400 configuration and other security precautions can prohibit the unauthorized access to your AS/400 system and its applications, the AS/400 provides methods that allow you to regularly monitor security activities and requirements. The following logs and journals present information about system and object access. Monitor QHST History log for security messages Security violations are logged to the AS/400 History Log (QHST) via CPF messages. These messages (CPF2200-CPF22FF, CPI2200-CPI22FF, CPC2200-CPC22FF, and CPD2200-CPD22FF) show security and object violations that have occurred on the AS/400. By displaying the log for these messages (using the DSPLOG command), you can monitor invalid signon requests, as well as other attempted security violations. Monitor/audit journal QAUDJRN for security related system and object requests The QAUDJRN journal contains audit trail entries for each of a number of security activities on the AS/400. These activities include, but are not limited to: authority failures, program adoptions, authority and object ownership changes, object creations and deletions, network logons and logoffs, and userid or password failures. The AS/400 Security - Reference manual provides more information about setting up and using the auditing functions. These entries can assist you in your steps to ensure that your AS/400 remains secure, whether it is connected to the Internet or a single 5250 workstation. Additional information about logging and auditing can be found in the AS/400 Security - Basic manual. 2.2.7 Other Security Tips These are a few general items that don't fall into any other specific security category. These items are recommendations that affect operating practices, application objects, and Webulator/400 operational characteristics. Change user passwords periodically It is always a good security practice to change user passwords from time to time. The QPWDEXPITV (password expiration interval) system value helps in the enforcement of these periodic changes. Another common Page 29 Webulator/400 User Manual 2.0 Using Webulator/400 recommendation concerning the creation of passwords is for them to contain a combination of characters and numbers (QPWDRQDDGT system value). Specifically limit authority to key files and programs (no *PUBLIC *ALL) Even without Internet access, users that sign on to your AS/400 only have access to the files, programs, and data that you provide for them. Prudent object management allows each user to have the authority that is appropriate for the completion of their job or function. This not only applies to users who will access the AS/400 via Webulator/400, but also to the default "*PUBLIC" user that provides authority to any user who signs on to the AS/400. Limit access to other computers on your LAN The AS/400 has the capability to communicate with other computer systems using SNA and TCP/IP protocols. As a result Webulator/400 users, with networking commands available, may have the capability to communicate with the other systems on your LAN. Specifically the STRPASTHR and TELNET commands give the user the capability to log on to remote AS/400s in your network. If security on the remote system is not configured to handle this unexpected access, that system may be vulnerable to a security breach. Limit access to "Program/procedure", "Menu", and "Current library" on Sign On display In some circumstances, the Program/procedure and Menu entry fields on the Sign On display are an open invitation for users to experiment with what is available for execution on your system. If you are planning to have "Signon screen" as your Webulator/400 sign on method, you may wish to create a new QDSIGNON display file (the file used to show the AS/400 Sign On display) that protects the Program/procedure, Menu, and Current library entry fields. More information about changing the Sign On display can be found in the AS/400 Work Management manual (SC41-3306). Another aspect of this topic involves the "Allow signon overrides" element of the SIGNON parameter of the CHGWBLCFG (section 3.1.4 on page 74) command. This element allows for the override of these Signon screen parameters during Webulator/400 access. As a result, the discussion of considerations (Considerations on page 33) for allowing signon override should also be reviewed. TERMTIME (CHGWBLCFG) must be less than QINACTITV Since the AS/400 has the ability to detect and sign off (alternatively disconnect) terminal jobs that have been inactive for a specific period of time, it is possible Page 30 Webulator/400 User Manual 2.0 Using Webulator/400 for a Webulator/400 user to be presented with a Sign On display if the AS/400 inactivity timeout (system value QINACTITV) expires before the Terminal Timeout (TERMTIME (section 4.3.1 on page 102) parameter on the CHGWBLCFG (section 3.1.4 on page 74) command) value. There is also the possibility of a two (2) minute delay in the timing of the Webulator Terminal timeout value. As a result, it is recommended that, if you practice an inactivity timeout policy, the TERMTIME parameter be set to a value at least two (2) minutes less than the QINACTITV system value. Do not change the public authority for the Web Server/400 commands Because the Web Server/400 commands can change the way Webulator/400 functions, and also affects Internet access controls, it is not advisable to make them available to users outside your organization. They are installed with public authority *NONE and can be accessed by individual users with specific authority granted. Page 31 Webulator/400 User Manual 2.0 Using Webulator/400 2.3 Customizing Webulator/400 . Query String Options (section 2.3.1 on page 32) . HTML Tables or Preformatted Text (section 2.3.2 on page 34) . JavaScript Usability Enhancements (section 2.3.3 on page 35) . AS/400 Display Types (section 2.3.4 on page 36) . Screen Background (section 2.3.5 on page 37) . Screen Heading (section 2.3.6 on page 37) . Virtual Keyboard Buttons (section 2.3.7 on page 39) . Input Field Characteristics (section 2.3.8 on page 42) . Output Characteristics (section 2.3.9 on page 43) . Screen Text Colors (section 2.3.10 on page 44) . Graphical Menus (section 2.3.11 on page 45) . Converting Keywords to Buttons (section 2.3.12 on page 46) . Screen Footing (section 2.3.13 on page 47) . Termination Options (section 2.3.14 on page 48) . Embedding HTML in the 5250 Data Stream (section 2.3.15 on page 48) . Default Configuration Values (section 2.3.16 on page 50) . Sample Directory Based Configuration Files (section 2.3.17 on page 55) . Reconfiguring Webulator/400 (section 2.3.18 on page 59) 2.3.1 Query String Options You can specify options on the query string of the URL that initializes a Webulator/400 session to change the behavior of that interactive Webulator/400 session. 2.3.1.1 URL Syntax The query string is specified on the initial URL after the complete Webulator/400 path has been specified. It starts with a ? followed immediately by the list of query string value pairs separated by an &. Assuming that your Webulator/400 session URL is www.xyz.com/www5250, the syntax would be like this: www.xyz.com/www5250?KEYWORD1=VALUE&KEYWORD2=VALUE. Spaces are not allowed inside the query string, you must substitute a + for all embedding spaces. 2.3.1.2 Valid Keywords The following query string keywords are available. . PGM - Allows you to specify a signon screen value for the initial program to run. Page 32 Webulator/400 User Manual 2.0 Using Webulator/400 . MENU - Allows you to specify a signon screen value for the initial menu to run. . LIB - Allows you to specify a signon screen value for the initial library. . FIELD1 - Allows you to specify the value that will be returned to the AS/400 for the first input capable field that is encountered. When this keyword is specified, Webulator/400 will simulate pressing ENTER for all screens up to and including the first screen with an input field. It is your responsibility to ensure that the first screen with an input field will properly handle the value being passed to it. 2.3.1.3 Restrictions The Signon Method (section 4.4.1 on page 103) value must be either USER ALLOWSIGNONOVERRIDE or USEAUTHENTICATION ALLOWSIGNONOVERRIDE for Webulator/400 to recognize the PGM, MENU or LIB query string keywords. There are no restrictions on using the FIELD1 keyword. 2.3.1.4 Considerations Care should be taken before enabling the ALLOWSIGNONOVERRIDE feature. When this feature is enabled, it allows you to override any of the initial signon values based on a HTML link. This may be useful if you wish to create a series of HTML links to some of your most popular applications but you don't want to create separate user profiles that have those applications as their initial program. In this case, you could use the query string keywords to override which application is called based on the HTML link regardless of the user profile that was used to signon. This flexibility does not come without additional security considerations. If you enable the ALLOWSIGNONOVERRIDE feature, any user that has access to that URL can also override the query string keywords to run any program that their user profile has access to. Please keep this in mind before enabling this feature. There are no security considerations associated with the FIELD1 query string keyword. The inclusion of this keyword on the query string is the equivalent to the user typing it in themselves. They are not able to get access to any additional AS/400 programs or functions by using this feature. You may find this feature useful if you have a URL with a signon method of USER that brings up an AS/400 menu as its first screen. In this case, you would be able to create a series of HTML links to the same URL but with a different query string FIELD1 value that would automatically select the appropriate menu option for the user. 2.3.1.5 Examples The following examples are assuming that your Webulator/400 URL is www.xyz.com/www5250,. Page 33 Webulator/400 User Manual 2.0 Using Webulator/400 If you would like the user to automatically start the program called MYPROG in the MYLIB library, you would use the following URL: www.xyz.com/www5250?PGM=MYPGM&LIB=MYLIB. If you would like the user to automatically take option 1 from the menu called MYMENU in the MYLIB library, you would use the following URL: www.xyz.com/www5250?MENU=MYMENU&LIB=MYLIB&FIELD1=1. You can also use the FIELD1 keyword to call an initial program that accepts dynamic parameters. Please be aware that in order to do this, you must give the user access to a command line which may not always be desirable for security reasons. Assume that the program MYPGM accepts parameters. You could call this program with the following URL: www.xyz.com/www5250?FIELD1=CALL+MYLIB/MYPGM+PARM('PARM1'+'PA RM2'). 2.3.2 Preformatted Text or HTML Tables Webulator/400 allows you to choose if the AS/400 screen data should be sent as HTML Preformatted Text or as a HTML Table. 2.3.2.1 HTML Preformatted Text Webulator/400 Version 1.0 sent all screens using HTML Preformatted Text and is the default method in Version 1.1. Webulator/400 will send Preformatted Text when the Tables Enabled (section 4.2.20 on page 99) configuration value is set to No. Preformatted text has the following characteristics: . It instructs the browser to use a fixed width font. This means that all characters (including spaces) on the screen will be the same width. This results in the characters going across a line will have the same spacing as in a traditional emulation program. . It produces the smallest size HTML file. . It is fast for the browser to render on the screen. . The width of input fields and submit buttons are larger than the number of characters that they hold. This means that the columns of any line that have input fields or submit buttons will not properly line up with columns on a line that have only output fields. The effects of this vary depending on the composition of the screen. It may range anyway from a small nuisance to having columns lining up with the wrong headings. 2.3.2.2 HTML Tables Webulator/400 Version 1.1 allows you to specify that all 5250 screen data should be included inside a HTML Table. Webulator/400 will send HTML tables when the Tables Enabled Page 34 Webulator/400 User Manual 2.0 Using Webulator/400 (section 4.2.20 on page 99) configuration value is set to Yes. HTML Tables have the following characteristics: . Tables are able to keep track on the largest number of pixels that is needed by any column. This means that columns that have either input fields or submit buttons will have more pixels allocated to them than columns that only have output fields. The result is that tables will guarantee that all fields that start in the same column will be properly aligned but there may be extra space between fields to compensate for the different widths of the various HTML elements used. . Tables allow for the specification of a background color different from the body of the form. This allows for reverse image attributes to be honored. . Tables by default use non fixed width fonts. This will make the 5250 screen look quite a bit different than when viewed using a traditional emulation program. You can change the font that tables use by setting the Table Font Name (section 4.2.18 on page 98) configuration entry. You may need to experiment with the font name to ensure that all of your target browsers support it. You should be safe setting this value to Courier. . It produces much larger HTML files. . It is slower for the browser to render on the screen. . It requires a browser that supports HTML Tables. 2.3.2.3 Recommendations You are better off using Preformatted Text if your 5250 screens do not use tabular data. It produces smaller files that are quicker to display and is supported by more browsers than tables. If your programs use tabular data and you are not satisfied with the way Preformatted Text aligns your columns, then experiment with Tables. 2.3.3 JavaScript Usability Enhancements 2.3.3.1 What is JavaScript? JavaScript is a HTML scripting language that allows HTML pages to interact with a browser. It was originally developed by Netscape as a way to extend the functionality of HTML. It is supported by Netscape Navigator 2.0 or later and Microsoft Internet Explorer 3.0. Various other browsers either support it or will support it in the near future. Browsers that do not support JavaScript should ignore the embedded JavaScript commands. Page 35 Webulator/400 User Manual 2.0 Using Webulator/400 2.3.3.2 Webulator/400 and JavaScript Webulator/400 can insert a small amount of JavaScript code into every HTML page that it generates. You can enable this support by setting the Send JavaScript (section 4.1.1 on page 80) configuration value. Webulator/400 uses JavaScript to add two important usability enhancements. The first enhancement allows the browser to insert the cursor at the start of the correct input field on the screen. It does this by calling a function during the onLoad event. This gives the user the ability to type into a field without first having to select it with the mouse. It also indicates to the user the first input field that may contain an error if the row and column are properly set by the AS/400 application. The second enhancement allows the browser to return the row and column position of the last input field that had focus. It does this by calling a function during the various onFocus events. This feature will allow the user to be able to get field level prompting without having to type a ? into the field. 2.3.3.3 Why you would want to disable JavaScript There are a couple of reasons why you may wish to disable the JavaScript support. First of all, JavaScript is an interpreted scripting language which means that the browser must perform extra work to follow the JavaScript instructions. Our testing did not indicate that performance is noticeably slower when including the JavaScript functions. Depending on the equipment and browsers that you use, you may see different results and determine that the added functionality is not worth the price in performance. Secondly, JavaScript is relatively new and not all browser support it. A browser should ignore any HTML tags (including JavaScript tags) that they do not understand. Of course there is no guarantee that all browsers will act appropriately. If your target audience uses ill-behaved browsers, you may wish to disable these feature. 2.3.4 AS/400 Display Types 2.3.4.1 Emulating Color and Monochrome Displays The Terminal Color (section 4.1.2 on page 80) configuration element lets you emulate either a color or monochrome display. If you emulate a monochrome display, Webulator/400 will display all text in a single color and display high intensity characters as bold. The monochrome display configuration requires an HTML 2.0 compliant browser to properly view Webulator/400 screens. You can optionally define the text color by configuring the Monochrome Text Color (section 2.3.10 on page 44). Please note that if you Page 36 Webulator/400 User Manual 2.0 Using Webulator/400 do this you will require a browser that supports extensions to HTML 2.0. If you emulate a color display, Webulator/400 will use the colors defined in the 5250 Data Description Specifications (DDS). While this is more visually appealing, it does require a browser that supports extensions to HTML 3.0. You can optionally choose to define one or all of the colors by configuring the Screen Text Colors (section 2.3.10 on page 44). 2.3.4.2 Controlling the AS/400 Terminal Size The Terminal Size (section 4.1.3 on page 81) configuration element lets you control the maximum width and height of the emulated display. This element allows you to one of the following terminals: . 24 x 80 Single Byte Terminal . 24 x 80 Double Byte Terminal . 27 x 132 Single Byte Terminal 2.3.5 Screen Background 2.3.5.1 Specifying a Background Color The Background Color (section 4.2.3 on page 85) configuration element lets you specify a color to use as a background for Webulator/400 screens. Please note that a browser that supports extensions to HTML 2.0 is required to properly view a screen with a background color. 2.3.5.2 Specifying a Background Image The Background Image (section 4.2.4 on page 86) configuration element lets you specify an image file to be used as a background for Webulator/400 screens. The background image file must be qualified to the Web Server/400 document root by including a leading slash ("/") in the file name. Failure to do this will result in Web Server/400 not starting. Please note that a browser that supports extensions to HTML 2.0 is required to properly view a screen with a background image. 2.3.6 Choosing a Header 2.3.6.1 Standard Webulator/400 Header The standard Webulator/400 header contains the following HTML entries: Page 37 Webulator/400 User Manual 2.0 Using Webulator/400 (Text From First Output Field) 2.3.6.2 Using a Custom Header Webulator/400 allows you to replace the standard header with either an HTML or plain text custom header (section 4.2.12 on page 93). This feature allows you to control what will appear above the 5250 terminal data in the HTML form. For example, you can include a link to your company's home page or an address for sending email. Custom HTML Headers If you choose to create a custom HTML header file, it must include the following tags: (Title Text) (Optional BODY elements) All embedded file references must be qualified to the Web Server/400 document root by including a leading slash ("/") in the file name. Failure to do this may result in broken links. Webulator/400 may insert some optional BODY attributes into your custom header based on your configuration settings. For example, if the session has a Background Color Value (section 4.2.3 on page 85) configured, but the custom header does not have a BGCOLOR attribute set, Webulator/400 will insert the proper attribute to honor the configuration value. If the custom header has a BGCOLOR attribute, Webulator/400 would use its value instead. The following sample header places a link to a home page and a mail address for the local WebMaster. Page 38 Webulator/400 User Manual 2.0 Using Webulator/400 Webulator/400 Demo Home | WebMaster

Custom HTML Headers and JavaScript If Send JavaScript (section 4.1.1 on page 80) is enabled, Webulator/400 automatically inserts ONLOAD="SetFocus()" into the form BODY tag. If your custom HTML header also includes a JavaScript function that must be called on the OnLoad event, you must include your function name in the BODY tag and a call to the SetFocus() function at the end of your function. For example, suppose that you have a JavaScript function called InitForm() and you want it to be called during the OnLoad event. Your custom HTML header should look something like this: Webulator/400 Demo Custom Plain Text Headers If you choose to create a custom plain text header file, Webulator/400 will use the standard Webulator/400 header followed immediately by the plain text header in a "Preformatted" text section. 2.3.7 Virtual Key Buttons 2.3.7.1 Purpose of Virtual Key Buttons AS/400 programs are dependent on receiving information about which key was pressed by the user to exit a screen. For example, an application may perform a specific operation if the user presses ENTER and a different operation if they Page 39 Webulator/400 User Manual 2.0 Using Webulator/400 press F3. The keys that allow a user to exit an AS/400 screen are known as Attention Identifier (AID) generating keys. Since Webulator/400 screens are HTML forms being executed by a browser, the user must be given browser submit buttons that represent the AS/400 AID keys in order to notify the AS/400 application of the action they wish to take. You must have all the Virtual Keyboard Buttons needed by your application defined in a Virtual Keyboard Row or the necessary Screen Keywords (section 2.3.12 on page 46) defined so that Webulator/400 will create the needed Virtual Keyboard Buttons. If you do not, the user will not have access to all of your application's functionality. Webulator/400 allows you to identify groups and positions of all the Virtual Keyboard Buttons needed to properly run your AS/400 applications. You have control over which buttons the user will see and have access to. For example, if you do not configure the System Request key to be a button, the user will not be given access to that function. 2.3.7.2 List Of Virtual Keyboard Buttons Webulator/400 allows the following AS/400 keys to be defined as Virtual Keyboard Buttons: . Enter . Help . Roll Down . Roll Up . System Request . Attention . Function Keys F1 through F24 Webulator/400 allows the following actions to be defined as Virtual Keyboard Buttons: . Reset - Resets form data to original values . Close - Closes the Webulator/400 session . Session Configuration (section 2.3.7.5 on page 41) - Allows the user to set a limited number of configuration values for their session only 2.3.7.3 Selecting AS/400 Key and Browser Command Buttons You select which AS/400 Key and Browser Command Buttons will be available by grouping the desired buttons in a manner of your choosing. You can locate a group of buttons either before or after the 5250 screen data. The ordering of the buttons inside a row is based on the order that they are defined. Page 40 Webulator/400 User Manual 2.0 Using Webulator/400 2.3.7.4 Example Assume that you would like a row of Virtual Keyboard Buttons consisting of the Enter, Reset and Close buttons to appear at the top of the screen. You would define these buttons using the following steps: 1.Run the Work with Webulator/400 Button Rows (WRKWBLROW) command with the name of your current Web Server/400 master configuration file. 2.Select the desired Webulator/400 directory entry. 3.Create a new Virtual Keyboard Row by typing the following items on the Work with Webulator/400 Virtual Keyboard Rows screen and pressing ENTER. . 1 in the Opt field to add a new row. . TOP in the Location field. . 1 in the Order field. 4.Add the Virtual Keyboard Buttons by taking option 5 (Work with virtual keyboard buttons) for the newly created row on the Work with Webulator/400 Virtual Keyboard Rows screen and pressing ENTER. 5.Type the following on the Work with Webulator/400 Virtual Keyboard Buttons screen to add the Enter Virtual Keyboard Button: . 1 in the Opt field to add a new entry. . Enter in the Key Name field. . 10 in the Seq field. . Enter in the Description field. 6.Type the following on the Work with Webulator/400 Virtual Keyboard Buttons screen to add the Reset Virtual Keyboard Button: . 1 in the Opt field to add a new entry. . Reset in the Key Name field. . 20 in the Seq field. . Reset Fields in the Description field. 7.Type the following on the Work with Webulator/400 Virtual Keyboard Buttons screen to add the Close Virtual Keyboard Button: . 1 in the Opt field to add a new entry. . Close in the Key Name field. . 30 in the Seq field. . End Session in the Description field. 2.3.7.5 Session Configuration The Session Configuration Button (section 2.3.7 on page 39) allows the user to set display settings for their current session. These settings will affect the current user's session and will not be saved for future sessions. The purpose of session configuration is to allow the user to choose the best display settings for their current browser configuration. If the session configuration button is not defined in one of the button rows, the user will not have access to these settings. Page 41 Webulator/400 User Manual 2.0 Using Webulator/400 The first session configuration value is the font size. Valid font sizes range from 1 to 7 with 3 being the default size used by browsers. This setting will allow the user to either increase or decrease the font size used for output fields on Webulator/400 screens. The initial font size setting for all sessions is 3. The second session configuration value allows the user to toggle between displaying blank lines and not displaying blank lines. Not displaying blank lines may be useful if the user is running the browser in low resolution (640 by 480) and they cannot see all of the Webulator/400 lines without scrolling inside the browser. The one disadvantage is that Webulator/400 screens will lose some of the resemblance to the original AS/400 screen. The initial setting for all sessions is to display blank lines. 2.3.8 Input Field Characteristics 2.3.8.1 Input Fields that Extend Multiple Lines The Extended Input Field (section 4.2.6 on page 88) configuration value allows you to choose how Webulator/400 will present input fields that extend multiple lines. An example is the extended command entry prompt that appears on some AS/400 screens. It often starts at line 18 column 7 and ends at line 21 column 79. You can choose to have these fields shown as either Scrollable Input Fields (section 4.2.6 on page 88) or Text Areas (section 4.2.6 on page 88). Scrollable Input Fields Scrollable input fields are fields that have a height of 1 row and a width equal to the starting position on the screen to the edge of the screen. It allows the viewable value to be scrolled either left or right as necessary. The advantages of scrollable input fields include: . Allows long entries without unnecessary CR/LFs. . Browser limits the amount of text that can be typed. The disadvantages of scrollable input fields include: . Single line entry looks different than native AS/400 screen. . May not allow entire entry to be viewed without manual scrolling. Page 42 Webulator/400 User Manual 2.0 Using Webulator/400 Text Areas Text Areas are fields that have a width and height that closely resemble the dimensions of the corresponding AS/400 input field. The advantages of text areas include: . More closely resembles the native AS/400 screen. . Allows entire entry to be viewed. The disadvantages of text areas include: . Does not automatically word wrap. Requires CR/LFs to get desired effect. . Browsers do not limit the amount of text that can be typed. 2.3.9 Output Characteristics 2.3.9.1 HTML Tables The Tables Enabled (section 4.2.13 on page 94) configuration value allows you to specify whether Webulator/400 should use HTML tables when generating forms containing the 5250 screen data. By default, Webulator/400 uses Preformatted Text when generating forms. HTML tables will do a better job of presenting column data than Preformatted Text but the HTML files will be much larger. Please see the Preformatted Text or HTML Tables (section 2.3.2 on page 34) section for more information. 2.3.9.2 Horizontal Rules The Horizontal Rules (section 4.2.13 on page 94) configuration value allows you to specify whether Webulator/400 should include HTML horizontal rules to provide screen separation. The following values can be specified: . BOTH - Horizontal rules will be included after the top row(s) and before the bottom row(s) of AS/400 Virtual Keyboard buttons. (Default). . TOP - A horizontal rule will only be included after the top row(s) of AS/400 Virtual Keyboard buttons. . BOTTOM - A horizontal rule will only be included before the bottom row(s) of AS/400 Virtual Keyboard buttons. . NONE - No horizontal rules will be added. 2.3.9.3 Blank Lines The Include Blank Lines (section 4.2.17 on page 97) configuration value allows you to specify whether Webulator/400 should include AS/400 blank lines in the HTML form. Page 43 Webulator/400 User Manual 2.0 Using Webulator/400 This value can be changed by the user for a particular session by selecting the Session Settings AS/400 Virtual Keyboard button. 2.3.9.4 Font Size The Font Size (section 4.2.8 on page 89) configuration value allows you to specify the initial font size that Webulator/400 will use. This font size is relative to the current font size defined by the browser. This value can be changed by the user for a particular session by selecting the Session Settings AS/400 Virtual Keyboard button. 2.3.9.5 Reverse Image Space Replacement Character The Reverse Image Space Replacement Character (section 4.2.16 on page 96) configuration value allows you to specify a replacement character for Webulator/400 to use when it encounters a blank output field with a display attribute of reverse image. The setting of this value can be helpful if you are running AS/400 applications that are dependent on a series of reverse image blanks to act as a window border. It can also be used to help designate an input field that is in error. The reverse image space replacement character will be placed in front of all input fields that have a display attribute of reverse image. 2.3.10 Screen Text Colors 2.3.10.1 How Colors Are Used The Terminal Color (section 4.1.2 on page 80) configuration value determines if Webulator/400 will emulate a color or monochrome display. Regardless of the choice, you have control over the color(s) used when presenting screen data. 2.3.10.2 Setting the Text Color for Monochrome Displays When emulating a monochrome display, Webulator/400 will allow you to define one color to use for all 5250 output fields. This is done by performing the following steps: 1.Run the Change Webulator/400 Configuration (CHGWBLCFG) command with the name of your current Web Server/400 master configuration file. 2.Select the desired Webulator/400 directory entry. 3.Change the Monochrome Color Conversion field to 000000. If this entry is not set, Webulator/400 will not set the text color and will allow the browser to determine the color to use based on its own configuration values. Page 44 Webulator/400 User Manual 2.0 Using Webulator/400 2.3.10.3 Setting the Text Colors for Color Displays When emulating a color display, Webulator/400 will allow you to define the colors to use for the following 5250 color attributes: . White . Green . Red . Turquoise . Yellow . Pink . Blue Assume that you wish to change the color Green to its brightest value. This is done by performing the following steps: 1.Run the Change Webulator/400 Configuration (CHGWBLCFG) command with the name of your current Web Server/400 master configuration file. 2.Select the desired Webulator/400 directory entry. 3.Change the Green Color Conversion field to 00FF00. Webulator/400 will even allow you to map a 5250 color attribute into a completely different color. For example, if you wanted to present all output fields with a color attribute of Green as the color Black, you would only have to change the above entry to 000000: If a color entry is not set, Webulator/400 will use a default color attribute that closely represents the defined color on the AS/400. 2.3.11 Graphical Menus Webulator/400 can add browser buttons to AS/400 menus to make it easier for the user to navigate through your AS/400 applications. When a user presses a menu browser button, it is the equivalent to typing the menu number in the accompanying input field and pressing the Enter key. You have the following Menu Type choices (section 4.2.14 on page 94): . No menu parsing - do not convert any menus to browser buttons. . Convert Menu Number - Converts the menu number to a browser button. . Convert Menu Description - Converts the menu description to a browser button. . Add Image Button - Adds an image button to the left of the menu number. Page 45 Webulator/400 User Manual 2.0 Using Webulator/400 You can also specify which input capable field will receive that menu item value selected. You can specify either the *FIRST or *LAST field on the screen will receive the value. 2.3.12 Identifying Screen Keywords Webulator/400 can parse output fields in the 5250 data stream for configurable keywords or phrases and convert them into Virtual Keyboard Buttons. Pressing these buttons are the equivalent to the user pressing Enter or the corresponding function key in a 5250 emulation program. This feature allows for an easier and quicker way for the user to navigate through your applications. 2.3.12.1 Defining Keywords To Parse You define the list of case sensitive keywords to parse by associating a text phase with an AS/400 AID Code. You can have multiple entries for any AS/400 AID Code. For example, you may want to search for all occurrences of the word Enter and ENTER and convert them to a browser button. See the configuration topic on Parsed Buttons (section 4.2.15 on page 95) for more information on how to configure keywords. You can choose to have the button display the keyword entry or the text description associated with the keyword. The default behavior is to use the text description for the button text. If you specify to use the text description, Webulator/400 will use all characters after the keyword until one of the following conditions is found: . The output field ends. . The location of the next parsing button is found. . Two or more spaces are encountered. . A colon (:), period (.), comma (,), semicolon (;), or a question mark (?) is encountered. 2.3.12.2 Example Assume that the last line of your AS/400 screen had the following output fields: F3=Exit F4=Prompt F12=Cancel You can have Webulator/400 convert these function key definitions into buttons by performing the following steps: 1.Run the Work with Webulator/400 Parsing Strings (WRKWBLPRS) command with the name of your current Web Server/400 master configuration file. 2.Select the desired Webulator/400 directory entry. 3.Type the following on the Work with Webulator/400 Parsed Buttons screen to parse for the F3 keyword: . 1 in the Opt field to add a new entry. Page 46 Webulator/400 User Manual 2.0 Using Webulator/400 . F3= in the Parse string field. . F3 in the Key name field. 4.Type the following on the Work with Webulator/400 Parsed Buttons screen to parse for the F4 keyword: . 1 in the Opt field to add a new entry. . F4= in the Parse string field. . F4 in the Key name field. 5.Type the following on the Work with Webulator/400 Parsed Buttons screen to parse for the F12 keyword: . 1 in the Opt field to add a new entry. . F12= in the Parse string field. . F12 in the Key name field. The first configuration entry is interpreted as search for all occurrences of the string "F3=" in the 5250 data stream and replace the output field with a Virtual Keyboard button that sends the F3 key code to the AS/400. 2.3.13 Choosing a Footer 2.3.13.1 Standard Webulator/400 Footer The standard Webulator/400 footer contains the and entries. 2.3.13.2 Using a Custom Footer Webulator/400 allows you to replace the standard footer with either an HTML or plain text custom footer (section 4.2.9 on page 90). This feature allows you to control what will appear below the 5250 terminal data in the HTML forms. For example, you can include a link to your company's home page or an address for sending email. Custom HTML Footers If you choose to create a custom HTML footer file, it must include the following tags: (Optional BODY elements) All embedded file references must be qualified to the Web Server/400 document root by including a leading slash ("/") in the file name. Failure to do this may result in broken links. The following sample footer places a link to a home page and a mail address for the local WebMaster. Page 47 Webulator/400 User Manual 2.0 Using Webulator/400

Home | WebMaster Custom Plain Text Footers If you choose to create a custom plain text footer file, Webulator/400 will insert the plain text footer in a "Preformatted" text section followed immediately by the standard Webulator/400 footer. 2.3.14 Termination Options 2.3.14.1 Closing Confirmation Webulator/400 allows you to determine if the user should be presented with a Confirmation Screen (section 4.2.21 on page 100) after they press the Close Session command button. You may want to set this value to Yes if you wish to protect users from accidentally pressing the Close Session button and losing their session data. The closing confirmation screen will allow the user to return back to the previous screen or to continue closing. You may want to set this value to No if you feel the likelihood of your users accidentally pressing the Close Session is remote or you find that they are less likely to close a session because of the extra step involved. 2.3.14.2 Termination URL Webulator/400 allows you to specify a Termination URL (section 4.2.22 on page 101) that control is transferred to when the user ends a Webulator/400 session. This allows for a transparent way for the user to be returned to a meaningful URL when they are finished with their Webulator/400 session. In addition to the URL, a description must be entered that will be used as the link text to your termination URL on all Webulator/400 error messages. 2.3.15 Embedding HTML in the 5250 Data Stream 2.3.15.1 V3R1 / V3R6 Considerations Browsers are context sensitive to the data stream that they receive. In particular, they assume that all less than signs (<) are a start of an HTML keyword and will not display any characters until it reaches the next greater than sign (>). This will cause display problems for any AS/400 data stream that contains a < that is not an HTML keyword. Because of this, Webulator/400 recognizes a subset of HTML keywords and will escape all < characters (change the < to a different set of characters) that are not part of a recognized HTML keyword. This has two sets of ramifications. First is all < Page 48 Webulator/400 User Manual 2.0 Using Webulator/400 characters that are not a part of a recognized HTML keyword will be displayed properly on Webulator/400 screens. The second is that it is possible to embed certain HTML keywords into the 5250 data stream and have them be interpreted by the browser. This means that you can include such things as images or links to other URLs inside your screens. Please note that the number of supported HTML keywords is very limited. The following HTML keywords will be passed to the browser intact: . - Start of hyperlink anchor . - End of hyperlink anchor . - Image hyperlink Care should be taken before embedding HTML fields in your 5250 screens. You should take into account the following constraints when designing screens that will contain embedded HTML keywords. . You may want to make output fields that will contain HTML keywords to have a display attribute of Nondisplay (DSPATR(ND)). If you do not do this, users viewing the screen with an application other than Webulator/400 will see the HTML keywords as text and not as embedded images or links. . HTML keywords usually require a large number of characters. You may run into problems fitting them on your screen. . You may run into some spacing problems. There is sometimes little to no correlation between the amount of space needed for the keyword and the amount of space needed for the resulting image or link. 2.3.15.2 V3R2 Considerations With the release of V3R2, IBM has introduced the HTML DDS keyword that will allow AS/400 applications to embed any HTML tag into the 5250 data steam. This method of embedding HTML offers the following advantages: . HTML keywords do not occupy any screen space. You can add HTML anywhere on the screen no matter how crowded it is. . All HTML tags are supported. . HTML keywords will not be passed to normal green screens or emulation programs. One limitation imposed by IBM is that HTML keywords cannot be included in subfile records. Please refer to the following IBM publications for more information on the HTML DDS keyword. Page 49 Webulator/400 User Manual 2.0 Using Webulator/400 . AS/400 DDS Reference - SC41-3712-01 . AS/400 Application Display Programming - SC41-3715-01 2.3.16 Default Configuration Values In order to help get Webulator/400 configured, a default set of configuration values is assumed. The following values will be used unless they are overridden by the current directory entry or one of its parent directory entries. Background Color The default Background Color (section 4.2.3 on page 85) is "Blank". This means that there will be no background color used. This value can be changed by setting the BACKCOLOR parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Background Image The default Background Image (section 4.2.4 on page 86) is "Blank". This means that there will be no background image used. This value can be changed by setting the BACKIMAGE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Color Conversion The default Color Conversion (section 4.2.5 on page 86) are as follows: White #FFFFFF Green #00BF00 Red #E50000 Turquoise #00BFBF Yellow #E5E500 Pink #E500E5 Blue #0000E5 Monochrome These values can be changed by setting the COLORCONV parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Extended Input Fields The default Extended Input Fields (section 4.2.6 on page 88) is Scrollable . This value can be changed by setting the EXTFIELDS parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Page 50 Webulator/400 User Manual 2.0 Using Webulator/400 Field Level Prompting The default Field Level Prompting (section 4.2.7 on page 89) is ?. This value can be changed by setting the FLDPROMPT parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Font Size The default Font Size (section 4.2.8 on page 89)is 3. This means that the current browser font size will be used. This value can be changed by setting the FONTSIZE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Footer File The default Footer File (section 4.2.9 on page 90) is "Blank". This means that the standard Webulator/400 footer will be used. This value can be changed by setting the FOOTFILE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Header File The default Header File (section 4.2.12 on page 93) is "Blank". This means that the standard Webulator/400 header will be used. This value can be changed by setting the HEADFILE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Horizontal Rules The default Horizontal Rules (section 4.2.13 on page 94) is Both. This means that there will be a horizontal rule drawn between both the top and bottom sets of AS/400 virtual keyboard buttons and the 5250 screen data. This value can be changed by setting the HORIZRULE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Light Pen Image The default Light Pen Image (section 4.2.10 on page 91) is /icons/ltpen.gif . This is an image of a small red circle. This value can be changed by setting the LIGHTPEN parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Menu Type The default Menu Type (section 4.2.14 on page 94) is None. This value can be changed by setting the MENUTYPE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Page 51 Webulator/400 User Manual 2.0 Using Webulator/400 Parsed Buttons The default Parsed Buttons (section 4.2.15 on page 95) is"Blank". This means that there will be no keywords parsed in the screen text and converted to browser submit buttons. This value can be changed through option 8 of the WRKWWWDIR command or directly through the WRKWBLPRS command. Reverse Image Space Replacement Character The default Reverse Image Space Replacement Character (section 4.2.16 on page 96) is *None. This means that you will not be able to see any spaces that have an attribute of reverse image. This value can be changed by setting the RICHAR parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Send JavaScript The default Send JavaScript (section 4.1.1 on page 80) value is Disabled. This value can be changed by setting the SNDJAVASCR parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Please see the JavaScript Usability Enhancements (section 2.3.3 on page 35) for more information concerning the use of JavaScript. Show Blank Lines The default Show Blank Lines (section 4.2.17 on page 97) value is Yes. This means that you will see all blanks lines on the AS/400 screen. This value can be changed by setting the SHOWBLINE parameter through option 10 of the WRKWWWDIR command or directly through the CHGWBLCFG command. Signon Method The default Signon Method (section 4.4.1 on page 103) is Disabled. This is the only configuration entry that must be overridden in a directory entry before a URL is accessible. This value is disabled because of the potential security issues associated with the other available Signon Methods (section 2.2.1 on page 20). This value can be changed by setting the SIGNON parameter through option 10 of