Jolt 1.2 & JoltParam class

I'm trying to decode the returned int value from the getType() method within
the JoltParam class. It returns some large integer value defined somewhere
in
the bowels of Jolt land to denote whether a given field is of type string,
float, integer
etc. Where are these defined values? Are they published anywhere?
You're supposed to use the int values vs the pt= entry in the jrepository
according to the docs.
Anybody done this?
Thx.
Wendell

I think I have a solution...
shift the integer value to the right 24 bits and then do a switch against
the remainder.
Will this work safely?
Thx.
Wendell
"Wendell MacKenzie" <[email protected]> wrote in message
news:[email protected]..
I'm trying to decode the returned int value from the getType() methodwithin
the JoltParam class. It returns some large integer value definedsomewhere
in
the bowels of Jolt land to denote whether a given field is of type string,
float, integer
etc. Where are these defined values? Are they published anywhere?
You're supposed to use the int values vs the pt= entry in the jrepository
according to the docs.
Anybody done this?
Thx.
Wendell

Similar Messages

How to return jolt connection back to the joltpool?

hi
I used following codes to get joltconnection pool:
SessionPool sessionPool = sessionPoolManager.getSessionPool(poolName);
     DataSet request = new DataSet(requestString.length()*2);
     request.setValue("STRING", requestString);
     Result result = sessionPool.call(serviceName, request, null);
     return (String) result.getValue("STRING", null);
my question is : how to return jolt connection back to the joltpool? do I need
to do that?
when I used jdbc connection pool, I used conn.close() to return
to jdbc connection pool. Is there any method like "close()" in
jdbc connection?
Wei Jiang

