Jolt for NonStop(TM) TUXEDO Developer's Guide About This Guide Who Should Read This Guide Organization of This Guide Related Documentation Your Comments Invited 1. Introducing Jolt What is Jolt What is New in Jolt for NonStopTM TUXEDO What Has Changed in Jolt for NonStopTM TUXEDO Repository Enhancements for Jolt 1.
Starting the JSL Shutting Down the JSL Restarting the JSL Configuring the JSL JSL Command-Line Options Security and Encryption Jolt Relay Jolt Relay Failover Jolt Relay Process Jolt Relay Adapter Network Address Configurations Jolt Repository Configuring the Jolt Repository Initializing Services Using NonStopTM TUXEDO and the Repository Editor Event Subscription Configuration NonStopTM TUXEDO Background Information Configuration File The UBBCONFIG File Configuration File Format 4.
Using Service-Level Keywords and Values Using Parameter-Level Keywords and Values Troubleshooting Sample Bulk Load Data 5.
To Export or Unexport Services Reviewing the Exported/Unexported Status Testing a Service Repository Editor Service Test Window Testing a Service Process Flow Troubleshooting 6. Using the Jolt Class Library Class Library Functionality Overview Java Applications vs.
Notification Event Handler Subscribing to Event Notifications Enables Unsolicited Notifications Connection Modes Notification Data Buffers NonStopTM TUXEDO Event Subscription Using the Jolt API to Receive NonStopTM TUXEDO Notifications Clearing Parameter Values Reusing Objects Application Deployment and Localization Deploying a Jolt Applet Client Considerations Web Server Considerations Localizing a Jolt Applet 7.
JoltCheckbox JoltChoice Using the Property List and the Property Editor to Modify the JoltBeans Properties JoltBeans Class Library Walkthrough Building the Sample Form Wiring the JoltBeans Together Running the Sample Application Using the JoltBeans Repository and Setting the Property Values JoltBeans Programming Tasks Using Transactions With JoltBeans Using Custom GUI Elements With the JoltService Bean 8.
Java Servlets Servlet Interest Group 9. Using Jolt 1.2 ASP Connectivity for NonStopTM TUXEDO Key Features ASP Connectivity Enhancements for Jolt 1.2 How the Jolt ASP Connectivity for NonStopTM TUXEDO Works The ASP Connectivity for NonStopTM TUXEDO Toolkit Jolt 1.
3-7. Sample UBBCONFIG File for TMUSREVT 3-8. FIELDTBLS Variable in the TMUSREVT.ENV File 3-9. UBBCONFIG File 4-1. Correct Hierarchical Order in a Data File 4-2. Sample Bulk Load Data 6-1. Jolt Transfer of Funds Example (SimXfer.java) 6-2. Use of the STRING buffer type (ToUpper.java) 6-3. Use of the CARRAY buffer type (tryOnCARRAY.java) 6-4. tryOnFml.java Source Code 6-5. tryOnFml.f16 Field Definitions 6-6. tryOnFml.c Source Code 6-7. simpview.java Source Code 6-8. simpview.v16 Field Definitions 6-9.
5-11. Example of a Moved Service 5-12. Edit Services Window 5-13. Edit Parameters Window 5-14. Export and Unexport Buttons 5-15. Exported/Unexported Status 5-16. Sample Service Test Window 5-17. Test Service Flow 6-1. Jolt Client/Server Relationship 6-2. Jolt Object Relationships 7-1. Possible Interrelationships Among the JoltBeans 7-2. Example of the Property List and Ellipsis Button 7-3. Custom Property Editor Dialog Box 7-4. Sample Inquiry Applet 7-5. JoltBeans and the Form Designer in Visual Café 7-6.
7-28. Custom Property Editor for serviceName 7-29. JoltBeans Repository Log On 7-30. Property Editor with Selected Service 9-1. Jolt ASP Connectivity for NonStopTM TUXEDO Architecture 9-2. tellerForm.asp Example 9-3. transferForm.htm Example 9-4. tlr.asp Results Page List of Tables 1-1. Using the Jolt Class Library 3-1. Command Line Options for JSL 3-2. JRAD CLOPT Parameter Descriptions 3-3. Jolt Internet Relay Network Address Configuration Criteria 3-4. NonStopTM TUXEDO Buffer Types 3-5.
U.S. Government Customers Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. (c) 1999 Compaq Computer Corporation. Compaq, the Compaq logo, Atalla, Deskpro, Enform, Expand, Guardian, Himalaya, Inspect, Integrity, NonStop, NonStop Availability, Presario, ProLiant, ServerNet, SignMaster, SNAX, Tandem, TMF, VLM, and VMS Registered in U.S.
About This Guide The guide describes the Compaq Jolt for Compaq NonStopTM TUXEDO product, discusses how to use the Jolt system, and defines messages and terms associated with using the product. Who Should Read This Guide This guide is intended for system administrators, network administrators, and developers interested in extending secure, scalable transaction-based processing from the enterprise to intranet and Internet-wide availability.
Related Documentation ● NonStopTM TUXEDO Reference, which contains the online descriptions of the commands, utilities, and routines that make up the NonStopTM TUXEDO administrative and programmatic interfaces. ● NonStopTM TUXEDO Administration Guide, which describes how to configure and manage a NonStopTM TUXEDO system. ● NonStopTM TUXEDO Application Programming Guide, which describes how to develop NonStopTM TUXEDO client programs and services.
1. Introducing Jolt The Jolt product is a Java-based interface to the Compaq NonStopTM TUXEDO system that extends NonStopTM TUXEDO services to the Internet. Jolt allows you to build client programs and applets that can remotely invoke existing NonStopTM TUXEDO services allowing application messaging, component management, and distributed transaction processing.
● Jolt Class Library. The Jolt class library is a Java package containing the class files that implement the Jolt API. These classes enable Java applications and applets to invoke NonStopTM TUXEDO services. The Jolt class library includes functionality to set, retrieve, manage and invoke communication attributes, notifications, network connections, transactions, and services. ● JoltBeans. JoltBeans provide a JavaBeans-compliant interface to Jolt for NonStopTM TUXEDO.
keys for each user session. One key is used for encrypting and decrypting messages sent from the client to the server, the other for messages sent from the server to the client. ● JRLY Connection to JRAD. The Jolt Relay (JRLY) in Jolt for NonStopTM TUXEDO allows you to specify a list of IP addresses for JRADs. On startup, the JRLY tries to connect to each JRAD on the list, searching sequentially from the beginning. The first JRAD to respond successfully is used.
NonStopTM TUXEDO does not support the Netscape Enterprise Server (NES). Also, ASP Connectivity for NonStopTM TUXEDO is no longer an add-on; it is part of the Jolt Client Class Library. ● JSE Connectivity for NonStopTM TUXEDO. The name Jolt WAS for Servlets is now JSE Connectivity for NonStopTM TUXEDO. ● JoltBeans. This feature is no longer an add-on; it is part of the Jolt Client Class Library. ● Security/Encryption. Diffie-Hellman (DH) key exchange replaces the DES key exchange mechanism (for U.S.
How Jolt Works Jolt connects Java clients to applications built using the NonStopTM TUXEDO system. The NonStopTM TUXEDO system provides a set of modular services, each offering specific functionality related to the application as a whole. For example, a simple banking application might have services such as INQUIRY, WITHDRAW, TRANSFER, and DEPOSIT. Typically, service requests are implemented in C or COBOL as a sequence of calls to a program library.
● Jolt Server Handler (JSH). Manages network connectivity, executes service requests on behalf of the client, and translates NonStopTM TUXEDO buffer data into the Jolt buffer and vice versa. ● Jolt Repository Server (JREPSVR). Retrieves Jolt service definitions from the Jolt Repository and returns the service definitions to the JSH; also updates or adds Jolt service definitions. Figure 1-2 illustrates the Jolt Server and Jolt Repository components. Figure 1-2.
Table 1-1 summarizes the flow of activity involved in using the Jolt Class Library to access NonStopTM TUXEDO services. Table 1-1. Using the Jolt Class Library Process Step Action Connection 1. Request Reply A Java-enabled Web browser downloads an HTML page using the HTTP protocol. 2. A Jolt applet is downloaded and executed in the Java Virtual Machine on the client. 3. A Java applet opens a separate connection to the Jolt Server using a private protocol. 4.
graphically construct client applications. JoltBeans provide a JavaBeans-compliant interface to Jolt for NonStopTM TUXEDO. A fully functional Jolt client can now be developed without writing any code. You can drag and drop JoltBeans from the component palette of a development tool and position them on the Java form (or forms) of the Jolt client application you are creating.
5. The results are returned to the Jolt Server, which packages the results and any error information into a message that is sent to the Jolt client. 6. The Jolt client maps the contents of the message into the various Jolt client interface objects, completing the request. Jolt Repository The Jolt Repository is a database where NonStopTM TUXEDO services are defined, such as name, number, type, parameter size, and permissions.
Note The Jolt Repository Editor controls services only for Jolt client applications. It cannot be used to make changes to the NonStopTM TUXEDO application. Jolt Internet Relay The Jolt Internet Relay is a component that routes messages from a Jolt client to a JSL or JSH. The Jolt Internet Relay consists of the Jolt Relay (JRLY) and the Jolt Relay Adapter (JRAD). The Jolt Relay is not a NonStopTM TUXEDO client or server.
The following steps summarize how to create and deploy Jolt clients. 1. Begin the process with a NonStopTM TUXEDO system application. 2. Install the Jolt system. For information about installing Jolt components, refer to the readme.txt file on the Jolt CD-ROM. 3. Configure and define services using the Jolt Repository Editor or the Bulk Loader.
the Jolt Class Library: ● Section 6, Using the Jolt Class Library 5. Run the Jolt-based client applet or application. Refer to Section 6, Using the Jolt Class Library, to assist you in installing a Jolt Class Library on a Web Server.
2. Installing Jolt Compaq Jolt for Compaq NonStopTM TUXEDO must be installed in the Open System Services (OSS) environment on a Compaq NonStopTM Kernel system. For information about installing Jolt on OSS, refer to the readme.txt file on the Jolt for NonStopTM TUXEDO CD.
3. Configuring the Jolt System This section explains how to configure Jolt. It contains a "Quick Configuration section for users who are familiar with Jolt. The rest of the section provides more detailed information. Readers of this section are assumed to be system administrators or application developers who have experience with the operating systems and workstation platforms on which they are configuring Jolt.
In the GROUPS section: 1. Specify the same identifiers given as the value of the LMID parameter in the MACHINES section. 2. Specify the value of the GRPNO, between 1 and 30,000. In the SERVERS section: The Jolt Repository Server (JREPSVR) contains services for accessing and editing the Repository. Multiple JREPSVR instances share repository information through a shared file. Include JREPSVR in the SERVERS section of the UBBCONFIG file: 1. Indicate a new server identification with the SRVID parameter. 2.
Note If jolt.jar and admin.jar are in the same directory as RE.html, the web server provides the classes. If they are not in the same directory as RE.html, modify the applet code base. 4. Press Enter. The Repository Editor logon window displays. After starting the Jolt Repository Editor, follow these directions to log on: 1. Type the name of the server machine designated as the access point to the NonStopTM TUXEDO application and select the port number text field. 2. Type the port number and press Enter.
To exit the Repository Editor: 1. Select Back from a previous window to return to the Logon window. 2. Select Close to terminate the connection with the server. The Repository Editor Logon window continues to display with disabled fields. 3. Select Log Off from your browser menu to remove the window from your screen.
LOGDIR= ACCESS_LOG= ERROR_LOG= LISTEN= CONNECT= The format for directory and file names is determined by the operating system.
● Determining server network addresses. ● Determining the number of Jolt clients to be serviced (by MAXWSCLIENTS in UBB). ● Determining the minimum and maximum number of JSHs. Starting the JSL To start all administrative and server processes in the UBBCONFIG file: 1. Type: tmloadcf Parses the configuration file and loads the binary version of the configuration file. 2. Type: tmboot -y Activates the application specified in the configuration file.
[-H external netaddr] The external network address Jolt clients use to connect to the application. The JSL process uses this address to listen for clients attempting to connect at this address. If the address is 0x0002MMMMdddddddd and JSH network address is 0x00021111ffffffff, the known network address is 0x00021111dddd dddd.
format; each # should be a number from 0 to 255. This dotted decimal number represents the IP address of the local machine. In both of the above formats, port_number is the TCP port number at which the domain process listens for incoming requests. port_number can either be a number between 0 and 65535 or a name. If port_number is a name, it must be in the network services database on your local machine. The address can also be specified in hexadecimal format when preceded by the character "0x".
Security and Encryption Authentication and key exchange data are transmitted between Jolt clients and the JSL/JSH using the Diffie-Hellman key exchange. All subsequent exchanges are encrypted using RC4 encryption. International packages use a DES key exchange and a 128-bit key, with 40 bits encrypted and 88 bits exposed. Programs using 128-bit encryption cannot be exported outside the United States without proper approval from the United States government.
processes are executed. Each JRLY (service or process) has its own configuration file. This type of failover is handled by Jolt 1.2 client API changes that allow you to specify a list of Jolt server addresses (JSL or JRLY). ● JRLY to JRAD connection failover Each JRLY configuration file has a list of JRAD addresses. When a JRAD is unavailable, JRLY tries to connect to the next free (unconnected) JRAD, in a round-robin fashion. Two JRLYs cannot connect to the same JRAD.
The format for directory and file names is determined by the operating system. If any of the files specified in LOGDIR, ACCESS_LOG or ERROR_LOG cannot be opened for writing, the JRLY prints an error message on stderr and exits. Here are the formats for host names and port numbers: Host Name/Port Number Descriptions Hostname:Port Hostname is a string, Port is a decimal number. //Hostname:Port Hostname is a string, Port is a decimal number.
JRLY LISTEN: CONNECT: JRAD -l: -c: JSL -n: Jolt Repository The Jolt Repository contains NonStopTM TUXEDO service definitions that allow the Jolt clients to access NonStopTM TUXEDO services.
Note You must install only one writable JREPSVR (that is, only one JREPSVR with the -W flag). Multiple read-only JREPSVRS can be installed on the same host. 3. Type the -P flag to specify the path of the repository file. An error message displays in the NonStopTM TUXEDO ULOG file if the argument for the -P flag is not entered. 4. Add the file pathname of the Repository file (for example, /app/jrepository). 5.
1. Build the NonStopTM TUXEDO server containing the service. See the NonStopTM TUXEDO Administration Guide or NonStopTM TUXEDO Programming Guide for additional information on the following: ● Building the NonStopTM TUXEDO applications/server ● Editing the UBBCONFIG file ● Updating the TUXCONFIG file ● Administering the tmboot command 2. Access the Jolt Repository Editor.
Table 3-4. NonStopTM TUXEDO Buffer Types Buffer Type Description FML Attribute, value pair. Explicit. VIEW C structure. Very precise offsetting. Implicit. STRING Length and offset are different values. All readable. CARRAY Character array. Only client and server know; JSL does not. X_C_TYPE Equivalent to VIEW. X_COMMON Equivalent to VIEW, but used for both COBOL and C. X_OCTET Equivalent to CARRAY. FML Buffer Example Example 3-8 shows a use of the FML buffer.
configuration file or a copy of it in its monitoring activity. tmshutdown references the configuration file for information needed to shut down the application. Configuration File Format The UBBCONFIG file can consist of up to nine specification sections. Lines beginning with an asterisk (*) indicate the beginning of a specification section. Each such line contains the name of the section immediately following the *.
The Jolt Server and /WS use MAXWSCLIENTS in the same way. For example, if 200 slots are configured for MAXWSCLIENTS, this number configures NonStopTM TUXEDO for the total number of remote clients used by Jolt and /WS. If MAXWSCLIENTS is not specified, the default is 0. Note If MAXWSCLIENTS is not set, the JSL does not boot. *GROUPS Section This section provides information about server groups, and must have at least one server group defined in it.
The network address specified for the JSL designates a TCP/IP address for both the JSL and any JSH processes associated with that JSL. The port number identified by the network address specifies the port number on which the JSL accepts new client connections. Each JSH associated with the JSL uses consecutive port numbers at the same TCP/IP address. For example, if the initial JSL port number is 8000 and there are a maximum of three JSH processes, the JSH processes use ports 8001, 8002, and 8003.
Specifies the minimum number of occurrences of the server to booted. If an RQADDR is specified, and MIN is greater than 1, the servers form a Multiple Servers Single Queue (MSSQ) set. The identifiers for the servers are SRVID up to (SRVID + (MAX -1)). All occurrences of the server have the same sequence numbers as well as any other server parameters. The value range for MIN is 0 to 1000. If MIN is not specified, the default value is 1.
RQPERM=number Assigns permissions to the request queue for this server.number can be from 0001 to 0777, inclusive. If no parameter is specified, the permissions value of the bulletin board, as specified by PERM in the RESOURCES section, is used. If no value is specified there, the default of 0666 is used (this exposes your application to possible use by any login on the system, so consider this carefully).
4. Bulk Loading NonStop TUXEDO Services TM This section covers the following topics: ● Introduction to the Bulk Loader ● Using the Bulk Loader ● Syntax of the Bulk Loader Data Files ● Troubleshooting ● Sample Bulk Load Data Introduction to the Bulk Loader As a systems administrator, you may have an existing Compaq NonStopTM TUXEDO application with multiple NonStopTM TUXEDO services. Manually creating these definitions to the repository database may take hours to complete.
-p package Specifies the repository package name; default is BULKPKG. //host:port Specifies the JRLY or JSL address (host name and IP port number). (Mandatory) filename Specifies the file containing the service definitions. (Mandatory) About the Bulk Load File The bulk load file is a text file that defines services and their associated parameters. The bulk loader loads the services defined in the bulk loader file into the repository using the package name, BULKPKG by default.
Keyword Order in the Bulk Loader Data File Keyword order must be maintained within the data files to ensure an error-free transfer during the bulk load. Example 4-1.
inview Any view name for input parameters (optional; only if VIEW or VIEW32 or X_C_TYPE buffer type is used) outview Any view name for output parameters (optional) Using Parameter-Level Keywords and Values A parameter begins with the param= keyword followed by a number of parameter keywords until another param or service keyword, or end-of-file is encountered. The parameters can be in any order after the param keyword.
service=TRANSFER export=true inbuf=FML outbuf=FML param=ACCOUNT_ID type=integer access=in count=2 param=SAMOUNT type=string access=in param=SBALANCE type=string access=out count=2 param=STATLIN type=string access=out service=LOGIN inbuf=VIEW inview=LOGINS outview=LOGINR export=true param=user type=string access=in param=passwd type=string access=in param=token type=integer access=out service=PAYROLL inbuf=FML outbuf=FML param=EMPLOYEE_NUM type=integer access=in param=SALARY type=float access=inout param=HIR
5. Using the Jolt Repository Editor Use the Jolt Repository Editor to add, modify, test, export, and delete Compaq NonStopTM TUXEDO service definitions from the Repository based on the information available from the NonStopTM TUXEDO configuration file. The Jolt Repository Editor accepts NonStopTM TUXEDO service definitions, including the names of the packages, services, and parameters. The Repository is used internally by Jolt to translate Java parameters to a NonStopTM TUXEDO-type buffer.
The parts of the Repository Editor window are: Part Function Entry fields Enter text, numbers, or alphanumeric characters such as service names, server names, or port numbers. Scrollable display Display list Command buttons View lists that extend beyond the display using a button. Select from a list of predefined items such as the Parameters list or select from a list of items that have been defined.
Getting Started Before starting the Repository Editor, make sure that you have installed all necessary Jolt software. To use the Repository Editor, you must: ● Start the Repository Editor ● Log on to the Repository Editor Note For information on exiting the Repository Editor when you are finished entering information, refer to Exiting the Repository Editor. Start the Repository Editor from either the JavaSoft appletviewer or from your Web browser. Starting the Repository Editor Using appletviewer 1.
Logging on to the Repository Editor After starting the Jolt Repository Editor: 1. Type the name of the server machine designated as the access point to the NonStopTM TUXEDO application and select the port number text field. 2. Type the port number and press Enter. The system validates the server and port information. Note Unless you are logging on through the Jolt Relay, the same port number is used to configure the Jolt Listener. Refer to your UBBCONFIG file for additional information. 3.
Option Description Server Type the server name. Port Number Type the port number in decimal value. Note that after the server name and port number are entered, the user name and password fields are activated. Activation is based on the authentication level of the NonStopTM TUXEDO application. Application Password Enter the NonStopTM TUXEDO administrative password. User Name Enter the NonStopTM TUXEDO user identification. The first character must be an alpha character.
Exiting the Repository Editor Exit the Repository Editor when you are finished adding, editing, testing, or deleting packages, services, and parameters. Only Pages, Services, and Close are enabled. All text entry fields are disabled. To exit the Repository Editor: 1. Select Back from a previous window to return to the Logon window. 2. Select Close to terminate the connection with the server. The Repository Editor Logon window continues to display with disabled fields. 3.
What is a Package? Packages provide a convenient method for grouping services for Jolt administration. A service is composed of parameters, including PIN number, account number, payment, rate, term, age, or Social Security number. The Packages Window Figure 5-4.
Option Description Packages Lists available packages. Services Lists available services within a selected package. Package Organizer Accesses the Package Organizer window to review available packages and services, moves the services among the package,s or add a new package. Export Makes the most current services available to the client. Enabled when a package is selected. Unexport Enabled when a package is selected. Delete Deletes a package.
What is a Service? A service is a definition of an available NonStopTM TUXEDO service. Services are composed of parameters such as PIN number, account number, payment, and rate. Adding or editing a Jolt service does not affect an existing NonStopTM TUXEDO service. Use the Services window to add, edit, or delete services. To view the services, select Services from the Logon window. The available packages are displayed in the Packages display list.
Packages Lists the services and parameters for a selected package. Select a package to add a new service, edit, or delete a service. Services Lists a service in a package to edit or delete. Parameters When a service is selected, displays its service parameters. New Displays the Edit Services window for adding a new service. Edit Displays the Edit Services window for editing an existing service. Enabled if a service has been selected. Delete Deletes a service. Enabled if a service has been selected.
Setting Up Packages and Services This section describes these procedures: ● Adding a package ● Adding a service ● Adding a parameter Saving Your Work As you are creating and editing services and parameters, it is important to regularly save information to ensure that you do not inadvertently lose any input. Selecting Save Service can prevent the need to re-enter information in the event of a system failure. Be sure to exercise caution when you are adding or editing the parameters of a service.
If youo add a new service or modify an existing service using the Edit Services window, select Save Service before choosing Back. If you select Back before the modified information is saved, a warning briefly displays on the status line at the bottom of the window. Adding a Package You must create a new package before adding the services. . Figure 5-7. Adding a New Package To create a package: 1. From the Logon window, select Packages. The Packages window displays. 2. Select Package Organizer.
displayed in the Packages display list in random order. Adding a Service Services are definitions of available NonStopTM TUXEDO services and can only be a part of a Jolt package. You are not required to create a new package before creating a new service; however, you must create the service as a part of a package, even if it is moved to a different package later.
Option Description Service Name Adds the name of the new service to the Repository. Input Buffer Type, Output Buffer Type VIEW--a C-structure and 16-bit integer field. Contains subtypes that have a particular structure. X_C_TYPE and X_COMMON are equivalent. X_COMMON is used for COBOL and C. VIEW32--similar to VIEW, except 32-bit field identifiers are associated with VIEW32 structure elements.
STRING--a character array terminated by a null character that is encoded or decoded. Input View Name, Output View Name A unique name assigned to the Input View Buffer and Output View Buffer types. These fields are only enabled if VIEW or VIEW32 are the selected buffer types. Current Status Shows thethe service status as either Exported or Unexported . Unexported is the default. Save Service Saves newly created service in the Repository. Test Tests the service.
Note If Save Service is not selected before selecting Back, the parameters are not saved as part of the service. 7. Select Back to return to the previous window. Figure 5-9. Edit Parameters Window Option Description Field Name Adds the field name (for example, asset, inventory).
Data Type List data type choices: byte--8-bit short--16-bit integer--32-bit float--32-bit double--64-bit string--null-terminated character array carray--variable length 8-bit character array Direction Lists choices for direction: Input--Information is directed from the client to the server. Output--Information is directed from the server to the client. Both--Information is directed from the client to the server, and from the server to the client.
Grouping Services Using the Package Organizer The Package Organizer moves or transfers services between packages. You may want to group related services in a package (for example, WITHDRAWAL services that are exported only at a certain time of the day can be grouped together in a package). The Package Organizer arrow buttons allow you to move a service from one package to another. These buttons are useful if you have several services to move between packages.
Available Packages Lists packages available where the service to be moved currently resides. left Lists packages available to move the service to. right Services left Lists available services for the highlighted package that can be moved. Lists available services that have been moved for the highlighted package. right Left arrow Moves highlighted services on the right (one service at a time) to the package highlighted on the left.
Modifying Packages, Services, and Parameters If a package, service, or parameter requires modifications, you can edit a service or parameter, or delete a parameter, service, or package. Editing a Service Use the Edit Service Window to edit an existing service name or service information. For a description of the Edit Services window, see Adding a Service. Figure 5-12 is an example of the Edit Services window. Figure 5-12.
To edit a service: 1. Select the package containing the service that requires editing. 2. Select the service to edit. The parameters are displayed in the parameters display list. 3. Select Edit. The Edit Services window displays. 4. Type or select the new information and select Save Service. Editing a Parameter All parameter elements can be changed, including the name of the parameter.
WARNING If you are creating a new parameter using an existing name, the system overwrites the existing parameter. Figure 5-13 is an example of the Edit Parameters window. Figure 5-13.
Editing a Parameter Instructions 1. Select the parameter in the Parameters window and select Edit Parameters. The Edit Parameters: Changing Existing Parameter window displays. 2. Type the new information and select Change. 3. Select Back to return to the previous window. Deleting Parameters, Services, and Packages Before you delete a package,you must delete all of the services from the package. The Delete option is not enabled until all components of the package or service are deleted.
Deleting a Parameter Determine which parameter to delete, then: 1. Highlight the parameter in the Parameters display list and select Delete Parameter. 2. Select Back to return to the previous window. Deleting a Service Determine which services to delete, then: 1. Select Services from the Logon window. The Packages window displays. 2. Select the package containing the service you want to delete. 3. Select the service you want to delete. Delete is enabled. 4. Select Delete. The service is deleted.
2. Select a package. Export and Unexport are enabled. 3. To make services available, select Export. 4. To make services unavailable, select Unexport. Note The system does not confirm that the service has been exported or unexported. See Reviewing the Exported/Unexported Status for additional information. Figure 5-14. Export and Unexport Buttons Reviewing the Exported/Unexported Status When a service is exported or unexported, you can review its status from the Edit Services window. 1.
3. Select the service. 4. Select Edit. : Figure 5-15. Exported/Unexported Status Testing a Service A service and its parameters should be tested to ensure that they are functioning properly before they are made available to Jolt clients. Services that are currently available can be tested without making changes to the services and parameters. Note The Repository Editor allows you to test an existing NonStopTM TUXEDO service with Jolt without writing Java code.
An exported or unexported service can be tested. If you need to change a service and its parameters, unexport the service before you edit it. Repository Editor Service Test Window Although testing is enabled when parameters are not added to a service, the Service Test window (Figure 5-16) displays the parameter fields as unused and they are disabled. A service can only be tested when the corresponding NonStopTM TUXEDO server is running for the service being tested.
Testing a Service Process Flow You can test a service without making changes to the service or its parameters. You can also test a service after editing the service or its parameters. Figure 5-17 shows a typical Repository Editor service test flow. Figure 5-17. Test Service Flow Testing a Service Instructions 1. Select Services from the Logon window to display the Services window. 2. Select the package and the service to test. 3. Select Edit to access the Edit Services window. 4.
5. Select Services to display the Services window. 6. Select the package and the service that requires editing and select Edit. 7. Edit the service. 8. Save the service and then go to Step 4 in the previous list. Some Reasons a Test Might Fail If this . . . Do this . . . A parameter is incorrect. Edit the service. The Jolt server is down. Check the server. The NonStopTM TUXEDO service is down. You do not need to edit the service.
You cannot connect to the Jolt Server (after entering Server and Port Number) You cannot start the Repository Editor Check that: ● Your Server name is correct (and accessible from your machine), the port number is correct, a JSL or JRLY must be configured to listen on that port. ● The Jolt server is up and running. If any authentication is enabled, check that you are entering the correct user names and passwords.
You cannot test services ● Check that the service is available. ● Verify that the service definition matches the service. ● If NonStopTM TUXEDO authentication is enabled, check that you have the required permissions to execute the service. ● Check if the application file (FML or VIEW) is specified correctly in the variables (FIELDTBLS or VIEWFILES) in the ENVFILE. All applications' FML field tables or VIEW files must be specified in the FIELDTBLS and VIEWFILES environment variables in the ENVFILE.
6. Using the Jolt Class Library The Jolt Class Library provides developers with a set of new object-oriented Java language classes for accessing Compaq NonStopTM TUXEDO services. These classes allow you to extend applications for Internet and intranet transaction processing. The application developer can use the Jolt Class Library to customize access to NonStopTM TUXEDO services from Java applets.
Java Applications vs. Java Applets Java programs that run in a browser are called applets. Applets are intended to be small, easily downloaded parts of an overall application that perform specific functions. Many popular browsers impose limitations on the capabilities of Java applets for the purpose of providing a high degree of security for the users of the browser. These are some of the restrictions imposed on applets: ● An applet ordinarily cannot read or write files on any host system.
Jolt Client/Server Relationship Jolt works in a distributed client/server environment and connects Java clients to NonStopTM TUXEDO-based applications. Figure 6-1 illustrates the client/server relationship between a Jolt program and the Jolt Server. Figure 6-1. Jolt Client/Server Relationship The Jolt Server acts as a proxy for a native NonStopTM TUXEDO client, implementing functionality available through the native NonStopTM TUXEDO client.
1 attr=new JoltSessionAttributes(); attr.setString( attr.APPADDRESS, "//myhost:8000" ); Binds the client to the NonStopTM TUXEDO environment 2 session=new JoltSession( attr, username, userRole, userPassword, appPassword ); Logs the client on to NonStopTM TUXEDO 3 withdrawal=new JoltRemoteService( servname, session ); Looks up the service attributes in the Repository 4 withdrawal.addString( "accountnumber", "123" ); withdrawal.addFloat( "amount", (float) 100.
4. Perform the necessary transaction processing. 5. Log the client off of the NonStopTM TUXEDO system. Each of these activities is handled through the use of the Jolt Class Library classes. These classes include methods for setting and clearing data and for handling remote service actions. The following section describes the Jolt Class Library classes in more detail. Jolt Object Relationships Figure 6-2 illustrates the relationship between the instantiated objects of the Jolt Class Library classes.
Jolt Class Functionality Jolt classes are used to perform the basic functions of transaction processing: log on/log off, synchronous service calling, transaction begin, commit, rollback and subscribe to events or unsolicited messages. The following sections describe how the Jolt classes are used to perform these functions. Logon/Logoff The client application must log on to the NonStopTM TUXEDO environment before initiating any transaction activity.
trans = new JoltTransaction(timeout, session) Jolt uses an explicit transaction model for any services involved in a transaction. The transaction service invocation requires a JoltTransaction object as a parameter. Jolt also requires that the service and the transaction belong to the same session. Jolt does not allow you to use services and transactions that are not bound to the same session.
switch (sattr.checkAuthenticationLevel()) { case JoltSessionAttributes.NOAUTH: System.out.println("NOAUTH\n"); break; case JoltSessionAttributes.APPASSWORD: appPassword = "appPassword"; break; case JoltSessionAttributes.USRPASSWORD: userName = "myname"; userPassword = "mysecret"; appPassword = "appPassword"; break; } sattr.setInt(sattr.
catch (ApplicationException e) { e.printStackTrace(); // This service uses the STATLIN field to report errors // back to the client application. System.err.println(withdrawal.getStringDef("STATLIN","NO STATLIN")); System.exit(1); } String wbal = withdrawal.getStringDef("SBALANCE", "$-1.0"); // remove leading "$" before converting string to float float w = Float.valueOf(wbal.substring(1)).floatValue(); if (w < 0.0) { System.err.println("Insufficient funds"); trans.rollback(); System.
System.out.println("Successful deposit"); System.out.println("New balance is: " + dbal); } session.endSession(); System.exit(0); } // end main } // end SimXfer The basic steps of the transaction process are as follows: 1. Set the connection attributes like hostname and portnumber in the JoltSessionAttribute object; see this line in the example: sattr = new JoltSessionAttributes(); 2. The sattr.
The add*() methods can throw IllegalAccessError or NoSuchFieldError exceptions. 6. The JoltTransaction call allows a timeout to be specified if the transaction does not complete within the specified time. Refer to the following line in Example 6-1: trans = new JoltTransaction(5,session); 7. Once the withdrawal service definition has been automatically populated, the withdrawal service is invoked by calling the withdrawal.call(trans) method. Refer to the following line in Example 6-1: withdrawal.
● Using the FML Buffer Type ● Using the VIEW Buffer Type (Note that X_COMMON and X_C_TYPE are used identically to VIEW.) For information about all of the NonStopTM TUXEDO typed buffers, data types, and buffer types, refer to the NonStopTM TUXEDO Application Programming Guide and the NonStopTM TUXEDO Reference Manual.
2. For the TOUPPER service, define an input buffer type of STRING and an output buffer type of STRING. 3. Define only one parameter for the TOUPPER service named STRING that is both an input and an output parameter.
ToUpper.java Client Code Example 6-2 illustrates how Jolt works with a service whose buffer type is STRING. The example shows a Jolt client using a STRING buffer to pass data to a server. The NonStopTM TUXEDO server would take the buffer, convert the string to all uppercase letters and pass the string back to the client. The example assumes that a session object was already instantiated. Example 6-2. Use of the STRING buffer type (ToUpper.
/* Copyright 1996 BEA Systems, Inc. import bea.jolt.*; All Rights Reserved */ public class ToUpper { public static void main (String[] args) { JoltSession session; JoltSessionAttributes sattr; JoltRemoteService JoltTransaction toupper; trans; String userName=null; String userPassword=null; String appPassword=null; String userRole="myapp"; String outstr; sattr = new JoltSessionAttributes(); sattr.setString(sattr.APPADDRESS, "//myhost:8501"); switch (sattr.
} sattr.setInt(sattr.IDLETIMEOUT, 300); session = new JoltSession(sattr, userName, userRole, userPassword, appPassword); toupper = new JoltRemoteService ("TOUPPER", session); toupper.setString("STRING", "hello world"); toupper.call(null); outstr = toupper.getStringDef("STRING", null); if (outstr != null) System.out.println(outstr); session.endSession(); System.
In the Repository Editor add the ECHO service as follows: 1. Add a service named ECHO whose buffer type is CARRAY. 2. Define the input buffer type and output buffer type as CARRAY for the ECHO service. 3. Define the ECHO service with only one parameter named CARRAY that is both an input and output parameter. Note that if you are using the X_OCTET buffer type, you must change the Input Buffer Type and Output Buffer Type fields to X_OCTET.
tryOnCARRAY.java Client Code Example 6-3 illustrates how Jolt works with a service whose buffer type is CARRAY. Since Jolt does not look into the CARRAY data stream, the programmer must match the data format between the Jolt client and the CARRAY service. The following example assumes that a session object was already instantiated. Example 6-3. Use of the CARRAY buffer type (tryOnCARRAY.java) /* Copyright 1996 BEA Systems, Inc.
/* Use java.io.DataOutputStream to put data into a byte array */ bout = new ByteArrayOutputStream(512); dout = new DataOutputStream(bout); dout.writeInt(100); dout.writeFloat((float) 300.00); dout.writeUTF("Hello World"); dout.writeShort((short) 88); /* Copy the byte array into a new byte array "data". * issue the Jolt remote service call. */ data = bout.toByteArray(); Then csvc = new JoltRemoteService("ECHO", session); csvc.setBytes("CARRAY", data, data.length); csvc.
System.out.println(din.readShort()); } } } Using the FML Buffer Type Field Manipulation Language (FML) is a flexible data structure that can be used as a typed buffer. The FML data structure stores tagged values that are typed, variable in length, and may have multiple occurrences. The typed buffer is treated as an abstract data type in FML. FML lets you access and update data values without having to know how the data is structured and stored.
/* Copyright 1997 BEA Systems, Inc. All Rights Reserved */ import bea.jolt.*; class ... { ... public void tryOnFml () { JoltRemoteService passFml; String outputString; int outputInt; float outputFloat; ... passFml = new JoltRemoteService("PASSFML",session); passFml.setString("INPUTSTRING", "John"); passFml.setInt("INPUTINT", 67); passFml.setFloat("INPUTFLOAT", (float)12.0); passFml.call(null); outputString = passFml.getStringDef("OUTPUTSTRING", null); outputInt = passFml.
Example 6-5. tryOnFml.f16 Field Definitions # # FML field definition table # *base 4100 INPUTSTRING 1 string INPUTINT INPUTFLOAT OUTPUTSTRING 2 3 4 OUTPUTINT OUTPUTFLOAT 5 long float string 6 long float Define PASSFML in the Repository Editor The other service in SIMPAPP package is the PASSFML service. This service is used with the tryOnFml.java and tryOnFml.c code.
3. Define the parameters for the PASSFML service.
tryOnFml.c Server Code Example 6-6 illustrates the server side code for using the FML buffer type. The PASSFML service reads in an input FML buffer and outputs an FML buffer. Example 6-6. tryOnFml.
/* * tryOnFml.c * * Copyright (c) 1997 BEA Systems, Inc. * * Contains the PASSFML TUXEDO server. * */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "tryOnFml.f16.
/* * PASSFML service reads in a input fml buffer and outputs a fml buffer.
/* We could just pass the FML buffer back as is, put lets /* store it into another FML buffer and pass it back.
When allocating a VIEW, your application specifies a buffer type of VIEW and a subtype that matches the name of the view (the name that appears in the view description file). Since the NonStopTM TUXEDO run-time system can determine the space needed based on the structure size, your application need not provide a buffer length.
/* Copyright 1997 BEA Systems, Inc. All Rights Reserved */ /* * This code fragment illustrates how Jolt works with a service whose buffer * type is VIEW. */ import bea.jolt.*; class ... { ... public void simpview () { JoltRemoteService ViewSvc; String outString; int outInt; float outFloat; // Create a Jolt Service for the TUXEDO service "SIMPVIEW" ViewSvc = new JoltRemoteService("SIMPVIEW",session); // Set the input parametes required for SIMPVIEW ViewSvc.setString("inString", "John"); ViewSvc.
System.out.print("outString=" + outString + ","); System.out.print("outInt=" + outInt + ","); System.out.println("outFloat=" + outFloat); } } VIEW Field Definitions The following entries show the NonStopTM TUXEDO VIEW field definitions for the simpview.java example. Example 6-8. simpview.v16 Field Definitions # # VIEW for SIMPVIEW. This view is used for both input and output. The # service could also have used separate input and output views. # The first 3 params are input params, the second 3 are outputs.
Note If you are not familiar with using the Jolt Repository Editor, refer to Adding a Service and Adding a Parameter for more information about defining your services and adding new parameters. In the Repository Editor add the VIEW service as follows: 1. Add a VIEWSVC service for the SIMPAPP package. 2. Define the VIEWSVC service with an input buffer type of VIEW and an output buffer type of VIEW.
3. Define the parameters for the VIEW service. In this example, the parameters are: cname, inString, inInt, inFloat, outString, outInt, outFloat. Note If using the X_COMMON or X_C_TYPE buffer types, you must put the correct buffer type in the Input Buffer Type and Output Buffer Type fields. Additionally, you must choose the corresponding Input View Name and Output View Name fields. simpview.
In the following server code, the input and output buffers are VIEW. The code accepts the VIEW buffer data as input and outputs the same data as VIEW. Example 6-9. simpview.c Source Code /* * SIMPVIEW.c * * Copyright (c) 1997 BEA Systems, Inc. * * Contains the SIMPVIEW Tuxedo server. * */ #include #include #include #include #include #include #include #include #include #include #include
#include "simpview.h" /* * Contents of simpview.h. * *struct SimpView { * char inString[32]; * long inInt; * float inFloat; * * * char long float outString[32]; outInt; outFloat; *}; */ /* * service reads in a input view buffer and outputs a view buffer. */ void SIMPVIEW( TPSVCINFO *rqst ) { /* * get the structure (VIEWSVC) from the TPSVCINFO structure */ struct SimpView *svcinfo = (struct SimpView *) rqst->data; /* * print the input params to the UserLog. Note there is * no error checking here.
/* * Populate the output fields and send them back to the caller */ strcpy (svcinfo->outString, "Return from SIMPVIEW"); svcinfo->outInt = 100; svcinfo->outFloat = (float) 100.00; /* * If there was an error, return TPFAIL * tpreturn(TPFAIL, ErrorCode, (char *)svcinfo, sizeof (*svcinfo), 0); */ tpreturn(TPSUCCESS, 0, (char *)svcinfo, sizeof (*svcinfo), 0); } Multithreaded Applications As a Java-based set of classes, Jolt supports multithreaded applications.
● A RUNNING thread is a currently executing thread. ● A RUNNABLE thread can be run once the current thread has relinquished control of the CPU. There can be many threads in the RUNNABLE state, but only one can be in the RUNNING state. Running a thread means changing the state of a thread from RUNNABLE to RUNNING, and causing the thread to have control of the Java Virtual Machine (VM). ● A BLOCKED thread is a thread that is waiting on the availability of some event or resource.
Note Sun has indicated that JDK 1.1 will implement preemptive threads, and should alleviate the requirement for yields. Code that includes yields will continue to work; code without yields will begin working with the JDK 1.1 release. Using Threads for Asynchronous Behavior You can use threads in Jolt to get asynchronous behavior that is analogous to the tpcall() function in NonStopTM TUXEDO. With this capability, you do not need a asynchronous service request function.
/* Copyright 1996 BEA Systems, Inc. import bea.jolt.*; All Rights Reserved */ public class ThreadBank { public static void main (String [] args) { JoltSession session; try { JoltSessionAttributes dattr; String userName = null; String userPasswd = null; String appPasswd = null; String userRole = null; // fill in attributes required dattr = new JoltSessionAttributes(); dattr.setString(dattr.APPADDRESS,"//bluefish:8501"); // instantiate domain // check authentication level switch (dattr.
userPasswd = "mySecret"; appPasswd = "myAppPasswd"; break; } dattr.setInt(dattr.IDLETIMEOUT, 60); session = new JoltSession (dattr, userName, userRole, userPasswd, appPasswd); T1 t1 = new T1 (session); T2 t2 = new T2 (session); t1.start(); t2.start(); Thread.currentThread().yield(); try { while (t1.isAlive() && t2.isAlive()) { Thread.currentThread().
catch (InterruptedException e) { System.err.println(e); if (t2.isAlive()) { System.out.println("job 2 is still alive"); try { Thread.currentThread().sleep(1000); } catch (InterruptedException e1) { System.err.println(e1); } } else if (t1.isAlive()) { System.out.println("job1 is still alive"); try { Thread.currentThread().sleep(1000); } catch (InterruptedException e1) { System.err.
session.endSession(); } catch (SessionException e) { System.err.println(e); } finally { System.out.println("normal ThreadBank term"); } } } class T1 extends Thread { JoltSession j_session; JoltRemoteService j_withdrawal; public T1 (JoltSession session) { j_session=session; j_withdrawal= new JoltRemoteService("WITHDRAWAL",j_session); } public void run() { j_withdrawal.addInt("ACCOUNT_ID",10001); j_withdrawal.addString("SAMOUNT","100.00"); try { System.out.
System.out.println("-->Withdrawal Balance: " + W); } catch (ApplicationException e) { e.printStackTrace(); System.err.println(e); } } } class T2 extends Thread { JoltSession j_session; JoltRemoteService j_deposit; public T2 (JoltSession session) { j_session=session; j_deposit= new JoltRemoteService("DEPOSIT",j_session); } public void run() { j_deposit.addInt("ACCOUNT_ID",10000); j_deposit.addString("SAMOUNT","100.00"); try { System.out.println("Initiating Deposit from account 10000"); j_deposit.
catch (ApplicationException e) { e.printStackTrace(); System.err.println(e); } } } Event Subscription and Notifications Programmers developing client applications using Jolt can receive event notifications from either NonStopTM TUXEDO Services or other NonStopTM TUXEDO clients. The Jolt Class Library contains classes that support the following types of NonStopTM TUXEDO notifications for handling event-based communication: ● Unsolicited Event Notifications.
Notification Event Handler For both unsolicited notifications and a brokered event notification, the Jolt client application requires an event handler routine that is invoked upon receipt of a notification. The Jolt 1.2 release only supports a single handler per session. In current NonStopTM TUXEDO versions, it is not possible to determine which event generated a notification. Thus it is not possible to invoke an event-specific handler based on a particular event.
Notification Data Buffers When a client receives notification, it is accompanied by a data buffer. The data buffer can be of any NonStopTM TUXEDO data buffer type. Jolt clients (i.e., the handler) will receive these buffers as a JoltMessage object and should use the appropriate JoltMessage class get*() methods to retrieve the data from this object. The Jolt Repository does not need to have the definition of the buffers used for notification.
Note This is NOT the recommended method for enabling unsolicited notification--if you want unsolicited notification, the application should explicitly do so (as described in the JoltUserEvent class). The reason for this is explained in the following unsubscribe section. Unsubscribing from Notifications To stop subscribing to event notifications and/or unsolicited messages, you need to use the JoltUserEvent unsubscribe method.
class EventSession extends JoltSession { public EventSession( JoltSessionAttributes attr, String user, String role, String upass, String apass ) { super(attr, user, role, upass, apass); } /* * Override the default unsolicited message handler. * @param reply a place holder for the unsolicited message * @see bea.jolt.JoltReply */ public void onReply( JoltReply reply ) { // Print out the STRING buffer type message which contains // only one field; the field name must be "STRING".
public static void main( Strings args[] ) { JoltUserEvent unsolEvent; JoltUserEvent EventSession helloEvent; session; ... // Instantiate my session object which can print out the // unsolicited messages. Then subscribe to HELLO event // and Unsolicited Notification which both use STRING // buffer type for the unsolicited messages. session = new EventSession(...); helloEvent = new JoltUserEvent("HELLO", null, session); unsolEvent = new JoltUserEvent(JoltUserEvent.UNSOLMSG, null, session); ...
Example 6-12. Jolt Object Reuse (reuseSample.java) /* Copyright 1996 BEA Systems, Inc. All Rights Reserved */ import java.net.*; import java.io.*; import bea.jolt.*; /* * This is a Jolt sample program that illustrates how to reuse the * JoltRemoteService after each invocation. */ class reuseSample { private static JoltSession s_session; static void init( String host, short port ) { /* Prepare to connect to the TUXEDO domain. */ JoltSessionAttributes attr = new JoltSessionAttributes(); attr.setString(attr.
/* Check what authentication level has been set. */ switch (attr.checkAuthenticationLevel()) { case JoltSessionAttributes.NOAUTH: break; case JoltSessionAttributes.APPASSWORD: applpasswd = "secret8"; break; case JoltSessionAttributes.USRPASSWORD: username = "myName"; userpasswd = "BEA#1"; applpasswd = "secret8"; break; } /* Logon now without any idle timeout (0). */ /* The network connection is retained until logoff. */ attr.setInt(attr.
public static void main( String args[] ) { String host; short port; JoltRemoteService svc; if (args.length != 2) { System.err.println("Usage: reuseSample host port"); System.exit(1); } /* Get the host name and port number for initialization. */ host = args[0]; port = (short)Integer.parseInt(args[1]); init(host, port); /* Get the object reference to the DELREC service. This * service has no output parameters, but has only one input * parameter.
/* Simply discard all input parameters */ svc.clear(); svc.addString("REPNAME", "Record3"); svc.call(null); } catch (ApplicationException e) { System.err.println("Service DELREC failed: "+ e.getMessage()+" "+ svc.getStringDef("MESSAGE", null)); } /* Logoff now and get rid of the object. */ s_session.endSession(); } } Reusing Objects The following extendSample.java example illustrates one way to subclass the JoltRemoteService class.
/* Copyright 1996 BEA Systems, Inc. All Rights Reserved */ import java.net.*; import java.io.*; import bea.jolt.*; /* * This Jolt sample code fragment illustrates how to customize * JoltRemoteService.
try { /* Invoke the transfer service. */ this.call(null); /* Get the output parameters */ fromBal = this.getStringItemDef("SBALANCE", 0, null); if (fromBal == null) return "No balance from Account " + fromAcctNum; toBal = this.getStringItemDef("SBALANCE", 1, null); if (toBal == null) return "No balance from Account " + toAcctNum; return null; } catch (ApplicationException e) { /* The transaction failed, return the reason */ return this.
class extendSample { public static void main( String args[] ) { JoltSession s_session; String host; short port; TransferService xfer; String failure; if (args.length != 2) { System.err.println("Usage: reuseSample host port"); System.exit(1); } /* Get the host name and port number for initialization. */ host = args[0]; port = (short)Integer.parseInt(args[1]); /* Prepare to connect to the TUXEDO domain. */ JoltSessionAttributes attr = new JoltSessionAttributes(); attr.setString(attr.
/* Check what authentication level has been set. */ switch (attr.checkAuthenticationLevel()) { case JoltSessionAttributes.NOAUTH: break; case JoltSessionAttributes.APPASSWORD: applpasswd = "secret8"; break; case JoltSessionAttributes.USRPASSWORD: username = "myName"; userpasswd = "BEA#1"; applpasswd = "secret8"; break; } /* Logon now without any idle timeout (0). */ /* The network connection is retained until logoff. */ attr.setInt(attr.
System.err.println("Tranasaction failed: " + failure); else { System.out.println("Transaction is done."); System.out.println("From Acct Balance: "+xfer.fromBal); System.out.println(" To Acct Balance: "+xfer.toBal); } if ((failure = xfer.doxfer(51334, 40343, "$123.25")) != null) System.err.println("Tranasaction failed: " + failure); else { System.out.println("Transaction is done."); System.out.println("From Acct Balance: "+xfer.fromBal); System.out.println(" To Acct Balance: "+xfer.
● Requirements for the NonStopTM TUXEDO server and Jolt Server ● Client-side execution of the applet ● Requirements for the Web server that downloads the Java applet The following sections describe common client and Web server considerations for deploying Jolt applets. Client Considerations When you write a Java applet that incorporates Jolt classes, the applet works just as any other Java applet in an HTML page.
/export/html/ |___ classes/ | |_____ bea/ | | |______ jolt/ | | | | |_____ JoltSessionAttributes.class |_____ JoltRemoteServices.class | | | | |_____ ... |_____ mycompany/ |________ app.class |___ ex1.html |___ ex2.html The webmaster may specify the "app" applet in ex1.html as:
7. Using JoltBeans Formerly available as an add-on, JoltBeans are now included in Jolt for Compaq NonStopTM TUXEDO. Using JoltBeans, you can create Jolt client applications with the ease of using JavaBeans. JoltBeans are JavaBeans components that are used in Java development environments (IDEs) to construct Jolt clients. You can now use popular Java-enabled development tools like Symantec Visual Café to graphically construct client applications.
TUXEDO services. Note Currently, Symantec Visual Café 3.0 is the only IDE that has been certified for use with JoltBeans. However, JoltBeans are also compatible with other Java development environments such as Visual Age. The first topics in this section provide a general, conceptual overview of how JoltBeans work, as well as a description of each Jolt bean and how it interacts with NonStopTM TUXEDO events.
development environment so that JoltBeans are available in the component library of your Java tool. For example, using Symantec Visual Café, you can set the class path so that the .jar files are visible in the Component Library window of Visual Café. You only need to set the class path of the .jar files in your development environment once. After you have placed these .jar files in the class path of JoltBeans to the Component Library.
JavaBeans Events and NonStopTM TUXEDO Events JavaBeans communicate via events. An event in a NonStopTM TUXEDO system is different from an event in a JavaBeans environment. In a NonStopTM TUXEDO application, an event is raised from one part of an application to another part of the same application. JoltBeans events are communicated between beans. Using NonStopTM TUXEDO Event Subscription and Notification With JoltBeans NonStopTM TUXEDO supports brokered and unsolicited event notification.
The JoltBeans Toolkit The JoltBeans toolkit includes the following beans: ● JoltSessionBean ● JoltServiceBean ● JoltUserEventBean These components transform the complete Jolt Class Library into beans components, with all of the features of any typical JavaBean, including easy reuse and graphic development ease. Refer to the online Jolt API Reference in Javadoc for specific descriptions of the JoltBeans classes, constructors, and methods.
JoltSessionBean. When a logon is successful and a session is established, LoggedOn is set to TRUE. After the logoff is successful and the session is closed, the LoggedOn property is set to FALSE. The JoltSessionBean provides methods to control transactions, including beginTransaction(), commitTransaction(), and rollbackTransaction(). Table 7-1 shows the JoltSessionBean properties and descriptions. Table 7-1.
Transactional Set to TRUE if this JoltServiceBean is to be included in the transaction that was started by its JoltSessionBean. JoltUserEventBean The JoltUserEventBean provides access to NonStopTM TUXEDO events. The NonStopTM TUXEDO event to subscribe to or unsubscribe from is defined by setting the appropriate properties of this bean (event name and event filter). The actual event notification is delivered in the form of a JoltOutputEvent from the JoltSessionBean.
JoltList This is a Jolt-aware extension of java.awt.List that is linked to a specific Jolt field in the Jolt input or output buffer by its JoltFieldName property. If the field occurs multiple times in the Jolt input buffer, the occurrence this list is linked to is specified by the occurrenceIndex property of this bean. JoltList can be connected with JoltServiceBeans in two ways: ● JoltList contains parts of the input for a service. A JoltServiceBean listens to events raised by a JoltList.
. When the ellipsis button is selected, the Property Editor shown in Figure 7-3 is displayed. Figure 7-3. Custom Property Editor Dialog Box The Custom Property Editors of JoltBeans read cached information. Initially, there is no cached information available, so when the Property Editor is used for the first time, the dialog box is empty. Log on to the Jolt repository and load the Property Editor cache from the repository.
Figure 7-4. Sample Inquiry Applet Refer to Figure 7-6 for an example of each item. To begin, select the following items shown in Table 7-4. Table 7-4. Required Form Components Component Purpose Applet A form used to paint the beans in your development environment. JoltSessionBean Logs on to a NonStopTM TUXEDO session. JoltTextField Gets input from the user (in this case, ACCOUNT_ID). JoltTextField Displays the result (in this case, SBALANCE).
These steps are described in detail in the following sections. Note The graphic interface of previous versions of Visual Café differ from the look of Visual Café 3.0. You can complete this sample applet in a previous version of Visual Café. However, the steps executed in the Interaction Wizard differ slightly from this example. Placing JoltBeans Onto the Form Designer 1. Choose File | New Projects and select JFC Applet. 2.
3. Next, set the properties of each bean. To modify or customize the buttons, labels or fields, use the Property List. Some JoltBeans use a Custom Property Editor. The example in Figure 7-7 shows how selecting the JoltFieldName of the button property list displays the Custom Property Editor. Set the properties of the beans (for example, set the JoltFieldName property of the JoltTextField to ACCOUNT_ID). Refer to Figure 7-7).
button1 Label Inquiry Note In this walkthrough, the default occurrenceIndex of 0 works for both JoltTextFields. Refer to Table 7-6 and Using the JoltBeans Repository and Setting the Property Values for general guidelines on JoltBean properties. Figure 7-7. Example of JoltTextField Property List and Custom Property Editor 1. To change the value of the JoltFieldName property, click on the ellipsis button of the JoltFieldName in the Property List. The Custom Property Editor is displayed.
The change is reflected in the Property List shown in Figure 7-8 and on the text field shown in Figure 7-9. Figure 7-9.
Figure 7-9 is an example of how the text on the Button changes after the label text is added to the Property List fields for these beans. 2. After you set the properties to the right values (refer to Table 7-5 for additional information on the required and recommended property values), define how the beans will interact by wiring them together using the Visual Café Interaction Wizard.
Wire the JoltSessionBean logon 1. Select the Interaction Wizard button. Click in the applet window (as shown in figure) and drag a line to the JoltSessionBean. The Interaction Wizard window similar to the example shown in Figure 7-11 is displayed. Figure 7-11. Wire the Applet to the Jolt Session Bean 2. Choose ComponentShown as the event you want to start the interaction. Click Next. The Visual Café Interaction Wizard displays. Figure 7-12.
3. With the "Perform an action" radio button selected, select "Logon to the TUXEDO system." Click Finish. Figure 7-13.
Wire JoltSessionBean to JoltServiceBean via propertyChange 1. Click the Interaction Wizard button. Click on the JoltSessionBean and drag a line to the JoltServiceBean. The Interaction Wizard is displayed and asks "What event in joltSessionBean1 do you want to start the interaction?" Figure 7-14.
2. Choose propertyChange as the event that starts the interaction. Click Next. The Interaction Wizard window is displayed and asks "What do you want to happen when joltSessionBean1 fires propertyChange event?" and provides a list of object and actions Figure 7-15.
. 3. Select "Handle a Jolt property change event" as the method. Choose Next. The Interaction Wizard window displays and asks, "How do you want to supply the parameter to this method?" and provides a list of available objects and actions to choose from. Figure 7-16.
4. Select joltSessionBean1 as the object that supplies the action. 5. Select "Get the current Property Change Event object" as the action. Click Finish. Completing these three steps enables the JoltSessionBean to send a propertyChange event when logon() completes. The JoltServiceBean listens to this event and associates its service with this session. Wire the accountID JoltTextField as input to the JoltServiceBean using JoltInputEvent 1. Click the Interaction Wizard button.
2. Select dataChanged as the event. Click Next. 3. With the joltServicebean "inquiry" selected as the object supplying the parameter, select "Handle a jolt input event" as the action. Click Next. Figure 7-18.
The Interaction Wizard window is displayed asking "How do you want to supply the parameter to this method?" with a list of available objects and actions to choose from. Figure 7-19.
4. With "accountId" selected as the object, select "get the current Jolt Input Event" as the action. Click Finish. Completing these four steps enables you to type the account number in the first text field. The JoltFieldName property of this JoltTextField is set to ACCOUNT_ID. Whenever the text inside this text box changes, it sends a JoltInputEvent to the JoltServiceBean. (The JoltServiceBean listens to JoltInputEvents from this textbox.
2. Select "actionPerformed" as the event. Click Next. Figure 7-21. Select "inquiry" and the Invoke TUXEDO Service...
3. Select "Invoke TUXEDO Service represented by this bean" as the action. Click Finish. Completing these two steps enables the callService() method of the JoltServiceBean to be triggered by an ActionEvent from the Inquiry button. Wire JoltServiceBean to the Balance JoltTextField Using JoltOutputEvent 1. Click the Interaction Wizard button, select the JoltServiceBean and drag a line to the AmountJoltTextField bean. The Interaction Wizard is displayed. Figure 7-22.
2. Select serviceReturned as the event. Click Next. Figure 7-23. Select "balance" and "Handle a service returned event...
3. Select "balance" as the object, and "Handle a service returned event..." as the action. Click Next. Figure 7-24. Select "inquiry" and "Get the value of field...
4. Select "inquiry" as the object, and "Get the JoltOutputEvent object" as the action. Click Finish. Completing these three steps allows the JoltServiceBean to send a JoltOutputEvent when it receives reply data from the remote service. The JoltOutputEvent object contains methods to access fields in the output buffer. The JoltTextField displays the result of the INQUIRY service. Wire the JoltSessionBean logoff 1. Click the Interaction Wizard button.
2. Select componentHidden as the event. Figure 7-26.
3. With "joltSessionBean1" selected as he object, select "Logoff from the TUXEDO system" as the action. Click Finish. Completing these two steps enables the logoff() method of the JoltSessionBean to be triggered by an applet (for example, componentHidden) that is sent when the applet gets hidden. Wire the JoltSessionBean logoff After wiring the JoltBeans together, compile the applet. It is also recommended that you fill in the empty cache blocks for exceptions.
● serviceName (JoltServiceBean) The Property Editor, accessed from the Property List, includes dialog boxes that are used to add or modify the properties. You can invoke the boxes from the Property List by selecting the button with the ellipsis "..." that is next to the value of the corresponding property value. Some JoltBeans require input in the Property List field. The beans are listed in Table 7-6. Table 7-6.
Note If you cannot or do not want to connect to the Repository database, simply type the service name in the text box and proceed to Step 7. 3. If you are not logged on, make sure the Jolt Server is running and select Logon. The JoltBeans Repository Logon shown in Figure 7-29 displays. Figure 7-29. JoltBeans Repository Log On 4. Type the NonStopTM TUXEDO or Jolt Relay Machine name for Server and the JSL or Jolt Relay Port Number. Type passwords and user name information (if required) and clock Logon. 5.
6. Select the appropriate service name in the list box shown in Figure 7-29. Enter the property value (service or field name) directly. A text box is provided. Select OK on the property editor dialog in Figure 7-29. The bean property gets set with the contents of the textbox. 7.
Using Custom GUI Elements With the JoltService Bean JoltBeans provides a limited set of GUI components. You can also use controls that are not Jolt-enabled together with the JoltServiceBean. You can link controls to the JoltServiceBean that display output information of the service represented by the JoltServiceBean. You can also link controls that display input information. For example, the GUI element that uses an adapter class to implement the JoltOutputListener interface can listen to JoltOutputEvents.
8. Using Servlet Connectivity for NonStop TUXEDO TM With Compaq NonStopTM TUXEDO Jolt 1.2 servlet connectivity, you can use HTTP servlets to perform server-side Java tasks in response to HTTP requests. Remote Jolt clients previously were Java applets or applications that connected directly to the Jolt Server in order to request NonStopTM TUXEDO services. Jolt 1.2 certifies pool with the Java Web Server Versions 1.1.3 and up, and supports most other standard servlet engines. Using the Jolt 1.
This class contains data elements that represent the input and output parameters of a NonStopTM TUXEDO service. It provides a method to import the HTML field names and values from a javax.servlet.http.HttpServletRequest object. ServletPoolManagerConfig This class is the startup class for a Jolt Session Pool Manager and one or more associated Jolt Session Pools. It creates the session pool manager if needed and starts a session pool with a minimal number of sessions. This class is derived from bea.jolt.pool.
● How to retrieve the session pool by name ● How to invoke a NonStopTM TUXEDO service ● How to process the result set This example demonstrates how a Servlet may connect to NonStopTM TUXEDO and call upon one of its services; it should be invoked from the simpapp.html file. The servlet creates a session pool manager at initialization, which is used to obtain a session when the doPost() method is invoked.
weblogic.httpd.register.simpapp=examples.jolt.servlet.SimpAppServlet 6. To access the SimpApp initial page simpapp.html, type: http://mywebserver:8080/simpapp.html BankApp Sample The Bankapp application illustrates how the servlet is written with PageCompiledServlet with Servlet Connectivity for NonStopTM TUXEDO.
application server for details. 5. To access BankApp through Servlet Connectivity for NonStopTM TUXEDO, use the following URL in your favorite browser: http://mywebserver:8080/tellerForm.
9. Using Jolt 1.2 ASP Connectivity for NonStop TUXEDO TM The Jolt Active Server Pages (ASP) Connectivity for Compaq NonStopTM TUXEDO provides an easy-to-use interface for processing and generating dynamic HTML pages. You do not need to learn how to write Common Gateway Interface (CGI) transactional programs to access NonStopTM TUXEDO services. The following topics are discussed in this section: ● Key Features ● ASP Connectivity Enhancements for Jolt 1.
Note Asynchronous notification is not available in the ASP Connectivity for NonStopTM TUXEDO. It is recommended that Jolt-enabled Java clients (applets) be written using a retained connection to support asynchronous notification. ASP Connectivity Enhancements for Jolt 1.2 Jolt 1.2 includes the following enhancements to ASP Connectivity for NonStopTM TUXEDO: ● The package name for JoltWAS has been changed from bea.web to bea.jolt.pool.
How the Jolt ASP Connectivity for NonStop TUXEDO Works TM The Jolt ASP Connectivity for NonStopTM TUXEDO architecture includes three main components: a session, a session pool, and a session pool manager. A session object represents a connection with the NonStopTM TUXEDO system. A session pool represents many physical connections between the Web server and the NonStopTM TUXEDO system. It also associates a session with an HTTP request.
Refer to the online Jolt 1.2 API Reference in Javadoc for additional information about the SessionPool class and SessionPoolManager class. The ASP Connectivity for NonStop TUXEDO Toolkit TM The ASP Connectivity for NonStopTM TUXEDO Toolkit is an extension to the Jolt 1.2 Class Library. The Toolkit allows the Jolt Client Class Library to be used in a web server (such as Microsoft Active Server) to provide an interface between HTML clients or browsers and a NonStopTM TUXEDO application.
Jolt 1.2 ASP Connectivity for NonStop TUXEDO Walkthrough TM A complete listing of all the examples used in this section are distributed with the Jolt 1.2 software. In this section, segments of code from these samples are used to illustrate the use of the Toolkit. The samples delivered with the software support four services: INQUIRY, WITHDRAWAL, DEPOSIT, and TRANSFER.
Getting Started Check List Review this checklist before starting the TRANSFER Request Walkthrough. Note This checklist applies to Microsoft Active Server Pages only. 1. The client machine must have a network connection to the web server that is used to connect to the NonStopTM TUXEDO environment. 2. Configure and boot NonStopTM TUXEDO and the NonStopTM TUXEDO Bankapp example. a. Make sure the TRANSFER service is available. b.
tellerForm.asp Initializes the Jolt Session Pool Manager and displays available Bankapp services. transferForm.htm Presents an HTML form for user input. tlr.asp Processes the HTML form and returns results as an HTML page. web_admin.inc VBScript functions for initializing the JoltSessionPool Manager. web_start.inc VBScript functions for initializing the JoltSessionPool Manager. web_templates.inc VBScript functions for caching HTML templates. templates/transfer.
● Initializing the Jolt Session Pool Manager ● Submitting a TRANSFER Request From the Client ● Processing the Request ● Returning the Results to the Client Initializing the Jolt Session Pool Manager To start the walkthrough, use the browser on your client to connect to the Web server where the Jolt Asp Connectivity For NonStopTM TUXEDO classes are installed. The first page to download is tellerForm.asp (see Figure 9-2 for an example of a ttellerForm.asp page).
The page tellerForm.asp contains VBScript procedures required to initialize the Jolt Session Pool Manager. The initialization code is contained in an ASP Script block. This code tells the web server to execute this block of code on the server, instead of sending it to the client. <% `// Initialize the sessionmanager and cache templates Call web_initSessionMgr(Null) Call web_cacheTemplates() %> The VBScript procedure web_initSessionMgr() calls other VBScript procedures to establish a pool of Jolt Sessions.
TUXEDO application. One of the procedures called is web_start(). This procedure (in the file web_start().inc) should have been edited as part of the teller application installation process in Step 6 of the Getting Started Check List. The procedure web_cacheTemplates() reads various HTML template files into a memory cache. This step is not required, but it improves performance. PAGE 193
The form in Figure 9-3 is generated by the page transferForm.htm. This page presents you with a form that will be used for input. The page consists of three text fields (two account numbers and a dollar amount), and a button that, when pressed, causes the TRANSFER service to be invoked. The following code segment in shows the key HTML elements for this page. The highlighted elements correspond to the elements in Table 9-2.
'// Choose the response template If IsEmpty(Application("templates")) Then Set template = Server.CreateObject("BEAWEB.Template") Else Select Case Request("SVCNAME") Case "INQUIRY" Set template = Application("templates")(INQUIRY) Case "DEPOSIT" Set template = Application("templates")(DEPOSIT) Case "WITHDRAWAL" Set template = Application("templates")(WITHDRAWAL) Case "TRANSFER" Set template = Application("templates")(TRANSFER) End Select End If Next, call the NonStopTM TUXEDO service.
| Account # | Balance |
| From: | <%=ACCOUNT_ID[0]%> | <%=SBALANCE[0]%> |
| To: | <%=ACCOUNT_ID[1]%> | <%=SBALANCE[1]%> |
To substitute the placeholders in the template with the actual values of the data returned from the service call, use the eval() method of the Template object shown in the following example.A. NonStop TUXEDO Errors TM This appendix describes the Jolt Class Library errors and exceptions. The Jolt Class Library returns both Jolt and Compaq NonStopTM TUXEDO errors and exceptions. The Jolt Class Library errors and exceptions are also listed for each class, constructor, and method listed in the Jolt 1.2 Online API Javadoc. NonStopTM TUXEDO errors are described briefly in this appendix. Table A-1.
TPEPERM A client cannot join an application because it does not have permission to do so or because it has not supplied the correct application password. TPEPROTO A library routine was called in an improper context. TPERELEASE To be determined. TPERMERR A resource manager failed to open or close correctly. TPESVCERR A service routine encountered an error either in tpreturn() or tpforward(). For example, bad arguments might have been passed.
B. System Messages Jolt system messages and code references will be available in a future release of the Jolt product documentation. This appendix includes: ● Jolt System Messages ● Repository Messages ● FML Error Messages ● Information Messages ● Jolt Relay Adapter (JRAD) Messages ● Jolt Relay (JRLY) Messages ● Bulk Loader Utility Messages Jolt System Messages 1503 ERROR: Could not initialize Jolt administration services. Description Jolt administration services cannot be started.
1510 ERROR: Received network message with unknown context. Description Jolt protocol failure. Received a corrupted or an improper message. Action Restart Jolt client. 1511 ERROR: _tprandkey() failed tperrno = %d, could not generate random encryption key. Description NonStopTM TUXEDO internal failure. Action Restart Jolt servers. 1512 ERROR: Sending of reply to challenge call to client failed. Description JSH was unable to reply to Jolt client because of network error. Action Restart client.
1517 ERROR: Commit handle and clientid have no matching requests. Description Received a copy from NonStopTM TUXEDO that has no corresponding client. Action No action required. 1518 ERROR: Call handle and clientid have no matching requests. Description Received a reply from NonStopTM TUXEDO that has no corresponding client. Action No action required. 1519 ERROR: Application password does not match. Description Authentication error. Action Check the application password.
1525 ERROR: Tried to process unexpected message opcode 0x%1x. Description Received a message with invalid opcode. Action Check the client. 1526 ERROR: Jolt license has expired. Description License for Jolt use has expired. Action Contact your service provider. 1527 ERROR: Expected argument to -c option. Description Option -c needs an argument. Action Provide a valid argument. 1528 ERROR: Request for inappropriate session type. Description Received a message without valid session information.
1532 ERROR: Received J_CLOSE message with invalid context. Description Timeout in connection. Action If a request is sent after a timeout that is longer than the session timeout of the JSL, the JSH cannot validate the session ID. 1533 ERROR: Sending of reply of close protocol failed. Description Jolt protocol failure. Action Check the client. 1534 ERROR: Sending of reply of reconnect protocol failed. Description Jolt protocol failed. Action Check the client.
1539 ERROR: Failed to decrypt reconnect information. Description Jolt protocol failure. Action Restart the client. 1540 ERROR: Failed to encrypt reconnect information. Description Jolt protocol failure. Action Restart the client. 1541 ERROR: Received RECONNECT request for nonTRANSIENT client. Description Improper request from client. Action Restart the client. 1542 ERROR: Unlicensed Jolt server. Description The JSL is not licensed.
NonStopTM TUXEDO 6.0 or earlier. Action Install NonStopTM TUXEDO 6.1 or 6.2 or check to ensure that your NonStopTM TUXEDO release is 6.1 or 6.2. 1546 WARN: The version of this TUXEDO is not available; is assumed. Description The MIB is supported with this version of NonStopTM TUXEDO, but the release number is unavailable. The NonStopTM TUXEDO version might not be a master binary. It might also be an internal version of NonStopTM TUXEDO. Action No action is required.
1552 WARN: Dropping notification message for Transient client %d. Description Notification arrived when a transient client is not connected. Action Information message only; no action required. 1553 WARN: Dropping broadcast message for Transient client %d. Description Notification arrived when a transient client is not connected. Action Information message only; no action required. 1554 ERROR: Expected numeric argument for -Z option. Description -Z option expects 0, 40, or 128 as the argument.
1559 ERROR: %s - Illegal argument to -E option. Description Incorrect value is specified as argument to -E option. Action Specify the correct option. 1560 ERROR: Cannot initialize the code conversion for local %s. Description Cannot find function to do the code conversion for internationalization. Action Check the shared library. 1561 ERROR: TUXDIR is not set. Description TUXDIR environment variable is not set. Action Set the variable to NonStopTM TUXEDO directory and restart NonStopTM TUXEDO.
ERROR: Not enough memory Description Not enough memory; add more swap space. Action Configure additional memory. Make sure the operating system parameters are set correctly for the amount of memory on the machine and the amount of memory that can be used by a process. Reduce the memory usage on the machine or increase the amount of physical memory on the machine.
Description A buffer was passed to an FML function that has not been initialized. Action Use Finit to initialize a buffer allocated directly by the application, or use Falloc to allocate and initialize a fielded buffer. ERROR: Invalid argument to function. Description An invalid argument (other than an invalid field buffer, field identifier, or field type) was passed to an FML function. This can be a parameter where a non-NULL parameter was expected (for example, it can be an invalid buffer size, and so on.
1008 ERROR: Could not establish listening address on network. Description This error occurs if the JSH or the JSL cannot advertise its listening address on the network. This could happen because of one of the following condition: ● The format of the address supplied to the JSL is incorrect. If the address format is incorrect, the network provider will be unable to advertise the address and the request fails. ● The address used in the -n command line option to the JSL is already in use by another process.
1081 ERROR: Error servicing network event. Description The JSL was unable to process a network event. Action This error indicates an internal problem with the JSL or the LIBNET software. Contact your service provider. 1101 ERROR: Bad hex number provided for listening address: %s. Description The JSL process was invoked with a -n option that specified a hexadecimal value as an option-argument. However, the value specified was not a valid hexadecimal constant.
any of the TCP ports in the range. The Jolt listener could not bind to the given address. Action If there are more Jolt handlers than ports available in the range specified by -p and -P, then a new handler will not be able to bind to any of the TCP ports in the allowable range. Do not forget about the TCP port which is used by the workstation listener as well. Increase the range specified by the -p and -P options. Make sure that address is correct. 1500 ERROR: Needs both -l -c options with arguments.
1506 ERROR: Connection to JSL failed. Description JSL is not running. Action Check the address given with option -c. 1507 ERROR: Sending message to JSL failed. Description JSL is not running or the network connection is down. Action Restart the JRAD/JSL. 1508 INFO: Sending message to JSH failed. Description Network is down. Connection to the JSH failed. Action Check the network and restart the JSL. 1509 ERROR: Sending CONNECT reply to JRLY. Description Unable to reach JRLY.
Description Memory allocation failed. The relay will exit. Action Make more memory available on the machine on which the relay is running. Remove other unnecessary processes that may be running on the same host as the relay. Restart the relay. ERROR: Client structure != NULL for file descriptor %ld Description An internal error occurred. The relay will continue to run, but a client process may have been disconnected. Action None.
Action Verify the entry for the tag LISTEN in the configuration file. Check that the correct configuration file is being used (-f parameter). ERROR: No JRAD port specified or JRAD port <= 0. Description The value for the CONNECT tag does not contain a valid port number on the relay host. Action Verify the entry for the tag CONNECT in the configuration file. Check that the correct configuration file is being used (-f parameter).
ERROR: Error on line %d: %s value is null Description A value is expected for this keyword. Action Input the value. ERROR: Error on line %d: Invalid keyword: %s=%s Description Keyword is not recognized. Action Input the correct keyword value. ERROR: Error on line %d: Invalid number: %s Description The numeric number is malformed. Action Input the correct value. ERROR: Error on line %d: Invalid value: %s Description The value of the parameter is out of range. Action Input the correct value.
Index A ADDRESS parameter, configuring for 53 Applets deploying 142/143 localizing 144 overview of Jolt support for 27 relationship to applications 102 Applications, design Java, relationship to applets 102 Jolt, enabling for 29 Applications, programming deployment and localization 142/144 Jolt class library, using 101/144 JoltBeans, using custom GUI elements 183 JoltBeans, using TUXEDO event subscription and notification 149 JoltBeans, using with transactions 183 multithreaded, Jolt support for 128/132 ASP
C CARRAY buffer type tryOnCARRAY.
E ECHO service, defining 115 Encryption configuring for Jolt 43 support for 43 encryption 43 Error handling Jolt class library overview 102 Event notifications connection modes supported 134 data buffers for 134 enabling unsolicited 134 example code for receiving 136 handle for 133 TUXEDO and JoltBeans support 149 types supported 133 using with TUXEDO 135 Event subscription configuring Jolt for 50 Jolt description 50, 133/137 TUXEDO and Jolt support comparison 135 TUXEDO and JoltBeans support 149 Exporting
using 116/122 FML (Field Manipulation Language) system messages 221 G GROUPNAME parameter configuring for JSL 53 GROUPS section JREPSVR 48 JSL 53 GRPNO parameter configuring for JREPSVR 48 H Help Jolt repository editor 98 troubleshooting jbld application 65 HTTP servlet advantages of 185 definition of 185 I Information messages 222 Installing Jolt 31 Internet and Intranet services 20 J Java applets, deploying 142/143 applets, localizing 144 applications vs.
definition of 146 JavaSoft appletviewer starting repository editor 69 jbld application description of 61 getting started 61/62 keyword order 63 keywords for service definitions 63 keywords, using parameter-level 65 keywords, using service-level 64 sample data for 65 syntax of data files 62/65 system messages 231 troubleshooting 65 Jolt See also jbld application applets, support for 27 architecture 23 bulk loadingTUXEDO services 61/66 client/server communication between 26 client/server interaction 104 clien
description of 152 Jolt Aware Bean definition of 146 Jolt Aware GUI Beans, definition of 147 Jolt class library application deployment and localization 142/144 applications, multithreaded 128/132 buffer types, using 110/127 classes for event subscription 133 description of 20 error and exception handling 102 error and exception methods 207/208 event subscription and notifications 133/137 functions, description of 106 how to use, walk-through 107/109 logon/logoff functions 106 object hierarchy 105 objects, r
overview 27 package organizer 86 packages, adding 79 packages, deleting 91 packages, description of 74/75 parameters, adding 83 parameters, deleting 91 parameters, modifying 89 process flow 73 saving your work 78 services, adding 80/?? services, deleting 91 services, description of 75 services, exporting and unexporting 92 services, modifying 89 services, testing 95/98 services, viewing export status 93 starting 69 troubleshooting 98 Jolt server components of 24 overview of functions 26 Jolt Server Listener
overview 145 properties, modifying 154 transactions, using with 183 TUXEDO event subscription and notification, using 149 JoltBeans class library how to use, walk-through 155 Java form example applet for BANKAPP 155 JoltBeans repository, using 180 JoltBeans Toolkit, definition of 147 JoltCheckbox aware AWT bean description of 153 Property List required input 180 JoltChoice aware AWT bean description of 154 Property List required input 180 JoltLabel aware AWT bean description of 153 Property List required in
definition of 133 description of 103 example asychronous notification 136 JoltSessionAttributes class example using 109 steps in beginning a transaction 104 JoltSessionBean bean description of 150 properties of 151 Property List required input 180 JoltTextField aware AWT bean description of 153 Property List required input 180 JoltTransaction class description of 103 JoltUserEvent class definition of 133 example asychronous notification 136 JoltUserEventBean bean description of 152 properties of 152 Propert
jrepository file 49 system messages 219/221 JRLY (Jolt relay) process component of Jolt internet relay 20 configuring 38, 45 configuring network addresses 47 description of 43/45 description of functions 28 starting 45 system messages 228/231 JSH (Jolt server handler) component of Jolt server 24 configuring minimum/maximum per JSL 41 JSL (Jolt server listener) component of Jolt server 24 configuring 40/43 configuring network addresses 47 starting 40 L Libraries, Jolt class 20 LMID parameter, configuring fo
JRLY 228/231 Multiplexing, configuring for JSH 43 Multithreaded applications 128/132 N NAME parameter, configuring for 53 Networks configuring addresses for Jolt 47 JSL address 42 JSL external address for Jolt clients 41 Non-preemptive threads 129 Notification event handler 133 O Objects extending, example of 139/142 reusing parameter values, example of 137 P Package organizer, Jolt repository editor 86 Packages window, Jolt repository editor 74 Packages, Jolt repository editor See Jolt respository edito
Property Editor using 154 R Repository Editor exiting the 37 starting from Web server 35 reuseSample.
HTTP 185 ServletSessionPool 187 ServletSessionPoolManager 187 Servlets, HTTP, writing and registering 187 SIMPAPP sample application PASSFML service, defining 119 TOUPPER service, defining 111 simpview.c sample application code for 126 VIEW service, defining 124 simpview.java sample application code for 123 VIEW service, defining 124 SimXfer.
T ThreadBank.java sample application 130/132 Threads, multithreaded applications in 128/132 Thread.yield method 129 Timeouts configuring JSH 42 configuring JSL 41 TMUSREVT server, configuring for Jolt 50 TOUPPER service 111 ToUpper.
Transactions begin, commit, rollback support by Jolt 107 Troubleshooting jbld application 65 Jolt repository editor 98 tryOnCARRAY.java sample client 115 tryOnFml.c sample server 120 tryOnFml.
example of 163 wiring, definition of 147
