× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



IBM finally got back to me about my V7R1 upgrade issues, using a combined DSLO image.
My image was missing a PTF Si50242.

I need to recreate my DSLO image, however, I don't have a partition with a clean QGPL and QUSRSYS.
I read once that you can create a partition within a partition.
I have 3 choices.
1) Scratch install my test partition where I originally created the image, (I really don't want to do this, lose all the configuration)
2) Try and cleanup QGPL and QUSRSYS, so they appear like what a scratch install would produce.
3) Create a new partition for the DSLO image from a "hosted" partition. (Not sure of the complexity of this)

Any tips on creating a new combined (OS and all PTFs) DSLO V7R1 image

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, November 27, 2013 2:33 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Upgrading R&D LPAR from V6R1 to V7R1 TR7

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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.