Hi,
The below is the simple source code using Pool which it is extracted from
BEA's support web site.
and it is helpful.
The Pool doesn't need to return jolt connection back to the joltpool.
because it is done by Pool Manager automatically.
import bea.jolt.*;
import bea.jolt.pool.*;
public class Pho2 {
public static void main(String argv[])
try
String[] adresses = new String[1];
adresses[0] = "//aglaia:7040";
// creation du manager et du pool par defaut
SessionPoolManager sessionPoolManager = new SessionPoolManager();
int i = sessionPoolManager.createSessionPool(adresses, null, 1, 3, new
UserInfo(), null);
SessionPool sessionPool = sessionPoolManager.getSessionPool(null);
DataSet dataset = new DataSet();
Result result=null;
dataset.setValue("rhaine","coucou");
try
result = sessionPool.call("TOUPPER", dataset, null);
catch(Exception Ex)
System.out.println("session");
Ex.printStackTrace();
System.out.println("dataset="+dataset);
System.out.println("result ="+result);
System.out.println("ApplicationCode="+(new
Integer(result.getApplicationCode())).toString());
catch(Exception Ex)
System.out.println(Ex.getMessage());
Hope this helps.
Mr, Ko.
"wei jiang" <[email protected]> wrote in message
news:[email protected]..
>
hi
I used following codes to get joltconnection pool:
SessionPool sessionPool = sessionPoolManager.getSessionPool(poolName);
DataSet request = new DataSet(requestString.length()*2);
request.setValue("STRING", requestString);
Result result = sessionPool.call(serviceName, request, null);
return (String) result.getValue("STRING", null);
my question is : how to return jolt connection back to the joltpool? do Ineed
to do that?
when I used jdbc connection pool, I used conn.close() to return
to jdbc connection pool. Is there any method like "close()" in
jdbc connection?
Wei Jiang

Problems in jolt 1.2 with weblogic 6.1

Hi,
I am trying configure a jolt pool connection on startup of weblogic server.
I am using weblogic 6.1, tuxedo 6.5 server y jolt 1.2.
JSL is started.
I have copy $WL_HOME/classes/bea/jolt/pool from weblogic 5.1 to weblogic 6.1
I have defined a jolt pool, a startup class and a shutdown class.
I have not any problem on weblogic startup:
<Jan 13, 2003 5:21:06 PM CET> <Info> <WebLogicServer> <Invoking startup class:
bea.jolt.pool.servlet.weblogic.PoolManagerStartUp.startup(poolname=simpapp,appaddrlist=//69.51.23.140:13398,failoverlist=//69.51.23.140:13414,minpoolsize=1,maxpoolsize=15)>
<Jan 13, 2003 5:21:07 PM CET> <Info> <WebLogicServer> <bea.jolt.pool.servlet.weblogic.PoolManagerStartUp
reports: Jolt Session Pool: simpapp initialized>
The problem is when a servlet try:
private SessionPoolManager b_mgr;
Environment env = new Environment();
Context ctx = env.getInitialContext();
b_mgr = (SessionPoolManager) ctx.lookup(SessionPoolManager.POOLMANAGER_NAME);
SessionPool session = (SessionPool) b_mgr.getSessionPool("simpapp");
The object session is always null.
Thx in advance

Shashi,
Tuxedo 6.5 needs a patch to run on later versions of Solaris or else the WSNAT_CAT:1008 or JOLT_CAT:1008 "Error: Could not establish listening address on network +netaddr+" message can occur.
The thread Could not establish listening address on network describes a similar problem with the WSL, and the ULOG in that thread also indicates "TUXEDO Version 6.5 SunOS 5.5.1".
Please obtain the latest rolling patch from Oracle support. (It would be even better to upgrade to a later release of Tuxedo, since Tuxedo 6.5 is past its end of life date on Solaris. Hopefully whatever compilation problems you are having with later Tuxedo releases can be resolved fairly easily.)
Regards,
Ed

URG! problem with wls 9.2. DynamicMBeanImpl Class no exists in weblogic.jar

Hi all,
I have a problem instalating in startupclass and shutdownclass to uses jolt connections.
Theses classes are PoolManagerStartUp and PoolManagerShutdown.
it looks like the problem is in the joltwls.jar library (it contains the classes previously mentioned, bea.jolt.pool.servlet.weblogic.PoolManagerStartUp and bea.jolt.pool.servlet.weblogic.PoolManagerShutdown)
These classes uses a method that is in weblogic.jar version 7.0 but not in weblogic.jar version 9.2.
the class that hasn´t been found is weblogic/management/internal/DynamicMBeanImpl
this is the log :
<Dec 20, 2008 6:29:27 PM CET> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: java.lang.NoClassDefFoundError: weblogic/management/internal/DynamicMBeanImpl
java.lang.NoClassDefFoundError: weblogic/management/internal/DynamicMBeanImpl
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:246)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.invokeClass(ClassDeploymentManager.java:253)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager.access$000(ClassDeploymentManager.java:54)
at weblogic.management.deploy.classdeployment.ClassDeploymentManager$1.run(ClassDeploymentManager.java:205)
Truncated. see log file for complete stacktrace
thanks in advance!!
Edited by: user5481292 on 20-dic-2008 10:21
Edited by: user5481292 on 20-dic-2008 10:37

Hi,
This missing classes can be found inside the JAR : *"E:\bea10_3_3\wlserver_10.3\server\lib\wseeclient.jar"* As well as inside *"E:\bea10_3_3\wlserver_10.3\server\lib\wls-api.jar"*
Thanks
Jay SenSharma
http://weblogic-wonders.com/weblogic/webservices/ (WebLogic Wonders Are Here)

Problem compiling class: "oracle/jdbc/jolt/jdbc/client/Drive

I have this message trying to make an ear file with JBoss for a J2EE Aplication. My application access the Oracle JDBC Driver. I've seen that the class OracleDirver has a relationship to this packet inside, but this packet is not in classes12.zip. I think that it can be a bug in the code of this class.
Did anybody had the same problem?

You need to set the THIRD_PARTY_JDBC_CLASSPATH to the location of the oracle jdbc drivers (classes12.zip etc). You can do this in a number of ways run the db_setup use kregedit to modify the registry or on the Solaris version edit the iasenv.ksh directly.

Performance degradation using Jolt ASP Connectivity for TUXEDO

We have a customer that uses Jolt ASP Connectivity for TUXEDO and is suffering
from a severe performance degradation over time.
Initial response times are fine (1 s.), but they tend to increase to 3 minutes
after some time (well, eh, a day or so).
Data:
- TUXEDO 7.1
- Jolt 1.2.1
- Relatively recent rolling patch installed (so no there are probably no JSH performance
issues and memory leaks as fixed in earlier patches)
The ULOG shows that during the night the JSH instances notice a timeout on behalf
of the client connection and do a forced shutdown of the client:
040911.csu013.cs.kadaster.nl!JSH.234333.1.-2: JOLT_CAT:1185: "INFO: Userid:
[ZZ_Webpol], Clientid: [AP_WEBSRV3] timed out due to inactivity"
040911.csu013.cs.kadaster.nl!JSH.234333.1.-2: JOLT_CAT:1198: "WARN: Forced
shutdown of client; user name 'ZZ_Webpol'; client name 'AP_WEBSRV3'"
This happens every 10 minutes as per configuration of the JSL (-T flag).
The customer "solved" the problem for the time being by increasing the connection
pool size on the IIS web server.
However, they didn't find a "smoking gun" - no definite cause for the problem.
So, it is debatable whether their "solution" suffices.
It is my suspicion the problem might be located in the Jolt ASP classes running
on the IIS.
Maybe the connection pool somehow loses connections over time, causing subsequent
users having to queue before they get served (although an exception should be
raised if no connections are available).
However, there's no documentation on the functioning of the connection pool for
Jolt ASP.
My questions:
1) What's the algorithm used for managing connections with Jolt ASP for TUXEDO?
2) If connections are terminated by a JSH, will a new connection be established
from the web server automatically? (this is especially interesting, because the
connection policy can be configured in the JSL CLOPT, but there's no info on how
this should be handled/configured by Jolt ASP connectivity for TUXEDO)
Regards,
Winfried Scheulderman

