CMDTUX_CAT:1685: ERROR: Application initialization failure tmboot:
CMDTUX_CAT:827: ERROR: Fatal error encountered; initiating user error handler
1) Authority/security not in place for the userid trying to boot the Application Server or Process Scheduler (when Maintained by Tuxedo)
Log on in 2-tier mode, go to Security Manager, and check that the ID being used to start the Application Server has the 'authority to boot the app server' box checked 'ON'.
2) Connectivity problems between the Application Server and the database.
CASE 1:
The problem was with the connectivity and this could be seen in the appsrv.log file. The Tuxedo-delivered services booted, but the PeopleSoft delivered services (psauth, psappsrv, etc) did not. It is the PS services that require the connectivity DLLs to the RDBMS. This can be fixed by specifically coding the AddToPath in Psadmin, instead of relying on the '.'
Check the environment variables set before going into Psadmin, especially the Ld Library Path.
Make sure psconfig.sh is run before going into psadmin.
CASE 2:
2) NT/2000 only. Make sure the PeopleSoft service and the Tuxedo IPC Helper are started with the same user id. Change the Logon As for the Service to be This Account. Make sure the account is a local account with local administrator privileges or a domain account with local administrator
privileges to this box. Use a regular userid id like TUXADM not the administrator account. TUXADM should have right to the report repository to be able to start the Distribution Agent.
CASE 3:
For one customer, the problem was due to password changes on the database (PS) or PIA. Once they reset the database password, the Application Server was able to start.
CASE 4:
For one customer on PeopleTools 7.5 and Sybase platform They received the error message above every time that they tried to boot up the App Server.
Found out that the user login into the system did not have have access to the /opt/Sybase/bin directory, and there was a missing /opt/Micro Focus COBOL.41 directory.
Once they gave the user right to the Sybase middle ware software, and installed the COBOL compiler, it worked and they were able to start up Application Server.
CASE 5:
2-tier log on also failed. The Oracle listener had not been started.
CASE 6:
Could not complete a TCP loopback as psoft (sqlplus VP1/VP1@dbname) but could as oracle.
Check for differences in environment settings and permissions of these two UNIX id's. This should fix the problem.
CASE 7: (Oracle Customers) :
Problem was with the tnsnames.ora file on the database server (or application server, as they have got logical 3-tier architecture). New domain database name was not updated in tnsnames.ora file. It started running once this file was updated.
CASE 8: (Oracle Customers)
The Application Server would hang without any error messages during PSAUTH start up. Tuxedo log file would just show "Standard main starting" and no errors either. The problem was with Oracle database archive logs. The archive log directory was full and the database had stopped all operations. Creating space in the archive log directory (or turning off archiving),
fixed the problem.
CASE 9:
Customer upgraded Oracle and get CMDTUX_CAT 1685 errors. The Application Server hangs while booting PSAPPSRV. The problem was resolved by doing Server transfer again and recompiling and relinking COBOL.
CASE 10 :
Customer didn't have sufficient space left on their Hard disk. Once they created some space they were able to boot the App Server.
CASE 11:
Customer upgraded to PT 7.58 and not able to start Application Server. Getting CMDTUX_CAT:1685: ERROR: Application initialization failure on the screen. APPSRV.LOG shows the following error :
PSAUTH.90 [05/17/00 18:08:51](1)
=== GenMessageBox ==
Title: Database Signon
Message: Invalid operator ID or password for database signon. (id=PS)
Style: 8208
Msg Set: 0
Msg #: 0
==
RESOLUTION:
Try to start the Application Server using another Operator Id. Make sure that the new Operator Id has permission to start Application Server by going into Security Manager. It should work.
If you still want to use the original Operator Id to start the Application Server then delete and recreate the Operator Id.
CASE 12:
Customer was booting up their domain and received the following:
exec JSL -A -- -d /dev/TCP -n //etsprode105:9140 -m 1 -M 1 -I 5 -c ANY -x 60
-T 60 -j 5000 -w JSH :
CMDTUX_CAT:1685: ERROR: Application initialization failure
RESOLUTION:
They were using a port number that was already being used, once they change the port number for JOLT, JSL started up OK.
CASE 13:
In the Install/Admin Guide for Oracle, for tools 7.5, Appendix A lists information on the Oracle bug
#617681 and the changes required for Hp UX 10.20 for Oracle 7.3.4 customers. Here the delivered clntsh.mk file is incorrect. The instructions ask the customer to login as the Oracle user and cd to $Oracle_Home/rdbms/lib. There, the clntsh.mk script needs to be editted as follows -- move the include of cobsqlintf.o to the front of the link list in the clntsh.mk script.
CASE 14:
ODBC configuration for SQL Server did not have peoplesoft database set as default in ODBC configuration
CASE 15:
Seen in PT 8.41 for Process Scheduler. The TNSNAMES.ORA file was using "IFILE=" clause to dereference a TNS file on the network.
Even though TNSPING and SQLPLUS could connect to the database, the Process Scheduler failed.
Create or copy the TNS file to the local machine, remove the IFILE clause.
CASE 16:
This Error can also be caused by an incorrect Node selection .
in pt 8.4x Navigate to : peopletools->process scheduler->servers->(select the distribution tab).
Click on the magnifying glass and select one of the available Nodes. Note* even though the Test box may contain a node name when you first navigate it may not be the correct one. available ones will be listed in the lookup listbox.
A referenced to an incorrect Node will also be references in the log of the service that errors out during the scheduler boot up.
CMDTUX_CAT:827: ERROR: Fatal error encountered; initiating user error handler
1) Authority/security not in place for the userid trying to boot the Application Server or Process Scheduler (when Maintained by Tuxedo)
Log on in 2-tier mode, go to Security Manager, and check that the ID being used to start the Application Server has the 'authority to boot the app server' box checked 'ON'.
2) Connectivity problems between the Application Server and the database.
CASE 1:
The problem was with the connectivity and this could be seen in the appsrv.log file. The Tuxedo-delivered services booted, but the PeopleSoft delivered services (psauth, psappsrv, etc) did not. It is the PS services that require the connectivity DLLs to the RDBMS. This can be fixed by specifically coding the AddToPath in Psadmin, instead of relying on the '.'
Check the environment variables set before going into Psadmin, especially the Ld Library Path.
Make sure psconfig.sh is run before going into psadmin.
CASE 2:
2) NT/2000 only. Make sure the PeopleSoft service and the Tuxedo IPC Helper are started with the same user id. Change the Logon As for the Service to be This Account. Make sure the account is a local account with local administrator privileges or a domain account with local administrator
privileges to this box. Use a regular userid id like TUXADM not the administrator account. TUXADM should have right to the report repository to be able to start the Distribution Agent.
CASE 3:
For one customer, the problem was due to password changes on the database (PS) or PIA. Once they reset the database password, the Application Server was able to start.
CASE 4:
For one customer on PeopleTools 7.5 and Sybase platform They received the error message above every time that they tried to boot up the App Server.
Found out that the user login into the system did not have have access to the /opt/Sybase/bin directory, and there was a missing /opt/Micro Focus COBOL.41 directory.
Once they gave the user right to the Sybase middle ware software, and installed the COBOL compiler, it worked and they were able to start up Application Server.
CASE 5:
2-tier log on also failed. The Oracle listener had not been started.
CASE 6:
Could not complete a TCP loopback as psoft (sqlplus VP1/VP1@dbname) but could as oracle.
Check for differences in environment settings and permissions of these two UNIX id's. This should fix the problem.
CASE 7: (Oracle Customers) :
Problem was with the tnsnames.ora file on the database server (or application server, as they have got logical 3-tier architecture). New domain database name was not updated in tnsnames.ora file. It started running once this file was updated.
CASE 8: (Oracle Customers)
The Application Server would hang without any error messages during PSAUTH start up. Tuxedo log file would just show "Standard main starting" and no errors either. The problem was with Oracle database archive logs. The archive log directory was full and the database had stopped all operations. Creating space in the archive log directory (or turning off archiving),
fixed the problem.
CASE 9:
Customer upgraded Oracle and get CMDTUX_CAT 1685 errors. The Application Server hangs while booting PSAPPSRV. The problem was resolved by doing Server transfer again and recompiling and relinking COBOL.
CASE 10 :
Customer didn't have sufficient space left on their Hard disk. Once they created some space they were able to boot the App Server.
CASE 11:
Customer upgraded to PT 7.58 and not able to start Application Server. Getting CMDTUX_CAT:1685: ERROR: Application initialization failure on the screen. APPSRV.LOG shows the following error :
PSAUTH.90 [05/17/00 18:08:51](1)
=== GenMessageBox ==
Title: Database Signon
Message: Invalid operator ID or password for database signon. (id=PS)
Style: 8208
Msg Set: 0
Msg #: 0
==
RESOLUTION:
Try to start the Application Server using another Operator Id. Make sure that the new Operator Id has permission to start Application Server by going into Security Manager. It should work.
If you still want to use the original Operator Id to start the Application Server then delete and recreate the Operator Id.
CASE 12:
Customer was booting up their domain and received the following:
exec JSL -A -- -d /dev/TCP -n //etsprode105:9140 -m 1 -M 1 -I 5 -c ANY -x 60
-T 60 -j 5000 -w JSH :
CMDTUX_CAT:1685: ERROR: Application initialization failure
RESOLUTION:
They were using a port number that was already being used, once they change the port number for JOLT, JSL started up OK.
CASE 13:
In the Install/Admin Guide for Oracle, for tools 7.5, Appendix A lists information on the Oracle bug
#617681 and the changes required for Hp UX 10.20 for Oracle 7.3.4 customers. Here the delivered clntsh.mk file is incorrect. The instructions ask the customer to login as the Oracle user and cd to $Oracle_Home/rdbms/lib. There, the clntsh.mk script needs to be editted as follows -- move the include of cobsqlintf.o to the front of the link list in the clntsh.mk script.
CASE 14:
ODBC configuration for SQL Server did not have peoplesoft database set as default in ODBC configuration
CASE 15:
Seen in PT 8.41 for Process Scheduler. The TNSNAMES.ORA file was using "IFILE=" clause to dereference a TNS file on the network.
Even though TNSPING and SQLPLUS could connect to the database, the Process Scheduler failed.
Create or copy the TNS file to the local machine, remove the IFILE clause.
CASE 16:
This Error can also be caused by an incorrect Node selection .
in pt 8.4x Navigate to : peopletools->process scheduler->servers->(select the distribution tab).
Click on the magnifying glass and select one of the available Nodes. Note* even though the Test box may contain a node name when you first navigate it may not be the correct one. available ones will be listed in the lookup listbox.
A referenced to an incorrect Node will also be references in the log of the service that errors out during the scheduler boot up.
Thank You. Information you provided helped me a lot.
ReplyDeleteCASE 16 :
ReplyDeleteThis error occurred when the schema owner (sysadm) ID was locked. Getting that ID unlocked allowed the process scheduler to start.
NOTE: password expired shows as password locked in Oracle databases (11+)