HP NonStop Server Guide for BEA WebLogic Server 8.1

Size: px
Start display at page:

Download "HP NonStop Server Guide for BEA WebLogic Server 8.1"

Transcription

1 HP NonStop Server Guide for BEA WebLogic Server 8.1 Abstract This manual describes the installation, configuration, and management of the BEA WebLogic Server on HP Integrity NonStop NS-series servers. Product Version HP Integrity NonStop Server Toolkit for BEA WebLogic Server 8.1 SP3 Supported Release Version Updates (RVUs) This manual supports H06.03 and all subsequent H-series RVUs until otherwise indicated by its replacement publication. Part Number Published July 2005

2 Document History Part Number Product Version Published HP Integrity NonStop Server Toolkit for BEA WebLogic Server 8.1 SP3 July 2005

3 HP NonStop Server Guide for BEA WebLogic Server 8.1 Glossary Index Examples Figures Tables What s New in This Manual v Manual Information v New and Changed Information Legal Notice v v About This Manual vii Who Should Read This Guide vii Organization of This Manual vii Related Documentation viii Notation Conventions viii 1. Introduction The WebLogic Server for the HP NonStop Server 1-1 Server-Specific Features 1-2 Specific Enhancements 1-2 Native Socket Multiplexer 1-3 High Level Architecture 1-6 Differences Between SMP Systems and HP NonStop Servers Installation 3. Migration 4. Configuring Persistent WebLogic Server Processes Overview of Generic Processes 4-2 Considerations 4-2 Configuration 4-2 Automatic Restart 4-2 Sample Scripts 4-3 Managed Servers 4-3 Generic Process Attributes 4-4 Hewlett-Packard Company i

4 Contents 4. Configuring Persistent WebLogic Server Processes (continued) 4. Configuring Persistent WebLogic Server Processes (continued) Sample Shell Scripts and TACL Macros 4-5 startgp.sh 4-5 startgp.tacl 4-6 Scripts to Start the WebLogic Server Process 4-6 stopgp.sh and stopgp.tacl 4-7 Using the Node Manager on the NonStop Server 4-7 Starting a Managed Server Through the Node Manager 4-8 nodemanager.sh 4-8 CPUselector 4-9 gname_load 4-10 jvm_load 4-10 managed_load 4-10 no_load 4-11 Configuring the Node Manager 4-11 Settings 4-11 Step 1. Create a Machine and Associate Servers To It 4-11 Step 2. Generate Node Manager Configuration Files 4-12 Step 3. Configure and Start the Node Manager 4-12 Step 4. Configure Managed Servers Startup Options 4-13 Step 5. Start Managed Servers Using the Node Manager 4-13 Step 6. Monitor Startup of the Managed Server 4-14 Troubleshooting and Notes 4-14 Starting the Node Manager from a Non-Default Location 4-15 Shutting Down a WebLogic Server Application Configuring JTA 6. XA Resource Manager (XARM) Configuring the WebLogic Server XA Resource Object 6-2 Configuring the XA Resource Manager Error Output Destination 6-3 Configuring the WLSNonStopTxHelper as a Startup Class 6-3 Configuring the JDBC Connection Pools for SQL/MX 6-5 Configuring the WebLogic Server Data Sources for SQL/MX 6-8 Additional Considerations for JDBC Access to SQL/MX DataBases 6-9 ii

5 Contents 7. Configuring JDBC Stores for JMS 7. Configuring JDBC Stores for JMS 8. Using the WS Plug-in Comparison of RLS and WS Plug-in 8-1 Overview 8-1 Using DBACCESS Table 8-1 Routing to Replicated Applications 8-2 Load Balancing 8-2 Tracking Failed Target Application Server Processes 8-2 Passthrough and Redirect Modes 8-2 Requirements 8-3 Compatibility 8-3 Background 8-3 Architecture 8-4 Installing and Building the WS Plug-in Start an OSS Shell Run the WS Plug-in Script Change the Directory Configuring WebLogic Server Applications and Clusters Create the Database and Build the WS Plug-in Modify the WS Plug-in Configuration Restart itp Secure WebServer 8-6 Configuring the WS Plug-in 8-7 Defining the WS Plug-in Server Class 8-7 WS Plug-in Configuration Tool 8-11 Configuring the itp WebServer to Process Static Content 8-16 Creating the Database 8-17 Modifying the Database 8-21 Migration Considerations 8-22 WS Plug-in Event Messages (5000 through 5024) 8-22 Troubleshooting Managing the SQL/MX Tables for BLOB and CLOB Data Creating SQL/MX Tables 9-1 Providing Properties to the JDBC Driver Sample Application WebLogic Server Sample Application 10-1 Running MedRec Application in the Installed WebLogic Server Location 10-1 Running MedRec in Another Location 10-5 iii

6 Contents 11. Deploying Applications Built in WebLogic Workshop 11. Deploying Applications Built in WebLogic Workshop Install WebLogic Server 8.1 SP3 on Your Workstation 11-1 Create a Domain to Run the Application 11-1 Map the NonStop Server 11-1 Set the Application Properties 11-2 Verify Your Setup 11-5 A. Script Options Usage check-wl-hpns.sh A-1 install-wl-hpns.sh A-2 uninstall-wl-hpns.sh A-3 Glossary Index Examples Example 4-1. Example Server Environment File 4-9 Example 8-1. Default RLS Server Class Definition 8-7 Example 8-2. Server Class Definition for WS Plug-in 8-8 Example 8-3. WS Plug-in Statistics Output 8-9 Figures Tables Figure 1-1. Socket Reader Polling 1-4 Figure 1-2. Single Thread Polling 1-5 Figure 1-3. WebLogic Server on NonStop Server Architecture 1-6 Figure 1-4. WebLogic Server Domain Representation on a 4-Way SMP Machine 1-7 Figure 1-5. WebLogic Server Domain Representation on a NonStop Server 1-8 Figure 8-1. Information Flow Using WS Plug-in 8-5 Figure Initial MedRec Screen 10-4 Figure MedRec Logon Screen 10-5 Figure Mapping the NonStop Server 11-2 Figure New Application Dialog Box 11-3 Figure Application Properties 11-4 Figure Application Properties with Corrected Values 11-5 Table 4-1. Generic Process Attributes Table 4-4 Table 6-1. Java System Properties Used by WLSNonStopTxHelper 6-4 iv

7 What s New in This Manual Manual Information Abstract WebLogic Server for the HP NonStop Server Platform Guide This manual describes the installation, configuration, and management of the BEA WebLogic Server on HP Integrity NonStop NS-series servers. Product Version HP Integrity NonStop Server Toolkit for BEA WebLogic Platform 8.1 SP3 Supported Release Version Updates (RVUs) This manual supports H06.03 and all subsequent H-series RVUs until otherwise indicated by its replacement publication. Part Number Published July 2005 Document History Part Number Product Version Published HP Integrity NonStop Server Toolkit for July 2005 BEA WebLogic Server 8.1 SP3 New and Changed Information This manual is new for the H-series. Previous editions were specific to the G-series. Legal Notice WebLogic Server is a registered trademark of BEA Systems, Inc. v

8 What s New in This Manual Legal Notice vi

9 About This Manual This guide describes: The BEA WebLogic Server for the HP Integrity NonStop NS-series servers How to install the BEA WebLogic Server 8.1 SP3 on HP NonStop servers Possible configurations The XA Resource Manager The WS Plug-in Avitek Medical Records (or MedRec) sample application suite that is run with WebLogic Server Who Should Read This Guide This documentation is intended for: Users who install and set up the WebLogic Server Users who administer the WebLogic Server after it is installed Note. This guide describes only the NonStop server differences and additions that allow BEA WebLogic Server to work on the NonStop platform. The reader must be fully familiar with the BEA WebLogic Server 8.1 documentation, which is located at the following URL: Organization of This Manual Section 1, Introduction, describes the WebLogic Server features and the WebLogic Server-specific enhancements to the NonStop server platform. Section 2, Installation, provides a link to the installation instructions. Section 3, Migration, discusses migrating from WebLogic Server 8.1 SP2 on the MIPs platform (TNS/R) to WebLogic Server 8.1 SP3 on the Intel Itanium Processor based platform (TNS/E). Section 4, Configuring Persistent WebLogic Server Processes, describes the generic process and its use with the WebLogic Server. A step-by-step procedure about how to configure the Node Manager is included. Sample shell scripts and TACL macros are also described. Section 5, Configuring JTA, discusses configuring the JTA. Section 6, XA Resource Manager (XARM), describes the WebLogic Serverspecific XA resource facilities and various configurations. vii

10 About This Manual Related Documentation Section 7, Configuring JDBC Stores for JMS, explains how the JMS Server can be configured to use a JMS JDBC store. Section 8, Using the WS Plug-in, explains how to use the WS Plug-in. Section 9, Managing the SQL/MX Tables for BLOB and CLOB Data, discusses managing BLOB and CLOB data. Section 10, Sample Application, discusses Avitek Medical Records (or MedRec), a sample reference application that demonstrates the BEA WebLogic Server features. Section 11, Deploying Applications Built in WebLogic Workshop, explains how to run your application that was built in WebLogic Workshop. Appendix A, Script Options Usage, lists options for shell scripts used to check, install, and uninstall software. Related Documentation This guide should be used with: The BEA suite of documentation on the WebLogic Server located at SCF Reference Manual for the Kernel Subsystem (describes the generic process mechanism), located in the NonStop Technical Library (NTL) NonStop TCP/IPv6 documentation, located in NTL TMF product documentation, located in NTL NonStop SQL/MX documentation, located in NTL itp WebServer documentation, located in NTL SQL/MX Comparison Guide for SQL/MP Users, located in NTL Java documentation, located in NTL Notation Conventions Hypertext Links Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example: See to Section 6, XA Resource Manager (XARM) for information about the XA resource manager. viii

11 About This Manual General Syntax Notation General Syntax Notation This list summarizes the notation conventions for syntax presentation in this manual. UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: MAXATTACH lowercase italic letters. Lowercase italic letters indicate variable items that you supply. Items not enclosed in brackets are required. For example: file-name computer type. Computer type letters within text indicate C and Open System Services (OSS) keywords and reserved words. Type these items exactly as shown. Items not enclosed in brackets are required. For example: myfile.c italic computer type. Italic computer type letters within text indicate C and Open System Services (OSS) variable items that you supply. Items not enclosed in brackets are required. For example: pathname [ ] Brackets. Brackets enclose optional syntax items. For example: TERM [\system-name.]$terminal-name INT[ERRUPTS] A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list can be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: FC [ num ] [ -num ] [ text ] K [ X D ] address Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in brackets or braces. For example: INSPECT { OFF ON SAVEABEND } Item Spacing. Spaces shown between items are required unless one of the items is a punctuation symbol such as a parenthesis or a comma. For example: CALL STEPMOM ( process-id ) ; ix

12 About This Manual General Syntax Notation If there is no space between two items, spaces are not permitted. In this example, no spaces are permitted between the period and any other items: $process-name.#su-name Line Spacing. If the syntax of a command is too long to fit on a single line, each continuation line is indented three spaces and is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example: ALTER [ / OUT file-spec / ] LINE [, attribute-spec ] x

13 1 Introduction The WebLogic Server for the HP NonStop Server Server-Specific Features Specific Enhancements Native Socket Multiplexer High Level Architecture Differences Between SMP Systems and HP NonStop Servers The WebLogic Server for the HP NonStop Server The WebLogic Server is a standards-based J2EE application server that provides a foundation for building applications and includes: Load balancing Fault tolerance Web services Network transparency Legacy integration Transaction management Security Multi-threading Persistence Database connectivity Resource pooling Development, testing, and packaging facilities The WebLogic Server uses the Java platform for portability to a large number of operating platforms supporting the Java platform. The WebLogic Server 8.1 SP3 is certified by BEA on HP NonStop servers. On properly configured HP NonStop servers, the WebLogic Server runs unchanged just like on other platforms. 1-1

14 Introduction Server-Specific Features Server-Specific Features HP provides the following NonStop server-specific features to the WebLogic Server: An XA resource manager for the HP NonStop Transaction Management Facility (TMF) facility so that NonStop server resources can participate in global transactions coordinated by the WebLogic Server transaction managers. Refer to Section 6, XA Resource Manager (XARM) for information. An HP NonStop Server Toolkit for BEA WebLogic Server 8.1 SP3 (NonStop Server Toolkit) containing: A Java XA resource object adapted specifically for the WebLogic Server so that NonStop server resources can participate in WebLogic Server global transactions. An XA wrapper to the Java Database Connection (JDBC) drivers for the HP NonStop SQL/MX (SQL/MX) database so those drivers can be used in the WebLogic Server components needing XA-compliant JDBC data sources. Transaction helpers and dummy XA resource objects to be used by the XA wrappers for the JDBC drivers. The WS Plug-in, which supports stateful dialogs between web clients (usually a browser) and J2EE application servers. It also supports more sophisticated load balancing and configuration options. The WS Plug-in also supports web applications that utilize session-based dialogs. Refer to Section 8, Using the WS Plug-in for information. Avitek Medical Records (or MedRec) sample application suite that works with the WebLogic Server. Refer to Section 10, Sample Application for information. Documentation for supporting various software pieces that form the NonStop Server Toolkit. Note. Applications using WebLogic Server must use SQL/MX to access NonStop SQL tables. Access to these tables is not supported for programs using HP NonStop SQL/MP (SQL/MP). For information about the differences between SQL/MX and SQL/MP, see SQL/MX Comparison Guide for SQL/MP Users. Specific Enhancements WebLogic Server clusters use UDP multicast-based communications for cluster heartbeat monitoring and propagation of the Java Naming and Directory Interface (JNDI) tree to the members of a cluster. The WebLogic Server transaction manager coordinates global transactions with branches contracted to TMF through the Java XA resource object. Since the WebLogic Server usually accesses only TMF protected resources on the NonStop server, the WebLogic Server transaction manager s logging and recovery activities 1-2

15 Introduction Native Socket Multiplexer must be efficient. To this end, the TMF product has been enhanced to support onephase commit optimization for imported branches. SQL/MX SPR 2.0 is HP s next generation relational database management system designed for business-critical applications. SQL/MX software brings traditional NonStop fundamentals high availability, scalability, reliability, and parallel processing to a distributed database. The WebLogic Server 8.1 Service Pack 3 is available for the NonStop server. This version of the WebLogic Server depends on Java 2 Standard Edition Version 1.4.2_04. The NonStop Server for Java 4 has been updated to conform to this. Refer to Java documentation for more information. Native Socket Multiplexer The WebLogic Server allows two mechanisms for network socket I/O a pure Java socket reader implementation and a platform-optimized native socket multiplexer. Benchmarks show major performance improvements when using the native multiplexer. Below are details of the two implementations and the advantages of the native implementation over the pure Java implementation. Prior to Java 2 Standard Edition Platform 1.4.1_05, there was no facility within the Java Platform for a thread to initiate and poll asynchronous I/O operations (similar to the UNIX select (2) system call). To work around this, the WebLogic Server product provides a pure Java socket multiplexer that simulates polling functionality. This polling is implemented by using multiple dedicated threads polling for each of the sockets for data (by specifying a timeout for the I/O operation). The polling socket readers are always busy, polling for data even when there is no data to read, thereby incurring unnecessary overhead. The performance issue is more visible when there are more sockets than socket readers. In this case, each of the socket readers has to poll multiple sockets, which can result in situations where a socket with data is not processed immediately while the reader is blocked on data from a socket that has no data, thereby delaying the servicing of sockets. Figure 1-1 illustrates this scenario. There are three socket readers, SR1, SR2, and SR3. There are six open sockets (SP1 through SP6). Sockets SP1, SP3, and SP6 have data and the others do not. The socket readers are polling sockets SP2, SP3, and SP4. Socket reader SR2 immediately detects data on socket SP3 and processes it, whereas the other socket readers are blocked for a chosen polling timeout period before they move to poll other 1-3

16 Introduction Native Socket Multiplexer sockets. Sockets SP1 and SP6, though ready with data, are not serviced immediately, whereas the socket readers are polling sockets SP2 and SP4 without data. Figure 1-1. Socket Reader Polling SR1 SR2 SR3 SP1 SP2 SP3 SP4 SP5 SP6 VST003.vsd Another potential aspect of the Java socket multiplexer implementation, which has an impact on the overall performance of the WebLogic Server application, is the use of the kernel execute queue. The kernel execute queue is configured with threads that are used to perform server internal functions and also application request processing. When the pure Java socket multiplexer is used, the number of socket readers is expressed as a percentage of the kernel default execute queue, thus reducing the number of threads that can service other requests. To overcome this, a native socket multiplexer facility is implemented in the WebLogic Server product. This native socket multiplexer eliminates the need to poll the sockets by providing a set of dedicated poller threads. These threads call native code (hence the name native socket multiplexer) implemented in C and C++ to use the host operating system-specific facility to wait for I/O events on the sockets. As shown in Figure 1-2, a single thread, N1, waits for I/O events on all the active sockets S1 through S6. Whenever an I/O event is triggered in any of the sockets, the thread is notified of the event by the operating system. The thread wakes up to service the I/O event on the socket. This greatly reduces the unnecessary overhead in polling 1-4

17 Introduction Native Socket Multiplexer the sockets and thus reduces the processor resource utilization by the WebLogic Server. Figure 1-2. Single Thread Polling Native Socket Reader Thread N1 SP1 SP2 SP3 SP4 SP5 SP6 VST004.vsd Another advantage of the native socket implementation is the usage of the kernel execute queue. Unlike the pure Java multiplexer, the native socket polling threads are managed using a separate execute queue distinct from the default kernel queue. Therefore, the kernel execute queue threads are all used to handle application requests, which helps in better performance at reduced resource utilization. 1-5

18 Introduction High Level Architecture High Level Architecture The WebLogic Server provides standards-based access to NonStop server resources protected by TMF. The XA resource object facilitates transactional access of NonStop server resources within the scope of the WebLogic Server global transaction. The WebLogic Server uses the generic process support in the NonStop server to monitor and manage the Node Manager and the Administration Server (There is one Node Manager for each NonStop server node, and one Administration Server for each WebLogic Server domain.). Figure 1-3. WebLogic Server on NonStop Server Architecture Applications WebLogic Server - J2EE Services Process Management Communications Network Management Load Balancing and Failover WebLogic Transaction Manager XARM NonStop Server Resources SQL/MX Enscribe NonStop JMS others NonStop Server for Java TMF Transaction Management and DB Integration NonStop Kernel Generic process support for managing node manager and admin server. 1-6

19 Introduction Differences Between SMP Systems and HP NonStop Servers Differences Between SMP Systems and HP NonStop Servers A WebLogic Server domain deployment on a traditional SMP system can be viewed as presented below. The Administrative Server, Managed Servers as part of a cluster, Managed Servers independent of clusters, and Node Manager all run on a single SMP machine. The threads of all these Java Virtual Machine (JVM) instances can be scheduled on all the available processors (see Figure 1-4). Fault tolerance is not built into these systems. Loss of a processor can bring down the entire system along with all the instances running on the machine. Until the transaction logs and other critical components are recovered on a configured backup system, significant application outages can occur. Figure 1-4. WebLogic Server Domain Representation on a 4-Way SMP Machine Administrative Server Managed Server (part of a cluster) Managed Server (part of a cluster) Managed Server (part of a cluster) Managed Server (independent of cluster) Node Manager Managed Server (independent of cluster) Managed Server (part of a cluster) 4-way SMP Machine VST001.vsd 1-7

20 Introduction Differences Between SMP Systems and HP NonStop Servers The same domain (without any specific direction from the WebLogic Server domain administrator) can be deployed transparently: Figure 1-5. WebLogic Server Domain Representation on a NonStop Server Administrative Server Managed Server (part of a cluster) Managed Server (part of a cluster) Managed Server (part of a cluster) CPU 0 CPU 1 CPU 2 CPU 3 Managed Server (independent of cluster) Node Manager Managed Server (independent of cluster) Managed Server (part of a cluster) VST002.vsd The WebLogic Server instances are distributed across all the available CPUs (which are loosely coupled). A JVM and all its threads run within the CPU where the JVM was started, so, when a CPU is lost, only WebLogic Server instances running on that CPU are affected. WebLogic Server instances on other CPUs are not affected. The WebLogic Server instances on the failed CPU can be automatically restarted on other CPUs without reconfiguration and migration requirements. Fault-tolerance is provided by every component (such as TCP/IP, TMF, and SQL/MX) so the WebLogic Server application on a NonStop server is always available. Moreover, the Node Manager and Administration Server are monitored to restart automatically if the processor they run on fails (or the process itself fails for other reasons). This method provides continued availability of monitoring and management services. The deployment benefits of the NonStop server, such as tight integration with the faulttolerant transaction manager, massively scalable relational database, and TCP/IP are transparently provided to the WebLogic Server application when deployed on a NonStop server. 1-8