Hi,
For ASP connectivity I would suggest looking at the .Net client facility provided in Tuxedo 9.1 and later.
Regards,
Todd Little
Oracle Tuxedo Chief Architect

UTFDataFormatException in JOLT buffer

I would appreciate some tips on how to track down the cause to my problems with
fetching certain strings from my database from my Java client using Tuxedo and
JOLT.
When reading a certain 380 characters long string from the database, the client
crashes, and I get the following message in my Java console:
"bea.jolt.ServiceException: bea.jolt.JoltRemoteService(ServiceName).decodeCALL()
bea.jolt.MessageException: bea.jolt.BufException: java.io.UTFDataFormatException
at bea/jolt/JoltRemoteService.decodeCALL
at bea/jolt/JoltRemoteService.call"
I have tried to find faulty characters by fetching various substrings of the string,
but only the substring with characters 1 to 379 or the entire 380 characters long
string seems to cause the problem. A substring with, for instance, characters
350 to 380 does not cause any error.
I have tested my service with UD32, and it works fine. The problem seems to be
at the JOLT level. Although the string was once written using the client, it is
not possible to regenerate the error by writing the exact same string via the
keyboard into my client. I cannot see any illegal characters when looking at the
string using SQL commands.
When looking in the JOLT API, I only get some information about the MessageException.
The BufException is not visible in the API documentation. Why is that?
Please, could someone help? Where can I look for the cause to this problem?
Thank You!
/Fredrik Israelsson
Systems used:
Tuxedo 7.1
Java 1.2.something
Oracle 8.1.7

Hi,
I'm not sure where you are wanting to check the buffer. If it is on the Jolt side, i.e., Java client side, then you get use the JoltMessage class accessors to find out what is in the buffer. On the Tuxedo side (JSL/JSH side) the handling of the buffers is done by C code, not Java and the protocol is not documented. There is no code in the JSH that does what you want, as it doesn't process the buffer in the same format as the Java side.
Can you explain a little more about what it is you are trying to accomplish?
Regards,
Todd Little
Oracle Tuxedo Chief Architect

Where is the jar file to have jolt.pool.*

hi,
where to find the jar files that have
bea.jolt.pool.DataSet;
bea.jolt.pool.Result;
bea.jolt.pool.SessionPool;
bea.jolt.pool.SessionPoolManager;
Do

If you are using Tuxedo 7.1 or 8 (or Tuxedo 6.x+Jolt), you should find
it in joltjse.jar under $TUXDIR/udataobj/jolt.
If you are using WLS 5.1, you should find in under
$WL_HOME/classes/bea/jolt/pool or in the service pack jar.
_shailesh
wei jiang wrote:
hi,
where to find the jar files that have
bea.jolt.pool.DataSet;
bea.jolt.pool.Result;
bea.jolt.pool.SessionPool;
bea.jolt.pool.SessionPoolManager;
Do

Problem using jolt function checkAuthentication. chkauth:J_CHECKAUTH FAILED

Hi, I'm using jolt 8.1.
When I attemp to chek security requirements using the function checkAuthenticationLevel() of the class JoltSessionAttributes it gives an error.
I have previously setted the address:
JoltSessionAttributes = new JoltSessionAttributes();
sattr.setString(JoltSessionAttributes.APPADDRESS, "//50.88.43.237:6005");
sattr.checkAuthenticationLevel();
Then it fails:
bea.jolt.SessionException: Cannot connect to any //50.88.43.237:6005.
Reason:NwHdlr: Network Error: chkauth: J_CHECKAUTH FAILED
Any idea? thx.

Hi,
I was facing a similiar problem but when i changed the port number it didnot give me this error but now its giving me bea.jolt.ServiceException:Service is not available:GETKEYS.
Can you help me solve this

Jolt 1.2/Tuxedo 6.5

