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 compatib