Hi,

can somebody explain me when does ttadv501, ttadv502, ttadv503 table gets entry in 000 co. ???

Regards

Learner

I may not be covering everything:

ttadv502: Whenever you make a change to a table (Maintain Table Definitions), that table and VRC are stored here.
Whenever you change a domain (Maintain Domains), this is updated for the package only.

ttadv501: Definately when you update a domain. Not sure, but also sometimes when you update a table.

ttadv503: If you convert to runtime fails an entry is made here. This is how it gets the message that you have a failed convert already started - continue?

There may be other times they are updated, but those are the most common. These are the tables that are used when issuing the 'convert to runtime' option. For the tables / domains to convert they must have entries here. Otherwise, run a full create runtime will convert things that are not flagged here, but obviously takes longer as it will run for all components in your range.

I can say when they are NOT updated, and that is when you Import table and domain changes. That's why you are unable to run convert to runtime for even simple table changes, and are usually instructed to run Create Runtime instead.

Just an elaboration to what Lisa said.

1. When domain / table is changed / created, records are inserted in ttadv501/502 both.
2. When user converts to runtime(ttadv5215m000). Following happens.
- it first creates runtime dd (.new file) domain or table dictionary and deletes the record in ttadv502.
- if the original dictionary and new dictionary (.new file ) are same , then .new file is deleted. And related domain/ table record from ttadv501 also is deleted.
- In case of domain changes, it determines the tables affected by change in the domain and creates record in ttadv501 for the tables affected and it deletes the domain record in ttadv501. Only if the datatype changes , physical length changes , addition /deletion of enum/sets options , change of alignment / conversion etc require the reconfig of the tables using the changed domain. Change of enum option description or change of domain description does not require reconfig of tables using such domains. Internally program run bdbreconfig -c to check whether reconfig of a table is required.
- Once the complete conversion activity is over and reconfig option also is chosen in ttadv5215m000 then the program starts reconfiguring the tables in ttadv501 . It creates temprorary R. file in $BSE for reconfiguring the table from the existing tables . It deletes the existing table completely if it's not used by anybody. If table deletion does not work it revert backs the same table. From the temporary file and new table definition it creates the table again. During this entire process the the record remains in ttadv503 just in case the process aborted , it can restart from the R. file and new dictionary. As the tables are reconfigured , the records are deleted from ttadv501. After the complete reconfig process , all relevant original dictionary files are copied to .old files and .new files are copied to original dictionary file.

Recently quite a few changes have been made in new porting sets for bdbreconfig . However broad process remains the same.

Hi,

Thanks for clearing up my concept. In case of any doubt i will revert back accordingly.

Regards

Learner

Hi Hitesh,

if they did some changes to bdbreconfig in regards to these tables, there must be a corresponding tools patch, right?

Otherwise bdbreconfig would expect certain vailues in these tables, which are actually filled by normal tools objects during customizations.

So you know about such a patch?

Regards

markus

Hi Markus,

There have been NO changes to these tables (ttadv501 - 3 till B40c SP12). We are on SP12 . I don't expect any changes in later SP's also though I don't know.

The changes have been in bdbrecong6.1 binary which comes along with porting set upgrade. The release notes of porting sets describes the errors resolved in the new porting set. Most changes are with respect to the error handling in bdbreconfig so that there is no loss of data at any point of time .

I think this clarifies ur question.

The changes which Hitesh mentioned were part of my case.

Here is more info-

Solution 141012
TOOLS VERSION(S):
7.1_a, 7.3_a

SITUATION IDENTIFIED IN:
"Convert to Runtime Data Dictionary" (ttadv5215m000)

SITUATION DESCRIPTION:
When a new unique index is added to a table, this may result in duplicates on this new index. Execution of session Convert to Runtime Data Dictionary with checkbox Reconfigure Tables checked, results in skipping of lines with duplicate index. No warning is given. Lines are simply removed.

SOLUTION DESCRIPTION:
A new option is introduced in session Convert to Runtime Data Dictionary "Ignore Errors". When this button is checked (the default situation) the session works in the old way (errors are ignored), when this button is not checked the tables with duplicate index won't be reconfigured. The errors are logged in the logfile log.bdbreconfig6.2. The user can get rid of the duplicates and do the Reconfiguration again.