I'm working on Tuxedo 6.5/Jolt 1.2 in a Websphere 3.02 environment.
1. Problem with Transaction and Session pools
Our application retreives information from an Informix database through servlets. We've built a SessionPool in order to access our Tuxedo services, but without any transactional state. In fact, as we do not update the database, we didn't use transactions.
Our question is when is the user connection free and available for an other user, since the Reference Documentation API says a connection is free when the transaction commit's or rollbacks. As we don't use any transaction, we don't know when (and how) a connection is available for reuse. Must we wait the Tuxedo timeout? ....
And is there an easy way to free a connection (force a connection to be once again available)?
2. Jolt 1.2 release
We're working with the Jolt 1.2 release, as I already said. The reference API documentation says a class named ServiceInfo in bea.jolt.pool will retreive information on Tuxedo services (parameters, ...). Unfortunately, our jar file (joltjse.jar, 33Kb) doesn't have it. I'd like to use it to built my DataSets' automatically from an Array or a Vector.
Is it because our Jolt version is too old and because the 1.2 does not provide this class? Is it part of the 1.2.x release?
In this case, how can I get the right jar without having to install (and/or upgrade to) a new version of Jolt?
Thank you for your answers
TR.

Dear,
Could you please send Jolt 1.2<For AIX4.3> to me ?
Or tell me where I can find it.
Thanks anywhere.
Fogg wg

Any adverse effects from singleton classes?

We're trying to decide whether it is a good/bad/indifferent idea to use
singleton classes in various places in an application (servlets, session
EJBs, BMP entity EJBs), in a clustered environment. Our app designers
have a number of different potential uses in mind, such as storing some
rarely changed data, and localised caches. We're happy with the
restriction that they obviously wouldn't be replicated. However, we're
not sure about what other implications there might be, especially when
the thing is scaled up. Questions that spring to mind include:
- any inbuilt synchronisation that WL may do (if the singleton had to
dive off to a database to get some further info we wouldn't necessarily
want to have other callers to it synchronise at that point)
- the effect on the JVM if we tie up some of its virtual memory
- any other considerations
Note that they are considering using this technique in both the web app
and the ejbs (which will reside in different clusters).
Are there any guidelines available for the use of singletons,
particularly from a performance point of view?
Thanks
Chris

For caching in clustering, read only entity beans are best bet.
You must not bind a cach ( HashMap or soemthing) object in JNDI tree in
clustering. This could lead to mess as this binding is not cluster aware. You
might see conflict messages in your log file or your local bidning could fail
in one or other server depending upon timing.
Other than that as long as you don't have synchronization in singleton classes
that leads to deadlocks, there should not be a problem.
Viresh Garg
Principal Developer Relations Emgineer
BEA Systems
Larry Presswood wrote:
Well duno if this helps but their new Jolt Pool Manager is a singleton
class.
Also you could use JNDI as a data cache but be careful as it replicates
across
the cluster.
Chris Palmer wrote:
We're trying to decide whether it is a good/bad/indifferent idea to use
singleton classes in various places in an application (servlets, session
EJBs, BMP entity EJBs), in a clustered environment. Our app designers
have a number of different potential uses in mind, such as storing some
rarely changed data, and localised caches. We're happy with the
restriction that they obviously wouldn't be replicated. However, we're
not sure about what other implications there might be, especially when
the thing is scaled up. Questions that spring to mind include:
- any inbuilt synchronisation that WL may do (if the singleton had to
dive off to a database to get some further info we wouldn't necessarily
want to have other callers to it synchronise at that point)
- the effect on the JVM if we tie up some of its virtual memory
- any other considerations
Note that they are considering using this technique in both the web app
and the ejbs (which will reside in different clusters).
Are there any guidelines available for the use of singletons,
particularly from a performance point of view?
Thanks
Chris

Connection recv error in jolt connection

Hi,
We have Java GUI client connecting to the Tuxedo server thru Jolt.
When we try to do some operation that connects to server after the GUI is idle for a about an hour we get Jolt error "Connection recv error" , sometimes we also get the error "Connection send error".
Wanted to know what causes this error, we are connecting the GUI in RETAINED mode option.
I could not get much in edocs on this, please let me know anyone encountered such problem and what really causes to throw this error.
I have pasted the error below:
bea.jolt.TransactionException: Connection recv error\nbea.jolt.SessionException: Connection recv error\nbea.jolt.JoltException: [6] NwHdlr.recv(): Network Error\njava.net.SocketException: Connection reset
     at bea.jolt.JoltTransaction.begin(JoltTransaction.java:337)
     at bea.jolt.JoltRemoteService.call(JoltRemoteService.java:278)
     at bea.jolt.JoltRemoteService.call(JoltRemoteService.java:257)
Thanks
gowardhan