21 2 Installation For information on how to install the BEA WebLogic Server 8.1 SP3 on HP NonStop servers, go to: 2-1

22 Installation 2-2

23 3 Migration There are no application changes required to migrate from WebLogic Server 8.1 SP2 on the MIPs platform (TNS/R) to WebLogic Server 8.1 SP3 on the Itanium-based NonStop servers (TNS/E). For general migration information, refer to the H-Series Application Migration Guide, located in NTL. 3-1

24 Migration 3-2

25 4 Configuring Persistent WebLogic Server Processes Overview of Generic Processes Considerations Configuration Automatic Restart Sample Scripts Managed Servers Generic Process Attributes Sample Shell Scripts and TACL Macros startgp.sh startgp.tacl Scripts to Start the WebLogic Server Process stopgp.sh and stopgp.tacl Using the Node Manager on the NonStop Server Starting a Managed Server Through the Node Manager nodemanager.sh CPUselector gname_load jvm_load managed_load no_load Configuring the Node Manager Settings Step 1. Create a Machine and Associate Servers To It Step 2. Generate Node Manager Configuration Files Step 3. Configure and Start the Node Manager Step 4. Configure Managed Servers Startup Options Step 5. Start Managed Servers Using the Node Manager Step 6. Monitor Startup of the Managed Server Troubleshooting and Notes Starting the Node Manager from a Non-Default Location Shutting Down a WebLogic Server Application The WebLogic Server supports three process types: Administration Server Managed Server Node Manager In a typical production application on the HP NonStop server, it is assumed that all three process types are present on a single system. Specifically, there is an 4-1

26 Configuring Persistent WebLogic Server Processes Overview of Generic Processes Administration Server controlling a set of Managed Servers. This is often configured as a cluster. There is also a Node Manager to start and stop the Managed Servers. To provide persistence on UNIX platforms, BEA recommends configuring the Administration Server and Node Manager as daemon processes. On the NonStop server, there are several mechanisms that support process persistence. This section describes how to use generic processes to provide process persistence. Overview of Generic Processes For complete documentation about the generic process mechanism, refer to the SCF Reference Manual for the Kernel Subsystem. Generic processes are configured using SCF and started and maintained by the $ZPM persistence manager. A generic process can be configured to start in certain CPUs and to be restarted if the process terminates. However, the process must be a Guardian process and cannot use Guardian ASSIGNs, PARAMs, or DEFINEs. The WebLogic Server processes are Open System Services (OSS) processes and typically require DEFINEs to be set to run with NonStop TCP/IPv6. Therefore, the generic process mechanism cannot be used to directly start and monitor the WebLogic Server application server process. Instead, a program called OSH starts as the generic process. The OSH process runs a shell script that starts and waits for the WebLogic Server process, which is configured as the second persistent process using the ASSOCPROC attribute. If the WebLogic Server process later fails, the shell script and OSH process also fail. The $ZPM will restart the generic process. Considerations Configuration Only a member of the SUPER group can configure and start a generic process even though a generic process can run as any userid. Because, for security reasons, the WebLogic Server administrator userid is not typically a member of the SUPER group, either the script used to configure the generic process must be owned and run as a member of the SUPER group or a member of the SUPER group has to execute the script directly. Automatic Restart Generic processes can be automatically restarted after the system is restarted. However, the WebLogic Server depends on OSS and NonStop TCP/IPv6 and part of NonStop TCP/IPv6 does not use the generic process mechanism. Therefore, the generic processes used to support the WebLogic Server must be started after OSS and NonStop TCP/IPv6 have been successfully started. By default, the sample scripts configure the generic process STARTMODE as APPLICATION. If OSS and NonStop TCP/IPv6 are not started by the CIIN processing, set STARTMODE to MANUAL and run the script after NonStop TCP/IPv6 starts. 4-2

27 Configuring Persistent WebLogic Server Processes Sample Scripts Sample Scripts The sample scripts provided use OSH and shell scripts to start and wait for the WebLogic Server process. If the intervening OSH or shell processes are killed but the WebLogic Server process is not, all processes will be restarted. One way to reduce the number of intervening shell processes between the OSH process and the WebLogic Server is to use exec. For example, instead of the shell script, started by OSH, running./startweblogic.sh, which starts a second shell process, the sample script runs an exec./startweblogic.sh. Using exec causes the second shell process to reuse the existing shell s pid. To completely eliminate the intervening shell processes requires that exec be used in all cases where a shell process is being started. In a typical installation, this requires changing scripts in the WebLogic Server home directory, too, or using the files from a different location. By using exec exclusively when starting the intervening processes, it is possible to have the OSH process effectively waiting on the WebLogic Server. A drawback to using exec this way is that no shell post-processing can be done. For example, a script cannot start the Java process, wait for it to terminate, and then perform cleanup processing. Whether or not exec is used, because OSH is the process being monitored by the generic process mechanism, any script invoked by the generic process must avoid the operations listed below: The shell script must wait for the WebLogic Server process. If it does not, the script will terminate causing OSH to terminate and the generic process will restart. The scripts should avoid calling sleep for any significant period of time unless you modify the AUTORESTART parameter of the generic process to reflect the delay. For example, if a script were to delay so that a failed start attempt of the generic process takes two minutes, the generic process will continually restart the generic process. By using an AUTORESTART of 10, only ten failures in 10 minutes will cause the generic process to move to the STOPPED state. By using a two-minute delay, the process will never fail ten times in 10 minutes. Managed Servers Instead of using the WebLogic Server Node Manager, you can use the generic process mechanism to monitor Managed Servers. Before using this approach, consider. CPU load balancing may be slightly harder to achieve than when you use the supplied nodemanager.sh. Each Managed Server must be configured to run in more than one CPU to be fault tolerant and to allow in-doubt transactions to be recovered after a server failure. To provide balance across CPUs, Managed Servers have to be assigned to a subset of CPUs. Therefore, use the FIRSTOF attribute with a list of CPU numbers. 4-3

28 Configuring Persistent WebLogic Server Processes Generic Process Attributes The following Node Manager features are not available: The WebLogic Server Administration Server is not able to use the WebLogic Server Node Manager to start Managed Servers Automatically monitoring the health of Managed Servers and restarting server instances that have reached the failed health state Shutting down or forcing the shut down of a Managed Server that failed to respond to a shut down request The generic process mechanism should be faster at restarting Managed Servers that have terminated or failed due to a processor failure. However, this speed requires monitoring and configuring outside of the WebLogic Server environment. Generic Process Attributes Table 3-1 contains a brief consideration for each useful attribute. These considerations assume that you are using OSH to start and monitor a WebLogic Server. See the sample scripts later in this section to learn how to set these attributes. Table 4-1. Generic Process Attributes Table Attribute AUTORESTART CPU NAME PRIORITY PROGRAM STARTMODE Consideration A setting of 0 means the process will not be persistent. The sample scripts set the value to 10 to allow up to ten failures in 10 minutes. Reducing this value might help avoid hitting an infinite restart loop. Use FIRSTOF to allow the process to run in a list of available CPUs. Use FIRST only if you want the process to normally run in CPU 0. Choose an available process name. Unless the script that starts the WebLogic Server process specifies a Guardian priority, set this attribute to ensure that the WebLogic Server process runs at an appropriate priority for your system. An inappropriate setting can significantly affect system performance and user response times. The scripts use $SYSTEM.SYSTEM.OSH so that OSH will be found in the current SYSnn. The WebLogic Server process depends on NonStop TCP/IPv6, so only APPLICATION or MANUAL should be used. If NonStop TCP/IPv6 is not fully started during the CIIN processing, use MANUAL and make sure the script used to configure and start the WebLogic Server process is run after the system is reloaded. Conversely, if the WebLogic Server process should not be automatically started after a system restart, change the script to use MANUAL to avoid having the WebLogic Server process started during system startup. 4-4

29 Configuring Persistent WebLogic Server Processes Sample Shell Scripts and TACL Macros Table 4-1. Generic Process Attributes Table Attribute STARTUPMSG STOPMODE TYPE USERID ASSOCPROC Consideration This attribute is limited to 128 characters. The sample scripts use -c script <->>stdout 2>>stderr. In this example, -c tells OSH to run script, <- causes OSH to ignore stdin, >> directs output to stdout, and >>2 directs output to stderr. Using OSH, only STANDARD causes the OSH process to be stopped during an SCF ABORT PROCESS command. Using SPI or SYSMSG with OSH will cause the ABORT command to succeed, but the process will not stop. The process will have to be manually stopped. Use OTHER. Unless the WebLogic Server process runs as a member of the SUPER group, set this attribute. This might have ramifications with the shell scripts if your environment expects values to be set from the.profile of this userid. Set ASSOCPROC to the Guardian name of the OSS process. Other generic process attributes can be ignored. HOMETERM and OUTFILE should typically be set to $ZHOME. Sample Shell Scripts and TACL Macros Configuring a generic process requires using SCF, the Guardian command interpreter. Commands must be run by a member of the SUPER group. Four sample files are provided for the NonStop server. These sample files are: startgp.sh, startgp.tacl, stopgp.sh, and stopgp.tacl. Two of the scripts are Korn shell scripts and two are TACL macros, therefore, you can choose which command interpreter you prefer to use. Both startgp files must be copied and modified to start either the Administration Server or the Node Manager. The stopgp files take the name of the generic process to be stopped and should not need modification. startgp.sh startgp.sh is a shell script. It can be copied by a member of the SUPER group, updated, and then a chmod command performed (for example, chmod u+s startgp.sh) so that anyone running the script will be considered a member of the SUPER group. Or, the user can log on as a SUPER user before running the script. Update the script as outlined in the script instructions (found in the script). Changes include making sure the script uses a unique generic process logical name and process name and that the script starts the correct shell script. Otherwise, the script starts SCF and will attempt to delete, add, and then start the generic process. 4-5

30 Configuring Persistent WebLogic Server Processes startgp.tacl startgp.tacl startgp.tacl is a TACL macro that must be copied to the Guardian namespace and converted to an EDIT file using CTOEDIT. As with startgp.sh, the macro needs to be updated to reflect the process to be started and must be run by a member of the SUPER group. Scripts to Start the WebLogic Server Process Regardless of what method is used to add and start the generic process, a sample script is needed to start the WebLogic Server process. To avoid the character limit of 115 on STARTUPMSG, place the following scripts in a directory near the root directory. The Administration Server script and the Node Manager script use the standard scripts created by the WebLogic Server. These scripts can be expanded as appropriate. Administration Server Script Place the following text into a file, turn the execute bit on, and use its name as the script name used when adding the generic process: #!/bin/sh PATH=/usr/bin:/bin:/usr/local/bin: cd <application directory>../setenv.sh run -name=/g/adsvr ${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} -Dweblogic.Name=${ADMIN_SERVER} -Dweblogic.ProductionModeEnabled=${PRODUCTION_MODE} -Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" -Dweblogic.management.username=${WLS_USER} -Dweblogic.management.password=${WLS_PW} weblogic.server Node Manager Script Place the following text into a file, turn the execute bit on, and use its name as the script name used when adding the generic process: #!/bin/sh PATH=/usr/bin:/bin:/usr/local/bin: cd application directory../setenv.sh run -name=/g/nmgr "${JAVA_HOME}/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} - Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" -Dweblogic.nodemanager.javaHome="${JAVA_HOME}" weblogic.nodemanager 4-6

31 Configuring Persistent WebLogic Server Processes stopgp.sh and stopgp.tacl stopgp.sh and stopgp.tacl The script and macro have one required argument, the generic process name, and an optional delete argument if the generic process entry should be deleted. The script and macro attempt to run an ABORT PROCESS command to cause the generic process to stop. Because the process being stopped is the OSH process, running the ABORT PROCESS command does not cause the WebLogic Server process to stop. Instead, the scripts put out a message reminding you that the WebLogic Server process also needs to be stopped. Realize that if the entry is not deleted, if the system is reloaded the process will be automatically restarted if STARTMODE is APPLICATION. That is, aborting the process only stops the current process while the system is still running. The entry will persist in the system configuration unless the delete option is used. Using the Node Manager on the NonStop Server The Node Manager can be used to start and stop Managed Servers. Its use on the NonStop server is the same as on other platforms. However, due to the NonStop server's multi-cpu architecture, the Node Manager is appropriate even when the cluster consists of only one NonStop server. To learn how to configure and use the Node Manager, refer to Configuring the Node Manager and the Overview of Node Manager and Configuring, Starting, and Stopping Node Manager sections in the BEA document titled Configuring and Managing WebLogic Server. The primary consideration when using the Node Manager on the NonStop server is that native process control is not supported. This means the Node Manager property NativeVersionEnabled must be set to false in either the nodemanager.properties file, or in the shell script (named startnodemanager.sh by default) used to start the Node Manager. Also, the default value for ListenAddress (that is, localhost) will normally need to be changed to be that of the NonStop server's TCP/IP process. It is important to realize that to fully exploit the Node Manager, other WebLogic Server properties may need to be changed. For example, the Node Manager only restarts servers if AutoRestart is true (the default value). However, if the same event that causes the Node Manager to fail causes a Managed Server to fail, the server will not be restarted unless HostsMigratableServices is false (the default value is true). For single node domains, HP recommends HostsMigratableServices be set to false. This property is not externalized on the console; instead the Server element of each Managed Server needs to be updated in the config.xml file directly. If HostsMigratableServices is not set to false, the Node Manager may report the status of a Managed Server as FAILED_MIGRATABLE. In that case, restart the server using the console or weblogic.admin utility. 4-7

32 Configuring Persistent WebLogic Server Processes Starting a Managed Server Through the Node Manager Starting a Managed Server Through the Node Manager When NativeVersionEnabled is set to false as required on the NonStop server, the Node Manager uses a shell script to start a Managed Server. By default that script is named nodemanager.sh, but can be changed using the StartTemplate property. The Node Manager passes four arguments to the script: Java command-line stdout to use stderr to use Filename where the pid of the Java process should be written Therefore, the nodemanager.sh could be as simple as: #!/bin/sh. $WL_HOME/common/bin/commEnv.sh java $1 > $2 2>$3 & echo $! > $4 To take advantage of the NonStop server multi-cpu architecture, a sample script and executable are provided that will balance the Managed Servers throughout the system. The nodemanager.sh script is stored in $WL_HOME/server/lib/unix. The script performs some simple processing and then runs a C program, CPUselector, in the same directory to select what CPU should be used by the Managed Server. The script then starts the Managed Server. nodemanager.sh The nodemanager.sh script reads in a server environment file to allow environment variables to be set per server. It invokes the C program named CPUselector to perform the load-balancing functionality. Once CPUselector completes, the script starts the Managed Server in the appropriate CPU. The WebLogic Server uses replication groups to support fault-tolerance by allowing a primary and secondary server to retain state information. To avoid a single point of failure requires the primary and secondary server not be started in the same CPU on a NonStop server. nodemanager.sh and CPUselector allow you to ensure the primary and secondary server will not be started on the same CPU. To support replication groups, CPUs are specified for use using a new environment variable named WLS_CPUS. Furthermore, the order the CPUs are listed in WLS_CPUS determines the order the CPUs are scanned when comparing the load of each CPU. nodemanager.sh scans the script's arguments to determine the server's name to set the environment variable WLS_SERVER. It then looks for the server environment file in the current working directory. By default, the server environment file is named nmserver.env and must be located in $WL_HOME/common/nodemanager, but both values can be changed in the nodemanager.sh script. If the file is present, the script invokes the file (for example,. nm-server.env). The script can then use the variable 4-8

33 Configuring Persistent WebLogic Server Processes CPUselector WLS_SERVER to selectively set the environment variables to be used by CPUselector. Example 4-1. Example Server Environment File case $WLS_SERVER in ms1) WLS_CPUS="2 3" WLS_LOADBAL_FUNC="no_load" ;; ms2) WLS_CPUS="4 5" WLS_LOADBAL_FUNC="no_load" ;; *) WLS_CPUS=" " WLS_LOADBAL_FUNC="jvm_load" ;; esac # Common DEFINEs and variables can go here or in commenv.sh The server environment file should set the appropriate environment variables and DEFINEs based on the server name passed. The variables and their functions are described below. CPUselector will then use the environment variables to determine what load-balancing algorithm to use and what CPUs can be used, and in what order for each server. Using these variables, you can configure replication groups in such a way that the primary and secondary server will never be placed in the same CPU. The one caveat being that a 2-CPU system will necessitate both servers being placed in the same CPU after a CPU failure; otherwise one of the servers will not be restarted. CPUselector The task of CPUselector is to determine what CPU to use when starting the Managed Server. The program first determines what CPUs are available. It then calculates the current load and selects the CPU with the minimum load. The two significant environment variables used by CPUselector are WLS_CPUS and WLS_LOADBAL_FUNC. WLS_CPUS is a space-separated list of valid CPU numbers and can be 16 values at most. WLS_CPUS determines what CPUs are available for selection by the server and in what order the computed loads are compared. That is, WLS_CPUS="3 2 0" will cause the load for CPU 3 to be examined first, then CPU 2, and finally CPU 0. If two CPUs have the same (minimum) load, the first CPU examined will be used. If no CPU contained in WLS_CPUS is currently up, no CPU will be selected. The variable WLS_LOADBAL_FUNC determines what load-balancing algorithm is used to compute the loads. The following sections describe how each load-balancing function computes the current load. The sections also identify the files and environment variables that are used. 4-9

34 Configuring Persistent WebLogic Server Processes gname_load gname_load gname_load uses Guardian process names to calculate the current load. The process names are specified using the environment variable WLS_GNAMES, which is a spaceseparated list of Guardian process names without the leading dollar sign (WLS_GNAMES="ms1 ms2 ms3 ms4"). gname_load then determines what CPU the process is executing in and calculates the aggregate load per CPU. To allow Managed Servers to be started with a Guardian process name, the WLS_GNAME variable is used. Consider two things when using gname_load. One, the process names listed in WLS_GNAMES can be any valid Guardian process name; there is no requirement that the process names only reference WebLogic Server processes. Two, WLS_GNAMES is used to determine what processes are running; WLS_GNAME (without the "S") assigns a process name to the Managed Server being started. jvm_load The move to using CPUselector has changed this existing function slightly. A new variable, WLS_JVM_PATHNAMES, is used to determine what executables should be queried for when computing the load. WLS_JVM_PATHNAMES is a colon-separated list of OSS executables. For example, WLS_JVM_PATHNAMES="/usr/tandem/nssjava/jdk141_v10/bin/java" causes every process using that executable to be included in the load. Likewise, WLS_JVM_PATHNAMES="/usr/bin/java:/bin/ksh" causes both executables to be included in the aggregate load. As the example above implies, any valid OSS executable name can be included in WLS_JVM_PATHNAMES. However, beware of including the same executable more than once, which can happen if a hard link or symbolic link is included because the algorithm first converts the OSS pathname to the corresponding Guardian filename, and then does a status for processes using that program filename. If the WLS_JVM_PATHNAMES includes the same Guardian filename twice because the OSS file is a link, the load will be added twice. For example, if /usr/bin/jre/java is a symbolic link to /usr/bin/java, then setting WLS_JVM_PATHNAMES to "/usr/bin/java:/usr/bin/jre/java" causes the same processes to be included in the total twice. managed_load managed_load computes the current load by using files maintained by the Node Manager. Each time a Managed Server is started its pid is written to a file. This function reads in each pid and determines in what CPU that process is executing. The list of processes being monitored is maintained in "./NodeManagerLogs/NodeManagerInternal/MonitorProcessList" by default. The "pid files" are located in directories under "./NodeManagerLogs" with names of the form domain_server. The addition of WLS_CPUS helps the managed_load algorithm because different Managed Servers can specify a different CPU ordering. That helps in the multi-start 4-10

