On 21-Oct-2011 15:20 , Raul A. Jager W. wrote:
Really, I can not add the constraint, and the system reported some
damage in the object.
Again, expressions like "can not add the constraint" and "system
reported some damage" are not helpful to describe the situation in a
manner that allows the reader to give to you some assistance in
resolving the issue. That is like saying "my car will not run" and "the
check-engine light is on"; commentary which provides barely any
information to the listener\reader, limiting their ability to provide
constructive replies of assistance.
So, I need to do something. Either re-create
with DDS or do it with SQL (which I think it is better).
Unless there is a specific reason for one over the other, either
choice should be fine; either SQL DDL or DDS, to create the file anew.
If the record format level identifier needs to remain the same, then
there may be a reason to stick with DDS, or at least use DDS to create a
DDS LF which would replace the PF for RLA [Row Level Access, where
rcdfmt lvlid remains relevant] versus SQL access [rcdfmt lvlid is
irrelevant].
Maybe a RCLSTG will fix the file, but I prefer to re-create and have
it "clean".
And maybe a tune-up will fix the car. Random attempts at solutions,
instead of investigating the actual problem symptoms and the problem
origin, are not generally the best option. Re-creating the file is a
good idea, but investigation of the problem and its origin might be
worthwhile; without investigation, might the same problem just recur?
I consult the list to know my options, and get some advise.
Nothing wrong with that. However since there are problems with "can
not add the constraint" and "system reported some damage", perhaps
opening a PMR with IBM [or your service provider] to help investigate
the issue(s) might be worthwhile. I could probably assist [I used to
provide DB2 for i level-2 and level-3 support], but not with a dearth of
specifics on the symptoms for the failing requests.
In my prior reply I thought I had, but I failed to... suggest
creating the DDS PF in an alternate library, copying the data [in case
the failure was data-related], and then test adding the constraint to
the new file to verify that whatever problem prevented adding the
constraint on the "old" file does not also occur on a newly created
version of the same file.
Since the file had the 8 chars date, I expected to be able to create
it new with the same format.
And now hopefully understood to be impossible with SQL, to create a
TABLE with anything other than DATFMT(*ISO). And while the effective
"same format" is true irrespective of DATFMT(), I believe the date
format and the date separator are included in the hash which defines the
Record Format Level Identifier, because that attribute affects how the
RLA must interact with the database for I\O. So even though the DATFMT
is irrelevant to the SQL, just as the RcdFmt LvlId, any non-SQL access
may be impacted by a level check issue; at least if the PF can not be
replaced by a DDS LF which [may be able to] maintains the original
identifier.
I feel that by doing nothing I have a "worst problem waiting to
happen".
I did not intend to imply do nothing, nor would I suggest that. I
intended to suggest that the current problem might best be investigated
and then resolved. Though also having suggested that deleting the old
file and creating a new file [with optional data recovery] as recovery
should resolve, irrespective of any investigation of the current
difficulties and the origin of the problem.
Regards, Chuck
midrange.com
