Content

The WebFacing server can be configured by adding configuration parameters to the server's data area QQFCONFIG found in library QQFTEMP. When the server starts, a new data area is created if one does not already exist. The following two configuration parameters are currently supported:

• SBS to specify the number of subsystems the server uses to run user jobs.
• TXW to specify the amount of time the server waits for long-running transactions.

The server sets the initial default configuration to the following values: SBS=01;TXW=05;

Long-running transaction timeout

By default, the WebFacing server waits five minutes for a transaction with the user job to complete. If a response for a transaction has not been received during this time, the user job is terminated and the WebSphere resources servicing the client are released. The five-minute timeout ensures that WebSphere resources are made available to service other clients. While long-running transactions are not appropriate for the Web, WebFacing customers might occasionally need to run such transactions during periods of updates to their databases.

This scenario is supported by configuring the server as follows:
The WebFacing server allows a Transaction Wait Time to be configured in the server's QQFTEMP/QQFCONFIG data area. TXW is the configuration keyword for the Transaction Wait Time with syntax as shown below. The time value is entered in minutes followed by a semi-colon. The default wait time is five minutes if the TXW keyword is not set in the configuration area. TXW is the configuration keyword for the Transaction Wait Time. The syntax of the TXW configuration keyword is shown below:

Data area . . . . . . . :   QQFCONFIG
  Library . . . . . . . :     QQFTEMP

Type  . . . . . . . . . :   *CHAR
Length  . . . . . . . . :   1024
Text  . . . . . . . . . :   CFG DATA

            Value
Offset
            *...+....1....+....2....+...
     0      'SBS=01;TXW=6;
    50      '

After configuring the data area, restart the server. A configuration message in the server's QQFWFSVR job is logged:

MAXIMUM TRANSACTION WAIT TIME: TXW = XX MINUTES

When a long-running transaction is detected, the server issues an informational message after five minutes:

WAITING FOR LONG RUNNING TRANSACTION IN JOB QQFNNNNNN

The server will continue to wait for the transaction up to the configured wait time. Messages are issued when the long-running transaction times out or completes normally:

LONG RUNNING TRANSACTION IN JOB QQFNNNNNNN TIMED-OUT AFTER XXX SECONDS

LONG RUNNING TRANSACTION IN JOB QQFNNNNNNN COMPLETED

Background information

The following information provides some background on how application servers and the WebFacing server work and handle long-running transactions. This information might provide some guidance as to what additional manual intervention might be required in your case if long-running transactions are used.

Web servers, both application servers such as IBM® WebSphere® Application Server (WAS) and the WebFacing server, are designed with the intention that browser requests are handled quickly (in a few seconds or less). A typical application server runs with a small pool of threads that are used to quickly handle an incoming request, and then are freed to be ready for the next request. When a long-running transaction is taking place, it is monopolizing a thread on the application server as well as the port or ports while the transaction is running. If too many long-running transactions are taking place, the perceived response time to the browser increases as requests are queued for the remaining available threads.

The WebFacing server will not interrupt a transaction unless the transaction timeout expires. Meaning if a long-running transaction is active and the user initiates a *logoff from a browser (by a programmed link or by closing the browser), the *logoff is not processed until the currently active transaction is complete. The implication is that if the user job is no longer responding and a very long transaction timeout has been configured, the user job might have to be ended manually.

Profile-derived device configuration

Previously, WebFacing devices were created based on the system value for QLANGID and the character set and codepage obtained from QCHRID. Basing WebFacing device characteristics on system values prevents WebFacing from supporting profiles defined for different languages, independent of system settings.

Currently, WebFacing devices are created based on the user profile settings for LANGID and the character set and codepage associated with the specified CCSID.

Note: The character set and codepage that are used are derived by calling an operating system function with the CCSID specified in the user profile. For some special CCSID values such as 65536, valid character set and codepage values are not returned. This can cause a device to be created that is not compatible with other system settings. When this occurs, the WebFacing user job cannot be started. This can be diagnosed by looking for messages in the WebFacing server joblogs.
Multiple interactive subsystems

Depending on the number of users and the number of WebFacing jobs that are created on your system, you might want to configure additional interactive subsystems to handle WebFacing jobs. Using multiple interactive subsystems improves the scalability of WebFacing by:

• Increasing the total number of WebFacing jobs that can be run on your machine.
• Load balancing so that WebFacing jobs are assigned in a distributed manner spread optimally among configured subsystems.

Up to 16 additional subsystems can be configured for WebFacing. If no other subsystems are configured, WebFacing jobs run in the QINTER subsystem. Assess the need for using additional subsystems based on your knowledge of how many users you have and the capabilities of your hardware. Remember that an interactive job is created for each user logon whether the logon is through a 5250 session or a WebFacing session. Note that when additional subsystems are configured for WebFacing, QINTER is no longer used for WebFacing interactive jobs.

WebFacing interactive jobs are named QQFn* where n represents the subsystem that is being used in a sequence of up to 16. The value for n follows hex numbering conventions. In hex, the first 10 values for n are represented with the numbers 0 through 9, and the next six values (values 10 to 15) are represented with the letters A through F. For example, names for jobs in the first subsystem begin with QQF0*, and names for jobs in the twelfth subsystem begin with QQFB*. If no additional subsystems are configured, WebFacing interactive jobs can be identified in the QINTER subsystem by names beginning with the string QQF0*.

To configure the WebFacing server to use multiple subsystems, perform the following steps:

1. If necessary, modify the QINTER subsystem so that WebFacing jobs are no longer processed there. This is required if *ALL is the value currently used in the Work station name field for Work Station Entry values in QINTER. Use the DSPSBSD command to view your current settings. If required, replace *ALL with the display device name convention used for your system. For example, some systems use QPADEV*.


2. Create additional interactive subsystems for WebFacing jobs. These subsystems should be modelled after QINTER. Create these subsystems by creating subsystem descriptions using the CRTSBSD command.


3. When the WebFacing server is installed, a data area called QQFCONFIG is created for it in the library QQFTEMP. Change the SBS value in the QQFTEMP/QQFCONFIG data area to the number of interactive subsystems to be used for WebFacing. In this data area, a default name/value pair of SBS=01; is created to define the number of interactive subsystems to be used for WebFacing. To change the default value, use the command WRKDTAARA DTAARA(QQFTEMP/QQFCONFIG). Select option 2=Change, and then in the New value field type SBS=nn; where nn is the number of subsystems you will be using for WebFacing. This can be a number from 1 to 16; for example, SBS=16;. Although you type the value in decimal notation, at run time the SBS number is displayed in hexadecimal format. If you want to display your current values, use the command DSPDTAARA DTAARA(QQFTEMP/QQFCONFIG).


4. Using the ADDWSE command, add work station entries for WebFacing for each additional subsystem that you are going to use. Populate the Work station name field of the Add Work Station Entry screen with the WebFacing device name to be used for that subsystem. Follow the hex numbering conventions described earlier in this document to determine what values to use. Hex values for the first 10 subsystems are 0 to 9. Hex values for the next six subsystems (10 to 15) are A to F. For example, in the ADDWSE screen for the first subsystem, type QQF0*. For the second subsystem, type QQF1*. For the sixteenth subsystem, type QQFF*.


5. For these changes to take effect stop, and then restart the WebFacing server. For V4R5, use the command ENDWFSVR to stop the WebFacing server; use the command STRWFSVR to start the server. For V5R1 and later, use the command ENDTCPSVR SERVER(*WEBFACING)to stop the WebFacing server; use the command STRTCPSVR SERVER(*WEBFACING)to start the server.