IBM Zapp document

The name of the Z Project.

This helps people understand your project as it would be used by tools.

Version is a string and it must be parsable for managing dependencies.

Defines a group name that is shared for each application part in case of applications composed of multiple parts. Allows to uniquely identify the parts by concatenating with the artifact id. For example a groupId com.ibm.wazi with an artifactId service would create the unique application identifier com.ibm.wazi.service.

Define id of the application artifact. Use it in combination with a groupId for multi-part applications.

In case of a multi-part application defines the name of the parent application part. This zapp will inherit properties such as propertyGroups defined in the parent.

This helps people discover your project.

The url to the project homepage.

You should specify a license for your package so that people know how they are permitted to use it and any restrictions you're placing on it.

A person who has been involved in creating or maintaining this package

A list of people who contributed to this package.

A list of people who maintain this package.

A list of properties defining path names for resolving dependencies.

Profiles are additional groups of properties that should only become valid under specific conditions such as running in a build job or as part of a debug session.

The name of the property group, which is used in hovers and error messages.

Limits the property group to one specific language.

Global compiler options separated by a comma that impact the parsing of the programs for the editor. Requires that you specify a language. If there are multiple Property Groups for a language with compiler option then they will be concatenated.

An array of potential library locations defining the search order for include files. Libraries with the name 'syslib' will be handled as default include locations. The list can contain many entries of the type 'local' or 'mvs'. It can contain items of the same type twice in case, for example, you want to search in remote locations first, then some local location, and if still not found more remote locations.

Name of the library. The default name should be syslib if using unnamed libraries.

The type of the property group defining where dependencies should be located. Allowed values are 'local' for using a local workspace and 'mvs' for dependencies located in MVS data sets.

An array of include file locations. For 'local' libraries values can be absolute and relative filename paths using GLOB patterns. For 'mvs' libraries value can be data set names. GLOB patterns for data sets are currently not supported.

The name of the profile.

The type of the profile.

If the profile type supports it then it defines a scope for the profile to one specific programming language. For example, a profile that defines preprocessor commands for COBOL.

If the profile type supports it then it defines a scope for the profile to a specific location for resources. For example, a profile that defines preprocessor commands to be executed on MVS or local files.

Settings objects specific to the type specified for the profile.

Defines the name of the application to build. Will be used to create a folder on USS to upload all files to.

Command that the build script is executed with such as the path to groovyz and it's parameters.

The full path of build script on the remote host that should be used with the command.

A list of strings that are the parameters for the build script. Check the documentation for built-in variables, such as the name of the program to build, that can be used here.

Lists of GLOB patterns that define the files that should be uploaded to USS for a build. Relative path names are interpreted relative to the location of the ZAPP file that is being used for the build, which is a ZAPP file in the same workspace as the program to be build.

Lists of GLOB patterns that define the files that should be downloaded from USS after the build. Relative path names are interpreted relative to the DBB log directory user setting. If not provided then all files of the user setting location will be downloaded.

Command that the build script is executed with such as the path to groovyz and it's parameters.

Defines named build lifecycles that represent different build scenarios the customer needs to perform and can be executed from the DBB CLI.

Additional arguments and options for the lifecycle.

Lists of GLOB patterns that define the files that should be uploaded to USS for a build. Relative path names are interpreted relative to the location of the ZAPP file that is being used for the build, which is a ZAPP file in the same workspace as the program to be build.

Lists of GLOB patterns that define the files that should be downloaded from USS after the build. Relative path names are interpreted relative to the DBB log directory user setting. If not provided then all files of the user setting location will be downloaded.

A list of mapping objects that map local file extensions to transfer modes and encodings to MVS data sets that can be specified using wildcards.

The encoding to be used when no mapping can be found. If not provided then either the user or server default will be used.

A local file extension such as cbl or pl1.

The transfer mode to be used. Can be 'text' or 'binary'.

The data set name to be mapped to. Can use a wildcard such as '**CPY'.

The encoding to be used for text transfer. See the RSE API documentation for the values allowed.

A nested mappings array with resource mappings to members of the data sets that were mapped by the parent mapping.

The command to run to execute the preprocessor executable.

Path where preprocessor produces its build output.

The desired file extension for the post-processed file.

Specifies any user defined environment variables to be passed to the preprocessor.

Specifies an input listing sequential data set.

Specifies an output listing sequential data set.

Specifies the high-level qualifier used for data sets created by plug-in requests to export observation files.

The parameters for the command being run.

Specifies the data set where local programs will be uploaded for preprocessing.

Type of application that will be recorded.

Provide a path to a JCL file that runs the application to be recorded.

Provide name of the program to capture.

Provide a transaction id to capture in the recording.

The workspace-relative path to an application source file.

The z/OS load module name that corresponds to the specified source file.

Required if recording and replaying DB2 statements.

If recording a CICS application, specify a CICS region where the application is running.

If recording a batch application, specify the data set where Debug Test Engine load library is located.

If recording an IMS application, specify the subsystem id.

Specify what to capture in an application.

Specify host settings for the recording tool.

Specify which application load modules correspond to application source files.

Specify settings for the recording application tool.

Properties to run a unit test case.

Specify settings for the functional test.

Specifies the list of Procedure libraries.

If this option is selected, the data set for the working file is allocated automatically with the allocation options.

Options to allocate a working file.

Runner configuration destination container.

Runner result destination container.

The datat set of the application under test.

The default local folder to create the test case artifacts.

The job card to run a unit test.

If recording a CICS application, specify the cicsts.dse.tag from the .galasa/cps.properties file.

If recording a CICS or IMS application, specify the zos.dse.tag from the .galasa/cps.properties file.

If recording a CICS application, specify the Db2 DB ID that was established when the Db2 instance was created.

If recording a CICS application, specify the db2.dse.schema.PRIMARY.name from the .galasa/cps.properties.

If recording a CICS or IMS application, specify the zos.image.x.credentials value from the .galasa/cps.properties.

If recording an IMS application, specify the imstm.dse.tag from the .galasa/cps.properties.

If recording an IMS application, specify the dli.database.tag.{imsTag}.datastore value from the .galasa/cps.properties.

Specify the path to the default test case folder.

Specify the code pages to be used.

Specify an array of local BMS files.

Specify an array of local MFS files from the mfs-maps directory to be used for generating accurate test files. Ex: sample.mfs.

Specify an array of local Db2 Config files.

Specify settings for the functional test substitution map.