35 Configuring Persistent WebLogic Server Processes no_load case because no servers will have been started so all the CPUs will have the same load (that is, 0). If a different CPU is listed first for each Managed Server, the servers will still start in different CPUs. However, managed_load still relies heavily on the pid files remaining current. If Managed Servers are started or restarted frequently, the likelihood of the pid files containing stale data increases. no_load no_load does not use a load-balancing algorithm. Instead, every CPU listed in WLS_CPUS that is currently up receives a load of 1. Thus, when the CPUs are scanned in WLS_CPUS-order, the first CPU that is currently up is used. The remaining CPUs in the list are examined when all the earlier CPUs in the list are down. In effect, the first CPU in WLS_CPUS is the primary CPU for the Managed Server, the second CPU is the backup, and so on. Using no_load allows the most control for assigning Managed Servers to specific CPUs. Therefore, when working with replication groups, using no_load allows you to avoid having the primary and secondary server being started in the same CPU. However, in a 2-CPU system, the backup CPU for a Managed Server needs to be the primary CPU of another Managed Server. By using no_load, you can avoid any issue with the multi-start case because every server will start in its assigned CPU regardless of where the other servers are started. Configuring the Node Manager This section provides step-by-step instructions about how to configure the Node Manager, including settings specific to the NonStop server platform. For further information, refer to the Overview of Node Manager and Configuring, Starting, and Stopping Node Manager sections in the BEA document titled Configuring and Managing WebLogic Server and the Troubleshooting and Notes section. Settings These instructions use and assume these settings: The server host where admin, Node Manager, and managed servers are running is called: icebat4.txn.cpqcorp.net A domain with servers in it already exists and is called rldomain. There are two managed servers called rlserver1 and rlserver2. Step 1. Create a Machine and Associate Servers To It 1. Start an admin server for your domain:../my_env (loading your usual WL_HOME, JAVA_HOME, and so on) cd $WL_HOME/../user_projects/domains/rldomain./startWebLogic.sh Access the GUI. For example:

36 Configuring Persistent WebLogic Server Processes Step 2. Generate Node Manager Configuration Files 2. On the left pane: a. Click on Machine folder. b. Click on Configure a New unix Machine. c. Enter a machine name d. Click Create. 3. Select the Node Manager tab and update: Listen Address: icebat4.txn.cpqcorp.net Listen Port: Click the Servers tab and select the servers that you want to be under the control of Node Manager. Step 2. Generate Node Manager Configuration Files 1. Generate Node Manager configuration files by running a first startup of the Node Manager. The two required configuration files, nodemanager.hosts and nodemanager.properties, are created in $WL_HOME/common/nodemanager at the first start of the Node Manager. 2. Run startnodemanager.sh to create the two configuration files: $WL_HOME/server/bin/startNodeManager.sh On the NonStop server platform, the Node Manager will fail to start, giving the error: Node manager could not find the required library, libnodemanager.a, in path - > This error is expected because the use of the native version of the NodeManager must be disabled (see Step 3. Configure and Start the Node Manager). The default configuration files are now available to do so. Step 3. Configure and Start the Node Manager 1. On the NonStop server: cd $WL_HOME/common/nodemanager 2. Edit nodemanager.properties to add: NativeVersionEnabled=false ReverseDnsEnabled=true PIDFileReadRetryCount=1 ScavangerDelaySeconds= Edit nodemanager.hosts to add the server where the admin resides: 4-12

37 Configuring Persistent WebLogic Server Processes Step 4. Configure Managed Servers Startup Options icebat4.txn.cpqcorp.net 4. Start the Node Manager: $WL_HOME/server/bin/startNodeManager.sh 5. In the output, check that new values for the properties are set. Step 4. Configure Managed Servers Startup Options The Node Manager will now start each managed server. Because neither the servers usual startup scripts (startmanagedweblogic.sh) or shell env are used, you must configure the following for the managed servers: 1. $WL_HOME/server/lib/unix/nodemanager.sh starts each managed server using NonStop platform-specific variables from nm-server.env: Create $WL_HOME/common/nodemanager/nm-server.env with the minimum contents shown below (TCP/IP stack identification is mandatory. See CPUselector for information about CPU selection): export TCPIP_PROCESS_NAME=\$ZSAMA export PTCPIP_FILTER_KEY=rlkey case $WLS_SERVER in rlserver1) WLS_CPUS= 0 ;; rlserver2 WLS_CPUS= 1 ;; esac 2. Configure startup options for each managed server. The environment values for each managed server are mirrored from the Node Manager. For options that must be configured at the managed server level: a. In the Admin console GUI, select a managed server (for example, rlserver1). b. Click the Remote Start tab and configure at least: Root Directory: /home/roland/wls/bea/user_projects/domains/rldomain User Name: weblogic Password: ******** Step 5. Start Managed Servers Using the Node Manager 1. From the Admin console GUI: a. Select a server and click the Control tab. b. Click Start this server. 4-13

38 Configuring Persistent WebLogic Server Processes Step 6. Monitor Startup of the Managed Server 2. From the command line enter:.$wl_home/server/bin/setwlsenv.sh java weblogic.admin -url icebat4:7001 -username webogic -password weblogic START rlserver1 Step 6. Monitor Startup of the Managed Server If the server does not start, check the following logs: (NODEMGR_HOME = $WL_HOME/common/nodemanager) For Node Manager process events: $NODEMGR_HOME/NodeManagerLogs/NodeManagerInternal/ directory For managed server startup events: $NODEMGR_HOME/NodeManagerLogs/domain_server name/ directory Troubleshooting and Notes If one specific server fails to start, test if the server starts in stand-alone: cd into the domain directory and start the managed server with:./startmanagedweblogic.sh rlserver2 PIDFileReadRetryCount defaults to 0 although it is documented in nodemanager.properties to default to 1. Leaving PIDFileReadRetryCount unchanged may cause unexpected behavior because the server might start but its status may not be reported in the Admin console. You should set PIDFileReadRetryCount to at least 1 to avoid error messages that may not be relevant. A value higher than 1 may be needed on slower or busier systems. ScavangerDelaySeconds defaults to 180, which is too low for the NonStop server. 300 seconds is more appropriate. If you do not change the default, the admin console may report failure even though the server started. weblogic.security.ssl.ignorehostnameverification property. Depending on how you used IP addresses and DNS names in the configuration of your servers, this property might need to be set to "true" for the SSL connections to establish between the admin and Node Manager and each servers. The BEA knowledge base states that setting this property to true is needed when using the demo certificates, However, in this sample we have used successfully both true and false settings: rlserver 1: GUI, configuration, Keystore & SSL, Advanced option: "Hostname Verification = BEA Hostname Verifier" This means weblogic.security.ssl.ignorehostnameverification = false. rlserver 2: GUI, configuration, Keystore & SSL, Advanced option: "Hostname Verification = none" 4-14

39 Configuring Persistent WebLogic Server Processes Starting the Node Manager from a Non-Default Location This means weblogic.security.ssl.ignorehostnameverification = true. Additional SSL debugging can be turned on by using the following properties: -Dweblogic.StdoutDebugEnabled=true -Dssl.debug=true Also a debug file can be specified within $WL_HOME/server/lib/unix/nodemanager.sh This document assumes that the default SSL demo Keystore and certificates shipped with WebLogic Server 8.1 are used. When the servers are created, they point to the demo SSL configuration by default (see Keystores and SSL configuration tab). This default allows an administrator to set up the Node Manager without initial SSL administration knowledge. Starting the Node Manager from a Non-Default Location The Node Manager can be used to control Managed Servers for several domains. However, there may be situations where you want to run multiple Node Managers on the same system, or run the Node Manager from a non-default location. To do either task can entail making several changes. By default, the script used to start the Node Manager sets NODEMGR_HOME to $WL_HOME/common/nodemanager, and then uses that value as its current working directory. This directory must contain nm-server.env, the server environment file that is used by nodemanager.sh. This directory also contains subdirectories that are used if CPUselector is instructed to use the managed_load load-balancing algorithm. To use a different directory, change the startnodemanager.sh script to set NODEMGR_HOME to a different value. Furthermore, update the script to export the NODEMGR_HOME variable (that is, export NODEMGR_HOME) so that the nodemanager.sh script will use the new value. Or, instead of exporting the variable, update nodemanager.sh to use the same value for NODEMGR_HOME. To change the location of nodemanager.sh or CPUselector, the Node Manager property named StartTemplate must be changed. By default, the value./nodemanger.sh is used, which translates to $WL_HOME/server/lib/unix/nodemanager.sh. The nodemanager.sh script assumes CPUselector is in $WL_HOME/server/lib/unix as well by setting the variable DFLT_CPUSELECTOR to $WL_HOME/server/lib/unix/CPUselector. Change either the StartTemplate and/or nodemanager.sh as appropriate. For example, changing only StartTemplate changes the location where the nodemanager.sh is located, but CPUselector is still used from the default location. Changing DFLT_CPUSELECTOR in the nodemanager.sh script that will be invoked allows CPUselector to be located in a non-default location (for example, if the program has been modified and recompiled). 4-15

40 Configuring Persistent WebLogic Server Processes Shutting Down a WebLogic Server Application To summarize, changing the value for NODEMGR_HOME in the start script allows multiple Node Managers to be run without conflict. If NODEMGR_HOME is changed, the variable must be exported for the nodemanager.sh script to use the updated location. If each Node Manager then wishes to use a unique nodemanager.sh and/or CPUselector, the StartTemplate property needs to be used to redirect the Node Manager to the non-default location. The nodemanager.sh can then point at a different CPUselector, if desired. Shutting Down a WebLogic Server Application If the generic process mechanism is used to monitor the Administration Server and Node Manager, the generic process must be stopped before the WebLogic Server process is stopped. A sample shell script, stopgp.sh, and TACL macro, stopgp.tacl, are provided. They can be used to abort, and optionally delete, the generic process. Running stopgp.tacl stops the OSH process and prevents $ZPM from restarting the generic process. Once the generic process is stopped, the usual WebLogic Server method of stopping the process can be employed. 4-16

41 5 Configuring JTA Java Transaction API (JTA) elements of the configuration describe several attributes for controlling the WebLogic Server transaction manager. If the TMF configuration is different for your application, the JTA attributes can be changed. This is an example with some NonStop server-specific changes. <JTA AbandonTimeoutSeconds= 7200 MaxTransactions= 1000 CheckpointIntervalSeconds= 60 ForgetHeuristics= true Name= examples /> The following are explanations of the JTA attributes specified above: AbandonTimeoutSeconds Number of seconds after which a transaction is abandoned if not complete. TMF defaults the autoabort timeout to 7200 seconds, making it sensible to restrict the WebLogic Server AbandonTimeout to be the same as TMF. MaxTransactions Controls the maximum number of transactions that can execute concurrently. When a static TMF resource manager is configured, the maximum number of transactions that can be started is restricted by the TFILE depth. The TFILE depth is Since the WebLogic Server can create transaction table entries on startup to recover indoubt transactions, this parameter should be set to a higher value than the maximum number of concurrent TMF transactions. The default value is and can be left unchanged without negative performance impact. CheckpointIntervalSeconds The default value is 300 seconds (5 minutes). The transaction manager creates new TLOG files and checks old TLOG files for deletion at this interval. This attribute has the side effect of determining the interval at which a registered XA resource is polled for in-doubt transactions. The correct behavior for a transaction manager is to call the recover on a resource manager immediately after it registers so that the resource manager can remove locks and be available for general transaction processing. 5-1

42 Configuring JTA 5-2

43 6 XA Resource Manager (XARM) Configuring the WebLogic Server XA Resource Object Configuring the XA Resource Manager Error Output Destination Configuring the WLSNonStopTxHelper as a Startup Class Configuring the JDBC Connection Pools for SQL/MX Configuring the WebLogic Server Data Sources for SQL/MX Additional Considerations for JDBC Access to SQL/MX DataBases The XA Resource Manager (XARM) for the HP NonStop server is a software component specifically written for and tested with the BEA WebLogic Server. It is written in C and Java and implements the Java XA resource interface as defined in the Java Transaction API (JTA) specification. Normally, the WebLogic Server Transaction Manager enlists an XA resource in a transaction only when the associated resource manager is accessed within a WebLogic Server transaction. A special construct is needed so that a Transaction Management Facility (TMF) transaction is associated with the thread along with the WebLogic Server transaction. Whenever a WebLogic Server transaction associated with a thread changes, the TMF transaction association should change. This requirement is achieved by registering a static resource manager object with the WebLogic Server. A static resource object is a special construct in the WebLogic Server. A statically registered XA resource manager is enlisted in every transaction started by the WebLogic Server. When the XARM is registered as a static resource manager with the WebLogic Server, it interacts with the WebLogic Server to import transaction branches into TMF when instructed by the WebLogic Server and takes part in the commitment of the branch under the direction of the WebLogic Server transaction manager. As part of starting up each WebLogic Server instance, the NonStop server XA resource must be registered as a static resource with that instance. Whenever a WebLogic Server transaction is started (either implicitly or explicitly), a branch of the transaction is contracted to TMF by the WebLogic Server transaction manager through the NonStop XA resource. The imported branch protects all NonStop server resources accessed within the scope of the WebLogic Server transaction. The static resource manager protects the NonStop server resources when it is accessed within the scope of a WebLogic Server transaction. However, the WebLogic Server transaction manager treats a resource as a transactional resource only if it supports the XA resource (even if the XA resource does not really do transaction management). For example, for a SQL/MX connection pool to take part in a transaction involving other XA resources, the JDBC (Java Database Connectivity) driver for SQL/MX should have an XADataSource driver. However, JDBC/MX does not support XADataSource and XAConnection interfaces. Because of this, a JDBC/MX wrapper driver has been provided to support the XADataSource and XAConnection interfaces. The associated XA resource is a dummy resource because it ignores all the XA requests from the WebLogic Server transaction manager. This satisfies the WebLogic Server requirement that JDBC/MX be XA-aware. 6-1

44 XA Resource Manager (XARM) Configuring the WebLogic Server XA Resource Object Configuring the WebLogic Server XA Resource Object To configure the NonStop server XA resource object into a WebLogic Server, you must define a startup class. A startup class is a special class that implements the T3StartupDef interface. This startup class is loaded by the WebLogic Server as part of the WebLogic Server startup. For the NonStop server, the startup class WLSNonStopTxHelper has to be configured for every server in the domain. This class, when instantiated, constructs the Java XA resource object for TMF and registers that resource as a static resource manager with the WebLogic Server. The object is also published in the JNDI as a non-replicated custom object so that the WebLogic Server does not attempt to replicate it to other servers in the cluster. The WLSNonStopTxHelper, when creating the Java XA resource, passes in some configuration information to the Java object so that the communication between the XA resource object and TMF can be realized. You can provide these parameters to the startup class in a property file or as Java system properties. If specified, the Java system property for a parameter takes precedence. To specify the property file explicitly for an instance, set the Java system property hp.nsk.xares.properties to refer to the properties file. Use absolute paths to specify the file so that the file can be opened and processed regardless of the current directory of the WebLogic Server instance on startup. The property file can be implicitly specified by naming it servername.xaproperties, where servername is the name of the WebLogic Server instance to which the property file applies. This file should be placed in the current directory (typically the domain directory) or under the server root directory. Note that the server root directory defaults to ".", but you can change the root directory by using the ServerStart element in the configuration file; however, note that this change is useful only when the Node Manager is used. You should explicitly specify the Property file so no confusion occurs between the current directory and root directory checks. When configuring servers that are to be started using the Node Manager, for each configured server, set the arguments of the ServerStart element to specify this property. 6-2

45 XA Resource Manager (XARM) Configuring the XA Resource Manager Error Output Destination Configuring the XA Resource Manager Error Output Destination You can control the destination of the XA resource manager error output by configuring the following environment variables: Name XARM_SYSLOG XARM_LOG_FILE Description Set to Y to log the XA resource manager error output to the Event Management Service (EMS). Set to N to disable logging the error output to EMS. The default setting is Y. The name of the log file for error and debug output. If not specified, the trace file name is xalog-year-monthstring-date-hour-minute-secs.txt For example, xalog-2003-apr txt. Configuring the WLSNonStopTxHelper as a Startup Class You can use the WebLogic Server console to configure startup classes. Below is an XML fragment showing the StartupClass element that is used to configure the startup class for the WLSNonStopTxHelper. All the XA resource object files reside in the package com.hp.nsk.xares. <StartupClass ClassName= com.hp.nsk.xares.wlsnonstoptxhelper DeploymentOrder= 1 FailureIsFatal= true LoadBeforeAppActivation= true LoadBeforeAppDeployments="false" Name= NSKXAResource Targets= VCluster /> ClassName Describes the Java class implementing the T3Startup interface. LoadBeforeAppActivation Determines if the startup class should be loaded after the connection pools are created but before the applications are activated. Activation is the second phase in the 2-phase deployment model. LoadBeforeAppActivation should be used when the startup class needs to be invoked after the connections pools are available but before the applications are activated and ready to service client requests. 6-3

46 XA Resource Manager (XARM) Configuring the WLSNonStopTxHelper as a Startup Class LoadBeforeAppDeployments Determines whether a startup class is loaded and run before the server creates JMS and JDBC services or deploys applications and EJBs. If you specify true for this option, the server loads and runs the class before the prepare() phase in the 2- phase deployment model. At this point, JMS and JDBC services are not yet available, and no applications or EJBs have been deployed. If you specify false, the server loads the class after all other types of modules have been deployed. Name Used by the WebLogic Server Mbeans for configuration purposes. The Startup class has no arguments. The arguments for specifying various options are specified in the startup script as Java system properties or by using a properties file. Table 6-1. Java System Properties Used by WLSNonStopTxHelper Property Name Used in Property File Name when Specified with the -D Java Command Line Option Description name hp.nsk.xares.name Specifies the name of the TMF recoverable resource manager that the XA resource manager uses.this name must be unique in a NonStop server node. It should be independent of the recoverable resource manager names used by other WebLogic Server instances regardless of their domain, HP NonStop Tuxedo Domain gateway resource manager, as well as those used by HP NonStop CORBA. A valid value is a name that is a valid TMF recoverable resource name. The default value is WLSdomainName-WLSservername. flags hp.nsk.xares.flags Valid values are 0-7. These values are represented by three bits. Bit 0, if set, enables statistics. Bit 1 enables auditing, and Bit 2 enables asynchronous import of transactions. The default value is 0. maxtrans hp.nsk.xares.maxtrans Specifies the maximum number of concurrent TMF transactions that will be handled by the XA resource manager, for the entire process. It is limited by the TMF TFILE depth. The maximum TFILE depth is Valid values are 100 and higher. For a value greater than 100 to take effect, you must also set the value into the environment variable. Default value is

47 XA Resource Manager (XARM) Configuring the JDBC Connection Pools for SQL/MX Table 6-1. Java System Properties Used by WLSNonStopTxHelper (continued) Property Name Used in Property File Name when Specified with the -D Java Command Line Option Description maxthreads hp.nsk.xares.maxthreads Specifies the maximum number of threads that can concurrently take part in a transaction. Typically, set to the maximum number of transactions configured so that the case where each thread operates on only one transaction is allowed for. Valid values are 100 and higher. Default value is enabletrace hp.nsk.xares.enabletrace Enables or disables tracing of the XA operations by the XA resource manager. Valid values are true and false. Default value is false. tracefile hp.nsk.xares.tracefile Specifies that the file cannot be opened and trace output is redirected to System.err destination. Valid value is null or a valid path to a file. Default value is null. If set to null, tracing is disabled. auditfile hp.nsk.xares.auditfile If auditing is enabled in the flags, this file is used as the audit file. If the filename is null or invalid and auditing is enabled in the flags, an audit file with the name xaaudit-date+time.txt is created for audit messages. Configuring the JDBC Connection Pools for SQL/MX The JDBC/MX driver does not support the optional XA support specified in the JDBC specification because there is no need for the XA interfaces in the NonStop platform. However, the WebLogic Server and other J2EE containers depend on data sources to provide the XA resource for coordinating the participation of these resources in global transactions. The WebLogic Server can optionally provide an XA emulation driver for a non-xa resource. However, only one resource with WebLogic Servers-provided XA emulation can take part in a distributed transaction. Furthermore, using the WebLogic serverprovided XA resource can result in more heuristic completions. To take part in a distributed transaction without depending on the WebLogic Server-provided XA emulation, the resource manager should be XA-aware. An XA resource interface for NonStop server resources does not have to do transaction management when used with the WebLogic Server because the static resource manager handles the transaction management and is enlisted in all WebLogic Server transactions. 6-5

