Thanks Chuck for your comprehensive reply.
I will try your suggestion.
Regards,
Adam Mills
Snr Technical Consultant, Island Pacific
Direct: +44 (0)7739 941855
Any reference to or discussion regarding existing contracts in the body of this email will not otherwise alter the terms and conditions of our existing contracts - which other than any temporary change described in the body of this email remains in full force
-----Original Message-----
From: CRPence [mailto:CRPbottle@xxxxxxxxx]
Sent: 25 May 2012 17:41
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Table Definition in System i Navigator V6R1
On 25 May 2012 08:58, Adam Mills wrote:
I think you have identified the problem.
When I run your query on my V6R1 partition I only have one result row
as follows.
SYSTEM_TYPE_NAME
ROWID
******** End of data ********
On my V5R4 partition I see all the types as per your list.
What should I do to correctly populate the SYSTYPES table in V6R1?
I would prefer that the origin of the problem be investigated first.
Possibly the effect is the result of an incorrect [install\upgrade with] data migration. The library QSYS2 is one of the pseudo-user [quasi-system] libraries; i.e. system libraries that contain user data.
Thus any data migrations should avoid mucking with those libraries except when the target system has installed only the LIC and the OS, nothing more. So minimally the files in library QSYS2 should be reviewed for any "Old name ..." in the TEXT. Before performing any "change" activity, probably best to gather potentially valuable diagnostic information like spooled output from each of: DSPFD
QSYS2/SYS* [and QASQ*], DSPOBJD QSYS2/SYS* [and QASQ*] *FILE [*SERVICE and *FULL], DSPOBJD QSYS2/*ALL *PRDLOD [*SERVICE and *FULL]. Also before any attempts to recover, use the feature to check the status of the *DBXREF [System Database Cross-Reference], to ensure there are no errors [for the library QSYS2]; RCLDBXREF OPTION(*CHECK) LIB(*ERR) and possibly also RCLDBXREF OPTION(*CHECK) LIB(QSYS2) if the prior gives an error versus a list.
The RSTLICPGM *OPSYS OPTION(01) will [at least used to, when I enhanced the install code for that option] reset the data in SYSTYPES from the data in the database file QASQTYPE [an effective 'model' file with data]. The design of the installation [assuming the files are not completely mucked] is that [most of] the catalog files are "created"
versus "shipped\restored", thus simply saving the current installation and then restoring from that save will generally effect recovery of the catalog files while maintaining the existing user data. The most basic requirement then, for restore from the current version, is that the file QASQTYPE must have the expected data.
So if there are no files previously affected by an improper data migration [i.e. restores into QSYS2 using ALWOBJDIF(*ALL)], and no apparent data loss for file QASQTYPE, then the following is probably going to effect recovery:
/* Notes: naming with ## replaced is just my convention */
/* *opsys is not a valid special value, replace with */
/* the appropriate 57##SS1, for the installed OS */
crtsavf qgpl/Q57##SS101 text('savlicpm *opsys option(01)')
/* while in restricted state, or no active SQL dependent on */
/* the data in QSYS2 is active [mostly function resolution] */
savlicpgm *opsys *savf option(01) savf(qgpl/Q57##SS101)
rstlicpgm *opsys *savf option(01) savf(qgpl/Q57##SS101)
Regards, Chuck
midrange.com
