Re: SQLRPGLE create table

Sorry I could not find more information about the cause of the problem.
I tried to add a constraint and I got a message: "Can not allocate object". Since I knew for sure that nobody else was using the table, I digged in the joblog and I found as probable cause that the object is damaged, but I did not found the reason why. I suspect it was damaged when the electricity went out and the UPS died before the generator started, but I can not prove it. At that time other file in the same library got badly damaged I could not read it, so I had to delete it and restore a back-up.

I agree that it will be very good to know the real cause, and your comparation with the car is good. But, getting a new car will fix the problem, if it only was as cheap as re-creating a file.

CRPence wrote:

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