48 XA Resource Manager (XARM) Configuring the JDBC Connection Pools for SQL/MX A wrapper driver has been written for JDBC/MX. The wrapper driver does not do transaction management, but implements the XA interface. The XA resource implemented by JDBC/MX responds with XA_RDONLY, implying that no change was done to the underlying resource. The static XA resource manager protects changes to resources managed by JDBC/MX. Returning XA_RDONLY tells the WebLogic Server transaction manager to ignore the resource in the second phase of commit processing. If all the resources accessed with a WebLogic Server transaction are JDBC/MX resources pools, the WebLogic Server transaction manager does not write a transaction log during the commit processing. This provides better performance and reliability as the transaction log is protected with TMF audit trails. The following is a sample configuration element for the JDBCConnectionPool using the wrapper drivers. Note that the JDBC URL does not change from the underlying JDBC driver that is being wrapped. <JDBCConnectionPool CapacityIncrement= 1 DriverName= DriverName InitialCapacity= 1 MaxCapacity= 10 Name= PoolName RefreshMinutes= 0 ShrinkPeriodMinutes= 15 ShrinkingEnabled= true Targets= examplesserver TestConnectionsOnRelease= false KeepXAConnTillTxComplete= true TestConnectionsOnReserve= false RollbackLocalTxUponConnClose= true SupportsLocalTransaction= true URL= JDBCUrl /> DriverName Name Specifies the JDBC driver associated with the Pool. It can be the name of the class for the Type 2 JDBC driver or the XA DataSource driver. The Type 2 driver name is com.tandem.sqlmx.sqlmxdriver The XA DataSource driver name is com.hp.nsk.xares.wlstxsqlmxdatasource The name of the connection pool that is used when referencing the connection pool when configuring the data sources. PoolName is also used by the WebLogic Server Mbeans management infrastructure. 6-6

49 XA Resource Manager (XARM) Configuring the JDBC Connection Pools for SQL/MX KeepXAConnTillTxComplete Tells the WebLogic Server not to close the connection until the global transaction is complete. This attribute must be set in the JDBCConnectionPool for the WebLogic Server to invoke the settransactionisolation method. When generating primary keys using a named sequence table, the WebLogic Server sets the transaction isolation level on the JDBC connection to TRANSACTION_SERIALIZABLE. To change the transaction isolation level, the WebLogic Server must be instructed to keep the connection until the transaction is complete. This implies that all requests to acquire a connection from a specific JDBCConnectionPool for a given transaction will return the same connection object. RollbackLocalTxUponConnClose If set to true, the connection pool calls rollback() on the connection before putting it back in the pool. Enabling this attribute impacts performance because the rollback call requires communication with the database server. The NonStop SQL/MX JDBC/MX driver requires that local transactions be ended before enlisting a connection in a global transaction; therefore, you must set RollbackLocalTxUponConnClose to true. SupportsLocalTransaction Applies only to the JDBC/MX connection pools. The JDBC/MX driver can determine if it was called within the context of an external transaction (in the case of the WebLogic Server, a transaction that was imported into TMF as a branch of a WebLogic Server global transaction). If so, it defers transaction management to the application managing the transaction. Otherwise, the JDBC driver manages the transactions by itself. This flag tells the WebLogic Server that the JDBC driver has the ability to do JDBC work even without a WebLogic Server transaction in progress and is used in some sample applications used by the WebLogic Server (including repopulating the MedRec database). URL Designates different database instances so that the JDBC driver can determine whether it can open the database based on the URL provided. The JDBC driver should be able to parse the URL and make a connection to the database. Unlike the driver name, the JDBC URL does not change between non-xa and XA drivers. The JDBC URL is: jdbc:sqlmx: 6-7

50 XA Resource Manager (XARM) Configuring the WebLogic Server Data Sources for SQL/MX Properties The Properties field is useful only with the XADataSource driver. The property names and the various acceptable values are provided the following table. Property Name maxstatements maxpoolsize minpoolsize Description Has the same meaning as specified in the JDBC specification. Valid value is greater than or equal to zero (>=0). Zero (0) disables statement caching. Less than zero (>0) enables statement caching with specific number of statements. Default value is 0. The maximum number of physical connections the pool should keep available at all times. Valid values are -1 and 0 or less than zero (<0). Negative 1 (-1) disables use of the connection pooling data source to get a connection. Zero or greater than 0 (0 or >0) value results in a data source object being created in the background and used for connection pooling. Default value is 0. This value indicates no maximum size. The number of physical connections the pool should keep available at all times. Valid values are -1 and 0 or greater than 0 (<0). Value must be less than maxpoolsize. Negative 1 (-1) disables use of the connection pooling data source to get a connection. Default value is 0. This value indicates that connections should be created as needed. Configuring the WebLogic Server Data Sources for SQL/MX While configuring the JDBC data sources for SQL/MX, one of the XA or non-xa pools configured for SQL/MX, as described in the previous section (Configuring the JDBC Connection Pools for SQL/MX), is used. A transaction data-source has to either use the XA connection pool or should have the EnableTwoPhaseCommit attribute set to true. For example: <JDBCTxDataSource JNDIName= examples-tx-mx-datasource Name= examples-tx-mx-datasource PoolName= PoolName EnableTwoPhaseCommit= true Targets= targetservers /> The EnableTwoPhaseCommit attribute instructs the WebLogic Server to emulate an XA resource object if the underlying JDBC driver supporting the connection pool does not have XA support. This attribute is otherwise ignored. 6-8

51 XA Resource Manager (XARM) Additional Considerations for JDBC Access to SQL/MX DataBases To configure non-transactional data sources, a connection pool using the default JDBC driver, or the wrapper JDBC driver can be specified. Additional Considerations for JDBC Access to SQL/MX DataBases When the NonStop XA resource is registered statically with the WebLogic Server, all subsequent access to the SQL/MX database within the scope of the WebLogic Server transaction is automatically protected by the TMF transaction imported as a branch to the WebLogic Server transaction. There are three possible configuration options when configuring the WebLogic Server data sources to access SQL/MX: 1. Configure a WebLogic Server JDBC data source based on the Type 2 JDBC/MX driver. In this configuration, a WebLogic Server data source object is created based on the JDBC/MX driver. The data source is not an XA-aware resource, so it cannot be used with WebLogic containers that require an XA-aware JDBC driver (such as the Container-Managed Persistence Service (CMP) container). If a WebLogic Server transaction is started before the invocation of the component that uses the WebLogic Server JDBC data source, either initiated by the client or container-initiated transactions based on declarative requirements of the component, all the JDBC access by the component will be within the context of the imported transaction. The JDBC/MX driver operates in the context of an external TMF transaction (one not started by the JDBC/MX driver itself). Therefore, the application components should not call commit/rollback method of the JDBC/MX driver to commit/rollback the database work. Instead, the JTA methods for commiting/rolling back should be used. During commit processing, the WebLogic Server will coordinate with the static resource manager to drive the TMF transaction to completion. This is the most efficient use of JDBC/MX with the WebLogic Server. It allows the WebLogic Server to do one-phase commit optimization (if no other XA resource other than the static XA resource manager is involved in the transaction) and lets TMF perform onephase commits efficiently. 2. Configure a WebLogic Server JDBC transactional data source based on the Type 2 JDBC/MX driver. In this configuration, a TxDataSource object is created based on a non XA-aware driver by setting the EnableTwoPhaseCommit attribute to true in the data source configuration. The WebLogic Server provides an XA wrapper on top of JDBC/MX. The JDBC/MX driver operates in the context of an external TMF transaction (one not started by the JDBC driver itself). The WebLogic Server-provided XA wrapper does not run real transaction management. When the application calls the JTA methods to 6-9

52 XA Resource Manager (XARM) Additional Considerations for JDBC Access to SQL/MX DataBases commit or rollback the transaction, the WebLogic Server calls the JDBC driver to perform the commit/rollback. The JDBC/MX driver ignores this request because the transaction is managed externally to the JDBC driver. During commit processing, the WebLogic Server coordinates with the static resource manager to drive the TMF transaction to completion This transactional data source can be used with the WebLogic Server containers that require XA-aware resources, like the WebLogic Server CMP. A restriction is that only one NonStop server data source can take part in the global transaction. Note that each data source is an independent XA resource. To use this method effectively, it is desirable to define a single TxDataSource object in the WebLogic Server configuration to access the SQL/MX database. Note that even if only the JDBC/MX resources are involved in the transaction, WebLogic Server will do a 2- phase commit processing involving the static XA resource manager and the WebLogic Server XA wrapper resources associated with each of the TxDataSource object. 3. Configure a TxDataSource object using the WLSTxSQLMXDataSource JDBC XADataSource driver provided with the WebLogic Server. This driver implements the XA interfaces (XADataSource and XAConnection) using the JDBC/MX driver facilities. In this case as in the previous cases, the JDBC/MX driver operates in the context of an external TMF transaction (one not started by the JDBC driver itself). During commit processing, the WebLogic Server coordinates with the static resource manager to drive the TMF transaction to completion. Just like the TxDataSource configured in Option 2 above, this also can be used with CMP configuration. An important thing to note is that, in this case, the WebLogic Server JDBC wrapper drivers know that the JDBC/MX driver has a resource-specific XA resource object. Therefore, the WebLogic Server expects that the JDBC connection be used as in the J2EE model. In the J2EE model, an application that uses JDBC connections is supposed to use the "acquire, use and release" model. If a connection reference is kept between method invocations under different transaction contexts, runtime errors will occur. 6-10

53 7 Configuring JDBC Stores for JMS The WebLogic Java Messaging Service (JMS) Server can be configured to use a JMS JDBC store when the underlying JDBC connection pool uses NonStop SQL/MX 2.0 with ANSI tables as the database. The JMS database contains two system tables (generically called JMSState and JMSStore) that are generated automatically and are used internally by each JMS server. Because the JMSStore table has a column defined with a BLOB data type, a special table is used by the JDBC/MX driver to store the BLOB data. Be aware of the following situations regarding this special table: When using a JMS Server in a WebLogic Server domain, you must pre-create this table before you start WebLogic Server. To pre-create the table, use the JdbcMxLobAdmin utility supplied with the JDBC/MX driver. The JDBC Driver for SQL/MX Programmer s Reference Manual describes how to do this. You must identify the name of the BLOB table to the JDBC/MX driver by specifying the following in the JAVA_OPTIONS environment variable: -Djdbcmx.blobTableName=catalog.schema.table-name where catalog is your catalog, schema is your schema, and table-name is the name you gave the table. If your application runs in a cluster, you must specify the prefix name for JMSDBStore to uniquely identify the tables used by a particular JMS Server. The prefix should contain the catalog name, the schema name, and a unique identifier. JMS prepends the prefix to the generic table name to form a valid table name. Specifying the prefix using the following format results in a valid table name: [catalog.] [schema.] unique-identifier where catalog is the catalog used by the application, schema is the schema used by the application, and unique-identifier is any value you choose. Note. If you specify -Djdbcmx.catalog=catalog and -Djdbcmx.schema=schema in the JAVA_OPTIONS environment variable, you do not need to specify the catalog or schema. For example, specifying a prefix such as mycat.myschema.s1 causes JMS to create tables named mycat.myschema.s1jmstate and mycat.myschema.s1jmstore. Because JDBC/MX stores BLOB data for the JMSStore table in the special BLOB table, you must create TRIGGERs to delete the BLOB data from the BLOB table when the BLOB data is deleted or changed in the base JMSStore table. Use the 7-1

54 Configuring JDBC Stores for JMS JdbcMxLobAdmin utility to create these triggers. The JDBC Driver for SQL/MX Programmer s Reference Manual describes how to do this. Note. You cannot configure a transaction (XA) JDBC connection pool or JDBC TxDataSource to use with a JMS JDBC store. JMS must use a JDBC connection pool that uses a non-txdatasource with a non-xaresource driver. For more information, refer to Section 9, Managing the SQL/MX Tables for BLOB and CLOB Data. 7-2

55 8 Using the WS Plug-in Comparison of RLS and WS Plug-in Architecture Installing and Building the WS Plug-in Configuring the WS Plug-in WS Plug-in Configuration Tool Migration Considerations WS Plug-in Event Messages (5000 through 5024) Troubleshooting Comparison of RLS and WS Plug-in Overview The WS Plug-in replaces the version of the Resource Locator Service (RLS) distributed with itp Secure WebServer. The RLS is an optional feature of itp Secure WebServer. It enables multiple web servers to appear as a single server to users. See the HP itp Secure WebServer documentation for more information. The WS Plug-in is distributed with the NonStop Server Toolkit. It supports stateful dialogs between web clients (usually a browser) and J2EE application servers. It also supports more sophisticated load balancing and configuration options. The WS Plug-in also supports web applications that utilize session-based dialogs. Therefore, because the WebLogic Server is a J2EE application server platform that includes a web container (which uses session based dialogs), you must use the WS Plug-in in place of the RLS product distributed with itp WebServer. Using DBACCESS Table The itp Secure WebServer version of the RLS uses a single SQL/MP table (called DBACCESS) to configure the servers to which requests are forwarded. This approach is not practical in a J2EE environment where many applications are deployed in a cluster of application servers. Because each web application has a separate pathname prefix, a separate entry is required for each prefix to target server combinations. Using WS Plug-in, you can group a number of target servers (usually application servers) together as a cluster. Therefore, you must define the cluster only once. Many different applications (defined by their pathname prefix) can be routed to that cluster. WS Plug-in also provides a number of new features related to load balancing and request redirection that are especially designed for use with application servers. These features are enabled on a per-application basis using an additional column (titled noredirect) in the DBACCESS table. If this column contains a non-zero value, the J2EE mode is enabled. 8-1

56 Using the WS Plug-in Routing to Replicated Applications Routing to Replicated Applications The WS Plug-in supports pathname prefix mapping, which routes requests to the same application deployed in multiple clusters. To use this feature, you must replace the first component of the pathname specified by the client with a different prefix before forwarding it to the server. The WS Plug-in uses the prefix to determine to which cluster to route the request and then it replaces the prefix specified by the client with the one required by the server. This means that you can route preferred clients to a separate cluster of application servers (which may be running at a higher priority) in order to provide them with superior service. Load Balancing When the WS Plug-in is operating in J2EE mode, you have the option of using a loadbalancing algorithm based on POST directives and GET directives that include a query string (because these requests are likely to involve significant processing by the application server). The WS Plug-in also keeps track of the number of new sessions allocated to each application server. Then it uses these two pieces of information to determine the capacity of each target application server process in the cluster and routes requests accordingly. This feature can be activated using a run time environmental parameter. The default load balancing algorithm is 'round-robin'. Tracking Failed Target Application Server Processes The WS Plug-in also uses the J2EE mode setting to activate the recording and retrying of failed target application server processes. If J2EE mode is configured, the router for itp will record failed servers in the DBSTATUS table and update the DBFILES table to indicate to other router for itp processes that a target application server has failed. This action causes each router for itp process to read the list of failed target application servers in the DBSTATUS table and update its own internal table. Passthrough and Redirect Modes The WS Plug-in supports two types of operation: passthrough and redirect. In passthrough mode, all requests are sent from the client to the itp Secure WebServer, then to the WS Plug-in and the application server. To use this mode, set the noredirect column in the DBACCESS table to a positive value. In redirect mode, the client initially communicates with the itp Secure WebServer and the WS Plug-in. However, having selected a server process, the WS Plug-in instructs the client to communicate directly with that specific application server. In this case, the client sends all subsequent requests directly to the specific target application server process in the application server cluster selected by the WS Plug-in. To use this mode, set the noredirect column in the DBACCESS table to a negative value. HP recommends the use of passthrough mode. This ensures that static content is processed by itp Secure WebServer rather than the application server and is also 8-2

57 Using the WS Plug-in Requirements useful when an application server is configured, for security reasons, to use TCP/IP addresses that are not visible to external clients. Using passthrough mode also has advantages in load balancing. Requests to stateless applications can be routed to the least busy server on a per-request basis. Requests to session-based applications are routed to the server in which the session was created. However, if that server fails, the WS Plug-in can redirect the request to an alternative member of the WebLogic Server cluster. Furthermore, if the application is configured for session replication, the WebLogic Server replicates session state to a separate server in the cluster. This means that the alternate server can restore the user s session state. Requirements itp Secure WebServer requires HP NonStop SQL/MP. Therefore, to use the WS Plug-in you must have NonStop SQL/MP installed and running on the same system (in addition to HP NonStop SQL/MX required by the WebLogic Server). Use a D43 release version update (RVU) or later of NonStop SQL/MP. Compatibility The WS Plug-in is backward compatible; it supports all the functions provided by the itp Secure WebServer version of the RLS. For migration information, see Migration Considerations. Background Web applications can include static and dynamic content. Static content includes applets, HTML documents and image files. Web servers can support static content more efficiently than Java-based web containers. To process dynamic content, such as servlets and JavaServer Pages (JSP), you must have a web container. Servlets and JSPs usually require access to database tables or Enterprise Java Beans (EJB) applications. Therefore, requests with dynamic content can require significantly more system resources than requests with static content (which is simply transferred to the client). This contrast is the basis of the need for the enhanced load balancing function in the WS Plug-in. For example, you can use itp Secure WebServer on a NonStop server in conjunction with a WebLogic Server application server that has multiple target application server processes. The itp Secure WebServer services the static content and provides user authentication (either Digital Certificate or HTTP-based). Requests for dynamic content (which are not supported by itp Secure WebServer) are sent to the WS Plug-in, which forwards them to the appropriate target application server process in the WebLogic Server cluster. The WS Plug-in selects the target application server process using the following criteria: If a WS Plug-in cookie is present, the request is associated with an existing session and must be routed to a specific target application server process. 8-3

58 Using the WS Plug-in Architecture If that process is not available, the request is routed to an alternate target application server process. WebLogic Server application servers provide support for persisting session details. This enables an alternate target application server process to restore it. If a cookie is not present, the WS Plug-in routes the request to the least busy application server process. Architecture The WS Plug-in is implemented as a Pathway CGI server class. It interacts with other itp Secure WebServer components as follows: 1. If itp Secure WebServer is configured to use traditional TCP/IP, the distributor process receives a request from the network. The distributor process sends the request to an HTTP Daemon process. If NonStop TCP/IPv6 is configured, the HTTP Daemon processes all listen on the same port and NonStop TCP/IPv6 distributes requests to specific HTTP Daemon processes. 2. The HTTP Daemon process determines whether it can service the request. The HTTP Daemon can service the request if the file specified by the pathname component of the URL is present in the itp Secure WebServer's file system or is supported by a mapping to another itp Secure WebServer component (for example, NonStop Servlets for JavaServer Pages). 3. If the HTTP Daemon process can service the request, it does not invoke the WS Plug-in (in which case, the rest of the steps do not apply). If the HTTP Daemon process cannot service the request, it invokes the WS Plug-in, using the NonStop TS/MP Pathsend facility. 4. The WS Plug-in uses an internal table (loaded at startup from an SQL table) to identify the cluster that can handle the request. It reads an SQL table to obtain the status information for the prefix specified. If the availability of the target application server processes in the cluster that this path is configured to use have been changed, the WS Plug-in also checks the cluster status table. This method prevents the WS Plug-in from sending requests to a failed target application server process. 5. The WS Plug-in attempts to connect to the best-performing server in the cluster. If the best-performing server is not available, the WS Plug-in updates the status tables and connects to the next-best server. Failed target application server processes are retried periodically. The retry interval is configurable using the RETRY_PERIOD option in the server class definition. 8-4

59 Using the WS Plug-in Installing and Building the WS Plug-in 6. WS Plug-in updates the workload and capacity information relating to the individual target application server processes of the cluster for use in subsequent decisionmaking. Figure 8-1. Information Flow Using WS Plug-in Client Internet HTTP Daemon NonStop TS/MP WS Plugin Application Server Application Server Application Server VST005.vsd Installing and Building the WS Plug-in The itp WebServer is required if you plan to use BEA WebLogic Server 8.1 SP3 with the WS Plug-in. The following itp WebServer product versions are supported: T8996H01 T8997H01 1. Start an OSS Shell Start an Open Systems Services (OSS) shell and navigate to the WS Plug-in installation directory (usually /usr/tandem/wlhpns/t2924h13). Note that if you are installing the WS Plug-in on a system separate from the WebLogic Server, you must copy the T2924PAX file to that system and unpax it before you proceed with the following steps. 2. Run the WS Plug-in Script Run the WS Plug-in install script in /usr/tandem/wlhpns/t2924h13. /usr/tandem/wlhpns/t2924h13/install-plugin.sh The install-plugin.sh script must be run using a user id that has sufficient privilege to remove the current contents of the itp WebServer product installation/bin/rmt directory. The script copies the files from directory /usr/tandem/wlhpns/t2924h13 to the itp Secure WebServer directory, usually /usr/tandem/webserver/bin/rmt. If you want to install the WS Plug-in files into a different directory, use the -i option to specify the base directory of the target webserver. 8-5

