If you do not want users to have a mainframe connection when working with the Workflow Manager, they can use a local master configuration file or default configuration.
A local master configuration file can either be located in the Eclipse root folder with the name MasterConfig.xml or MasterConfig.txt depending on its format. See Master configuration syntax for more information. Alternatively, a master configuration file can be returned by a local operating system command. See Master Configuration for more information. In this case, a local system reference can be created in the Application Explorer view:
This opens the Add System(s) dialog box.
Expanded the local system reference to view all the applications defined in the local master configuration file.
If any application of a local system reference contains mainframe-dependent actions, or the model of one of the applications is stored on the mainframe, you must add the mainframe connection to the local system reference, by right-clicking the local system reference, and then click Associate Remote System, see the figure below:
After you have associated the remote system, the label of the local system reference changes and the Properties view shows properties of the selected remote system. The context menu now shows the Remove Associated Remote System command. A local system reference with an associated remote system acts like a remote system reference, except the local master configuration is not provided via the mainframe.
The master configuration can be defined in one of two supported formats: flat format and XML. Both formats use the same keywords. The table below lists all available keywords and their descriptions.
The XML format is currently only supported by local system references, meaning that master configuration files located on the mainframe must be defined in flat format.
The flat format master configuration consists of lines with keywords, together with the respective values. The keywords are separated from the values by a colon and at least one space.
For example, a row in the master configuration file might look like this:
System: System_nameLines beginning with an asterisk (*) are interpreted as comments.
Flat format | XML format | Description |
---|---|---|
System | <System> | Name and identifier of the remote system as it is displayed in the Tree view. It is used as a unique identifier for caching application data, so changing the name in a productive system is not recommended. |
Appl | <Appl> | Name and identifier of the modeled application as it is displayed in the Tree view. |
Conf | <Appl conf="…"/> | Platform, path and name of the model file. |
Version | <Appl version="…"/> | Version of the model file. |
INFO | <Appl info="…"/> | Optional. Information about the data that is deleted for consistency in the Eclipse Workspace when loading a new version of the model. |
User | <Appl user="…"/> | Limits the corresponding application(s) to one or more RACF users. Multiple users can be separated with spaces. |
Property: <Property ID>=<Value> | <Property propertyID="…" value="…"/> | Static property values for an application. |
EndUser | Not required | End of a user limitation. |
EndAppl | </Appl> | End of an application description. |
Parmfile | Not required | Optional - This is the name of the remote parameter file that is used to transfer long parameters between the client and
the remote system when executing remote commands. The name may contain property references.
If the parmfile option is not specified, the standard name of the parameter file is <userid>.TAURUS.PARMFILE. |
Any number of modeled applications can be listed for a system. The master configuration file must have at least one application defined.
The Conf entry consists of the specification of the platform together with the platform-dependent fully-qualified or absolute file name. Permissible platform designations are local and mvs.
local:c:\config\config.xml (Windows)
The INFO entry determines which persistent information held in the Eclipse workspace have to be deleted in the case of a version change of the modeled application. Permitted information are filters and elements. The information can be combined in any way.
INFO entry | Deleted files | Content of the files |
---|---|---|
filters | ft_filters.xml | All filters in the application |
elements | et_elements.xml
eb_elementsinlists.xml li_<listid> lm_Element_Lists.xml |
All cached elements that are assigned to the application and all element lists in the application |
For example, a master configuration file in XML format:
<?xml version="1.0" encoding="UTF-8"?> <System name="My Local System"> <Appl name="My Application" conf="local:C:\Models\MyApplication.model" version="1.0" info=""> <Property propertyID="PROP_UserRole" value="ADMIN" /> <Property propertyID="PROP_Environment" value="TEST" /> </Appl> <Appl name="SCLM Application" conf="MVS:HLQ.APPLS.MODELS(SCLMPROD)" version="2.1" info="" /> </System>
For example, a master configuration file in flat format:
System: My System * * PDS EXPLORER EXAMPLE APPLICATION * User: * application name Appl : PDS Explorer * location of the application configuration file Conf : mvs:'hlq.ZSERVER.XML(PDSECONF)' * application version number Version: 1.1 * process information
A local master configuration can be returned dynamically by an operating system command. The command, which could, for instance, execute a script file to return the configuration, must be specified with the "teamdeveloper.masterconfig" Java system variable. See Setting Java System Variables for more information.
The value of the variable must contain an operating system command, which returns a complete master configuration file in XML format to standard out when executed.
For example (Windows):