On 25-Nov-2013 11:37 -0800, Steinmetz, Paul wrote:
Here are the specific error details.
This error occurred on two different LPARS, I expect it to occur
again on my production LPAR.
<<SNIP>>
The <snipped> errors rewritten using some symptom strings:
msgCPF9898 F/QSQPROC FM/QSQPROC FP/OPEN_SYSROUTINE STMT/49624
T/QSQPROC TM/QSQPROC TP/DROP_ROUTINE STMT/23943
"SQL CATALOG QSYS2/SYSROUTINE HAS AN OLD FORMAT. AN IPL MAY BE NEEDED."
¿ CPF9898 f/QSQPROC fm/QSQPROC fp/CLEANUP stmt/51749
t/QSQPROC tm/QSQPROC tp/DROP_ROUTINE stmt/23943
msgSQL0901 f/QSQPROC fm/QSQPROC fp/CLEANUP stmt/51749
t/QSQPROC tm/QSQPROC tp/CLEANUP stmt/51749
"SQL system error. ... The previous message identifier was CPF9898.
Internal error type 7112 has occurred." rc7112 et7112 rcCPF9898
msgCPF87F8 f/QZXMMRMX in QDBXM fm/DXXMRMX fp/SendMsg stmt/3
t/QLPRPCPR x/2158
"Unexpected internal system error occurred in program QZXMMRMX. The
internal error data is 1001" rc1001 errdta1001
CPF8356 <<normal; omitted data and kwds>>
msgCPF3D95 f/QLPRPCPR x/30E4 t/QLPRPCPR x/30E4
"Exit program processing failed."
msgCPD3DC3 f/QLPRPCPR x/30E4 t/self
"Product 5770DE1 option 2 release V7R1M0 processing not complete.
... processing to complete saving or restoring library QDBXM
did not complete."
msgCPD3DFD f/QLPRPCPR x/30E4 t/self
"*PGM objects for product 5770DE1 option 2 release V7R1M0 not restored."
The Installation Exit Program QZXMMRMX for the feature [5770-DE1-02]
apparently failed due to a request to DROP PROCEDURE, DROP FUNCTION, or
DROP ROUTINE having been prevented by a mismatched file definition
[record format] for the SYSROUTINES file in QSYS2 as compared to the
level of the SQL run-time code used to effect the DROP activity; i.e. an
effective level-check. The columns that define that file apparently are
either down-level or up-level to the code, such that required changes
[ALTER] to the SQL catalog TABLE files in the Extended Base Option
either were _not applied_ whereas the OS SQL run-time code had been
updated or [less likely] were _applied_ whereas the OS SQL run-time code
had not been updated [i.e. what should be the pre-requisite PTFs had not
been applied, or had been removed; and thus why this scenario is less
likely].
Surely that implies a maintenance\PTF level-mismatch between the
OPTION(01) of the OS and the *OPSYS itself. As I had alluded in a prior
reply, given this is an install from a DSLO, my supposition is that the
DSLO image was created from a system on which the /background/
processing used to effect the updates to the OPTION(01) were not yet
applied; likely due to a failure of the post-PTF-apply to complete the
effective upgrade activity per some errors [likely logged in a system
job and left unreported to QSYSOPR or QHST, not as an impromptu message
nor as either of an /install/ message nor a /PTF/ message as something
obvious to look for] or due to the _loss_ of the request which should
have implemented the required upgrade activity. While a timing issue
versus a loss is possible, that is very unlikely.
midrange.com
