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
First steps), 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.
Example: Conf attribute of the Master Configuration for a local test AWM
- local: c:\config\repository.model
Note the following for the maintenance and test of this application:
- The AWM is copied when loading the test application and uses the copy at run time. The user should therefore be familiar with the rules that cause the loading of an application (see in particular the remarks regarding the Version number in
Variable references and
Master configuration). Note in particular that a revised AWM will only be loaded if the Version Number of the application in the master configuration is different from the version number in the modeled application options.
- The user can initiate the loading of his application for testing by the 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 also EXITPARM in
Variable references).
Certain changes to an AWM that has already been used could lead to the existing cache no longer being compatible with the AWM. This includes in particular the removal of properties and the modification of IDs. The results are error situations at run time (as a rule 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).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 will have to be deleted in the case of an update. In order to do this, the most important components of the cache must have first been generated in the existing AWM. This requires the following actions to have been carried out at least once:
- Loading an application
- Identifying containers (expansion of the application sufficient)
- Creation of a filter
- Creation of an element list (e.g. by carrying out the filter action)
- Opening an element in the editor
- Restarting Eclipse
If errors then occur when loading a new version, a number of components will 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 meanings:
| File name
|
Meaning
|
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 Team Developer Table View
Contains errors that have been generated by means of the integrated tools Error Feedback.
All the error entries of the Error List will be lost when the file is deleted.
|
None
None
None
|
| ft_filters.xml
|
Contains all the filters defined by the user.
All the filters will be 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 will be 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 will be rewritten when leaving Eclipse (as the cache is exclusively created on Close). The Navigator view can nevertheless be used as Help, however, by simply copying the path of the cache from the Properties view (see the figure below).
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.
