I am not sure about you, but for me as a DB2 DBA this SQL code used to be a nightmare. Why a nightmare ? I didn't know where to look for things when I used to encounter emails having an -805 in the subject line. After working with lot of -805's I felt, may be there is someone out there who is still finding it difficult to solve them.
After reading this post, the perception on -805's may change !
Can I fix the -805 INSTANTLY for my application ?
YES ! You can. PRECOMPILE & BIND your program again - One stop fix for all -805 !, Tried, tested and executed - 100 % success ratio - guaranteed !! By doing so, you generate a new consistency token for your load and DBRM module. While performing this operation you need not worry about anything else if there are no changes in your job ( through which you run your program).
Where exactly the link is lost ?
Most of the developers perform PRECOMPILE while generating a new piece of code ( program ) I have seen my fellow developers using online tools to perform precompile ( it's pretty amazing ) and they overlook to UN-comment the BIND cards. PRECOMPILE should always be followed by a BIND step else you end up with -805. Based on my experience 80 - 90 % of -805's are caused since the BIND's are not performed.
I want to work on fixing the -805 error code as a DB2 DBA, Are there any thumb rules ?
-805's can be due to several reasons, BIND's issues, wrong DBRM name, no load module mapped to the application job, data sharing environments - there are loads of them why they occur !. Well, there isn't any such thumb rule but I have a set of standards I follow while working on -805's - it does apply pretty well !
Try following these steps
1) Don't Panic ! - All the -805's can be fixed
2) Copy the consistency token ( 191C3BF40947BC2E ), dbrm or package name ( PROG001 ) and Plan name ( PLAN001) from the error message ( SQLCA ) into a fresh note pad for analysis. Note the reason code as well, it will narrow down your search while you refer the SQL reference manual.
3) Find the DBRM library for the module ( PROG001) using the administration tools in your shop. In our case it is TEST.DBRMLIB
4) Browse the PDS - TEST.DBRMLIB, find for PROG001 member in the list of members displayed. Select PRG001
5) Find for the first 8 digits of the contoken ( it's a hex code ) by issuing a find command on the command line - F x'191C3BF4'
5a) If you find this consistency token - it indicates a BIND was performed on the program - One possible reason can be the PLAN ( PLAN001) is not having PROG001 as its package. Go to the PLAN and include the member using PKLIST or member keyword and BIND the plan. But most of the times you won't find the contoken within the member.
5b) If you could not find the consistency token - it indicates the BIND was not performed, a different DBRM library was used - Generate a BIND card and perform the BIND or ask the developer for the DBRM library which he used while performing the BIND and perform step 5 again.
6) Cross check for load module concatenation in the Job ( JCL ) - Based on the concatenation pattern(s) the contoken(s) are matched with recurrence in DBRM modules. If there is a old load module concatenated at the beginning then * comment * the library or libraries out else there is a good chance that a wrong contoken may get associated with your load library
Now, try not to forward any -805's to your DBA's. Try finding out the cause for it and fix it yourself. I bet, fixing -805's is fun and gives some high dosage of '' learning experiences ", I used to run away from -805's during my early days as a DBA. Now, I anxiously wait for any -805's to creep in and enjoy fixing them ( yes, the developers here try to fix it themselves and then forward the email once they loose the battle ). Try following these steps and let me know if it worked out for you by leaving a comment, if it did not - leave a comment and I will update the post with more details.
NOTE : Performing REBIND's won't fix -805s !
No comments:
Post a Comment