60 Using the WS Plug-in 3. Change the Directory For example, the following command removes the files in /usr/tandem/webserver-v61/bin/rmt and copies the files from /usr/tandem/wlhpns/t2924h13 into that directory: cd /usr/tandem/wlhpns/t2924h13 install-plugin.sh -i /usr/tandem/webserver-v61 3. Change the Directory a. Change to the rmt directory (where you installed the WS Plug-in files). For example: cd /usr/tandem/webserver/bin/rmt b. By default the WS Plug-in SQL/MP database files are created in $SYSTEM.ZWEBDB. To change the location of these files, update the following lines in the Makefile: DB_VOLUME=SYSTEM DB_SUBVOLUME=ZWEBDB 4. Configuring WebLogic Server Applications and Clusters The WS Plug-in uses a number of NonStop SQL/MP database tables to configure the WebLogic Server applications and clusters. A template script file for loading data into these database tables is provided in the file dbload.sqlci. A utility is provided that reads the WebLogic Server configuration file (config.xml) and updates the dbload.sqlci file with the entries required to configure the WS Plug-in. Refer to the WS Plug-in Configuration Tool section below for details. You can also update the dbload.sqlci table manually as described in Creating the Database. 5. Create the Database and Build the WS Plug-in Use the make utility to create the database and build the WS Plug-in executable. make This utility creates and loads the SQL/MP database and builds the WS Plug-in executable file rmt.pway. 6. Modify the WS Plug-in Configuration You must modify the default configuration of the WS Plug-in to use it with the WebLogic Server. For information about configuring, see Configuring the WS Plug-in. 7. Restart itp Secure WebServer You must restart itp Secure WebServer to use the newly installed WS Plug-in. The default httpd.config file contains the basic configuration directives required by the WS Plug-in. 8-6

61 Using the WS Plug-in Configuring the WS Plug-in Configuring the WS Plug-in You configure the WS Plug-in by configuring the Server Class definition and database tables. Defining the WS Plug-in Server Class The WS Plug-in server class is named rmt.pway. The itp Secure WebServer default configuration file httpd.config defines the RLS server class, shown in Example 8-1 Example 8-1. Default RLS Server Class Definition ####################################################### ###### Configure Resource Locator attributes # set rmt /bin/rmt/rmt.pway if { [file exists $root$rmt]} { Filemap $rmt $root$rmt Server $root$rmt { eval $DefaultServerAttributes CWD $root/bin/rmt } } RmtServer $rmt For a description of the elements in this definition, see the itp Secure WebServer System Administrator's Guide. For more information about defining Pathway server classes, see the Pathway/XM System Management Manual. 8-7

62 Using the WS Plug-in Defining the WS Plug-in Server Class The web client displays a server error if you replace rmt.pway with your own application or if you installed rmt.pway incorrectly. Example 8-2. Server Class Definition for WS Plug-in ############################################################### # # Configure Plug-in for WebLogic Server # set rmt /bin/rmt/rmt.pway if { [file exists $root$rmt]} { Filemap $rmt $root$rmt Server $root$rmt { eval $DefaultServerAttributes CWD $root/bin/rmt Env PASSTHROUGH_CONTENT_LENGTH=5000 Env HTTP11_SUPPORT=ON Env KEEP_ALIVE=ON Env AUTO_LOAD=ON Env DISPLAY_CONFIG=ON Env SESSION_BALANCING=ON Env RETRY_PERIOD=30 Env STATS_PERIOD=300 Env SHOW_STATS=EMS Env RATED_STATS=ON Env TRACE_LEVEL=1 Env LOG_DIR=/projects/MyApp/Apps/webserver/logs MapDefine =DBACCESS /G/data09/wwebdb/dbaccess } MapDefine =PATHMAP /G/data09/wwebdb/pathmap MapDefine =CLUSTERS /G/data09/wwebdb/clusters Numstatic 4 Maxservers 400 Stderr $root/logs/rmt.log Stdin /dev/nullstdout $root/logs/rmt.log } RmtServer $rmt HTTP11_SUPPORTED specifies that the target server can support HTTP1.1 requests. If this variable is not set to ON, WS Plug-in replaces HTTP1.1 with HTTP1.0 in the first line of the request header. This feature is provided for compatibility with the existing RLS product. When using the WS Plug-in with WebLogic Server, you must set this option to ON. LOG_DIR and TRACE_LEVEL control tracing output to the log file. Set TRACE_LEVEL to a value of 1 to enable basic tracing or set it to a value of 2 to enable verbose tracing. Level one tracing displays the headers and contents of messages sent between the client and the WebLogic Server. You might find this useful when investigating application 8-8

63 Using the WS Plug-in Defining the WS Plug-in Server Class problems. Level two should only be used if instructed to do so by HP support staff. If you enable tracing, you must also specify the Stderr standard error file. If you want a separate log file for each WS Plug-in server process, set LOG_DIR to the pathname of an existing directory. Each WS Plug-in process will create a separate file in that directory to which tracing information will be written. The WS Plug-in process name (without the leading dollar sign) is used for the filename. RETRY_PERIOD Determines the number of seconds the WS Plug-in servers wait before attempting to communicate with a previously failed target application server process in a cluster. This variable applies only to prefixes for which J2EE mode is enabled. The default value is 30 seconds. Note that this period is the minimum delay; the actual delay could be almost as long as RETRY_PERIOD plus STATS_PERIOD because the WS Plug-in processes only check the cluster status table if the fault indicator in the prefix status table has been updated since that WS Plug-in process last checked the cluster status table. If no other server processes fail after a target application server process is marked as failed, the WS Plug-in processes will not be advised to check the cluster status table and, therefore, will not try to contact the failed server again. However, the WS Plug-in checks the cluster status table at the start of each STATS_PERIOD. STATS_PERIOD Sets the interval in seconds between recalculations of the capacity of each target application server process in the cluster. The default is 30 seconds. Note that each WS Plug-in process collects and reports its own statistics separately. Also, statistics are recorded and reported separately for each URL prefix configured. A WS Plug-in process will only check for STATS_PERIOD expiry when it receives a request for a particular prefix. Thus if no requests for a given prefix are received by the WS Plug-in process for a period greater than the configured period, the STATS_PERIOD will be extended to the time between requests. SHOW_STATS controls whether capacity and workload statistics are displayed. ON EMS usage statistics for each server in the cluster are written to the log file at the end of each STATS_PERIOD usage statistics are written to the Event Message System log Example 8-3. WS Plug-in Statistics Output Prefix: prefix, Address: addr, Port: port, Capacity: c, New Sessions: sessions, Posts: posts 8-9

64 Using the WS Plug-in Defining the WS Plug-in Server Class The statistics information is repeated for each target application server process in the cluster. prefix The URL prefix to which these statistics relate. Address and Port NonStop TCP/IPv6 address and port that the target application server process is configured to use. Capacity is calculated based on the number of posts and new session creations that occurred during the previous STATS_PERIOD. If the application does not use HTTP sessions, the session count is not included in the calculation. A capacity of -1 indicates that the target application server process is marked as failed. posts and sessions the count of posts and sessions that occurred during that period plus 10 percent of the total for the previous period. The WS Plug-in defines a 'post' as any POST directive or a GET directive that includes a query string. This approach is designed to distinguish requests that will cause the Application Server to perform tasks that are likely to consume significant resources from requests that merely entail the Application Server returning static content. If RATED_STATS is set to ON, these values are the average number per minute during the STATS_PERIOD. If the application does not use HTTP sessions, the New Session value is omitted from the statistics display. SESSION_BALANCING The default approach to load balancing is round-robin. This means that each WS Plug-in process will send subsequent requests to a different member of the cluster. Setting this option to ON causes the WS Plug-in to use the posts, sessions and capacity values (see above) to determine the best member of the cluster to use. KEEP_ALIVE causes the WS Plug-in to retain the NonStop TCP/IPv6 connection with an Application Server at the end of each request. If this variable is not set to ON, NonStop TCP/IPv6 closes connection with an Application Server at the end of each request. The default is OFF. This feature is provided for compatibility with the existing RLS product. When using the WS Plug-in with the WebLogic Server, you should usually set this option to ON. However, in the event of problems with having too many NonStop TCP/IPv6 connections, you might want to suppress this feature. 8-10

65 Using the WS Plug-in WS Plug-in Configuration Tool AUTO_LOAD set this to ON to enable automatic detection of configuration database updates. The WS Plug-in processes read the configuration database at startup and build an internal list of URL prefixes and the cluster to which requests should be sent. The itp WebServer sends all requests it cannot process to the WS Plug-in. If the prefix is not in the WS Plug-in's list, it will generate an EMS message and reject the request. However, if this option is turned on, itp WebServer will first check to see if the configuration database tables have been updated since the process last read them. If so, it will reload the configuration data and try to find the requested prefix in the new internal list. Note that setting the auto load option will not cause existing WS Plug-in processes to detect changes to previously configured prefixes, that is, if you add a server to a cluster or direct a previously configured prefix to be routed to a different cluster. This scenario can be dealt with by forcing the WS Plug-in processes to reload the current configuration from the database tables - see Modifying the Database for details. The default is OFF, which means the WS Plug-in does not check for recent modification of the configuration database tables. In this case, you need to use the make utility to force the WS Plug-in processes to reload the current configuration from the database tables - see Modifying the Database for details. DISPLAY_CONFIG The WS Plug-in includes the facility to view the current configuration using a Web Browser. For security reasons the default is OFF. Set this option to ON to enable this facility. To view the configuration, enter the '_PluginConfig' URL. Note there are a number of itp WebServer directives that can be used to restrict access to the Configuration Display. See the itp Secure WebServer System Administrator's Guide for information. WS Plug-in Configuration Tool The WS Plug-in Configuration Tool for WebLogic Server uses the WebLogic Server configuration file (config.xml) and user-provided input to add entries to the WS Plug-in's SQL/MP database script file (dbload.sqlci). You can then use the make utility to update the database and signal the active WS Plug-in processes to reload the new configuration, see Modifying the Database below. The configuration tool is run using the plugin-config.sh shell script located in itp WebServer directory/bin/rmt. You can run this script from any directory. Write access is required to the itp WebServer directory/bin/rmt directory and the dbload.sqlci contained in that directory. Only one user can run the utility at any one time. 8-11

66 Using the WS Plug-in WS Plug-in Configuration Tool The tool picks up default settings from a file called itpwls-defs.sh located in the itp WebServer directory/bin/rmt directory. The default contents are: export _WLS_DOMAIN_NAME=mydomain export _WLS_CLUSTER_NAME=MyCluster export _TCPIP_PROCESS_NAME=ZTC0 #export _WLS_COOKIE_NAME=JSESSIONID export _PLUGIN_PATH_NAME=/usr/webserver/bin/rmt export _WLS_PATH_NAME=$BEA_HOME/user_projects/domains You can update this file to reflect the environment on your system. Additionally, the script looks for a file called itpwls-defs.sh in your current working directory. If this file exists, any settings contained in it are used in preference to those set in the itp WebServer directory/bin/rmt/itpwls-defs.sh file. This means that you can set system-wide defaults in the itp WebServer directory/bin/rmt/itpwls-defs.sh and also override these on a temporary basis by creating an itpwls-defs.sh file in your current directory. All the settings contained in the itpwls-defs.sh file(s) can be overridden using command line arguments. Note that the installation script updates the value of the WS Plug-in path setting in the itpwls-defs.sh file to reference the directory this file is located. The plugin-config.sh script accepts the following arguments: [-w WLS URL Prefix] This argument specifies the URL prefix of the WebLogic Server application, that is, /SlotServletRoot. [-u Plug-in URL Prefix] Use the -u flag to specify the WS Plug-in URL prefix. If this argument is included (and specifies a different URL prefix from the WebLogic Server URL Prefix specified with the -w flag), the tool will add a mapping from the WS Plug-in URL to the WebLogic Server URL. This provides the facility to specify a different URL prefix from the prefix used by the application deployed in WebLogic Server to be used by the WS Plug-in. For example, specifying -u /Slot and -w /SlotServletRoot means that any request sent to WebServer Address/Slot/ will be routed to a member of the target WebLogic Server cluster as /SlotServletRoot/. Use the Configuration Display feature to check that the itp prefix chosen is not already in use. This facility enables you to configure multiple instances of the same application in different WebLogic Server clusters and access them through the same itp WebServer/Plug-in. There are a number of circumstances that might warrant this requirement. You might want to partition users by category. For example, the Call Center staff to a high priority cluster, high value customers to a medium priority cluster, and other customer to a lower priority cluster. It might also be useful during the introduction of new versions of an application.that is, deploy the new version in a separate WebLogic Server cluster for live testing or a pilot for a restricted group of 8-12

67 Using the WS Plug-in WS Plug-in Configuration Tool users and then simply alter the WS Plug-in configuration to switch all users transparently across to the new version of the application. If the -w, -a, and -u options are all omitted, the tool configures a cluster without any application. This enables you to add clusters separately from the applications that use them. [-d WebLogic Server domain name] Use the -d option to override the default domain name. [-c WebLogic Server cluster name] Use the -c option to override the default cluster name. [-i TCPIP Process Name] The -i option is used to specify the name of the NonStop TCP/IPv6 process name to be used. If this option is not supplied, the value in the default settings file is used. The NonStop TCP/IPv6 process name should be specified in Guardian format, without the leading dollar sign. Note that this setting determines the NonStop TCP/IPv6 process used by the WS Plug-in to communicate with the WebLogic Servers that make up the specified cluster. If the target servers are on the same system as the WS Plug-in, HP recommends that you specify the same NonStop TCP/IPv6 process as used by the target servers as this improves performance. To determine the NonStop TCP/IPv6 process associated with your WebLogic Server cluster, run the script that checks the prerequisite software (check-wl-hpns.sh). If the target servers are on another system, it is important to ensure that the target address is reachable from the subnet associated with the NonStop TCP/IPv6 process specified. [-n WS Plug-in Cluster Name] The -n option is used to specify the name the WS Plug-in knows the cluster by. If omitted, the WS Plug-in cluster name is constructed using the WebLogic Server domain and cluster name. For example, given the defaults shown above, the WS Plugin cluster name would be mydomain-mycluster. Use this option to specify an alternative name. Use the Configuration Display feature to check that the cluster name you chose is not already in use. [-a] The -a option is used to inform the configuration tool that you are configuring a new application using an existing cluster. If this option is specified, one of the -u or -w options is required. The -d and -c or -n options can be used to specify the WS Plugin cluster name to which the application is to be associated. Note that the tool is not able to check that the WS Plug-in cluster name specified exists. [-x Cookie Name] Use the -x option to specify the name of the session cookie used by the application being configured. The default is no session cookie, which means the WS Plug-in does not look for a session cookie. This is the correct behavior for stateless applications. For session-based applications, use this option to specify the session cookie name. 8-13

68 Using the WS Plug-in WS Plug-in Configuration Tool [-p Pathname to WS Plug-in directory] The -p option is used to specify the path to the WS Plug-in directory. It can be used to override the WS Plug-in directory. This may be useful if you want to update an alternative dbload.sqlci file. [-l Pathname to WebLogic Server domains directory] The -l option is used to specify the path to the directory where the WebLogic Server domain directory is located. The default location is bea_home/user_projects/domains. This option can be used to direct the tool to use a different directory from the one specified in the itpwls-defs.sh file. This is useful for processing a config.xml file relating to a domain running on a remote system. To do this, copy the config.xml file to the local system, locating it in a directory reflecting the domain name and use this option to reference that directory's parent. [-t] The -t option causes the configuration tool to show details of the setting used and tasks performed. [-v] The -v option turns on the XSLT script tracing mode and is intended for Support use only. Examples: Before using the configuration tool for the first time, update the itpwls-defs.sh file: export _WLS_DOMAIN_NAME=MyDomainName export _WLS_CLUSTER_NAME=Cluster4 export _TCPIP_PROCESS_NAME=ZSM1 #export _WLS_COOKIE_NAME=JSESSIONID export _PLUGIN_PATH_NAME=/projects/MyApp/Apps/webserver/bin/rmt export _WLS_PATH_NAME=/projects/MyApp/Apps/WLS The name of the target WebLogic Server domain is MyDomainName and the domain directory is located in /projects/myapp/apps/wls. The MyDomainName domain has a cluster called Cluster4. Finally, the NonStop TCP/IPv6 Process Name has been updated to reflect the name of the NonStop TCP/IPv6 process. With these 8-14

69 Using the WS Plug-in WS Plug-in Configuration Tool defaults set, the configuration tool can be used to add the MyDomain application as follows: plugin-config.sh -w /MyDomain Processing /projects/myapp/apps/wls/mydomain/config.xml for Cluster Name: Cluster4 Generating itp Plug-in configuration Saving existing dbload.sqlci to _dbload.sqlci Adding new config to /projects/myapp/apps/webserver/bin/rmt/dbload.sqlci Update of dbload.sqlci completed. To implement new configuration change directory to /projects/myapp/apps/webserver/bin/rmt and then Type 'make dbload' to update configuration database Type 'make refresh' to force running servers to load new configuration The configuration tool adds the appropriate configuration entries to the dbload.sqlci file in the directory referred to by the PLUGIN_PATH_NAME setting shown above. cat dbload.sqlci Generated by itp Plug-in WLS config tool Configuration for Application:/MyDomain -- deployed to WLS cluster: Cluster4, in WLS Domain: MyDomainName -- insert into =dbaccess values ("/MyDomain", "MyDomainName- Cluster4", 0,"x",0,-1,1,""); -- Configuring itp Plug-in cluster: MyDomainName-Cluster4 -- to access WLS cluster: Cluster4, in WLS Domain: MyDomainName -- insert into =clusters values ("MyDomainName- Cluster4"," ",8023,"$ZSM1", 1); -- insert into =clusters values ("MyDomainName- Cluster4"," ",8024,"$ZSM1", 2); -- insert into =clusters values ("MyDomainName- Cluster4"," ",8025,"$ZSM1", 3); -- insert into =clusters values ("MyDomainName- Cluster4"," ",8026,"$ZSM1", 4); 8-15

