Did you, or anyone, ever experiment with a "guest partition"

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, December 17, 2013 4:23 PM
To: Midrange Systems Technical Discussion
Subject: RE: Upgrading R&D LPAR from V6R1 to V7R1 TR7

the "partition within a partition" is called a guest partition.
The one link is a 6.1 but it does kind of take you through it step-by-step. Of course, Pete Massieola(sp) did a webinar on this not too long ago and that would be worthwhile finding.

Rob Berendt
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755

From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
Date: 12/17/2013 04:06 PM
Subject: RE: Upgrading R&D LPAR from V6R1 to V7R1 TR7
Sent by: midrange-l-bounces@xxxxxxxxxxxx

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.

The <snipped> errors rewritten using some symptom strings:

¿ CPF9898 f/QSQPROC fm/QSQPROC fp/CLEANUP stmt/51749
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

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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2021 by 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.