 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups Database Servers DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybaseDesktop Databases FileMakerFoxProMS AccessParadoxGeneral General DB TopicsDatabase TheoryRelated Topics Java Development.NET DevelopmentVB DevelopmentMore Topics ... |
Database Forum / DB2 Topics / January 2006Error in diag.log(-444)
Hi All db2 8.1.3 Windows I am getting this error in db2diag.log.Please tell why is this error (-444) always there and how to go about for removing it. Diag.log output: ---------------------------------------------- 2006-01-28-19.48.05.816000 Instance:DB2 Node:000 PID:1628(db2syscs.exe) TID:1524 Appid:none base sys utilities startdbm Probe:911 ADM7513W Database manager has started. PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): input string .. 0x178964BA : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x178964CA : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x178964DA : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x178964EA : 4143 4553 5044 4D5C 5753 4143 4553 5C50 ACESPDM\WSACES\P 0x178964FA : 3133 3930 3932 3921 7067 736A 6D70 1390929!pgsjmp PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): instance name .. 0x1789632A : 424C 445F 5356 5F46 4E4C 5F4D 4F44 5F53 BLD_SV_FNL_MOD_S 0x1789633A : 5441 TA PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved path .. 0x01E843C9 : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x01E843D9 : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x01E843E9 : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x01E843F9 : 4143 4553 5044 4D5C 5753 4143 4553 ACESPDM\WSACES PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved module .. 0x01E845CA : 0x3932393039333150 P1390929 PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved function ... 0x01E844CA : 7067 736A 6D70 pgsjmp PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): input string .. 0x178964BA : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x178964CA : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x178964DA : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x178964EA : 4143 4553 5044 4D5C 5753 4143 4553 5C50 ACESPDM\WSACES\P 0x178964FA : 3133 3930 3932 3921 7067 736A 6D70 1390929!pgsjmp PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): instance name .. 0x1789632A : 424C 445F 5356 5F46 4E4C 5F4D 4F44 5F53 BLD_SV_FNL_MOD_S 0x1789633A : 5441 TA PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved path .. 0x01E843C9 : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x01E843D9 : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x01E843E9 : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x01E843F9 : 4143 4553 5044 4D5C 5753 4143 4553 ACESPDM\WSACES PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved module .. 0x01E845CA : 0x3932393039333150 P1390929 PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved function ... 0x01E844CA : 7067 736A 6D70 pgsjmp PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): input string .. 0x02350C2A : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x02350C3A : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x02350C4A : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x02350C5A : 4143 4553 5044 4D5C 5753 4143 4553 5C50 ACESPDM\WSACES\P 0x02350C6A : 3134 3631 3537 3721 7067 736A 6D70 1461577!pgsjmp PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): instance name .. 0x02350AC2 : 5351 4C30 3331 3031 3432 3031 3233 3032 SQL0310142012302 0x02350AD2 : 3738 78 PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): resolved path .. 0x18F1CB89 : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x18F1CB99 : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x18F1CBA9 : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x18F1CBB9 : 4143 4553 5044 4D5C 5753 4143 4553 ACESPDM\WSACES PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): resolved module .. 0x18F1CD8A : 0x3737353136343150 P1461577 PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): resolved function ... 0x18F1CC8A : 7067 736A 6D70 pgsjmp PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): input string .. 0x02350C2A : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x02350C3A : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x02350C4A : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x02350C5A : 4143 4553 5044 4D5C 5753 4143 4553 5C50 ACESPDM\WSACES\P 0x02350C6A : 3134 3631 3537 3721 7067 736A 6D70 1461577!pgsjmp PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): instance name .. 0x02350AC2 : 5351 4C30 3331 3031 3432 3031 3233 3032 SQL0310142012302 0x02350AD2 : 3738 78 PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): resolved path .. 0x18F1CB89 : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x18F1CB99 : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x18F1CBA9 : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x18F1CBB9 : 4143 4553 5044 4D5C 5753 4143 4553 ACESPDM\WSACES PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): resolved module .. 0x18F1CD8A : 0x3737353136343150 P1461577 PID:1628 TID:168 Node:000 Title: sqlerRoutineLoad (-444): resolved function ... 0x18F1CC8A : 7067 736A 6D70 pgsjmp > Hi All > db2 8.1.3 Windows [quoted text clipped - 120 lines] > function ... > 0x18F1CC8A : 7067 736A 6D70 pgsjmp -444 means that DB2 is trying to find a routine (stored proc or UDF maybe) and can't find it. Could it be the library and routine name in the dump text on the right side? Larry Edelstein Hi Larry, I have loaded the production data last week in a new database.I had compiled all the SP's and functions.There are 6 databases inside a single instance out of which one is the new database where I have loaded the objects.Developers are complaining for slow database response.How to find what is the exact issue and how to make sure which library is missing. Thanx in advance Praveen Hi Larry, One more thing I observed just now. The path "D:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\ACESPDM\WSACES" does not exist!!! db2 is installed in C:\ and Instance and databases are in D:\ . All tablespaces are SMS.Can you tell me how does db2 resolve the path from where it should pickup the routine's dll??? Thanx in advance Praveen > Hi Larry, > One more thing I observed just now. The path [quoted text clipped - 3 lines] > tablespaces are SMS.Can you tell me how does db2 resolve the path from > where it should pickup the routine's dll??? First, what might be really helpful to narrow down the issue is the exact error message that DB2 returns. You should have that message available somewhere, or your application is not properly handling errors. Unless you specified it otherwise, all routines are in the sqllib/function/ directory in the location where you installed DB2. Did you copy the DLLs from the development system to the production system? (Or did you create the procedures at the production system and is there a C compiler installed?) Would it be an option for you to install FP7 or later? With that you won't have the requirement for a C compiler any longer as the procedures would be stored and executed using a DB2-internal representation. This would also do away with the library issues you are experiencing.  SignatureKnut Stolze DB2 Information Integration Development IBM Germany Hi Knut Thanks for the reply. The exact error which I am getting is SQL0444N RC'4'. I have compiled the procedures in the database and it has a C compiler.Unfortunately I have to bear with 8.1.3 only as it is as par the client requirement. One thing I am not able to understand is why is db2 looking in "D:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\ACESPDM\WSACES" when that path doesnot exist.Its not there even in PATH and CLASSPATH.Actually it should look into "D:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\ACESPDM\WSACES". Please advise. Praveen > Hi Knut > Thanks for the reply. [quoted text clipped - 8 lines] > Please advise. > Praveen I'm confused.. Maybe it's because Monday morning, but teh two paths you posted above look identical to me... The path is generated. Prior to DB2 V8.2 the executable of an SQL Procedure is loaded from the file system. ACESPDM is teh DB name and WSACES is the schema name. The filename P***** reflects the name of the package associated with the SQL Procedure. If, for some reason (e.g. after backup/restore) the fie edoes not exist DB2 will copy it from the SYSCAT.ROUTINES catalog into to the filesystem. Now it could happen that for some reason there is a permission problem somewhere along the path which prevents DB2 from doing so. Do all procedure calls fail like this or just this one? Cheers Serge SignatureSerge Rielau DB2 Solutions Development DB2 UDB for Linux, Unix, Windows IBM Toronto Lab > > Hi Knut > > Thanks for the reply. [quoted text clipped - 11 lines] > I'm confused.. Maybe it's because Monday morning, but teh two paths you > posted above look identical to me... I guess Praveen made a little mistake. He posted earlier in this thread that Db2 is installed on the C: drive so I guess it's a copy/paste/forgot-to-change issue. > Now it could happen that for some reason there is a permission problem > somewhere along the path which prevents DB2 from doing so. When you check permissions, remember that the DB2 instance owner (usually "db2" on Windows systems if you did not change the default) has to be have create directory, write, read, and execute privileges under sqllib/function/ and all subdirectories. SignatureKnut Stolze DB2 Information Integration Development IBM Germany Hi Serge Really sorry for that. path should be "C:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\ACESPDM\WSACES" procedure calls are not failing if I call them from db2clp. But when developers are calling it using .NET they are complaining of database being slow.When I look in to the diag.log for the reasons it shows me entries that I posted above. Please tell me how to resolve this error. I have given all the privileges to schema "wsaces" through control center.Also it is in the administrator group. > Hi Serge > Really sorry for that. > path should be > "C:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\ACESPDM\WSACES" > procedure calls are not failing if I call them from db2clp. I guess you should start over and tell us exactly what is work and what is not. Right now we have different paths (I don't know which one you meant to "correct"), failing procedures that don't work, ... > But when > developers are calling it using .NET they are complaining of database > being slow. When I look in to the diag.log for the reasons it shows me > entries that I posted above. You removed too much stuff from the db2diag.log, so that we can't even be sure if those messages are normal, informational messages collected with DIAGLEVEL 4. > Please tell me how to resolve this error. > I have given all the privileges to schema "wsaces" through control > center.Also it is in the administrator group. The library "p*" should by in the path you have listed above, assuming that DB2 is installed under "c:/Progra~1/ibm/sqllib". Now you should check (a) that the respective directories exist -> if not, create the procedure again (b) that the db2 instance owner has the privileges to access that directory as stated before (c) that you give us a complete description of the error, including the error message and all the information relating to the problem from the db2diag.log SignatureKnut Stolze DB2 Information Integration Development IBM Germany >> Hi Serge >> Really sorry for that. [quoted text clipped - 5 lines] > not. Right now we have different paths (I don't know which one you meant > to "correct"), failing procedures that don't work, ... Oops, I meant "failing procedures that _do_ work" SignatureKnut Stolze DB2 Information Integration Development IBM Germany Thanx All for replying. I am stating the whole issue once again. I have one instance (say DB2) and 3 databases in it(db1,db2,db3). All the databases are SMS and replicas of production databases(When I say replica it is not actually making use of 'replication' .its restoration using 'db2look' and 'db2move'.) All the database oblects in all databases are under same schema(say SCHNME. NOTE:its a 6 characters name) DB1 and DB3 have similar structure.the name and sizes of tablespaces,bufferpools etc are same. Actually DB1 had some data mismatch issues hence DB3 was created on the lines of DB1 and proper(and latest) data and db objects were put there. Data was brought using db2move.DDl and for routines was run for individual procedures and UDF's using batch file.Now we are accessing DB3 and there is no connection made to DB1 through any application. I am seeing errors like this in db2diag.log ********************************************************************************* PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): input string .. 0x178964BA : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x178964CA : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x178964DA : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x178964EA : 4143 4553 5044 4D5C 5753 4143 4553 5C50 DB1\SCHNME\P 0x178964FA : 3133 3930 3932 3921 7067 736A 6D70 1390929!pgsjmp PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): instance name .. 0x1789632A : 424C 445F 5356 5F46 4E4C 5F4D 4F44 5F53 BLD_SV_FNL_MOD_S 0x1789633A : 5441 TA PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved path .. 0x01E843C9 : 443A 5C50 524F 4752 417E 315C 4942 4D5C D:\PROGRA~1\IBM\ 0x01E843D9 : 5351 4C4C 4942 5C66 756E 6374 696F 6E5C SQLLIB\function\ 0x01E843E9 : 726F 7574 696E 655C 7371 6C70 726F 635C routine\sqlproc\ 0x01E843F9 : 4143 4553 5044 4D5C 5753 4143 4553 DB1\SCHNME PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved module .. 0x01E845CA : 0x3932393039333150 P1390929 PID:1628 TID:1144 Node:000 Title: sqlerRoutineLoad (-444): resolved function ... 0x01E844CA : 7067 736A 6D70 pgsjmp ************************************************************************************* In the server db2 is installed in C: and all the databases are in D:. Hence ideally db2 should access "C:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\DB1\SCHNME" whereas it is accessing "D:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\DB1\SCHNME". Secondly, why is it accessing package "P1390929" of DB1 for accessing procedure (say proc1) when the same procedure is there in DB3 and has package "P2783467" in "C:\PROGRA~1\IBM\SQLLIB\function\routine\sqlproc\DB3\SCHNME" I have not logged in the server thru user SCHNME but it is included in the administrative group. As I said in my previous post, developers are complaining of database being slow.I think (-444) can be a reason for that as db2 may take some time for resolving modules and functions as in above code from db2diag.log. Also Knut,please tell me if I am logged in through some other user(say ADMIN) how can I check whether SCHNME has all rights over some particular folder or not? One more thought- Can the schemaname of 6 characters be an issue? This is because in 'db2look' and 'db2move' it gives the schema name as "SCHNME " instead of "SCHNME". Please advise as this problem is there from last week and I need to resolve it soon. TIA Praveen > Thanx All for replying. I am stating the whole issue once again. > I have one instance (say DB2) and 3 databases in it(db1,db2,db3). [quoted text clipped - 72 lines] > Please advise as this problem is there from last week and I need to > resolve it soon. I took this up with the architect of SQL PRocedures and here is the answer: "The error msgs referring to db1 can be caused by a package with static CALL sections that was originallly created on db1 and later on run on db3, presumably after a db1 backup was restored on top of db3. To get rid of the error, the package must be rebound. This is caused by the CALL section caching the physical path to the library of the routine it's calling." Hope that helps Serge SignatureSerge Rielau DB2 Solutions Development DB2 UDB for Linux, Unix, Windows IBM Toronto Lab |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.