I've created and compiled a program in Cobol, but when trying to run and test it with a JCL job, I'm getting this error when reading the output. (The program compiles and the job runs without errors themselves)
SQLCODE = -991, ERROR: CALL ATTACH WAS UNABLE TO ESTABLISH AN IMPLICIT CONNECT OR OPEN TO DB2. RC1=0008 RC2=00F30034
SQLSTATE = 57015
Now I don't understand why this error occurs. The DB2 database is up and running, I can access it myself. I can't find an error in my program code either. Googling it sadly doesn't provide me a clear solution, all I can find is that the issue is either the compiling job for the program, the jcl to run it or issues with the DB2 itself.
Have you done a bind and did it work !!!, The error indicates the plan does not exist or is not authorized.
You need to talk to people at your site about the Compile/Bind process and who
authorises
If you do not know know about Mainframe Cobol/DB2 compile process, try
reading this
Basically --->
Cobol program
Cobol DB2 Program ---+----> with no SQL ---> Compile -----> Executable
| but calls Plan
|
+----> DBRM (SQL) -----> Bind ------> DB2 Plan
It is the plan that needs the DB2 authorisation to run the SQL !!!
You might be able to authorise the Plan or you might need to see the DBA's
With DB2 COBOL, There is Co-Compiler (was a pre-compiler) that strips out
the SQL and creates the DBRM (basically a a special SQL procedure).
It is the Bind that processes the DBRM (SQL) and creates DB2 access plans
This may seem long winded after java etc. But there are some advantages
The SQL is processed ahead of time and not while the program is running
You can check the DB2 access path at any time - Before / after execution. Useful for
analysing performance issues.
The same DB2 access paths are used from one run to the next. This leads to
fairly predictable run times.
Related
I have a question regarding error handling practices within SQL Server.
What I would like to accomplish is easy error re-creation. I have a very active SQL Server installation with constantly changing data in the tables I am interested in. It is modeling an active warehouse environment.
I've already built a generic error handler for all the stored procedures on this installation in order to track errors and log specifics about the cause of the error such as:
calling line (this gives the EXEC statement of the stored procedure as well as input variables)
error_message
error_state
error_number
error_line
etc.
What I am missing is reproducibility. Even if I were to run the same statement just a few minutes after being notified that an error occurred, I cannot be sure that my results would be the same due to the underlying data changing.
I would like to capture the state of the data on the database when the error occurred.
This could be something like a database image that I could then import into a clean SQL Server installation and execute the erring line in order to perfectly capture what was happening on the database the moment the error occurred.
Due to the nature of needing to capture this at runtime, I would prefer a light-weight solution. Perhaps only capturing the tables relevant to the failing statement.
Does anyone know if this is possible or has been done before? It is really only critical to try and suss out logical errors. It wouldn't be necessary for something like a deadlock.
I would ultimately turn these data subsets into XML or JSON and include them in the error log when appropriate.
Essentially, where I work we run a variety of reporting processes that follow the same basic structure...
A batch file calls an sql script which executes a stored procedure. Another script extracts the data from Oracle and writes to a csv. Finally, an excel macro runs to create the final output.
We have been encountering an issue recently where if the procedure takes approximately longer than an hour to run, it will then hang indefinitely without moving on to the next line of the batch file. No error message is thrown up.
The most frustrating part is that certain procedures sometimes have the issue, and then the next day they do not.
Has anyone else ever encountered this issue? Or have any idea what could be causing this problem? I feel like it could be connection/firewall related, but it really is not my area of expertise!
You should instrument the batch file and use extended SQL tracing to reveal where ALL of your time is going. Nothing can escape proper instrumentation. You will find the source of the problem. What you do about it varies depending upon the particular problem (i.e., anti-pattern).
I see issues like this all the time. What I do it to connect to the DB and see what is running by checking gV$session. Key is to identify what SQL the script is running, then see if there are any reasons for it to be "hung" (there are MANY possible reasons). for example, missing indexes ; missing or not up to date stats ; workload on the instance ; blocking locks ; ...
If you have the SQL Tuning Advisor, you can run the SQL through there to get some ideas on solutions. Also ADDM Report may provide some additional solutions.
I want to make sure the new procedure valid, insteading of the DB2 always query by the cache pool, I have to rebind the database (db2rbind command). And then I deploy the application on WebSphere. BUT, when I login to the application, the error occurs:
The cursor "SQL_CURSN200C4" is not in a prepared state..SQLCODE=-514 SQLSTATE=26501,DRIVER=3.65.97
further more, the most weird thing is that the error just occurred only once. It will not never occur after this time, and the application runs very well. I'm so curious about how it occurs and the reason why it only occurs only once.
ps: my DB2 version is 10.1 Enterprise Server Edition.
and the sql which the error stack point to is very simple just like:
select * from table where 1=1 and field_name="123" with ur
Unless you configure otherwise (statementCacheSize=0) or manually use setPoolable(false) in your application, WebSphere Application Server data sources cache and reuse PreparedStatements. A rebind can cause statements in the cache to become invalid. Fortunately, WebSphere Application Server has built-in knowledge of the -514 error code and will purge the bad statement from the cache in response to an occurrence of this error, so that the invalidated prepared statement does not continue to be reused and cause additional errors to the application. You might be running into this situation, which could explain how the error occurs just once after the rebind.
I have written a program in vb.net for in house use that connects to a Progress OpenEdge database. Now I'm having a really weird runtime problem.
I have a .exe file that runs on my local C: drive, the C: drive of the servers, from a certain network Location (but not other places on the network) just fine on at least two regular users. The problem is that when I submit it to my IT manager for review she gives it back and says it wont even run; on looking at the error, it seems to fail on the very first select query (which happens before the form finishes loading) Specifically, it ultimately boils down to the error below:
System.Data.Odbc.OdbcException: ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Number contains an invalid character: ?
ERROR [HY000] [DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Number contains an invalid character: ?
now, certainly, I'm using data sources in visual studio and parameterized queries. So, yes, if it's trying to run it as straight SQL and not filling the parameters like it's supposed to, then there is a question mark in a number field. My question is: why does the same .exe, in the same place, run by a user with HIGHER privileges throw errors?
Are you initializing the integer variable with zero (0). The question mark in progress means unknown value.
If you are still running into a problem or haven't verified a solution yet, maybe check this KnowledgeBase article on SQL tracking out to make sure that the interpretation/execution of these statements is correct.
Providing that everything is the same with the SQL statements, the problem is most likely with the way the .exe is being run. There may be filling with an alpha character rather than numeric input depending on how the .exe is being run.
I'm developing a web project and for a start I need to create tables, procedures, views, etc.
At the first (and in debug mode) the code is running fine and the first tables are created but suddenly the transaction throws me an error Timed out
If I start again to run the code (in debug mode) it doesn't make any change
In order to run and continue to create the rest's I have to build the code again (without have made any change on it). I Published again and then continues to create more until will stops again and make the same actions as before.
I haven't test it yet in my web to see what will happen, and the reason is simple... my ISP didn't giving me the choice to create one more data base (because that is my contract I use).
Any way I need to know why that happens?
I have to say that I use some delays in my code especially when it reads from an xml file this file contains structure's of tables, procedures etc. And from where I read and execute thru my code behind in vb.net.
After many attempts finding solution, I noticed that the problem starts from the reading of the XML File, I set in this file some sleeps of totally 300 milliseconds and the code now runs ok but slowly...
Thanks to all for there assistance