70 Using the WS Plug-in Configuring the itp WebServer to Process Static Content The WS Plug-in configuration database can be reloaded using the make utility. The utility must be run from the directory referred to by the PLUGIN_PATH_NAME setting shown above: make dbload The WS Plug-in processes will utilize the new setting the next time they load the configuration from the database. This occurs at process startup and restarts following a process termination. Note that the HTTP daemon terminates the WS Plug-in process when a request is canceled, so you should be aware that some of the WS Plug-in servers could begin using the new configuration at any time. Also, note that if the configuration changes the addition of a new application, the AUTO_LOAD directive can be used to force the WS Plug-in processes to load the new configuration as required. Alternatively, the make utility can be used to force all WS Plug-in processes to reload the configuration before processing a new request: make refresh Configuring the itp WebServer to Process Static Content The itp WebServer is capable of serving static content (web pages, image files, applets, etc.) much more efficiently than an application server. It is possible to configure the itp WebServer to perform this function for the applications deployed to the WebLogic Server. To do this, add a Filemap to the itp WebServer configuration file (httpd.conf file in the itp WebServer's conf directory, /usr/tandem/webserver/conf, by default). First, add a Filemap directive for the WS Plug-in URL prefix. Filemap /wls-mydomainname /Apps/MyDomain The Filemap should map the prefix used by the client to a directory where the.war file has been unpacked. This directory can be located anywhere in the OSS filesystem. One approach is to create a subdirectory in the directory where your.ear or.war file is and name it the same as the WebLogic Server URL prefix. For example, assuming that your application directory is /Apps and this directory contains a MyDomain.war or MyDomain.ear file, create a directory called MyDomain and unpack the contents of the.war file (which is in the.ear file) into this directory. For example: cd /Apps/ mkdir MyDomain jar -xf MyDomain.ear MyDomain.war - Skip this if your application is in a.war file. cd MyDomain jar -xf../mydomain.war rm -rf *-INF Note the last line removes the WEB-INF directory, which contains non-static content. The META-INF and WEB-INF directories are standard and will probably not contain static content, so they can be safely removed in most cases. In general, you should remove the *-INF directories and also any *.jsp files. Note that the.war file might contain multiple directories, possibly containing subdirectories. You need to ensure 8-16

71 Using the WS Plug-in Creating the Database that all non-static content is removed from all these directory subtrees. The easiest way to do this is the use the find utility to list files that should be processed by the application server and then remove them. Note that if you use prefix mapping, it is necessary to enter one of these filemap directives for each different WS Plug-in URL prefix that maps to the same application. For example, WS Plug-in URL prefixes /wls-mydomainname and /wls4- MyDomainName map to the same version of the MyDomain application (deployed in different clusters). In this case add: Filemap /wls-mydomainname /Apps/MyDomain Filemap /wls4-mydomainname /Apps/MyDomain Note that welcome-file specified in the WEB.XML should be added to the IndexFile directive. For example, if your application has a welcome file called myindex.html, you should add this to the existing IndexFile directive in the itp WebServer configuration file. # List of html files to look for when a client only specifies a # directory name # IndexFile index.html index.htm home.html home.htm myindex.html Creating the Database You must update the database files to configure the WS Plug-in. HP recommends that you use the entries in the cluster table to configure the individual target application server processes of an application server. This action causes the WS Plug-in to update the DBFILES and DBSTATUS tables with details of failed target application server processes, which alerts other WS Plug-in processes about failed application server processes. If you do not use the cluster configuration approach and configure the individual target application server processes in the DBACCESS table, then each WS Plug-in independently identifies failed server processes in its application server and does not retry them unless all target application server processes are marked as failed. Note. HP strongly recommends that you configure the application server processes by using the entries in the cluster table. The option of configuring individual target application server processes in the DBACCESS table is provided solely for compatibility with previous version of the RLS. To customize the database, edit the file dbload.sqlci in the itp Secure WebServer's /bin/rmt directory. When you run the make command to build the WS Plug-in, the data in dbload.sqlci is loaded into the DBACCESS, CLUSTER and PATHMAP tables. 8-17

72 Using the WS Plug-in Creating the Database DBACCESS Table The rows in the DBACCESS table define which servers or domain that requests for an application table should be sent to. An application table is defined by a pathname prefix. Each row includes the following columns: Filename Ip_addr Port Tcpip No_Servers relative_id noredirect Cookie_name Filename is the prefix that defines an application. The maximum size is 200 characters; wildcard characters are not valid. The text in this field must match the first element of the URL pathname specified by the client, including the leading forward slash. For example, if the client enters: addr./slot/slotservlet?clientid=0&betcount=1&machineid=0 Filename should contain /Slot to route the request to the domain named in the Ip_addr field. Ip_addr specifies the address of the remote server. The value can be either an address in dotted decimal format or a cluster name; the value cannot exceed 40 characters. If No_Servers contains a zero, Ip_addr is interpreted as a cluster name and is used to look up the individual target application server processes of the cluster in the CLUSTER table. Port If No_Servers contains a non-zero value, this field specifies the port number of the remote server. Otherwise, the contents of this field are ignored. Tcpip If No_Servers contains a non-zero value, specifies the name of the local NonStop TCP/IPv6 process that the RLS must use to connect to the remote web server. You can specify any NonStop TCP/IPv6 process on your system. If the server defined in this record is on the same system as the WS Plug-in, you must still specify a NonStop TCP/IPv6 process name, but the WS Plug-in ignores it. Specify the process name in Guardian format: a dollar sign ($) followed by up to five characters. Otherwise, the contents of this field are ignored. No_Servers Enter a 0 in this field to cause the WS Plug-in to interpret the Ip_addr field as a cluster name. All other fields in this record are ignored except noredirect and Cookie_name. 8-18

73 Using the WS Plug-in Creating the Database If this field contains a value other than 0, the value specifies the number of replicated servers in the cluster. Each replicated server must be represented by its own record. The value of No_Servers must be the same in each record. Maximum value is 50. Relative_ID If No_Servers contains a 0, this field is ignored. If No_Servers contains a value other than 0, that value is used to assign a record number. The first record is numbered 0. The maximum record number is No two records in the table can have the same value for this field. You do not have to list the records in order in dbload.sqlci. However, it is practical not to leave gaps in the numbering. For example, if you create five records, they can be numbered 0, 1, 2, 3, and 4. noredirect If noredirect contains a 0, J2EE mode is disabled. If it contains a value other than 0, J2EE mode is enabled. If it contains a positive value, request redirection is suppressed. Cookie_name Some application servers allow you to specify the name of an HTTP sessiontracking cookie to be used for each deployed application. If the target application is deployed in an application server that supports this feature, enter the cookie name used by the target application. Because WebLogic Server does not support this feature, set this field to JSESSIONID, which is the default name of the HTTP session-tracking cookie name. CLUSTER Table The rows in the CLUSTER table define the target cluster members in a WebLogic Server cluster. This table is used when configuring clusters. When configuring multiple clusters, in which you deploy the same application to each cluster, you can specify all the target application server processes for all the clusters in the CLUSTER table. This allows you to distribute requests to itp Secure WebServer across multiple clusters. Each row includes the following columns: Filename Ip_addr Port Tcpip relative_id Filename specifies the name of the domain in which the target application server processes are located. 8-19

74 Using the WS Plug-in Creating the Database Ip_addr specifies the address of the target application server process. The value can be either an address in dotted decimal format or a domain name; the value cannot exceed 40 characters. Port specifies the port number of the target application server process. Tcpip specifies the name of the local NonStop TCP/IPv6 process that the WS Plug-in must use to connect to the remote web server. You can specify any NonStop TCP/IPv6 process on your system. If the server defined in this record is on the same system as the WS Plug-in, you must still specify a NonStop TCP/IPv6 process name, but the WS Plug-in ignores it. Specify the process name in Guardian format: a dollar sign ($) followed by up to five characters. Relative_ID assigns a record number within the group of records that have the same domain name. The first record is numbered 1. The maximum record number is 500. No two records with the same domain name can have the same value for this field. You do not have to list the records in order in dbload.sqlci. However, it is practical not to leave gaps in the numbering. For example, if you create four records, they can be numbered 1, 2, 3, and 4. PATHMAP Table The rows in the PATHMAP table map the application name (prefix) specified by the client to the one expected by the server. Each row includes the following columns: USER_PATH SERVER_PATH USER_PATH contains the prefix entered by the client. SERVER_PATH contains the prefix required by the server. Example In the following example, the prefixes /sample.html and /samples specify the web server with the domain name localhost and which is listening on port 80. insert into =dbaccess values ("/sample.html","localhost",80,"$ztc0",1,0,0); insert into =dbaccess values ("/samples", "localhost",80,"$ztc0",1,1,0); 8-20

75 Using the WS Plug-in Modifying the Database In the following example, the prefix /Slot invokes the least busy target application server process in the cluster called Test-Cluster. This cluster is defined in the clusters file and includes two target application server processes that are listening on ports 4080 and (The port numbers are specified in the configuration file for the cluster.) The path mapping converts the /Slot prefix to /SlotServletRoot before forwarding requests to the application server. insert into =dbaccess values ("/Slot", "Test-Cluster", 0,"x",0,-1,1); -- Clusters insert into =clusters values ("Test-Cluster","localhost",4080,"$ztc0",1); insert into =clusters values ("Test-Cluster","localhost",4090,"$ztc0",2); -- Path Mapping insert into =pathmap values ("/Slot","/SlotServletRoot"); Modifying the Database When you first build and install the WS Plug-in, the make command loads the database with the data in dbload.sqlci. To update the database, however, you do not need to reinstall the WS Plug-in. To Update the Database, Without Changing the Locations of the Database Files: 1. Update the dbload.sqlci file. 2. Use NonStop TS/MP PATHCOM to stop the WS Plug-in server class. 3. Change to the WS Plug-in directory (itpws directory/bin/rmt) and use the make dbload command to update the database tables. 4. Use PATHCOM to start the WS Plug-in server class. To Update the Database Without Stopping the WS Plug-in Servers: 1. Update the dbload.sqlci file. 2. Change to the WS Plug-in directory (itpws directory/bin/rmt) and use the make dbload command to update the database tables 3. Use the make refresh command to force the WS Plug-in processes to load the new configuration. To Change the Location of the Database: 1. Stop the itp Secure WebServer environment. 8-21

76 Using the WS Plug-in Migration Considerations 2. Use the make clean command in the WS Plug-in directory (itpws directory/bin/rmt) to remove the rmt.pway file executable and delete the existing database. 3. Change the values of DB_VOLUME and DB_SUBVOLUME in the make file to specify the new Guardian volume and subvolume location. 4. Use the make command to create a new database and build the rmt.pway executable. 5. If the Auto Load option is used, update the MapDefine entries in the Plug-in section of the httpd.config file. 6. Restart the itp Secure WebServer environment. Migration Considerations The WS Plug-in can be used with existing versions of itp Secure WebServer. However, if you use itp Secure WebServer, you must modify your existing configuration by adding the no_redirect column to the dbload script. To add the no_redirect column to the dbload script, add a 0 (zero) to each line in the dbload script. For example, change the following line insert into =dbaccess values ("/sample.html","localhost",80,"$ztc0",1,0); to insert into =dbaccess values ("/sample.html","localhost",80,"$ztc0",1,0,0); HP recommends that when you migrate from the itp Secure WebServer version of the WS Plug-in: Use the database creation/removal scripts that are distributed with the WebLogic Server. Replace the example dbload script with your current, customized dbload script. WS Plug-in Event Messages (5000 through 5024) The following messages are generated by the WS Plug-in in addition to the RLS messages documented in the Operator Messages Manual (#5001) (#1) WS Plug-in unable to service request because all remote servers are hanging Cause. The WS Plug-in cannot service the request because all the servers are marked as failed. Effect. The WS Plug-in stops trying to process the request. 8-22

77 Using the WS Plug-in WS Plug-in Event Messages (5000 through 5024) Recovery. Investigate the reason why the servers are not responding and take corrective action (#5002) (#2) WS Plug-in unable to service request because all servers are broken, waiting for retry-secs seconds retry-secs The number of seconds delay before retrying the request. This value cannot be greater than the value of the RETRY_PERIOD environmental variable. Cause. The WS Plug-in has marked as failed all the servers that can service this request. Effect. The WS Plug-in waits for the specified number of seconds before checking the status of the servers again. If there are still no available servers after waiting for more than the value of the RETRY_PERIOD environmental variable, the WS Plug-in tries to contact one of the servers. If this attempt fails, the WS Plug-in generates event Recovery. Investigate the reason why the servers are not responding and take corrective action (#5003) (#3) CGI_fread failed Cause. The WS Plug-in cannot read a request from the HTTPD process. Effect. The WS Plug-in stops trying to process the current request. Recovery. If problem persists, check itp Secure WebServer logs and event messages to determine cause of problem (#5004) (#4) WS-Plug-in encountered database error error error SQLMP error code. Cause. The WS Plug-in cannot access the database files used to configure and control its operation. Effect. The WS Plug-in stops trying to process the request. Recovery. Verify the database tables and take corrective action. 8-23

78 Using the WS Plug-in WS Plug-in Event Messages (5000 through 5024) 5005 (#5005) (#5) Description-of-error Description-of-Error This is a text description of the error message. The description might include an error number. Cause. The WS Plug-in encountered a network or communications error. Effect. The WS Plug-in stops trying to send the request to the currently selected target application server process and looks for an alternate target application server process. Recovery. Informational message only. The message is usually accompanied by message (#5006) (#6) Description-of-error - error-code Description-of-Error This is a text description of the error message. error-code SQLMP error code. Cause. The WS Plug-in encountered a database error. Effect. The WS Plug-in abandons the current database operation and continues processing the request. Recovery. Informational message only. A number of these messages can be generated in the event of multiple WS Plug-in processes detecting a failed application server process at the same time. Under these circumstances all of the processes will attempt to add a record to the DBSTATUS table to reflect the target application server process status. Only the first is successful; the others generate this message (#5007) (#7) Unable to operation remote server address port port operation This is a text description of the error. Valid values are: Connect Recv data Send data address and port The address and port number of the target application server process for which the operation failed. 8-24

79 Using the WS Plug-in WS Plug-in Event Messages (5000 through 5024) Cause. The WS Plug-in cannot communicate with the specified target application server process. Effect. The WS Plug-in stops trying to send the request to the currently selected application server process and looks for an alternate server process. The WS Plug-in periodically retries. Recovery. Investigate why the target application server process is not responding and take corrective action (#5008) (#8) Prefix pfx, Addr: addr, Port port, Capacity cap, Posts posts, Sessions sess pfx The URL prefix that identifies an application. addr and port The address and port number of the target application server process to which the statistics apply. cap The calculated capacity of the target application server process. The higher this value, the more likely the server process is to be selected by the WS Plug-in load balancing feature. A value of -1 indicates that the target application server process is unavailable. posts The number or rate of requests sent to the target application server process. sess The number or rate of new sessions associated with the target application server process. This value is only included for applications that use HTTP sessions. Cause. The WS Plug-in is configured to generate periodic statistics events. Effect. None. Recovery. Informational message only; no recovery required (#5009) (#9) Status 500 from AppServer Cause. The WS Plug-in received an HTTP Status 500 response from the target application server process. Effect. The WS Plug-in reports this event but take no other action. The Status 500 reply is sent back to the client. 8-25

80 Using the WS Plug-in WS Plug-in Event Messages (5000 through 5024) Recovery. Investigate why the Status 500 messages are being generated by the application server and take corrective action (#5010) (#10) path not found because pfx not in the DBACCESS table path The pathname component of the URL specified by the client. pfx The first component of the pathname that identifies an application. Cause. The WS Plug-in cannot find an entry for the prefix in the DBACCESS table. Effect. The WS Plug-in stops trying to process the request. Recovery. Verify the contents of the database table and take corrective action if necessary (#5011) (#11) Load of Config failed Cause. The WS Plug-in encountered an error while loading the configuration from the database. Effect. The WS Plug-in stops trying to process the request. Recovery. Verify the database tables and take corrective action (#5012) (#12) Multiple zero bytes replies received, aborting Cause. The WS Plug-in received consecutive zero-length messages from the TCP/IP process while waiting for a reply from the target application server process. Effect. The WS Plug-in stops trying to send the request to the currently selected application server process and looks for an alternate target application server process. The WS Plug-in periodically retries. Recovery. Investigate why the target application server process is not responding and take corrective action (#5013) (#13) Unable to open TCP/IP process tcpip-process tcpip-process The name of the TCP/IP process. 8-26

81 Using the WS Plug-in Troubleshooting Cause. The WS Plug-in was unable to communicate with the TCP/IP process while trying to contact a target application server process. Effect. The WS Plug-in stops trying to send the request to the currently selected application server process and looks for an alternate target application server process. The RLS periodically retries. Recovery. Investigate why the TCP/IP process is not responding and take corrective action. Troubleshooting The TS/MP numstatic setting for the rmt.pway Plugin should be at least 2 to 1 with regard to the TS/MP numstatic setting of the httpd process. For example, if numstatic is set to 5 for the httpd serverclass, the rmt.pway serverclass should have a numstatic setting of at least 10. (The TS/MP maxservers setting for the rmt.pway serverclass would also have to be set to at least 10). If the rmt.pway setting is not correct, the rmt.pway serverclass gets TS/MP error If access.log shows that it is using HTTP/1.0 even if the rmt.pway serverclass has been configured with HTTP11_SUPPORT ON, could signify that the current configuration settings for the httpd rmt.pway serverlass coupled with the BEA WebLogic Server, are not well tuned or adequate for the current environment. This can be accompanied by error messages in the error log that state, Zero length reply received from server, Aborting. In general, this means that configured resources are overloaded. Check /usr/tandem/webserver/logs/httpd.log for itp Secure WebServer messages. For more troubleshooting information, see the HP itp Secure WebServer documentation. 8-27

82 Using the WS Plug-in Troubleshooting 8-28

83 9 Managing the SQL/MX Tables for BLOB and CLOB Data Creating SQL/MX Tables Providing Properties to the JDBC Driver Creating SQL/MX Tables WebLogic Server uses Large Objects (LOBs) in its application. LOBs are stored by SQL/MX in a special manner and can only be accessed by configuring a JDBC Connection Pool to use either the com.tandem.sqlmx.sqlmxdriver driver or the com.hp.nsk.xares.wlstxsqlmxdatasource driver. See Configuring the JDBC Connection Pools for SQL/MX in Section 6. WebLogic Server stores both Binary Large Object (BLOB) data and Character Large Object (CLOB) data. The JDBC driver implementation of BLOB/CLOB requires the existence of two special tables to store the BLOB/CLOB data. Generically, these tables are called a blobtable (for BLOB data) and a clobtable (for CLOB data). When data is inserted or updated in a base table (a table containing a column with a BLOB or CLOB datatype), the JDBC driver places a reference to the blobtable or clobtable in the base table and stores the actual BLOB/CLOB data in the blobtable or clobtable. Providing Properties to the JDBC Driver You must identify the location of these tables to the supported driver by specifying their names as properties to the driver. You use the JAVA_OPTIONS environment variable to supply the properties as follows: export JAVA_OPTIONS= -Djdbcmx.blobTableName=mycat.myschema.ZZWLI_BLOBTABLE -Djdbcmx.clobTableName=mycat.myschema.ZZWLI_CLOBTABLE Note. These three lines should be typed as one line. mycat is the catalog name of your catalog and myschema is the name of your schema. For ease of use, you can put the export statement in a shell script that you execute each time you start your application. 9-1

84 Managing the SQL/MX Tables for BLOB and CLOB Data Providing Properties to the JDBC Driver 9-2

85 10 Sample Application WebLogic Server Sample Application Running MedRec Application in the Installed WebLogic Server Location Accessing MedRec from a Web Browser Running MedRec in Another Location WebLogic Server Sample Application MedRec is a sample reference application that demonstrates the BEA WebLogic Server features. If you are running with NonStop SQL/MX Version 2.0 Native Tables, the SQL/MX directory is medrec_sqlmx. If you are running with NonStop SQL/MX Version 2.0 MX Tables, the SQL/MX directory is medrec_sqlmx2. For optimal performance on the NonStop server, MedRec uses NonStop SQL/MX. Running MedRec Application in the Installed WebLogic Server Location The easiest place to run MedRec is in the installed location which, by default, is /usr/bea/weblogic81. However, running MedRec in the installed location changes files in the installed directories, which can cause problems for other users who want to run private copies of MedRec. Also, you need write access to the installation directories. Before you run MedRec or other applications with WebLogic Server, ensure that the NonStop server is using the correct software prerequisites and your shell environment has correct values. Note that the MedRec sample application accesses the internet. If your server requires a proxy to access the internet, edit the startmedrecserver.sh command procedure to set -Dhttp.proxyHost, -Dhttp.proxyPort, and -Dhttp.nonProxyHosts. Set and export environment variables for use of NonStop Server for Java 4.0 and NonStop TCP/IPv6. For example: ksh [125] export JAVA_HOME=/usr/tandem/java ksh [126] export PATH=$JAVA_HOME/bin:$PATH ksh [127] export WL_HOME=/usr/bea/weblogic81 ksh [128] add_define =PTCPIP^FILTER^KEY class=map file=mykey If your NonStop TCP/IPv6 process is not named $ZTC0, create a define so that WebLogic Servers started by this shell use NonStop TCP/IPv6. For example: ksh [129] add_define =TCPIP^PROCESS^NAME class=map file=\$zsm1 It is recommended that you save these commands in a file, such as your.profile. 10-1

86 Sample Application Running MedRec Application in the Installed WebLogic Server Location The prerequisite software and shell environment can be checked using the same script run during the installation. For example: ksh [130] $WL_HOME/server/lib/hpns/check-wl-hpns.sh To run MedRec in directories outside the installed WebLogic Server location, see Running MedRec in Another Location. During installation of the NonStop Server Toolkit, extra files needed to run MedRec sample application are copied into the directory: $WL_HOME/samples/domains/medrec_sqlmx if you are running SQL/MX Version 2.0 native tables or $WL_HOME/samples/domains/medrec_sqlmx2 if you are running SQL/MX Version 2.0 MX Tables. This location can be used to run MedRec immediately after installation. If you have previously run medrec_sqlmx or medrec_sqlmx2, you might need to clean up before running medrec_sqlmx or medrec_sqlmx2 again. To clean up, run the cleanmedrec_sqlmx.sh script using the same userid as the previous user who ran medrec_sqlmx or medrec_sqlmx2. To run the sample application, ensure that environment variables are set and exported, then use the startmedrecserver_sqlmx.sh script. For example: ksh [134] export JAVA_HOME=/usr/tandem/nssjava/jdk142_h10 ksh [135] export PATH=$PATH:$JAVA_HOME/bin ksh [136] export WL_HOME=/usr/bea/weblogic81 ksh [137] cd $WL_HOME/samples/domains/medrec_sqlmx ksh [138]../startMedRecServer_sqlmx.sh Note that startmedrecserver_sqlmx.sh calls $WL_HOME/common/bin/commEnv.sh, which sets the variables _RLD_LIB_PATH and _RLD_FIRST_LIB_PATH. The following portions of output from the startmedrecserver_sqlmx.sh script are useful to note: *************************************************** * To start WebLogic Server, use a username and * * password assigned to an admin-level user. For * * server administration, use the WebLogic Server * * console at * *************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ After the server has booted, point your browser to the URL " to view the WebLogic Server Index running on this server. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <Dec 2, :00:20 PM PST> <Notice> <WebLogicServer> <BEA > <Server started in RUNNING mode> <Dec 2, :00:19 PM PST> <Notice> <WebLogicServer> <BEA > <Thread "ListenThread.Default" listening on port 7001, ip address *.*> <Dec 2, :00:19 PM PST> <Notice> <WebLogicServer> <BEA > <Thread "SSLListenThread.Default" listening on port 7002, ip address *.*> 10-2

87 Sample Application Running MedRec Application in the Installed WebLogic Server Location The NonStop SQL catalog is created and populated the first time you start this sample application and the catalog name is put into files you can use to control the catalog. Subsequent starts of MedRec will keep the same catalog data. Also, the scripts that control the catalog are available in the directory db where you are running the application. The defaults used with NonStop SQL are: SQL/MX catalog SQL/MX schema SQL/MP subvolume (applies to SQL/MX 2.0 native tables only) TMF resource manager The current user s group. For example, DEV. The current user s ID. For example, USER. The current user s default subvolume. medrec To specify other values for these default values, read the instructions in the script create_medrecdb.sh. Be sure to escape the dollar-sign ($) character in the volume name. To use any of these scripts, change to the correct directory and run the script. For example, to repopulate the catalog: ksh [142] cd $WL_HOME/samples/domains/medrec_sqlmx/db ksh [143] create_medrecdb.sh -reload The other scripts are input files to SQL. Be sure to use the correct command interpreter. For example, to remove the catalog after you have finished using the sample application: ksh [144] cd $WL_HOME/samples/domains/medrec_sqlmx/schema/db ksh [145] create_medrecdb.sh -drop Accessing MedRec from a Web Browser From a web browser, view the initial MedRec screen at the address that was output at the shell when the application started. 10-3

88 Sample Application Running MedRec Application in the Installed WebLogic Server Location Figure 10-1 and Figure 10-2 show the initial MedRec screens. Figure Initial MedRec Screen 10-4

89 Sample Application Running MedRec in Another Location Figure MedRec Logon Screen Running MedRec in Another Location You might want to run MedRec outside the WebLogic Server installation directories if: You are not the user who installed WebLogic Server. You want to keep a clean set of MedRec files in the installed location so other users can copy them for their private use. The standard mechanism for creating a private copy of MedRec is the Configuration Wizard, config.sh. BEA documentation describes how to run the Wizard in Console mode. Another way to run a private copy of MedRec is to copy existing sample files and change values in them. 1. Create your own directory to run MedRec. For example: ksh [146] MYMEDREC=/h/me/mymedrec 10-5

90 Sample Application Running MedRec in Another Location 2. Copy the medrec_sqlmx or medrec_sqlmx2 directory from the installed WebLogic Server samples to the directory you just created. For example: ksh [148] export WL_HOME=/usr/bea/weblogic81 ksh [150] cp -rp $WL_HOME/samples/domains/medrec_sqlmx/* $MYMEDREC 3. Remove files that might be left over after MedRec was run in the installed WebLogic Server location. These files might interfere with the operation of your private copy of MedRec. The cleanmedrec_sqlmx.sh script is supplied to do this. For example: ksh [153] cd $MYMEDREC ksh [154]./cleanMedRec_sqlmx.sh 4. Set and export shell variables with values for your private copy of MedRec and run the altermedrec_sqlmx.sh script, which changes files to use these values. For example: ksh [156] export NEW_PORT=20011 ksh [157] export NEW_SPORT=20012 ksh [158] export NEW_XARES=medrec-2 ksh [160]$./alterMedRec_sqlmx.sh * db/* NEW_PORT=20011 NEW_SPORT=20012 NEW_XARES=medrec-2 Old string = 7001 New string = Changing config.xml Changing startmedrecserver_sqlmx.sh Old string = 7002 New string = Changing config.xml Old string = TMF_RM=medrec$ New string = TMF_RM=medrec-2 Changing db/create_medrecdb.sh 5. Run MedRec with the same commands used earlier (see Running MedRec Application in the Installed WebLogic Server Location). Values that should be unique are reported so you can check your changes. ksh [165] cd $MYMEDREC ksh [166]../startMedRecServer_sqlmx.sh 6. Control returns to the shell at this point. If the values reported in Step 5 are not those you want, you should edit config.xml, startmedrecserver_sqlmx.sh or create_medrecdb.sh before MedRec starts. For example, you may want to change the subvolume used for NonStop SQL/MP tables. 7. Run the commands shown in the output of Step 5, to start MedRec as shown earlier: db/create_medrecdb.sh -m $PWD....../startMedRecServer_sqlmx.sh If you change values as shown in Step 6, the output in this step shows the user s new value. 10-6

91 Sample Application Running MedRec in Another Location Additional documentation for using MedRec with BEA WebLogic Server 8.1 SP3, including procedures for stopping the application, is available at

92 Sample Application Running MedRec in Another Location 10-8

93 11 Deploying Applications Built in WebLogic Workshop Install WebLogic Server 8.1 SP3 on Your Workstationl Create a Domain to Run the Application Map the NonStop Server Set the Application Properties Verify Your Setup Install WebLogic Server 8.1 SP3 on Your Workstation Download WebLogic Server 8.1 SP3 from Create a Domain to Run the Application Create a Workshop domain on your NonStop system using the Configuration Wizard tool and start the domain. This may not be necessary if you already have a working domain. Map the NonStop Server When you map the share name for the network drive, be sure that the name provides access to: the directory where you created the sample domain 11-1

94 Deploying Applications Built in WebLogic Workshop Set the Application Properties the directory where Java is installed Figure Mapping the NonStop Server Set the Application Properties From the WebLogic Workshop menu, click: File -> New -> Application 11-2

95 Deploying Applications Built in WebLogic Workshop Set the Application Properties The New Application dialog box is displayed. Figure New Application Dialog Box 1. Select the application you want to deploy to the NonStop server. 2. Supply values for the Directory, Name, and Server fields as follows: Directory: Fill in using the drive you mapped to the NonStop system Name: The name of your application Server: Fill in using the drive you mapped to the NonStop system. This is the directory of your config.xml file. 3. Click Create. 4. From the menu, click Tools -> WebLogic Server -> Server Properties -> Build 11-3

96 Deploying Applications Built in WebLogic Workshop Set the Application Properties The build properties for the application are now set, Figure Application Properties 11-4

97 Deploying Applications Built in WebLogic Workshop Verify Your Setup 5. Change the JDK Home and the WebLogic Home to the drive you mapped to the NonStop system (in Tools -> Application Properties). In the following examples, the NonStop server is mapped to drive Y: Figure Application Properties with Corrected Values 6. Click OK to complete the setup. Verify Your Setup 1. If your WebLogic Server is running, the indicator visible in the status bar at the bottom of the WebLogic Workshop visual development is green. If the indicator is not green, verify that you specified all parameters correctly on the WebLogic Server popup (found from Tools -> WebLogic Server). 11-5

HP NonStop Server Guide for BEA WebLogic Server 9.2

HP NonStop Server Guide for BEA WebLogic Server 9.2 HP NonStop Server Guide for BEA WebLogic Server 9.2 Abstract This manual describes the installation, configuration, and management of the BEA WebLogic Server on HP Integrity NonStop NS-series servers.

More information

Native Inspect Manual

Native Inspect Manual Native Inspect Manual Abstract This manual describes how to use the symbolic command-line debugger Native Inspect for debugging TNS/E native processes and snapshot files on HP NonStop Series TNS/E systems.

More information

HPE NonStop Remote Server Call (RSC/MP) Messages Manual

HPE NonStop Remote Server Call (RSC/MP) Messages Manual HPE NonStop Remote Server Call (RSC/MP) Messages Manual Abstract This manual provides a listing and description of RSC/MP messages that are reported on the HPE NonStop host and on RSC/MP workstations.

More information

Mid-Range Library Media Manager Installation and User s Guide

Mid-Range Library Media Manager Installation and User s Guide Mid-Range Library Media Manager Installation and User s Guide Abstract This guide describes how to install and use the Mid-Range Library Media Manager software. It includes information about connection

More information

BEAWebLogic Server. Node Manager Administrator s Guide

BEAWebLogic Server. Node Manager Administrator s Guide BEAWebLogic Server Node Manager Administrator s Guide Version 10.0 Revised: March 30, 2007 Contents 1. Introduction and Roadmap Document Scope and Audience.............................................

More information

Library Media Manager Installation and User s Guide

Library Media Manager Installation and User s Guide Library Media Manager Installation and User s Guide Abstract This guide describes how to install and use the Library Media Manager software. It includes information about connection with an HP Integrity

More information

HP NonStop MXDM User Guide for SQL/MX Release 3.2

HP NonStop MXDM User Guide for SQL/MX Release 3.2 HP NonStop MXDM User Guide for SQL/MX Release 3.2 HP Part Number: 691119-001 Published: August 2012 Edition: J06.14 and subsequent J-series RVUs; H06.25 and subsequent H-series RVUs Copyright 2012 Hewlett-Packard

More information

Chapter 2 WEBLOGIC SERVER DOMAINS. SYS-ED/ Computer Education Techniques, Inc.

Chapter 2 WEBLOGIC SERVER DOMAINS. SYS-ED/ Computer Education Techniques, Inc. Chapter 2 WEBLOGIC SERVER DOMAINS SYS-ED/ Computer Education Techniques, Inc. Objectives You will learn: Domain - concept and implementation. Content of a domain. Common domain types. Production versus

More information

BEA WebLogic. Server. MedRec Clustering Tutorial

BEA WebLogic. Server. MedRec Clustering Tutorial BEA WebLogic Server MedRec Clustering Tutorial Release 8.1 Document Date: February 2003 Revised: July 18, 2003 Copyright Copyright 2003 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This

More information

BEA WebLogic. Server. Creating and Configuring WebLogic Server Domains

BEA WebLogic. Server. Creating and Configuring WebLogic Server Domains BEA WebLogic Server Creating and Configuring WebLogic Server Domains Release 7.0 Revised: September 4, 2002 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This

More information

DSM/SCM Messages Manual

DSM/SCM Messages Manual DSM/SCM Messages Manual Abstract This manual provides cause, effect, and recovery information for messages and errors that you might encounter while using the Distributed Systems Management/Software Configuration

More information

Oracle WebLogic Server

Oracle WebLogic Server Oracle WebLogic Server Node Manager Administrator s Guide 10g Release 3 (10.3) August 2008 Oracle WebLogic Server Node Manager Administrator s Guide, 10g Release 3 (10.3) Copyright 2007, 2008, Oracle and/or

More information

BEAWebLogic. Platform. 8.1 Supported Configurations: HP NonStop Server on MIPS

BEAWebLogic. Platform. 8.1 Supported Configurations: HP NonStop Server on MIPS BEAWebLogic Platform 8.1 Supported Configurations: HP NonStop Server on MIPS Version 8.1 Document Revised: December 10, 2004 Copyright Copyright 2005 BEA Systems, Inc. All Rights Reserved. Restricted Rights

More information

Data Management in Application Servers. Dean Jacobs BEA Systems

Data Management in Application Servers. Dean Jacobs BEA Systems Data Management in Application Servers Dean Jacobs BEA Systems Outline Clustered Application Servers Adding Web Services Java 2 Enterprise Edition (J2EE) The Application Server platform for Java Java Servlets

More information

Oracle Fusion Middleware

Oracle Fusion Middleware Oracle Fusion Middleware Creating Domains Using the Configuration Wizard 11g Release 1 (10.3.4) E14140-04 January 2011 This document describes how to use the Configuration Wizard to create, update, and

More information

Node Manager Administrator's Guide for Oracle WebLogic Server g Release 1 (10.3.6)

Node Manager Administrator's Guide for Oracle WebLogic Server g Release 1 (10.3.6) [1]Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server 10.3.6 11g Release 1 (10.3.6) E13740-08 December 2016 This document describes how to configure and use Node Manager

More information

Measure User s Guide Abstract Product Version Supported Release Version Updates (RVUs) Part Number Published

Measure User s Guide Abstract Product Version Supported Release Version Updates (RVUs) Part Number Published Measure User s Guide Abstract This manual describes how to use the Measure performance monitor to collect and examine data, through either a command interface or programmatic interface. This manual is

More information

Contents at a Glance. vii

Contents at a Glance. vii Contents at a Glance 1 Installing WebLogic Server and Using the Management Tools... 1 2 Administering WebLogic Server Instances... 47 3 Creating and Configuring WebLogic Server Domains... 101 4 Configuring

More information

NonStop Server for Java Message Service User s Manual

NonStop Server for Java Message Service User s Manual NonStop Server for Java Message Service User s Manual Abstract NonStop Server for Java Message Service (NSJMS) is an implementation of Sun Microsystems Java Message Service (JMS) API on HP NonStop S-series

More information

Interception, Replication, and Consolidation Solutions

Interception, Replication, and Consolidation Solutions Interception, Replication, and Consolidation Solutions OPTA2000 clock & time-zone simulator FileSync replication & synchronization software TMF-Audit Toolkit easily converts non-audited TMF files to audited

More information

BEAWebLogic Server and WebLogic Express. Programming WebLogic JNDI

BEAWebLogic Server and WebLogic Express. Programming WebLogic JNDI BEAWebLogic Server and WebLogic Express Programming WebLogic JNDI Version 10.0 Document Revised: March 30, 2007 Contents 1. Introduction and Roadmap Document Scope and Audience.............................................

More information

What every DBA needs to know about JDBC connection pools Bridging the language barrier between DBA and Middleware Administrators

What every DBA needs to know about JDBC connection pools Bridging the language barrier between DBA and Middleware Administrators Presented at What every DBA needs to know about JDBC connection pools Bridging the language barrier between DBA and Middleware Administrators Jacco H. Landlust Platform Architect Director Oracle Consulting

More information

BEA WebLogic Server. Using WebLogic Server Clusters

BEA WebLogic Server. Using WebLogic Server Clusters BEA WebLogic Server Using WebLogic Server Clusters BEA WebLogic Server Version 6.1 Document Date: October 20, 2003 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend

More information

Native Inspect Manual

Native Inspect Manual Native Inspect Manual Part Number: 528122-015R Published: November 2015 Edition: H06.23 and subsequent H-series RVUs, J06.12 and subsequent J-series RVUs, and L15.02 and subsequent L-series RVUs Copyright

More information

CROSSREF Manual. Tools and Utilities Library

CROSSREF Manual. Tools and Utilities Library Tools and Utilities Library CROSSREF Manual Abstract This manual describes the CROSSREF cross-referencing utility, including how to use it with C, COBOL 74, COBOL85, EXTENDED BASIC, FORTRAN, Pascal, SCREEN

More information

ATM Configuration and Management Manual

ATM Configuration and Management Manual ATM Configuration and Management Manual Abstract This manual describes how to configure, operate, and manage the ATM subsystem on an HP NonStop S-series server. The manual includes descriptions of the

More information

BEA Liquid Data for. WebLogic. Deploying Liquid Data

BEA Liquid Data for. WebLogic. Deploying Liquid Data BEA Liquid Data for WebLogic Deploying Liquid Data Release: 1.0.1 Document Date: October 2002 Revised: December 2002 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend

More information

Virtual Hometerm Subsystem (VHS) Manual

Virtual Hometerm Subsystem (VHS) Manual Virtual Hometerm Subsystem (VHS) Manual Abstract This manual describes the Compaq NonStop Virtual Hometerm Subsystem (VHS). VHS acts as a virtual home terminal for applications by emulating a 6530 terminal.

More information

This document is intended for users of UniBasic. Copyright 1998 Dynamic Concepts, Inc. (DCI). All rights reserved.

This document is intended for users of UniBasic. Copyright 1998 Dynamic Concepts, Inc. (DCI). All rights reserved. Dynamic Concepts Incorporated (DCI) has prepared this document for use by DCI personnel, licensees, and authorized representatives. The material contained herein shall not be reproduced in whole or in

More information

Oracle WebLogic Server 11g: Administration Essentials

Oracle WebLogic Server 11g: Administration Essentials Oracle University Contact Us: +33 (0) 1 57 60 20 81 Oracle WebLogic Server 11g: Administration Essentials Duration: 5 Days What you will learn This Oracle WebLogic Server 11g: Administration Essentials

More information

BEAWebLogic Server. Introduction to BEA WebLogic Server and BEA WebLogic Express

BEAWebLogic Server. Introduction to BEA WebLogic Server and BEA WebLogic Express BEAWebLogic Server Introduction to BEA WebLogic Server and BEA WebLogic Express Version 10.0 Revised: March, 2007 Contents 1. Introduction to BEA WebLogic Server and BEA WebLogic Express The WebLogic

More information

Event Management Programming Guide and Reference

Event Management Programming Guide and Reference RS/6000 Cluster Technology Event Management Programming Guide and Reference SA22-7354-01 RS/6000 Cluster Technology Event Management Programming Guide and Reference SA22-7354-01 Note! Before using this

More information

BEAWebLogic. Server. Automatic and Manual Service-level Migration

BEAWebLogic. Server. Automatic and Manual Service-level Migration BEAWebLogic Server Automatic and Manual Service-level Migration Version 10.3 Technical Preview Revised: March 2007 Service-Level Migration New in WebLogic Server 10.3: Automatic Migration of Messaging/JMS-Related

More information

Bipul Sinha, Amit Ganesh, Lilian Hobbs, Oracle Corp. Dingbo Zhou, Basavaraj Hubli, Manohar Malayanur, Fannie Mae

Bipul Sinha, Amit Ganesh, Lilian Hobbs, Oracle Corp. Dingbo Zhou, Basavaraj Hubli, Manohar Malayanur, Fannie Mae ONE MILLION FINANCIAL TRANSACTIONS PER HOUR USING ORACLE DATABASE 10G AND XA Bipul Sinha, Amit Ganesh, Lilian Hobbs, Oracle Corp. Dingbo Zhou, Basavaraj Hubli, Manohar Malayanur, Fannie Mae INTRODUCTION

More information

BEA WebLogic. Server. Securing WebLogic Resources

BEA WebLogic. Server. Securing WebLogic Resources BEA WebLogic Server Securing WebLogic Resources Release 7.0 Document Revised: July 18, 2003 Copyright Copyright 2003 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software and documentation

More information

In today s global business environment, companies must maintain

In today s global business environment, companies must maintain HP NonStop Business Continuity Product Suite: An Introduction Protecting Your Data, Your Applications, and Your Business Ajaya Gummadi >> Product Manager >> HP NonStop Worldwide In today s global business

More information

Oracle WebLogic Server

Oracle WebLogic Server Oracle WebLogic Server Creating WebLogic Domains Using the Configuration Wizard 10g Release 3 (10.1.3) August 2008 Oracle WebLogic Server Creating WebLogic Domains Using the Configuration Wizard, 10g Release

More information

Configuring and Managing Embedded Event Manager Policies

Configuring and Managing Embedded Event Manager Policies Configuring and Managing Embedded Event Manager Policies The Cisco IOS XR Software Embedded Event Manager (EEM) functions as the central clearing house for the events detected by any portion of the Cisco

More information

Oracle WebLogic Server 12c: Administration I

Oracle WebLogic Server 12c: Administration I Oracle WebLogic Server 12c: Administration I Student Guide Volume 1 D80149GC10 Edition 1.0 July 2013 D82757 Authors Bill Bell Elio Bonazzi TJ Palazzolo Steve Friedberg Technical Contributors and Reviewers

More information

ExpressCluster X SingleServerSafe 3.2 for Windows. Configuration Guide. 2/19/2014 1st Edition

ExpressCluster X SingleServerSafe 3.2 for Windows. Configuration Guide. 2/19/2014 1st Edition ExpressCluster X SingleServerSafe 3.2 for Windows Configuration Guide 2/19/2014 1st Edition Revision History Edition Revised Date Description First 2/19/2014 New manual Copyright NEC Corporation 2014.

More information

NonStop Development Environment for Eclipse 4.0 Debugging Supplement

NonStop Development Environment for Eclipse 4.0 Debugging Supplement NonStop Development Environment for Eclipse 4.0 Debugging Supplement HP Part Number: 732675-001 Published: October 2013 Edition: NSDEE 4.0, J06.03 and subsequent J-series RVUs, H06.08 and subsequent H-series

More information

<Insert Picture Here> WebLogic JMS Messaging Infrastructure WebLogic Server 11gR1 Labs

<Insert Picture Here> WebLogic JMS Messaging Infrastructure WebLogic Server 11gR1 Labs WebLogic JMS Messaging Infrastructure WebLogic Server 11gR1 Labs Messaging Basics Built-in Best-of-Breed Messaging (JMS) Engine Years of hardening. Strong performance.

More information

Enform Plus Reference Manual

Enform Plus Reference Manual Enform Plus Reference Manual Abstract This manual provides detailed information about the syntax of the Enform Plus language. Product Version Enform Plus D46 Supported Releases This manual supports D46.00

More information

IBM Tivoli Monitoring for Databases: DB2. User s Guide. Version SC

IBM Tivoli Monitoring for Databases: DB2. User s Guide. Version SC IBM Tivoli Monitoring for Databases: DB2 User s Guide Version 5.1.0 SC23-4726-00 IBM Tivoli Monitoring for Databases: DB2 User s Guide Version 5.1.0 SC23-4726-00 Note Before using this information and

More information

BEA WebLogic. Integration. Best Practices in Designing BPM Workflows

BEA WebLogic. Integration. Best Practices in Designing BPM Workflows BEA WebLogic Integration Best Practices in Designing BPM Workflows Release 7.0 Document Date: June 2002 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software

More information

Interception, Replication, Security & Consolidation Solutions

Interception, Replication, Security & Consolidation Solutions Interception, Replication, Security & Consolidation Solutions SDI for Sensitive Data Intercept protects sensitive data-at-rest. Interception, encryption, and tokenization FileSync synchronizes Guardian

More information

IBM Tivoli Storage Manager for AIX Version Installation Guide IBM

IBM Tivoli Storage Manager for AIX Version Installation Guide IBM IBM Tivoli Storage Manager for AIX Version 7.1.3 Installation Guide IBM IBM Tivoli Storage Manager for AIX Version 7.1.3 Installation Guide IBM Note: Before you use this information and the product it

More information

Sun Java System Application Server 8.1: Administration & Deployment

Sun Java System Application Server 8.1: Administration & Deployment Sun Java System Application Server 8.1: Administration & Deployment Student Guide - Volume I IAS-4444 Rev A D62040GC10 Edition 1.0 D63846 Copyright 2006, 2009, Oracle and/or its affiliates. All rights

More information

IBM DB2 Query Patroller. Administration Guide. Version 7 SC

IBM DB2 Query Patroller. Administration Guide. Version 7 SC IBM DB2 Query Patroller Administration Guide Version 7 SC09-2958-00 IBM DB2 Query Patroller Administration Guide Version 7 SC09-2958-00 Before using this information and the product it supports, be sure

More information

HP NonStop SQL/MX Release 3.2 Installation and Upgrade Guide

HP NonStop SQL/MX Release 3.2 Installation and Upgrade Guide HP NonStop SQL/MX Release 3.2 Installation and Upgrade Guide HP Part Number: 691118-003 Published: May 2013 Edition: J06.14 and subsequent J-series RVUs; H06.25 and subsequent H-series RVUs Copyright 2013

More information

BEA WebLogic. Platform. Configuration Wizard Template Reference

BEA WebLogic. Platform. Configuration Wizard Template Reference BEA WebLogic Platform Configuration Wizard Template Reference Release 7.0 Document Date: June 2002 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software

More information

TNS/R Native Application Migration Guide

TNS/R Native Application Migration Guide TNS/R Native Application Migration Guide Abstract This manual introduces the HP NonStop Series/RISC (TNS/R) native development and execution environments and explains how to migrate existing HP NonStop

More information

BEAWebLogic. Server. Programming WebLogic Management Services with JMX

BEAWebLogic. Server. Programming WebLogic Management Services with JMX BEAWebLogic Server Programming WebLogic Management Services with JMX Release 8.1 Revised: October 8, 2004 Copyright Copyright 2003 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This

More information

Telserv Manual Abstract Product Versions Supported Release Version Updates (RVUs) Part Number Published

Telserv Manual Abstract Product Versions Supported Release Version Updates (RVUs) Part Number Published Telserv Manual Abstract This manual describes the HP NonStop Telserv subsystem. Part I contains a product overview. Part II contains operational and configuration information for system administrators,

More information

IBM MQ Update BITUG BigSIG Gerry Reilly Development Director and CTO IBM Messaging and IoT Foundation IBM Hursley Lab, UK

IBM MQ Update BITUG BigSIG Gerry Reilly Development Director and CTO IBM Messaging and IoT Foundation IBM Hursley Lab, UK IBM MQ Update BITUG BigSIG 2014 Gerry Reilly Development Director and CTO IBM Messaging and IoT Foundation IBM Hursley Lab, UK Please Note IBM s statements regarding its plans, directions, and intent are

More information

Oracle Fusion Middleware

Oracle Fusion Middleware Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server 11g Release 1 (10.3.4) E13738-04 January 2011 This document is a resource for system administrators who configure, manage,

More information

FileSync Replicates and Synchronizes Applications and Files between HPE Nonstop Servers. tandsoft.com TANDsoft Corporation

FileSync Replicates and Synchronizes Applications and Files between HPE Nonstop Servers. tandsoft.com TANDsoft Corporation FileSync Replicates and Synchronizes Applications and Files between HPE Nonstop Servers Jack.DiGiacomo @ tandsoft.com TANDsoft Corporation 1 Presentation Agenda Introduction TANDsoft products FileSync

More information

Oracle Fusion Middleware

Oracle Fusion Middleware Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server 11g Release 1 (10.3.1) E13738-01 May 2009 This document is a resource for system administrators who configure, manage, and

More information

Attunity Connect and BEA WebLogic (Version 8.1)

Attunity Connect and BEA WebLogic (Version 8.1) Attunity Connect and BEA WebLogic (Version 8.1) Attunity Connect and BEA WebLogic (Version 8.1) 2006 by Attunity Ltd. Due to a policy of continuous development, Attunity Ltd. reserves the right to alter,

More information

Installing on WebLogic Server

Installing on WebLogic Server 155 Chapter 11 Installing on WebLogic Server This chapter provides instructions for performing a new installation of TIBCO Collaborative Information Manager on WebLogic Application Server in a non-clustered

More information

Contents. 1 Introduction... 2 Introduction to Installing and Configuring LEI... 4 Upgrading NotesPump to LEI...

Contents. 1 Introduction... 2 Introduction to Installing and Configuring LEI... 4 Upgrading NotesPump to LEI... Contents 1 Introduction... Organization of this Manual... Related Documentation... LEI and DECS Documentation... Other Documentation... Getting Started with Lotus Enterprise Integrator... 2 Introduction

More information

Administering Clusters for Oracle WebLogic Server 12c (12.1.2)

Administering Clusters for Oracle WebLogic Server 12c (12.1.2) [1]Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.1.2) E28074-07 February 2015 This document describes clusters and provides information for planning, implementing,

More information

HP NonStop TCP/IPv6 Configuration and Management Manual

HP NonStop TCP/IPv6 Configuration and Management Manual HP NonStop TCP/IPv6 Configuration and Management Manual Abstract This manual describes how to configure and manage the HP NonStop TCP/IPv6 subsystem on HP NonStop S-series servers and HP Integrity NonStop

More information

1Z Oracle WebLogic Server 12c - Administration I Exam Summary Syllabus Questions

1Z Oracle WebLogic Server 12c - Administration I Exam Summary Syllabus Questions 1Z0-133 Oracle WebLogic Server 12c - Administration I Exam Summary Syllabus Questions Table of Contents Introduction to 1Z0-133 Exam on Oracle WebLogic Server 12c - Administration I... 2 Oracle 1Z0-133

More information

Installing and Administering a Satellite Environment

Installing and Administering a Satellite Environment IBM DB2 Universal Database Installing and Administering a Satellite Environment Version 8 GC09-4823-00 IBM DB2 Universal Database Installing and Administering a Satellite Environment Version 8 GC09-4823-00

More information

ViewSys User s Guide Abstract Product Version Supported Release Version Updates (RVUs) Part Number Published

ViewSys User s Guide Abstract Product Version Supported Release Version Updates (RVUs) Part Number Published ViewSys User s Guide Abstract ViewSys provides system managers and system operators the ability to view system resources on HP NonStop servers. This manual describes how the ViewSys program operates and

More information

Configuring the Oracle Network Environment. Copyright 2009, Oracle. All rights reserved.

Configuring the Oracle Network Environment. Copyright 2009, Oracle. All rights reserved. Configuring the Oracle Network Environment Objectives After completing this lesson, you should be able to: Use Enterprise Manager to: Create additional listeners Create Oracle Net Service aliases Configure

More information

VI. Corente Services Client

VI. Corente Services Client VI. Corente Services Client Corente Release 9.1 Manual 9.1.1 Copyright 2014, Oracle and/or its affiliates. All rights reserved. Table of Contents Preface... 5 I. Introduction... 6 II. Corente Client Configuration...

More information

Oracle 1Z Oracle Weblogic Server 11g- System(R) Administration I.

Oracle 1Z Oracle Weblogic Server 11g- System(R) Administration I. Oracle 1Z0-102 Oracle Weblogic Server 11g- System(R) Administration I http://killexams.com/exam-detail/1z0-102 QUESTION: 105 Which three techniques can create a new WebLogic domain? A. Configuration Wizard

More information

IBM Tivoli Storage Manager for HP-UX Version Installation Guide IBM

IBM Tivoli Storage Manager for HP-UX Version Installation Guide IBM IBM Tivoli Storage Manager for HP-UX Version 7.1.4 Installation Guide IBM IBM Tivoli Storage Manager for HP-UX Version 7.1.4 Installation Guide IBM Note: Before you use this information and the product

More information

HPE Code Coverage Tool Reference Manual for HPE Integrity NonStop NS-Series Servers

HPE Code Coverage Tool Reference Manual for HPE Integrity NonStop NS-Series Servers HPE Code Coverage Tool Reference Manual for HPE Integrity NonStop NS-Series Servers Abstract This manual describes the HPE Code Coverage Tool for HPE Integrity NonStop NS-Series Servers. It addresses application

More information

Creating WebLogic Domains Using the Configuration Wizard 12c (12.1.3)

Creating WebLogic Domains Using the Configuration Wizard 12c (12.1.3) [1]Oracle Fusion Middleware Creating WebLogic 12.1.3 Domains Using the Configuration Wizard 12c (12.1.3) E41890-02 August 2015 This document describes how to use the Configuration Wizard to create, update,

More information

Oracle Fusion Middleware

Oracle Fusion Middleware Oracle Fusion Middleware Deployment Guide for Oracle Service Bus 11g Release 1 (11.1.1.5.0) E15022-03 April 2011 Oracle Fusion Middleware Deployment Guide for Oracle Service Bus, 11g Release 1 (11.1.1.5.0)

More information

Oracle WebLogic Server

Oracle WebLogic Server Oracle WebLogic Server Configuring Log Files and Filtering Log Messages 10g Release 3 (10.3) July 2008 Oracle WebLogic Server Configuring Log Files and Filtering Log Messages, 10g Release 3 (10.3) Copyright

More information

DataLoader/MX Reference Manual

DataLoader/MX Reference Manual DataLoader/MX Reference Manual Abstract This manual describes the features and functionality of the DataLoader/MX product, a tool to load HP NonStop SQL/MX, SQL/MP, and Enscribe databases. Product Version

More information

Oracle WebLogic Server

Oracle WebLogic Server Oracle WebLogic Server Using Clusters 10g Release 3 (10.3) July 2008 Oracle WebLogic Server Using Clusters, 10g Release 3 (10.3) Copyright 2007, 2008, Oracle and/or its affiliates. All rights reserved.

More information

Programming JNDI for Oracle WebLogic Server 11g Release 1 (10.3.6)

Programming JNDI for Oracle WebLogic Server 11g Release 1 (10.3.6) [1]Oracle Fusion Middleware Programming JNDI for Oracle WebLogic Server 11g Release 1 (10.3.6) E13730-06 April 2015 This document describes the WebLogic Scripting Tool (WLST). It explains how you use the

More information

DLL Programmer s Guide for TNS/E Systems

DLL Programmer s Guide for TNS/E Systems DLL Programmer s Guide for TNS/E Systems Abstract This guide describes how application programmers can use the DLL facilities provided on TNS/E systems and recommends good practices in using them. Product

More information

Spooler Plus Programmer s Guide

Spooler Plus Programmer s Guide Spooler Plus Programmer s Guide Abstract This manual describes the Spooler Plus subsystem, its uses, and its applications. This guide is intended for application programmers who want to use the Spooler

More information

HP NonStop Pathway/iTS Web Client Programming Manual

HP NonStop Pathway/iTS Web Client Programming Manual HP NonStop Pathway/iTS Web Client Programming Manual Abstract This manual describes how to convert SCREEN COBOL requesters to web clients and explains how to build and deploy those clients. It also provides

More information

IBM Tivoli Federated Identity Manager Version Installation Guide GC

IBM Tivoli Federated Identity Manager Version Installation Guide GC IBM Tivoli Federated Identity Manager Version 6.2.2 Installation Guide GC27-2718-01 IBM Tivoli Federated Identity Manager Version 6.2.2 Installation Guide GC27-2718-01 Note Before using this information

More information

BEAWebLogic Server. Using the WebLogic Diagnostic Framework Console Extension

BEAWebLogic Server. Using the WebLogic Diagnostic Framework Console Extension BEAWebLogic Server Using the WebLogic Diagnostic Framework Console Extension Version 10.0 Revised: March 30, 2007 Contents 1. Introduction and Roadmap What Is the WebLogic Diagnostic Framework Console

More information

SOA Cloud Service Automatic Service Migration

SOA Cloud Service Automatic Service Migration SOA Cloud Service Automatic Service Migration SOACS 12.2.1.2 O R A C L E W H I T E P A P E R A U G U S T 2 0 1 8 Table of Contents Introduction 1 Configuring Automatic Service Migration for a 12.2.1.2

More information

BEAWebLogic. Server. Configuring and Managing WebLogic JDBC

BEAWebLogic. Server. Configuring and Managing WebLogic JDBC BEAWebLogic Server Configuring and Managing WebLogic JDBC Version 9.0 Revised: October 14, 2005 Copyright Copyright 2005 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software and

More information

HP NonStop SQL/MX 2.3.x to SQL/MX 3.0 Database and Application Migration Guide

HP NonStop SQL/MX 2.3.x to SQL/MX 3.0 Database and Application Migration Guide HP NonStop SQL/MX 2.3.x to SQL/MX 3.0 Database and Application Migration Guide Abstract This manual explains how to migrate databases and applications from HP NonStop SQL/MX 2.3.x to SQL/MX Release 3.0

More information

EXPRESSCLUSTER X SingleServerSafe 4.0 for Windows. Configuration Guide. April 17, st Edition

EXPRESSCLUSTER X SingleServerSafe 4.0 for Windows. Configuration Guide. April 17, st Edition EXPRESSCLUSTER X SingleServerSafe 4.0 for Windows Configuration Guide April 17, 2018 1st Edition Revision History Edition Revised Date Description 1st Apr 17, 2018 New manual Copyright NEC Corporation

More information

Adapter for Mainframe

Adapter for Mainframe BEA WebLogic Java Adapter for Mainframe Introduction Release 5.1 Document Date: August 2002 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software and documentation

More information

High Availability Options

High Availability Options , on page 1 Load Balancing, on page 2 Distributed VPN Clustering, Load balancing and Failover are high-availability features that function differently and have different requirements. In some circumstances

More information

Oracle Fusion Middleware

Oracle Fusion Middleware Oracle Fusion Middleware Upgrade Guide for Oracle WebLogic Server 12c Release 1 (12.1.1) E24497-02 January 2012 This document describes the procedures to upgrade an application environment to Oracle WebLogic

More information

Managing Oracle Real Application Clusters. An Oracle White Paper January 2002

Managing Oracle Real Application Clusters. An Oracle White Paper January 2002 Managing Oracle Real Application Clusters An Oracle White Paper January 2002 Managing Oracle Real Application Clusters Overview...3 Installation and Configuration...3 Oracle Software Installation on a

More information

BEA WebLogic Server. and BEA WebLogic Express. Introduction to BEA WebLogic Server 6.1

BEA WebLogic Server. and BEA WebLogic Express. Introduction to BEA WebLogic Server 6.1 BEA WebLogic Server and BEA WebLogic Express Introduction to BEA WebLogic Server 6.1 BEA WebLogic Server Version 6.1 Document Date: June 24, 2002 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved.

More information

Using Clusters for Oracle WebLogic Server g Release 1 (10.3.6)

Using Clusters for Oracle WebLogic Server g Release 1 (10.3.6) [1]Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server 10.3.6 11g Release 1 (10.3.6) E13709-11 July 2015 This document describes clusters in WebLogic Server 10.3.6 and provides information

More information

IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server. User s Guide. Version SC

IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server. User s Guide. Version SC IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server User s Guide Version 5.1.1 SC23-4705-01 IBM Tivoli Monitoring for Web Infrastructure: WebSphere Application Server User s Guide

More information

HP NonStop TCP/IPv6 Migration Guide

HP NonStop TCP/IPv6 Migration Guide HP NonStop TCP/IPv6 Migration Guide Abstract Version This manual discusses the differences between HP NonStop TCP/IP and NonStop TCP/IPv6 and the differences between Parallel Library TCP/IP and NonStop

More information

Teamcenter Installation on Windows Clients Guide. Publication Number PLM00012 J

Teamcenter Installation on Windows Clients Guide. Publication Number PLM00012 J Teamcenter 10.1 Installation on Windows Clients Guide Publication Number PLM00012 J Proprietary and restricted rights notice This software and related documentation are proprietary to Siemens Product Lifecycle

More information

Oracle Fusion Middleware

Oracle Fusion Middleware Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server 11g Release 1 (10.3.1) E13702-01 May 2009 This document describes deploying Java EE applications or application modules to WebLogic

More information

1 Introduction to Oracle WebLogic Server

1 Introduction to Oracle WebLogic Server Oracle Fusion Middleware Introduction to Oracle WebLogic Server 11g Release 1 (10.3.1) E13752-01 May 2009 This document provides an overview of Oracle WebLogic Server features and describes how you can

More information

Client Installation and User's Guide

Client Installation and User's Guide IBM Tivoli Storage Manager FastBack for Workstations Version 7.1.1 Client Installation and User's Guide SC27-2809-04 IBM Tivoli Storage Manager FastBack for Workstations Version 7.1.1 Client Installation

More information

OneVision DEFINITY G3 Fault Management Installation and Integration for AT&T OneVision

OneVision DEFINITY G3 Fault Management Installation and Integration for AT&T OneVision 585-229-109 Issue 1 October, 1995 Table of Contents OneVision DEFINITY G3 Fault Management Installation and Integration for AT&T OneVision Graphics AT&T 1988 Contents About This Book vii Intended Audiences

More information

Adapter for ClarifyCRM

Adapter for ClarifyCRM BEA WebLogic Adapter for ClarifyCRM User Guide Release 7.0 Document Date: January 2003 Copyright Copyright 2002 BEA Systems, Inc. All Rights Reserved. Copyright 2002 iway Software. All Rights Reserved.

More information