| ora6508 - AM4CICS on recompile of stored procedure. [message #113768] |
Thu, 08 November 2001 06:58  |
stephen heasley
Messages: 4
Registered: November 2001
|
Junior Member |
|
|
|
Does anyone have knowledge of a workaround for a problem we have where the am4cics adaptor is assembled having protect = yes, and cics commit, as we have to for performance reasons, but with our 24*7 system, in which these adaptors run if I change the main stored procedure and recompile, the programs running on the adaptor threads just get a 6508, because they seem to have an address handle on the original stored procedure, and do not let go of it even on this receipt of this error.I cannot code for it in the cics program, because that does not know which thread it is in, and it is (I think) the thread which owns the cached address of the stored procedure. Currently we have no other way to fix this than to bring the adaptor down and restart it, then the threads are started clean and look at the new stored procedure, but then any future changes cause the same effect.
|
|
|
|
| Re: ora6508 - AM4CICS on recompile of stored procedure. [message #113771 is a reply to message #113768] |
Fri, 16 November 2001 09:07  |
Subhash Roy
Messages: 24
Registered: January 2001
|
Junior Member |
|
|
: Does anyone have knowledge of a workaround for a problem we have where the am4cics adaptor is assembled having protect = yes, and cics commit, as we have to for performance reasons, but with our 24*7 system, in which these adaptors run if I change the main stored procedure and recompile, the programs running on the adaptor threads just get a 6508, because they seem to have an address handle on the original stored procedure, and do not let go of it even on this receipt of this error.I cannot code for it in the cics program, because that does not know which thread it is in, and it is (I think) the thread which owns the cached address of the stored procedure. Currently we have no other way to fix this than to bring the adaptor down and restart it, then the threads are started clean and look at the new stored procedure, but then any future changes cause the same effect.
: There may be a patch for Oracle Access Manager for CICS. The error is common in the Unix/NT world, and can be fixed. Not sure if Oracle is aware of this problem on the mainframe.
|
|
|
|
| Re: ora6508 - AM4CICS on recompile of stored procedure. [message #113783 is a reply to message #113771] |
Tue, 27 November 2001 13:14 |
Subhash Roy
Messages: 24
Registered: January 2001
|
Junior Member |
|
|
: : Does anyone have knowledge of a workaround for a problem we have where the am4cics adaptor is assembled having protect = yes, and cics commit, as we have to for performance reasons, but with our 24*7 system, in which these adaptors run if I change the main stored procedure and recompile, the programs running on the adaptor threads just get a 6508, because they seem to have an address handle on the original stored procedure, and do not let go of it even on this receipt of this error.I cannot code for it in the cics program, because that does not know which thread it is in, and it is (I think) the thread which owns the cached address of the stored procedure. Currently we have no other way to fix this than to bring the adaptor down and restart it, then the threads are started clean and look at the new stored procedure, but then any future changes cause the same effect.
: : There may be a patch for Oracle Access Manager for CICS. The error is common in the Unix/NT world, and can be fixed. Not sure if Oracle is aware of this problem on the mainframe.
:Additional information from the manual. Please let me if it helps.
:Package Corruption
ERROR at line 1:
ORA-04068: existing state of packages has been discarded
ORA-04063: package body "<name>" has errors
ORA-06508: PL/SQL: could not find program unit being called
ORA-06512: at "<name>", line <number>
ORA-06512: at line <number>
This error might occur if you are extending an existing data cartridge; it indicates that the package has been corrupted and must be recompiled.
Before you can perform the recompilation, you must delete all tables and object types that depend upon the package that you will be recompiling.
To find the dependents on a Windows NT system, use the Oracle Administrator toolbar. Click the Schema button, log in as syschange_on_install, and find packages and tables that you created. Drop these packages and tables by entering SQL statements of the following form into the SQL*Plus interface:
Drop type <type_name>;
Drop table
cascade constraints;
The recompilation can then be done using a SQL statement of the following form:
Alter type <type_name> compile body;
or Alter type <type_name> compile specification;
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
