TUXEDO 8.1 Patches
Can somebody tell me where I can get the latest patches from for TUXEDO 8.1 running
on AIX5.2 please? (In a hurry)
TIA
Nige...
Hi,
If you have a support contract from Oracle for your Tuxedo installation, you can contact Oracle support to obtain the patches, assuming they aren't already available on Metalink.
Regards,
Todd Little
Oracle Tuxedo Chief Architect
Similar Messages
-
Where can I download tuxedo 8.1 patches
I need some tuxedo patches for my speical application!
but I don't know where I can get them!
help me ! help me!Hi,
If you have a support contract from Oracle for your Tuxedo installation, you can contact Oracle support to obtain the patches, assuming they aren't already available on Metalink.
Regards,
Todd Little
Oracle Tuxedo Chief Architect -
Tuxedo 8.0 and Oracle patch 9.2.0.8
Hi,
We have installed Oracle patch 9.2.0.8 into UNIX machine. We are using Tuxedo for middleware that using an API Application through Tuxedo to provision onto Oracle database.
Since Oracle patch 9.2.0.8 installed, Tuxedo produced core file.
It has been mentioned by Oracle Metalink Doc ID 455832.1 that potentially because both server and client have to be in synch version. The Oracle patch has been installed on UNIX server for both
My question is that:
- Is there any Oracle client on Tuxedo (8.0) patch that need to be installed ?
- Or should we upgrade Tuxedo to later version, if yes which version that in synch with Oracle patch 9.2.0.8 ?
At the moment no workarround is applied.
Thank in advance for any info and help.
--AgeHi Todd,
Thank you for your usefull answer. I will take this point with our application's vendor.
Do you know if we would like to upgrade to a higher version or best to the latest 10gR3, is there any contact Support that we can contact to get software kit (weblink for download etc.). I am not sure the license contract agreement of our company, in parallel I would like to know the procedure from your side (Oracle Tuxedo).
Regards,
--Age -
Wrong translation commond when I write Tuxedo Service to use Informix Database
Old Environment:
DB : Informix Dynamic Server Version 7.31.UC5
Tools : INFORMIX-ESQL Version 7.24.UC8
MIDDLE : Tuxedo 6.4 patch 341
New Environment :
DB : Informix Dynamic Server Version 9.30.FC1
Tools : IBM Informix CSDK Version 2.80,
IBM Informix-ESQL Version 9.52.UC2
MIDDLE : Tuxedo 8.0 patch 135
Event :
My old tuxedo service had wroted to communicate with Informix Database by
XA transaction. In my service code have to
prepare informix statement by command
' EXEC SQL PREPARE p_roll FROM "ROLLBACK WORK" ' And in my old environment it's
workable until I upgrade my environment.
My old tuxedo service can compile in new environment but when i try to test
service by ud32 tool the result is error "A syntax error has occurred". After
I check my code and receive statement at Database host I found some thing does
not correct.
I send to prepare ' ROLLBACK WORK ' but at database host received ' ROLLBACK WORKRK"
' that unknown command to database.
I try to write my small new code to test PREPARE command of Informix ESQL/C
without to build to Tuxedo Server, It's can work correctly.
If you had found the same case , Please advise me too.
Thanks you very much for your advise.
[roll.ec]If ud32 reported a syntax error, then your service was never called.
Normally, a service running under XA control should not issue transactional SQL
statements. Begins and Rollbacks are issued from the transaction manager, not the
application code.
Can you post the Tuxedo message catalog number, and your ud32 script, as well as
your environment variables?
Scott Orshan
Sutep wrote:
Old Environment:
DB : Informix Dynamic Server Version 7.31.UC5
Tools : INFORMIX-ESQL Version 7.24.UC8
MIDDLE : Tuxedo 6.4 patch 341
New Environment :
DB : Informix Dynamic Server Version 9.30.FC1
Tools : IBM Informix CSDK Version 2.80,
IBM Informix-ESQL Version 9.52.UC2
MIDDLE : Tuxedo 8.0 patch 135
Event :
My old tuxedo service had wroted to communicate with Informix Database by
XA transaction. In my service code have to
prepare informix statement by command
' EXEC SQL PREPARE p_roll FROM "ROLLBACK WORK" ' And in my old environment it's
workable until I upgrade my environment.
My old tuxedo service can compile in new environment but when i try to test
service by ud32 tool the result is error "A syntax error has occurred". After
I check my code and receive statement at Database host I found some thing does
not correct.
I send to prepare ' ROLLBACK WORK ' but at database host received ' ROLLBACK WORKRK"
' that unknown command to database.
I try to write my small new code to test PREPARE command of Informix ESQL/C
without to build to Tuxedo Server, It's can work correctly.
If you had found the same case , Please advise me too.
Thanks you very much for your advise.
#include <stdio.h>
#define BUFF 30
#define SQLROWCOUNT sqlca.sqlerrd[2]
exec sql define LNGTH1 40;
main()
exec sql whenever sqlerror goto :sqlx;
exec sql begin declare section;
string hs_vlue_char[LNGTH1];
string hs_sql[500];
exec sql end declare section;
long li_line;
fprintf(stderr,"\nProcessing...\n");
exec sql connect to 'sysmaster@oltp';
li_line = __LINE__;
exec sql prepare bwork from "BEGIN WORK";
li_line = __LINE__;
exec sql prepare cwork from "COMMIT WORK";
li_line = __LINE__;
exec sql prepare rwork from "ROLLBACK WORK";
printf("%d: Before Rollback Work\n", __LINE__);
EXEC SQL PREPARE p_rwork FROM "ROLLBACK WORK";
/* free(hs_v[tmp]);
hs_v[tmp] = strfmt("%s", "rollback work");
CHECK_STRFMT_ERROR( hs_v, tmp);
debug("'%s'", hs_v[tmp]);
exec sql prepare p_rwork from :hs_v[tmp];
printf("%d: After Rollback Work\n", __LINE__);
printf("%d: Before Begin Work\n", __LINE__);
EXEC SQL PREPARE p_bwork FROM "BEGIN WORK";
printf("%d: After Begin Work\n", __LINE__);
printf("%d: Before Commit Work\n", __LINE__);
EXEC SQL PREPARE p_cwork FROM "COMMIT WORK";
printf("%d: After Commit Work\n", __LINE__);
sprintf(hs_sql, "SELECT vlue_char from cs_dfpm where dfpm_code = 'LOG_PATH_NAME1'");
printf("hs_Sql = %s\n", hs_sql);
exec sql prepare sel_sql from :hs_sql;
exec sql execute sel_sql into :hs_vlue_char;
printf("hs_vlue_char = %s\n", hs_vlue_char);
exec sql free sel_sql;
exec sql execute p_bwork;
exec sql
update cs_dfpm
set vlue_char = '/test/'
where dfpm_code = 'LOG_PATH_NAME1';
if ( SQLROWCOUNT == 0 )
exec sql execute p_rwork;
exec sql execute p_cwork;
exec sql free p_bwork;
exec sql free p_cwork;
exec sql free p_rwork;
exec sql disconnect current;
fprintf(stderr, "\nProcess completed successfully.\n");
return(0);
sqlx:
fprintf(stderr,"\nDB error encountered at line = %ld(%ld)\n", li_line, SQLCODE);
fprintf(stderr,"\nDB error encountered(%ld)\n", SQLCODE);
exec sql whenever sqlerror continue;
exec sql free sel_sql;
exec sql free p_bwork;
exec sql free cwork;
exec sql free rwork;
exec sql disconnect current;
printf("%s@%d:Process completed with Error.\n", __FILE__, __LINE__); -
Can't boot ap Server, in TUXEDO ver 8.0
Hi
We have tested the ap server(XA), in tuxedo 7.1 and the result is OK.
But we have tested the same ap server(XA), in tuxedo 8.0(tuxedo patch not
applied).
However, the following error is occurred in ulog.
ulog's output
165244.uclick!TEST2.13734.1.0: 05-30-2002: Tuxedo Version 8.0
165244.uclick!TEST2.13734.1.0: LIBTUX_CAT:262: INFO: Standard main starting
165244.uclick!TEST2.13734.1.0: LIBTUX_CAT:525: INFO: Default tpsvrinit()
function used
165244.uclick!TEST2.13734.1.0: LIBTUX_CAT:6205: WARN: Server initialization
function did not call tx_open() or tpopen() or this call failed
Why did it occur, in tuxedo 8.0 ?
Please tell me about it.
Thanks in advance.
Best Regards.It seems you may be hitting a bug that is already fixed in Tuxedo 8 rolling
patch. Apply rolling patch 34 or above and see if problem goes away.
-Deepak
"°í°æÇÐ" wrote:
Hi
We have tested the ap server(XA), in tuxedo 7.1 and the result is OK.
But we have tested the same ap server(XA), in tuxedo 8.0(tuxedo patch not
applied).
However, the following error is occurred in ulog.
ulog's output
165244.uclick!TEST2.13734.1.0: 05-30-2002: Tuxedo Version 8.0
165244.uclick!TEST2.13734.1.0: LIBTUX_CAT:262: INFO: Standard main starting
165244.uclick!TEST2.13734.1.0: LIBTUX_CAT:525: INFO: Default tpsvrinit()
function used
165244.uclick!TEST2.13734.1.0: LIBTUX_CAT:6205: WARN: Server initialization
function did not call tx_open() or tpopen() or this call failed
Why did it occur, in tuxedo 8.0 ?
Please tell me about it.
Thanks in advance.
Best Regards. -
Hi,
We have a performance situation where Tuxedo is favouring one MSSQ out of the
8 available across 2 boxes.
Our configuration is that we have 8 Tuxedo Servers each publishing 4 instances
of a particular E2A adapter service (a total of 32 instances of a particular service).
Each of the 8 Tuxedo Servers has its own MSSQ and there are 4 Tuxedo Servers on
each of the physical boxes. ie. 2 physical boxes.
When the aforementioned service is called it favours one particular Tuxedo in
a very odd manner.
TMIB output shows the Q depths as (typically):
Mon Sep 15 13:42:59 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 10
TA_MSG_QNUM 0
TA_MSG_QNUM 93
Mon Sep 15 13:43:04 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 11
TA_MSG_QNUM 0
TA_MSG_QNUM 92
Mon Sep 15 13:43:10 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 11
TA_MSG_QNUM 0
TA_MSG_QNUM 92
Does anyone know what might cause Tuxedo to bias like like this?
Significant ubb entries:
$ tmunloadcf |grep -e LDBAL -e MODEL
MODEL MP
LDBAL Y
$
Master is HP-UX. Slaves running the E2A's and MSSQ are NT.
NigelScott,
You are right, the assignment of an MSSQ per server makes no sense, we will change
it to have a single MSSQ per physical server, hopefully we won't get Message Q
blocking as a result (since we will now have only 25% of the previous Q space).
We are (by design) using uncontrolled tpacall. Yes, yes, I know...
For the record, we are on Tuxedo 6.5 (patch 389).
Thanks for your assistance. I'll let you know what happens when we reconfigure
the Q's.
Nigel
Scott Orshan <[email protected]> wrote:
I don't completely understand your configuration. MSSQ means
multi-server, single-queue, yet it sounds like each of your servers has
its own queue.
I think we need to see more about your service configuration. Do you
have the latest patches applied? You didn't sey what release you're
running, but there could have been a load balancing problem at some point.
Remember that Tuxedo cannot "see" remote queue lengths. For services
with equal load factor, it round-robins among the available queues. If
one of those adapter services takes longer, then its queue will build
up. Make sure that you are not using uncontrolled tpacall(TPNOREPLY)
calls, as that can easily flood the remote queues. You've got over 100
queued messages. Does that mean that you have 100 tpcalls waiting for
replies, or were 100 tpacalls done?
What might help is if you did use MSSQ. Set RQADDR the same for all
of
the servers on a machine (so long as they offer the identical set of
services). Then all requests will go to one queue, and be taken off as
quickly as they can be processed by the services. If one process gets
hung up, the rest will be able to continue processing.
For further control, you might have to use Routing or service naming
to
better direct the service calls.
Scott Orshan
Nigel wrote:
The attached file should be easier to read than the output in the originalmessage.
"Nigel" <[email protected]> wrote:
Hi,
We have a performance situation where Tuxedo is favouring one MSSQ
out
of the
8 available across 2 boxes.
Our configuration is that we have 8 Tuxedo Servers each publishing4
instances
of a particular E2A adapter service (a total of 32 instances of a particular
service).
Each of the 8 Tuxedo Servers has its own MSSQ and there are 4 Tuxedo
Servers on
each of the physical boxes. ie. 2 physical boxes.
When the aforementioned service is called it favours one particularTuxedo
in
a very odd manner.
TMIB output shows the Q depths as (typically):
Mon Sep 15 13:42:59 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 10
TA_MSG_QNUM 0
TA_MSG_QNUM 93
Mon Sep 15 13:43:04 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 11
TA_MSG_QNUM 0
TA_MSG_QNUM 92
Mon Sep 15 13:43:10 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 11
TA_MSG_QNUM 0
TA_MSG_QNUM 92
Does anyone know what might cause Tuxedo to bias like like this?
Significant ubb entries:
$ tmunloadcf |grep -e LDBAL -e MODEL
MODEL MP
LDBAL Y
$
Master is HP-UX. Slaves running the E2A's and MSSQ are NT.
Nigel
Mon Sep 15 13:42:59 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 10
TA_MSG_QNUM 0
TA_MSG_QNUM 93
Mon Sep 15 13:43:04 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 11
TA_MSG_QNUM 0
TA_MSG_QNUM 92
Mon Sep 15 13:43:10 EST 2003
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 0
TA_MSG_QNUM 11
TA_MSG_QNUM 0
TA_MSG_QNUM 92 -
Funny reactions to bugs in tpsvrdone (strange Tuxedo behaviour)
*** SAMPLE ***
Try the following funny experiment:
1) Write the tuxedo server which in tpsvrdone crashes somehow. Something
like
extern "C"
void tpsvrdone()
char *c = 0;
// Let's dump core...
*c = 'a';
2) Boot this server (and specify in tuxconfig RESTART=Y).
3) Try to shutdown it.
tmshutdown -s myserver
You will see something like
Server Id = 1 Group Id = mygroup Machine = mymachine:
(forever). After pressing Ctrl-C you will get
Interrupt Force to shutdown the process? (y/n):
and after choosing 'y' you will get
shutdown failed
The corresponding process still exists, the whole application can not be
shut down as there are active processes.
*** EXPLANATION ***
The exact scenario which happens is the following:
1) administrator calls tmshutdown,
2) Tuxedo accepts this and causes the server to call tpsvrdone
3) tpsvrdone causes SEGV, so the process crashes
4) (!!!!!!) As the server crashed, Tuxedo starts new instance of the server
5) Tuxedo calls tpsvrdone in the freshly started instance
6) Go to step 3) and repeat forever
What a great idea! If tpsvrdone fails, let's start new instance just to
shut it down..
More serously, in my opinion this is a bug, after the server is
requested to be shut down it should no more be restarted. And it causes
the real problem - you can not shutdown the application, you can not
install the new server version which corrects the bugs, ... (oh yes, you
can manually kill all the processes and ipcrm resources, if you use
multiple machines it starts to be real fun).
PS I use Tuxedo 7.1What patch level for Tuxedo 7.1 are you using? A problem was fixed sometime
ago that will cause restartsrv to schedule clean up of a server which has been
issued a shutdown command.
-Deepak
Marcin Kasperski wrote:
*** SAMPLE ***
Try the following funny experiment:
1) Write the tuxedo server which in tpsvrdone crashes somehow. Something
like
extern "C"
void tpsvrdone()
char *c = 0;
// Let's dump core...
*c = 'a';
2) Boot this server (and specify in tuxconfig RESTART=Y).
3) Try to shutdown it.
tmshutdown -s myserver
You will see something like
Server Id = 1 Group Id = mygroup Machine = mymachine:
(forever). After pressing Ctrl-C you will get
Interrupt Force to shutdown the process? (y/n):
and after choosing 'y' you will get
shutdown failed
The corresponding process still exists, the whole application can not be
shut down as there are active processes.
*** EXPLANATION ***
The exact scenario which happens is the following:
1) administrator calls tmshutdown,
2) Tuxedo accepts this and causes the server to call tpsvrdone
3) tpsvrdone causes SEGV, so the process crashes
4) (!!!!!!) As the server crashed, Tuxedo starts new instance of the server
5) Tuxedo calls tpsvrdone in the freshly started instance
6) Go to step 3) and repeat forever
What a great idea! If tpsvrdone fails, let's start new instance just to
shut it down..
More serously, in my opinion this is a bug, after the server is
requested to be shut down it should no more be restarted. And it causes
the real problem - you can not shutdown the application, you can not
install the new server version which corrects the bugs, ... (oh yes, you
can manually kill all the processes and ipcrm resources, if you use
multiple machines it starts to be real fun).
PS I use Tuxedo 7.1 -
Tuxedo Production Issue:LIBTUX_CAT:5005
Dear friends,
Problem : We getting the Tuxedo Error LIBTUX_CAT:5005 , in our Production Environment , frequently .
The Impact : Tuxedo Is not at all responding , even tmadmin/tmipcrm/tmshutdown commands are not responding .
Please help us to identify the root cause for this issue.
Here is the Details of our Tuxedo Production environment
TUXEDO MACHINE DETAILS
Tuxedo Version : TUXEDO 8.0
Patch : No Patch Applied
Operating System : AIX Version 5.3 level 04
oslevel -r : 5300-04
Oracle client : SQL*Plus: Release 9.2.0.3.0 - Production on Sat May 12 19:25:18 2007
System Model: IBM,9119-590
Processor Type: PowerPC_POWER5
Processor Clock Speed: 1654 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
Firmware Version: IBM,SF235_206
Paging Space Information
Total Paging Space: 4096MB
DATABASE MACHINE DETAILS .
Oracle Version : 10.2.0.3 (10g release2 patch 2 )
Operating System : AIX Version 5.3 level 04
oslevel -r -> 5300-04
System Model: IBM,9119-590
Processor Type: PowerPC_POWER5
Processor Clock Speed: 1654 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
Firmware Version: IBM,SF235_206
Paging Space Information
Total Paging Space: 10240MB
Entry details from ULOG .
63924.mware02!bnatrx.11628728.1.0: Starting service BNATRX [Key = 0220B472201108A1A00000000000040000805402000000000180000000000000000.000000003241163925051268200000000588845 7132160032410376 BNAQTF4803550376 ]
163924.mware02!bnatrx.11628728.1.0: NAZIM - Before calling stored procedure --- INPUT-FIELDS = [0220B472201108A1A00000000000040000805402000000000180000000000000000.000000003241163925051268200000000588845 7132160032410376 BNAQTF4803550376 QATIF 0151003|5001|10001SARSAR1040248100 1040248100 0001175.75 002008010810000000000000000000]
163924.mware02!bnatrx.11628728.1.0: DEBUG: Just before bna_caller [Key = 0220B472201108A1A000000000000400008]
163924.mware02!bnatrx.11628728.1.0: JUN B - Reply of bna_caller OUTPUT-FIELDS = [ATMFINUPD0320070512163925B003241 000000001001001000000000000000000000000000000025 BNA0376 555500000000000000NOR66660000864UBCH2007051220070512SAR0000000000180.000000000000180.00BNA SEC Bill # 1040248100 48 /025 00000000000000000000SAR0000000000000.0001.00000020070512N 00000000000000000000SAR0000000000000.0001.00000020070512N SAR0000000000000.0000000000000000000000SAR0000000000000.0000000000000000000000 163925 000000 000000NNNNNNNNNN 085000000000000000 NN1040248100 04 00C0001 0000000000000000000000000180.000020080108]
163924.mware02!op2trx.14397630.1.0: DEBUG: About to call service 'GFCUPD'
163937.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
163944.mware02!sddtrx.12288238.1.0: Entering service SDDTRX: [Key = BDSFININQ1120070512163944878800 ]
163944.mware02!sddtrx.12288238.1.0: SDDTRX: TranCode/Numentries is SDDTRX01 0
163944.mware02!sddtrx.12288238.1.0: DEBUG: Forward to GFCINQ: [BDSFININQ1120070512163944878800 000000001001001000000000000000000000000000000067 02BSF7690 555500000000000000NOR6666000002901 26577893 03 ]
163944.mware02!sddtrx.12288238.1.0: Entering service SDDTRX: [Key = BDSFININQ1120070512163944878805 ]
163944.mware02!sddtrx.12288238.1.0: SDDTRX: TranCode/Numentries is SDDTRX01 0
163944.mware02!sddtrx.12288238.1.0: DEBUG: Forward to GFCINQ: [BDSFININQ1120070512163944878805 000000001001001000000000000000000000000000000067 02BSF7690 555500000000000000NOR6666000002901 26577893 03 ]
163947.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
163948.mware02!sddtrx.12288238.1.0: Entering service SDDTRX: [Key = BDSFINUPD0320070512163947878810 ]
163948.mware02!sddtrx.12288238.1.0: SDDTRX: TranCode/Numentries is SDDTRX01 0
163948.mware02!sddtrx.12288238.1.0: DEBUG: Forward to GFCUPD: [BDSFINUPD0320070512163947878810 000000001001001000000000000000000000000000000067 02BSF7690 555500000000000000NOR66660000864UBCH2007051220070512SAR0000000000703.450000000000703.45STC Bill Bill # 265778933 00000000000000000000SAR0000000000000.0001.00000020070512N 00000000000000000000SAR0000000000000.0001.00000020070512N SAR0000000000000.00 SAR0000000000000.00 163947 000000 000000NNNNNNNNNN 022000000000000000 NN265778933 01 00C03 0000000000000000000000000703.450020070415 000000002007041520000000000000.0000 00000000000 00 ]
163957.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164007.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164017.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164027.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164037.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164047.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164057.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164107.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
164117.mware02!BBL.4866204.1.0: LIBTUX_CAT:5005: WARN: USEM[0] lock appears stuck: held by pid=4096190
Thanks In Advance for your help and support
Nadeer
Edited by nadeer78 at 05/13/2007 2:49 AMHi Lin,
I do know there was a problem with the Tuxedo 8.1 restart server under certain conditions (mostly related to having to restart large numbers of servers in a short period of time) that might have caused a problem like you are seeing.
I suggest you contact BEA support and open a case with them. They'll have access to the best information regarding this type of a problem and will be able to help you get this resolved.
Regards,
Todd Little
BEA Tuxedo Chief Architect -
Tuxedo10gR3VS2008 patches absolutely needed for Peopetools Installation
I am building a VM with Windows 2008r2 with SQL08R2.
I am going to install PeopleSoft HRMS on it. Hopefully it should work with SQL08R2 on WIN08R2.
Anyways, during the Peopletools installation process I came across a place where i needed to install the Tuxedo 10gR3 VS2008 patches before i proceed for people tools installation. I do not have the Oracle Support ID as i am right now doing this as a POC for my company with all trial editions. So I was wondering is the patches for Tuxedo are absolutely necessary before i do the peopletools installation?
-VishalYou did not tell your Peopletools version, let's assume you are on Peopletools 8.52... If you are speaking about the Tuxedo Rolling patch, then I'm not sure that is absolutely required to get it work, even though the RP043 is the minimum certified, find out more on http://edelivery.oracle.com ?
Otherwise, VS2008 is provided within Peopletools, once installed, you can run if needed %PS_HOME%\setup\psvccrt\psvccrt_retail.msi.
Nicolas. -
Application Server will not shutdown-Tuxedo 8.1
We run Tuxedo 8.1 (Patch 291), on Windows 2003 and shutdown the system nightly for PS Portal database refresh. Over the last couple of months both Application Servers are having issues shutting down our Portal environment.
Tuxlog is reporting various errros including:
ERROR: msgrcv err(LIBTUX_CAT:666: ERROR: Message operation failed because the queue was removed
ERROR: Message operation failed because of the invalid message queue identifier
ERROR: System lock semop failure
Any insight is appreciated
Thanks/PeterIf the app server was okay before and this problem started some where in between, then you may try this. Kill all java.exe processes and restart IDE & Servers.
-
Hi all,
Iam about to patch PT8.49 to 8.49.28.So, should i patch Tuxedo,web logic and verity also?If so to what versions?
Thank uWhat nicholas is said is right. peopletools does not require any third party patches upgrade to be done.
How ever at the same time, try to be on a recommended level of weblogic, tuxedo and verity patches
Peopletools 8.49 (recommended should be)
WL - 9.2 Mp3
Tuxedo - 9.1 R095
Verity - 6.2.1
Thanks -
Beam_Fget32() failed for TA_UID in tux_agent_seteuid
using the snmpd deamon with tuxedo 8.1 (patch 304)...
getting the following error in the ULOG:
"tdp039_snmpd.27020.1.-2: WARN:beam_Fget32() failed for TA_UID in tux_agent_seteuid
tdp039_snmpd.27020.1.-2: WARN:Agent may be unable to update application configuration
tdp039_snmpd.27020.1.-2: INFO:Caching times for /domains/tdp039/system/TUXCONFIG are 10/30 seconds for booted/non-booted states
tdp039_snmpd.27020.1.0: ERROR:Failed to get local LMID to retrieve values for
tdp039_snmpd.27020.1.0: ERROR:Failed to get local LMID to retrieve values for"
basically i can retrieve with snmp walk/get any configuration information like domain info (tuxTdomain at .1.3.6.1.4.1.140.300.3). however, anything related to runtime isn't found (tuxTqueueTable at .1.3.6.1.4.1.140.300.7.1.1). anytime i state a valid OID for runtime data the last record in the above error statements is returned. nothing is returned for bogus OIDs.
must be configuration thing. the errors i get are in a particular set of domains (just under production) while in test domains all runtime data is avialable.
any help is greatly appreciated. / matthewthe problem comes up due to the environment we run in...
the snmp agent works fine in non-clustered environments however in our veritus cluster the machine name in the ubbconfig file is the logical server name rather than the physical machine name (and the PMID variable is exported as the logical server). for some reason this disables the snmp agent from retrieving LMID/TA_UID information.
can anybody from BEA respond as to whether this can be resolved? -
Hi all
I'm using SALT 1.1 (Patch Level 011) with Tuxedo 8.1 (Patch Level 355) and experiencing intermittent HTTP Timeout Error 408 response codes. These responses are returned by SALT immediately and there's no output from the Tuxedo service when it occurs. I haven't been able to reliably recreate it, but it occurs quite regularly in some of our environments. The GWWS is configured with mostly default values. The server timeout value is unspecified, which should mean a default of 300 seconds. Has anyone come across any similar behaviour with SALT?
Thanks,
EoinEoin,
At most of time, this error, 408 indicates the network reading is timeout. For example, the client claims to send 100 bytes, but hung at 90 bytes for some reason. And GWWS will report timeout if the waiting time longer than the timeout value, as you mentioned, the default value is 300 seconds. You may configure it to a large value to see the result.
Wayne -
TPETIME and long running transactions
Tuxedo version and patch: Tuxedo Version 8.1, 32-bit, Patch Level 328
Issue:
One of the services we have is exhibiting very high response times (as gathered from the stderr log using -r option). In some instances the reported response time has reached 827 seconds. Now, my understanding says that since the default timeout in Tuxedo is set to 300 seconds, the service should have timed out and it did not. I checked if there is a SVCTIMEOUT setting for this service in the ubbconfig file, but there is not.
I am confused as in why this service did not timeout as expected? Is there a known issue with Tuxedo 8.1 and is there a patch for it (i searched the forum but didn't find any)?
Any help/hints appreciated.Hi,
there are many different kinds of timeouts available in Tuxedo and it might feel confusing sometimes.
Timeouts can be viewed from two different perspectives - that of the client (calling the service) and that of the service/server itself.
From the client's point of view, a service call using tpcall() is generally subject to a timeout, defined by BLOCKTIME*SCANUNIT in the ubbconfig, or a service-specific BLOCKTIME in newer versions of Tuxedo (called "blocking timeout", default 60 seconds). If the service call lasts (more than SCANUNIT seconds) longer than the blocking timeout, tpcall() will fail with tperrno TPETIME.
The client can avoid this by setting the flag TPNOTIME, in which case the tpcall() call will "hang" until the service finally returns something. (I would personally recommend against this, but that's another story...)
From the service/servers point of view, a blocking timeout is never really an issue (unless the service performs a nested call, but in that case it becomes a client!). The service will continue its work until it finally reaches the point of tpreturn() (or possibly tpforward()). It has no real understanding that the client might have given up a long time ago (with a TPETIME error), it will do whatever it takes to try to deliver a response, sometimes causing entries in the ULOG if the client has terminated and the delivery is impossible.
If you want to avoid this, you need to define a SVCTIMEOUT in the ubbconfig for the service in question. If you do that, Tuxedo will monitor the server side of the service call and brutally abort the server process (kill it by means of a unix signal) if a service call hosted by that process lasts (more than SCANUNIT seconds) longer than the SVCTIMEOUT specified for that service. If you have defined the server with RESTART=Y (and MAXGEN=n!!!), Tuxedo will then restart the server automatically, which is probably a good thing. I'm not 100% sure what the client will receive, but probably a TPETIME. (If you have specified TPNOTIME you might actually get into trouble in this case.)
In order not to make things too easy, there's also the possibility of a transactional timeout (as opposed to blocking timeout). A transactional timeout is a mechanism to protect databases and other users from transactions/locks with too long durations, and as such is is somewhat more potent than a blocking timeout (that is only protecting a single client from waiting too long).
If a transactional timeout is in effect, it will always override the blocking timeout.
To return to your question, it is my belief that the client in your case experienced a timeout (TPETIME) error after some 300 seconds, if that's your configured BLOCKTIME (60 used to be the default). As the server did not really know this, it continued doing work (in vain) for another 527 seconds before reaching tpreturn(), where it wrote timing information for txrpt and tried to return a response to the client that already had given up all hope.
Does this make any sense to you?
Best regards,
/Per -
Proc.17086.1.-2: LIBTUX_CAT:6274: ERROR: TMNOTHREADS set to yes but multipl
Hi
I am seeing above errors in my ULOG and i have made sure TMNOTHREADS=yes , is set in the environment. We are not using threads and thread functions in my client and server.
we are using tux80 on hp11i
we get ocassional failures and below is the snippet
proc.17086.1.0: LIBTUX_CAT:6242: ERROR: Invalid user password
17086.1.0: LIBWSC_CAT:2005: ERROR: gssapi function returned failure -3003
proc.17086.1.-2: LIBTUX_CAT:6274: ERROR: TMNOTHREADS set to yes but multiple threads detected: 1/0
why does buildclient add -lpthread default ?
VasuRonan,
This error message tells us your application password stored in
TPINIT.passwd does not match the one which was input when creating
TUXCONFIG.
I would like suggest following checking,
1. If compiling the same workstation client to native client, can you get
the same error message ? If the native client works correctly and this
problem came up after a particular Tuxedo rolling patch, please contact BEA
support.
2. If possible, recreate your TUXCONFIG from UBBCONFIG and input the
application password again.
Hope some help.
Wayne
<Ronan Shee> wrote in message news:[email protected]..
Good day and thanks in advance for one's advice in this column. <BR><BR>
<b>Background and Error</b><BR>
- "LIBTUX_CAT:6251: ERROR: A workstation client does not have a properapplication password"<BR>
- Recently, our system was logged with this error message in TuxedoULOG.<BR><BR>
>
<b>Findings</b><BR>
- The version of Tuxedo (8.0, Patch Level 331) that we are using isbelieved to have addressed the issue faced in previous version of
Tuxedo.<BR>
- We are able to simulate that error message with a bad batchapi call(i.e. setting an invalid "tux.user" value in a batch program's
"tpinit.properties" file).<BR>
- Tried changing the different logging parameters but was still not ableto trace / identify the source (program, IP) of this fault.<BR><BR>
>
<b>Questions</b><BR>
1.a) May I know, is there a logging parameter that can be turned on inorder for the system to log more information (program name, transaction
call, IP address) about the calling program / machine?<BR>
1.b) If yes, where will it be written to (ULOG)?<BR>
2) Are there any other causes for this error?
<BR>
<BR>
One's advice / feedback shall be much appreciated. Thank you.
<BR>
<BR>
Best Regards
Maybe you are looking for
-
I created and albums and I copied all the pictures and videos and I pasted it in the new album after that i deleted all the pictures and videos in the camera roll . I didnt know that it will be also deleted from the new album ! any one can help me to
-
Why icannot export pdf file from other app to ibook (after update today)?. Please correct my problem. iPad 2, iOS 5.0.1
-
Displacement filter not working in Photoshop cc
I just downloaded Photoshop CC and was trying to use the displacement filter. Photoshop freezes every time I try, and when I open the Task Manager the message Displacement Failed appears. When I end that task the program will unfreeze, but I still do
-
Crystal Report error on creation connexion on Bex Query
All, I'm trying to create a Crystal report on Bex Query but unfortunatly I've got an error message when I try to authenticate after clicking the on the new report on the Bex toolbar. The message is : Run-Time error '-2147417848 (80010108)': Automatio
-
Regarding Lead number by using BAPI_LEAD_CREATEMULTI.??
Hi Guru's, I am creating lead the Lead using the BAPI_LEAD_CREATEMULTI.and BAPI_TRANSACTION_COMMIT. I want to know <b>Lead Number</b> created by using these BAPI's??Which <b>field</b> will give me the<b> lead number</b>?? thanks in advance, Arjun