Maintaining the AWM Model

A suitable way to maintain an AWM is to define a test application in the master configuration file.

One way to test model modifications is to specify a local file path for the AWM in the master configuration file. This should point to a project in the administrator's workspace. See Setting up and Configuring AWM for more information. This is so that the project can conveniently maintain the file with the Model editor. It is also possible to make use of the file suffix .model, as the file can be directly opened with the Model editor.
Application cache

For example, the conf attribute of the Master Configuration for a local test AWM:

local: c:\config\repository.model

Note: Consider the following points when maintaining and testing this application:

The AWM is copied when loading the test application and uses the copy at run time. You should be familiar with the rules that cause an application to be loaded. In particular the remarks regarding the version number in Variable References and Master Configuration. A revised AWM is only loaded if the version number of the application in the master configuration is different from the version number in the modeled application options.
You can initiate a load of the application for testing by targeted modification of the version number in the master configuration and in the application options.
If ISPF tools that should be verified in the test environment are also changed during maintenance of the AWM, the ISPF test environment can be dynamically allocated for this application with the exit TAUTOXA1. See ISPF Exits, and EXITPARM in Variable References for more information.

Certain changes to an AWM that has already been used could lead to the existing cache no longer being compatible with the AWM. In particular the removal of properties and the modification of IDs. The results are errors at run time and as a rule occur when loading the application.

The parts of the caches that must be deleted can be specified in the master configuration through the entry of a new version. See Master Configuration for more information. If the effects on consistency as a result of the changes carried out are not absolutely clear to the user, a test must be carried out to determine which parts of the cache have to be deleted in the case of an update. In order to do this, the most important components of the cache must first have been generated in the existing AWM. This requires the following actions to have been carried out at least once:

Loading an application.
Identifying containers, the expansion of the application is sufficient.
Creation of a filter.
Creation of an element list, for example, by carrying out the filter action.
Opening an element in the editor.
Restarting Eclipse.

If errors still occur when loading a new version, a number of components have to be deleted in the cache, entries in the master configuration.

If a situation arises when testing that makes the automatic deletion of the cache by the entry no longer possible in the master, the cache can be deleted manually at any time.

The figure above shows the complete cache of an application in the Navigator view. The individual files have the following descriptions:

File name	Description	Critical changes
eb_elementsinlists.xml lm_Element List s.xml li_LI_<listID>.xml et_elements.xml	Contain all the information stored about elements and element lists. Deleting the files removes all element lists and the cached information about elements. They should always be deleted together, or inconsistencies could arise.	Changes to ID definitions, element list structures, elements and all their relationships.
tv_tableviewlists.xml cs_columnsetting.xml er_errorFeedback.xml	Contains all the information about showing element lists on the user interface. Contain all the information about columns of a Table Results view. Contains errors that have been generated by means of the integrated tools Error Feedback. All the error entries of the Error List are lost when the file is deleted.	None None None
ft_filters.xml	Contains all the filters defined by the user. All the filters are lost if the file is deleted.	Changes to filter types and their relationships.
ft_openfiles.xml	Stores references to all files that the user had open when leaving the application in the editor. Once this file has been deleted, a restore of editor changes after an application restart is no longer possible.	None
jt_jobs.xml	Contains all submitted and finished jobs. All the job information is lost if the file is deleted.	None

Even if the Navigator view supports the deletion of files in principle, the cache must be directly deleted from the file system after closing Eclipse. Otherwise, the cache is rewritten when leaving Eclipse, this is because the cache is exclusively created on Close. The Navigator view can be used to locate the cache from the Properties view, see the figure below:

Determining the file path of the Cache

If all changes to a new AWM have been tested locally, they can be released for all users. The following steps must be followed:

Increase the version number of the new AWM.
Adapt the master configuration file:
- Compare the version number with the new AWM.
- Where necessary, supplement the INFO entries for the deletion of the cache.
Update the central AWM.