Hi Gowardhan,
My comments are in line.
Wayne
Gowardhan Reddy wrote:
Hi Wayne,
Thanks for your reply.
The disconnect seems to be happening due to network problem.
Can you please help us understand the difference between a connection recv and connection send error? When we get a recv error does that mean a message was sucessfully sent to the server and the error was in receiving the response? [Wayne] I assume you use "call" method of JoltRemoteService class. This
method encapsulates send and recv action in a try{} block. So whether
send or recv throw exceptions depends on when the connection
disconnected. I guess most exceptions were regarding send. When a recv
error happens, I think the message was sent successfully except some
rare situation, that is message transmission seems OK for client, but at
that time the network disconnected.
We tried with ANY option and the problem doesnt seem to happen when we connect with -j ANY option. We have a range of 50 ports reserved for Jolt connection and network maybe dropping the idle connections.
What is difference in using -T option with ANY or just the RETAINED option, as it looks using ANY option without -T specified is same as RETAINED option. Will the server be able to push/connect to GUI in case of ANY option after the timeout value is reached?[Wayne] I think -T option will override the RETAINED option. That is to
say even you give a retained mode for connection, -T may also disconnect
the clients in a specified idle time. But if the client is closed due to
inactive timeout, JSH should have some message in ULOG like "... timed
out due to inactivity".
There is no error logged in ULOG.
Thanks
Gowardhan

How to run a sample Jolt client

Can any one explain me how to run a sample jolt client.
Iam trying to run the following jolt client code ToUpper.java at the command prompt but I am getting the following error.I am getting the same error when i run the Jrepository Applet RE.html.
D:\ToUpper>javac ToUpper.java
D:\ToUpper>java ToUpper
bea.jolt.SessionException: Cannot connect to any //localhost:3050.
Reason:NwHdlr: Network Error: chkauth: J_CHECKAUTH FAILED
at bea.jolt.JoltSessionAttributes.getDomainInfoJoltSessionAttributes.java:584)
at bea.jolt.JoltSessionAttributes.checkAuthenticationLevel(JoltSessionAttributes.java:507)
at ToUpper.main(ToUpper.java:20).
I have the tlistener running and provided apppassword and userpassword as my System login password where I have the complete Tuxedo Installation(server and client). Please see the attached sample jolt client program I am trying to run. I am not sure what configuration Settings I need to do.
ToUpper.java
/* Copyright 1996 BEA Systems, Inc. All Rights Reserved */
import bea.jolt.*;
public class ToUpper
public static void main (String[] args)
JoltSession session;
JoltSessionAttributes sattr;
JoltRemoteService toupper;
JoltTransaction trans;
String userName=null;
String userPassword=null;
String appPassword=null;
String userRole="myapp";
String outstr;
          try{
sattr = new JoltSessionAttributes();
sattr.setString(sattr.APPADDRESS, "//GVC3ZA03TESTING:3050");
switch (sattr.checkAuthenticationLevel())
case JoltSessionAttributes.NOAUTH:
break;
case JoltSessionAttributes.APPASSWORD:
appPassword = "123456"//"appPassword";
break;
case JoltSessionAttributes.USRPASSWORD:
userName = "myname";
userPassword = "123456";
appPassword = "123456";
break;
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.exit(0);
          }catch(Exception e){
          e.printStackTrace();
} // end main
} // end ToUpper

