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
