Concept

Before the implementation and modeling can be started, you must design a concept for how an MVS Projects Application should be connected to Eclipse using the AWM. Consider the following questions:

1. What structure should the Tree view have (container element types)?
   • How deep should the hierarchy go?
   • What properties are relevant for the application per container element type?
2. What other element types are there?
   • How fine should the difference between the element types be?
   • What properties are relevant for the application per element type?
   • What properties make an element unique (ID definition)?
3. How does a user want to search for elements (filter type)?
4. How should elements be shown in the Element Table view (element list structure)?
   • Which properties are to be defined as columns? The performance of the available tools for the determination of the table contents must be considered here. 
5. What actions are needed (action, tool descriptor)?

These questions have been answered and implemented as follows for the example AWM model:

1. The first level of the tree view should show a fixed entry “MVS Projects”. It should be possible to add entries, for example, Enterprise Development COBOL Project(s), if required.

   The second level should contain entries for mainframe data set filters, which a user should be able to define in a dialog. It should be possible to define a filter name, filter criteria and to associate default syslib data sets for COBOL, PL/I and maclib data sets for Assembler.

   The third level should show the data sets retrieved based on the filter criteria with supported properties like volume, organization, record format, record length, block size, creation date, last used date.

   The fourth and last level should display the member list for PO data sets. Member properties like creation date, change date, change user, version, modification level and member size should be supported. The following picture shows the expected result of the modeled tree view. 

   
   
   
2. You can expect different properties and actions depending on the data set organization. Different element types have been defined for each supported data set organization; PO, PS, and DS migrated.
3. What identifies an element? The static entry "MVS Projects" is identified by its name, a defined data set filter is identified by its filter criterion, a data set is identified by its name, and a PO member is uniquely identified through the data set name and its member name.
4. The user should be able to use generic symbols (* %) when he searches for data sets or member names.
5. The setup of the element list structure for PO members should contain columns like the member name, date created, date and time modified, change user, file suffix, and member size whereas a data set list should contain columns like the data set name, type, organization, record format record length, block size, default suffix and others. The following picture shows the expected result of the modeled table entries.
   
   
   
   
6. The following actions should be supported:
   • In the static entry "MVS Projects" you need an action to insert a data set filter and an action to show the next level of the tree view, the defined filters.
   • In a defined filter you need actions to update the filter properties, delete a filter and to show the data sets either in the tree or table view.
   • In a PO or PS data set, you require actions to rename/delete and to copy/paste a data set.
   • In the PO data set you need actions to insert a PO member, to execute a text search within members and to show the contained members either in the tree or table view.
   • On the PO member level you need actions to edit, browse, delete, rename and duplicate a member. In addition you want to support remote syntax check (a compile on the mainframe with error feedback) and would like to manage member specific syslib data sets.

     In addition, you require actions to copy/paste PO members.

7. It should be possible to manage data set filters not only in the tree but in the filter. The execution of a data set filter defined in the filter view should create a member list in the table view with the same structure as defined above.
8. The result of a PO data set text search should be displayed in a tree table format including entries with the member lines where a text was found. It is necessary to define an additional element for this member record which is identified by data set name, member name and member line number. The following picture shows the expected result of the modeled tree table entries.