Hi Todd,
I am not getting the jcheckauthentication error now as i changed the port no. to the port where JSL is running.Now I am getting this error.Also find the ULOG contents pasted below.
D:\bea\tuxedo9.1\samples\jolt\ToUpper>java ToUpper
Authentication Level set To :0
Exception caught error no is:6
bea.jolt.ServiceException: TPENOENT - no entry found
at bea.jolt.JoltRemoteService.decodeCALL(JoltRemoteService.java:460)
at bea.jolt.JoltRemoteService.call(JoltRemoteService.java:345)
at bea.jolt.JoltRemoteService.call(JoltRemoteService.java:267)
at ToUpper.main(ToUpper.java:39)
I have checked the jrepository file and also the Applet window for the service defination(TOUPPER)but still its not recognizing the service.Is there some configuration thing I have missed out before running JOLT client.
ULOG File Contents
132947.GVC3ZA03TESTING!JSH.4000.2464.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
132956.GVC3ZA03TESTING!WSL.432.5308.0: WSNAT_CAT:1196: INFO: Terminating handlers in preparation for shutdown
132956.GVC3ZA03TESTING!WSL.432.5308.0: WSNAT_CAT:1197: INFO: Exiting system
132956.GVC3ZA03TESTING!JSL.2644.2356.0: JOLT_CAT:1506: "INFO: Terminating Jolt administration services in preparation for shutdown"
132956.GVC3ZA03TESTING!JSL.2644.2356.0: JOLT_CAT:1196: "INFO: Terminating handlers in preparation for shutdown"
132956.GVC3ZA03TESTING!JSH.4000.2464.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'jolt'; client name 'joltadmin'"
132956.GVC3ZA03TESTING!JSL.2644.2356.0: JOLT_CAT:1197: "INFO: Exiting system"
132956.GVC3ZA03TESTING!DMADM.5844.5348.0: CMDGW_CAT:1655: INFO: DMADMSVR is exiting
132959.GVC3ZA03TESTING!BBL.3216.4372.0: CMDTUX_CAT:26: INFO: The BBL is exiting system
133021.GVC3ZA03TESTING!tmloadcf.6104.3164.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
133021.GVC3ZA03TESTING!tmloadcf.6104.3164.-2: CMDTUX_CAT:872: INFO: TUXCONFIG file D:\bea\tuxedo9.1\samples\jolt\ToUpper\tuxconfig has been updated
133028.GVC3ZA03TESTING!BBL.6140.5124.0: 02-01-2007: Tuxedo Version 9.1, 32-bit, Patch Level (none)
133028.GVC3ZA03TESTING!BBL.6140.5124.0: LIBTUX_CAT:262: INFO: Standard main starting
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: LIBTUX_CAT:262: INFO: Standard main starting
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: CMDGW_CAT:3149: INFO: BDMCONFIG environment variable not set. Using $APPDIR/BDMCONFIG
133028.GVC3ZA03TESTING!DMADM.4928.1868.0: CMDGW_CAT:3761: INFO: Using version 2 BDMCONFIG, 3DES is enabled.
133028.GVC3ZA03TESTING!JSL.5608.6088.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133028.GVC3ZA03TESTING!JSL.5608.6088.0: LIBTUX_CAT:262: INFO: Standard main starting
133028.GVC3ZA03TESTING!JSL.5608.6088.0: INFO: JOLT Listener version-BEA Jolt 9.1
133028.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1563: "INFO: Serial Number : <454493271161-2140437240256>, Expiration Date : <2007-02-15>"
133028.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1564: "INFO: Licensee : <BEA Evaluation Customer>"
133029.GVC3ZA03TESTING!JSH.6028.5748.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1030: "INFO: Jolt Handler joining application"
133029.GVC3ZA03TESTING!JSH.6028.5748.-2: INFO: JOLT Handler version-BEA Jolt 9.1
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: LIBTUX_CAT:262: INFO: Standard main starting
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: Current version: BEA Jolt 9.1
133029.GVC3ZA03TESTING!JREPSVR.3476.4980.0: Repository "D:\bea\tuxedo9.1\udataobj\jolt\repository\jrepository" (16 records) is writable.
133029.GVC3ZA03TESTING!WSL.3292.4892.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!WSL.3292.4892.0: LIBTUX_CAT:262: INFO: Standard main starting
133029.GVC3ZA03TESTING!WSH.2568.3772.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!WSH.2568.3772.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
133029.GVC3ZA03TESTING!WSH.5764.3836.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
133029.GVC3ZA03TESTING!WSH.5764.3836.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
133242.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
133300.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
133300.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
133359.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
133456.GVC3ZA03TESTING!JSH.6028.5748.-2: Fldid32(ACCOUNT_ID) failed for INQUIRY: LIBFML_CAT:8: ERROR: Unknown field name. Maybe FIELDTBLS32 is not set properly.
133612.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
143325.GVC3ZA03TESTING!JSH.6028.5748.-2: Fldid(SAMOUNT) failed for DEPOSIT: LIBFML_CAT:11: ERROR: Cannot find or open field table. Maybe FIELDTBLS is not set properly.
144116.GVC3ZA03TESTING!WSL.3292.4892.0: WSNAT_CAT:1196: INFO: Terminating handlers in preparation for shutdown
144116.GVC3ZA03TESTING!WSL.3292.4892.0: WSNAT_CAT:1197: INFO: Exiting system
144116.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1506: "INFO: Terminating Jolt administration services in preparation for shutdown"
144116.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1196: "INFO: Terminating handlers in preparation for shutdown"
144116.GVC3ZA03TESTING!JSH.6028.5748.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'jolt'; client name 'joltadmin'"
144116.GVC3ZA03TESTING!JSL.5608.6088.0: JOLT_CAT:1197: "INFO: Exiting system"
144116.GVC3ZA03TESTING!DMADM.4928.1868.0: CMDGW_CAT:1655: INFO: DMADMSVR is exiting
144119.GVC3ZA03TESTING!BBL.6140.5124.0: CMDTUX_CAT:26: INFO: The BBL is exiting system
144142.GVC3ZA03TESTING!tmloadcf.2668.3316.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144142.GVC3ZA03TESTING!tmloadcf.2668.3316.-2: CMDTUX_CAT:872: INFO: TUXCONFIG file D:\bea\tuxedo9.1\samples\jolt\ToUpper\tuxconfig has been updated
144148.GVC3ZA03TESTING!BBL.4144.4376.0: 02-01-2007: Tuxedo Version 9.1, 32-bit, Patch Level (none)
144148.GVC3ZA03TESTING!BBL.4144.4376.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: CMDGW_CAT:3149: INFO: BDMCONFIG environment variable not set. Using $APPDIR/BDMCONFIG
144148.GVC3ZA03TESTING!DMADM.4436.5968.0: CMDGW_CAT:3761: INFO: Using version 2 BDMCONFIG, 3DES is enabled.
144148.GVC3ZA03TESTING!JSL.5072.2444.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!JSL.5072.2444.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!JSL.5072.2444.0: INFO: JOLT Listener version-BEA Jolt 9.1
144148.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1563: "INFO: Serial Number : <454493271161-2140437240256>, Expiration Date : <2007-02-15>"
144148.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1564: "INFO: Licensee : <BEA Evaluation Customer>"
144148.GVC3ZA03TESTING!JSH.5856.5268.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1030: "INFO: Jolt Handler joining application"
144148.GVC3ZA03TESTING!JSH.5856.5268.-2: INFO: JOLT Handler version-BEA Jolt 9.1
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: Current version: BEA Jolt 9.1
144148.GVC3ZA03TESTING!JREPSVR.2952.1248.0: Repository "D:\bea\tuxedo9.1\udataobj\jolt\repository\jrepository" (16 records) is writable.
144148.GVC3ZA03TESTING!WSL.3040.5488.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!WSL.3040.5488.0: LIBTUX_CAT:262: INFO: Standard main starting
144148.GVC3ZA03TESTING!WSH.5740.2764.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!WSH.5740.2764.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144148.GVC3ZA03TESTING!WSH.1784.5448.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144148.GVC3ZA03TESTING!WSH.1784.5448.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144157.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144207.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
144226.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144229.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144518.GVC3ZA03TESTING!WSL.3040.5488.0: WSNAT_CAT:1196: INFO: Terminating handlers in preparation for shutdown
144518.GVC3ZA03TESTING!WSL.3040.5488.0: WSNAT_CAT:1197: INFO: Exiting system
144518.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1506: "INFO: Terminating Jolt administration services in preparation for shutdown"
144518.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1196: "INFO: Terminating handlers in preparation for shutdown"
144518.GVC3ZA03TESTING!JSH.5856.5268.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name 'jolt'; client name 'joltadmin'"
144518.GVC3ZA03TESTING!JSL.5072.2444.0: JOLT_CAT:1197: "INFO: Exiting system"
144519.GVC3ZA03TESTING!DMADM.4436.5968.0: CMDGW_CAT:1655: INFO: DMADMSVR is exiting
144522.GVC3ZA03TESTING!BBL.4144.4376.0: CMDTUX_CAT:26: INFO: The BBL is exiting system
144537.GVC3ZA03TESTING!tmloadcf.4892.4980.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144537.GVC3ZA03TESTING!tmloadcf.4892.4980.-2: CMDTUX_CAT:872: INFO: TUXCONFIG file D:\bea\tuxedo9.1\samples\jolt\ToUpper\tuxconfig has been updated
144543.GVC3ZA03TESTING!BBL.5440.4548.0: 02-01-2007: Tuxedo Version 9.1, 32-bit, Patch Level (none)
144543.GVC3ZA03TESTING!BBL.5440.4548.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: CMDGW_CAT:3149: INFO: BDMCONFIG environment variable not set. Using $APPDIR/BDMCONFIG
144543.GVC3ZA03TESTING!DMADM.1016.6128.0: CMDGW_CAT:3761: INFO: Using version 2 BDMCONFIG, 3DES is enabled.
144543.GVC3ZA03TESTING!JSL.1796.5232.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!JSL.1796.5232.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!JSL.1796.5232.0: INFO: JOLT Listener version-BEA Jolt 9.1
144543.GVC3ZA03TESTING!JSL.1796.5232.0: JOLT_CAT:1563: "INFO: Serial Number : <454493271161-2140437240256>, Expiration Date : <2007-02-15>"
144543.GVC3ZA03TESTING!JSL.1796.5232.0: JOLT_CAT:1564: "INFO: Licensee : <BEA Evaluation Customer>"
144543.GVC3ZA03TESTING!JSH.3164.4076.-2: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1030: "INFO: Jolt Handler joining application"
144543.GVC3ZA03TESTING!JSH.3164.4076.-2: INFO: JOLT Handler version-BEA Jolt 9.1
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: Current version: BEA Jolt 9.1
144543.GVC3ZA03TESTING!JREPSVR.860.2916.0: Repository "D:\bea\tuxedo9.1\udataobj\jolt\repository\jrepository" (16 records) is writable.
144543.GVC3ZA03TESTING!WSL.2596.4404.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!WSL.2596.4404.0: LIBTUX_CAT:262: INFO: Standard main starting
144543.GVC3ZA03TESTING!WSH.3508.5136.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!WSH.3508.5136.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144543.GVC3ZA03TESTING!WSH.4288.5676.0: 02-01-2007: Tuxedo Version 9.1, 32-bit
144543.GVC3ZA03TESTING!WSH.4288.5676.0: WSNAT_CAT:1030: INFO: Work Station Handler joining application
144548.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"
144634.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1198: "WARN: Forced shutdown of client; user name ''; client name 'myapp'"
144734.GVC3ZA03TESTING!JSH.3164.4076.-2: JOLT_CAT:1043: "ERROR: tpacall() call failed, tperrno = 6"

