Regenerating Entries

When an Entry is created or generated the following dependencies (rows in the table) are important:

Database file	Entry	Data retrieval program (optional)
File name	File to access	File to access
Record format name	Record format to access	Record format to access
Key fields	Formal parameters	Program parameters
		Key selection data returned with call to ISNDDTA
Fields	Screen fields
	Entry fields	Result returned with call to ISNDDTA
Record length	Record Length
	PGM data retrieval (optional)	Program name

If for instance a field definition in the database file changes, the corresponding Entry field must be changed accordingly, which might also require the data retrieval program to be changed. If the change of the field definition was only the change of its type without changing its length, then the program need not be changed if the program was a generated C-program because this references individual fields only type-independent. But if the program was a generated RPG or Cobol program it has to be changed depending on the exact type change.

It is not possible to give an exact recipe for what to do when something changes because the number of possible changes is too large. In most cases it would be much simpler and faster to recreate the Entry from scratch. This has one big disadvantage: Entries do not only exist in a DID-source; Entry-Subentry relations may be defined as well. If an Entry is deleted prior to recreation all Entry-Subentry relations the Entry played a role in are deleted as well. To prevent the loss of Entry-Subentry relations the possibility to re-generate Entries is available: options Option "61=Check re-generation of entry" and "62=Re-generate entry" on the panel Work with Entries.

Re-generation reads the current definition of the Entry and compares it to a complete recreation of the Entry. It tries to match field and formal parameter definitions and detects differences, keeping as much from the existing Entry (like field names) as possible. Option "61=Check re-generation of entry" does not change anything but presents a report of the differences and changes in a spool file, whereas option "62=Re-generate entry" actually changes the Entry.

Note that there are decisions the re-generation process cannot make. The re-generation process for instance has no means of deciding whether any of the original Formal parameters or Fields were dropped or deleted, or new Formal parameters or Fields were added. In this case the re-generation process assumes that new Fields were added, and they have to be dropped or deleted manually again after re-generation.

Another issue is when the DDS name of a Field in the database has changed. The re-generation process then decides that the Field with the old name was deleted and a new Field was added. This is especially important because Formal parameters and Fields play a role in the Entry-Subentry relations. Only where a Formal parameter or the Field used in an Actual parameter has not changed the re-generation process can guarantee that the Entry-Subentry relations are still valid. It is therefore always a good idea to do a "Check DID-source" from the panel Work with DID-sources after re-generating Entries. On the panel Work with Sub entries there is also the possibility to do a "Check sub entry", and on the panel Work with Actual parameters the function Synchronize exists.

Also note that the re-generation process doe not include the re-generation of any data retrieval programs; just use option "25=Generate Data retrieval" again.