Zowe Schema Validation And SDSF User Considerations

Introduction

This document delves into the discussions surrounding schema changes and SDSF (System Display and Search Facility) user considerations within the Zowe project. Specifically, it addresses the recent updates to schema validation, the implications of allowing empty or null values for optional keys, and the strategies for handling SDSF user requirements during Zowe initialization (zwe init). This comprehensive analysis aims to provide clarity and guidance for developers and users navigating these aspects of Zowe.

Understanding the complexities of schema validation and SDSF user management is crucial for maintaining a robust and user-friendly Zowe environment. This document will explore the issues, proposed solutions, and future directions for these critical areas.

Schema Changes: Allowing Empty and Null Values

The Initial Problem

As highlighted in issue #4384, the Zowe schema initially permitted the use of empty strings or null values for optional keys in YAML configuration files. This flexibility, while seemingly convenient, introduced complexities in code handling and validation. To address these issues, the schema was updated to reject empty or null values, enforcing stricter data integrity. This change, however, was marked as a breaking change, potentially disrupting existing configurations and workflows.

The Reversion and Its Rationale

In response to the breaking change designation, a decision was made to revert the schema validation to once again accept empty or null values. This reversion is intended to minimize disruption to users and maintain compatibility with existing configurations. However, this is a temporary measure. The long-term goal remains to properly handle optional keys and ensure data integrity.

The Proposed Solution: Manual Defaults and Code Updates

The current strategy involves reverting the schema validation while simultaneously addressing the underlying issues in the codebase. This includes:

1. Re-enabling acceptance of empty/null values: This ensures that existing YAML configurations, such as the example provided, remain valid.
2. Reviewing and updating code: The codebase needs to be thoroughly reviewed to identify areas where empty or null values are used and ensure they are handled correctly. This may involve setting default values manually within the code, rather than relying on the schema.
3. Manual Default Settings: Instead of depending on files/defaults.yaml for default values when keys are empty or null, the code will be updated to manage default settings directly.
4. Targeted YAML Validation: Ensuring that the YAML remains valid across Zowe versions (3.2.0, 3.x, and staging) is a priority.

The objective is to achieve a balance between maintaining compatibility and enforcing data integrity. By reverting the schema validation temporarily and implementing code updates, Zowe can gracefully transition to a more robust system.

YAML Example

The following YAML snippet illustrates the type of configuration that needs to remain valid:

zowe:
  setup:
    dataset:
      prefix: 
      parmlib: 
      jcllib: 
      authLoadlib: 
      authPluginLib: 
    security:
      groups:
        admin: ~
        stc: ''
        sysProg: 
      users:
        zowe: null
        zis: 
      stcs:
        zowe: 
        zis: 
        aux: 
  sysMessages:
  - ~
  - ''

This example demonstrates the use of empty strings ('') and null values (~, null) for various configuration options. The challenge is to ensure that Zowe can correctly interpret and handle these values.

Handling empty and null values correctly in configuration schemas is essential for maintaining the stability and usability of Zowe. A well-defined strategy for managing these values ensures that the system behaves predictably and that users can configure Zowe effectively.

SDSF Users: Requirements and Alternatives

The SDSF Dependency Question

The second major topic of discussion revolves around the dependency on SDSF for Zowe operations, particularly during the zwe init process. SDSF is a powerful tool for managing and monitoring z/OS jobs, but not all Zowe users may have access to it or require its functionality. This raises the question of how to handle users who do not have SDSF.

Proposed Solutions and Considerations

Several options have been proposed for addressing the SDSF dependency:

1. Do Nothing: This option suggests leaving the current behavior unchanged, meaning that SDSF would continue to be a requirement for certain Zowe operations. This is the simplest approach in the short term but may limit the accessibility of Zowe for some users.
2. Change Documentation: This approach involves updating the documentation to clearly state that SDSF is a prerequisite for zwe init. This would manage user expectations but does not address the underlying issue of the dependency itself.
3. Move or Rename zwe init: This option suggests moving the SDSF-dependent functionality to an internal command or renaming it to indicate its SDSF requirement. This would allow users without SDSF to use other parts of Zowe without encountering errors. This strategy could improve user experience by preventing unexpected issues.
4. Find a Way to Get Job Status: This is the most ambitious option, aiming to decouple Zowe from SDSF by finding alternative methods to retrieve job status information. This would make Zowe more flexible and accessible but may require significant development effort. Alternative methods for job status retrieval could involve using z/OSMF APIs, or other system interfaces.

Analyzing the Options

Each of these options has its own set of advantages and disadvantages. Doing nothing is the easiest in the short term but may alienate users without SDSF. Changing the documentation is a simple way to manage expectations but does not solve the problem. Moving or renaming zwe init is a good compromise, but finding an alternative way to get job status is the ideal long-term solution.

The discussion around SDSF dependency underscores the need for Zowe to be flexible and adaptable to different user environments. A solution that accommodates users with and without SDSF access is crucial for the widespread adoption of Zowe.

The decision on how to handle SDSF dependency will significantly impact the usability and accessibility of Zowe. A careful evaluation of the proposed solutions is necessary to ensure the best outcome for the Zowe community.

The Importance of Job Status Retrieval

At the core of the SDSF dependency question is the need to retrieve job status information. SDSF provides a convenient way to access this information, but it is not the only way. Exploring alternative methods for job status retrieval is essential for reducing the dependency on SDSF. This could involve leveraging other z/OS facilities or APIs.

Finding alternative methods to retrieve job status information is a key step in making Zowe more accessible and flexible. This would allow Zowe to be used in environments where SDSF is not available or preferred.

Conclusion

The discussions surrounding schema changes and SDSF user considerations are vital for the ongoing development and refinement of Zowe. Reverting the schema validation to accept empty/null values requires a concurrent effort to update code and manage defaults manually. Addressing the SDSF dependency involves weighing different options, from documentation updates to finding alternative methods for job status retrieval. These decisions will shape the future of Zowe, influencing its usability, accessibility, and overall robustness.

The Zowe project's commitment to addressing these challenges demonstrates its dedication to creating a versatile and user-friendly platform for z/OS development and operations. By carefully considering these issues and implementing thoughtful solutions, Zowe can continue to evolve and meet the needs of its diverse user base.

Future Directions

Moving forward, the Zowe project will need to continue evaluating the best approaches for schema validation and SDSF dependency. This includes:

• Monitoring the impact of the schema reversion: It's crucial to track any issues that arise from allowing empty/null values and adjust the strategy as needed.
• Prioritizing code updates: The codebase should be updated to handle empty/null values gracefully and set defaults manually.
• Exploring alternative job status retrieval methods: Researching and implementing alternatives to SDSF will reduce the dependency and increase flexibility.
• Engaging with the community: Gathering feedback from Zowe users and developers is essential for making informed decisions.

By addressing these challenges proactively, Zowe can continue to grow and provide value to the z/OS community.

The future of Zowe depends on its ability to adapt to changing needs and address key challenges effectively. The discussions outlined in this document are an important step in that process.