Webulator/400R User's Guide Version 2.0 COPYRIGHT c 1996, 1998 I/NET, INC. Revision B Copyright c 1996, 1998 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/400R is a trademark of I/NET, Inc. Other brand and product names are trademarks or registered trademarks of their respective holders. Webulator/400R User Manual, Version 2.0 Table o Table of Contents 1. GETTING STARTED ..................................5 1.1 HARDWARE REQUIREMENTS .........................6 1.2 SOFTWARE REQUIREMENTS .........................8 1.3 TCP/IP CONFIGURATION TIPS .....................9 1.4 INSTALLATION .................................16 1.5 WHAT'S NEW WITH VERSION 2.0 ..................20 1.6 MIGRATION ....................................22 1.7 INITIAL WEBULATOR/400 SETUP ..................27 1.8 WEBULATOR/400 HTTP FILES .....................29 1.9 STARTING THE SERVER ..........................30 1.10 TESTING THE SETUP ............................31 1.11 VIEWING WEBULATOR/400 DOCUMENTATION ..........33 2. USING WEBULATOR/400 .............................34 2.1 WEBULATOR/400 ARCHITECTURE ...................35 2.2 WEBULATOR/400 SESSION MANAGEMENT .............37 2.3 SECURE WEBULATOR/400 SESSIONS ................38 2.4 SETTING UP SECURE SESSIONS (SSL) .............43 2.5 URL LOCATIONS ................................49 2.6 ALIASES ......................................51 2.7 NLS ARCHITECTURE .............................56 2.8 CUSTOMIZING WEBULATOR/400 ....................60 2.9 PROTECTING YOUR AS/400 .......................98 2.10 WEBULATOR/400 SECURITY TOPICS ...............108 2.11 USER PROFILE CONSIDERATIONS .................110 2.12 AS/400 VIRTUAL TERMINAL CONSIDERATIONS ......112 2.13 AS/400 PROGRAMMING CONSIDERATIONS ...........113 2.14 AS/400 SYSTEM VALUES ........................114 2.15 AS/400 SYSTEM AUDITING ......................116 2.16 OTHER SECURITY TIPS .........................117 2.17 LOGS ........................................119 2.18 ERROR LOG ...................................120 2.19 ACCESS LOG ..................................122 2.20 STATUS CODES ................................126 2.21 WEBULATOR/400 USEABILITY CONSIDERATIONS .....127 2.22 SESSION BASED CONFIGURATION .................130 3. COMMANDS .......................................133 3.1 WEBULATOR COMMANDS ..........................134 4. CONFIGURATION VALUES ...........................173 4.1 ALL CONFIGURATION VALUES BY CATEGORY ........174 4.2 ALL CONFIGURATION VALUES IN ALPHABETICAL ORDER178 5. CONFIGURATION FILES ............................262 5.1 CONFIGURATION FILES .........................263 Page 3 Webulator/400R User Manual, Version 2.0 Table o 5.2 HOW TO CONFIGURE THE SERVER .................265 Page 4 Webulator/400R User Manual, Version 2.0 1.0 Get 1. Getting Started Page 5 Webulator/400R User Manual, Version 2.0 1.0 Get 1.1 Hardware Requirements 1.1.1 Hardware Requirements Listed below are the minimum hardware requirements needed to run Webulator/400. Basically, any AS/400 running V3R1M0 or later can run Webulator/400 just fine. The most challenging hardware configurations involved with Webulator/400 are the TCP/IP and Internet connections (Network Configurations on page 6). . Any AS/400 that is supported by OS/400 V3R1M0 or later supports Webulator/400. . The DASD, RAM, and processor levels chosen depends on individual capacity and performance requirements. . Optional: Workstation access to the Integrated File System and/or Shared Folders through PC Support/400 or Client Access/400. The management of site is simplified with direct workstation access to stream files on the AS/400. 1.1.2 Network Configurations In order for Webulator/400 to be useful, TCP/IP connections to machines other than the AS/400 running the product must be available. This is typically done through a Local Area Network (LAN) or through X.25. The outside machines might be PCs on the LAN or Internet customers attached to your AS/400 through a TCP/IP router. Below are the most common network configurations that can be used by Webulator/400. 1.1.3 Webulator/400 over a LAN . Local Area Network (LAN) . Token Ring, Ethernet, or X.25. . AS/400 . Version 3 Release 1 Mod 0 or later. . Connected to Token Ring, Ethernet, or X.25 LAN . TCP/IP . Webulator/400 . Workstations . Connected to Token Ring or Ethernet LAN or over X.25 . TCP/IP . Web browser Page 6 Webulator/400R User Manual, Version 2.0 1.0 Get . Client Access/400 (for Web administrators only) Optional. 1.1.4 Webulator/400 over the Internet - LAN Router . Local Area Network (LAN) . Token Ring, Ethernet, or X.25. . AS/400 . Version 3 Release 1 Mod 0 or later. . Connected to Token Ring, Ethernet, or X.25 LAN . TCP/IP . Webulator/400 . Workstations . Connected to Token Ring, Ethernet, or X.25 LAN . TCP/IP . Web browser . Client Access/400 (for Web administrators only) Optional. . Internet Access . Router connected to LAN using Token Ring, Ethernet, or X.25 . Telecommunication company connection from your router to access provider 1.1.5 Non-Network Configurations It is recommended that Webulator/400 be used over a Token Ring, Ethernet, or X.25 TCP/IP connection. You may be able to use Webulator/400 over a non-networked configuration using direct dial-up Internet access based on your level of OS/400. Please refer to your IBM AS/400 documentation for your available options concerning direct dial-up Internet access. Page 7 Webulator/400R User Manual, Version 2.0 1.0 Get 1.2 Software Requirements Webulator/400 works without any changes to the installed configuration. However, not all features will be available in this default installation. Listed below are the software requirements for Webulator/400. . OS/400 V3R1 or later. The supported versions of OS/400 come with all of the TCP/IP components necessary to run Webulator/400. The separate product TCP/IP Connectivity Utilities/400 is not used by Webulator/400, but can be used in conjunction with Webulator/400. . TCP/IP connectivity with Web client machines. See TCP/IP configuration tips for more details. See Hardware configuration (section 1.1 on page 6) for network configuration details. . The latest cumulative PTF package. This is not necessary but highly recommended. The GA release and early cumulative PTF packages experienced some problems when IFS and TCP/IP interacted with each other. . Optional: Client Access/400 or PC Support/400 (or equivalent) for workstation access to the Integrated File System and/or Shared Folders for Webulator/400 management. Page 8 Webulator/400R User Manual, Version 2.0 1.0 Get 1.3 TCP/IP Configuration Tips This section is intended to give some very basic background of TCP/IP terminology and some tips on how to configure TCP/IP on your AS/400 so that you can run the Webulator/400 product. All of the following information refers to TCP/IP for the V3R1M0 version or greater of the OS/400 operating system. 1.3.1 TCP/IP Terms Internet Network An internet network is the term used to describe a network that contains a collection of machines communicating together using the internet protocol (IP). The term Internet with a capital "I" is considered THE Internet which is the largest implementation of a network running the internet protocol. All references to an internet network using a lower case "i" refers to a local network which may or may not be connected to the Internet. Host The term host is used to describe any machine with an IP address participating on an internet network. This includes workstations and machines running OS/400. Internet Protocol (IP) Address A 32 bit number broken up into 4 bytes (each 8 bits in size). The number will be represented as a decimal number with a "." separating each of the 4 bytes. In the decimal notation each of the four numbers can contain a value between 0 and 255. The values 0 and 255 are considered special values (broadcast and loopback) and should not be used when determining a host's IP Address. All machines on an internet network must have a unique IP address. IP addresses include a network and host portion. The network portion is used to determine which network the host resides on, and the host portion is used to uniquely identify the machine within that internet network. This concept can get complicated, especially if subnetting is taking place within your network. Gateway or Router A machine that is used to bridge two internet networks together. This is needed when you want to send/receive information outside of your local network. For example, if your AS/400 is going to be connected to the Internet you will need a router to connect your local network to one of the Internet backbone networks (or to a network Page 9 Webulator/400R User Manual, Version 2.0 1.0 Get which is connected through other networks to one of the Internet backbone networks). Route A route is used to determine the IP address of a gateway. A route is not needed for information which is being sent to or received from machines which reside on the same internet network. Subnet Mask The subnet mask is used to determine what bits of the IP Address are used to assign the network portion. Any bits within the subnet mask that are set to 1 are used to determine the network. You will need additional information beyond this documentation if you intend to set up sub-networks within your internet network. However, we should note that the subnet mask is needed to configure TCP/IP on the AS/400 and further discussion will take place to assist you in setting this value. Ping A TCP/IP utility which sends test information and waits for the information to return. The utility displays the amount of data sent and received and the amount of time elapsed while doing so. The utility is very useful when testing the TCP/IP configuration. "Ping" is the name of the command. It accepts one parameter, the IP address or host name of the remote system to send/receive the data. 1.3.2 Assigning your AS/400 an IP Address If you plan on placing your server on the Internet, you will need to discuss the assignment of the network portion of your IP address with your Internet access provider. If you are not planning on placing your AS/400 on the Internet or your Internet access provider does not currently have a permanent IP address for you, then you are not restricted to the address you want to use. However, as soon as your internet network connects to other internet networks your network's IP addresses must be unique throughout all of the networks connected. This value can be reconfigured at a later point if you want to the AS/400 to be accessible on the Internet and you don't currently have an Internet access provider or your provider does not have a permanent address that they can assign to you immediately. Note: all hosts on the same network require the same network portion of the IP address and only the host portion of the IP address will be unique per machine. Page 10 Webulator/400R User Manual, Version 2.0 1.0 Get 1.3.2.1 Assigning the network portion of an IP Address In the case where the network portion of your IP address has not been assigned to you by a network administrator or an Internet access provider, you can use this section to better understand the network portion and assign one yourself. The most typical type of network address is a class 'C' address. A class 'C' address begins with the first byte having a value in the range of 192 to 223. For our example we will choose 200 for the first portion of the network address, which indicates that we are assigning a class 'C' address and that we expect to have less than 254 machines on our internet network. For the rest of the network portion we will choose values of 1. Therefore, we will use the address "200.1.1" as the network portion of our IP address. 1.3.2.2 Assigning the host portion of an IP Address For our discussion we are assuming that the network portion was defined to be a class 'C' address with no subnetworks defined. With a class 'C' address the last byte will be used for the host portion allowing the address of 1 - 254 to be used for these values. It would make sense for the administrator of this internet network to make all of the host portion assignments and to track these values in order to ensure that each machine is assigned a unique ID. 1.3.3 Working with the OS/400 commands to configure TCP/IP This section of the Webulator/400 documentation will assist the user in configuring the minimum TCP/IP features necessary to run the Webulator/400 product. The user must signon as QSECOFR or have equivalent authorities in order to be able to use the following commands effectively. Some of the commands will let you view the information but not change it if you do not have these authorities. The CFGTCP is an OS/400 command which gives the user a list of options available to configure the TCP/IP interface. Select the Work with TCP/IP interfaces option 1. The user will be presented with a screen that shows the current interfaces configured. An interface as it is presented on this screen refers to the line supporting the TCP/IP protocol and the IP address associated with that line. The *LOOPBACK line is a special line and is required for TCP/IP to operate properly. To add an interface use option 1 (also available directly as the ADDTCPIFC command). The three required parameters are: Page 11 Webulator/400R User Manual, Version 2.0 1.0 Get Internet address The value required for this parameter is the IP address chosen for this AS/400. If the machine is acting as a gateway and has multiple lines being configured to support TCP/IP then this value is the IP address set for the line being configured. Line description V3R1 OS/400 TCP/IP does not support all types of line descriptions. Refer to the help information available from this parameter within the ADDTCPIFC command for detailed information about what line descriptions are supported. The typical line descriptions used when configuring a TCP/IP connection for use with the Webulator/400 product would include a permanent connection such as Token Ring or Ethernet LAN connections. This would allow the Webulator/400 product to be available 24 hours a day 7 days a week without incurring additional usage costs. If the Webulator/400 product were to be made available through an Internet connection then either the Token Ring or Ethernet connection could be used along with a router connected to a leased line. The leased line would be permanently connected to the Internet access provider and available 24 hours a day 7 days a week at a fixed rate. Subnet mask Set this value to 255.255.255.0 for a class 'C' address which has no subnetworks defined. For any other type of scenarios additional research will be required. Refer to the TCP/IP terms (Subnet Mask on page 10) section above for a basic definition of subnet mask. The other parameters should not require any changes for the basic setup. If you are just getting started or are not connected to any other internet networks then the OS/400 side of things are all up and running ready and are ready to be used. If you have an Internet connection or a connection with other internet networks, you will need to configure a route to the gateway for data to flow between these internet networks. The CFGTCP command option 2 Work with TCP/IP routes provides a list of already configured routes. Within this option you have the ability to add routes. You will want to add a default route that is used for all traffic that is not destined for the internet network that the AS/400 resides on (machines that contain a different IP Address network portion other than that set for this AS/400 machine). Choose option 1 (also available directly as the ADDTCPRTE command) to add the default route. The three required parameters are: Page 12 Webulator/400R User Manual, Version 2.0 1.0 Get Route destination "*DFTROUTE" is the keyword used to indicate the default route. Subnet mask "*NONE" is the only valid value to specify for a default route. Next hop The IP address of the gateway (router) should be specified for the next hop parameter. This indicates that for the default route all of the information being sent out should next go the gateway machine. From there the gateway machine will use its routing tables to determine where to send the information. 1.3.4 Starting and Testing your TCP/IP Configuration The STRTCP command is used to start the TCP/IP services on the AS/400. After the TCP/IP services have been configured and started, you will want to test the configuration. The PING command is a good way to test the local and remote TCP/IP configurations. First use the PING command to test the local configuration by specifying the AS/400's IP address for the Remote system parameter. Check the results of the PING command by looking at the job log. If the job log shows that 100% of the packets sent were received successfully then the configuration on the AS/400 was a success. After verifying the local configuration the remote configurations can be tested. In order to test any remote configurations you need to have another machine configured and running TCP/IP on your internet network (your gateway is a good test if you have one configured and running). Use the PING command again this time specifying the remote system IP address or host name. Again check to ensure that 100% of the packets were successfully sent and received. 1.3.5 Host Names 1.3.5.1 Local Host Name Configuration Up to this point we have discussed the host machines by referencing them using a unique IP address. A second way to reference the host machines is to assign them a host name. A host name is an alternate meaningful name assigned to a host. For example, the host name of www.inetmi.com refers to the web server I/NET, Inc. is running to demonstrate the Webulator/400 product. The www portion of that name is the Page 13 Webulator/400R User Manual, Version 2.0 1.0 Get host portion the inetmi.com portion is the domain name. The local host and domain name can be set using option 12 (Change local domain and host names). If you are planning on connecting to the Internet you should discuss registering a domain name for your internet network with your Internet access provider. Problems Starting the Webulator/400 Due to Local Host Name Configuration The Webulator/400 product requires a local host name to be set either through the TCP/IP configuration, CFGTCP command option 12 (Change local domain and host names) or through the Webulator/400 server host name (section 4.2.73 on page 247) configuration value. The error message displayed on the STRWBL (section 3.1.2 on page 136) command indicating this error condition is: "The local host name could not be determined and was not explicitly set." 1.3.5.2 Remote Host Name Configuration The CFGTCP command provides multiple ways to assign remote host names. The first way would be to update the local host table using option 10 (Work with TCP/IP host table entries) (this would allow you to map the IP address of the remote machine to a meaningful name). The drawback to doing it this way is that if you have a lot of machines that you would like to reference by name, you have to add them all to this table. A second way of configuring names would be to reference a remote host running the TCP/IP Domain Name Service (DNS) using option 13 (Change remote name server). By using a DNS server hosts can be added to your network with meaningful names without any additional configuration required to remote machines. V3R1 OS/400 TCP/IP does NOT include a the ability to act as a DNS. Performance Problems Due to Remote Name Server Configuration Significant performance problems can occur due to an incorrect configuration of the remote name server within the OS/400 TCP/IP. The remote name server, also known as a Domain Name Server (DNS), is used by the Webulator/400 product to query the host name of a machine requesting a document. If this configuration specifies a search first parameter of *REMOTE and the remote DNS does not respond, the server will have to wait for the query to time-out (the number of retry attempts configured also extends the amount of time the request waits before failing). If you do not have a DNS available to you either from your Internet service provider or internally within your organization, you should leave the server address blank and specify *LOCAL for the search first parameter. This should correct your time- out delay, which in turn will increase the speed of the server. The only other side effect to this configuration change is that the access log (section 2.19 on page 122) Page 14 Webulator/400R User Manual, Version 2.0 1.0 Get file will contain the IP address of the machine requesting the document, not the host name. For additional information concerning the configuration of TCP/IP the user can reference the OS/400 publications or the information provided online by the IBM Corporation (http://as400bks.rochester.ibm.com/). Page 15 Webulator/400R User Manual, Version 2.0 1.0 Get 1.4 Installation 1.4.1 Installing Webulator/400 1.4.1.1 Important Pre-Installation Instructions Performance Problems Due to Domain Name Server Configuration Significant performance problems can occur due to an incorrect configuration of the remote name server (Remote Host Name Configuration on page 14) within the OS/400 TCP/IP. The remote name server, also known as a Domain Name Server (DNS), is used by the Webulator to query the host name of a machine requesting a session. If this configuration specifies a search first parameter of *REMOTE and the remote DNS does not respond, the Webulator will have to wait for the query to time-out (the number of retry attempts configured also extends the amount of time the request waits before failing). If you do not have a DNS available to you either from your Internet service provider or internally within your organization, you should leave the server address blank and specify *LOCAL for the search first parameter. This should correct your time-out delay, which in turn will increase the speed of the Webulator. The only other side effect to this configuration change is that the access log file will contain the IP address of the machine requesting the document, not the host name. Problems Starting the Webulator Due to Local Host Name Configuration The Webulator/400 product requires a local host name to be set either through the TCP/IP configuration (Local Host Name Configuration on page 13), CFGTCP command option 12 (Change local domain and host names) or through the Webulator/400 server host name (section 4.2.73 on page 247) configuration value. The error message displayed on the STRWBL (section 3.1.2 on page 136) command indicating this error condition is: "The local host name could not be determined and was not explicitly set." 1.4.1.2 Installation Instructions If migrating from a previous version, please read the migration instructions (section 1.6 on page 22) before continuing with the installation. Installing Webulator/400 on the AS/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 the server's objects (Objects Installed on page 17). Page 16 Webulator/400R User Manual, Version 2.0 1.0 Get 2.Ensure the system value QALWOBJRST is set to either *ALL or *ALWPGMADP. The Webulator/400 service program WBLVAUTSRV adopts authority for the purpose of validating user profiles and passwords. The Webulator documentation; sign on methods (section 2.8.1 on page 60), includes more information on this topic. QALWOBJRST can be reset, if needed, after the installation is successfully completed. 3.Run the system command LODRUN to install the server 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 20 minutes depending on the tape device and AS/400 model. 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. 4. If problems persist, please contact support. 1.4.2 Objects Installed The following objects were created/restored on the AS/400 by the installation program: . A user profile named WBLUSER was created. WBLUSER has no password, a user class of *USER, and no special authorities. The product user profile WBLUSER owns all of the objects installed. . The product user profile WBLUSER was granted *USE authority to job queue QSYSNOMAX. . The product library WEBULATOR was restored. WEBULATOR contains all of the product code. Product commands, a message file, menus, and panel groups were copied into library QSYS. Two utility programs are provided in library WEBULATOR that can be used to maintain the product objects that are copied into QSYS: 1. CPYQSYS: Copies product commands, message file, menus, and panel groups into library QSYS. This program may be needed after installing a new release of OS/400. 2. RMVQSYS: Removes product objects from library QSYS. If the product objects are removed from QSYS, either WEBULATOR will need to be added to the library list to access commands and menus or the commands and menus must be fully-qualified with the product Page 17 Webulator/400R User Manual, Version 2.0 1.0 Get library. This program needs to be run after each installation of product code. Neither program requires any parameters. . A product job description named WBLJOBD was created in library WEBULATOR. The job description was setup to use the job queue QSYSNOMAX. The product user profile WBLUSER was changed to use the created job description. . A product authorization list named WEBULATOR was created. The authorization list is used to secure public authority to all of the Webulator's commands. By default, only users with *ALLOBJ special authority have access to running Webulator/400 commands. Additional users can be granted authority to running Webulator commands by adding the users to the WEBULATOR authorization list. . A physical file named INSTLOG was created in the WEBULATOR product library. INSTLOG is used by Webulator/400 to record each time the product or a product fix is installed. . A directory named WBL was restored into the root of the IFS file system. WBL contains many other directories and stream files. WBL contains the following directories: . Cfg directory contains Webulator/400 configuration files. The shipped configuration files are saved in a sub-directory named Shipped. . Logs directory is the default location of Webulator/400 log files. . Pubs directory is the default location of Webulator/400 online publications. . PlugIns directory contains files needed to enable browser keyboard support for Webulator/400 sessions. . Images directory contains images that are used by Webulator/400. . Key directory is used by Webulator/400 to store commerce keys. . Tmp directory is used by Webulator/400 for caching. 1.4.3 Uninstalling Webulator/400 There is not an uninstall command or program. The following steps can be followed to delete the product: 1.CALL WEBULATOR/RMVQSYS Deletes product objects that were copied into the QSYS library. 2.DLTLIB LIB(WEBULATOR) Delete the product library. 3.Delete the \Wbl directory (and all of the sub- directories and stream files). If access with the appropriate authority is available to IFS from a PC then it is recommended to use a deletion program that Page 18 Webulator/400R User Manual, Version 2.0 1.0 Get supports recursive/sub-directory deletion (if available). 4.DLTUSRPRF USRPRF(WBLUSER) Delete the WBLUSER user profile. WRKOBJOWN can be used to check if there are any remaining objects on the system before deleting the product user profile. Page 19 Webulator/400R User Manual, Version 2.0 1.0 Get 1.5 What's new with Version 2.0 1.5.1 Architectural Changes Earlier versions of Webulator/400 were tightly integrated with I/NET's Web Server/400 and Commerce Server/400 products. Version 2.0 has been uncoupled from the I/NET server family and will work with any native AS/400 Web server. For more information, please see Webulator/400 Architecture (section 2.1 on page 35) 1.5.2 New Configuration Options There have also been several additions and enhancements made to the Webulator/400 configuration options. . Input Inhibited Timeout (section 4.2.86 on page 259) - Webulator/400 can now be configured to have a separate timeout for input inhibited. Previous versions only had an inactivity timeout. . Keyboard Plugin (section 4.2.29 on page 208) - The keyboard plugin can be enabled/disabled using the WRKWBLSSN (section 3.1.23 on page 158) command. . Keyboard Plugin Buttons (section 4.2.30 on page 209) - Virtual keyboard browser submit buttons can now be shown when the Keyboard Plugin is enabled. . Signoff Action (section 4.2.84 on page 258) - Allows you to specify whether the user should be presented with a signon screen or automatically be sent to the termination URL when they sign off a Webulator/400 session. . Signon Screen Exit Program (section 2.8.1 on page 60) - Allows you to create your own Webulator/400 signon logic by writing a exit program that will be called each time a signon screen has been detected. . Subfile Detection (section 4.2.43 on page 223) - Webulator/400 can place clickable hot spots next to certain AS/400 subfile control characters. . Uppercase to Lowercase Conversion (section 4.2.24 on page 205) - Webulator/400 can automatically convert uppercase characters to lowercase characters to ensure that the entire data value can be see without scrolling. . Virtual Terminal Device CCSID (section 4.2.46 on page 225) - Webulator/400 can support terminal devices that are not in the same CCSID as the Webulator/400 server jobs. . Virtual Terminal Job CCSID (section 4.2.28 on page 208) - Webulator/400 can support interactive jobs that are not in the same CCSID as the Webulator/400 server jobs. Page 20 Webulator/400R User Manual, Version 2.0 1.0 Get 1.5.3 New Session Manager With earlier versions of Webulator/400, it was sometimes difficult to have multiple Webulator/400 sessions active within one browser window. Webulator/400 Version 2.0 has a built in Session Manager that will allow you to easily jump between Webulator/400 sessions. Please see Webulator/400 Session Management (section 2.2 on page 37) for more information. Page 21 Webulator/400R User Manual, Version 2.0 1.0 Get 1.6 Migration 1.6.1 End Webulator/400 Before Re-Installing All currently running Webulator servers must be ended with the ENDWBL command before re-installing the Webulator/400 upgrade. Also ensure that no product commands or menus are running. Use the WRKACTJOB command to verify there are no servers and commands running. You may see older version restored (CPF3722) messages in the joblog when migrating to the new version. These messages are normal and are generated because one or more of the product libraries have been backed up with a save command that had the update history (UPDHST) parameter set to *YES. 1.6.2 Migrating from Webulator/400 version 1.1 This section should be read by all customers migrating from a previous version of Webulator/400. Evaluate and duplicate Web Server/400 and Commerce Server/400 configuration files Many of the configuration elements that are part of Webulator/400 were also required by Web Server/400 and Commerce Server/400. These include many of the server related configuration items like port, logging files, request processors, content CCSID, initial library list, and access controls, as well as Webulator session characteristics. Files that have previously been used for Web Server/400, Commerce Server/400 and previous versions of Webulator/400 may be modified and tailored to function with this version of Webulator/400. Using the directory based migration command utility The MIGWBLWBL (section 3.1.9 on page 150) command has been designed to act as an aid during the installation and setup of version 2.x of Webulator/400. It provides the ability to migrate the configuration values that are found in a Webulator/400 (version 1.x) directory based configuration file to the appropriate Webulator/400 version 2.x session based configuration file. Only contents of the directory based configuration file will be migrated. Other aspects of the Webulator/400 configuration should be reviewed, duplicated, and modified manually. Values relating to non-Webulator/400 directories will not be reflected in the new Webulator/400 session configuration. As a result, definitions that were previously inherited from the root directory by all Webulator/400 sessions will not be Page 22 Webulator/400R User Manual, Version 2.0 1.0 Get migrated and should be evaluated and added to the session based configuration manually. Evaluate socket port Previous versions of Webulator/400 typically shared the socket port (usually port 80) between server HTTP requests and Webulator session requests via Web Server/400 or Commerce Server/400. Since Webulator/400 now includes its own server support, the ability to share ports with the HTTP server is no longer possible. The default port (section 4.2.77 on page 251) for Webulator/400 sessions is now 5061. You have the option to run with a separate port number (eg. 5061) or, with multihome support (section 4.2.72 on page 245), you can execute Webulator/400 sessions at another domain name or IP address using port 80. Evaluate session name entries In previous versions of Webulator/400, virtual terminal access was enabled through the HTTP serving capabilities of Web Server/400 or Commerce Server/400. This required a special distinction for Webulator/400 sessions within the Directory Based Configuration file - namely /*META/WEBULATOR directory entries. Webulator/400 version 2.0 no longer requires this distinction and, as a result, the Webulator Session entries cannot include the /*META/WEBULATOR prefix and instead begin with a root session defined as /. The MIGWBLWBL command automatically modifies these entries during the migration of the directory based configuration. Limits section definition entries are no longer needed Webulator/400 uses specific HTTP form method types to process interactive session information between the server and the browser. Since previous versions of Webulator/400 shared access control (section 2.9 on page 98) characteristics with Web Server/400 or Commerce Server/400, those products added a level of granularity that are not required for Webulator/400. This includes specific sections for varying method types. Since the HTML forms used by Webulator sessions relate to specific methods, it is no longer necessary to include the or section entries in the session based configuration. The MIGWBLWBL command removes these entries during the migration of the directory based configuration. Evaluate header and footer file entries Previous versions of Webulator/400 allowed for the inclusion of separate information at the top and bottom of every 5250 display. This information was stored in files and placed within the resulting HTML code when the Webulator/400 page is sent to the browser. Version 2.0 permits these entries to contain either a file name or a Page 23 Webulator/400R User Manual, Version 2.0 1.0 Get URL. New configuration sub-entries have been added to identify the type of entry (file or URL) that is contained in the header or footer configuration. As a result, a type and file CCSID must be included when specifying a file. The MIGWBLWBL command adds these entries (assuming the job's CCSID) during the migration of the directory based configuration. Certain default definition values have been modified In past versions of Webulator/400, mainstream browsers did not support all of the advanced functionality available in the product. Because of this, previous versions of the product shipped with certain functions disabled. Fortunately, browsers have advanced quickly with their support of advanced fuctionality and as a result, Webulator/400 Version 2.0 now ships with its advanced functions enabled. In addition, user feedback has indicated that some of our default values shipped in past versions of the product were not wanted. As a result of this, Webulator Version 2.0 has changed the following default configuration values: . The default for Horizontal Rule (section 4.2.57 on page 234) has been changed from *Both to *None. . The default for Reverse Image Space Character (section 4.2.45 on page 224) has been changed from *None to the character '*' (asterisk). . The default for Send Javascript (section 4.2.17 on page 199) has been changed from *No to *Yes. . The default for Table Font Name (section 4.2.59 on page 235) has been changed from *None to 'Courier'. . The default for Terminal Color (section 4.2.18 on page 200) has been changed from *Monochrome to *Color. . The default for Background Color (section 4.2.53 on page 231) has been changed from *None to '#CCCCCC' (light grey). . The '&KEYBOARD=Y' query string has been replaced with the parameter Keyboard Plugin (section 4.2.29 on page 208) with a default of *Yes. . The query strings '&VTJOBCCSID=nnn' and '&VTDEVCCSID=nnn' have been replaced with the Virtual Terminal Job CCSID (section 4.2.28 on page 208) and Virtual Terminal Device CCSID (section 4.2.46 on page 225) parameters with default values of *NoConvert. . The '&SUBFILE=Y' query string has been replaced with the parameter Subfile Scrolling Support (section 4.2.43 on page 223) with a default value of *No. . The query string '&UPPERTOLOWER=Y' has been replaced with the Upper to Lower Conversion (section 4.2.24 on page 205) parameter with a default of *No. Page 24 Webulator/400R User Manual, Version 2.0 1.0 Get Evaluate the resulting configuration The resulting configuration values (section 4 on page 173) should be evaluated to ensure that the new Webulator/400 configuration will function as desired and in a similar fashion to the original (version 1.1) configuration. Use the CHGWBLSVR (section 3.1.6 on page 147) CHGWBLSSN (section 3.1.24 on page 160), or WRKWBLSSN (section 3.1.23 on page 158) commands to modify other aspects of the Webulator/400 configuration. 1.6.3 Migrating From IBM's Workstation Gateway This section should be read by all customers migrating from the Workstation Gateway (WSG) TCP/IP product option from IBM. Using the migration command utility The MIGWSGWBL (section 3.1.8 on page 149) command provides the ability to migrate the configuration values that are pertinent to AS/400 Workstation Gateway (WSG) to an appropriate Webulator/400 session configuration. Contents of the INACTTIMO, DTARQSTIMO, DSPSGN, TOPBNRURL, BOTBNRURL, and CCSID parameters of the CHGWSGA command will be migrated in the following process: . INACTTIMO will be placed in the Terminal Timeout (section 4.2.85 on page 258) value of the session based configuration. . DTARQSTIMO will be place in the Input Inhibited Timeout (section 4.2.86 on page 259) value of the session based configuration. . DSPSGN will be evaluated for the value to be inserted into the Signon Method (section 4.2.81 on page 254) value of the session based configuration. . TOPBNRURL will be placed in the Header File (section 4.2.56 on page 233) value of the session based configuration. . BOTBNRURL will be placed in the Footer File (section 4.2.55 on page 232) value of the session based configuration. . CCSID will be placed in the Content CCSID (section 4.2.68 on page 242) value of the Master Configuration. The Port value for the "wsg" service in WRKSRVTBLE will also be migrated and placed in the Port (section 4.2.77 on page 251) Master Configuration value, as well as the first exit program found (controls WSG signon) that is registered for the QAPP0100 exit point. This will be placed in the Signon Method (section 4.2.81 on page 254) value of the session based configuration. Page 25 Webulator/400R User Manual, Version 2.0 1.0 Get Evaluate the resulting configuration The resulting configuration values (section 4 on page 173) should be evaluated to ensure that the new Webulator/400 configuration will function as desired and in a similar fashion to the WSG configuration. Use the CHGWBLSVR (section 3.1.6 on page 147) CHGWBLSSN (section 3.1.24 on page 160), or WRKWBLSSN (section 3.1.23 on page 158) commands to modify other aspects of the Webulator/400 configuration. Page 26 Webulator/400R User Manual, Version 2.0 1.0 Get 1.7 Initial Webulator/400 Setup The following steps must be performed before running the Webulator/400 Version 2.0 for the first time. 1.Install any AS/400 Web Server (Optional) Webulator/400 requires that you have an installed AS/400 http server if you wish to use any of the following Webulator/400 features: . Embedded files in custom headers/footers. . Embedded files resulting from HTML DDS keywords. . Webulator/400 keyboard plugin. . Webulator/400 graphical menus. . Webulator/400 subfile detection. 2.Install Webulator/400 (section 1.4 on page 16) 3.Set the Webulator/400 User File Path (WBLUSRFILE) Field (section 4.2.80 on page 253) You must set the path of the Webulator/400 user file if you plan to take advantage of the automatic signon capabilities (section 2.8.1 on page 60) 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 /WBL/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 WRKWBLPRF (section 3.1.19 on page 156) 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. 4.Evaluate the Maximum Webulator/400 Sessions (WBLMAXSSN) Field (section 4.2.79 on page 253) 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. This value can be set through the WBLMAXSSN field of the CHGWBLSVR (section 3.1.6 on page 147) command. 5.Evaluate Signon Method The sample Session Based Configuration file (/WBL/CFG/ACCESS.CFG) that is shipped with Webulator/400 contains a root session entry with a signon method (section 2.8.1 on page 60) of signon screen. "Signon screen" was chosen because of its ease of setup, but it does have some potential security Page 27 Webulator/400R User Manual, Version 2.0 1.0 Get 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 Webulator/400. This value can be set through the Sign-on method field through option 2 of the WRKWBLSSN (section 3.1.23 on page 158) command or directly through the CHGWBLSSN (section 3.1.24 on page 160) command. 6.Add Additional Webulator/400 Session Entries (Optional) The sample Session Based Configuration file (/WBL/CFG/ACCESS.CFG) that is shipped with Webulator/400 contains only the Webulator/400 root session entry and no child sessions. You can optionally add more Webulator/400 session entries by running the WRKWBLSSN (section 3.1.23 on page 158) command. The Webulator/400 root session will always be named /. If you want to add a new session entry off of the Webulator/400 root, you can add an entry such as /STATUS/. By creating additional sessions, you can have multiple URLs that will have different characteristics (such as which user will automatically be signed on). 7.Ensure Webulator/400 specific files are accessible through the native AS/400 server. (section 1.8 on page 29) 8.Set the Fall-thru Path for HTTP (section 4.2.21 on page 202). This value is needed to locate the native AS/400 HTTP server that is used by the shipped Termination URL (section 4.2.88 on page 260). This value can be set through the FALLTHRUH field of the CHGWBLSVR (section 3.1.6 on page 147) command. 9.Check AS/400 Virtual Terminals (section 2.12 on page 112) 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. 10. Start Webulator/400 (section 1.9 on page 30) If Webulator/400 is already started, then you may run the Set WBL Configuration Values (SETWBLCFG) (section 3.1.7 on page 148) command which will reconfigure Webulator/400. Please note that 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.8.22 on page 97) for more information. Page 28 Webulator/400R User Manual, Version 2.0 1.0 Get 1.8 Webulator/400 HTTP Files 1.8.1 Webulator/400 features requiring a HTTP server. Webulator/400 ships a small set of files that must be served from a standard HTTP server. Depending on your configuration, Webulator/400 may embed references to some of these files. Since Webulator/400 is a specialized HTTP server, it cannot serve these files directly. After configuring your Webulator/400 sessions, you should check if you must copy any of these shipped files to a location that is accessible to your native Web Server. If you are planning to use any of the following features, please ensure that the corresponding Webulator/400 files are available for use. . Keyboard Plugin (section 2.8.11 on page 78) . PLUGIN.WKY - Default location is in the server's document root directory. . Graphical Menus (section 2.8.15 on page 84) . MENUITEM.GIF - Default location is in the server's document root directory. . Subfile Detection (section 4.2.43 on page 223) . MENUHELP.GIF - Must reside in the server's document root directory. . MENUNEXT.GIF - Must reside in the server's document root directory. . MENUPREV.GIF - Must reside in the server's document root directory. 1.8.2 Webulator/400 online publications. Since Webulator/400 online publications are written in as HTML files, they cannot be served directly through the Webulator/400 specialized HTTP server. If you wish to view the publications online, you must either copy the files to a directory that is accessible to your native Web Server or configure your Web Server to have access to the /wbl/pubs directory. Please see Viewing Webulator/400 Documentation (section 1.11 on page 33) for more information. Page 29 Webulator/400R User Manual, Version 2.0 1.0 Get 1.9 Starting the Server 1.9.1 Starting Webulator/400 The following steps should be followed to start Webulator/400. 1.Sign on the AS/400 with a user profile that has *ALLOBJ authority (e.g., QSECOFR). 2.Once TCP/IP has been configured on the AS/400, start TCP/IP support using the STRTCP command (if not already started). 3.Start the server using the STRWBL (section 3.1.2 on page 136) command, which is accessible through the CMDWBL (Menus on page 136) menu. When starting the server for the first time perform the following steps: 1. Prompt the STRWBL command 2. Press enter (use the default master configuration file) 3. Press F10 to view additional parameters 4. Key in the product activation key provided to you by your supplier with the product tape and press enter. Contact your supplier if you did not receive an activation code or your activation code does not work. If the server does not start due to an error: 1. Check the joblog to determine the cause of the error. You may also need to check the server user profile's spooled files for a joblog that indicates why the server did not start (e.g., WRKSPLF WBLUSER). 2. Correct the problem. 3. Re-run the STRWBL command. 4. If problems persist, please contact support. Once the server is started, configured Webulator sessions should be available. The server can be stopped using the ENDWBL (section 3.1.3 on page 142) command. Page 30 Webulator/400R User Manual, Version 2.0 1.0 Get 1.10 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.7 on page 27) section for these tests to be valid. In order to perform the following tests, Webulator/400 must be started (section 1.9 on page 30) 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 or Exit Program, you should 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:port_no/ where: your.system.name is your AS/400 system's TCP/IP host name or IP address. port_no is your Webulator/400 port number (default is 5061). For example, assume that your HOSTNAME is www.xyz.com and your port_no is 5061. The name of your Webulator/400 root URL would be http://www.xyz.com:5061/. Access the Remaining Webulator/400 URLs. If you added additional Webulator/400 session entries using the WRKWBLSSN (section 3.1.23 on page 158) command, you should try to access their URLs also. To determine how to access child URLs, you must look at the names of your session entries. For example, assume that you have the following Webulator/400 session entries: / /STATUS/ Page 31 Webulator/400R User Manual, Version 2.0 1.0 Get The first entry is the Webulator/400 root session and the second session is a child off the root session. You must append the name of the child session entry to the URL of the Webulator/400 root to get the correct URL for the child session entry. Assuming that the root session URL is http://www.xyz.com:5061/, the URL for the child would be http://www.xyz.com:5061/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.8.20 on page 89) or are inheriting a value from one of their parent directories. If a session entry is inheriting an undesirable configuration value, you must define a new value in the current session to override the inherited value. These values can be set through options 2, 8 and 9 of the WRKWBLSSN (section 3.1.23 on page 158) command. Page 32 Webulator/400R User Manual, Version 2.0 1.0 Get 1.11 Viewing Webulator/400 Documentation All of the documentation is written in HTML (Hyper Text Markup Language). Upon installation, the Webulator/400 user guide documentation is located in the directory /WBL/Pubs. 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.11.1 Accessing Document Files Directly 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. Client Access/400 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 /WBL/Pubs directory or you can connect to the ROOT of the IFS file system and work your way through the path (/WBL/Pubs) to reach the documentation. 1.11.2 Accessing Documentation through a Web Server Depending on the Web Server you are using, you will have to take some additional steps before you can view the online documentation. If you are using I/NET's Web Server/400 or Commerce Server/400, you must copy the contents of the /WBL/Pubs directory to a directory that falls under your server document root (which by default is /WWWServ/Webdocs). For example, if you create a new directory named /WWWServ/Webdocs/WblV2Pubs and copy the contents of the /WBL/Pubs directory into it, you could view the base document by accessing the /WblV2Pubs/usrguide.htm file. If you are using another Web Server, you must either copy the contents of the /WBL/Pubs directory to an accessible directory or change your server's configuration so that your can serve files from the /WBL/Pubs directory. Page 33 Webulator/400R User Manual, Version 2.0 2.0 Usi 2. Using Webulator/400 Page 34 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.1 Webulator/400 Architecture 2.1.1 Webulator/400 Overview Webulator/400 version 2.0 is packaged offering that incorporates a highly specialized HTTP server and CGI program that allows users to run AS/400 green screen applications inside their browser. The Webulator/400 server will only fulfill Webulator/400 session requests and will not fulfill any other standard HTTP requests such as images and HTML files. Webulator/400 is meant to be used in conjunction with other native AS/400 servers such as I/NET's Web Server/400 and Commerce Server/400 or IBM's ICS and ICSS servers. The Webulator/400 server interacts with OS/400 through a set of APIs known as the Virtual Terminal (VT) APIs. The VT APIs allow Webulator/400 to emulate a physical device that is connected to an AS/400. They allow Webulator/400 to open, read, write and close virtual devices. A typical session would consists of a user accessing a Webulator/400 session. The server would read the session configuration, open the device and wait for screen data to be made available for that session. Once screen data was available, the server would convert the 5250 data stream to a HTML form and return it to the browser. At that time, the HTTP protocol would drop the connection. After the user has completed the necessary input fields on the Webulator/400 screen, they would press a desired action key and the form would be returned back to the Webulator/400 server. At that time the server would write the returned data to the AS/400 and wait for additional screen data to be made available. This sequence of events would continue until the session was terminated either through an user action or a timeout value and the server would close the corresponding virtual device making it available for another user. 2.1.2 Changes from Version 1.x Users of previous versions of Webulator/400 will notice a rather large design change in version 2.0. Version 1.x was an add on product to I/NET's Web Server/400 and Commerce Server/400 servers. Version 2.0 incorporates key Commerce Server/400 components with an enhanced version of the Webulator/400 1.1 into a single product that allows it to run with any native AS/400 Web server. The packaging of portions of Commerce Server/400 and Webulator/400 into one package should not be misconstrued to mean that Webulator/400 version 2.0 is a stand alone Page 35 Webulator/400R User Manual, Version 2.0 2.0 Usi package. While it may be possible to run version 2.0 as a standalone package, you will not be able to take advantage of all of Webulator/400's features if you do not have a native AS/400 Web server running. The Webulator/400 server has all of the functionality needed to properly handle input from a user, but it may generate HTML forms that have other objects embedded into them that require a HTTP server to deliver. For example, the keyboard plugin and any embedded images will not work correctly unless a full featured HTTP server is also available. Version 2.0 also uses different TCP/IP ports than previous versions. Since previous versions of Webulator/400 were essentially a CGI script being called from Web Server/400 or Commerce Server/400, it run on the same port as the server. Because version 2.0 has its own embedded server, it must run either on a non standard port on your existing TCP/IP address or run a separate TCP/IP address. Webulator/400's new default port is 5061. Page 36 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.2 Webulator/400 Session Management 2.2.1 Overview With earlier versions of Webulator/400, it was quite difficult to have multiple active sessions open inside a single browser window. In addition, the only effective method of returning to a Webulator/400 screen once you left a session as a result clicking on a link was to use the browser's back button. If the user would try to gain access to an existing session via a bookmark or link, it would result in a new Webulator/400 session being started. Webulator/400 Version 2.0 has a built in Session Manager that will help eliminate the complexity of managing active Webulator/400 sessions. 2.2.2 Accessing an existing session When accessing a Webulator/400 URL, the system searches for an active session. If an active session is found, the current screen for that session is sent to the user. For Example, your AS/400 application may have embedded HTML links to various static pages on your site. You can easily code a return to Webulator link in the static html file by referring back to a valid Webulator/400 URL. From a user's perspective, they would be able to click on embedded HTML links to see a static HTML page and then have a convenient link back to the current Webulator/400 session in which they left. 2.2.3 Accessing a new session Occasionally, users may have a need to access a second Webulator/400 session without ending the first session. With earlier versions of Webulator/400, the user would simply access a new valid Webulator/400 URL. This will no longer work with Version 2.0 since the Session Manager now assumes that you want to access the original session. To get around this assumption by the Session Manager, a new query string value has been added to the system. If a query string value of ?SESSION=NEW is appended to a Webulator/400 URL, a new session will always be started. 2.2.4 Managing multiple sessions If a user has multiple sessions active and they access a valid Webulator/400 URL (without the query string value of ?SESSION=NEW), the Session Manager will build a list of active sessions that the user can choose from. Once an active session is choosen, the current screen for that session is shown to the user. Page 37 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.3 Secure Webulator/400 sessions 2.3.1.1 Encryption This allows private conversations over the public Internet. Using Secured Webulator/400 sessions, you are able to have a browser obtain information off of your site that is encrypted. Even someone that can tap the wire between the machines cannot understand the communications. The same is true for data typed into the Webulator/400 screen. Sensitive information such as user ids and passwords are protected using strong encryption technologies. 2.3.1.2 Integrity Secured Webulator/400 sessions essentially guarantees that the data sent between the browser and server is unaltered during transmission. This would detect both transmission errors due to noisy communication lines and malicious modifications possibly made by someone in the middle of the server and browser. 2.3.1.3 Authentication Secured Webulator/400 sessions provide the visitors to your site confidence that they have reached your site and not someone else's site trying to impersonate your site. 2.3.2 Secured Webulator/400 Session Basics In this section, a handful of concepts specific to doing secured sessions over the World Wide Web are discussed. These concepts should be clear to anyone administering a secure Web site. The following section gets into more detail about how security is implemented. Understanding these topics is not critical, however the entire picture would be much more clear if these topics are also mastered. 2.3.2.1 HTTP and SSL Non Secured Webulator/400 sessions serve HTML forms using the Hypertext Transport Protocol (HTTP). This protocol does not perform encrypted transactions. The data sent between the browser and server is sent "in the clear," meaning that anyone that can tap into the wire connecting the two machines can eavesdrop on the conversation. In addition to HTTP, Webulator/400 can also be configured to encrypt the conversation by interfacing with the Secure Sockets Layer (SSL) protocol. If both the server and browser are communicating through SSL, then the HTTP conversation is Page 38 Webulator/400R User Manual, Version 2.0 2.0 Usi done securely. The Secure Sockets Layer encrypts data as it leaves one machine and decrypts it as it arrives at the other. There are three ways to set up Webulator/400 sessions. Webulator/400 can be configured to serve non secured sessions. This means the HTTP communications between the server and browser would not be encrypted. Webulator/400 can also be configured for secured sessions which means that all screens will be transmitted securely to the browser using SSL. And lastly, Webulator/400 sessions can be configured as a SSL Signon session. SSL Signon sessions can be thought of as a hybrid solution. Only signon screens will be encrypted using SSL. All other screens will use the standard HTTP protocol and will not be encrypted. You may want to consider using this approach if are willing to spend the extra CPU require for encryption to protect your user ids and passwords but do not consider the extra CPU requirements necessary for all other AS/400 screens. Configuring session security is done on a per-session basis using the Allowed Protocols (section 4.2.67 on page 241) session based configuration value. 2.3.2.2 Server Certificate Every server implementing secured transactions requires a server certificate. This is used to identify the Web site and to provide browsers with the Web site's Public Key. The public key is used to provide encryption, integrity, authentication and nonrepudiation. Server certificates are obtained from a Certification Authority such as VeriSign, Inc. A series of commands are provided to assist in the creation of a server certificate for a Web site. 2.3.2.3 Keylist Database File A Web site's security information is stored in the keylist database file. This file is encrypted using a user-supplied password. The file is reasonably protected by being encrypted, but it should also be physically guarded as much as possible. The server's certificate, public key, and private key are all stored in this file. The public and private keys are very large numbers that are used to perform the secure transactions. Only the private key needs to be closely guarded. The server's certificate and public key can be freely distributed. The server certificate, public key and private key are all interrelated and must be kept together in the same keylist database file. If a Web site has more than one certificate, then multiple keylist database files will be needed. This Page 39 Webulator/400R User Manual, Version 2.0 2.0 Usi might be the case if a Web site is using Multi-home support to host multiple secure Webulator sites on the same machine. Each instance of the server could either share the same keylist database file (and certificate) or use its own. 2.3.3 How Does Webulator/400 Do This? The exact details of how secure electronic communications are done are not important, but a few of the pieces can be helpful. The above listed features of a trusted Web site are accomplished using 1) Server Certificates, 2) Private and Public Keys, 3) Public Key Cryptography, and 4) Bulk Encryption Algorithms. 2.3.3.1 Server Certificates Every Webulator/400 server requires a server certificate if you wish to configure secured sessions. This is used to both prove its identity and to exchange encrypted information with browsers. The certificate contains a distinguished name of the server which is used to uniquely identify the server to visitors, it contains the server's public key, and it contains a digital signature of a Certification Authority. Distinguished Name This consists of information that uniquely identifies your Web site. Values such as the Internet host name of the machine, the company's name, and the State and country of the company. The Certification Authority will validate this information before providing a company their server certificate. Public Key The public half of a Web site's encryption key. Visiting browsers use this value to communicate securely with the server. This is described more below. Certification Authority A Certification Authority (CA) provides server certificates. Before a company can begin doing secure transactions, they need to request a server certificate from a CA. The CA will verify the identity and validity of the company's request for a server certificate and then provide a digitally signed server certificate. The company will then install this certificate into their Web server software. Digital Signature Using sophisticated mathematical algorithms, a digital signature of a document can be created that proves the identity of the signer and verifies the contents of the document. In the case of a server certificate, if the CA digitally signs the distinguished name and public key Page 40 Webulator/400R User Manual, Version 2.0 2.0 Usi portions of the certificate, then anyone that trusts the CA can be confident that the certificate has not been changed. 2.3.3.2 Private and Public Keys Part of the process of generating a server certificate is generating a pair of large numbers. One of these numbers, the public key, is shared with everyone who wants to communicate with the Web site. The other number, the private key, is only known to the Web site and its administrator(s). The private key is held in the strictest of confidence. Webulator/400 stores this in its keylist database file, encrypted using a user-supplied password. 2.3.3.3 Public Key Cryptography Public Key Cryptography is used to do two things: exchange bulk encryption keys and verify digital signatures. What is special about Public Key Cryptography is that anyone who knows a person's public key can use it to encrypt a message for that person that no one else can understand. The only way to decrypt that message is using the private key half of the public and private key. The opposite is also true: Something encrypted with a private key can only be decrypted with the public key. This allows two parties to communicate without previously exchanging a secret password. In terms of Web serving, the Web site's public key is provided to anyone that wants to securely communicate with that server. This is done by sending the server's certificate (which contains the public key) to a browser that wants information from the server. The browser then uses the server's public key to encrypt a password that will be used to encrypt the rest of the communication between the server and browser. Since the server is the only one that knows its private key that can decrypt something encrypted with its public key, the server is the only one that can successfully decrypt the password. Public Key Cryptography is also used to verify digital signatures. When a CA digitally signs a certificate, it is really encrypting a piece of the certificate data using the CA's private key. When a browser wishes to verify that signature, it decrypts the signature using the CA's public key and compares it to the certificate data. If they match then the digital signature is valid. 2.3.3.4 Bulk Encryption Algorithms In the discussion on Public Key Cryptography, the browser encrypted a password that would then be used by both sides to encrypt the rest of the data. Public Key Cryptography could be used to do all the encryption between the browser Page 41 Webulator/400R User Manual, Version 2.0 2.0 Usi and server, but it has two disadvantages: This would require that the browser also has a public and private key so the server can securely encrypt data sent to the browser. And, Public Key Cryptography is computationally very expensive. Instead of using Public Key Cryptography for the entire transaction, only a secret key, or password, is exchanged using this algorithm. Then this secret key is used by both sides to perform simpler and faster bulk encryption algorithms. Page 42 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.4 Setting Up Secure Sessions (SSL) 2.4.1 Overview With the unmodified, default configuration files shipped with Webulator/400, the server only supports HTTP Webulator sessions. That is, by default, the server does not do secured (i.e., SSL) transactions. Below are the steps that need to be accomplished before secured transactions can be performed. Please read through all the instructions presented here before proceeding. This page contains many hyperlinks to other Web sites that may change over time. Hopefully, the appropriate areas can always be found by starting at the site's home page or using the site's search engine. 1.Install (section 1.4 on page 16) Webulator/400. 2.Obtain a Server Certificate. 1. Create a Public Key, Private Key, and a certificate request. 2. Submit the certificate request to a Certification Authority. 3. Install certificate received from the Certification Authority. 3.Change Webulator/400 Configuration Values. 1. Set the Keylist Database File. 2. Set the Protocols configuration value to SSL. 3. Set the Allowed Protocols session based configuration value to SSL for the root session. 4.Start the server (or re-start a running server). 2.4.2 Obtaining a Server Certificate This step is the most time consuming step since it requires interacting with a new entity: a Certification Authority (CA). Customer's of Webulator/400 are able to easily obtain server certificates from the Certification Authority VeriSign, Inc. (http://www.verisign.com/) VeriSign, Inc. supplies server certificates (or Digital IDs ) for a variety of security enhanced products. You will become a customer of VeriSign once you purchase a server certificate from them. VeriSign will also assist you with any special needs you may have concerning your server certificate. Below are sources of additional information about VeriSign and server certificates: . Introduction to Cryptography (http://www.verisign.com/docs/pk_intro.html) . VeriSign Information Desk (http://digitalid.verisign.com/ask_veri.htm) Page 43 Webulator/400R User Manual, Version 2.0 2.0 Usi . Digital IDs for Servers (https://digitalid.verisign.com/ss_intro.html) . General Cryptography FAQ (http://www.rsa.com/rsalabs/newfaq/) from RSA Data Security, Inc. . VeriSign's Price Schedule (http://digitalid.verisign.com/Payment.htm) . Additional instructions for international (http://www.verisign.com/international/index.html) (non-US/Canadian) customers or Japanese (http://www.verisign.co.jp/) customers A server certificate/digital ID is required for Webulator/400 to serve secure sessions. The certificate will provide proof to your site's visitors that they are indeed communicating with your company, and it will provide browsers with your company's public key. This public key allows secure communications to be initiated between your server and your visitor's browsers. VeriSign provides an enrollment process that must be followed to receive a certificate. This allows VeriSign to validate your identity to ensure some other entity is not masquerading as your company. The entire process may take several days to complete and you cannot perform secure (SSL) transactions until everything is finished. 2.4.2.1 Creating a Public Key, Private Key, and Certificate Request The first step in obtaining a server certificate is to generate a public/private key pair and a certificate request by running Webulator/400's CRTWBLKEY (section 3.1.28 on page 165) command. Please check with your certification authority (https://digitalid.verisign.com/ss_intro.html) for additional information on the CRTWBLKEY (section 3.1.28 on page 165) command parameters that are required. The CRTWBLKEY command will create two new stream files: 1.Keylist file 2.Certificate request file The keylist file is an encrypted binary file that contains your public and private keys, which are used by the server to perform encryption and digital signing tasks. The keylist file is encrypted using the password provided on the CRTWBLKEY command. Page 44 Webulator/400R User Manual, Version 2.0 2.0 Usi The certificate request file is an ASCII text file whose contents will be given (e.g., cut-and-pasted) to the Certification Authority to produce your server certificate. Please note that VeriSign calls the certificate request file a certificate signing request (CSR). Each certificate request will require a new keylist and certificate request file. The following are reasons additional certificates may be acquired: . Previous certificate expiring . Test certificate needed . Multiple secure servers running on a AS/400 For each new certificate, change the CRTWBLKEY (keylist and certificate request) file parameters to use a different directory and/or file name. IMPORTANT: Make a backup copy of the keylist file after it is successfully created. A backup copy may be needed to replace a deleted or damaged/corrupted keylist file. Also, since the keylist file is an encrypted binary file other tools/editors, which may corrupt the keylist file, should not be used to try to view or manipulate the keylist file. WARNING: The keys are randomly generated and cannot be re- created if the file is lost or if the password is forgotten. If you lose access to this file, you must obtain a new certificate from VeriSign (for an additional fee) by repeating all of these instructions. 2.4.2.2 Submitting the Certificate Request VeriSign provides an on-line enrollment process used to request and receive server certificates. To obtain a server certificate/digital ID for Webulator/400 from VeriSign, go to the URL http://digitalid.verisign.com/server_ids.html (http://digitalid.verisign.com/server_ids.html). To do this, you will need a browser that is attached to the Internet and capable of performing SSL requests. Choose I/NET from the software vendor list and then press the SELECT button to continue. To obtain your site's certificate please follow VeriSign's directions. 2.4.2.3 Installing the Certificate After you receive your certificate from VeriSign through e- mail, you are ready to install the certificate into Webulator/400. This is done by running the AS/400 command ADDWBLCERT (section 3.1.29 on page 168). Step 1 The e-mail message that contains your certificate needs to be saved in a stream file in the root file system of Page 45 Webulator/400R User Manual, Version 2.0 2.0 Usi IFS or in QDLS (shared folders). If you have a drive connected to your AS/400 from your e-mail machine, save the message to a file directly on the AS/400. Otherwise, you can use FTP to transfer the file from your e-mail machine into QDLS on your AS/400. Step 2 Run the ADDWBLCERT command specifying the file created in Step 1 as the Signed Certificate File. For example, if you used FTP to get the file into QDLS on the AS/400 you may use a filename like /qdls/myfolder/cert.txt. Provide the same password and keylist file that was supplied to the CRTWBLKEY command that generated the certificate request file for this certificate. IMPORTANT: Make a backup copy of the keylist file after the server certificate is successfully added. If something should happen to the original (e.g., deleted, damaged) the backup would then be used. Most certification authorities will charge additional money to re-create the server certificate for a new keylist file. You should now have a valid and usable keylist file. Prior to this, trying to start Webulator/400 in a secure mode using this keylist file would fail. The keylist file needs both the public and private keys and the associated certificate to be valid. 2.4.3 Enabling Webulator/400 to do SSL The following three configuration values need to be changed in order to enable secure sessions through Webulator/400. After making these changes, all sessions served by Webulator/400 can be accessed with either SSL (encrypted) or HTTP (not encrypted). You have the option of setting up (HTTP and SSL on page 38) Webulator/400 sessions to require the use of SSL and/or HTTP. You can also start two instances of Webulator/400; one that handles regular HTTP requests and one that handles SSL requests. 2.4.3.1 Set the Keylist Database File Using the command CHGWBLSEC (section 3.1.27 on page 164), the keylist file path can be set to the newly completed keylist file. By default this would be /Wbl/Key/KeyList.Cfg. The other values can be left to their default values. The keylist file path also needs to be changed when updating the server to use a new certificate (the server must be stopped and restarted after changing this value). Page 46 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.4.3.2 Set the Protocols Value Using the command CHGWBLSSN (section 3.1.24 on page 160), the Protocols configuration value can be changed from HTTP to SSL or it can be set to both HTTP and SSL. 2.4.3.3 Set the Allowed Protocols Value Webulator Server/400 uses a Session Based Configuration value: Allowed Protocols (section 4.2.67 on page 241). This tells Webulator/400 which protocol (SSL or HTTP) is allowed for a particular session. Using the CHGWBLSSN (section 3.1.24 on page 160) command, set the Session Based Configuration file (ACCGBLFILE) to /wbl/cfg/access.cfg. If this value is already set to your own configuration file, you don't need to do this. Using the WRKWBLSSN (section 3.1.23 on page 158) command, add the session "/" using option 1 (Add). If this session is already present, you don't need to add it. Select option 14 on the "/" session. Select the appropriate allowed protocols value: . SSL: All sessions must be accessed using SSL . HTTP: All sessions must be accessed using HTTP . SSL and HTTP: SSL or HTTP can be used to access all sessions 2.4.4 Start the Server The server should now be ready to start, using the STRWBL (section 3.1.2 on page 136) command. If the server is already running, you must end the server and re-start it to enable secure transactions. SSL cannot be enabled by reconfiguring the server since a password is now required. You must provide the keylist file password on the STRWBL command now that SSL transactions are being handled. To access this server from your browser, you need to use the protocol identifier https instead of http. For instance, to open a new URL from your browser enter https://www.yourhost.com/. 2.4.5 Testing the Server The following information can help test whether sessions are being served securely (encrypted and authenticated) by Webulator/400. Accessing a page secured with SSL From your browser, enter a URL for a SSL enabled session into the Open Document or Open URL entry box. For example, Page 47 Webulator/400R User Manual, Version 2.0 2.0 Usi https://www.your.host.com/SslSessionName The protocol to use is https for SSL enabled sessions. Substitute your host name for the www.your.host.com portion of the URL and your SSL enabled session name for SslSessionName. When accessing pages from a server running a certificate from an untrusted Certification Authority (such as test certificates), the browser will usually put up a dialog box indicating that the server's certificate could not be verified. Some browser's will let you continue after answering some questions. Netscape browsers, for instance, will normally display a series of dialog boxes explaining that the server's certificate could not be validated. These dialog boxes are not present if the server certificate is obtained from a Certification Authority that the browser trusts (such as VeriSign, Inc.). How do I know my pages are secured? All SSL-enabled browsers provide a visual clue that the current page is protected using SSL. The clue is usually a picture of a key or a lock near the bottom of the browser's window. Also, most browsers have a menu option that allows you to view information about the server's certificate. When frames are used, the visual clue that indicates the "page" is protected using SSL will only occur when all of the frames are retrieved using SSL. Browser Support Only browsers that are enabled with SSL 2.0 or 3.0 support can be used to do secured transactions with Webulator/400. Known, popular browsers that work with Webulator/400: . Netscape Navigator version 1.1N and later. . Microsoft Internet Explorer 2.0 and later. . OS/2 Secure Web Explorer 1.0 and later. 2.4.6 Test and Evaluation Server Certificates If you are not running with secure Webulator sessions yet and want to try out SSL without purchasing a validated certificate from VeriSign, or if you would like to start evaluating the software while you wait for your official server certificate, you can obtain a test and evaluation server certificate (https://digitalid.verisign.com/test_intro.html) from VeriSign. Page 48 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.5 URL Locations 2.5.1 Uniform Resource Locator A Uniform Resource Locator (URL) describes where to find something of interest stored somewhere on the Internet. A URL has enough information in it to uniquely describe any resource on any host anywhere in the world. The basic form of a World Wide Web URL is: protocol://server:port/URL-path?Query String where, protocol:// is the protocol being used. Common protocols used for Webulator/400 sessions are: . http: - used for non encrypted transactions . https: - used for encrypted transactions (SSL) server is the fully qualified domain name of the machine that contains the resource. port is the socket port on the host machine that is running the HTTP server. The :port is optional. If the port is not included, it defaults to port 80 for the http protocol and 443 for the https protocol. Please note that the Webulator/400 default http port number is 5061. URL-path is the fully qualified, hierarchical path to the resource. This can be based on the machine's file system hierarchy or an arbitrary (but unique) naming scheme. An empty URL-path is valid. Query String The Query String begins with the first unescaped question mark ("?") after the URL-path. This is generally used to pass parameters into scripts. 2.5.2 How Webulator/400 Finds a Session URL-paths are typically hierarchical with the structure indicated by names separated by slashes ("/"). This is very similar to the hierarchical nature of Webulator/400 sessions. In fact, for the most part Webulator/400 maps a URL-path's hierarchy directly to the configured session Page 49 Webulator/400R User Manual, Version 2.0 2.0 Usi entries. So when a browser requests a URL-path of /abc, the server looks for a session entry called /abc 2.5.2.1 Examples http://www.inetmi.com:5061/ Identifies the root Webulator/400 session on the host www.inetmi.com. The request is an HTTP request that is handled by the Webulator/400 server running on port 5061. https://www.inetmi.com:5062/session1 Identifies the Webulator/400 session named /session1 on the host www.inetmi.com. The request is an HTTPS request that is handled by the Webulator/400 server running on port 5062. Page 50 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.6 Aliases 2.6.1 Mapping a URL-Path to a Defined Session The main purpose of an alias is to re-route a browser's request from one location to another. The new location can be just a different session on the current server or it could be a complete URL to a different server. The command WRKWBLALS (section 3.1.10 on page 151) will show a list of aliases (section 4.2.15 on page 197) and the values that they are mapped. The server checks every URL- path to see if an alias substitution should occur. If the URL-path begins with an alias, the value the alias is mapped to will replace the aliased portion of the URL-path and appends the end portion of the URL-path to the new URL-path. The replaced portion can be the whole URL-path, or any beginning portion of a URL-path. Note that Webulator/400 supports begins with (Begins-with match on page 51) alias matching. This means that the only time an alias substitution occurs is when the beginning of a URL-path matches a configured alias. This comparison is case- insensitive. Webulator/400 assumes that all requests are Webulator/400 session requests. This means that you are not required to create any aliases in order to access a Webulator/400 session. You may choose to create aliases with a source type ([SrcType] on page 197) of *WEBULATOR if you wish to mask your implementation details from the user. 2.6.1.1 Alias Matching These are some important points regarding aliases that you should know prior to setting up aliases. Begins-with match A check is only made to see if a URL-path matches an alias from the very beginning of the URL-path. An alias that appears in the middle or at the end of a URL-path is ignored. Leading slash All aliases should begin with a slash since all URL-paths begin with a slash. If the alias did not have a leading slash, it would never be found in a URL-path because only begins-with matching is done with aliases. Maximal matching If two aliases that begin the same are defined, the server has to decide which alias substitution to use on a URL-path that begins the same as both aliases. The server Page 51 Webulator/400R User Manual, Version 2.0 2.0 Usi always uses the longest alias that still matches. For example, if an alias /abc maps to /uvw and alias /abcdef maps to /xyz and the URL-path /abcdef/screen1 is requested, the server has to decide if this should be converted to /uvwdef/screen1 or /xyz/screen1. Webulator/400 does a maximal match which means that the longest matching alias will always be picked. In this example, /xyz/screen1 would be used since it comes from the longest matching alias (/abcdef). 2.6.1.2 Webulator/400 Alias Examples For example, assume that you have set up Webulator/400 sessions with the following names: /region1/sales/orderentry Automatically signs on the user with userid SALESENTRY whose user profile automatically runs the application SALES/ENTRY. /region1/sales/orderstatus Automatically signs on the user with userid ORDSTATUS whose user profile automatically runs the application SALES/STATUS. The above Webulator/400 sessions are accessible by the complete Webulator/400 URL (www.xyz.com:5061/region1/sales/orderentry and www.xyz.com:5061/region1/sales/orderstatus) or you can create Webulator/400 aliases that will allow for more flexible access. Assume that you define the following aliases: /entry/ maps to /region1/sales/orderentry/ with a source type of *WEBULATOR /status/ maps to /region1/sales/orderstatus/ with a source type of *WEBULATOR Now, the same Webulator/400 sessions are accessible by using the newly defined aliases instead of the complete Webulator/400 URL (www.xyz.com:5061/entry and www.xyz.com:5061/status). The use or aliases allows for a shorter URL and hides the implementation details which means that you can restructure your Webulator/400 session names without breaking existing links to your site. Page 52 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.6.2 Increasing Alias Flexibility by Including Query String Options It is possible to specify options on the query string (section 2.8.3 on page 67) of the URL that initializes a Webulator/400 session to change the behavior of that interactive Webulator/400 session. These query string options can be simplified by their incorporation as part of an alias, eliminating the need for the user at the browser to enter the complex string options. When including the query string options in the alias value, the full URL-path must be specified. This includes the entire session path and query string. 2.6.2.1 Examples of Query Strings in the Alias Assume that you have set up the following Webulator/400 session: /region1/sales Performs user authentication which requires a valid AS/400 user id and password to be provided. This session will challange the user for a valid user id and password and run the initial program or menu defined for the user id. If query strings are configured (section 2.8.3 on page 67) for this session, you can change the behavior of this session by defining aliases with query strings. Assume the following aliases have been configured: /entry/ maps to /region1/sales?PGM=ENTRY=SALES with a source type of *WEBULATOR /status/ maps to /region1/sales?PGM=STATUS=SALES with a source type of *WEBULATOR With this setup, each of the following requests would be handled as described. A URL-path of /entry The server would accept this request, use the configuration values setup for the session /region1/sales and automatically start the program called ENTRY in the SALES library. A URL-path of /status The server would accept this request, use the configuration values setup for the session /region1/sales and automatically start the program called STATUS in the SALES library. Page 53 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.6.3 Using Aliases to Redirect URLs to Different Servers A Web server has the ability to tell a Web browser to look for a URL at a certain location on an entirely different Web server. This is referred to as Redirection. This might be useful if a Webulator/400 application is removed from one server, and relocated to another. HTML documents with links to the old application location will still work since the server will redirect them automatically to the new location. Also, people that have a bookmarked URLs will still be able to find applications that have moved. URL redirections can be permanent or temporary: Permanent The new URL will be in effect indefinitely and it is not planned to have the old URL be valid anymore. Temporary The redirection is only temporary. The old URL will be effective again or the redirection could change to something else at any time. When redirecting a URL-path the entire new URL must be specified. This includes the protocol, server, port, and URL-path. 2.6.3.1 Examples of Alias Redirection Assume that you are migrating from Webulator/400 version 1.x to version 2.0 and you want all of your version 1.x Webulator/400 URLs to be redirected to your new version 2.0 URLs. If you have the following sessions defined in your version 1.x configuration: /*meta/webulator/region1/sales/orderentry /*meta/webulator/region1/sales/orderstatus You should define the following session in your version 2.0 configuration: /region1/sales/orderentry /region1/sales/orderstatus In order for existing links to find the new sessions, you must change any *WEBULATOR aliases in your existing Web Server/400 or Commerce Server/400 configuration files to be a redirect. Assume that your existing configuration files had the following *WEBULATOR alias entry: Page 54 Webulator/400R User Manual, Version 2.0 2.0 Usi /WWW5250/ This entry should be changed to the following: /WWW5250/ maps to http://www.yourcompany.com:5061/ (permanently). With this setup, your existing Web Server/400 or Commerce Server/400 server would redirect all of your Webulator/400 requests to your Webulator/400 version 2.0 server running on port 5061. Page 55 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.7 NLS Architecture Webulator/400 implements National Language Support (NLS) with the services provided by OS/400, the AS/400 operating system. This means that Webulator/400 has some of the same NLS strengths and weaknesses as OS/400. This section is especially useful for non-U.S. installations. The World Wide Web and the Internet are becoming more internationally aware, but some inconveniences still exist for non-U.S. Web sites. This section provides assistance in configuring a successful Web site for all national languages. 2.7.1 NLS Definitions The following terms which are used to discuss National Language Support (NLS) may be unfamiliar to you: CCSID A number which identifies an encoding scheme (see ESID), and one or more code pages. This is all that is needed to correctly interpret text data. Character set A defined set of characters. No mapping between characters and values is assumed. Code page Specifies a mapping between values and characters for one or more character sets. Double-byte code page A code page in which each character is represented by two bytes. ESID Encoding scheme identifier. An encoding scheme specifies the way that text data is interpreted. It includes information such as whether the text is ASCII or EBCDIC. ISO character set The ISO mechanism for cataloging ways of interpreting text data. This has a correspondence to CCSID. Single-byte code page A code page in which each character is represented by one byte. Page 56 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.7.2 Reading Configuration Files When reading a configuration file, Webulator/400 needs to know what CCSID the file is in so that it can be converted correctly. In most cases, the file's associated codepage is used. Additionally, the CCSID for the session based configuration file (section 4.2.12 on page 194) can be explicitly entered. This is supported to make it easier to enter mixed byte data in the session based configuration file. The root file system does not allow the specification of mixed byte CCSIDs unless they are in QSYS. 2.7.3 Browser Encoding Most browsers that are used to interact with the server have a setting that is used to set the browser's encoding method. The server's content CCSID (section 4.2.68 on page 242) configuration value should be set to a CCSID that is compatible with the browser's encoding setting. When the server receives text data from the browser the server converts the text from the content (ASCII) CCSID to the server job's (EBCDIC) CCSID, and the reverse when returning text data. If the content CCSID does not properly match the browser's encoding setting then certain characters may appear to be corrupted. To support multiple types of encoding on the same AS/400, multiple servers would have to be configured. 2.7.4 Server CCSID The server job(s) CCSID is controlled by setting the CCSID for the server user profile (section 4.2.76 on page 250). Since V3R1 an AS/400 job will always have a "real" CCSID which is known as the default CCSID. The server converts data between the job's (default) CCSID and the configured content CCSID when processing browser requests. The default CCSID should be compatible with the content CCSID (section 4.2.68 on page 242) or data may appear corrupted. 2.7.5 Serving Webulator Screens By default, the server assumes the Webulator interactive session's CCSID and the virtual device's code page match the server job's CCSID. If this is not the case, the virtual terminal job CCSID (section 4.2.28 on page 208) and/or virtual terminal device CCSID (section 4.2.46 on page 225) configuration values may need to be set. If the CCSIDs/code pages do not match then data may appear corrupted. To serve double-byte screens, change the Terminal Size (section 4.2.19 on page 200) parameter to DBCS. No changes are needed for non-double-byte screens. Page 57 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.7.6 Conversion Methods OS/400 conversion routines are used to convert data. When converting data, Webulator/400 will keep trying different methods until one succeeds or all have been exhausted. Webulator/400 tries the following methods (in order): best fit, enforced subset, round-trip. The three methods differ in what their purpose is and how they handle mismatched characters (characters that do not convert correctly). Best fit conversion will attempt to find a close alternative for a mismatched character. For example, if converting the letter o with an umlaut above it (o) to a CCSID that does not contain this character, it might be converted to a o without an umlaut above it. Enforced subset conversion deals with mismatched characters by replacing them with a single substitution character. The substitution character depends on the encoding scheme of the destination CCSID. Round trip conversion is meant to allow conversion from one CCSID to a second, and then back to the first CCSID without a loss of information. This is the least useful for Webulator/400, because all conversions are one-way, and so is a last resort. If a conversion from a single-byte CCSID to a mixed byte CCSID fails, Webulator/400 will also attempt a conversion from the single-byte CCSID to the single-byte codepage of the mixed-byte CCSID. 2.7.7 CCSIDs and ISO character sets While OS/400 uses CCSIDs to identify the way text data is encoded, the World Wide Web uses ISO character sets to identify the way text data is encoded. Following is a table showing some of the useful ISO character sets and associated CCSIDs: ASCII ISO character set CCSID ----------------- ----- US-ASCII 367 ISO-8859-1 819 ISO-8859-2 912 ISO-8859-5 915 ISO-8859-7 813 ISO-8859-8 916 ISO-8859-9 920 ISO-2022-JP 5052 Page 58 Webulator/400R User Manual, Version 2.0 2.0 Usi Note that ISO-8859-1 (CCSID 819) is the default character set for HTTP and is the default value for the Content CCSID (section 4.2.68 on page 242). 2.7.8 Limitations URLs URLs (section 2.5 on page 49) must be single-byte except for the query string, which can be mixed-byte. This is a limitation of the HTTP specification. CCSIDs CCSIDs with an encoding scheme (ESID) of 4403 and 5404 are not currently supported. File names All file names must be single byte. This includes configuration file names and content file names. 2.7.9 Related Documentation The following IBM manuals contain information that may be useful to you: Character Data Representation Architecture Level 1 SC09-1390-00 Character Data Representation Architecture Level 2 SC09-1390-01 AS/400 International Application Development SC41-3603-00 AS/400 National Langauge Support Planning Guide Version 2 GC41-9877-02 Page 59 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8 Customizing Webulator/400 . Sign On Methods (section 2.8.1 on page 60) . Query String Options (section 2.8.3 on page 67) . HTML Tables or Preformatted Text (section 2.8.4 on page 69) . JavaScript Usability Enhancements (section 2.8.5 on page 70) . AS/400 Display Types (section 2.8.6 on page 71) . Screen Background (section 2.8.7 on page 73) . Screen Heading (section 2.8.8 on page 73) . Virtual Keyboard Buttons (section 2.8.9 on page 75) . Keyboard Plugin (section 2.8.11 on page 78) . Input Field Characteristics (section 2.8.12 on page 81) . Output Characteristics (section 2.8.13 on page 82) . Screen Text Colors (section 2.8.14 on page 83) . Graphical Menus (section 2.8.15 on page 84) . Converting Keywords to Buttons (section 2.8.16 on page 85) . Screen Footing (section 2.8.17 on page 86) . Termination Options (section 2.8.18 on page 87) . Embedding HTML in the 5250 Data Stream (section 2.8.19 on page 88) . Default Configuration Values (section 2.8.20 on page 89) . Sample Session Base Configuration Files (section 2.8.21 on page 95) . Reconfiguring Webulator/400 (section 2.8.22 on page 97) 2.8.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.2.81 on page 254) within the session based configuration (section 2.22 on page 130) using one of available methods. Each Webulator URL specified within the session 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 session based configuration file allows the WebMaster to configure a user profile name associated with a *WEBULATOR URL (section 2.6 on page 51). In addition to specifying the user profile name within the session 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.2.9 on page 271) file. Since the password in this file is the AS/400 Page 60 Webulator/400R User Manual, Version 2.0 2.0 Usi 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 Webulator/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.2.81 on page 254) configuration entry. Please refer to Query String Options (section 2.8.3 on page 67) for more information and ramifications of allowing signon values to be overridden using query string keywords. 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 secured Webulator/400 sessions, this should not be considered a secure encoding algorithm, however it is better than sending the password across the network in plain text. Webulator/400 contains a service program (WBLVAUTSRV) 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 Webulator/400 configuration (default value WBLUSER) *USE authority to the following programs: 1.QSYS/QSYGETPH 2.QSYS/QSYRLSPH 2. Change the owner of the WBLVAUTSRV service program to WBLUSER and remove authority adoption by using the following AS/400 commands: 1.CHGOBJOWN OBJ(WEBULATOR/WBLVAUTSRV) OBJTYPE(*SRVPGM) NEWOWN(WBLUSER) 2.CHGSRVPGM SRVPGM(WEBULATOR/WBLVAUTSRV) USRPRF(*USER) Page 61 Webulator/400R User Manual, Version 2.0 2.0 Usi 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.14 on page 114)). 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 4.2.81 on page 254) configuration entry. Please refer to Query String Options (section 2.8.3 on page 67) 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 secured Webulator/400 sessions, 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. Exit Program This method offers the most flexibility if you wish to deploy a custom access control scheme. Webulator/400 will call a user written program that must determine if the current request should be allowed and if so, provide a valid user id and password for the session. Please see Sign On Exit Program (section 2.8.2 on page 63) for more information. Access to each of the Webulator URLs can be protected using the access control (Access Control on page 174) directives within the Session Based Configuration File (section 2.22 on page 130). 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. Page 62 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.2 Sign On Exit Program 2.8.2.1 Exit Program Overview Setting a session's Sign On Method (section 4.2.81 on page 254) to ExitPgm will result in Webulator/400 call a user written exit program to determine how a session should be signed on. Webulator/400 uses the output of the user exit program and performs the sign on action on for the user. Currently, Webulator/400 only supports one data structure that can be passed to the exit program as its parameter list. QAPP0100 Parameter Structure Parameter Description In/Out Type 1 Query String Input Char(*) 2 Length Of Query String Input Binary(4) 3 Client IP Address Input Char(15) 4 CCSID Input Binary(4) 5 Allow Operation Output Char(1) 6 User Profile Output Char(10) 7 Password Output Char(10) 8 Current Library Output Char(10) 9 Program To Call Output Char(10) 10 Initial Menu Output Char(10) 11 Session Termination URL Output Char(300) Query String INPUT:CHAR(*) This is the user defined information that appears at the end of a Webulator/400 URL. For example, www.inetmi.com:5061/?QueryStringID=Value If no information is appended, then it is set to a NULL pointer. Length of Query String INPUT:BINARY(4) The length, in bytes, of any query string parameter content from the URL. The length is set to zero if no query string parameter is provided. Client IP address INPUT:CHAR(15) The Internet Protocol (IP) (dotted decimal) address of the client, which is extracted from the connected socket information. Please note that this may actually be a firewall address, router, or other identifier, and not the actual client IP address. CCSID INPUT:BINARY(4) Page 63 Webulator/400R User Manual, Version 2.0 2.0 Usi The CCSID of the data to use for conversions between EBCDIC and ASCII. Allow operation OUTPUT:BINARY(4) Indicates whether the Webulator/400 session should be accepted. The possible values are: 0 - Reject the request from the client browser. User profile, password, current library, program to call, and initial menu output parameters are ignored and an error is sent to the client. 1 - Accept the request from the client browser. The exit program supplies the user profile, password, current library, program to call and initial menu output parameters. User profile OUTPUT:CHAR(10) The user profile to be used for the sign-on procedure. This parameter is required. It must be left justified and padded with blanks. Password OUTPUT:CHAR(10) The password to be used for the sign-on procedure. This parameter is required. It must be left justified and padded with blanks. Current library OUTPUT:CHAR(10) The library in which the program to be called is located. This parameter is optional. It must be left justified and padded with blanks. If you do not supply a library, Webulator/400 uses the default of *USRPRF. Program to call OUTPUT:CHAR(10) The name of the program to be called. This parameter is optional. It must be left justified and padded with blanks. If you do not supply a program name, Webulator/400 uses the default of *USRPRF. Initial menu OUTPUT:CHAR(10) The name of the initial menu to display. This parameter is optional. It must be left justified and padded with blanks. Page 64 Webulator/400R User Manual, Version 2.0 2.0 Usi If you do not supply a menu name, Webulator/400 uses the default of *USRPRF. 2.8.2.2 Exit Program Example Signon Exit programs can be written in any programming language on the AS/400. Below you will find a simple example written in CL and C. Both samples show the basics of how to accept parameter structure and returns a valid userid and password to Webulator/400. The intent of these samples is to give you a basic skeleton that you can use for your own exit program. CL Exit Program Sample PGM PARM( + ) /*------------------------------------------*/ /* Accept QAPP0100 parameter structure */ /*------------------------------------------*/ DCL VAR() TYPE(*CHAR) LEN(300) DCL VAR() TYPE(*CHAR) LEN(4) DCL VAR() TYPE(*CHAR) DCL VAR() TYPE(*DEC) DCL VAR() TYPE(*CHAR) DCL VAR() TYPE(*CHAR) LEN(10) DCL VAR() TYPE(*CHAR) LEN(10) DCL VAR() TYPE(*CHAR) LEN(10) DCL VAR() TYPE(*CHAR) LEN(10) DCL VAR() TYPE(*CHAR) LEN(10) DCL VAR() TYPE(*CHAR) LEN(300) /* Change ALLOW to 1 to specify OK to signon */ CHGVAR VAR() VALUE('1') /* Hardcode a valid user ID */ CHGVAR VAR() VALUE('QUSER ') /* Hardcode a valid password */ CHGVAR VAR() VALUE('QUSER ') /* Do not change default lib, prog or menu */ CHGVAR VAR() VALUE(' ') CHGVAR VAR() VALUE(' ') CHGVAR VAR() VALUE(' ') /* Set term URL to value passed on qry string */ CHGVAR VAR() VALUE() RETURN ENDPGM C Exit Program Sample Page 65 Webulator/400R User Manual, Version 2.0 2.0 Usi #include #include #include /* Prototypes */ void CheckValues (char *,int,char *,int,char *,char *,char *,char *,char *,char *,char *); /*********************************************************** ***********/ /* Input: */ /* chat * argv[1] - Query string value */ /* int argv[2] - Length of query string */ /* char * argv[3] - IP address of the remote host system. */ /* int argv[4] - CCSID of the query string value */ /* Output: */ /* char * argv[5] - Allow operation '0'=No, '1'=Yes */ /* char * argv[6] - User profile to be used */ /* char * argv[7] - Password to be used */ /* char * argv[8] - Program library to be used */ /* char * argv[9] - Program name to be used */ /* char * argv[10] - Menu panel to be used */ /* char * argv[11] - Termination URL to be used */ /*********************************************************** ***********/ void main(int argc, char *argv[]) { exitpgm(argv[1], *((int *)(argv[2])), argv[3], *((int *)(argv[4])), argv[5], argv[6], argv[7], argv[8], argv[9], argv[10], argv[11]); return; } /* End main */ void CheckValues(char *QueryString, int QueryStringLength, char *IPaddr, Page 66 Webulator/400R User Manual, Version 2.0 2.0 Usi int CCSID, char Allow, char *UserID, char *Password, char *Library, char *Program, char *Menu, char *TerminationURL) { /* change here for your logic */ memcpy(UserID, "QUSER ", 10); memcpy(Password, "QUSER ", 10); memcpy(Library, " ", 10); memcpy(Program, " ", 10); memcpy(Menu, " ", 10); Allow = '1'; return; } 2.8.3 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.8.3.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:5061/, the syntax would be like this: www.xyz.com:5061/?KEYWORD1=VALUE&KEYWORD2=VALUE. Spaces are not allowed inside the query string, you must substitute a + for all embedding spaces. 2.8.3.2 Valid Keywords The following query string keywords are valid: . PGM - Allows you to specify a signon screen value for the initial program to run. . 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 Page 67 Webulator/400R User Manual, Version 2.0 2.0 Usi ensure that the first screen with an input field will properly handle the value being passed to it. . SESSION - Instructs the Session Manager (section 2.2 on page 37) as to which session should be used. If this value is not given, the Session Manager will create a new session only if there are no existing Webulator/400 sessions for that client. Acceptable values for this query string are NEW which instructs the Session Manager to always start a new session or Session Number which instructs the Session Manager to use a specific session. 2.8.3.3 Restrictions The Signon Method (section 4.2.81 on page 254) 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 when using the FIELD1 or SESSION keywords. 2.8.3.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. Page 68 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.3.5 Examples The following examples are assuming that your Webulator/400 URL is www.xyz.com:5061/. 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:5061/?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:5061/?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:5061/?FIELD1=CALL+MYLIB/MYPGM+PARM('PARM1'+'PARM 2'). 2.8.4 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.8.4.1 HTML Preformatted Text Webulator/400 will send Preformatted Text when the Tables Enabled (section 4.2.61 on page 236) 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. Page 69 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.4.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 (section 4.2.61 on page 236) 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.59 on page 235) 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.8.4.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.8.5 JavaScript Usability Enhancements 2.8.5.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 or later. Various other browsers either support it or will support it in the near Page 70 Webulator/400R User Manual, Version 2.0 2.0 Usi future. Browsers that do not support JavaScript should ignore the embedded JavaScript commands. 2.8.5.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.2.17 on page 199) 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.8.5.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 this feature. 2.8.6 AS/400 Display Types 2.8.6.1 Emulating Color and Monochrome Displays The Terminal Color (section 4.2.18 on page 200) 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 Page 71 Webulator/400R User Manual, Version 2.0 2.0 Usi properly view Webulator/400 screens. You can optionally define the text color by configuring the Monochrome Text Color (section 2.8.14 on page 83). Please note that if you 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.8.14 on page 83). 2.8.6.2 Controlling the AS/400 Terminal Size The Terminal Size (section 4.2.19 on page 200) 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.8.6.3 Virtual Terminal Device CCSID Data originating from an application is in the Virtual Terminal's Device CCSID. It then gets sent to the Webulator/400 which is running under the Server User Profile CCSID. If these two CCSIDS are not the same, some characters may get changed. The Virtual Terminal Device CCSID (section 4.2.46 on page 225) value instructs Webulator/400 to perform an extra translation step from the Device's CCSID to the Server User Profile CCSID before sending the screen to the browser. 2.8.6.4 Virtual Terminal Job CCSID Data received from the browser gets converted to the Server User Profile's CCSID. It must then be sent to the application in the interactive job's CCSID. If these two CCSIDS are not the same, some characters may get changed. The Virtual Terminal Job CCSID (section 4.2.28 on page 208) value instructs Webulator/400 to perform an extra translation step from the Server User Profile CCSID to the interactive job's CCSID before sending input data to the application. Page 72 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.7 Screen Background 2.8.7.1 Specifying a Background Color The Background Color (section 4.2.53 on page 231) 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.8.7.2 Specifying a Background Image The Background Image (section 4.2.54 on page 231) configuration element lets you specify an image file to be used as a background for Webulator/400 screens. The background image file must be accessable by a Web Server. At a minimum, you must qualified the file name by including a leading slash ("/") in the file name. Please note that a browser that supports extensions to HTML 2.0 is required to properly view a screen with a background image. 2.8.8 Choosing a Header 2.8.8.1 Standard Webulator/400 Header The standard Webulator/400 header contains the following HTML entries: (Text From First Output Field) 2.8.8.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.56 on page 233). 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. Page 73 Webulator/400R User Manual, Version 2.0 2.0 Usi 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 accessible by a Web Server. At a minimum, you must include 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.53 on page 231) 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. Webulator/400 Demo Home | WebMaster

Custom HTML Headers and JavaScript If Send JavaScript (section 4.2.17 on page 199) 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: Page 74 Webulator/400R User Manual, Version 2.0 2.0 Usi 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.8.9 Virtual Key Buttons 2.8.9.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 press F3. The keys that allow a user to exit an AS/400 screen are known as Attention Identifier (AID) generating keys. You must have all the Virtual Keyboard Buttons needed by your application defined in a Virtual Keyboard Row. 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. Since Webulator/400 screens are HTML forms being executed by a browser, the user must be given access to the defined Virtual Keys. This access can be given in one of two ways. The most common is through the Webulator/400 Keyboard Plugin. The Keyboard Plugin will take the list of defined Page 75 Webulator/400R User Manual, Version 2.0 2.0 Usi Virtual Keys and map them on the user's keyboard whenever the browser is showing a Webulator/400 screen. The other method is to not enable the Keyboard Plugin. In this case, Webulator/400 will simply create 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. 2.8.9.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.8.10 on page 77) - Allows the user to set a limited number of configuration values for their session only 2.8.9.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. 2.8.9.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 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. Page 76 Webulator/400R User Manual, Version 2.0 2.0 Usi 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.8.10 Session Configuration The Session Configuration Button (section 2.8.9 on page 75) 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. 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 Page 77 Webulator/400R User Manual, Version 2.0 2.0 Usi the original AS/400 screen. The initial setting for all sessions is to display blank lines. 2.8.11 Keyboard Plugin Webulator/400 provides a browser plugin file that allows the browser to map the keyboard similiar to a green screen. This option will allow the user to press AS/400 AID keys (e.g., Enter, F1 through F24) without having to use the mouse to press browser submit buttons. There are two versions of the plugin shipped with Webulator/400. The first, npwsky16.dll is for Microsoft Windows 3.1 and the second, npwsky32.dll is for Microsoft Windows 95/NT. Configuring Webulator/400 There are two Webulator/400 configuration values that impact the keyboard plugin. First, you must enable the keyboard plugin (section 4.2.29 on page 208) for the Webulator/400 session. By default, the plugin will take over the defined Virtual Keyboard Buttons (section 4.2.31 on page 210) and they will not be shown on the screen. You can optionally set the Keyboard Plugin Buttons (section 4.2.30 on page 209) value so that the plugin will share the Virtual Keyboard values and the buttons will also be shown on the screen. In addition, you will need to copy the plugin.wky file that is shipped in the /wbl/plugins directory to a location that is accessible from your native AS/400 Web Server. By default, Webulator/400 expects to find this file in the Server's document root directory. Optionally, you can change the location of the plugin.wky file (section 4.2.23 on page 204) to any directory accessible by the Web Server. Supported Browsers Because keyboard support is implemented as a Netscape plugin, it is platform specific and must be tested with each browser. The supported browsers are: . Windows 3.x . Netscape Navigator 3.0 . Microsoft Internet Explorer 3.0 . Windows 95/NT . Netscape Navigator 3.0 . Netscape Communicator 4.0 . Microsoft Internet Explorer 3.0 . Microsoft Internet Explorer 4.0 Page 78 Webulator/400R User Manual, Version 2.0 2.0 Usi Installing The Plugin Locating the Plugin Files The browser plugin files have a .dll extension and are shipped in the /wbl/plugins directory. You must use the Npwsky16.dll file on Windows 3.1 machines and the Npwsky32.dll file for Windows 95/NT machines. You may either copy these files directly from the shipped directory or you may wish to copy these files to a directory that is accessible to your AS/400 Web Server if you wish to distribute the plugin files using a browser. In addition, you may want to check the I/Net's Support site (http://www.inetmi.com/support/) for the latest available plugin files. Copy the Plugin file Place the appropriate DLL into your browser's plugins directory. The plugins directory exists below the directory where your browser program file (EXE) is. The exact directory depends on which browser you use and how you installed it. Some example directories are: . "c:\Program Files\Netscape\Navigator\Programs\plugins" . "c:\Program Files\Microsoft Internet\plugins" . "c:\netscape\plugins" Close Your Browser You must close your browser before the next step. The plugin will not be recognized until you close your browser and restart it. Make Sure the Browser Recognizes the Plugin Restart your browser and choose Help|About plugins from the menu. If you are using Netscape Navigator 3.0, you should see an entry that says I/NET Webulator/400 Keyboard plugin. If you are using another browser, you should see an entry that says application/x-webulator400- keys. If you do not see one of these entries, your browser does not recognize the plugin and you may have copied the DLL to the wrong directory. Using the Plugin For usability, it is recommended that you enable javascript for any webulator urls for which you plan to use the keyboard plugin. This will attempt to automatically set the keyboard focus to the correct input field, reducing your need to use the mouse. The following list is all the eligible AS/400 keys and their respective mappings: . Enter - Enter key Page 79 Webulator/400R User Manual, Version 2.0 2.0 Usi . F1 through F12 - F1 through F12 keys . F13 through F24 - Shift F1 through Shift F12 keys . Page Up - Page Up Key . Page Down - Page Down Key . Attention - Esc key . System Request - Shift Esc Key In addition, the following browser keys will be remapped when using the keyboard plugin. . Scroll browser contents down - Ctrl Page Down instead of Page Down . Scroll browser contents up - Ctrl Page Up instead of Page Up . New line inside multi-line text field - Ctrl Enter instead of Enter You will now see a combo box, a push button and the Webulator/400 keyboard icon when using the plugin. The combo-box contains the virtual keys (section 2.8.9 on page 75) you have defined for the current URL. You can still limit the keys available to a user or change descriptions through this mechanism. TroubleShooting There are several steps to configure and install this plugin and if any are not correct, it will not work. Fortunately, once you have the plugin correctly installed for a given browser, you should not need to worry about it in the future. The browser does not show the plugin in Help|About Make sure you COMPLETELY shut down the browser and restart it. If you leave even one browser window open, it will not recognize the plugin. Make sure you have the correct version of the DLL. If you are using a 16-bit browser, you must have the plugin for Windows 3.x. If you are using a 32-bit browser, you must have the plugin for Windows 95/NT. Check to see if your browser is on the list of supported browsers. Because this plugin is platform specific, it will not work with all browsers. Make sure you copied the DLL into the proper directory. The browser says "Plugin Not Loaded" The browser may not be able to find the plugin.wky file. Make sure it is in the document root and that it is available to the browser. You can check the access log to see if the server was able to successfully send it. Page 80 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.12 Input Field Characteristics 2.8.12.1 Input Fields that Extend Multiple Lines The Extended Input Field (section 4.2.25 on page 206) 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.25 on page 206) or Text Areas (section 4.2.25 on page 206). 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. 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. Page 81 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.12.2 Uppercase Input Fields The Upper to Lower Conversion (section 4.2.24 on page 205) configuration value allows you to automatically convert data inside a uppercase input field to lower case before being display to the user. You may want to use this option if you have uppercase input fields that do not show all of the characters without scrolling inside the input field. Some browsers do not allocate enough screen space to show all of the uppercase characters which results in fields that appear to be truncated. By converting these uppercase fields to lowercase, all of the characters should be viewable. 2.8.13 Output Characteristics 2.8.13.1 Blank Lines The Include Blank Lines (section 4.2.58 on page 234) configuration value allows you to specify whether Webulator/400 should include AS/400 blank lines in the HTML form. This value can be changed by the user for a particular session by selecting the Session Settings AS/400 Virtual Keyboard button. 2.8.13.2 Font Size The Font Size (section 4.2.41 on page 221) 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.8.13.3 HTML Tables The Tables Enabled (section 4.2.57 on page 234) 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.8.4 on page 69) section for more information. 2.8.13.4 Horizontal Rules The Horizontal Rules (section 4.2.57 on page 234) configuration value allows you to specify whether Webulator/400 should include HTML horizontal rules to provide screen separation. The following values can be specified: Page 82 Webulator/400R User Manual, Version 2.0 2.0 Usi . BOTH - Horizontal rules will be included after the top row(s) and before the bottom row(s) of AS/400 Virtual Keyboard buttons. . 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.8.13.5 Reverse Image Space Replacement Character The Reverse Image Space Replacement Character (section 4.2.45 on page 224) 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.8.13.6 Subfile Hot Spots The Subfile Hot Spots (section 4.2.43 on page 223) value instructs Webulator/400 to search for subfile specific output fields (+, -, more..., bottom). If any of these subfile fields are found, then Webulator/400 will place clickable images next to the keyword. This feature is valuable if your application has one or more subfiles on the screen that do not have any input capable fields in them. In addition, Webulator/400 can search for output fields on the last line of the screen. If an output field appears, it will place clickable images at the end of the line to allow for Page Up, Page Down and Help. This feature is used when your applicaton uses the bottom line of the display for status information that requires the user to move the cursor over to get help or to see addition messages. 2.8.14 Screen Text Colors 2.8.14.1 How Colors Are Used The Terminal Color (section 4.2.18 on page 200) 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. Page 83 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.14.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 (CHGWBLSSN) command with the name of your current 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. 2.8.14.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 (CHGWBLSSN) command with the name of your current 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.8.15 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 Page 84 Webulator/400R User Manual, Version 2.0 2.0 Usi 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.42 on page 222): . 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. 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.8.16 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.8.16.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.44 on page 223) 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. Page 85 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.16.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 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. . 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.8.17 Choosing a Footer 2.8.17.1 Standard Webulator/400 Footer The standard Webulator/400 footer contains the and entries. 2.8.17.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.55 on page 232). 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: Page 86 Webulator/400R User Manual, Version 2.0 2.0 Usi (Optional BODY elements) All embedded file references must be accessible by a Web Server. At a minimum, you must include 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.

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.8.18 Termination Options 2.8.18.1 Closing Confirmation Webulator/400 allows you to determine if the user should be presented with a Confirmation Screen (section 4.2.87 on page 260) 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.8.18.2 Input Inhibited Timeout Webulator/400 allows you to specify a Input Inhibited Timeout (section 4.2.86 on page 259) that controls how long Webulator/400 will wait for a screen to return from the AS/400 before timing out and ending the session. 2.8.18.3 Signoff action Webulator/400 allows you to specify a Signoff Action (section 4.2.84 on page 258) that indicates the action that should take place when a user signs off of the AS/400. You Page 87 Webulator/400R User Manual, Version 2.0 2.0 Usi can choose to allow a secondary signon screen to be displayed or Webulator/400 can automatically terminate the session which will prevent the user from being able to guess other valid user ids and passwords. 2.8.18.4 Termination URL Webulator/400 allows you to specify a Termination URL (section 4.2.88 on page 260) 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.8.19 Embedding HTML in the 5250 Data Stream 2.8.19.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 < 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 Page 88 Webulator/400R User Manual, Version 2.0 2.0 Usi 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.8.19.2 V3R2 and beyond 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. . AS/400 DDS Reference - SC41-3712-01 . AS/400 Application Display Programming - SC41-3715-01 2.8.20 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 session entry or one of its parent session entries. Background Color The default Background Color (section 4.2.53 on page 231) is "Blank". This means that there will be no background color used. This value can be changed by setting the BACKCOLOR parameter through option 2 of the WRKWBLSSN command. Background Image The default Background Image (section 4.2.54 on page 231) is "Blank". This means that there will be no background image Page 89 Webulator/400R User Manual, Version 2.0 2.0 Usi used. This value can be changed by setting the BACKIMAGE parameter through option 2 of the WRKWBLSSN command. Buttons with keyboard plugin The default Buttons with Keyboard Plugin (section 4.2.30 on page 209) value is No. This means that the defined virtual keyboards buttons will not be shown when using the keyboard plugin. This value can be changed by setting the KBDPLUGBTN parameter through option 2 of the WRKWBLSSN command. Color Conversion The default Color Conversion (section 4.2.40 on page 220) 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 2 of the WRKWBLSSN command. Extended Input Fields The default Extended Input Fields (section 4.2.25 on page 206) is Scrollable . This value can be changed by setting the EXTFIELDS parameter through option 2 of the WRKWBLSSN command. Field Level Prompting The default Field Level Prompting (section 4.2.26 on page 206) is ?. This value can be changed by setting the FLDPROMPT parameter through option 2 of the WRKWBLSSN command. Font Size The default Font Size (section 4.2.41 on page 221)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 2 of the WRKWBLSSN command. Footer File The default Footer File (section 4.2.55 on page 232) is "Blank". This means that the standard Webulator/400 footer will be used. This value can be changed by setting the Page 90 Webulator/400R User Manual, Version 2.0 2.0 Usi FOOTFILE parameter through option 2 of the WRKWBLSSN command. Header File The default Header File (section 4.2.56 on page 233) 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 2 of the WRKWBLSSN command. Horizontal Rules The default Horizontal Rules (section 4.2.57 on page 234) is None. This means that there will be no horizontal rules drawn between 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 2 of the WRKWBLSSN command. Input Inhibited Timeout The default Input Inhibited Timeout (section 4.2.86 on page 259) is 5 minutes. This value can be changed by setting the INPINHTIME parameter through option 2 of the WRKWBLSSN command. Keyboard Plugin The default Enable Keyboard Plugin (section 4.2.29 on page 208) value is Yes. This means that the keyboard plugin will be used to map the user's keyboard similar to the AS/400's keyboard so that Enter and all function keys can work properly. This value can be changed by setting the KBDPLUGIN parameter through option 2 of the WRKWBLSSN command. Light Pen Image The default Light Pen Image (section 4.2.27 on page 207) 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 2 of the WRKWBLSSN command. Menu Type The default Menu Type (section 4.2.42 on page 222) is None. This value can be changed by setting the MENUTYPE parameter through option 2 of the WRKWBLSSN command. Parsed Buttons The default Parsed Buttons (section 4.2.44 on page 223) is"Blank". This means that there will be no keywords parsed in the screen text and converted to browser submit buttons. Page 91 Webulator/400R User Manual, Version 2.0 2.0 Usi This value can be changed through option 8 of the WRKWBLSSN command. Reverse Image Space Replacement Character The default Reverse Image Space Replacement Character (section 4.2.45 on page 224) is '*'. This means that all spaces that have an attribute of reverse image will be shown as an *. This value can be changed by setting the RICHAR parameter through option 2 of the WRKWBLSSN command. Send JavaScript The default Send JavaScript (section 4.2.17 on page 199) value is *YES. This means that the session will take advantage of functionality written in JavaScript to make the session better emulate a 5250 session. This value can be changed by setting the SNDJAVASCR parameter through option 2 of the WRKWBLSSN command. Please see the JavaScript Usability Enhancements (section 2.8.5 on page 70) for more information concerning the use of JavaScript. Show Blank Lines The default Show Blank Lines (section 4.2.58 on page 234) 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 2 of the WRKWBLSSN command. Signon Method The default Signon Method (section 4.2.81 on page 254) is Disabled. This is the only configuration entry that must be overridden in a session 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.8.1 on page 60). This value can be changed by setting the SIGNON parameter through option 2 of the WRKWBLSSN command. Signoff Action The default Signoff Action (section 4.2.84 on page 258) is SignonScreen. This means that the user will be shown a signon screen whenever they sign off the system. This value can be changed by setting the TERMSIGNOF parameter through option 2 of the WRKWBLSSN command. Subfile scrolling support The default Subfile scrolling support (section 4.2.43 on page 223) value is None. This means that you will not see any clickable image buttons whenever an output field is Page 92 Webulator/400R User Manual, Version 2.0 2.0 Usi found on line 24 or a subfile has been indentified on the screen. This value can be changed by setting the SFLSCROLL parameter through option 2 of the WRKWBLSSN command. Tables Enabled The default Tables Enabled (section 4.2.61 on page 236) value is Disabled. This value can be changed by setting the TABENABLE parameter through option 2 of the WRKWBLSSN command. Please see the Preformatted Text or HTML Tables (section 2.8.4 on page 69) for more information concerning the use of HTML tables. Table Font Name The default Table Font Name (section 4.2.59 on page 235) value is "Courier". This value can be changed by setting the TABFONT parameter through option 2 of the WRKWBLSSN command. This value will be ignored if the Tables Enabled (section 4.2.61 on page 236) value is Disabled. Please see the Preformatted Text or HTML Tables (section 2.8.4 on page 69) for more information concerning the use of HTML tables. Table Width The default Table Width (section 4.2.60 on page 236) value is "Blank". This value can be changed by setting the TABWIDTH parameter through option 2 of the WRKWBLSSN command. This value will be ignored if the Tables Enabled (section 4.2.61 on page 236) value is Disabled. Please see the Preformatted Text or HTML Tables (section 2.8.4 on page 69) for more information concerning the use of HTML tables. Terminal Color The default Terminal Color (section 4.2.18 on page 200) is Color. This value can be changed by setting the TERMCOLOR parameter through option 2 of the WRKWBLSSN command. Terminal Size The default Terminal Size (section 4.2.19 on page 200) is Small. This value can be changed by setting the TERMCOLOR parameter through option 2 of the WRKWBLSSN command. Terminal Timeout The default Terminal Timeout (section 4.2.85 on page 258) is 5 minutes. This value can be changed by setting the TERMTIME parameter through option 2 of the WRKWBLSSN command. Page 93 Webulator/400R User Manual, Version 2.0 2.0 Usi Termination Confirmation The default Termination Confirmation (section 4.2.87 on page 260) is Yes. This value can be changed by setting the CONFIRM parameter through option 2 of the WRKWBLSSN command. Termination URL The default Termination URL (section 4.2.88 on page 260) is / Return to server home page. This value can be changed by setting the TERMURL parameter through option 2 of the WRKWBLSSN command. Upper to lower conversion The default Upper to lower conversion (section 4.2.24 on page 205) is No. This means that all data will be shown as it was sent from the AS/400 application. This value can be changed by setting the UPTOLOWERC parameter through option 2 of the WRKWBLSSN command. Virtual Terminal Device CCSID The default Virtual Terminal Device CCSID (section 4.2.46 on page 225) value is NoConvert. This means that CCSID associated with the device is the same CCSID as the one associate with the server user profile. This value can be changed by setting the VTDEVCCSID parameter through option 2 of the WRKWBLSSN command. Virtual Terminal Job CCSID The default Virtual Terminal Job CCSID (section 4.2.28 on page 208) value is NoConvert. This means that CCSID associated with the interactive job is the same CCSID as the one associate with the server user profile. This value can be changed by setting the VTJOBCCSID parameter through option 2 of the WRKWBLSSN command. Virtual Keyboard Buttons There will be four AS/400 Virtual Keyboard Rows (section 4.2.31 on page 210) defined. There will be one at the top of the screen and three at the bottom of the screen. These values can be changed through option 9 of the WRKWBLSSN command. The first row at the top of the screen will have the following buttons. . Enter . Reset . Close Page 94 Webulator/400R User Manual, Version 2.0 2.0 Usi The first row at the bottom of the screen will have the following buttons. . Function Keys F1 Through F12 The second row at the bottom of the screen will have the following buttons . Function Keys F13 Through F24 The last row at the bottom of the screen will have the following buttons. . Help . RollDown . Rollup The following AS/400 Virtual Keyboard Buttons are not used in the default configuration : . SystemRequest . Attention . SessionConfiguration 2.8.20.2 Related AS/400 Commands . Work with Session Configuration (WRKWBLSSN) command (section 3.1.23 on page 158) . Change Webulator/400 Configuration (CHGWBLSSN) command (section 3.1.24 on page 160) . Work with Webulator/400 Parsed Buttons (WRKWBLPRS) command (section 3.1.19 on page 156) . Work with Webulator/400 Virtual Keyboard Rows (WRKWBLROW) command (section 3.1.25 on page 162) 2.8.21 Sample Session Configuration File Webulator/400 sessions will look in the following places for configuration entries: . The current session entry . Parent session entries . Webulator/400 Default Configuration Values (section 2.8.20 on page 89) The sample session configuration file shipped with Webulator/400 should help you get your first Webulator/400 session running quickly. It defines the top most (root) Webulator/400 session and mostly uses the Webulator/400 default configuration values. It changes the signon method to SCREEN and defines the keywords F1 through F24, Enter and ENTER which will be converted into virtual keyboard buttons. Page 95 Webulator/400R User Manual, Version 2.0 2.0 Usi You can use this configuration file by setting the ACCGBLFILE parameter of the CHGWBLSVR command to Cfg/Access.cfg. You can view or change the configuration settings by running the WRKWBLSSN command and selecting option 2 for the / directory or directly using the CHGWBLSSN command. You can view or change the parsing strings by running the WRKWBLSSN command and selecting option 8 for the / directory or directly using the WRKWBLPRS command. The root directory has the following parsing strings defined: . F1 through F24 . Enter and ENTER If you prefer, the file Wbl/Cfg/Access.cfg can be edited directly with a stream file editor. The following lines are equivalent to the configuration described above ParsedButton DESCRIPTION F1 F1 ParsedButton DESCRIPTION F2 F2 ParsedButton DESCRIPTION F3 F3 ParsedButton DESCRIPTION F4 F4 ParsedButton DESCRIPTION F5 F5 ParsedButton DESCRIPTION F6 F6 ParsedButton DESCRIPTION F7 F7 ParsedButton DESCRIPTION F8 F8 ParsedButton DESCRIPTION F9 F9 ParsedButton DESCRIPTION F10 F10 ParsedButton DESCRIPTION F11 F11 ParsedButton DESCRIPTION F12 F12 ParsedButton DESCRIPTION F13 F13 ParsedButton DESCRIPTION F14 F14 ParsedButton DESCRIPTION F15 F15 ParsedButton DESCRIPTION F16 F16 ParsedButton DESCRIPTION F17 F17 ParsedButton DESCRIPTION F18 F18 ParsedButton DESCRIPTION F19 F19 ParsedButton DESCRIPTION F20 F20 ParsedButton DESCRIPTION F21 F21 ParsedButton DESCRIPTION F22 F22 ParsedButton DESCRIPTION F23 F23 ParsedButton DESCRIPTION F24 F24 ParsedButton DESCRIPTION Enter Enter ParsedButton DESCRIPTION Enter ENTER Page 96 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.8.22 Reconfiguring Webulator/400 You may reconfigure Webulator/400 to use the latest configuration values at any time Webulator/400 is active by running the Set WBL Configuration Values (SETWBLCFG) (section 3.1.7 on page 148) command or by setting the Update executing RPs (UPDATE) parameter on any of the configuration commands to *IMMED. It is important to note that when you reconfigure the Webulator/400 settings, the new settings will take effect for all future sessions and will not change any currently active Webulator/400 sessions. This is done as a way to prevent the Webulator/400's appearance and functionality from changing from one screen to another. Page 97 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.9 Protecting Your AS/400 Note that this document only describes protecting your AS/400 information in regards to Webulator/400. Other software such as Telnet and FTP pose additional concerns which are not addressed here. 2.9.1 OS/400 Authority This is familiar to AS/400 system administrators and is very strong (it can be configured to meet the requirements for C2 security, as defined by the United States Department of Defense). For OS/400 authority to be effective, your system's security level (system value QSECURITY) should be set to at least 30. Webulator/400 has been developed and tested at security level 40. The server jobs (daemon and request processors) run under the configured server user profile (section 4.2.76 on page 250). The server user profile should have the following authorities: . *USE to the WEBULATOR/WBLDAEMON program and to the QSYS/QSYSNOMAX job queue. . The server user profile must be registered in the system directory in order to access Document Library Services (DLS) folders and documents. 2.9.2 Webulator/400 Access Control While OS/400 authority is very strong, it is inflexible because it is based on the user profile of the person starting the server and on the server user profile. The server user profile either has access to an object or not. Access control takes into account information about the person requesting the information, such as the workstation they are using and the user name and password they enter. You can find more information about access control in the tutorial (section 2.9.5 on page 101), an access control example (section 2.9.6 on page 105) and a detailed description of how limit sections are evaluated (section 2.9.7 on page 106). 2.9.2.1 Ways Of Controlling Access Webulator/400 allows access to be restricted in two ways, which may be used separately or combined. For greatest security, both should be used together. Page 98 Webulator/400R User Manual, Version 2.0 2.0 Usi Host filtering Allows restriction of access to information based on the IP address or domain name of the machine (host) requesting the information. User authentication Allows restriction of access to information based on a user ID and password the user enters. Evaluating Webulator/400 access involves a two step process: 1.Host filtering will be checked first. If host filtering is not configured or allows access, the server goes on to the next step. If host filtering does not allow access, the server will forbid access. 2.User authentication is checked. If user authentication is not configured or allows access, then access is granted. If user authentication does not allow access, the server will forbid access. 2.9.3 Further Information About Protecting Your AS/400 The following topics are related to protecting your AS/400: . Server user profile (section 4.2.76 on page 250) . Access log (section 2.19 on page 122) (for auditing accesses and attempted accesses) . Domain name lookup (section 4.2.70 on page 243) (affects host filtering) . Authentication User Storage (section 2.9.4 on page 100) . Access control configuration files . Session based configuration file path (section 4.2.12 on page 194) . Session based configuration file (section 5.2.5 on page 268) . User access file (section 5.2.6 on page 269) . Group access file (section 5.2.8 on page 270) . Configuration values used in access control configuration files . Session section start (section 4.2.11 on page 193) . Authentication group file (section 4.2.3 on page 185) . Authentication realm name (section 4.2.4 on page 186) . Authentication type (section 4.2.6 on page 188) . Authentication user file (section 4.2.8 on page 189) . Session section end (section 4.2.10 on page 192) . Order (section 4.2.13 on page 195) . Allow hosts (section 4.2.1 on page 182) . Deny hosts (section 4.2.9 on page 190) . require user authentication (section 4.2.14 on page 196) Page 99 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.9.4 Authentication User Storage You have two choices to make when you are setting up authentication: what kind of file to store users in and the user password storage mode. 2.9.4.1 What Kind of File to Store Users In You can choose to store users in database files or stream files. This choice can be made separately for each user file (e.g. you can have one user stream file and one user database file for the same server). . Stream File This file type is compatible with NCSA servers and is ideal for holding a small number of users that does not change very often. Because it is read into the memory of each request processor during server startup and reconfiguration, it is not good for files containing a large number of users. . Database File This file type is ideal for large numbers of users and for cases where the list of users changes often. This file type is not read into memory by each request processor, conserving system memory. There is a small additional performance penalty to pay for each request that is authenticated with this type of file because the server needs to access the database file for each request. Remember that if performance is a concern, you can protect one area (or set of areas) with a stream file while protecting another area (or areas) with a database file. You choose the type of file to store users in with the Authentication User File (section 4.2.8 on page 189) configuration value. To migrate stream files into database files, you can use the MIGWBLUSR (section 3.1.18 on page 155) command. 2.9.4.2 User Password Storage Mode It is possible to use authentication user files that were originally created for use with Web Server/400 or Commerce Server/400. The way that user passwords are stored changed starting with Web Server/400 version 1.3. Webulator/400 can be configured to use either the new mode or the old mode (for backward compatibility). The new mode is called Normalized while the old mode is called Compatible. . Normalized Password Storage In this mode, the server converts all passwords to upper case and to a common CCSID before hashing them Page 100 Webulator/400R User Manual, Version 2.0 2.0 Usi with the RSA Data Security, Inc. MD5 Message-Digest Algorithm. The conversion to upper case allows the server to match passwords in a case-insensitive way, which is in line with general AS/400 operation. The conversion to a common CCSID allows users with different CCSIDs to manage the same user file. . Compatible Password Storage In this mode, the server does no conversion before hashing passwords. This is the method used in Web Server/400 versions prior to 1.3. If you are using authentication user files originally created for Web Server/400 and have any passwords that were created in this mode, you must either continue to use this mode, or change to the new mode and re-enter the old passwords. This mode is set through the Authentication Password Storage (section 4.2.5 on page 187) configuration value. When a new server is installed, the configuration files that are installed with it will specify Normalized mode. 2.9.5 Access Control Tutorial 2.9.5.1 General Information Access control works with the Session based configuration file (section 5.2.5 on page 268) Note that the access control-related files, like all configuration files, are read by the server at start-up (section 3.1.2 on page 136) and when the server is re- configured (section 3.1.7 on page 148). If you are experimenting with access control and the changes do not seem to be taking effect, re-configure the server (using the SETWBLCFG command). 2.9.5.2 How Secure Is It? Webulator/400 supports host filtering and Basic HTTP authentication for controlling access to configured sessions. Each kind of access control makes it difficult, but not impossible for unauthorized users to access protected sessions. Host filtering lets you allow or disallow access based on the client's domain or IP address. Basic authentication lets you require a user ID and password combination. In Basic authentication, the user ID and password is not sent over the network as plain text, but it is not encrypted either. It is uuencoded, in essentially the same way as Telnet login IDs and passwords. Basic authentication is Page 101 Webulator/400R User Manual, Version 2.0 2.0 Usi similar to Telnet security and is approximately as secure as Telnet. For maximum security, you will want to combine host filtering and user authentication. This would force a potential intruder to both "spoof" an IP address and to "sniff" the network to find a valid user ID and password. 2.9.5.3 User Authentication Example In this example, you will protect the "/Demo/Fun" session, only allowing access by user "DrKatz" using the password "ProfessionalTherapist". This assumes that the server is using the default value for the server root (section 4.2.20 on page 201). . Create or modify the session based configuration file. 1. Ensure the file exists The server is shipped with the stream file "/Wbl/Cfg/Access.Cfg". If that file is missing, create it. You can create a new file by copying one we ship for this purpose: /Wbl/Shipped/Cfg/Empty.Cfg. You can copy this file using either the WRKLNK command or the CPY command. 2. Ensure your master configuration file refers to your access control file. Enter the following command and press the F4 key: CHGWBLSVR (section 3.1.6 on page 147) The example above assumes that you are using the master configuration file that was shipped with the server. If you are not, specify the name to of the master configuration file you are using. Change the value of the Session based configuration file path parameter to the access control file you just created: /Wbl/Cfg/Access.Cfg and press the enter key. 3. Create the /Demo/Fun Session Entry Use the WRKWBLSSN (section 3.1.23 on page 158) command to create a /Demo/Fun session. This is the session we are going to set protection for. 4. Set the session values Enter the following command and press the F4 key: Page 102 Webulator/400R User Manual, Version 2.0 2.0 Usi CHGWBLSSN (section 3.1.24 on page 160) CFGFILE('/Wbl/Cfg/WebServ.cfg') DIRECTORY('/Demo/Fun') Change the value of Authentication realm to 'Fun'. This can actually be anything you want. It is passed to the browser and the browser (usually) displays it to the user so the user knows what they are trying to access and therefore what user name and password they should enter. Change the value of Authentication type to *BASIC. Webulator/400 currently only supports Basic authentication. Change the value of User file path to '/Wbl/Cfg/FunUser.cfg'. This tells the server what user file to use when evaluating access to the current session. You will add to the user file in a later step. Change the value of Signon method to *SCREEN. This tells Webulator/400 to issue a signon display for the beginning of this session. 5. Create an entry to require the user DrKatz. Use option 6 within the WRKWBLSSN (section 3.1.23 on page 158) command to add the REQUIRE entry. When done, the file should contain a section which looks like the one below: AuthUserFile /Wbl/Cfg/FunUser.cfg AuthName Fun AuthType Basic require user DrKatz . Add (section 3.1.15 on page 154) the "DrKatz" user to your authentication user file. Enter the following command and press the F4 key: ADDWBLAUT As in the prior step, if you are using a different master configuration file than the default, you will need to enter it in the command above. The User file path parameter should come up as '/Wbl/Cfg/FunUser.cfg'. If it does not, change it. Page 103 Webulator/400R User Manual, Version 2.0 2.0 Usi Enter the user name DrKatz and the password ProfessionalTherapist. Set the Update executing RPs parameter to *IMMED. This will update your server if it is currently running. If the server is not running yet, start (section 3.1.2 on page 136) it. . Test your changes To test your changes, enter [host]/Demo/Fun/ in your browser to attempt to show a sign on display for the /Demo/Fun session. The browser should ask you to enter authentication information. You will not be allowed to see the Webulator session with a sign on display unless you enter DrKatz for a user name and ProfessionalTherapist for a password. 2.9.5.4 Host Filtering Example In this example, you will protect the same /Demo/Fun session, but this time, you will set it up so that only people from the .EDU domain can access it. . Create or modify the session based configuration file. Follow the instructions from the previous example about how to create or modify the file, but add the following section instead. deny from all allow from .edu The deny entry denies all hosts access. Both the deny and allow entries can accept the same parameters. In addition to the examples, you can use IP addresses or more complete domain names. . Ensure your master configuration file refers to your access control file. See the previous example for instructions about this. Also see Protecting your AS/400 information (section 2.9 on page 98) Page 104 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.9.6 Access Control Example The example below assumes the session based configuration file contains the following entries. Note that the indentation shown below is purely for readability. The server will work the same way regardless of any indentation. AuthType Basic AuthName Example AuthUserFile /wbl/cfg/user.cfg AuthGroupFile /wbl/cfg/group.cfg allow from all deny from .edu allow from .ncsa.edu deny from .inetmi.com order mutual-failure allow from .inetmi.com .net deny from xyz.inetmi.com allow from hoohoo.ncsa.edu deny from .ncsa.edu require group Development user FictionalUser1 2.9.6.1 Session Root Example This entry allows any host except those ending in .edu to access the Webulator/400 session associated with the root (/) or any session below it. The session entries for /abc, /abc/def, /123 and /UserAuth contain overriding access controls, but all other subsessions on the host will use this entry. Note that the allow entry is redundant because all hosts are allowed by default. 2.9.6.2 Session /abc Example These access control directives still disallow hosts that end in .edu unless they end in .ncsa.edu, in which case they are allowed. It also disallows hosts that end in .inetmi.com. Except for the session /abc/def (which contains overriding access control directives), this limit will apply to all subsessions. Page 105 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.9.6.3 Session /123 Example Because the order in this limit section is mutual-failure, any previous allows and denies are ignored. In this session (and all subsessions), every host that ends in .inetmi.com or .net will be allowed except for the host xyz.inetmi.com. 2.9.6.4 Session /abc/def Example Note that even though this entry is not listed directly below the /abc entry, the server will evaluate it after the /abc session section for this session or any below. The order of session sections within the file is unimportant. They will always be evaluated from the root down to the session being evaluated. After this section is processed, any host that ends in .ncsa.edu will not be allowed unless it is hoohoo.ncsa.edu. Any host that ends in .inetmi.com will also not be allowed (because of the access control directives in the parent session section). All other hosts will be allowed. 2.9.6.5 Session UserAuth First, host filtering will be applied to allow any host except those ending in .edu. Then user authorization will be applied to only allow User name/password combinations for the group Development or the user FictionalUser1. Also see Protecting your AS/400 information (section 2.9 on page 98) 2.9.7 How Allow, Deny and Require Statements Are Evaluated Statements that control access to Webulator/400 sessions can appear within the session based configuration file (section 5.2.5 on page 268). If the server is evaluating access to a session for which no specific access control directives are specified and no parent session has access control specified, access will be granted. Otherwise, host filtering will be checked first. If access is allowed after host filtering (this includes the case where host filtering is not being used), user authentication will be checked. 2.9.7.1 Evaluating Host Filtering When the server is evaluating whether to give access to a Webulator/400 session, it will work its way down the session tree from the root, evaluating host filtering rules from the Page 106 Webulator/400R User Manual, Version 2.0 2.0 Usi highest session (closest to the root) to the lowest (closest to the session being evaluated). For host filtering, the access directives are order (section 4.2.13 on page 195), allow (section 4.2.1 on page 182) and deny (section 4.2.9 on page 190). The order directive specifies the order in which the allow and deny directives are evaluated. The allow directive is used to add hosts which have access to a session. The deny directive removes hosts which have access to a session. For the order values allow,deny and deny,allow, each set of directives may turn access on, turn it off or do nothing. Access will be turned on if the client's host matches an allow entry. It will be turned off if the host matches a deny entry. If neither the deny or allow entry matches the client's host, access will not be changed for that session. If both match the client's host, access will be set by the last entry evaluated (this depends on the order entry). If order is set to mutual-failure, access will only be allowed if the client's host matches an allow entry and does not match a deny entry. Note that the effect of this is to ignore any previously evaluated directives from higher sessions. 2.9.7.2 Evaluating User Authentication To evaluate user authentication, the server will find the directives in the session nearest to the session being evaluated (farthest from the root) that contains a require (section 4.2.14 on page 196) directive. If no such directive is found, access will be granted. When evaluating the require entry(ies), the current authentication type (section 4.2.6 on page 188), authentication user file (section 4.2.8 on page 189) and (possibly) authentication group file (section 4.2.3 on page 185) are used. If user authentication fails, the realm specified by the current authentication realm name (section 4.2.4 on page 186) is sent back to the browser to be displayed to the user when the browser prompts for a user name and password. Also see Protecting your AS/400 information (section 2.9 on page 98) Page 107 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.10 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 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.8.1 on page 60) . User Profile Considerations (section 2.11 on page 110) . AS/400 Virtual Terminal Considerations (section 2.12 on page 112) . AS/400 Programming Considerations (section 2.13 on page 113) Page 108 Webulator/400R User Manual, Version 2.0 2.0 Usi . AS/400 System Values (section 2.14 on page 114) . AS/400 System Auditing (section 2.15 on page 116) . Other Security Tips (section 2.16 on page 117) The IBM OS/400 Security - Reference publication (document number SC41-3302-00) is an excellent source for AS/400 security information. Page 109 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.11 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.8.9 on page 75). 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. 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. Page 110 Webulator/400R User Manual, Version 2.0 2.0 Usi 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. Page 111 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.12 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). 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. Page 112 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.13 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 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. Page 113 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.14 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 114 Webulator/400R User Manual, Version 2.0 2.0 Usi Additional information about AS/400 system values can be found in the AS/400 Work Management manual. Page 115 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.15 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. Page 116 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.16 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 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 Page 117 Webulator/400R User Manual, Version 2.0 2.0 Usi 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 CHGWBLSSN (section 3.1.24 on page 160) 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 68) for allowing signon override should also be reviewed. TERMTIME (CHGWBLSSN) 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 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.2.85 on page 258) parameter on the CHGWBLSSN (section 3.1.24 on page 160) 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 Webulator/400 commands Because Webulator/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 118 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.17 Logs Webulator/400 includes a logging facility which helps the WebMaster maintain the server. The access log reports all attempts to access documents on the server within either a text file using an industry defacto standard format, or within a Data Base file which provides a superset of the text file information. The error log (section 2.18 on page 120) is the location that the WebMaster checks to find any errors that may be occurring within the server. If the log file does not exist, it will be created. The log files only support one member within them. If multiple members exist within the file, only the first member will be used. Each log file stored within the QSYS file system will use a multi-field record format. Included within the logging facility is the ability to cycle the log files. The log file cycling capability gives the WebMaster the ability to set up a schedule when the error or access (section 2.19 on page 122) log files should be rotated. NOTE: Logging from within multiple Webulator/400 servers to the same log file is prohibited. If the log file is locked when the server attempts to cycle it, the cycling will be suspended until the file is unlocked. If a tool or another instance of the Web Server has the file open this will lock the file, suspending the log file cycling until the file is closed (unlocking the file). 2.17.1 Server User Profile Authority Considerations The Server User Profile (section 4.2.76 on page 250) requires Read, Write and eXecute authorities for all directories containing any of the logs. Note that the authorities assigned to all log files created, including cycled log files will only include the *PUBLIC authorities and the authorities of the server user profile. The *PUBLIC authority will be assigned the same as the library or directory where the log file exists. Any special authorities granted or denied to other users will not be carried forward from the library or directory. This limitation exists because the server user profile should, in most cases, have limited authorities for security reasons. Page 119 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.18 Error Log The error logging facility is used by the Webmaster to determine what web server errors are occurring on the system. These errors may include, but are not limited to system errors, TCP/IP errors, and programming errors. The error log has two different formats. The format used is dependent upon the file system the log is configured for. For every file system other than the QSYS file system the log file is a text file. Within the QSYS file system the log entries are stored within a multiple field data base file. The Error Log Filename configuration value is used to configure the error log file. There are three levels of logging: Error, Warning, Informational. The Error level of logging is the most severe level of the three with the Informational level being the least severe. The WebMaster has the ability to indicate what level of error messages to be placed in the error log file through the configuration value Error Log Level (section 4.2.39 on page 219). Error These messages are most often messages that need to be addressed. Warning These messages are possible areas to be aware of. Informational These messages are pieces of information that may help your server run smoother, but may not be a major concern. The following is the format of the error log text file entries: [day-of-week month day time year] Program name reporting error: Level of error message: Error message text The following is the list of the fields, in their respective order, included within a data base error log file entry: Date (8 characters) This is the date when the error occurred. The format of this field is "YYYYMMDD" . YYYY is the year using 4 character positions . MM is the month using 2 character positions . DD is the day of the month using 2 character positions. Time (6 characters) This is the time when the error occurred. The format of this field is "HHMMSS" Page 120 Webulator/400R User Manual, Version 2.0 2.0 Usi . HH is the hour displayed as a value of (00 - 23 hours) using 2 character positions . MM is the minutes using 2 character positions . SS is the seconds using 2 character positions Program name reporting the error (10 characters) The name of the program reporting the error. The Webulator/400 product ships multiple programs with the product. This name is used to determine which program the error occurred within. Error level (2 characters) The level of the error log entry. The valid values are 10 (indicating an informational message), 30 (indicating a warning message) or 40 (indicating an error message). Error message text (512 characters) The error message text. The Server User Profile (section 4.2.76 on page 250) requires Read, Write and eXecute authorities for the directory containing the error log file. Page 121 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.19 Access Log The WebMaster uses the access log to track every attempt to access the server, even failed attempts. This information can be useful for many different reasons. It can be used to determine which pages are being hit the most and perhaps where bad links exist (in the cases where unsuccessful attempts are reported). The access log has two different formats. The format used is dependent upon the file system the log is configured within. For every file system other than the QSYS file system the log file is a text file with its format conforming to the defacto standard put in place by the web server industry. By following this standard format it has made it easier for the WebMaster to obtain industry standard tools to help analyze the data. If the log file is configured for the QSYS file system the file is a Data Base file which contains a superset of the data stored within the text format. In either format if the file exists prior to starting the server the file will be appended to. If the file does not exist it will be created. The access log is a file created using the Access Log Filename (section 4.2.36 on page 215) configuration value. Access logging can be disabled by specifying a blank access log filename within the master configuration file, or by specifying a '*none' value within the CHGWBLSSN (section 3.1.24 on page 160) command. Access Log Text File Format The following is the format of an access log entry. Internet Address - User Name [Date and time stamp] "Req type URL HTTP level" Status code Bytes Transferred Internet Address The internet address of the host machine requesting the URL. This would be in the form of a host name if one is available. User Name The user name passed in the authentication header of the request. Date and Time stamp The format of the date and time stamp is [DD/Mth/Year:hr:mi:ss +-GMT] where . DD is the day of the month . Mth is the month . Year is the year . hr is the hour displayed as a value (0 - 23 hours) . mi is the minutes . ss is the seconds Page 122 Webulator/400R User Manual, Version 2.0 2.0 Usi . GMT will be the difference in time between the current time zone set on the AS/400 and Greenwich Mean Time. The first character in this field represents whether the current time zone is ahead (+) or behind (-) GMT. The next 4 characters represent the offset in hours and minutes HHMM. Req type The type of request being logged. URL The Uniform Resource Locator requested to be processed. HTTP level The HTTP protocol level requested by the browser. If there is no value in this location the requesting browsers HTTP protocol contains a level prior to HTTP/1.0 level (0.9 is the only valid HTTP protocol documented prior to 1.0). Status code The status code (section 2.20 on page 126) resulting from the attempt to access the URL specified. For example 200 indicates that the request was successfully processed without errors. Bytes transferred The size of the URL transferred to fulfill the request. Access Log Data Base File Format The data base format of the access log is very similar to the text formatted log file in the sense that it contains a single record for each attempted document access and it includes a superset of the data available in the text log file. The field ordering of the data base version of the access log file differs from the text formatted version. The following is the format of the data base version of an access log entry. Short Internet Address - User Name Date Time [Date and time stamp] Status code Bytes Transferred "Req type URL HTTP level" Long Internet Host Name Short Internet Address (32 characters) The internet address of the host machine requesting the URL. This would be in the form of a host name if one is available. This field only contains the first 32 characters of the host name. The entire host name is supplied in the Long Internet Host Name field. User Name (10 characters) The user name passed in the HTTP authentication header of the request. Page 123 Webulator/400R User Manual, Version 2.0 2.0 Usi Date (8 characters) This is the current access request date specified in the current time zone versus the GMT time zone. The format of this field is "YYYYMMDD" . YYYY is the year using 4 character positions . MM is the month using 2 character positions . DD is the day of the month using 2 character positions. Time (6 characters) This is the current access request time specified in the current time zone versus the GMT time zone. The format of this field is "HHMMSS" . HH is the hour displayed as a value of (00 - 23 hours) using 2 character positions . MM is the minutes using 2 character positions . SS is the seconds using 2 character positions Date and Time stamp (28 characters) The access request date and time specified using the access log industry standard format (including the fact that the date and time is specified in Greenwich Mean Time (GMT)). The format of the date and time stamp is [DD/MM/YYYY:HH:MM:SS +-GMT] where . DD is the day of the month using 2 character positions . MM is the month using 2 character positions . YYYY is the year using 4 character positions . HH is the hour displayed as a value of (0 - 23 hours) using 2 characters positions . MM is the minutes using 2 character positions . SS is the seconds using 2 character positions . GMT will be the difference in time between the current time zone set on the AS/400 and Greenwich Mean Time (GMT) using 5 character positions. The first character in this field represents whether the current time zone is ahead (+) or behind (-) GMT. The next 4 characters represent the offset in hours and minutes HHMM. Status code (3 characters) The status code (section 2.20 on page 126) resulting from the attempt to access the URL specified. For example 200 indicates that the request was successfully processed without errors. Bytes transferred (10 characters) The size of the URL transferred to fulfill the request. Req method type (6 characters) The HTTP request method type being logged (Get, Post, Put or Delete). Page 124 Webulator/400R User Manual, Version 2.0 2.0 Usi HTTP level (10 characters) The HTTP protocol level requested by the browser. If there is no value in this location the requesting browsers HTTP protocol contains a level prior to HTTP/1.0 level (0.9 is the only valid HTTP protocol documented prior to 1.0). URL (128 characters) The Uniform Resource Locator requested to be processed. Long Internet Address (128 characters) The internet address of the host machine requesting the URL. This would be in the form of a host name if one is available. This field supports the entire host name. The short internet address only contains the first 32 characters. In the cases where the host name is longer than 32 characters this field would be the location to find the entire name. The differences between the text access log file and the data base access log file are described by the additional fields listed below. . The date and time of the access attempt is recorded using the current time zone values (not GMT). This information is supplied separating the date and time into two separate fields. . A long and short version of the host name are both available. The long host name field which can hold up to 128 characters is located at the end of the record, while a short version (holding only the first 32 characters of the host name) is recorded in the first field of the record. The shortened host name is located in the front of the record for two reasons, the first is to make the host name or internet address easily available to the WebMaster when viewing the file using the DSPPFM command or the Webulator/400's integrated data base access support. Secondly it is kept in the same location as the text file format, this is for the WebMaster who is accustomed to viewing the text based industry standard access log. The long host name field is located as the last field in the record. This field will include the entire name, and is only needed when the name exceeds 32 characters. The DDS source used to create the access log can be found in the WEBULATOR library QDDSSRC file ACCESSLOG member. This information can be used to programmatically describe the record format of the access log data base file. The Server User Profile (section 4.2.76 on page 250) requires Read, Write and eXecute authorities for the directory containing the access log file. Page 125 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.20 Status Codes Status codes as specified in the HTTP 1.0 specification. (http://www.w3.org/Protocols/Overview.html) 2xx Success The requested action was successfully received and understood . 200 OK . 201 Created . 202 Accepted . 203 Provisional Information . 204 No Response . 205 Deleted . 206 Modified 3xx Redirection Further action must be taken in order to complete the request . 301 Moved Permanently . 302 Moved Temporarily . 303 Method . 304 Not Modified 4xx Client Error The request contains bad syntax or is inherently impossible to fulfill . 400 Bad Request . 401 Unauthorized . 402 Payment Required . 403 Forbidden . 404 Not Found . 405 Method Not Allowed . 406 None Acceptable . 407 Proxy Authentication Required . 408 Request Timeout 5xx Server Error The server could not fulfill the request . 500 Internal Server Error . 501 Not Implemented . 502 Bad Gateway . 503 Service Unavailable . 504 Gateway Timeout Page 126 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.21 Webulator/400 Useability Considerations 2.21.1 Webulator/400 Client Software Because Webulator/400 translates the AS/400 5250 data stream into HTML forms that are presented by Web browsers, there is no Webulator/400 specific client software. Data stream processing is performed on the AS/400 and user interaction is handled by the Web browsers. This differs from 5250 emulators that perform the data stream interpretations and user interaction on the client machine. The Webulator/400 offers the advantage of being client platform independent but pays a small price in terms of client side flexibility and functionality. This section will discuss some of the areas where Webulator/400 functionality differs from non- HTML based emumation packages. 2.21.2 Webulator/400 Browser Topics This section discusses the functionality differences imposed on Webulator/400 by HTML browsers. Unable to move cursor outside input capable fields The concept of a cursor to a browser only applies when working with input capable fields. Since the browser does not understand the concept of cursor positioning outside input fields can be used to indicate valuable positioning information, they do not allow users to place a cursor on output only fields. This means that you cannot move the cursor to a screen location that contains an output field and press an AID key to trigger a cursor sensitive AS/400 action. There is no field exit key Seasoned AS/400 users expect several things to happen when they press the field exit (or field minus) key in a non HTML based emulation package. Some of the expected behavior includes clearing out the remaining characters in the field, performing any necessary editing adjustment (e.g., right adjust - blank fill) and to move the cursor to the beginning of the next field. Since Webulator/400 is a form processing script program, it cannot provide all of the field exit functionality in real time. If a user could press field exit using Webulator/400, it would not be able to clear out the remaining data in the field nor could it immediately perform necessary adjustments (Webulator/400 always performs editing functions on all data it receives from the browser). The only functionality remaining is to move the cursor to the beginning of the next field. In other words, there is no difference between a field exit key and a tab key when using Webulator/400. Page 127 Webulator/400R User Manual, Version 2.0 2.0 Usi Unable to view all AS/400 output messages Since the browser is only able to receive data from the AS/400 after a user submits the HTML form, it is not possible for Webulator/400 to continually send screen updates to the browser. Webulator/400 will attempt to buffer all output messages and send them with the next screen but it is not always able to do so. Webulator/400 clears all screen data (seen and unseen) whenever it encounters a Clear Unit command in the 5250 data stream. A Clear Unit command is inserted into the 5250 data stream by various screen I/O commands such as the EXFMT command in RPG. In addition, Webulator/400 is also unable to support AS/400 Break messages. AS/400 Break messages are messages that interrupt the current screen and require some sort of response (at a minimum an Enter key) to return to the previous screen. Break messages cause Webulator/400 to be out of sync with the AS/400 causing unpredictable results. Extra screens are occasionally sent to the browser Some host programs send a write/read screen I/O request followed immediately by a cancel read operation. The end result of these operations are the same as a write request. These requests are handled seamlessly by non HTML based emulators because of their constant communication link with the AS/400. Webulator/400 has a little more difficulty handling these I/O requests. Webulator/400 will verify that no Cancel requests have been generated by the AS/400 before sending a screen to the browser. Unfortunately, there is no guarantee that the Cancel request will be received before the screen is sent to the browser. This means that certain write/read/cancel requests will get by Webulator/400's checking and be sent to the browser. If this happens, all you have to do is press a Virtual Keyboard button and the next screen will be sent to the browser. Unable to perform Text Assist functions Webulator/400 is unable to fully support programs that use the Text Assist functions (e.g., OfficeVision/400). Text Assist programs require more interaction with the AS/400 than is possible using Webulator/400. The Attention button does not always work Care should be taken before allowing this button to be made available through Webulator/400. You must ensure that the user profile that is signed on for a session has an Attention program assigned to it. As long as it does, everything will work fine. You will run into problems if a Webulator/400 user presses the Attention button and their user profile does not have an attention program defined for it. 5250 emulation programs are able to notify the AS/400 that the Attention key was pressed and retain control of the current screen until they are interrupted by the new attention program. If there is no attention program to run, the 5250 emulation program will continue to process the Page 128 Webulator/400R User Manual, Version 2.0 2.0 Usi current screen. Since the Web browser returns control to the AS/400 when any submit button is pressed (including the Attention submit button), it must wait for a new screen to arrive from the AS/400 before allowing the user to interact with the screen. If there is no attention program to generate a new screen, the browser will time out waiting for the new screen and will not allow the user to continue with the screen where the Attention button was pressed. Page 129 Webulator/400R User Manual, Version 2.0 2.0 Usi 2.22 Session Based Configuration 2.22.1 Overview Webulator/400 includes the support of session based configuration. This allows configuration to be based on the Webulator/400 configuration values (or URL) that a browser requests. The advantage of this is flexibility. You can configure the Webulator to act differently for different requests. All Webulator/400 session based configuration values can be configured independently for each Webulator/400 URL. The configuration file is divided into sections, one section per session. A session section can contain configuration information that applies to that session and all child sessions below it. Any child session can set configuration values in its own section that will override the value it would have inherited from its parent session. 2.22.2 A Simple Example If you use the WRKWBLSSN (section 3.1.23 on page 158) command to create an entry for the session /, then use the CHGWBLSSN (section 3.1.24 on page 160) command to set the signon (section 4.2.81 on page 254) value to *USER WblUser, a section like the one below will be created in your configuration file: Signon User WblUser In the example above, the first and third lines indicate that this configuration is for the root Webulator URL. The second line indicates that all browsers choosing this URL (and any below) will automatically be signed on as WblUser. 2.22.3 A Further Example After performing the simple example above, perform the following steps: 1.Add a black session Use the WRKWBLSSN (section 3.1.23 on page 158) command to create an entry for the session /Black, then use the CHGWBLSSN (section 3.1.24 on page 160) command to set the signon (section 4.2.81 on page 254) value to *USER Page 130 Webulator/400R User Manual, Version 2.0 2.0 Usi WblUser2, and set the background color (section 4.2.53 on page 231) to 000000. 2.Add a white session Use the WRKWBLSSN (section 3.1.23 on page 158) command to create an entry for the session /White, then use the CHGWBLSSN (section 3.1.24 on page 160) command to set the background color (section 4.2.53 on page 231) to FFFFFF. After performing the step from the simple example and the steps from this example, your configuration file will contain sections like those below: Signon User WblUser Signon User WblUser2 BackgroundColor #000000 BackgroundColor #FFFFFF The example above has three sections, representing three different URLs that a browser could access. The first section is taken from the previous example. The second section is a child session (or sub-session) of the first session. It changes the signon user to WblUser2. Therefore, any browser accessing this URL will automatically be signed on with that user name. There is also a configuration line that will set the background color of the browser to black. The Signon entry in the second section overrides the entry from the first section. The BackgroundColor entry overrides the default value. The third section is also a sub-session of the first session. As such, it inherits the Signon entry from the first section (and does not override it). Any browser accessing this URL will be signed on with the user name WblUser. The background color in this session is set to white. 2.22.4 How to Change the Configuration We recommend that you use the commands (section 3.1 on page 134) to change the configuration. Alternatively, you may Page 131 Webulator/400R User Manual, Version 2.0 2.0 Usi edit the files using an editor. The simplest way to do this is using a workstation attached to the AS/400 with Client Access/400. You will need to be aware that the editor may remove authority information because of the way it saves files. When saving files, many editors actually rename the original file with a .bak extension and write a new file with the correct extension. If this happens, the renamed file will retain the AS/400 authority information of the original file, while the new file will get new authority information. 2.22.5 Related Information Here is more information about the entries in the examples: . Session section (section 4.2.11 on page 193) . Session based configuration file (section 5.2.5 on page 268) . Signon method (section 4.2.81 on page 254) . Background color (section 4.2.53 on page 231) Page 132 Webulator/400R User Manual, Version 2.0 3.0 Com 3. Commands Page 133 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1 Webulator Commands 3.1.1 Webulator/400 Commands There are a number of configuration and operation commands provided by the Webulator/400 product. They include commands to work with the server operations (Operational Commands on page 134), as well as commands to work with, and modify, the configuration (Configuration Commands on page 134) of the server. Menus (Menus on page 136) are also provided for convenient access to the product commands. All of the Webulator/400 command names contain WBL which stands for Webulator. 3.1.1.1 Operational Commands Include: . STRWBL (section 3.1.2 on page 136) - Start Webulator Server . ENDWBL (section 3.1.3 on page 142) - End Webulator Server . STRWBLRP (section 3.1.4 on page 144) - Start Webulator Server Request Processors . ENDWBLRP (section 3.1.5 on page 145) - End Webulator Server Request Processors These commands perform the functions to allow operational use of the server, as well as discontinuing its availability. 3.1.1.2 Configuration Commands Include: . CHGWBLSVR (section 3.1.6 on page 147) - Change Webulator Server Configuration . SETWBLCFG (section 3.1.7 on page 148) - Set Webulator Configuration Values . MIGWBLUSR (section 3.1.8 on page 149) - Migrate Workstation Gateway Configuration Alias Commands: . WRKWBLALS (section 3.1.10 on page 151) - Work with Webulator Aliases . ADDWBLALS (section 3.1.11 on page 152) - Add Webulator Alias Entry . CHGWBLALS (section 3.1.12 on page 152) - Change Webulator Alias Entry . DLTWBLALS (section 3.1.13 on page 153) - Delete Webulator Alias Entry Page 134 Webulator/400R User Manual, Version 2.0 3.0 Com User / Authentication Commands: . WRKWBLAUT (section 3.1.14 on page 153) - Work with Webulator Authentication Users . ADDWBLAUT (section 3.1.15 on page 154) - Add Webulator Authentication User Entry . CHGWBLAUT (section 3.1.16 on page 154) - Change Webulator Authentication User Entry . DLTWBLAUT (section 3.1.17 on page 154) - Delete Webulator Authentication User Entry . MIGWBLAUT (section 3.1.18 on page 155) - Migrate Stream Authentication Users to Database User Profile Commands: . WRKWBLPRF (section 3.1.19 on page 156) - Work with Webulator User Profiles . ADDWBLPRF (section 3.1.20 on page 157) - Add Webulator User Profile Entry . CHGWBLPRF (section 3.1.21 on page 157) - Change Webulator User Profile Entry . DLTWBLPRF (section 3.1.22 on page 158) - Delete Webulator User Profile Entry Session Based Configuration Commands: . WRKWBLSSN (section 3.1.23 on page 158) - Work with Webulator Session Based Configurations . CHGWBLSSN (section 3.1.24 on page 160) - Change Webulator Session Configuration Special Secure Commands: . CHGWBLSEC (section 3.1.27 on page 164) - Change Secure Configuration . CRTWBLKEY (section 3.1.28 on page 165) - Create Secure Keys . ADDWBLCERT (section 3.1.29 on page 168) - Add Secure Certificate . CHGWBLKPWD (section 3.1.30 on page 170) - Change Secure Keylist File Password . ADDWBLROOT (section 3.1.31 on page 171) - Add Secure Root These commands change the functionality of the server, as well as default locations for the storage and retrieval of information, formats for the distribution of session information and alias transposition information. 3.1.1.3 Authority All of Webulator/400 commands are secured using a product authorization list named WEBULATOR. In order to use the Page 135 Webulator/400R User Manual, Version 2.0 3.0 Com product commands, a user must either be added to the WEBULATOR authorization list with at least *USE authority or have *ALLOBJ special authority (e.g., QSECOFR or users with *SECOFR user class). The product commands are secured to limit use to only authorized personnel. 3.1.1.4 Menus Command menus are also available for convenient access to the Webulator/400 operational and configuration commands. The two menus are called CMDWBL and CMDWBLCFG. CMDWBL shows operational commands and CMDWBLCFG contains the configuration commands. They can be accessed by typing "GO MENU(CMDWBL)" or "GO MENU(CMDWBLCFG)" at an AS/400 command line and pressing the enter key. 3.1.2 STRWBL 3.1.2.1 STRWBL - Start Webulator Server The STRWBL command is used to start the Webulator on the AS/400. Starting the server allows authorized users to access Webulator sessions on the AS/400 using Web browsers. TCP/IP must be started on the AS/400 with the STRTCP command before the server can be started. The server jobs (Server Jobs on page 139), advanced configuration (Advanced Configuration on page 141), and performance (Server Performance on page 142) topics contain further information about the server. 3.1.2.2 STRWBL Parameters CFGFILE - Master Configuration File Specifies the full-path to the master configuration file to be used by the server. The master configuration file (section 5.2.3 on page 265) contains many values that are used to control how the server starts and runs. The default master configuration file is '/Wbl/Cfg/Wbl.Cfg'. This file can be copied (e.g., using the CPY command) and changed using the configuration commands (Configuration Commands on page 134) to create custom master configuration files. STRWBL sets the PORT (PORT on page 137), RPS (RPS on page 137) and SVRID (SVRID on page 137) parameter values based on what is configured in the master configuration file unless the parameters are passed into the command. Page 136 Webulator/400R User Manual, Version 2.0 3.0 Com For special processing needs, the server can be configured with multihome processing enabled (section 4.2.72 on page 245). PORT - Socket Port The socket port the server is going to process. Refer to the socket port (section 4.2.77 on page 251) configuration value for more information. RPS - Initial Request Processors The initial number of request processors to start when the server is started. Refer to the initial request processors (section 4.2.48 on page 226) configuration value for more information. SVRID - Server Identifier A unique ID used to identify the server and the server's jobs. (Server Jobs on page 139) Refer to the server ID (section 4.2.74 on page 248) configuration value for more information. The default is to use the configured value. If a server ID is not entered or configured, the server port and host are used to uniquely identify the server when starting additional request processors (section 3.1.4 on page 144), ending request processors (section 3.1.5 on page 145) and ending the server (section 3.1.3 on page 142); otherwise the entered/configured server ID is used to uniquely identify the server. PASSWORD - Password The current password used to encrypt the server's keylist file. This parameter is required when running the server using a secure protocol (i.e., SSL). The keylist file password was initially set with the CRTWBLKEY (section 3.1.28 on page 165) command. The password can be changed with the CHGWBLKPWD (section 3.1.30 on page 170) command. If the password is case-sensitive it must be enclosed in single quotes. ACTKEY - Product Activation Key The product activation key is an additional parameter that is required when starting the server for the first time. The server will not start until a valid activation key is provided. The key is no longer required once the server has successfully started once. The activation key is provided by your supplier with the product tape. If the activation key was not sent, does not work, or your system serial number has changed contact your supplier. ENDDATE - Trial Activation Key End Date The ending date for the trial activation key. The date must be specified in the job date format. Page 137 Webulator/400R User Manual, Version 2.0 3.0 Com TCPTIMO - TCP/IP Timeout The number of minutes to wait for TCP/IP to start. This parameter is used when TCP/IP has not been completely started before starting the server. The server will wait up to the specified minutes for TCP/IP to be started. The default is to wait 10 minutes. 3.1.2.3 Authority Considerations 1.A user that does not have *ALLOBJ special authority must be authorized as follows to run the STRWBL command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/STRWBL *CMD. . *USE authority to WEBULATOR/WBLDAEPOP *PGM. . *USE authority to WEBULATOR/WBLDAECPP *PGM. . *USE authority to WEBULATOR/WBLDAEMON *PGM. and . *USE authority to QSYS/QSYSNOMAX *JOBQ. . *READ authority to server configuration files (section 5.1 on page 263). . *OBJMGT authority to server user profile (section 4.2.76 on page 250). . *ALL authority to WEBULATOR/WBLACTKEY *DTAARA when entering a new activation key. . *ALL authority to an existing server user space. 2.The Server user profile (section 4.2.76 on page 250) must be authorized as follows to start the server: . Added to the WEBULATOR product authorization list. or . *USE authority to WEBULATOR/WBLDAEMON *PGM. and . *USE authority to QSYS/QSYSNOMAX *JOBQ. . *USE authority to all of the libraries in the library list. The library list of the user starting the server is used by the server with the exception of the current library which is always set to library WEBULATOR. . Create authority to the configured log libraries/directories. At least execute authority to the preceding directories when logging to IFS. . *RX authority to the configured keylist file (if applicable). 3.The system value QALWUSRDMN must be set to allow user- domain objects to be created in libraries QTEMP and WEBULATOR. 4.A user must meet one of the following conditions to modify or end the started server: . User that started the server . User with *ALLOBJ authority Page 138 Webulator/400R User Manual, Version 2.0 3.0 Com . User that has been granted *ALL authority to the server user space. The authority must be granted after starting the server. The server user space can be found in the WEBULATOR product library and it is named as follows: WBU appended with the server identifer (SVRID on page 137). 3.1.2.4 Server does not Start If the server does not start consult the following for more information: 1.Display the joblog (e.g., DSPJOBLOG) 2.Work with and display the server user profile (section 4.2.76 on page 250) spooled files (e.g., WRKSPLF SELECT(WBLUSER)). The server user profile (section 4.2.76 on page 250) not having authority to a library in the library list is the most common cause of the server not starting. Correct the problem and try to start the server again. 3.1.2.5 Server Jobs When performing a WRKACTJOB command after starting the Webulator with multihome (section 4.2.72 on page 245) disabled using the default server ID (SVRID on page 137) the server jobs can be identified as follows: Subsystem/Job User Type CPU % Function Status QSYSWRK QSYS SBS .0 DEQW WBD5061 WBLUSER BCH .0 PGM-WBLDAEMON TIMW WBL5061 WBLUSER BCH .0 PGM-WBLDLOG DEQW WBR5061 WBLUSER BCH .0 PGM-WBLDRP DEQW WBR5061 WBLUSER BCH .0 PGM-WBLDRP DEQW WBV5061 WBLUSER BCH .0 PGM-WBLVT DEQW When multihome (section 4.2.72 on page 245) is enabled using configured server IDs (SVRID on page 137) the server jobs can be identified as follows: Page 139 Webulator/400R User Manual, Version 2.0 3.0 Com Subsystem/Job User Type CPU % Function Status QSYSWRK QSYS SBS .0 DEQW WBDINET WBLUSER BCH .0 PGM-WBLDAEMON TIMW WBDKAZOO WBLUSER BCH .0 PGM-WBLDAEMON SELW WBLINET WBLUSER BCH .0 PGM-WBLDLOG DEQW WBLKAZOO WBLUSER BCH .0 PGM-WBLDLOG DEQW WBRINET WBLUSER BCH .0 PGM-WBLDRP DEQW WBRKAZOO WBLUSER BCH .0 PGM-WBLDRP DEQW WBRKAZOO WBLUSER BCH .0 PGM-WBLDRP DEQW WBVINET WBLUSER BCH .0 PGM-WBLVT DEQW WBVKAZOO WBLUSER BCH .0 PGM-WBLVT DEQW where, WBLUSER is the default server user profile. All server jobs run under the configured server user profile (section 4.2.76 on page 250). WBLUSER's profile is setup to use the WEBULATOR/WBLJOBD job description, which is configured to use the QSYS/QSYSNOMAX job queue. QSYSWRK is the subsystem where the server jobs are running. The QSYSNOMAX job queue is configured to run multiple active jobs in the QSYSWRK subsystem. WBDxx is the server. One server job exists to handle requests for a single host and port. The server job accepts the request and immediately passes it on to a request processor. The name of the server job is WBD appended with the server identifier (SVRID on page 137). In the first set of jobs a single server is running with the default server ID of '5061', which is the port the server is processing. The second set of jobs show two servers running with configured server IDs: 'INET' and 'KAZOO'. The host and port(s) the server is processing can be displayed by performing the following command: DSPOBJD OBJ(WEBULATOR/WBQxx) OBJTYPE(*USRQ) DETAIL(*FULL) Page 140 Webulator/400R User Manual, Version 2.0 3.0 Com where the name of the user queue is the same as the server job name except for the D is replaced with a Q. The displayed user queue text contains the port(s) and host that the server is processing. For example, Text . . . . : PORT: 5061 HOST: www.inetmi.com Text . . . . : PORT: 5061/443 HOST: www.inetmi.com indicates the server is processing host 'www.inetmi.com' on port 5061. The second example is running the Webulator securely; HTTP protocol is being processed on port 5061 and SSL is being processed on port 443. WBLxx is the log server. The log server is used to write out the server access and error logs. One log server job exists to handle requests for a single host and port. The xx characters represent the server ID (SVRID on page 137). WBRxx are the server request processors. Each host and port can have many request processors. Each request is handled to completion by a single request processor. The xx characters represent the server ID (SVRID on page 137). WBVxx is the virtual terminal server. The virtual terminal server interacts with OS/400 virtual terminals to provide Webulator sessions. One virtual terminal server job exists to handle requests for a single host and port. The xx characters represent the server ID (SVRID on page 137). 3.1.2.6 Advanced Configuration Server Jobs The server user profile (section 4.2.76 on page 250) (e.g., WBLUSER) configuration controls how the server jobs are run. All of the attributes for the server jobs are retrieved from the server user profile and the profile's configured job description. The server user profile's job description defines the job queue that is used to submit the server jobs. The configured job queue must support multiple active jobs (e.g., QSYSNOMAX). Also, the job description's routing data (e.g., RUNPTY20) must be setup appropriately for the job queue and subsystem that is being used. The ability to change the server user profile and job description gives you the ability to configure how you want the server to run on your system. Page 141 Webulator/400R User Manual, Version 2.0 3.0 Com Library List The user part of the library list for the server jobs can be controlled with the Initial Library List (section 4.2.71 on page 245) configuration value. 3.1.2.7 Server Performance The server performance is affected by many factors: . AS/400 relative performance rating . Percentage of system auxiliary storage used . Amount of memory (main storage) installed . Pool configuration . Number of jobs running on the system (i.e., system load) . Network speed Improving any of the factors above can lead to increased server throughput. By default, TCP/IP, Client Access/400 and Webulator/400 jobs run in the *BASE pool (i.e., system pool 2). Server performance can be improved by reducing the number of page faults in the *BASE pool by adjusting the pool sizes. Also, advanced configuration (Advanced Configuration on page 141) provides information that can be used to customize how the server runs on your system. 3.1.3 ENDWBL 3.1.3.1 ENDWBL - End Webulator Server The ENDWBL command is used to end one or more running Webulator servers. The server(s) can be identified using either the PORT (PORT on page 142) and HOST (HOST on page 143) parameters or the SVRID (SVRID on page 143) parameter. Care must be taken when ending servers to ensure the correct server(s) are being ended. The ENDWBL command returns before all of the server jobs have ended. The WRKACTJOB command can be used to identify when all of the server jobs have been ended. 3.1.3.2 ENDWBL Parameters PORT - Socket Port Identifies the server to end by the socket port the server is processing. The port and host (HOST on page 143) uniquely identify the server ending. Refer to the socket port (section 4.2.77 on page 251) configuration value for more information. Page 142 Webulator/400R User Manual, Version 2.0 3.0 Com The special value *ALL may be used to end all running Webulator servers. This parameter is only used when the server ID (SVRID on page 143) parameter is set to *PORT. HOST - Host Name or IP Address Identifies the host the server is processing. The default value is *NOMULTIHOME. The default value must be used if the server has multihome processing (section 4.2.72 on page 245) disabled. A valid host must be specified if the server has multihome processing enabled. The host can be identified with either a host name or an IP address. If the host is not known then the server jobs (Server Jobs on page 139) can be used to determine the host name. The special value *ALL may be used to end all running servers on a specified port. This parameter is only used when the server ID (SVRID on page 143) parameter is set to *PORT. SVRID - Server Identifier Used to identify a specific server to be ended. The server identifier is assigned to the server at startup (SVRID on page 137). The server ID entered can be either a configured (section 4.2.74 on page 248) or default (section 4.2.74 on page 248) value. This parameter must be used to end a specific server if the server identifier is not the default server ID. The default of *PORT indicates that the PORT and HOST parameters are to be used to identify the server(s) to end. 3.1.3.3 Authorizing a User to ENDWBL A user that does not have *ALLOBJ special authority must be authorized as follows to run the ENDWBL command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/ENDWBL *CMD . *USE authority to WEBULATOR/WBLDAEMON *PGM and . *ALL authority to the server user space (server user space on page 139) Page 143 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1.4 STRWBLRP 3.1.4.1 STRWBLRP - Start Webulator Server Request Processors The STRWBLRP command is used to start additional Webulator request processors for a specific server. The server can be identified using either the PORT (PORT on page 144) and HOST (HOST on page 144) parameters or the SVRID (SVRID on page 145) parameter. The SVRID (SVRID on page 145) parameter must be used to identify the server if a server identifier was specified when starting the server (SVRID on page 137). Starting additional request processors allows the server to handle more concurrent requests. The initial number of request processors are started when the server is started using the STRWBL (section 3.1.2 on page 136) command. Additional request processors will also start dynamically based on the request wait timeout (section 4.2.50 on page 228) configuration value. 3.1.4.2 STRWBLRP Parameters PORT - Socket Port The socket port to start additional server request processors on. The default value is 5061. The port and host (HOST on page 144) uniquely identify the running server. Refer to the socket port (section 4.2.77 on page 251) configuration value for more information. This parameter is only used when the server ID (SVRID on page 145) parameter is set to *PORT. RPS - Additional Request Processors The number of additional server request processors to start. The default value is 1. The maximum request processors (section 4.2.49 on page 227) configuration value determines the total number of request processors that can be started. HOST - Host Name or IP Address Identifies the host the server is processing. The default value is *NOMULTIHOME. The default value must be used if the server has multihome processing (section 4.2.72 on page 245) disabled. A valid host must be specified if the server has multihome processing enabled. The host can be identified with either a host name or an IP address. If the host is not known then the server jobs (Server Jobs on page 139) can be used to determine the host name. This parameter is only used when the server ID (SVRID on page 145) parameter is set to *PORT. Page 144 Webulator/400R User Manual, Version 2.0 3.0 Com SVRID - Server Identifier Used to identify the server for which request processors are to be started. The server identifier is assigned to the server at startup (SVRID on page 137). The server ID entered can be either a configured (section 4.2.74 on page 248) or default (section 4.2.74 on page 248) value. This parameter must be used if the server identifier is not the default server ID. The default of *PORT indicates that the PORT and HOST parameters are to be used to identify the server. 3.1.4.3 Authorizing a User to STRWBLRP A user that does not have *ALLOBJ special authority must be authorized as follows to run the STRWBLRP command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/STRWBLRP *CMD . *USE authority to WEBULATOR/WBLDAEMON *PGM and . *USE authority to QSYS/QSYSNOMAX *JOBQ . *USE authority to server user profile (section 4.2.76 on page 250) . *ALL authority to the server user space (server user space on page 139) 3.1.5 ENDWBLRP 3.1.5.1 ENDWBLRP - End Webulator Server Request Processors The ENDWBLRP command is used to end Webulator request processors for a specific server that are no longer needed. The server can be identified using either the PORT (PORT on page 146) and HOST (HOST on page 146) parameters or the SVRID (SVRID on page 146) parameter. The SVRID (SVRID on page 146) parameter must be used to identify the server if a server identifier was specified when starting the server (SVRID on page 137). The initial number of request processors are started when the server is started using the STRWBL (section 3.1.2 on page 136) command. Additional request processors could have been started with the STRWBLRP (section 3.1.4 on page 144) command or started dynamically based on the request wait timeout (section 4.2.50 on page 228) configuration value. Page 145 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1.5.2 ENDWBLRP Parameters PORT - Socket Port The socket port to end server request processors on. The default value is 5061. The port and host (HOST on page 146) uniquely identify the running server. Refer to the socket port (section 4.2.77 on page 251) configuration value for more information. This parameter is only used when the server ID (SVRID on page 146) parameter is set to *PORT. RPS - Request Processors to End The number of server request processors to end. The default value is 1. The value must be less than the currently number of running request processors. To end all request processors and the server use the ENDWBL (section 3.1.3 on page 142) command. HOST - Host Name or IP Address Identifies the host the server is processing. The default value is *NOMULTIHOME. The default value must be used if the server has multihome processing (section 4.2.72 on page 245) disabled. A valid host must be specified if the server has multihome processing enabled. The host can be identified with either a host name or an IP address. If the host is not known then the server jobs (Server Jobs on page 139) can be used to determine the host name. This parameter is only used when the server ID (SVRID on page 146) parameter is set to *PORT. SVRID - Server Identifier Used to identify the server for which request processors are to be ended. The server identifier is assigned to the server at startup (SVRID on page 137). The server ID entered can be either a configured (section 4.2.74 on page 248) or default (section 4.2.74 on page 248) value. This parameter must be used if the server identifier is not the default server ID. The default of *PORT indicates that the PORT and HOST parameters are to be used to identify the server. 3.1.5.3 Authorizing a User to ENDWBLRP A user that does not have *ALLOBJ special authority must be authorized as follows to run the ENDWBLRP command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/ENDWBLRP *CMD Page 146 Webulator/400R User Manual, Version 2.0 3.0 Com . *USE authority to WEBULATOR/WBLDAEMON *PGM and . *ALL authority to the server user space (server user space on page 139) 3.1.6 CHGWBLSVR 3.1.6.1 CHGWBLSVR - Change WBL Server Configuration This is the primary configuration command for Webulator/400. The parameters in this command allow you to configure the functionality of the server, including how many request processors (RPs) will be allowed to run at any one time, a timeout variable to ensure that each request returns in a reasonable amount of time (even if that includes a message indicating no data returned), as well as variables for how information (and how much information) is presented to the user for the sessions returned. Other parameters determine the default locations of the error log file, the access log file, server root directory, and others. The parameters associated with the CHGWBLSVR command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . ACCGBLFILE - Session based configuration file path (section 5.2.5 on page 268) . ALIASFILE - Alias file path (section 4.2.16 on page 198) . SVRROOT - Server root path (section 4.2.20 on page 201) . ACCLOGFILE - Access log file path (section 4.2.36 on page 215) . ACCCYCLE - Access log cycle (section 4.2.35 on page 213) . ERRLOGFILE - Error log file path (section 4.2.38 on page 218) . ERRCYCLE - Error log cycle (section 4.2.37 on page 216) . ERRLOGLVL - Error logging level (section 4.2.39 on page 219) . CONNQUESIZ - Connection queue size (section 4.2.47 on page 226) . INITRPS - Initial request processors (section 4.2.48 on page 226) . MAXRPS - Maximum request processors (section 4.2.49 on page 227) . TIMEOUT - Request wait timeout (section 4.2.51 on page 229) . THRESHOLD - Wait threshold (section 4.2.50 on page 228) . AUTORPTIME - Automatic RP timeout (section 4.2.52 on page 230) . CNTNTCCSID - Content CCSID (section 4.2.68 on page 242) Page 147 Webulator/400R User Manual, Version 2.0 3.0 Com . DISABLESVR - Disable server (section 4.2.69 on page 242) . DOMNAMLOOK - Domain name lookup (section 4.2.70 on page 243) . HOSTNAME - Server host name (section 4.2.73 on page 247) . SVRID - Server Identifier (section 4.2.74 on page 248) . MULTIHOME - Multiple home host server support (section 4.2.72 on page 245) . SVRUSRPROF - Server user profile (section 4.2.76 on page 250) . PORT - Port (section 4.2.77 on page 251) . TEMPDIR - Server temporary directory (section 4.2.78 on page 252) . INLLIBL - Initial library list for server batch jobs (section 4.2.71 on page 245) . PSWDSTG - User password storage method (section 4.2.5 on page 187) . PROTOCOLS - Server protocols (section 4.2.75 on page 249) . WBLUSERFILE - Webulator user file path (section 4.2.80 on page 253) . WBLMAXSSN - Maximum Webulator sessions (section 4.2.79 on page 253) . FALLTHRUH - Fall-thru path for HTTP (section 4.2.21 on page 202) . FALLTHRUS - Fall-thru path for SSL (section 4.2.22 on page 203) . KBDPLUGLOC - Keyboard plugin location (section 4.2.23 on page 204) . UPDATE - Update executing RPs (section 4.2.89 on page 261) Authorizing a User to CHGWBLSVR A user that does not have *ALLOBJ special authority must be authorized as follows to run the CHGWBLSVR command: . *USE authority to QSYS/CHGWBLSVR *CMD . *USE authority to WEBULATOR/WBLGMPOP *PGM . *USE authority to WEBULATOR/WBLGMCPP *PGM . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.7 SETWBLCFG 3.1.7.1 SETWBLCFG - Set WBL Configuration Values While it is possible to modify the configuration values for Webulator/400 using the configuration commands (section 3.1 on page 134) provided with the product, some users may wish to make changes to the files directly. While not Page 148 Webulator/400R User Manual, Version 2.0 3.0 Com recommended, this practice is available for those wishing to exercise it. When modifying the server configuration (section 5.1 on page 263) using the commands, any changes made are automatically reflected in the operation of the server daemons when the command completes execution. Manual modifications using an editor do not inform the request processors that a modification has been made. The SETWBLCFG command allows you to set that flag after manual changes have been made. This command can also be run any time you wish to ensure that the latest configuration values are being executed by the server. The parameters associated with the SETWBLCFG command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) Authorizing a User to SETWBLCFG A user that does not have *ALLOBJ special authority must be authorized as follows to run the SETWBLCFG command: . *USE authority to QSYS/SETWBLCFG *CMD . *USE authority to WEBULATOR/WBLGMSCP *PGM . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *READ authority to server configuration files (section 5.1 on page 263) 3.1.8 MIGWSGWBL 3.1.8.1 MIGWSGWBL - Migrate Workstation Gateway Configuration to Webualtor/400 The MIGWSGWBL command provides the ability to migrate the configuration values that are pertinent to AS/400 Workstation Gateway (WSG) to an appropriate Webulator/400 session configuration. Contents of the INACTTIMO, DTARQSTIMO, DSPSGN, TOPBNRURL, BOTBNRURL, and CCSID parameters of the CHGWSGA command will be migrated. The Port value for the "wsg" service in WRKSRVTBLE will also be migrated, as well as the first exit program found (controls WSG signon) that is registered for the QAPP0100 exit point. The destination configuration files must exist before executing the MIGWSGWBL command. If the session does not exist within the Webulator/400 session configuration file, a new one will be automatically created. Use the CHGWBLSVR (section 3.1.6 on page 147), CHGWBLSSN (section 3.1.24 on page 160), or WRKWBLSSN (section 3.1.23 on page 158) commands to modify other aspects of the Webulator/400 configuration. The parameters associated with the MIGWSGWBL command are: Page 149 Webulator/400R User Manual, Version 2.0 3.0 Com . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . DIRECTORY - Specify or select the Session (section 4.2.11 on page 193) entry within the Session Based Configuration File (section 4.2.12 on page 194) where the resulting configuration values are to be contained. This entry will be the upper-most level for the newly created WSG session within the Webulator/400 configuration. Authorizing a User to MIGWSGWBL A user that does not have *ALLOBJ special authority must be authorized as follows to run the MIGWSGWBL command: . *USE authority to QSYS/MIGWSGWBL *CMD . *USE authority to WEBULATOR/WBLGMWSG *PGM . *USE authority to WEBULATOR/WWWGHCMD *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.9 MIGWBLWBL 3.1.9.1 MIGWBLWBL - Migrate Webulator Session Configuration The MIGWBLWBL command has been designed to act as an aid during the installation and setup of version 2.x of Webulator/400. It provides the ability to migrate the configuration values that are found in a Web Server/400, Commerce Server/400 and Webulator/400 (version 1.x) directory based configuration file to the appropriate Webulator/400 version 2.x session based configuration file. Only contents of the directory based configuration file will be migrated. Master, alias, authentication user, and profile configurations should be reviewed, duplicated, and modified manually. It is possible to use the Copy Object (CPY) command or Client Access IFS or Shared Folders support to accomplish this. Values relating to non-Webulator/400 directories will not be reflected in the new Webulator/400 session configuration. As a result, definitions that were previously inherited from the root directory by all Webulator/400 sessions will not be migrated and should be evaluated and added to the session based configuration manually. The destination session configuration file will be created during the execution of the MIGWBLWBL command. If the configuration file already exists, it will be cleared and migrated session information will replace any data that was previously in the file. Page 150 Webulator/400R User Manual, Version 2.0 3.0 Com Use the CHGWBLSVR (section 3.1.6 on page 147), CHGWBLSSN (section 3.1.24 on page 160), or WRKWBLSSN (section 3.1.23 on page 158) commands to modify other aspects of the Webulator/400 configuration. The parameters associated with the MIGWSGWBL command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . DIRECTORY - Specify or select the Session (section 4.2.11 on page 193) entry within the Session Based Configuration File (section 4.2.12 on page 194) where the resulting configuration values are to be contained. This entry will be the upper-most level for the newly created WSG session within the Webulator/400 configuration. Authorizing a User to MIGWSGWBL A user that does not have *ALLOBJ special authority must be authorized as follows to run the MIGWSGWBL command: . *USE authority to QSYS/MIGWBLWBL *CMD . *USE authority to WEBULATOR/WBLGMMW1 *PGM . *USE authority to WEBULATOR/WWWGHCMD *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) for Webulator/400 version 2.x and for Web Server/400 or Commerce Server/400 3.1.10 WRKWBLALS 3.1.10.1 WRKWBLALS - Work with WBL Aliases Aliases allow a URL to point to a different Webulator/400 session or to a different HTTP server. When an alias (section 4.2.15 on page 197) is found in a URL, the alias is substituted for the value assigned to that alias. This command, with the ADDWBLALS (section 3.1.11 on page 152), CHGWBLALS (section 3.1.12 on page 152), and DLTWBLALS (section 3.1.13 on page 153) commands, allow you to view and maintain the list of aliases (section 5.2.4 on page 267) and their values. The parameters associated with the WRKWBLALS command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) Authorizing a User to WRKWBLALS, and Other Related Commands A user that does not have *ALLOBJ special authority must be authorized as follows to run the WRKWBLALS command: . *USE authority to QSYS/WRKWBLALS *CMD Page 151 Webulator/400R User Manual, Version 2.0 3.0 Com . *USE authority to WEBULATOR/WBLGAWCP *PGM . *USE authority to WEBULATOR/WBLGAWP1 *PNLGRP . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to QSYS/ADDWBLALS *CMD . *USE authority to WEBULATOR/WBLGAACP *PGM . *USE authority to QSYS/CHGWBLALS *CMD . *USE authority to WEBULATOR/WBLGACCP *PGM . *USE authority to WEBULATOR/WBLGACPO *PGM . *USE authority to QSYS/DLTWBLALS *CMD . *USE authority to WEBULATOR/WBLGADCP *PGM . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.11 ADDWBLALS 3.1.11.1 ADDWBLALS - Add WBL Alias This command allows for the addition of an alias (section 4.2.15 on page 197) and its associated value to the alias list. The parameters associated with the ADDWBLALS command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . ALIAS - Alias (Alias on page 197) . VALUE - Actual ([Actual] on page 197) . SRCTYPE - Source type ([SrcType] on page 197) . UPDATE - Update executing RPs (section 4.2.89 on page 261) 3.1.12 CHGWBLALS 3.1.12.1 CHGWBLALS - Change WBL Alias This command allows you to modify the value associated with a given alias (section 4.2.15 on page 197). The parameters associated with the CHGWBLALS command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . ALIAS - Alias (Alias on page 197) . VALUE - Actual ([Actual] on page 197) . SRCTYPE - Source type ([SrcType] on page 197) . UPDATE - Update executing RPs (section 4.2.89 on page 261) Page 152 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1.13 DLTWBLALS 3.1.13.1 DLTWBLALS - Delete WBL Alias This command will remove an alias (section 4.2.15 on page 197) and its associated value from the list of aliases. The parameters associated with the DLTWBLALS command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . ALIAS - Alias (Alias on page 197) . UPDATE - Update executing RPs (section 4.2.89 on page 261) 3.1.14 WRKWBLAUT 3.1.14.1 WRKWBLAUT - Work with WWW Authentication Users User authentication (section 4.2.14 on page 196) allows for the limitation of access to server data to a pre-defined list of users or groups of users. User information will be entered by a browser user to identify themselves to the server during the processing of authenticated data. This command, with the ADDWBLAUT (section 3.1.15 on page 154), CHGWBLAUT (section 3.1.16 on page 154), and DLTWBLAUT (section 3.1.17 on page 154) commands, allow you to view and maintain the list of authentication users (section 4.2.7 on page 188) and their passwords. The parameters associated with the WRKWBLAUT command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USRFILE - User Configuration File (section 4.2.8 on page 189) Authorizing a User to WRKWBLAUT, and Other Related Commands A user that does not have *ALLOBJ special authority must be authorized as follows to run the WRKWBLAUT command: . *USE authority to QSYS/WRKWBLAUT *CMD . *USE authority to WEBULATOR/WBLGUWCP *PGM . *USE authority to WEBULATOR/WBLGUWP1 *PNLGRP . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to QSYS/ADDWBLAUT *CMD . *USE authority to WEBULATOR/WBLGUACP *PGM . *USE authority to QSYS/CHGWBLAUT *CMD . *USE authority to WEBULATOR/WBLGUCCP *PGM . *USE authority to QSYS/DLTWBLAUT *CMD . *USE authority to WEBULATOR/WBLGUDCP *PGM Page 153 Webulator/400R User Manual, Version 2.0 3.0 Com . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.15 ADDWBLAUT 3.1.15.1 ADDWBLAUT - Add WBL Authentication User This command allows for the addition of a user and its associated password to the authentication user list (section 4.2.8 on page 189). The parameters associated with the ADDWBLAUT command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USRFILE - User Configuration File (section 4.2.8 on page 189) . USER - User name (section 4.2.7 on page 188) . PASSWORD - Password (section 4.2.7 on page 188) . UPDATE - Update executing RPs (section 4.2.89 on page 261) 3.1.16 CHGWBLAUT 3.1.16.1 CHGWBLAUT - Change WBL Authentication User This command allows you to modify the password associated with a given authentication user (section 4.2.8 on page 189). The parameters associated with the CHGWBLAUT command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USRFILE - User Configuration File (section 4.2.8 on page 189) . USER - User name (section 4.2.7 on page 188) . PASSWORD - Password (section 4.2.7 on page 188) . UPDATE - Update executing RPs (section 4.2.89 on page 261) 3.1.17 DLTWBLAUT 3.1.17.1 DLTWBLAUT - Delete WBL Authentication User This command will remove a user and its associated password from the list of authentication users (section 4.2.8 on page 189). The parameters associated with the DLTWBLAUT command are: Page 154 Webulator/400R User Manual, Version 2.0 3.0 Com . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USRFILE - User Configuration File (section 4.2.8 on page 189) . USER - User name (section 4.2.7 on page 188) . UPDATE - Update executing RPs (section 4.2.89 on page 261) 3.1.18 MIGWBLUSR 3.1.18.1 MIGWBLUSR - Migrate Stream Authentication Users to Database User authentication (section 4.2.14 on page 196) allows for the limitation of access to server data to a pre-defined list of users or groups of users. User information can be stored in either a stream file or a database file. The MIGWBLUSR command allows for the migration of user information from the traditional stream file storage to a database user file. The parameters associated with the MIGWBLUSR command are: . USRINFILE - Input (Stream) File Specifies the stream user file to retrieve user information from. This user information will be processed and migrated to the database file specified in USROUTFILE. This is the name of the file that contains users. Each line in the file will consist of one user name followed by a colon (':') and then the user's password. . USROUTFILE - Output (Database) File Specifies the database user file that will receive the migrated user information. It should be entered in the usual IFS style ('/QSYS.LIB/LIBRARY.LIB/FILENAME.FILE/MEMBER.MBR'). . TEXTPSWD - Text Password - needs encoding Specifies whether the incoming passwords (in the stream file) are text or not. If they are contained as plain text they will be converted and encoded as they would be if newly added using the ADDWBLAUT command. Valid Values: . *YES Incoming passwords are stored as plain text and are to be converted and encoded before being written in the database file. The Master Configuration File (section 5.2.3 on page 265) name and path are also required during the Page 155 Webulator/400R User Manual, Version 2.0 3.0 Com encoding process to determine the password storage method (PSWDSTG parameter of the CHGWBLSVR (section 3.1.6 on page 147) command) for the conversion. . *NO Incoming passwords are already encoded and are to be written "as is" in the database file. The default for this parameter is *NO. Authorizing a User to MIGWBLUSR A user that does not have *ALLOBJ special authority must be authorized as follows to run the MIGWBLUSR command: . *USE authority to QSYS/MIGWBLUSR *CMD . *USE authority to WEBULATOR/WBLGUMCP *PGM . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.19 WRKWBLPRF 3.1.19.1 WRKWBLPRF - Work with Webulator/400 User Profiles This command lists the current AS/400 user profiles configured to be used for Webulator/400 auto signon sessions (section 2.8.1 on page 60). This command along with ADDWBLPRF (section 3.1.20 on page 157), CHGWBLPRF (section 3.1.21 on page 157), and DLTWBLPRF (section 3.1.22 on page 158) commands can be used to Add, Change, Delete, and Display Webulator/400 auto signon user profiles. The parameters associated with the WRKWBLPRF command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) Authorizing a User to WRKWBLPRF, and Other Related Commands A user that does not have *ALLOBJ special authority must be authorized as follows to run the WRKWBLPRF command: . *USE authority to QSYS/WRKWBLPRF *CMD . *USE authority to QSYS/ADDWBLPRF *CMD . *USE authority to QSYS/CHGWBLPRF *CMD . *USE authority to QSYS/DLTWBLPRF *CMD . *USE authority to WEBULATOR/WBLGPACP *PGM . *USE authority to WEBULATOR/WBLGPCCP *PGM . *USE authority to WEBULATOR/WBLGPDCP *PGM . *USE authority to WEBULATOR/WBLGPWCP *PGM . *USE authority to WEBULATOR/WBLGPWP1 *PNLGRP . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP Page 156 Webulator/400R User Manual, Version 2.0 3.0 Com . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.20 ADDWBLPRF 3.1.20.1 ADDWBLPRF - Add Webulator/400 User Profile This command allows for the addition of an AS/400 user profile, and its password, for use within a Webulator/400 auto signon session (section 2.8.1 on page 60). The parameters associated with the ADDWBLPRF command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USER - User Name (section 4.2.82 on page 256) . PASSWORD - User Password (section 4.2.82 on page 256) . UPDATE - Update executing RPs (section 4.2.89 on page 261) Authorizing a User to ADDWBLPRF A user that does not have *ALLOBJ special authority must be authorized as follows to run the ADDWBLPRF command: . *USE authority to QSYS/ADDWBLPRF *CMD . *USE authority to WEBULATOR/WBLGUACP *PGM . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.21 CHGWBLPRF 3.1.21.1 CHGWBLPRF - Change Webulator/400 User Profile This command provides the ability to change the AS/400 password associated with an AS/400 user profile being used within a Webulator/400 auto signon session (section 2.8.1 on page 60). The parameters associated with the CHGWBLPRF command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USER - User Name (section 4.2.82 on page 256) . PASSWORD - User Password (section 4.2.82 on page 256) . UPDATE - Update executing RPs (section 4.2.89 on page 261) Page 157 Webulator/400R User Manual, Version 2.0 3.0 Com Authorizing a User to CHGWBLPRF A user that does not have *ALLOBJ special authority must be authorized as follows to run the CHGWBLPRF command: . *USE authority to QSYS/CHGWBLPRF *CMD . *USE authority to WEBULATOR/WBLGUCCP *PGM . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.22 DLTWBLPRF 3.1.22.1 DLTWBLPRF - Delete Webulator/400 User Profile This command provides the ability to delete an AS/400 user profile from the list of user profiles available for Webulator/400 auto signon sessions (section 2.8.1 on page 60). The parameters associated with the DLTWBLPRF command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . USER - User Name (section 4.2.82 on page 256) . UPDATE - Update executing RPs (section 4.2.89 on page 261) Authorizing a User to DLTWBLPRF A user that does not have *ALLOBJ special authority must be authorized as follows to run the DLTWBLPRF command: . *USE authority to QSYS/DLTWBLPRF *CMD . *USE authority to WEBULATOR/WBLGUDCP *PGM . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.23 WRKWBLSSN This command allows you to add, remove and change session entries within the session-based configuration file. You can also run other session-based configuration commands from this command. The parameters associated with the WRKWBLSSN command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) Page 158 Webulator/400R User Manual, Version 2.0 3.0 Com The fields associated with the WRKWBLSSN command are: . Update Executing RPs (section 4.2.89 on page 261) . Session (section 4.2.11 on page 193) 3.1.23.1 Options The following options, which can all be entered in WRKWBLSSN for a selected session, are given explanation here: Add Allows you to add one session section to the configuration file. Change Runs the CHGWBLSSN (section 3.1.24 on page 160) command. Work with limits Allows you to work with the access limits for a session entry. Work with parsed values Allows you to work with the parsed button (section 4.2.44 on page 223) values for a session entry. Work with Virtual Keyboard Allows you to work with the virtual keyboard (section 4.2.31 on page 210) values for a session entry. Change Session Secure Options Allows you to change session security values for a session. 3.1.23.2 Authorizing a User to WRKWBLSSN A user that does not have *ALLOBJ special authority must be authorized as follows to run the WRKWBLSSN command: . *USE authority to QSYS/WRKWBLSSN *CMD . *USE authority to WEBULATOR/WBLGDWCP *PGM . *USE authority to WEBULATOR/WBLGDACP *PGM . *USE authority to WEBULATOR/WBLGDDCP *PGM . *USE authority to WEBULATOR/WBLGDWP1 *PNLGRP . *USE authority to WEBULATOR/WBLGNACP *PGM . *USE authority to WEBULATOR/WBLGNDCP *PGM . *USE authority to WEBULATOR/WBLGNWCP *PGM . *USE authority to WEBULATOR/WBLGBACP *PGM . *USE authority to WEBULATOR/WBLGBDCP *PGM . *USE authority to WEBULATOR/WBLGBWCP *PGM . *USE authority to WEBULATOR/WBLGRACP *PGM . *USE authority to WEBULATOR/WBLGRDCP *PGM . *USE authority to WEBULATOR/WBLGRWCP *PGM . *USE authority to WEBULATOR/WBLGTACP *PGM . *USE authority to WEBULATOR/WBLGTDCP *PGM Page 159 Webulator/400R User Manual, Version 2.0 3.0 Com . *USE authority to WEBULATOR/WBLGTWCP *PGM . *USE authority to WEBULATOR/WBLGECPP *PGM . *USE authority to WEBULATOR/WBLGEPOP *PGM . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.24 CHGWBLSSN 3.1.24.1 CHGWBLSSN - Change Webulator/400 Session Configuration The CHGWBLSSN command provides the ability to change the Webulator/400 configuration values that reside within a Session (section 4.2.11 on page 193) entry only once. All of the Webulator/400 configuration values with multiple occurrences within a Session entry can be modified through the WRKWBLSSN (section 3.1.23 on page 158) command. The CHGWBLSSN command provides an intermediate panel which allows the user to select from the list of existing session entries. To work directly with the session entries use the WRKWBLSSN (section 3.1.23 on page 158) command provided. The parameters associated with the CHGWBLSSN command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . SESSION - Specify or select the Session (section 4.2.11 on page 193) entry within the Session Based Configuration File (section 4.2.12 on page 194) containing the single entry configuration values desired to be changed. . SIGNON - Webulator/400 Signon method (section 4.2.81 on page 254) If the Signon method is *USER then an additional value is passed within the parameter specifying the User Profile name. If the Signon method is *EXITPGM then an additional value is passed within the parameter specifying the program, library and format names. . EXTFIELD - Extended input field (section 4.2.25 on page 206) . BACKCOLOR - Background Color (section 4.2.53 on page 231) . BACKIMAGE - Background Image (section 4.2.54 on page 231) . COLORCONV - Color Conversion (section 4.2.40 on page 220) The list of values within this parameter are as follows: 1. White 2. Green Page 160 Webulator/400R User Manual, Version 2.0 3.0 Com 3. Red 4. Turquoise 5. Yellow 6. Pink 7. Blue 8. Monochrome . HEADFILE - Header File (section 4.2.56 on page 233) . FOOTFILE - Footer File (section 4.2.55 on page 232) . MENUTYPE - Menu Type (section 4.2.42 on page 222) If the Menu type is set *IMAGE then an additional value is passed within the parameter specifying the Image File Name. . TERMCOLOR - Terminal Color (section 4.2.18 on page 200) . TERMSIZE - Terminal Size (section 4.2.19 on page 200) . CONFIRM - Termination Confirmation (section 4.2.87 on page 260) . TERMURL - Termination URL (section 4.2.88 on page 260) The Termination URL description is passed as the second value within the parameter. . TERMTIME - Terminal Timeout (section 4.2.85 on page 258) . FLDPROMPT - Field Level Prompting (section 4.2.26 on page 206) . LIGHTPEN - Light Pen Image (section 4.2.27 on page 207) . HORIZRULE - Horizontal Rule Locations (section 4.2.57 on page 234) . RICHAR - Reverse Image ReplacementCharacter (section 4.2.45 on page 224) . TABENABLE - Enable Tables (section 4.2.61 on page 236) . TABWIDTH - Table Width (section 4.2.60 on page 236) . TABFONT - Table Font Name (section 4.2.59 on page 235) . SNDJAVASCR - Send Javascript (section 4.2.17 on page 199) . FONTSIZE - Initial Font Size (section 4.2.41 on page 221) . SHOWBLINE - Initial Display/Show Blank Lines (section 4.2.58 on page 234) . TERMSIGNOF - Signoff (termination) aciton (section 4.2.84 on page 258) . UPTOLOWERC - Upper to Lower Conversion (section 4.2.24 on page 205) . KBDPLUGIN - Enable Keyboard plugin (section 4.2.29 on page 208) . KBDPLUGBTN - Buttons with Keyboard plugin (section 4.2.30 on page 209) . SFLSCROLL - Subfile Scrolling Support (section 4.2.43 on page 223) . VTJOBCCSID - Virtual Terminal Job CCSID (section 4.2.28 on page 208) . VTDEVCCSID - Virtual Terminal Device CCSID (section 4.2.46 on page 225) . INPINHTIME - Input Inhibited Timeout (section 4.2.86 on page 259) Page 161 Webulator/400R User Manual, Version 2.0 3.0 Com . AUTHNAME - Authentication realm (section 4.2.4 on page 186) . AUTHTYPE - Authentication type (section 4.2.6 on page 188) . USRFILE - User file path (section 4.2.8 on page 189) . GRPFILE - Group file path (section 4.2.3 on page 185) . AUTHORDER - Authentication order (section 4.2.13 on page 195) . UPDATE - Update executing RPs (section 4.2.89 on page 261) Authorizing a User to CHGWBLSSN A user that does not have *ALLOBJ special authority must be authorized as follows to run the CHGWBLSSN command: . *USE authority to QSYS/CHGWBLSSN *CMD . *USE authority to WEBULATOR/WBLGWCCP *PGM . *USE authority to WEBULATOR/WBLGWPOP *PGM . *USE authority to WEBULATOR/WBLGDWP1 *PNLGRP . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.25 Working with Webulator/400 Virtual Keyboard Rows This option and panel provide the ability to Add, Remove, and Work with Rows of Webulator/400 Virtual Keyboard Buttons. To work directly with session entries, and to access the Work with Virtual Keyboard Rows option, use the WRKWBLSSN (section 3.1.23 on page 158) command provided. 3.1.25.1 Work with Webulator Virtual Keyboard Rows Options The following options are available on the Work with Virtual Keyboard Rows panel: 1 - Add a Row of Virtual Keyboard Buttons This panel is used to create a row of virtual keyboard buttons. The data necessary to create a row of virtual keyboard buttons is collected within this panel: . Location (section 4.2.33 on page 211) - the location the row of buttons would be presented on the browser (top - above the 5250 data, bottom - below the 5250 data) . Order (section 4.2.33 on page 211) - defines the relative position amongst with the same Location (top or bottom) specified. Page 162 Webulator/400R User Manual, Version 2.0 3.0 Com 4 - Remove a Row of Virtual Keyboard Buttons This panel is used to confirm the removal of an entire row of button entries. The panel displays all of the virtual keyboard row entries selected to be removed. 5 - Work with Virtual Keyboard Buttons The work with virtual keyboard buttons option contains 3 options of its own: Add, Change, or Remove virtual keyboard buttons within a row. The following section describes each of those options in further detail. 1 - Add a Virtual Keyboard Button This panel is used to create a virtual keyboard button. The data necessary to create virtual keyboard button is collected within this panel: . Key Name (section 4.2.31 on page 210) - The name of the key value to be executed when the button is pushed. . Key Sequence - The location within the row of buttons that the button will be added. Each existing button contains a sequence number which identifies the location the virtual keyboard button exists with the virtual keyboard row. The number specified for the Key Sequence value must fall between the existing button sequences. If a virtual keyboard button already exists for the value specified, the key will be added immediately after the virtual keyboard button which currently contains the Key Sequence value. . Description (section 4.2.31 on page 210) - The description placed on the button when displayed in the browser. 2 - Change a Virtual Keyboard Button This panel is used to change a virtual keyboard button. 4 - Remove a Virtual Keyboard Button This panel is used to confirm the removal of a button entry. The panel displays all of the virtual keyboard button entries selected to be removed. 3.1.26 WRKWBLPRF 3.1.26.1 WRKWBLPRF - Work with Webulator/400 User Profiles This command lists the current AS/400 user profiles configured to be used for Webulator/400 auto signon sessions (section 2.8.1 on page 60). This command along with ADDWBLPRF (section 3.1.20 on page 157), CHGWBLPRF (section 3.1.21 on page 157), and DLTWBLPRF (section 3.1.22 on page 158) commands can be used to Add, Change, Delete, and Display Webulator/400 auto signon user profiles. Page 163 Webulator/400R User Manual, Version 2.0 3.0 Com The parameters associated with the WRKWBLPRF command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) Authorizing a User to WRKWBLPRF, and Other Related Commands A user that does not have *ALLOBJ special authority must be authorized as follows to run the WRKWBLPRF command: . *USE authority to QSYS/WRKWBLPRF *CMD . *USE authority to QSYS/ADDWBLPRF *CMD . *USE authority to QSYS/CHGWBLPRF *CMD . *USE authority to QSYS/DLTWBLPRF *CMD . *USE authority to WEBULATOR/WBLGPACP *PGM . *USE authority to WEBULATOR/WBLGPCCP *PGM . *USE authority to WEBULATOR/WBLGPDCP *PGM . *USE authority to WEBULATOR/WBLGPWCP *PGM . *USE authority to WEBULATOR/WBLGPWP1 *PNLGRP . *USE authority to WEBULATOR/WBLGHCMD *PNLGRP . *USE authority to WEBULATOR/WBLGHPN1 *PNLGRP . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.27 CHGWBLSEC This command allows you to change Webulator/400 configuration entries. The parameters associated with the CHGWBLSEC command are: . CFGFILE - Master Configuration File (section 5.2.3 on page 265) . KEYFILE - Key file (section 4.2.62 on page 237) . SSLPORT - SSL Port number (section 4.2.65 on page 239) . CACHETIME - Session Cache timeout (section 4.2.64 on page 238) . CACHESIZE - Session Cache size (section 4.2.63 on page 238) . SSLVER - SSL Server Version (section 4.2.66 on page 240) . UPDATE - Update executing RPs (section 4.2.89 on page 261) 3.1.27.1 Authorizing a User to CHGWBLSEC A user that does not have *ALLOBJ special authority must be authorized as follows to run the CHGWBLSEC command: . Added to the WEBULATOR product authorization list. or Page 164 Webulator/400R User Manual, Version 2.0 3.0 Com . *USE authority to QSYS/CHGWBLSEC *CMD . *USE authority to WEBULATOR/WWWGECPO *PGM . *USE authority to WEBULATOR/WWWGECPP *PGM . *USE authority to WEBULATOR/WWWGHPN1 *PNLGRP . *USE authority to WEBULATOR/WWWGHCMD *PNLGRP and . *CHANGE authority to server configuration files (section 5.1 on page 263) 3.1.28 CRTWBLKEY 3.1.28.1 CRTWBLKEY - Create Commerce Keys The CRTWBLKEY command is used to create two files that are needed by Webulator/400 to support SSL encryption. Keylist File (KEYFILE on page 167) CRTWBLKEY generates and stores the server's private and public keys in an encrypted file called the keylist file (section 4.2.62 on page 237). The keylist file is also used to store the server certificate. The server requires this file when processing secure (section 4.2.75 on page 249) (i.e., SSL) ports. SSL (section 4.2.65 on page 239) cannot be processed until the signed server certificate, returned by the certification authority, is added to the keylist file with the ADDWBLCERT (section 3.1.29 on page 168). IMPORTANT: Make a backup copy of the keylist file after it is successfully created. The backup will be needed if there is a problem adding the correct signed server certificate to the keylist file. Also, the keylist file is an encrypted binary file and other tools/editors should not be used to try to view or manipulate the keylist file. Certificate Request File (CERTFILE on page 167) The certificate request file contains formatted data (i.e., *PKCS10 format) that is required by a certification authority. The contents of the certificate request file is sent to the certification authority for signing. Server certificates will generally expire in a year which means the CRTWBLKEY command will need to be run yearly. When generating new files (i.e., keylist and certificate request) either create a new directory for the new files or simply change the file names. Page 165 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1.28.2 CRTWBLKEY Parameters NAME - Distinguished Name This is the distinguished name of the site and AS/400 running Webulator/400. The name is used in Internet commerce to distinguish one server from another across all organizations. The distinguished name is bound by the certification authority with the generated public and private keys. The certification authority may reject the certificate request if the information is insufficient or incorrect. The distinguished name is composed of six parts: 1. Common Name The common name is a required parameter that must be set to the fully qualified domain/host name of the server. Some browsers will only process commerce transactions if the server's common name is the same as the host name in the URL. For example, www.inetmi.com 2. Organization Name of the organization, company or individual that is hosting the Commerce Server. The organization name should be a non-abbreviated, legal name that is properly registered with a governmental unit. This parameter is required. For example, I/NET, Inc. 3. Country Code Required country in which the company or organization is located. This value must be the 2- character code for the country (e.g., United States is 'US', Canada is 'CA'). If you do not know your country code, contact your certification authority. 4. Organizational Unit Optional organizational unit or company division/department. Also for Doing Business As... names. The unit should not be abbreviated. For example, Internet Division 5. Locality Optional locality (e.g., city) of the company or organization. Required for organizations registered only at the local level. If the locality is specified the state or province must also be specified. For example, Kalamazoo 6. State or Province State or Province in which the company or organization is located. In most cases the state or province should be provided. This parameter must be specified if locality is specified. Contact your Page 166 Webulator/400R User Manual, Version 2.0 3.0 Com certification authority for help in determining if the state or province is required. The state or province must not be an abbreviated value (i.e., do not use 'MI', use 'Michigan'). PASSWORD - Password Password that is required to encrypt the server's keylist file. The password must be at least 8 characters in length and should follow good password guidelines (e.g., no repeating characters, use both letters and numbers). The same value must be passed into the STRWBL (PASSWORD on page 137) command when starting a Commerce Server that is using the created keylist file. If a case-sensitive password is desired the password must be enclosed in single quotes. KEYFILE - Keylist File Specifies the full-path to the keylist file (section 4.2.62 on page 237) that will be created. This file must not exist. The keylist file stores the public and private keys and the server certificate used by Webulator/400. Ensure that only authorized users have access to the keylist file. The server user profile must have access to read the keylist file. The default keylist file is '/Wbl/Key/KeyList.Cfg'. This file must be created in either the IFS root file system or the QDLS (shared folders) file system. It cannot be created in QSYS. IMPORTANT: Make a backup copy of the keylist file after it is successfully created. The backup will be needed if there is a problem adding the correct signed server certificate to the keylist file. CERTFILE - Certificate Request File Specifies the full-path to the certificate request file that will be created. This file must not exist. The certificate request file contains formatted data (i.e., *PKCS10 format), which includes the entered distinguished name, that is required by a certification authority. The certificate request must be sent (e.g., cut-and-paste into an e-mail message) to a certification authority to be signed. The default certificate request file is '/Wbl/Key/CertRqs.Txt'. This file must be created in either the IFS root file system or the QDLS (shared folders) file system. It cannot be created in QSYS. After the signed certificate is returned from the certification authority it must be added to the keylist file using the ADDWBLCERT (section 3.1.29 on page 168) command. Page 167 Webulator/400R User Manual, Version 2.0 3.0 Com RSABITS - RSA Encryption Bits The number of bits in the modulus value to be used by the RSA encryption algorithm. Increasing the number of bits increases the security of the data and the time required by the server to process encrypted data. Under most circumstances use the default value of 1024 (512 for the exported version). The exported version supports a maximum of 512. WEEKS - Number of Weeks Valid The number of weeks the generated public and private keys are valid. Due to rapid advances in computer technology the keys should be regenerated every few years. Under most circumstances use the default value. This must be a value between 1 and 260. The default value is 1 year. 3.1.28.3 Authorizing a User to CRTWBLKEY A user that does not have *ALLOBJ special authority must be authorized as follows to run the CRTWBLKEY command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/CRTWBLKEY *CMD . *USE authority to WEBULATOR/WBLEKCPP *PGM and . Read authority to the files in the /Wbl/Key/Digest directory. . If the default parameters are used, write authority to the /Wbl/Key directory. 3.1.29 ADDWBLCERT 3.1.29.1 ADDWBLCERT - Add Secure Certificate The ADDWBLCERT command is used to add a signed server certificate to a specified keylist file (section 4.2.62 on page 237). Webulator/400 can be configured (section 4.2.75 on page 249) to secure data, using SSL (section 4.2.65 on page 239), once the signed server certificate is added to the keylist file. After the signed server certificate is successfully added to the keylist file, you must use the CHGWBLSEC (section 3.1.27 on page 164) command to set the server's keylist file (KEYFILE on page 169). For example, CHGWBLSEC KEYFILE('/Wbl/Key/KeyList.Cfg') Page 168 Webulator/400R User Manual, Version 2.0 3.0 Com IMPORTANT: Make a backup copy of the keylist file after the server certificate is successfully added. If something should happen to the original (e.g., deleted, damaged) the backup would then be used. Most certification authorities will charge additional money to re-create the server certificate for a new keylist file. 3.1.29.2 ADDWBLCERT Parameters CERTFILE - Signed Certificate File Specifies the full-path to the file that contains the signed certificate. The signed certificate is returned from a certification authority after sending the certification authority the certificate request generated by the CRTWBLKEY (section 3.1.28 on page 165) command. Copy the signed certificate into a file that is in either the IFS root or QDLS AS/400 file system. The certificate data must be in the Public-Key Cryptography Standards format (i.e., *PKCS6 format). A *PKCS6 certificate is also referred to as a X.509 public key certificate. There must be a header line that begins with 5 dashes and "BEGIN" before the certificate data (i.e., -----BEGIN). This is the default format. The data in the file is assumed to be ASCII data in CCSID 819. PASSWORD - Password The current password used to encrypt the server's keylist file. The keylist file password was initially set with the CRTWBLKEY (section 3.1.28 on page 165) command. The password can be changed with the CHGWBLKPWD (section 3.1.30 on page 170) command. If the password is case- sensitive it must be enclosed in single quotes. KEYFILE - Keylist File Specifies the full-path to the keylist file (section 4.2.62 on page 237) that was created with the CRTWBLKEY (section 3.1.28 on page 165) command. The keylist file stores the public and private keys and certificates used by Webulator/400. Ensure that only authorized users have access to the keylist file. The server user profile must have access to read the keylist file. The default keylist file is '/Wbl/Key/KeyList.Cfg'. IMPORTANT: Make a backup copy of the keylist file after the server certificate is successfully added. If something should happen to the original (e.g., deleted, damaged) the backup would then be used. Most certification authorities will charge additional money to re-create the server certificate for a new keylist file. Page 169 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1.29.3 Authorizing a User to ADDWBLCERT A user that does not have *ALLOBJ special authority must be authorized as follows to run the ADDWBLCERT command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/ADDWBLCERT *CMD . *USE authority to WEBULATOR/WBLEACPP *PGM 3.1.30 CHGWBLKPWD 3.1.30.1 CHGWBLKPWD - Change Keylist File Password The CHGWBLKPWD command is used to change the password that is protecting a Webulator/400 keylist file (section 4.2.62 on page 237). The keylist file password cannot be changed until the keylist file contains a signed server certificate, which is added with the ADDWBLCERT (section 3.1.29 on page 168) command. IMPORTANT: Do not change the keylist file password if there is a server currently running that is using the keylist file. 3.1.30.2 CHGWBLKPWD Parameters CURPWD - Current Password The current password used to encrypt the server's keylist file. The keylist file password was initially set with the CRTWBLKEY (section 3.1.28 on page 165) command. If the password is case-sensitive it must be enclosed in single quotes. NEWPWD - New Password The new password to use to encrypt the server's keylist file. The password must be at least 8 characters in length and should follow good password guidelines (e.g., no repeating characters, use both letters and numbers). The same value must be passed into the STRWBL command when starting a server that is using the keylist file. If a case-sensitive password is desired the password must be enclosed in single quotes. VERPWD - New Password (to Verify) Enter the new password again to verify you have entered the new password correctly. This value must match the entered new password or the password is not changed. KEYFILE - Keylist File Specifies the full-path to the keylist file (section 4.2.62 on page 237) that is being changed. Page 170 Webulator/400R User Manual, Version 2.0 3.0 Com The default keylist file is '/Wbl/Key/KeyList.Cfg'. IMPORTANT: Make a backup copy of the keylist file after the password is successfully changed. If something should happen to the original (e.g., deleted, damaged) the backup would then be used. 3.1.30.3 Authorizing a User to CHGWBLKPWD A user that does not have *ALLOBJ special authority must be authorized as follows to run the CHGWBLKPWD command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/CHGWBLKPWD *CMD . *USE authority to WEBULATOR/WBLEPCPP *PGM 3.1.31 ADDWBLROOT 3.1.31.1 ADDWBLROOT - Add Commerce Trusted Root The ADDWBLROOT command is used to add a trusted root to a specified keylist file (section 4.2.62 on page 237). You will need to add a trusted root for your certifying authority if you will be obtaining a signed server certificate from a vendor other than VeriSign. Since the trusted root file must be in a specific format to be successfully added, you must contact your distributor to obtain a valid trusted root file for your certifying authority. IMPORTANT: Make a backup copy of the keylist file after the trusted root is successfully added. If something should happen to the original (e.g., deleted, damaged) the backup would then be used. 3.1.31.2 ADDWBLROOT Parameters ROOTFILE - Trusted Root File Specifies the full-path to the file that contains the trusted root for your certifying authority. You must contact your distributor to obtain a trusted root file that is in the required format. PASSWORD - Password The current password used to encrypt the server's keylist file. The keylist file password was initially set with the CRTWBLKEY (section 3.1.28 on page 165) command. The password can be changed with the CHGWBLKPWD (section Page 171 Webulator/400R User Manual, Version 2.0 3.0 Com 3.1.30 on page 170) command. If the password is case- sensitive it must be enclosed in single quotes. KEYFILE - Keylist File Specifies the full-path to the keylist file (section 4.2.62 on page 237) that was created with the CRTWBLKEY (section 3.1.28 on page 165) command. The keylist file stores the public and private keys, server certificate, and trusted roots used by Webulator/400. Ensure that only authorized users have access to the keylist file. The server user profile must have access to read the keylist file. The default keylist file is '/WBL/Key/KeyList.Cfg'. IMPORTANT: Make a backup copy of the keylist file after the trusted root is successfully added. If something should happen to the original (e.g., deleted, damaged) the backup would then be used. 3.1.31.3 Authorizing a User to ADDWBLROOT A user that does not have *ALLOBJ special authority must be authorized as follows to run the ADDWBLROOT command: . Added to the WEBULATOR product authorization list. or . *USE authority to QSYS/ADDWBLROOT *CMD . *USE authority to WEBULATOR/WBLERCPP *PGM Page 172 Webulator/400R User Manual, Version 2.0 4.0 Con 4. Configuration Values Page 173 Webulator/400R User Manual, Version 2.0 4.0 Con 4.1 All configuration values by category Also see alphabetical index of values (section 4.2 on page 178) 4.1.1 Access Control . Allow hosts (section 4.2.1 on page 182) . Authentication group entry (section 4.2.2 on page 184) . Authentication group file (section 4.2.3 on page 185) . Authentication realm name (section 4.2.4 on page 186) . Authentication password storage (section 4.2.5 on page 187) . Authentication type (section 4.2.6 on page 188) . Authentication user entry (section 4.2.7 on page 188) . Authentication user file (section 4.2.8 on page 189) . Deny hosts (section 4.2.9 on page 190) . Session section end (section 4.2.10 on page 192) . Session section start (section 4.2.11 on page 193) . Session based configuration file path (section 4.2.12 on page 194) . Authentication Order (section 4.2.13 on page 195) . Require user authentication (section 4.2.14 on page 196) 4.1.2 Aliases . Alias (section 4.2.15 on page 197) . Alias file path (section 4.2.16 on page 198) 4.1.3 Device Capabilities . Send Javascript (section 4.2.17 on page 199) . Terminal Color (section 4.2.18 on page 200) . Terminal Size (section 4.2.19 on page 200) 4.1.4 Document Locations . Server root path (section 4.2.20 on page 201) . Fall-thru path for HTTP (section 4.2.21 on page 202) . Fall-thru path for SSL (section 4.2.22 on page 203) . Keyboard Plugin Location (section 4.2.23 on page 204) Page 174 Webulator/400R User Manual, Version 2.0 4.0 Con 4.1.5 Input Fields . Convert Uppercase to Lowercase (section 4.2.24 on page 205) . Extended Input Field (section 4.2.25 on page 206) . Field Level Prompting (section 4.2.26 on page 206) . Light Pen Image (section 4.2.27 on page 207) . Virtual Terminal Job CCSID (section 4.2.28 on page 208) 4.1.6 Keyboard Functionality . Keyboard Plugin (section 4.2.29 on page 208) . Keyboard Plugin Buttons (section 4.2.30 on page 209) . Virtual Keyboard Button (section 4.2.31 on page 210) . Virtual Keyboard Row End (section 4.2.32 on page 210) . Virtual Keyboard Row Start (section 4.2.33 on page 211) 4.1.7 Logs . Access log cycle (section 4.2.35 on page 213) . Access log file path (section 4.2.36 on page 215) . Error log cycle (section 4.2.37 on page 216) . Error log file path (section 4.2.38 on page 218) . Error logging level (section 4.2.39 on page 219) 4.1.8 Output Fields . Color Conversion (section 4.2.40 on page 220) . Font Size (section 4.2.41 on page 221) . Menu Type (section 4.2.42 on page 222) . Subfile Scrolling Hot Spots (section 4.2.43 on page 223) . Parsed Button (section 4.2.44 on page 223) . Reverse Image Space Character (section 4.2.45 on page 224) . Virtual Terminal Device CCSID (section 4.2.46 on page 225) 4.1.9 Request Processing . Connection queue size (section 4.2.47 on page 226) . Initial request processors (section 4.2.48 on page 226) . Maximum request processors (section 4.2.49 on page 227) . Request wait timeout (section 4.2.50 on page 228) . Timeout (section 4.2.51 on page 229) Page 175 Webulator/400R User Manual, Version 2.0 4.0 Con . Automatic RP Timeout (section 4.2.52 on page 230) 4.1.10 Screen Appearance . Background Color (section 4.2.53 on page 231) . Background Image (section 4.2.54 on page 231) . Footer File (section 4.2.55 on page 232) . Header File (section 4.2.56 on page 233) . Horizontal Rule Location (section 4.2.57 on page 234) . Show Blank Lines (section 4.2.58 on page 234) . Table Font Name (section 4.2.59 on page 235) . Table Width (section 4.2.60 on page 236) . Tables Enabled (section 4.2.61 on page 236) 4.1.11 Secure Support . Secure Key List File Path (section 4.2.62 on page 237) . Secure Session Cache Size (section 4.2.63 on page 238) . Secure Session Cache Timeout (section 4.2.64 on page 238) . Secure SSL port (section 4.2.65 on page 239) . SSL Version (section 4.2.66 on page 240) 4.1.12 Server Administration . AllowedProtocols (section 4.2.67 on page 241) . Content CCSID (section 4.2.68 on page 242) . Disable server (section 4.2.69 on page 242) . Domain name lookup (section 4.2.70 on page 243) . Initial library list (section 4.2.71 on page 245) . Multiple home (section 4.2.72 on page 245) . Server host name (section 4.2.73 on page 247) . Server identifier (section 4.2.74 on page 248) . Server protocols (section 4.2.75 on page 249) . Server user profile (section 4.2.76 on page 250) . Socket port (section 4.2.77 on page 251) . Temporary directory (section 4.2.78 on page 252) 4.1.13 Session Support . Maximum Sessions (section 4.2.79 on page 253) . Webulator User Profile File Path (section 4.2.80 on page 253) Page 176 Webulator/400R User Manual, Version 2.0 4.0 Con 4.1.14 Signon Control . Signon Method (section 4.2.81 on page 254) . Webulator/400 user entry (section 4.2.82 on page 256) . Webulator/400 user file path (section 4.2.80 on page 253) 4.1.15 Termination . Signoff Action (section 4.2.84 on page 258) . Terminal Timeout (section 4.2.85 on page 258) . Input Inhibited Timeout (section 4.2.86 on page 259) . Termination Confirmation (section 4.2.87 on page 260) . Termination URL (section 4.2.88 on page 260) Page 177 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2 All configuration values in alphabetical order Also see configuration values by category (section 4 on page 173) (section 4.2.32 on page 210) Session virtual keyboard row end (section 4.2.33 on page 211) Session virtual keyboard row start (section 4.2.10 on page 192) Session section end (section 4.2.11 on page 193) Session section start AccessLog (section 4.2.36 on page 215) Access log file path AccessLogCycle (section 4.2.35 on page 213) Access log cycle Alias (section 4.2.15 on page 197) Configures an alias AliasCfgFile (section 4.2.16 on page 198) Alias file path Allow (section 4.2.1 on page 182) Allow hosts AllowedProtocols (section 4.2.67 on page 241) Allowed Protocols AuthGroupFile (section 4.2.3 on page 185) Authentication group file AuthName (section 4.2.4 on page 186) Authentication realm name AuthType (section 4.2.6 on page 188) Authentication type AuthUserFile (section 4.2.8 on page 189) Authentication user file AutoRPTime Automatic RP Timeout BackgroundColor (section 4.2.53 on page 231) Session background color Page 178 Webulator/400R User Manual, Version 2.0 4.0 Con BackgroundImage (section 4.2.54 on page 231) Session background image ColorConversion (section 4.2.40 on page 220) Session color conversion CommerceKeyListFile (section 4.2.62 on page 237) Secure Key List File Path CommerceSessionCacheSize (section 4.2.63 on page 238) Secure Session Cache Size CommerceSessionCacheTimeout (section 4.2.64 on page 238) Secure Session Cache Timeout CommerceSSLPort (section 4.2.65 on page 239) Secure SSL Port ConnectionQueueSize (section 4.2.47 on page 226) Connection queue size ContentCCSID (section 4.2.68 on page 242) Content CCSID Deny (section 4.2.9 on page 190) Deny hosts DisableServer (section 4.2.69 on page 242) Disable server DomainNameLookup (section 4.2.70 on page 243) Domain name lookup EnableKeyboardPlugin (section 4.2.29 on page 208) Session enable keyboard plugin ErrorLog (section 4.2.38 on page 218) Error log file path ErrorLogCycle (section 4.2.37 on page 216) Error log cycle ErrorLogLevel (section 4.2.39 on page 219) Error logging level ExtendedInputField (section 4.2.25 on page 206) Session extended input field FallThruRootHTTP Fall-thru path for HTTP FallThruRootSSL Fall-thru path for SSL Page 179 Webulator/400R User Manual, Version 2.0 4.0 Con FieldLevelPrompting (section 4.2.26 on page 206) Session field level prompting FontSize (section 4.2.41 on page 221) Session font size FooterFile (section 4.2.55 on page 232) Session footer file GlobalAccessCfgFile (section 4.2.12 on page 194) Session based configuration file path HeaderFile (section 4.2.56 on page 233) Session header file HorizontalRuleLocation (section 4.2.57 on page 234) Session horizontal rule locations InitialLibraryList (section 4.2.71 on page 245) Initial Library List InitialRPs (section 4.2.48 on page 226) Initial request processors KbdPluginLoc Keyboard Plugin location LightPenImage (section 4.2.27 on page 207) Session light pen image URL MaxRPs (section 4.2.49 on page 227) Maximum request processors MaxWebulatorSessions (section 4.2.79 on page 253) Maximum sessions MenuType (section 4.2.42 on page 222) Session menu type MultiHome (section 4.2.72 on page 245) Multiple home Order (section 4.2.13 on page 195) Authentication Order ParsedButton (section 4.2.44 on page 223) Session parsed button definition PasswordStorage (section 4.2.5 on page 187) Authentication Password Storage Port (section 4.2.77 on page 251) Socket Port Page 180 Webulator/400R User Manual, Version 2.0 4.0 Con Require (section 4.2.14 on page 196) Require user authentication ReverseImageSpaceCharacter (section 4.2.45 on page 224) Session reverse image space character RowBtn (section 4.2.31 on page 210) Session virtual keyboard button SendJavaScript (section 4.2.17 on page 199) Session send Javascript ServerHostName (section 4.2.73 on page 247) Server host name ServerIdentifier (section 4.2.74 on page 248) Server Identifier ServerProtocols (section 4.2.75 on page 249) Server Protocols ServerRoot (section 4.2.20 on page 201) Server root path ShowBlankLines (section 4.2.58 on page 234) Session show blank lines ShowKeyboardPluginButtons (section 4.2.30 on page 209) Session show keyboard plugin buttons Signon (section 4.2.81 on page 254) Session sign-on method SslVersion (section 4.2.66 on page 240) SSL Version SubfileScrolling (section 4.2.43 on page 223) Session subfile scrolling hotspots TablesEnabled (section 4.2.61 on page 236) Session allow tables TableFontName (section 4.2.59 on page 235) Session table font name TableWidth (section 4.2.60 on page 236) Session table width TemporaryDirectory (section 4.2.78 on page 252) Temporary Directory TermColor (section 4.2.18 on page 200) Session terminal color Page 181 Webulator/400R User Manual, Version 2.0 4.0 Con TermDeviceCCSID (section 4.2.46 on page 225) Session interactive terminal device CCSID TermInhibitedTimeout (section 4.2.86 on page 259) Session input inhibited timeout TermJobCCSID (section 4.2.28 on page 208) Session interactive terminal job CCSID TermSize (section 4.2.19 on page 200) Session terminal size/type TermTimeout (section 4.2.85 on page 258) Session terminal timeout TerminateUponSignoff (section 4.2.84 on page 258) Session signoff (termination) action TerminationConfirmation (section 4.2.87 on page 260) Session termination confirmation TerminationUrl (section 4.2.88 on page 260) Session termination URL Timeout (section 4.2.51 on page 229) Timeout UpperToLowerConvert (section 4.2.24 on page 205) Session upper to lower conversion UserProfile (section 4.2.76 on page 250) Server user profile WaitThreshold (section 4.2.50 on page 228) Request wait timeout WebulatorUsrFile (section 4.2.80 on page 253) Webulator user file path 4.2.1 Allow Hosts 4.2.1.1 Description Specifies hosts which are allowed. In general, if a host has not been specifically denied by a deny (section 4.2.9 on page 190) directive, it will be allowed. Therefore, this is used to override a deny directive, either in the session, or in a parent session. 4.2.1.2 Parameters One or more hosts, each of which may be any one of the following: Page 182 Webulator/400R User Manual, Version 2.0 4.0 Con all Any host is allowed. Domain name A name that begins with a dot (e.g. .inetmi.com). The server will attempt to match the domain name with the last part of the client's host name. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get a host name for the client. Host name A name that does not begin with a dot (e.g. xyz.inetmi.com) The server will attempt to match the host name exactly with the client's host name. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get a host name for the client. Partial IP address First one to three bytes of an IP address for subnet restriction (e.g. 123.456.789). The server will attempt to match the partial IP address with the first part of the client's IP address. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get the IP address for the client. Full IP address All four bytes of an IP address (e.g. 111.222.333.444). The server will attempt to match the full IP address exactly with the client's IP address. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get the IP address for the client. Of the above ways to specify a host, the partial and full IP address is more secure than the host name and domain name. It would be harder for a client to intentionally return a wrong IP address than it would be to return a wrong host name. In addition to the problems with intentionally wrong host names, it may be that the client returns a wrong host name for other reasons, such as accessing the server through a firewall. 4.2.1.3 Default If No Entry Found There is no default for this directive. 4.2.1.4 Command To Work With This Value . WRKWBLSSN (section 3.1.23 on page 158) option 6 Page 183 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.1.5 File Syntax allow from host [host] ... This directive is only valid within a session section in the session based configuration file (section 5.2.5 on page 268) More than one entry may exist in a session section. If more than one entry is found, it will be as if all hosts on all allow from lines had been listed on the same line. 4.2.1.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.2 Authentication Group Entry 4.2.2.1 Description Specifies a group name and user members which will be checked by Webulator/400 during user authentication (User authentication on page 99). The group can then appear in a require entry (section 4.2.14 on page 196). 4.2.2.2 Parameters Name This is the group name that must be specified on a require entry. Members This is a list of user names. The names are space- separated. Each name should appear in a user entry (section 4.2.7 on page 188). 4.2.2.3 Commands To Change This Value There are no commands to change group entries. The user authentication group configuration file (section 5.2.8 on page 270) must be edited directly. 4.2.2.4 File Syntax Name: Members Multiple entries may exist in the user authentication group configuration file (section 5.2.8 on page 270). Page 184 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.2.5 Also See . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.3 Authentication Group File Configuration 4.2.3.1 Description Specifies the group file to use when processing user authentications. 4.2.3.2 Parameters The name of the file that contains groups. Each line in the file will consist of one group name followed by a colon (':') and then user names which belong to the group. More than one user name can be on the same line as long as there is a space separating all user names. If the same group appears on more than one line, all user names on all lines containing the group will be considered a part of the group. 4.2.3.3 Default If No Entry Found If there is no group file specified, authentication using groups is not allowed. 4.2.3.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) GRPFILE('/Wbl/Cfg/group.cfg') 4.2.3.5 File Syntax AuthGroupFile GroupFile Each group file entry must be within a session section. If more than one group file is specified in the same session section, the last entry will be used for that session. When processing requires involving groups, only one group file will be used. The one used will be the one that is nearest (and farthest from the root) to the session for which access is being evaluated. 4.2.3.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) Page 185 Webulator/400R User Manual, Version 2.0 4.0 Con . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.4 Authentication Realm Name Configuration 4.2.4.1 Description Specifies the name of the current authorization realm. This will be passed back to the browser if authentication fails for display to the user. 4.2.4.2 Parameters The name to be displayed to the user by the browser. 4.2.4.3 Default If No Entry Found If there is no realm name specified, user authentication is not allowed. 4.2.4.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) AUTHNAME(ThisRealm) 4.2.4.5 File Syntax AuthName RealmName Each realm name entry must be within a session section. If more than one realm name is specified in the same session section, the last entry will be used for that session. When processing failed requires, only one realm name will be used. The one used will be the one that is nearest (and farthest from the root) to the session for which access is being evaluated. 4.2.4.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) Page 186 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.5 Authentication Password Storage 4.2.5.1 Description The way that user passwords are stored has changed starting with Web Server/400 version 1.3. The Web Server can be configured to use either the new mode or the old mode (for backward compatibility). 4.2.5.2 Parameters Mode Where Mode can be Normalized or Compatible. Normalized mode allows for case-insensitive password matching and is better for users configuring the server with different CCSIDs. Compatible mode is necessary for servers that contain passwords that have been migrated from Web Server/400 and were created prior to version 1.3 of Web Server/400. Read about authentication user storage (section 2.9.4 on page 100) for more information about modes. 4.2.5.3 Default If No Entry Found Compatible 4.2.5.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) PSWSTG(*Normalized) 4.2.5.5 File Syntax PasswordStorage Mode Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.5.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) Page 187 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.6 Authentication Type Configuration 4.2.6.1 Description Specifies the authentication type. 4.2.6.2 Parameters Basic This is the only authentication type currently supported. 4.2.6.3 Default If No Entry Found If there is no authentication type specified, user authentication is not allowed. 4.2.6.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) AUTHTYPE(*BASIC) 4.2.6.5 File Syntax AuthType Basic Each authentication type entry must be within a session section. If more than one authentication type is specified in the same session section, the last entry will be used for that session. When the server is processing requires, only one authentication type will be used. The one used will be the one that is nearest (and farthest from the root) to the session for which access is being evaluated. 4.2.6.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.7 Authentication User Entry 4.2.7.1 Description Specifies a user name and password which will be checked by Webulator/400 during user authentication (User authentication on page 99). The user can then appear in an authentication group entry (section 4.2.2 on page 184) or as part of a require entry (section 4.2.14 on page 196). Page 188 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.7.2 Parameters Name This is the name that the user must type in to receive access. It is case sensitive. Password This is the password that the user must type in to receive access. It is case sensitive. Because the password is hashed using the RSA Data Security, Inc. MD5 Message-Digest Algorithm, you should use configuration commands (Configuration Commands on page 134) to change this file, and not edit it directly. 4.2.7.3 Commands To Change This Value . ADDWBLAUT (section 3.1.15 on page 154) USER(Name) PASSWORD(Password) . CHGWBLAUT (section 3.1.16 on page 154) USER(Name) PASSWORD(Password) . DLTWBLAUT (section 3.1.17 on page 154) USER(Name) 4.2.7.4 File Syntax Name: Hashed-Password Multiple entries may exist in the user authenticaton user configuration file (section 5.2.6 on page 269). 4.2.7.5 Also See . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.8 Authentication User File Configuration 4.2.8.1 Description Specifies the user file to use when processing user authentications. 4.2.8.2 Parameters FileName The name of the file that contains users. Each line in the file will consist of one user name followed by a Page 189 Webulator/400R User Manual, Version 2.0 4.0 Con colon (':') and then the user's password. This parameter is required. FileType This optional parameter can be either Stream or Database. If not specified, Stream will be used. Authentication User Storage (section 2.9.4 on page 100) has more information about this. 4.2.8.3 Default If No Entry Found If there is no user file specified, user authentication is not allowed. 4.2.8.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) USRFILE('/Wbl/Cfg/users.cfg') 4.2.8.5 File Syntax AuthUserFile FileName FileType Each user file entry must be within a session section. If more than one user file is specified in the same session section, the last entry will be used for that session. When processing requires, only one user file will be used. The one used will be the one that is nearest (and farthest from the root) to the session for which access is being evaluated. 4.2.8.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.9 Deny Hosts 4.2.9.1 Description Specifies hosts which are denied. In general, if a host has not been specifically denied, it will be allowed. Also see the allow hosts (section 4.2.1 on page 182) directive. 4.2.9.2 Parameters One or more hosts, each of which may be any one of the following: Page 190 Webulator/400R User Manual, Version 2.0 4.0 Con all Any host is denied. Domain name A name that begins with a dot (e.g. .inetmi.com). The server will attempt to match the domain name with the last part of the client's host name. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get a host name for the client. Host name A name that does not begin with a dot (e.g. xyz.inetmi.com) The server will attempt to match the host name exactly with the client's host name. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get a host name for the client. Partial IP address First one to three bytes of an IP address for subnet restriction (e.g. 123.456.789). The server will attempt to match the partial IP address with the first part of the client's IP address. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get the IP address for the client. Full IP address All four bytes of an IP address (e.g. 111.222.333.444). The server will attempt to match the full IP address exactly with the client's IP address. For this to work, Domain name lookup (section 4.2.70 on page 243) must be configured to get the IP address for the client. Of the above ways to specify a host, the partial and full IP address is more secure than the host name and domain name. It would be harder for a client to intentionally return a wrong IP address than it would be to return a wrong host name. In addition to the problems with intentionally wrong host names, it may be that the client returns a wrong host name for other reasons, such as accessing the server through a firewall. 4.2.9.3 Default If No Entry Found There is no default for this directive. 4.2.9.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) option 6 Page 191 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.9.5 File Syntax deny from host [host] ... This directive is only valid within a session section in the session based configuration file (section 5.2.5 on page 268) More than one entry may exist in a session section. If more than one entry is found, it will be as if all hosts on all deny from lines had been listed on the same line. 4.2.9.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.10 Session Section End 4.2.10.1 Description Ends a session section which was started by the (section 4.2.11 on page 193) directive. All directives inside a session section apply to the current session and sub-sessions. 4.2.10.2 Parameters No parameters are required for this directive. 4.2.10.3 Default If No Entry Found There is no default for this directive. 4.2.10.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) 4.2.10.5 File Syntax Each entry in the session based configuration file (section 5.2.5 on page 268) must have a matching entry. Session sections cannot be nested (i.e. A session start must be followed by a session end before another session start is found). Page 192 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.10.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.11 Session Section Start 4.2.11.1 Description Starts a session section, which must be ended by the (section 4.2.10 on page 192) directive. All directives inside a session section apply to the current session and any sub-sessions. 4.2.11.2 Parameters A path relative to the root of the server where the Webulator/400 root is the meta path "/". Webulator/400 is a meta object, meaning that it does not represent anything within IFS, but another resource that can be served, protected and/or configured. All directives inside this session section will apply to the session and all sub- sections. 4.2.11.3 Default If No Entry Found There is no default for this directive 4.2.11.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) 4.2.11.5 File Syntax An unlimited number of session sections may be specified in the session based configuration file (section 5.2.5 on page 268). Each session section consists of a session section start, followed by other directives, followed by a session section end. Session sections may not be nested (i.e. one session section must be ended before another can be started). 4.2.11.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) Page 193 Webulator/400R User Manual, Version 2.0 4.0 Con . Alphabetical index of values (section 4.2 on page 178) 4.2.12 Session Based Configuration File Path 4.2.12.1 Description Specifies the location of the session based configuration file (section 5.2.5 on page 268). 4.2.12.2 Parameters File Location of the session based configuration file. If a leading slash is specified in the path, it will be treated as an absolute path name. If no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). CCSID A CCSID to use instead of the codepage associated with the file. This allows mixed byte data to be stored in this file, even though IFS does not support tagging files as mixed byte. If this entry is missing, the server will not attempt to read a session based configuration file and all hosts will be allowed access. 4.2.12.3 Default If No Entry Found If there is no entry for this, the default will be blank. 4.2.12.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) ACCGBLFILE('') 4.2.12.5 File Syntax GlobalAccessCfgFile File CCSID Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.12.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) Page 194 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.13 Order 4.2.13.1 Description Specifies the order in which allow (section 4.2.1 on page 182) and deny (section 4.2.9 on page 190) directives are evaluated within a session section. 4.2.13.2 Parameters allow,deny First the allow directive will be evaluated, then the deny directive. If a host matches both the allow and deny directives, the host will be denied because that is the last directive evaluated. deny,allow First the deny directive will be evaluated, then the allow directive. If a host matches both the allow and deny directives, the host will be allowed because that is the last directive evaluated. mutual-failure A host will only be allowed if it is allowed by the allow directive and it is not denied by the deny directive. 4.2.13.3 Default If No Entry Found If no order directive is found in a limit section, deny,allow will be assumed. 4.2.13.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.13.5 File Syntax order ord This directive is only valid within a session section in the session based configuration file (section 5.2.5 on page 268). It will only be used in the session configuration if at least one corresponding allow (section 4.2.1 on page 182), deny (section 4.2.9 on page 190) or require (section 4.2.14 on page 196) entry also exists. Only one entry may exist in a session section. If more than one entry exists, the last entry will be used. Page 195 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.13.6 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.14 Require User Authentication Configuration 4.2.14.1 Description Specifies which users are allowed to access sessions in the enclosing session (section 4.2.11 on page 193) section. When evaluating a require, the server will use the current user (section 4.2.8 on page 189) and group (section 4.2.3 on page 185) files. 4.2.14.2 Parameters One or more entities to match for a require. If there is more than one entity for a require, the user name/password combination only needs to be valid for any one of the entities. Each entity can be one of: valid-user Allows any user from the current user file (if they provide a valid password). valid-user-profile Allows any user with a user profile. This is only meant to be used in conjuction with a signon method (section 4.2.81 on page 254) of UseAuthentication. user ["comments"] user-name Specifies that the user name/password combination must be correct for the user in user-name. The comments parameter is ignored by the server and may contain any information useful to you. If this is used in a session with a signon method (section 4.2.81 on page 254) of UseAuthentication, the user is expected to be a user profile and does not have to be listed in a user file. group group-name Specifies that the user name/password combination must be correct for any one of the users in group identified by group-name. none Allows any user access. This has the effect of turning off user authentication for the current session section. Page 196 Webulator/400R User Manual, Version 2.0 4.0 Con Note that if any other require entries are combined with none, none will always take precedence. 4.2.14.3 Default If No Entry Found If no require entry is found in a session section, user authentication will not be used. 4.2.14.4 File Syntax require entity [entity] ... Multiple require entries may exist in the same session section. If more than one require entry is found, they will be treated as though each entity were on the same require line. 4.2.14.5 Also See . Protecting Your AS/400 Information (section 2.9 on page 98) . Related parameters (Access Control on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.15 Alias 4.2.15.1 Description Aliases are a way of mapping an incoming request from one location to another. An alias can change the session, or even server of a requested URL. When an alias is found in a URL, the alias's value is substituted in place of the alias. The alias must match the user's URL from the beginning. If the alias matches a string in the middle of the URL, no substitution is performed. 4.2.15.2 Parameters Alias A string that will be replaced in a URL if it matches the beginning of the URL. Because it must match in the beginning, a leading slash must be used. [Actual] The value that replaces the alias. *WEBULATOR aliases can optionally have a value; redirection types must have an [Actual] value. [SrcType] Page 197 Webulator/400R User Manual, Version 2.0 4.0 Con *WEBULATOR All URLs starting with this alias will be treated as Webulator/400 application URLs. *REDIRECT Causes Webulator/400 to redirect the browser to a URL on a different server. *TREDIRECT Same as *Redirect except the browser should consider the redirection temporary. 4.2.15.3 Default If No Entry Found If an alias is not listed, aliasing does not apply. 4.2.15.4 Commands to change this value . WRKWBLALS (section 3.1.10 on page 151) . ADDWBLALS (section 3.1.11 on page 152) . DLTWBLALS (section 3.1.13 on page 153) . CHGWBLALS (section 3.1.12 on page 152) 4.2.15.5 File Syntax Alias Alias [Actual] [SrcType] Multiple entries may exist in the alias configuration file (section 5.2.4 on page 267). If the same alias is listed in the alias configuration file, it is undefined which one will be used. It is recommended that the each alias entry appear only once. 4.2.15.6 Also See . Related parameters (Aliases on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.16 Alias File Path 4.2.16.1 Description Lists the file name of the alias configuration file (section 5.2.4 on page 267). Also see alias (section 4.2.15 on page 197). 4.2.16.2 Parameters Location of the alias file. If a leading slash is specified in the path, it will be treated as an absolute path name. If Page 198 Webulator/400R User Manual, Version 2.0 4.0 Con no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). 4.2.16.3 Default If No Entry Found If there is no entry for this, the default will be Cfg/alias.cfg . 4.2.16.4 Command To Change This Value . CHGWBLSVR ALIASFILE('Cfg/alias.cfg') (section 3.1.6 on page 147) 4.2.16.5 File Syntax AliasCfgFile FileName Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.16.6 Also See . Related parameters (Aliases on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.17 Send Javascript 4.2.17.1 Description Specifies whether to send Javascript code to browsers along with HTML Webulator screens. You only need to disable this if someone is accessing Webulator/400 screens with a browser that cannot handle Javascript and does not ignore it. 4.2.17.2 Parameters Send Can be Yes or No. 4.2.17.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Yes, will be inherited. Page 199 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.17.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.17.5 File Syntax SendJavascript Send 4.2.18 Terminal Color 4.2.18.1 Description Specifies whether a color or monochrome virtual terminal is used. Note that the use of a color virtual terminal depends on extensions to HTML 2.0 and may not work with all browsers. 4.2.18.2 Parameters Type The supported types are Color and Monochrome. Which type you choose will decide which color conversion (section 4.2.40 on page 220) values are used. 4.2.18.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Color, will be inherited. 4.2.18.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.18.5 File Syntax TermColor Type 4.2.19 Terminal Size 4.2.19.1 Description Specifies what size of virtual terminal is used. Page 200 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.19.2 Parameters Size Can be Big, Small or DBCS. Big will cause a 27 x 132 character virtual terminal to be created. Small will cause a 24 x 80 character virtual terminal to be created. DBCS will cause a 24 x 80 double-byte enabled character virtual terminal to be created. 4.2.19.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Small, will be inherited. 4.2.19.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.19.5 File Syntax TermSize Size 4.2.20 Server Root Path 4.2.20.1 Description Default path that contains server-related files. Many other paths can be made relative to this path. Configuration, log, security, and other files will typically reside within this path. 4.2.20.2 Parameters Name of fully qualified IFS path containing server related files. 4.2.20.3 Default If No Entry Found /Wbl 4.2.20.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) SVRROOT(/Wbl) 4.2.20.5 File Syntax ServerRoot Path Page 201 Webulator/400R User Manual, Version 2.0 4.0 Con Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.20.6 Also See . Related parameters (Document Locations on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.21 Fall-thru Path for HTTP 4.2.21.1 Description It is possible to include HTML tags within your DDS that cause the browser to display a link, an image, or another object on the screen with your 5250 data. This includes Webulator/400 menu images, background images, as well as the keyboard plugin. These objects can provide information, increase ease-of-use, and make your Webulator screen more attractive. They are served to the browser by an HTTP server that is separate from Webulator/400 - usually either Web Server/400 or one of the IBM Internet Connection Servers. The Fall-thru Path for HTTP value is used to assist Webulator/400 in redirecting the request for these objects to that server for them to be served via HTTP (not secure). This value is a URL path that points to an HTTP server. In the case of Web Server/400, this might contain www.servername.com. The Fall-thru Path for SSL (section 4.2.22 on page 203) value is also used by Webulator/400 to redirect requests for objects that are to be served securely via SSL. 4.2.21.2 Parameters A URL path for all additional file requests. 4.2.21.3 Default If No Entry Found If there is no entry for this, the default will be blank. 4.2.21.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) FALLTHRUH('') 4.2.21.5 File Syntax FallThruRootHTTP URLPath Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 202 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.21.6 Also See . Related parameters (Document Locations on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.22 Fall-thru Path for SSL 4.2.22.1 Description It is possible to include HTML tags within your DDS that cause the browser to display a link, an image, or another object on the screen with your 5250 data. This includes Webulator/400 menu images, background images, as well as the keyboard plugin. These objects can provide information, increase ease-of-use, and make your Webulator screen more attractive. They are served to the browser by an HTTP server that is separate from Webulator/400 - usually either Commerce Server/400 or one of the IBM Internet Connection Secure Servers. When the Webulator/400 screen is served via SSL, the objects that are to be included on the same browser page must also be served securely via SSL. The Fall-thru Path for SSL value is used to assist Webulator/400 in redirecting the request for these objects for them to be served securely via SSL by the external server . This value is a URL path that points to that secure HTTP server. In the case of Commerce Server/400, this might contain www.secureservername.com. The Fall-thru Path for HTTP (section 4.2.21 on page 202) value is also used by Webulator/400 to redirect requests for objects that are to be served via HTTP (not secure). 4.2.22.2 Parameters A URL path for all additional file requests. 4.2.22.3 Default If No Entry Found If there is no entry for this, the default will be blank. 4.2.22.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) FALLTHRUS('') 4.2.22.5 File Syntax FallThruRootSSL URLPath Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 203 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.22.6 Also See . Related parameters (Document Locations on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.23 Keyboard Plugin Location 4.2.23.1 Description A browser plug in is a platform specific piece of code that is loaded by the browser whenever data of a certain type is accessed. Webulator/400 can embed an HTML tag that forces our keyboard plug in to be called every time a Webulator/400 screen is displayed. The keyboard plug in monitors the keyboard for the user pressing any of the defined AS/400 AID keys (such as Enter and Function Keys). Whenever the plug in detects one of these keys being pressed, it will automatically return the HTML form to the AS/400. Some browsers key the execution of a plug in to the existence of a file on the server that is destined for the plug in code. This file usually contains data that the plug in will use during its execution, i.e.: a file that contains the sound that you wish to hear at the browser, or a file that contains the video clip that you wish to display. Webulator/400 allows the browser to request this type of file based on the Keyboard Plugin Location value. You will need a separate HTTP server to serve this file to the browser. The file specified may contain any data you like and can be named anything that the HTTP server is capable of serving; it must exist, but the contents are not important. The value of the Keyboard Plugin Location must be based on where the file actually exists, taking the HTTP server's document root path into consideration. In the case of Web Server/400, this would normally be /Plugin.wky if you have not changed the server defaults. In addition, content type information may also be required by the HTTP server. Additional information about the keyboard plugin may be found here (section 2.8.11 on page 78). 4.2.23.2 Parameters A fully qualified path and file name indicating the directory where the keyboard plugin file is stored and its file name. This file must be accessible by a Web Server. 4.2.23.3 Default If No Entry Found /PLUGIN.WKY Page 204 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.23.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) KBDPLUGLOC('/PLUGIN.WKY') 4.2.23.5 File Syntax KbdPluginLoc /PathAndFileName Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.23.6 Also See . Related parameters (Document Locations on page 174) . Alphabetical index of values (section 4.2 on page 178) 4.2.24 Upper to Lower Conversion 4.2.24.1 Description Indicates whether to data in uppercase only fields should be converted to lower case before displaying. The data will be automatically converted back to uppercase after the user submits the screen back to the AS/400. Some browsers may not show the entire contents of an input field if all of the characters are in uppercase while all of the characters will show correctly if they are first converted to lowercase. 4.2.24.2 Parameters Convert Can be Yes or No. 4.2.24.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is No, will be inherited. 4.2.24.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.24.5 File Syntax UpperToLowerConvert Convert Page 205 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.25 Extended Input Field 4.2.25.1 Description Specifies how 5250 extended input fields are represented on the browser. 4.2.25.2 Parameters FieldType This can be either TextArea or Scrollable. A TextArea field will generally appear on the browser as an editable field that can display more than one line at a time. A Scrollable field will generally appear on the browser as a single-line editable field that automatically scrolls as the user types. 4.2.25.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is to Scrollable, will be inherited. 4.2.25.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.25.5 File Syntax ExtendedInputField FieldType 4.2.26 Field Level Prompting 4.2.26.1 Description Specifies the text that a user can type in to indicate which field they want help with. Note: this parameter should not have to be used if you have the Send Javascript (section 4.2.17 on page 199) option enabled. 4.2.26.2 Parameters Text This optional parameter specifies the text that a user can type in a field to prompt that field. When any key other than the ENTER key is pressed, the Webulator will compare the text string with the ending Page 206 Webulator/400R User Manual, Version 2.0 4.0 Con characters of each entry field. If the text matches the ending characters of any entry field, the text will be stripped and the remaining characters will be returned to the AS/400 application along with the current row and column location. Only the first field will be processed. If this parameter is not specified, field level prompting will not be allowed. 4.2.26.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is to ?, will be inherited. 4.2.26.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.26.5 File Syntax FieldLevelPrompting Text 4.2.27 Light Pen Image 4.2.27.1 Description Specifies the image displayed by Webulator/400 to represent light pen fields. 4.2.27.2 Parameters Image The URL of the image file to load. This must contain a leading slash ('/') to make it relative to the document root. This parameter is required. 4.2.27.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is /icons/ltpen.gif, will be inherited. 4.2.27.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) Page 207 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.27.5 File Syntax LightPenImage Image 4.2.28 Virtual Terminal Interactive Job CCSID 4.2.28.1 Description Informs Webulator/400 of the CCSID that it will use to send data to the Virtual Terminal APIs. Webulator will use this value as the target CCSID when converting the data from the Server User Profile CCSID to the job's CCSID. 4.2.28.2 Parameters CCSID CCSID of the interactive job running the Webulator/400 session. 4.2.28.3 Default if no entry found If no entry is provided for a session, the parent session's value will be inherited. If the root session has no entry, the default, which is NoConvert, will be inherited. 4.2.28.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.28.5 File Syntax TermJobCCSID CCSID 4.2.29 Keyboard Plugin 4.2.29.1 Description Indicates whether the browser keyboard plugin should be embedded into each Webulator/400 screen. The plugin is a piece of code that must be downloaded and installed on the user's machine which will map the keyboard to emulate a green screen keyboard anytime a Webulator/400 screen is being displayed by the browser. 4.2.29.2 Parameters Include Can be Yes or No. Page 208 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.29.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Yes, will be inherited. 4.2.29.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.29.5 File Syntax EnableKeyboardPlugin Include 4.2.30 Keyboard Plugin Buttons 4.2.30.1 Description Indicates whether the Virtual Keyboard buttons should be shown on the screen when the Keyboard Plugin has been enabled. The setting of this value will have no impact on the functionality of the plug in. 4.2.30.2 Parameters Show Can be Yes or No. Yes means that all defined Virtual Keyboard buttons will be shown both in the Keyboard Plugin drop down list AND as browser submit buttons on the screen. No means that all defined Virtual Keyboard buttons will be shown only in the Keyboard Plugin drop down list and NOT as browser submit buttons on the screen. 4.2.30.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is No, will be inherited. 4.2.30.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.30.5 File Syntax ShowKeyboardPluginBtns Show Page 209 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.31 Virtual Keyboard Button 4.2.31.1 Description Describes one virtual keyboard button. This entry must appear in between a virtual keyboard row start (section 4.2.33 on page 211) and a virtual keyboard end (section 4.2.32 on page 210). You can also find more information about using predefined AS/400 key buttons (section 2.8.9 on page 75). 4.2.31.2 Parameters Key Specifies the key that will be simulated when this button is pressed. Read supported AID keys (section 4.2.34 on page 212) to see the list of possible values. Description This will appear on the button in the browser. 4.2.31.3 Default if no entry found There is no default for this entry. 4.2.31.4 File Syntax RowBtn Key Description Multiple virtual keyboard buttons may exist within each button row (section 4.2.33 on page 211) section. 4.2.31.5 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) option 9 4.2.32 Virtual Keyboard Row End 4.2.32.1 Description Ends a virtual keyboard row section that was started by the Virtual Keyboard Row Start (section 4.2.33 on page 211) directive. 4.2.32.2 Parameters None Page 210 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.32.3 Default if no entry found There is no default for this directive, but if not specified, button rows from the nearest parent directory containing button rows will be inherited. 4.2.32.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) option 9 4.2.32.5 File Syntax One entry should exist for every Virtual Keyboard Row Start directive. 4.2.32.6 Also see . Virtual Keyboard Row Start (section 4.2.33 on page 211) directive . Virtual Keyboard Button (section 4.2.31 on page 210) directive 4.2.33 Virtual Keyboard Row Start 4.2.33.1 Description Starts a virtual keyboard row section, which is used to define a row of virtual keyboard buttons on the screen. This section will override a section defined in a directory closer to the root if the two sections contain the same Location and Order. If an empty section is specified (a Virtual Keyboard Row Start followed by a Virtual Keyboard Row End (section 4.2.32 on page 210) with no intervening Virtual Keyboard Buttons (section 4.2.31 on page 210)), no virtual keyboard buttons will be displayed for that row. 4.2.33.2 Parameters Location Can be either Top or Bottom. Specifies where this row of buttons will appear on the screen. Order Used to define the order in which multiple rows of buttons appear. A row of buttons with a low order will appear before a row of buttons with a higher order. While button rows at different locations can share the same Page 211 Webulator/400R User Manual, Version 2.0 4.0 Con order, two button rows cannot have the same location and the same order. 4.2.33.3 Default if no entry found If no button row is specified, button rows from the nearest parent directory containing button rows will be inherited. If no button rows are specified in the root directory, default button rows will be used. These defaults can then be inherited by other directories which do not specify button rows. The four default button rows are at: Location Order Top 1 Bottom 1 Bottom 2 Bottom 3 4.2.33.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) option 9 4.2.33.5 File Syntax Multiple virtual keyboard row sections may exist within each Session (section 4.2.11 on page 193) section. 4.2.33.6 Also see . Virtual Keyboard Row End (section 4.2.32 on page 210) directive . Virtual Keyboard Button (section 4.2.31 on page 210) directive 4.2.34 Supported AID Keys Here is a list of all AID Keys supported by Webulator/400 and the way to specify them in configuration files: Page 212 Webulator/400R User Manual, Version 2.0 4.0 Con KEY CFG. FILE FORMAT ------------------- ---------------- Enter Enter Help Help Roll Down RollDown Roll Up RollUp F1 F1 F2 F2 F3 F3 F4 F4 F5 F5 F6 F6 F7 F7 F8 F8 F9 F9 F10 F10 F11 F11 F12 F12 F13 F13 F14 F14 F15 F15 F16 F16 F17 F17 F18 F18 F19 F19 F20 F20 F21 F21 F22 F22 F23 F23 F24 F24 Reset Reset Close Close System Request SystemRequest Attention Attention You can find more information about what each of these does by reading about AS/400 Command buttons (section 2.8.9 on page 75). 4.2.35 Access Log Cycle Configuration 4.2.35.1 Description Describes how to cycle the access log. 4.2.35.2 Parameters Date/Units This can either be a number from 1-31 representing a day- of-the month date or one of the following key words: Page 213 Webulator/400R User Manual, Version 2.0 4.0 Con MonthStart Cycle at the beginning of the month. This is the same as a 1. MonthEnd Cycle at the end of the month. Monday Cycle on Monday. Tuesday Cycle on Tuesday Wednesday Cycle on Wednesday Thursday Cycle on Thursday Friday Cycle on Friday Saturday Cycle on Saturday Sunday Cycle on Sunday Daily Cycle on a per-day basis. ServerStart Cycle on the day of the month the server was started. If this parameter is missing, cycling will be turned off. Time This can either be ServerStart, meaning the time the server was started or a time of the format HH:MM:SS. The seconds are optional and valid hours are from 00 to 23. Period This specifies how long to wait between cycles and is combined with the Date/Units field. For instance, with a period of 2 and a Date/Units of 3, cycling will occur every two months on the third of the month. If the Date/Units were changed to Saturday, cycling would occur every two weeks on a Saturday. MaxFiles This is the maximum number of files to keep when cycling. When this number is exceeded, old files will be deleted when new files are created while cycling. Page 214 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.35.3 Default If No Entry Found By default, cycling is not enabled. 4.2.35.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) ACCCYLCLE('') 4.2.35.5 File Syntax AccessLogCycle Date/Units Time Period MaxFiles Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.35.6 Also See . Related parameters (Logs on page 175) . Alphabetical index of values (section 4.2 on page 178) . Logs (section 2.17 on page 119) . Access Log File Path (section 4.2.36 on page 215) 4.2.36 Access Log File Path 4.2.36.1 Description File that logs all attempts to access the server. 4.2.36.2 Parameters [LogFilename] Location of the access log file. If a leading slash is specified in the path, it will be treated as an absolute path name. If no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). If this is blank, access logging will be disabled. [CodePage] Code page to be used when creating the access log. Code page 437 is U.S. English. Note that if the file already exists, the code page for the file will not be changed. This parameter is optional and will default if missing. This parameter is not used for log files created in QSYS. Log files created in QSYS will use the code page of the server user profile (section 4.2.76 on page 250). Page 215 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.36.3 Default If No Entry Found Logs/access.log 850 4.2.36.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) ACCLOGFILE(Logs/access.log 437) 4.2.36.5 File Syntax AccessLog [LogFilename [CodePage]] Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.36.6 Also See . Related parameters (Logs on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.37 Error Log Cycle Configuration 4.2.37.1 Description Describes how to cycle the error log. 4.2.37.2 Parameters Date/Units This can either be a number from 1-31 representing a day- of-the month date or one of the following key words: MonthStart Cycle at the beginning of the month. This is the same as a 1. MonthEnd Cycle at the end of the month. Monday Cycle on Monday. Tuesday Cycle on Tuesday Wednesday Cycle on Wednesday Page 216 Webulator/400R User Manual, Version 2.0 4.0 Con Thursday Cycle on Thursday Friday Cycle on Friday Saturday Cycle on Saturday Sunday Cycle on Sunday Daily Cycle on a per-day basis. ServerStart Cycle on the day of the month the server was started. If this parameter is missing, cycling will be turned off. Time This can either be ServerStart, meaning the time the server was started or a time of the format HH:MM:SS. The seconds are optional and valid hours are from 00 to 23. Period This specifies how long to wait between cycles and is combined with the Date/Units field. For instance, with a period of 2 and a Date/Units of 3, cycling will occur every two months on the third of the month. If the Date/Units were changed to Saturday, cycling would occur every two weeks on a Saturday. MaxFiles This is the maximum number of files to keep when cycling. When this number is exceeded, old files will be deleted when new files are created while cycling. 4.2.37.3 Default If No Entry Found By default, cycling is not enabled. 4.2.37.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) ERRCYCLE('') 4.2.37.5 File Syntax ErrorLogCycle Date/Units Time Period MaxFiles Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 217 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.37.6 Also See . Related parameters (Logs on page 175) . Alphabetical index of values (section 4.2 on page 178) . Logs (section 2.17 on page 119) . Error Log File Path (section 4.2.38 on page 218) 4.2.38 Error Log File Path 4.2.38.1 Description Name of file that logs all server errors. Also see error logging level (section 4.2.39 on page 219). 4.2.38.2 Parameters [LogFileName] Location of the error log file. If a leading slash is specified in the path, it will be treated as an absolute path name. If no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). If this is blank, error logging will be turned off. [CodePage] Code page to be used when creating the error log. Code page 437 is U.S. English. Note that if the file already exists, the code page for the file will not be changed. This parameter is optional and will default if missing. This parameter is not used for log files created in QSYS. Log files created in QSYS will use the code page of the server user profile (section 4.2.76 on page 250). 4.2.38.3 Default If No Entry Found Logs/error.log 437 4.2.38.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) ERRLOGFILE('Logs/error.log 437') 4.2.38.5 File Syntax ErrorLog [LogFileName [CodePage]] Page 218 Webulator/400R User Manual, Version 2.0 4.0 Con Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.38.6 Also See . Related parameters (Logs on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.39 Error Logging Level 4.2.39.1 Description Specifies the logging level of errors. Also see error log file path (section 4.2.38 on page 218). 4.2.39.2 Parameters All Equivalent to Informational. Errors Only log errors. Warnings Log warnings and errors. Informational Log informational messages, warnings and errors. 4.2.39.3 Default If No Entry Found Warnings 4.2.39.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) ERRLOGLVL(Warnings) 4.2.39.5 File Syntax ErrorLogLevel Level Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 219 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.39.6 Also See . Related parameters (Logs on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.40 Color Conversion 4.2.40.1 Description Specifies a color mapping from 5250 colors to browser colors. This is an extension to HTML 2.0. Being an extension, be aware it may not be supported by all browsers. 4.2.40.2 Parameters 5250Color Describes the 5250 color to map from. The possible values are: White Green Red Turquoise Yellow Pink Blue Monochrome Monochrome only applies if the terminal color (section 4.2.18 on page 200) has been set to monochrome. The other values only apply if the terminal value has been set to color. RGBColor This optional parameter specifies the color to map to. The color must be specifed in the form of #RRGGBB where RR represents red, GG represents green, and BB represents blue. Each value must be specified in hexadecimal (e.g. #000000 is black, #FFFFFF is white and #880000 is dark red). If no RGBColor is specified, no color information will be sent to the browser. The browser will then either use a default color or the color configured by the user. 4.2.40.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default will be inherited. If no entries are found in the root, the following defaults will be used: Page 220 Webulator/400R User Manual, Version 2.0 4.0 Con White #FFFFFF Green #00BF00 Red #E50000 Turquoise #00BFBF Yellow #E5E500 Pink #E500E5 Blue #0000E5 Monochrome 4.2.40.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.40.5 File Syntax ColorConversion 5250Color RGBColor 4.2.41 Font Size 4.2.41.1 Description Specifies the initial font size used to display Webulator/400 text. If a session configuration (section 2.8.10 on page 77) button is configured, the user can then override this setting. 4.2.41.2 Parameters Size The size can range from 1 to 7, with 1 being the smallest and 7 being the largest. The 'normal' size is 3. If this parameter is missing, the font size attribute will not be sent. This will let the browser decide what font size to use. 4.2.41.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is to let the browser choose the font size, will be inherited. 4.2.41.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.41.5 File Syntax FontSize Size Page 221 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.42 Menu Type 4.2.42.1 Description Specifies how menus are interpreted and presented by Webulator/400. 4.2.42.2 Parameters [InputFieldLocation] This optional parameter specifies which AS/400 input field to receive menu selections. It can be First or Last. If not specified, First will be used. Type This can be None, Numbers, Descriptions or Image. If None is specified, menus will not be interpreted at all. If Numbers is specified, menus will be interpreted and buttons will be displayed on the browser with numbers on the buttons. If Descriptions is specified, menus will be interpreted and buttons will be displayed on the browser with text from the menu items displayed on the buttons. ImageFile If Image was specified for the type, this must be present and is the image that will be displayed on each menu button. This must contain a leading slash ('/') to make it relative to the document root. 4.2.42.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is None, will be inherited. 4.2.42.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.42.5 File Syntax MenuType [InputFieldLocation] Type ImageFile Page 222 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.43 Subfile Scrolling Hot Spots 4.2.43.1 Description Specifies whether Webulator/400 should try to identify subfiles on the screen and to place clickable images that represent Page Up, Page Down and Help. 4.2.43.2 Parameters Keywords Can be SubFile and/or MsgLine. SubFile instructs Webulator/400 to search the screen for subfile keywords and to place clickable images for Page Up and Page Down next to any keywords that if locates. MsgLine instructs Webulator/400 to search for any output fields on the last line of the screen and to place clickable images at the end of the line for Page Up, Page Down and Help. 4.2.43.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is None will be inherited. 4.2.43.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.43.5 File Syntax EnableSflScrolling Keyword [Keyword] 4.2.44 Parsed Button 4.2.44.1 Description Describes a pattern to look for in Webulator/400 screens to replace with a button. You can find more information about converting keywords to buttons (section 2.8.16 on page 85). 4.2.44.2 Parameters [Type] This optional parameter defines how the button text will be generated. If set to Keyword, the text displayed on the button will match the Pattern entered. If set to Page 223 Webulator/400R User Manual, Version 2.0 4.0 Con Description, Webulator/400 will generate button text from the text on-screen that follows the Pattern. If not specified, Description will be assumed. Key Specifies the key that will be simulated when this button is pressed. Read supported AID keys (section 4.2.34 on page 212) to see the list of possible values. Pattern This optional parameter specifies the pattern to replace with a button. If the pattern is blank, any previous definitions for this key will be removed. 4.2.44.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is no parsed buttons, will be inherited. 4.2.44.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) opiton 8 4.2.44.5 File Syntax ParsedButton [Type] Key Pattern Multiple parsed button entries may exist within each directory (section 4.2.11 on page 193) section. In addition, multiple patterns may be defined for one key by using multiple lines and specifying the same key on each line. 4.2.45 Reverse Image Space Character 4.2.45.1 Description Specifies the character to display in place of a space with a reverse image attribute. This is useful because HTML does not allow for reverse image attributes. 4.2.45.2 Parameters Character Can be any single character or None. Page 224 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.45.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is *, will be inherited. 4.2.45.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.45.5 File Syntax ReverseImageSpaceCharacter Character 4.2.46 Virtual Terminal Device CCSID 4.2.46.1 Description Data originating from an application is in the Virtual Termainal's Device CCSID. It then gets sent to the Webulator/400 which is running under the Server User Profile CCSID. If these two CCSIDS are not the same, some characters may get changed. This value instructs Webulator/400 to perform an extra translation step from the Device's CCSID to the Server User Profile CCSID before sending the screen to the browser. 4.2.46.2 Parameters CCSID Informs Webulator/400 of the CCSID that it will receive data from the Virtual Terminal APIs. Webulator will use this as the source CCSID when converting the data from the Device CCSID to the Server User Profile CCSID. 4.2.46.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is NoConvert, will be inherited. 4.2.46.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.46.5 File Syntax TermDeviceCCSID CCSID Page 225 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.47 Connection Queue Size 4.2.47.1 Description Defines the size of the queue that holds pending TCP/IP requests. Each server request requires a connection. The queue size should be set large enough to hold the maximum concurrent requests expected. If the queue is full, additional requests are ignored. The queue size is set when the server is started with the STRWBL (section 3.1.2 on page 136) command. 4.2.47.2 Parameters Size of the outstanding connection requests queue. This must be a number between 0 and 512. 4.2.47.3 Default If No Entry Found 64 4.2.47.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) CONNQUESIZ(64) 4.2.47.5 File Syntax ConnectionQueueSize Size Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.47.6 Also See . Related parameters (Request Processing on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.48 Initial Request Processors 4.2.48.1 Description Indicates the number of request processors (RPs) that are started at startup time (i.e., when the server is started with the STRWBL (section 3.1.2 on page 136) command). An RP is needed to process each server request. The number of RPs the server should have available at startup is dependent on the typical number of concurrent requests the server must handle. Page 226 Webulator/400R User Manual, Version 2.0 4.0 Con Additional RPs can be started dynamically (see request wait timeout (section 4.2.50 on page 228)) or procedurally using the STRWBLRP (section 3.1.4 on page 144) command. Individual RPs can be ended with the ENDWBLRP (section 3.1.5 on page 145) command. 4.2.48.2 Parameters The number of RPs to start. This must be a value between 1 and maximum request processors (section 4.2.49 on page 227). 4.2.48.3 Default If No Entry Found 1 4.2.48.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) INITRPS(1) 4.2.48.5 File Syntax InitialRPs Number Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.48.6 Also See . Related parameters (Request Processing on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.49 Maximum Request Processors 4.2.49.1 Description Indicates the maximum number of request processors (RPs) that can be active at a time. This is roughly equivalent to the number of simultaneous requests that can be handled by the server. The maximum number of RPs the server should have available is dependent on the number of concurrent requests the server must handle and the system load. Additional RPs will not be started dynamically based on the request wait timeout (section 4.2.50 on page 228) configuration value or procedurally using the STRWBLRP (section 3.1.4 on page 144) command once this value is reached. If an RP is not available to process a request it will be rejected by the server in timeout (section 4.2.51 on page 229) seconds. Page 227 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.49.2 Parameters The maximum number of request processors. This must be a value between 1 and 9999. 4.2.49.3 Default If No Entry Found 50 4.2.49.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) MAXRPS(50) 4.2.49.5 File Syntax MaxRPs Number Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.49.6 Also See . Related parameters (Request Processing on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.50 Request Wait Timeout 4.2.50.1 Description Number of seconds to wait for a request processor (RP) to become available before dynamically starting another request processor. An additional RP will not be dynamically started if the maximum request processors (section 4.2.49 on page 227) have been reached. A request will be rejected if Timeout (section 4.2.51 on page 229) seconds minus Seconds is not enough time for the additional RP to start and another RP did not become available. Additional RPs can also be started using the STRWBLRP (section 3.1.4 on page 144) command. 4.2.50.2 Parameters Number of seconds to wait for a request processor to become available before dynamically starting another request processor. If 0, RPs will not be dynamically started. This value must be between 0 and Timeout (section 4.2.51 on page 229). 4.2.50.3 Default If No Entry Found 5 Page 228 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.50.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) THRESHOLD(5) 4.2.50.5 File Syntax WaitThreshold Seconds Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.50.6 Also See . Related parameters (Request Processing on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.51 Timeout 4.2.51.1 Description Time to wait for the completion of communications-related activities before abandoning the request and logging an error. For example, if the server receives a request and there is not a request processor available to process the request in Seconds, the request is rejected. 4.2.51.2 Parameters The number of seconds to wait before timing out. This must be a value that is greater than 10 and also greater than request wait timeout (section 4.2.50 on page 228). 4.2.51.3 Default If No Entry Found 120 4.2.51.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) TIMEOUT(120) 4.2.51.5 File Syntax Timeout Seconds Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 229 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.51.6 Also See . Related parameters (Request Processing on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.52 Automatic Request Processor Timeout 4.2.52.1 Description During the processing of Webulator/400 sessions, additional request processors (RPs) may be required from time to time. These additional RPs may be started automatically by the server based on the request wait timeout (section 4.2.50 on page 228), Timeout (section 4.2.51 on page 229) and maximum request processors (section 4.2.49 on page 227) values. While being needed to fill a request at the time they were started, these same request processors may be idle for long periods of time and consequentially take up system resources. The Automatic Request Processor Timeout value indicates the number of minutes the server should wait before these request processors are ended or cancelled due to inactivity. Request processors that are started as a result of the initial request processsors (section 4.2.48 on page 226) value when the server is started or by the STRWBLRP (section 3.1.4 on page 144) command are not affected by this parameter. 4.2.52.2 Parameters Number of minutes to wait before dynamically ending a request processor that is idle. If 0, RPs will not be automically ended. 4.2.52.3 Default If No Entry Found 0 4.2.52.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) AUTORPTIME(0) 4.2.52.5 File Syntax AutoRPTimeout Minutes Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 230 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.52.6 Also See . Related parameters (Request Processing on page 175) . Alphabetical index of values (section 4.2 on page 178) 4.2.53 Background Color 4.2.53.1 Description Specifies the background color for Webulator/400. This will be sent as an attribute of the BODY tag and is an extension to HTML 2.0. Being an extension, be aware it may not be supported by all browsers. 4.2.53.2 Parameters Color The color must be specifed in the form of #RRGGBB where RR represents red, GG represents green, and BB represents blue. Each value must be specified in hexadecimal (e.g. #000000 is black, #FFFFFF is white and #880000 is dark red). If this parameter is missing, the color attribute will not be sent. This will let the browser decide what background color to use. 4.2.53.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is to let the browser choose the background color, will be inherited. 4.2.53.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.53.5 File Syntax BackgroundColor Color 4.2.54 Background Image 4.2.54.1 Description Specifies the background image for Webulator/400. This will be sent as an attribute of the BODY tag and is an extension to HTML 2.0. Being an extension, be aware it may not be supported by all browsers. Page 231 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.54.2 Parameters Image The URL of the image file to load. This must contain a leading slash ('/') to make it relative to the document root. If no Image is specified, none will be loaded by the browser. 4.2.54.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is to not use a background image, will be inherited. 4.2.54.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.54.5 File Syntax BackgroundImage Image 4.2.55 Footer File 4.2.55.1 Description Specifies a file or URL that will appear at the bottom of the Webulator/400 page. To find out more about footer files, read choosing a footer (section 2.8.17 on page 86). 4.2.55.2 Parameters FileName This optional parameter specifies the footer file or URL. If it is blank, no footer file will be used. For a file, this must contain a leading slash ('/') to make it relative to the document root. If a file is specified, but cannot be accessed due to authorization, host filtering or protocol conflicts (e.g. SSL vs. HTTP), no footer will be attached to the Webulator/400 output. Type This optional parameter specifies whether the FileName is a file or a URL. The valid entries are FILE and URL. Page 232 Webulator/400R User Manual, Version 2.0 4.0 Con FileCCSID If the FileName is a file, this optional parameter specifies the CCSID of the footer file. 4.2.55.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is no footer file or URL, will be inherited. 4.2.55.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.55.5 File Syntax FooterFile FileName 4.2.56 Header File 4.2.56.1 Description Specifies a file or URL that will appear at the top of the Webulator/400 page. To find out more about header and footer files, read about choosing a header (section 2.8.8 on page 73). 4.2.56.2 Parameters FileName This optional parameter specifies the header file or URL to be displayed. If it is blank, no header file will be used. For a file, this must contain a leading slash ('/') to make it relative to the document root. If a file is specified, but cannot be accessed due to authorization, host filtering or protocol conflicts (e.g. SSL vs. HTTP), no header will be attached to the Webulator/400 output. Type This optional parameter specifies whether the FileName is a file or a URL. The valid entries are FILE and URL. FileCCSID If the FileName is a file, this optional parameter specifies the CCSID of the header file. Page 233 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.56.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is no header file or URL, will be inherited. 4.2.56.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.56.5 File Syntax HeaderFile FileName 4.2.57 Horizontal Rule Location 4.2.57.1 Description Specifies whether to show top and bottom horizontal rules. 4.2.57.2 Parameters Locations Can be Top, Bottom, Both or None. 4.2.57.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is None, will be inherited. 4.2.57.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.57.5 File Syntax HorizontalRuleLocation Locations 4.2.58 Show Blank Lines 4.2.58.1 Description Specifies whether to show blank lines when displaying Webulator/400 screens. If a session configuration (section 2.8.10 on page 77) button is configured, the user can then override this setting. Page 234 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.58.2 Parameters Enabled Can be Yes or No. 4.2.58.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Yes, will be inherited. 4.2.58.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.58.5 File Syntax ShowBlankLines Enabled 4.2.59 Table Font Name 4.2.59.1 Description Allows specification of a font name when tables are enabled (section 4.2.61 on page 236). Because font names tend to be platform-specific and people accessing your Webulator/400 screens may be using different platforms, you need to be aware that this will affect people differently. Note that this is not used if tables are not enabled. 4.2.59.2 Parameters Name Can be any string. This will be passed to the browser and interpreted by it. If this is left blank, the browser will choose a font to display. 4.2.59.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Courier will be inherited. 4.2.59.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) Page 235 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.59.5 File Syntax TableFontName Name 4.2.60 Table Width 4.2.60.1 Description Allows specification of table width when tables are enabled (section 4.2.61 on page 236). Note that this is not used if tables are not enabled. 4.2.60.2 Parameters Width Can be any string. This will be passed to the browser and interpreted by it. If this is left blank, the browser will choose a default table width which is usually 100%. 4.2.60.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is to let the browser choose the width, will be inherited. 4.2.60.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.60.5 File Syntax TableWidth Width 4.2.61 Tables Enabled 4.2.61.1 Description Allows the enabling or disabling of tables. You may choose to disable tables if someone is attempting to access your Webulator/400 screens with a browser that does not support them. 4.2.61.2 Parameters Enable Can be Yes or No. Page 236 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.61.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is No, will be inherited. 4.2.61.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.61.5 File Syntax TablesEnabled Enable 4.2.62 Secure Key List File Path 4.2.62.1 Description The location of the key list file used by the secure aspects of Webulator/400. 4.2.62.2 Parameters File Location of the key list file. If a leading slash is specified in the path, it will be treated as an absolute path name. If no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). This file should not be stored in QSYS as it is binary. 4.2.62.3 Default If No Entry Found By default, no key list file is specified. 4.2.62.4 Command To Change This Value . CHGWBLSEC (section 3.1.27 on page 164) KEYFILE('Cfg/KeyList.Cfg') 4.2.62.5 File Syntax CommerceKeyListFile File Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 237 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.62.6 Also See . Related parameters (Secure Support on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.63 Secure Session Cache Size 4.2.63.1 Description The number of entries allowed in the session cache at any one time. When this number is exceeded, existing entries will be purged from the session cache. When a browser first makes a secure connection to Webulator/400, many session parameters are negotiated; this is a resource-intensive task. The server then caches these session parameters for later reuse. 4.2.63.2 Parameters The number of entries to allow in the session cache at one time. 4.2.63.3 Default If No Entry Found 100 4.2.63.4 Command To Change This Value . CHGWBLSEC (section 3.1.27 on page 164) CACHESIZE(100) 4.2.63.5 File Syntax CommerceSessionCacheSize Entries Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.63.6 Also See . Related parameters (Secure Support on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.64 Secure Session Cache Timeout 4.2.64.1 Description Time to wait before purging existing cached session parameters. When a browser first makes a secure connection to Webulator/400, many session parameters are negotiated; Page 238 Webulator/400R User Manual, Version 2.0 4.0 Con this is a resource-intensive task. The server then caches the session parameters for later reuse. 4.2.64.2 Parameters The number of seconds to wait before purging unused identifiers. If this is 0, then session identifiers will not be cached. 4.2.64.3 Default If No Entry Found 100 4.2.64.4 Command To Change This Value . CHGWBLSEC (section 3.1.27 on page 164) CACHETIME(100) 4.2.64.5 File Syntax CommerceSessionCacheTimeout Seconds Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.64.6 Also See . Related parameters (Secure Support on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.65 Secure SSL Port 4.2.65.1 Description The TCP/IP socket port that the server listens to for the receiving and sending of SSL (secure socket layer) requests. 4.2.65.2 Parameters The port to monitor for SSL request. 4.2.65.3 Default If No Entry Found 443 4.2.65.4 Command To Change This Value . CHGWBLSEC (section 3.1.27 on page 164) SSLPORT(443) Page 239 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.65.5 File Syntax CommerceSSLPort Port Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.65.6 Also See . Related parameters (Secure Support on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.66 SSL Version 4.2.66.1 Description The version of SSL to use when browsers make secure connections to the server. The server may be configured to use a specific version or to negotiate the version with the browser. 4.2.66.2 Parameters The SSL Version. They may be one of: 2.0 The server will only serve SSL version 2.0. Use this if one or more of your clients has a browser which is not able to correctly negotiate SSL 3.0. 3.0 The server will only serve SSL version 3.0. Set this only if you have specific requirements for SSL version 3.0. *NEGOTIATE The server will attempt to serve SSL version 3.0. If the browser only supports SSL version 2.0, however, the server will serve that. 4.2.66.3 Default If No Entry Found *NEGOTIATE 4.2.66.4 Command To Change This Value . CHGWBLSEC (section 3.1.27 on page 164) SSLVER(*NEGOTIATE) 4.2.66.5 File Syntax SslVersion NegotiateLatest Page 240 Webulator/400R User Manual, Version 2.0 4.0 Con Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.66.6 Also See . Related parameters (Secure Support on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.67 Allowed Protocols 4.2.67.1 Description Allows specification of the protocols that will be served within a session or sessions. 4.2.67.2 Parameters One or more protocols, each of which can be one of the following: HTTP Serve information according the the HTTP 1.0 specification. This is the non-encrypted World-Wide-Web standard. SSL Serve information according to the Secure Socket Layer specification. SSLSIGNON If an AS/400 screen is determined to be the Sign on Display, that information will be served according to the Secure Socket Layer specification. All other information will be served according the the HTTP 1.0 specification. 4.2.67.3 Default If No Entry Found HTTP 4.2.67.4 Command To Change This Value . WRKWBLSSN (section 3.1.23 on page 158) option 14. 4.2.67.5 File Syntax AllowedProtocols Protocol [Protocols]... Page 241 Webulator/400R User Manual, Version 2.0 4.0 Con Only one entry may exist in a session section (section 4.2.11 on page 193). If more than one entry is found, the last one will be used. 4.2.67.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.68 Content CCSID 4.2.68.1 Description Contents of the Webulator/400 session text gets converted to this Coded Character Set ID (CCSID) before sending it to the browser. 4.2.68.2 Parameters Any ASCII or EBCDIC CCSID supported by OS/400. The value of 65535 is not supported. 4.2.68.3 Default If No Entry Found 819 4.2.68.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) CNTNTCCSID(819) 4.2.68.5 File Syntax ContentCCSID CCSID Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.68.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.69 Disable Server 4.2.69.1 Description Temporarily block requests coming into the server without shutting down the server. Browsers will get notified that Page 242 Webulator/400R User Manual, Version 2.0 4.0 Con the server currently is not satisfying requests and also when the server should be back to normal. This is useful for performing wide-spread maintenance on the server's content. 4.2.69.2 Parameters Disable Yes The server is disabled. The [Duration] parameter must be supplied when the server is disabled. No The server behaves normally. The [Duration] parameter is ignored. [Duration] The full Greenwich Mean Time (GMT) of when the server is expected to be available again. This should be in the form Wed, 26 Apr 1995 14:34:52 GMT. 4.2.69.3 Default If No Entry Found No 4.2.69.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) DISABLESVR(No) 4.2.69.5 File Syntax DisableServer Disable [Duration] Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.69.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.70 Domain Name Lookup 4.2.70.1 Description Determines how much information is retrieved about each client that accesses the server. Also see access log file path (section 4.2.36 on page 215). Page 243 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.70.2 Parameters None No information about the host is retrieved. Minimal Only the host's IP address is retrieved Normal The host's IP address and host name are retrieved. This requires more network traffic per request. If access control will be used with host or domain names, this is the minimum recommended setting. Note that the host name that is returned may not be correct (e.g. the client may be accessing the server from behind a firewall). This may cause unexpected entries in the access log (section 4.2.36 on page 215) or make it impossible to allow (section 4.2.1 on page 182) or deny (section 4.2.9 on page 190) specific hosts. Maximal This is the same as Normal. 4.2.70.3 Default If No Entry Found Normal 4.2.70.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) DOMNAMLOOK(Normal) 4.2.70.5 File Syntax DomainNameLookup Degree Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.70.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) Page 244 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.71 Initial Library List 4.2.71.1 Description Specifies what libarary list should be used for server batch jobs. 4.2.71.2 Parameters LibraryList Current The library list associated with the current job starting the server will be used. JobDescription The library list associated with the Server User Profile (section 4.2.76 on page 250) will be used. 4.2.71.3 Default If No Entry Found Current 4.2.71.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) INLLIBL(*CURRENT) 4.2.71.5 File Syntax InitialLibraryList LibraryList Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.71.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.72 MultiHome 4.2.72.1 Description Used to specify if multiple servers can be started on a specific port (section 4.2.77 on page 251). By default, only one server can be processing requests for a single port. When enabling multihome processing, multiple servers can be processing requests for a single port. Page 245 Webulator/400R User Manual, Version 2.0 4.0 Con By enabling multihome processing the following types of environments can be supported: . Running with 2 servers: a production server and a test server . Running with 2 servers: an internal server and an external server . Running with 2 servers: a Webulator server and a Web server . Multiple servers: each server is configured with a different environment Each multihome server must have its own master configuration file. Within the master configuration each server must log to unique files and use a unique server ID. The rest of the configuration values and files may be shared between or unique to each multihome server. The MultiHome configuration value is only used when starting the server (section 3.1.2 on page 136). 4.2.72.2 Parameters [Enabled] No Disable multihome processing. Only one server can be started on the configured port. If a Host is specified then only HTTP requests for the specified Host are processed. If a Host is not specified then all HTTP requests received on the port are processed by the server. Yes Enable multihome processing. This allows multiple servers with different configurations (e.g., home pages) to be started on a single port. The Host must be specified when multihome processing is enabled. Once a server is started with multihome enabled on a specific port, each additional server started on the port must be multihome enabled for a different Host (i.e., Host must process a different IP address). [Host] Identifies the host for which the server will process HTTP requests. The host can be identified using a host name (e.g., WWW.INETMI.COM) or IP address (e.g., 204.146.136.21). The specified host must be a local host (i.e., an identifier for the AS/400). See the TCP/IP network administrator for the appropriate value to use. Page 246 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.72.3 Default If No Entry Found MultiHome No 4.2.72.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) MULTIHOME(*YES HOSTNAME) 4.2.72.5 File Syntax MultiHome [Enabled [Host]] Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.72.6 Example Usage Multihome disabled with no host name specified (default) Only one server can be started on the port and the server processes requests for all host addresses. Multihome disabled with a host name of WWW.INETMI.COM (204.146.136.110) Only one server can be started on the port and the server only processes requests for host address 204.146.136.110 (i.e., host name WWW.INETMI.COM). Multihome enabled with a host name of WWW.INETMI.COM (204.146.136.110) Multiple servers can be started on the port and the server only processes requests for host address 204.146.136.110 (i.e., host name WWW.INETMI.COM). If the host has been configured with another address (e.g., host name of TEST and an IP address of 204.146.136.xxy), another server can be started that processes host address 204.146.136.xxy (i.e., host name TEST). 4.2.72.7 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.73 Server Host Name 4.2.73.1 Description Indicates the host name used to identify the host where the Webulator is running. This overrides what is configured through TCP/IP. This name should be a valid host name. The Page 247 Webulator/400R User Manual, Version 2.0 4.0 Con host name will be sent in the header information that is part of the HTTP protocol. 4.2.73.2 Parameters The valid host name. An example is: www.inetmi.com 4.2.73.3 Default If No Entry Found This defaults to the configured system value if the name is at least in the form abc.def. Otherwise, an empty name is used and a warning is logged. 4.2.73.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) HOSTNAME(www.initmi.com) 4.2.73.5 File Syntax ServerHostName Name Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.73.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.74 Server Identifier 4.2.74.1 Description Used to identify and describe a server. The server identifier is used in the naming of the server jobs (Server Jobs on page 139) and objects, and is supported by the server start and end commands. (Operational Commands on page 134) The server ID must be unique for each server starting on the AS/400. The ID can be up to 7 characters in length and can only contain alphabetic and numeric characters. If a server ID is not specified, the server creates a server ID based on the server's port. The HTTP socket port is used in the creation of the server ID unless the server is only running SSL, in which case the SSL socket port is used. For example, if the default port of 5061 is being used the server ID would be 5061xx. The xx characters uniquely Page 248 Webulator/400R User Manual, Version 2.0 4.0 Con identify the server processing on the port. When the server is started with multihome disabled, the xx characters are always spaces. When multihome is enabled, the xx characters range from 'A ' to 'ZZ'. The xx characters will always be the same for a specific IP address. 4.2.74.2 Parameters The valid server identifier. An example is: PUBLIC If this is missing, the default case will be used. 4.2.74.3 Default If No Entry Found The server creates a server identifier that is based on the port the server is processing. 4.2.74.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) SVRID(NAME) 4.2.74.5 File Syntax ServerIdentifier ID Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.74.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.75 Server Protocols 4.2.75.1 Description Specifies which protocols this server supports. 4.2.75.2 Parameters One or more protocols, each of which can be one of the following: HTTP Serve information according the the HTTP 1.0 specification. This is the non-encrypted World-Wide-Web standard. Page 249 Webulator/400R User Manual, Version 2.0 4.0 Con SSL Serve information according to the Secure Socket Layer specification. 4.2.75.3 Default If No Entry Found HTTP 4.2.75.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) PROTOCOLS(HTTP) 4.2.75.5 File Syntax ServerProtocol Protocol [Protocols]... Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.75.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.76 Server User Profile 4.2.76.1 Description User profile that server jobs will run under. Care should be taken to ensure the user profile only has authority to desired system objects. All request processors for a port (section 4.2.77 on page 251) will run under the same user profile (which is saved when the server is started using the STRWBL (section 3.1.2 on page 136) command). The user starting the server or additional request processors must have *USE authority to the server user profile. The server user profile must have at least *USE authority to the WBLDAEMON program in library WEBULATOR, to the server user profile's job description, and to the configured job queue (e.g., QSYS/QSYSNOMAX). The server user profile's configured job description determines the job queue to use when starting the server. The job queue must be setup to support multiple active jobs. The server user profile must have create authority to the configured log libraries/directories and at least execute authority to the preceding directories. The server user profile also must be registered in the system directory in Page 250 Webulator/400R User Manual, Version 2.0 4.0 Con order to access Document Library Services (DLS) folders and documents. 4.2.76.2 Parameters Valid AS/400 user profile name that the server jobs will run under. 4.2.76.3 Default If No Entry Found WBLUSER 4.2.76.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) SVRUSRPROF(WBLUSER) 4.2.76.5 File Syntax UserProfile Profile Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.76.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.77 Socket Port 4.2.77.1 Description The TCP/IP socket port that the server listens to for the receiving and sending of requests that use the HTTP protocol. Multiple servers can be started using the STRWBL (section 3.1.2 on page 136) command but each server must be processing a different socket port or must be using the server's multihome feature. 4.2.77.2 Parameters The number of the socket port to use. This must be a value between 1 and 32767 4.2.77.3 Default If No Entry Found 5061 Page 251 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.77.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) PORT(80) 4.2.77.5 File Syntax Port PortNum Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. 4.2.77.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.78 Temporary Directory 4.2.78.1 Description Specifies the directory where the server can store temporary files. 4.2.78.2 Parameters A fully qualified path indicating the temporary directory or a path relative to the server root path (section 4.2.20 on page 201) if it does not begin with a slash. This directory should not be within QSYS as it will be used to store binary files. 4.2.78.3 Default If No Entry Found Tmp If server root path (section 4.2.20 on page 201) is /Wbl then this is equivalent to /Wbl/Tmp. 4.2.78.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) TEMPDIR(Tmp) 4.2.78.5 File Syntax TemporaryDirectory DirectoryName Only one entry may exist in the master server configuration file (section 5.2.3 on page 265). If more than one entry is found, the last one will be used. Page 252 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.78.6 Also See . Related parameters (Server Administration on page 176) . Alphabetical index of values (section 4.2 on page 178) 4.2.79 Maximum Sessions 4.2.79.1 Description Specifies the maximum number of Webulator/400 sessions allowed at one time. Note that the system value QAUTOVRT specifies the number of virtual terminal devices supported system wide. You should always configure Webulator/400 to a maximum number of sessions that is smaller than the system value. 4.2.79.2 Parameters MaxSessions The maximum number of concurrent Webulator/400 sessions. 4.2.79.3 Default if no entry found 20 4.2.79.4 Command To Change This Value . CHGWBLSVR (section 3.1.6 on page 147) WBLMAXSSN(20) 4.2.79.5 File Syntax MaxWebulatorSessions MaxSessions 4.2.80 Webulator User File Path 4.2.80.1 Description Lists the file name of the Webulator user file (section 5.2.9 on page 271). 4.2.80.2 Parameters Location of the Webulator/400 user file. If a leading slash is specified in the path, it will be treated as an absolute path name. If no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). Page 253 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.80.3 Default If No Entry Found If there is no entry for this, the default will be blank. 4.2.80.4 File Syntax WebulatorUsrFile FileName 4.2.80.5 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) WBLUSRFILE('Cfg/WblUsr.cfg') 4.2.80.6 Also See . Alphabetical index of values (section 4.2 on page 178) 4.2.81 Signon Method 4.2.81.1 Description Describes the mechanism used to sign on a user when starting a Webulator/400 session at this URL. 4.2.81.2 Parameters Method Can be one of User, Screen, UseAuthentication, ExitPgm or Disabled. User will cause the system to automatically sign on with a specific user name. This is a secure way to configure Webulator/400 because you have control over what AS/400 user profiles people are allowed to sign on with. If this is specified, it must be followed by a UserName, which is described below. Screen will cause people to be presented with an AS/400 signon screen. They may then type in the AS/400 user and password they want to use to sign on. This may be less secure because the AS/400 user and password could be sent over the TCP/IP network between the browser and the server. It is recommended that this only be used over internal networks unless secured with SSL. If using secured Webulator/400 sessions, all data, including user ids and passwords is encrypted. UseAuthentication uses authentication information sent from the browser as the AS/400 user and password. This is slightly more secure than Screen because the user and password are sent uuencoded (while uuencoded text is not Page 254 Webulator/400R User Manual, Version 2.0 4.0 Con as obvious as "clear" text, it is not a form of encryption and it is easy to "decode" it). You can also combine this with access control (section 2.9 on page 98) to limit the user IDs and passwords that can be entered for a URL. This changes the meaning of Webulator/400 require (section 4.2.14 on page 196) entries; any users listed will be expected to be valid user profiles instead of entries in a user file. ExitPgm will instruct Webulator/400 to call a user written exit program anytime a signon screen is encountered. This method offers the greatest amount of flexibility but also requires additional setup time because of the effort needed to write the actual exit program. If this is specified, it must be followed by a Exit Program, Exit Program Library and Exit Program Format Name which are described below. Disabled Disables webulator access in the current directory. UserName This must be present if User was specified above. It is the AS/400 user that will be signed on. It must have a corresponding entry in the Webulator/400 user file (section 5.2.9 on page 271). AllowSignonOverride This is only applicable if the method is set to User or UseAuthentication. If set, Webulator/400 will allow signon screen fields to be overridden by URL options (section 2.8.3 on page 67). IgnoreSignonOverride This is only applicable if the method is set to User or UseAuthentication. If set, Webulator/400 will not allow signon screen fields to be overridden by URL options (section 2.8.3 on page 67). Exit Program This entry is required if the method is set to ExitPgm. This is the program that will be called whenever a signon screen is detected from the AS/400. It is the exit program's responsibility to determine whether a particular request should be allowed and if so it must return a valid user id and password to use for the system. Exit Program Library This entry is required if the method is set to ExitPgm. This is the library where the exit program resides. Page 255 Webulator/400R User Manual, Version 2.0 4.0 Con Exit Program Format Name This entry is required if the method is set to ExitPgm. This entry specifies the format of the structure that the exit program is expecting. Initially the only valid Format Name is QAPP0100. This list will be expanded as new formats are implemented. 4.2.81.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Screen, will be inherited. 4.2.81.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.81.5 File Syntax Signon Method UserName 4.2.81.6 Also see . Webulator/400 user file (section 5.2.9 on page 271) 4.2.82 Webulator User Entry 4.2.82.1 Description Specifies a user name and password which will be used for automatic signon by Webulator/400. 4.2.82.2 Parameters Name This is the AS/400 user profile that users will be signed on as. Password This is the AS/400 password that will be entered for users. Because this is not encrypted, you should protect this file with OS/400 authority. Only the user who changes the file and the user who starts the server needs authority to the file. The server user profile (section 4.2.76 on page 250) should NOT have authority to this file. Page 256 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.82.3 Commands To Change This Value . WRKWBLPRF (section 3.1.19 on page 156) USER(Name) PASSWORD(Password) . ADDWBLPRF (section 3.1.20 on page 157) USER(Name) PASSWORD(Password) . CHGWBLPRF (section 3.1.21 on page 157) USER(Name) PASSWORD(Password) . DLTWBLPRF (section 3.1.22 on page 158) USER(Name) 4.2.82.4 File Syntax Name Password Multiple entries may exist in the Webulator/400 user file (section 5.2.9 on page 271). 4.2.83 Webulator User File Path 4.2.83.1 Description Lists the file name of the Webulator user file (section 5.2.9 on page 271). 4.2.83.2 Parameters Location of the Webulator/400 user file. If a leading slash is specified in the path, it will be treated as an absolute path name. If no leading slash is specified, it will be considered to be relative to Server root path (section 4.2.20 on page 201). 4.2.83.3 Default If No Entry Found If there is no entry for this, the default will be blank. 4.2.83.4 File Syntax WebulatorUsrFile FileName 4.2.83.5 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) WBLUSRFILE('Cfg/WblUsr.cfg') 4.2.83.6 Also See . Alphabetical index of values (section 4.2 on page 178) Page 257 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.84 Signoff Action 4.2.84.1 Description Indicates what action should be performed when a user signs off of the AS/400. 4.2.84.2 Parameters Action Can be SignonScreen or Terminate. SignonScreen will cause the system to show the ensuing signon screen to the user. Terminate will cause the system to terminate the interactive job and to transfer the user to the Termination URL (section 4.2.88 on page 260). 4.2.84.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is SignonScreen, will be inherited. 4.2.84.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.84.5 File Syntax SignoffAction Action 4.2.85 Terminal Timeout 4.2.85.1 Description Allows you to specify the duration (in minutes) before an inactive session is closed. If the system value QINACTITV causes a timeout before Webulator/400 times out, the user will be presented with a sign-on screen. If you do not want that to happen, always set the Webulator/400 timeout value to something smaller than the system value. Page 258 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.85.2 Parameters Minutes The number of minutes Webulator/400 will wait before closing an inactive session. If this is 0, there will be no timeout. The maximum possible value for this is 1440 (24 hours). 4.2.85.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is 5, will be inherited. 4.2.85.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.85.5 File Syntax TermTimeout Minutes Only one entry may exist in a session section (section 4.2.11 on page 193). If more than one entry is found, the last one will be used. 4.2.86 Input Inhibited Timeout 4.2.86.1 Description Specifies the number of minutes to wait while input is inhibited until timing out and returning to the user. 4.2.86.2 Parameters Minutes This parameter must be present. If 0, no timeout will take place. Otherwise the session will be terminated if Input Inhibited is on for more than Minutes number of minutes. 4.2.86.3 Default if no entry found 5 4.2.86.4 File Syntax TERMINHIBITEDTIMEOUT Minutes Page 259 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.87 Termination Confirmation 4.2.87.1 Description Indicates whether to ask the user for confirmation when the Close session button has been pressed. 4.2.87.2 Parameters Confirm Can be Yes or No. 4.2.87.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is Yes, will be inherited. 4.2.87.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.87.5 File Syntax TerminationConfirmation Confirm 4.2.88 Termination URL 4.2.88.1 Description Specifies the URL to go to when a session is terminated normally as well as the URL description to display when a session is terminated abnormally (e.g. because of a session timeout). 4.2.88.2 Parameters URL The URL to link to when a session ends. Description A text description to display when a session ends abnormally.. 4.2.88.3 Default if no entry found If no entry is provided for a directory, the parent directory's value will be inherited. If the root directory has no entry, the default, which is / Return to server home page, will be inherited. Page 260 Webulator/400R User Manual, Version 2.0 4.0 Con 4.2.88.4 Command To Change This Value . CHGWBLSSN (section 3.1.24 on page 160) 4.2.88.5 File Syntax TerminationURL URL Description 4.2.89 UPDATE 4.2.89.1 UPDATE - Update executing RPs Allows for the immediate or deferred update of executing RPs with the modifications entered. The possible values for this parameter are: *IMMED Any modifications to the Webulator/400 configuration will be reflected in the request processors that are currently executing. Each RP will be updated upon the next request processed. *DEFER Updates will not take effect in the running RPs. You must execute the SETWBLCFG (section 3.1.7 on page 148) (Set Webulator Configuration) command for these modifications to be reflected in the current RP execution. Note: If another configuration command (Configuration Commands on page 134) is executed with the UPDATE(*IMMED) option selected, or if a new request processor is started (either via the STRWBLRP (section 3.1.4 on page 144) command or as the result of a new request that cannot be accommodated by the currently running RPs), the configuration values set here will be reflected in all request processors, even though *DEFER was selected here. Page 261 Webulator/400R User Manual, Version 2.0 5.0 Con 5. Configuration Files Page 262 Webulator/400R User Manual, Version 2.0 5.0 Con 5.1 Configuration Files This information is primarily for those people who wish to edit the configuration files directly (with an editor). Here is information about ways to edit configuration files (section 5.2 on page 265). 5.1.1 Creating a New Configuration File If you want to create a new configuration file (e.g. a user file), you can copy the empty file that is shipped with the server: /Wbl/Cfg/Shipped/Empty.Cfg. You can copy this file using either the WRKLNK command or the CPY command. 5.1.2 Rules About Configuration Files in General . Comments begin with a pound sign ("#") or a semi-colon (";")in the left-most character. . The contents are not case sensitive. . Extra white space (tabs and spaces) will be ignored. . One directive can appear on each line. . Most directives can only have one entry in a configuration file. If one of these directives appears more than once in a configuration file, the last value will be used. 5.1.3 Authority The user profile of the person starting or reconfiguring the server must have read access to all configuration files. The user profile of the server does not need read access to any configuration files. If the configuration commands (Configuration Commands on page 134) are used to change the configuration, the user that runs them must have write access to the configuration files, as well as the temporary (*.tmp) and backup (*.bak) that are created by those commands. 5.1.4 Specific Configuration Files . Master server configuration file (section 5.2.3 on page 265) . Alias configuration file (section 5.2.4 on page 267) Page 263 Webulator/400R User Manual, Version 2.0 5.0 Con . Session based configuration file (section 5.2.5 on page 268) . User authenticaton user stream file (section 5.2.6 on page 269) . User authenticaton user database file (section 5.2.7 on page 270) . User authentication group configuration file (section 5.2.8 on page 270) . User profile user file (section 5.2.9 on page 271) 5.1.5 File Relationships The diagram below shows the relationships between file types. You can click on the image of a file or configuration value to get more information about it. Clicking on the image will only work if this documentation is being accessed through a web server like Web Server/400 (section 1.11 on page 33). Page 264 Webulator/400R User Manual, Version 2.0 5.0 Con 5.2 How to Configure the Server You can configure Webulator/400 through commands (section 3.1 on page 134) or by editing files directly. 5.2.1 Configuring the Server Through Commands Changing configuration through commands is recommended because the system can validate information as you enter it and help to eliminate mistakes. 5.2.2 Configuring the Server by Editing Configuration Files You may also edit configuration files directly, using any editor. You must take care that the server has authority to read the files. By default, the server runs as WBLUSER. If you are editing the files with a PC editor (e.g. EPM, NOTEPAD, EDIT), you may find that the editor writes first to a temporary file, then renaming the temporary file over the original file. This scheme will cause authority information to be lost for the configuration file and Webulator/400 may not be able to read it. Here is information about the configuration file contents and syntax (section 5.1 on page 263). 5.2.3 Master Server Configuration File This file contains configuration information for the Webulator/400 server, as well as file names of other configuration files (section 5.1 on page 263). This is the file that is specified when starting the server (section 3.1.2 on page 136). Also see configuration values by category (section 4 on page 173) and the alphabetical index of values (section 4.2 on page 178). 5.2.3.1 Values Stored in This Configuration File AccessLog (section 4.2.36 on page 215) Access log file path AccessLogCycle (section 4.2.35 on page 213) Access log cycle AliasCfgFile (section 4.2.16 on page 198) Alias file path AutoRPTimeout (section 4.2.52 on page 230) Automatic RP timeout Page 265 Webulator/400R User Manual, Version 2.0 5.0 Con CommerceKeyListFile (section 4.2.62 on page 237) Secure Key List File Path CommerceSessionCacheSize (section 4.2.63 on page 238) Secure Session Cache Size CommerceSessionCacheTimeout (section 4.2.64 on page 238) Secure Session Cache Timeout CommerceSSLPort (section 4.2.65 on page 239) Secure SSL Port ConnectionQueueSize (section 4.2.47 on page 226) Connection queue size ContentCCSID (section 4.2.68 on page 242) Content CCSID DisableServer (section 4.2.69 on page 242) Disable server DomainNameLookup (section 4.2.70 on page 243) Domain name lookup ErrorLog (section 4.2.38 on page 218) Error log file path ErrorLogCycle (section 4.2.37 on page 216) Error log cycle ErrorLogLevel (section 4.2.39 on page 219) Error logging level FallthruRootHTTP (section 4.2.21 on page 202) Fall-thru path for HTTP FallthruRootSSL (section 4.2.22 on page 203) Fall-thru path for SSL GlobalAccessCfgFile (section 4.2.12 on page 194) Session based configuration file path InitialLibraryList (section 4.2.71 on page 245) Initial Library List InitialRPs (section 4.2.48 on page 226) Initial request processors KbdPluginLoc (section 4.2.23 on page 204) Keyboard plugin location MaxRPs (section 4.2.49 on page 227) Maximum request processors Page 266 Webulator/400R User Manual, Version 2.0 5.0 Con MaxWebulatorSessions (section 4.2.79 on page 253) Maximum Webulator sessions MultiHome (section 4.2.72 on page 245) Multiple home PasswordStorage (section 4.2.5 on page 187) Authentication Password Storage Port (section 4.2.77 on page 251) Socket Port ServerHostName (section 4.2.73 on page 247) Server host name ServerIdentifier (section 4.2.74 on page 248) Server Identifier ServerProtocols (section 4.2.75 on page 249) Server Protocols ServerRoot (section 4.2.20 on page 201) Server root path SslVersion (section 4.2.66 on page 240) SSL Version TemporaryDirectory (section 4.2.78 on page 252) Temporary Directory Timeout (section 4.2.51 on page 229) Timeout UserProfile (section 4.2.76 on page 250) Server user profile WaitThreshold (section 4.2.50 on page 228) Request wait timeout WebulatorUsrFile (section 4.2.80 on page 253) Webulator user file path 5.2.3.2 Command to Work With This File . CHGWBLSVR (section 3.1.6 on page 147) 5.2.4 Alias Configuration File This file is used to configure all Webulator/400 aliases (section 2.6 on page 51). Page 267 Webulator/400R User Manual, Version 2.0 5.0 Con Also see configuration values by category (section 4 on page 173), alphabetical index of values (section 4.2 on page 178) and other configuration files (section 5.1 on page 263). 5.2.4.1 Values Stored in This Configuration File Alias (section 4.2.15 on page 197) Configures an alias 5.2.4.2 Commands to Work With This File . WRKWBLALS (section 3.1.10 on page 151) . ADDWBLALS (section 3.1.11 on page 152) . CHGWBLALS (section 3.1.12 on page 152) . DLTWBLALS (section 3.1.13 on page 153) 5.2.5 Session Based Configuration File This file is used to configure access control and Webulator session behaviors. The file can contain zero or more session sections. Each session section can also contain entries relating to authority, parsed buttons, virtual keyboard rows, and protocol specifications. If this file is not specified, all access will be granted. Also see Protecting Your AS/400 Information (section 2.9 on page 98), session based configuration file path (section 4.2.12 on page 194) and configuration values by category (section 4 on page 173). 5.2.5.1 Directives Supported Within This File: . (section 4.2.11 on page 193) . AllowedProtocols (section 4.2.67 on page 241) . AuthGroupFile (section 4.2.3 on page 185) . AuthName (section 4.2.4 on page 186) . AuthType (section 4.2.6 on page 188) . AuthUserFile (section 4.2.8 on page 189) . Signon (section 4.2.81 on page 254) . BackgroundImage (section 4.2.54 on page 231) . BackgroundColor (section 4.2.53 on page 231) . HeaderFile (section 4.2.56 on page 233) . FooterFile (section 4.2.55 on page 232) . ExtendedInputField (section 4.2.25 on page 206) . ColorConversion (section 4.2.40 on page 220) . TermColor (section 4.2.18 on page 200) . TermSize (section 4.2.19 on page 200) Page 268 Webulator/400R User Manual, Version 2.0 5.0 Con . MenuType (section 4.2.42 on page 222) . TerminationConfirmation (section 4.2.87 on page 260) . TerminationUrl (section 4.2.88 on page 260) . FieldLevelPrompting (section 4.2.26 on page 206) . TermTimeout (section 4.2.85 on page 258) . LightPenImage (section 4.2.27 on page 207) . ParsedButton (section 4.2.44 on page 223) . HorizontalRuleLocation (section 4.2.57 on page 234) . ReverseImageSpaceCharacter (section 4.2.45 on page 224) . TablesEnabled (section 4.2.61 on page 236) . TableWidth (section 4.2.60 on page 236) . TableFontName (section 4.2.59 on page 235) . SendJavaScript (section 4.2.17 on page 199) . FontSize (section 4.2.41 on page 221) . ShowBlankLines (section 4.2.58 on page 234) . TerminateUponSignoff (section 4.2.84 on page 258) . UpperToLowerConvert (section 4.2.24 on page 205) . EnableKeyboardPlugin (section 4.2.29 on page 208) . ShowKeyboardPluginButtons (section 4.2.30 on page 209) . SubfileScrolling (section 4.2.43 on page 223) . TermJobCCSID (section 4.2.28 on page 208) . TermDeviceCCSID (section 4.2.46 on page 225) . TermInhibitedTimeout (section 4.2.86 on page 259) . (section 4.2.33 on page 211) . RowBtn (section 4.2.31 on page 210) . (section 4.2.32 on page 210) . order (section 4.2.13 on page 195) . allow (section 4.2.1 on page 182) . deny (section 4.2.9 on page 190) . require (section 4.2.14 on page 196) . (section 4.2.10 on page 192) 5.2.5.2 Commands to Work With This File . WRKWBLSSN (section 3.1.23 on page 158) . CHGWBLSSN (section 3.1.24 on page 160) 5.2.6 User Authenticaton User Stream File This file contains user entries (section 4.2.7 on page 188) for user authentication. It is referenced by the session based configuration file (section 5.2.5 on page 268). This file is in stream file format and is read into memory by each Webulator/400 request processor. To migrate stream files into database files, you can use the MIGWBLUSR (section 3.1.18 on page 155) command. Page 269 Webulator/400R User Manual, Version 2.0 5.0 Con 5.2.6.1 Commands to Work With This File . WRKWBLAUT (section 3.1.14 on page 153) . ADDWBLAUT (section 3.1.15 on page 154) . CHGWBLAUT (section 3.1.16 on page 154) . DLTWBLAUT (section 3.1.17 on page 154) Also see Protecting Your AS/400 Information (section 2.9 on page 98). 5.2.7 User Authenticaton User Database File This file contains user entries (section 4.2.7 on page 188) for user authentication. It is referenced by the session based configuration file (section 5.2.5 on page 268). This file is in a database file format and rather than being read into memory by each Webulator request processor, it is accessed when checking authenticated requests. To migrate stream files into database files, you can use the MIGWBLUSR (section 3.1.18 on page 155) command. 5.2.7.1 Commands to Work With This File . WRKWBLAUT (section 3.1.14 on page 153) . ADDWBLAUT (section 3.1.15 on page 154) . CHGWBLAUT (section 3.1.16 on page 154) . DLTWBLAUT (section 3.1.17 on page 154) Also see Protecting Your AS/400 Information (section 2.9 on page 98). 5.2.8 User Authentication Group Configuration File This file contains group entries (section 4.2.2 on page 184) for user authentication. It is referenced by a session based configuration file (section 5.2.5 on page 268). If you wish, you can put the same group name on multiple lines. The server will treat it as if you had entered all group members on the same line. 5.2.8.1 An Example File Development: John Bill Greg Anne Development: Marc Neil Paul Testing: Dave Geoffrey Gu Page 270 Webulator/400R User Manual, Version 2.0 5.0 Con The file above describes two groups: Development and Testing. Also see Protecting Your AS/400 Information (section 2.9 on page 98). 5.2.9 Webulator/400 User Profile File This file contains Webulator user profile entries (section 4.2.82 on page 256). Because the passwords are not encrypted, you should protect this file with OS/400 authority. Only the user who changes the file and the user who starts the server needs authority to the file. The server user profile (section 4.2.76 on page 250) should NOT have authority to this file. Note that only AS/400 user names that are needed for automatic signon of Webulator/400 sessions should appear in this file. The file WblUser.Cfg is installed in the /Wbl/Cfg/Auth directory for extra protection. Commands modifying this file will create backup and temporary files (WblUser.bak and WblUser.tmp), which you don't want users to see. The /Wbl/Cfg/Auth directory is protected to discourage this. 5.2.9.1 Example Entry WblUsr WblPass The above example shows an entry that allows automatic signon for the user WblUsr with the password WblPass. 5.2.9.2 Commands to Work With This File . WRKWBLPRF (section 3.1.19 on page 156) . ADDWBLPRF (section 3.1.20 on page 157) . CHGWBLPRF (section 3.1.21 on page 157) . DLTWBLPRF (section 3.1.22 on page 158) Page 271