Glossary

air-gapped environment: A secure network that is physically isolated from insecure networks, such as the public Internet or an insecure local area network.

build dependencies: DBB tracks three types of build dependencies:

Direct build dependencies
Indirect build dependencies
zUnit Test build dependencies

Build Manager: Starting from DBB V1.0.9, it is renamed to shared daemon. See daemon and shared daemon for more explanation.

build report: A JSON file that contains summary information of the build commands executed during the build. The build report is generated as a JSON file on the local file system at the end of the build and can be rendered as an HTML file with customized format to be viewed in a browser.

build result: Build metadata that are collected during the build and stored in the DBB Web App database. The build metadata include:

Build state
Built status
Build report
Additional file attachments such as log files
Simple information in the form of name-value pair properties

build state: The current state of the build, that is, whether it is running or it has completed. The values can be NEW, PROCESSING, COMPLETE, and ABANDONED. It is a field in the build result.

build status: The status whether the build was successful and everything was compiled cleanly or failed for some reason. The values can be CLEAN, ERROR, and WARNING. It is a field in the build result.

daemon: A tool that can be used to improve performance on IBM z Systems Development and Test Environment (ZD&T), or whenever Java startup time needs to be reduced. There are two forms of the daemon, the shared daemon (known as Build Manager before DBB V1.0.9) and the personal daemon.

dependency collection: A container for the logical files that you access from the metadata store.

dependency resolution rule: A match criterion (lname, category, library) and a search path in the collection of where the dependency file is located.

direct build dependencies: The references in z/OS programs to other source files that are needed by the compiler to build the program. Examples of such references are the COBOL COPY, the PL/I %INCLUDE, the C #include, SQL INCLUDE, and the Assembler macro reference.

DBB configuration properties: Name-value pairs of type string that are applied to some DBB APIs so that you do not need to code them explicitly on each declaration of these DBB APIs in the build scripts. DBB configuration properties are useful because some DBB APIs, such as RepositoryClient and ISPFExec, require configuration-like properties to be set on each declaration; however, these properties are often the same for all declarations and never change during the build process.

DBB toolkit: An SMP/E installable component that provides a set of Java APIs that can be used to define a build script for traditional z/OS applications, such as COBOL and PL/I.

file properties: Name-value pairs of type string that contains :: as a delimiter between the property value and the comma-delimited list of file path patterns use to indicate which files the property is associated to. File properties are useful in cases where some source files being built need to be handled differently than the rest of the source files.

full build: A basic type of build that builds the entire application. Another build type is the incremental build.

impact analysis: The process of identifying which programs in an application are impacted by code changes to copybooks or include files. If a source file is changed and rebuilt, impact analysis can determine other sources that need to be rebuilt as a result of that output changing.

incremental build: An advanced type of build that uses impact analysis to only build programs that are determined to be out of date. The programs are out of date either because the program has been modified or a copybook or include file that it uses has been modified since the last time the application was built.

indirect build dependencies: Relationship between the program source and the outputs from previous build processes. While indirect dependencies are not considered during dependency resolution, they are a factor in impact analysis.

logical dependencies: Dependency information of the scanned files that is collected by the source file scanner DependencyScanner and the link-edit scanner LinkEditScanner.

logical file: The result of scanning a source file. It contains the logical dependencies for that source file.

metadata store: A DBB component that is used to access and delete the DBB collections and build results that are stored either on the z/OS UNIX file system or in Db2 LUW or Db2 for z/OS databases.

personal daemon: A daemon that is started and used by a single user. Users have their own personal daemon. The other type of daemon in DBB is shared daemon.

physical dependencies: Dependencies resolved in the local file system. The logical dependencies in a program's logical file must be resolved to physical files in the local file system so that DBB can copy the latest versions to data sets for inclusion during compilation.

properties: Name-value pairs of type string that are defined outside of the build scripts and are either loaded (read) from a file or passed in as command-line arguments.

public repositories: Git repositories that contain DBB samples of scripts, snippets, and applications.

sandbox properties: Name-value pairs of type string used to defines user sandbox, where the user can store modified source code and generate build outputs without overwriting anyone else files or data set members.

shared daemon: A daemon that can be used by multiple users. The shared daemon must be started before any user trying to start a build that uses the shared daemon. The other type of daemon in DBB is personal daemon.

System Management Facility (SMF): A tool used to collect and record system and job-related information that can be used for billing, analyzing, scheduling, and etc. The full name is z/OS MVS System Management Facilities. DBB provides the capability to write SMF records when running a script that uses DBB functionality.

zUnit Test build dependencies: The dependency relationships between the z/OS source program, the zUnit test program, and the playback data file. These dependency relationships can then be used by DBB build scripts to automatically copy zUnit test case files from the local Git repository to partitioned data sets to execute zUnit test cases as part of a pipeline build. These dependency relationships also allow DBB to run zUnit test cases incrementally when the z/OS program changes or when the related test program or the playback file is modified.