Default

Enhanced Definition

In the context of mainframe and z/OS, a **default** refers to a pre-assigned value, setting, or action that is automatically used by the system, an application, a utility, or a programming language when no explicit alternative is specified by the user or programmer. It provides a standard, assumed behavior or value, reducing the need for exhaustive specification. In the mainframe and z/OS context, a **default** refers to a pre-defined value, setting, or action that a system, program, utility, or command assumes if no explicit alternative is specified by the user or developer. It provides a standard, often sensible, behavior or value when an option is omitted, aiming to simplify usage and ensure predictable outcomes.

Key Characteristics

- Pre-defined Behavior: Defaults are established by the operating system (z/OS), specific utilities, compilers (e.g., COBOL), or application programs to ensure a baseline operational state.
- Implicit Usage: They are invoked automatically when a particular parameter, option, or variable is omitted from a command, JCL statement, program code, or configuration file.
- Overridable: Most defaults can be explicitly overridden by providing a different value or option, allowing for customization when the standard behavior is not desired.
- Context-Specific: The specific default values and behaviors vary significantly depending on the context, such as a JCL parameter, a COBOL compiler option, a DB2 subsystem parameter, or a CICS system initialization parameter.
- Consistency and Simplicity: Defaults help maintain consistency across operations and simplify coding and configuration by allowing users to omit common or standard specifications.

Use Cases

- JCL DISP Parameter: When creating a new dataset, if the second subparameter of DISP is omitted, the default is often DELETE (e.g., DISP=(NEW,DELETE) is the default if only DISP=(NEW) is specified for a temporary dataset).
- COBOL VALUE Clause: If a PIC clause item in COBOL is not initialized with a VALUE clause, its initial content might default to spaces for alphanumeric items or zeros for numeric items, depending on compiler options and storage class.
- Sort Utility Parameters: A sort utility like DFSORT might have default sort keys (e.g., ascending EBCDIC) or default output dataset characteristics if not explicitly specified in the SORTIN or SORTOUT DD statements or control cards.
- DB2 Subsystem Parameters (DSNZPARMs): Many DB2 operational settings, such as buffer pool sizes, locking timeouts, or logging options, have default values that are used if not explicitly changed in the DSNZPARM module.
- CICS System Initialization Parameters (SIT): CICS regions use default values for various operational aspects like transaction classes, storage limits, or security settings if not overridden in the SIT or through system programming interfaces.

Related Concepts

Defaults are fundamental to the concept of system configuration and application development on z/OS. They interact closely with explicit specifications, where a user or program provides a specific value to override the default. Understanding defaults is crucial for JCL processing, as the z/OS JES (Job Entry Subsystem) relies heavily on them for dataset disposition, job class assignment, and resource allocation. In programming languages like COBOL, defaults influence data initialization and compiler behavior, impacting program logic and execution. They are also integral to utility execution, where standard operations are often performed without extensive parameter input.

Best Practices:

Understand and Document Defaults: Always be aware of the default behaviors for critical JCL parameters, utility options, and application settings to avoid unexpected outcomes. Document any deviations from defaults.
Explicitly Specify Critical Parameters: For clarity and maintainability, it is often a best practice to explicitly specify critical JCL parameters (e.g., DISP, UNIT, SPACE) or program options, even if they match the default, especially in production environments.
Be Aware of Version Changes: Defaults can change between z/OS versions, utility releases, or compiler levels. Always consult the relevant IBM manuals for the specific version you are working with.
Avoid Relying on Undocumented Defaults: Never assume or rely on undocumented default behaviors, as these can change without notice and lead to unpredictable results.
Use Defaults for Simplicity: When the standard, default behavior is precisely what is desired, leverage it to simplify JCL, code, or configuration, reducing verbosity and potential for errors.