Jolt STRING local character set

Our application sends data containing non-latin characters in FML32 STRING fields. What I found in documentation is:
For localization, the Jolt Class Library package relies on the conventions of the Java language and the Oracle Tuxedo system. Jolt transfers Java 16-bit Unicode characters to the JSH. The JSH provides a mechanism to convert Unicode to the local character set.
So how does JSH know the "local character set"?

tutti_frutti:
You may want to use the following:
String input = textfield.getText();
int len = 0;
char curr_char;
if(input != null) {
    len = input.length();
    for( int i = 0; i < len; i++) {
        curr_char = input.charAt(i);
        if(Character.UnicodeBlock.of(curr_char) == Character.UnicodeBlock.ARABIC) {
            // Do something
        else if(Character.UnicodeBlock.of(curr_char) == Character.UnicodeBlock.BASIC_LATIN) {
            // Do some other thing
}

Calling Tuxedo Service using BEA Jolt.

I'm trying to call Tuxedo service from java stored procedure using BEA JOLT.My normal java client works fine but when i use the same client as java stored procedure i get following error message :
can not connect to any //lucy:9021(host:port)
Reason:Nwhdlr:can not open socket
I've successfully loaded all required JOLT jar files using loadjava and created the procedure successfully .Java code is given below :
import bea.jolt.*;
import java.sql.*;
public class JoltToTux
     public static void callTuxService() throws Exception
          JoltSession session;
          JoltSessionAttributes sattr;
          JoltRemoteService toupper;
          JoltTransaction trans;
          String userName=null;
          String userPassword=null;
          String appPassword=null;
          String userRole=null;
          String outstr;
          try {
          sattr = new JoltSessionAttributes();
          sattr.setString(sattr.APPADDRESS, "//lucy:9021");
          sattr.setInt(sattr.IDLETIMEOUT, 300);
          session = new JoltSession(sattr, userName, userRole,userPassword, appPassword);
                    toupper = new JoltRemoteService ("CB_EXESUB", session);
          toupper.setString("CLFY_SUB", "PingSrvr");
          toupper.call(null);
          System.out.println( "Call to Tuxedo complete" );
          outstr = toupper.getStringDef("WF_MESSAGE","" );
          System.out.println("return string : " + outstr);
                    session.endSession();
          System.exit(0);
          } //end of try
          catch (Exception e) {
               // System.err.println(e.getMessage());}
               e.printStackTrace();
     } // end main
     public static void main( String args[] ) {
          try {
               JoltToTux jt = new JoltToTux();
               jt.callTuxService();
          catch ( Exception e0 ) {
               e0.printStackTrace();
} // end ToUpper
thanks
anurag

Ams,
You can't do that with JOLT. You will need to use the WTC product,
currently in beta - see WTC Questions and Answers
Regards,
Peter.
Got a Question? Ask BEA at http://askbea.bea.com
The views expressed in this posting are solely those of the author, and
BEA
Systems, Inc. does not endorse any of these views.
BEA Systems, Inc. is not responsible for the accuracy or completeness of
the
information provided
and assumes no duty to correct, expand upon, delete or update any of the
information contained in this posting.
Ams wrote:
Hi Manoj,
I want to call a tuxedo service and also want to update
database (using entity beabs) in same transaction so I
can't use AUTOTRAN , Am I right ?
I am using bea.jolt.pool.SessionPool's startTransaction
method to start a transaction and passing this
to SessionPool's call method.
Ams.
"Manoj SASIDHARAN" <[email protected]> wrote:
Hello Ams,
Could u plz give more information abt the usage scenario. Another way
to test
would be to put AUTOTRAN=Y for the service in question.
HTH
regards
MS
"Ams" <[email protected]> wrote:
Hi,
I am calling Tuxedo service from ejb using jolt.
I want the service call in transaction started in ejb.
I am getting following error.
LIBTUX_CAT:481: ERROR: Service xa_start returned -7
Does jolt support transaction ?
Ams
[att1.html]

Jolt 1.2 & JoltParam class

Similar Messages

Maybe you are looking for