Mainframe, MVS and zOS Discussion

Hi,

Can anyone of you please explain about SQLCODE=-805. I made a search in the forum but I did not get a proper answer. Please help.

What do you mean by "proper answer"? Have you tried the manual? What did you not understand about the explanation?

You get SQLCODE=-805 when the package corresponding to an SQL statement execution request was not found.

When you compile and bind a program, you get the following:

1. the load module and
2. the other is the DB2 package.
3. DBRMLIB, but for this discussion this is not relevant.

Now when you run the program, a COBOL DB2 program, you need to provide a "complete pack of program" and that is the correct combination of same outputs that were created by your compile step. If you'd ever had only a single program on your shop, you don't need what we read ahead but that's not a usual set-up so we read ahead -

When you execute your program, out of many at your shop, one of the following can happen:

1. You do not pick up the correct version of the load module.
2. You pick up the correct version of the load module BUT the correct version of the package cannot be found. There are a few reasons why a package cannot be found.
   
   1. It may be bound into a wrong collection and your plan does not have access to it. To fix this, you must fix your BIND command.
   2. Possibly it was just not there; may be it was deleted. If it is so - to fix this, simply recompile/bind.
   3. Or the plan you are running under does not have access to the collection that the package lives in. Ask your DBAs to add the collection to your plan.

To avoid all this, a consistency token, in short known as "contoken" is embedded in. When a program is compiled and bound all of its outputs are stamped with the same contoken value. It makes easy to match them later. The contoken gets stamped on the package and if you query the DB2 catalog tables you will find it. As well, the same contoken value gets embedded inside the load module. Along with it, compile date/time also gets stamped inside the load module. Now if DB2 fails to find a match using the contoken value, you get -805.

Anuj Dhawan wrote:You get SQLCODE=-805 when the package corresponding to an SQL statement execution request was not found.

When you compile and bind a program, you get the following:

1. the load module and
2. the other is the DB2 package.
3. DBRMLIB, but for this discussion this is not relevant.

Now when you run the program, a COBOL DB2 program, you need to provide a "complete pack of program" and that is the correct combination of same outputs that were created by your compile step. If you'd ever had only a single program on your shop, you don't need what we read ahead but that's not a usual set-up so we read ahead -

When you execute your program, out of many at your shop, one of the following can happen:

1. You do not pick up the correct version of the load module.
2. You pick up the correct version of the load module BUT the correct version of the package cannot be found. There are a few reasons why a package cannot be found.
   
   1. It may be bound into a wrong collection and your plan does not have access to it. To fix this, you must fix your BIND command.
   2. Possibly it was just not there; may be it was deleted. If it is so - to fix this, simply recompile/bind.
   3. Or the plan you are running under does not have access to the collection that the package lives in. Ask your DBAs to add the collection to your plan.

To avoid all this, a consistency token, in short known as "contoken" is embedded in. When a program is compiled and bound all of its outputs are stamped with the same contoken value. It makes easy to match them later. The contoken gets stamped on the package and if you query the DB2 catalog tables you will find it. As well, the same contoken value gets embedded inside the load module. Along with it, compile date/time also gets stamped inside the load module. Now if DB2 fails to find a match using the contoken value, you get -805.

Thanks for the explanation Anuj. This is very useful.

Glad that we had been helpful.