Here goes: Me: Describe the impacts of either disabling the RLSE subparameter of SPACE= in z/OS JCL on RAID drives or having RLSE only release unused extends on RAID drives. Consider the savings in avoiding unnecessary VTOC updates. Which is better, changing RLSE to only release unused extends, or disabling RLSE and running periodical utilities (vendor or site) to release unused extends? Assume that the majority of dataset of the legacy type with a limit of 16 extents. Consider and identify any program products or access methods that already specify TYPE=T with the CLOSE macro. Consider, as an alternative to the first cases, a new DISP= option, ASIS, which would become OLD if the dataset exists and NEW if said dataset did not exist.
The Resource Limit Specification Exception (RLSE) subparameter of SPACE= in z/OS Job Control Language (JCL) is designed to release any unused allocated space when the data set is closed. This means that if your program allocates more space than it uses, the RLSE option will make that unused space available for other programs to use, which can be important in ensuring efficient use of disk space. Disabling RLSE can lead to wasted space if a job frequently over-allocates, as unused allocated space remains assigned to the data set even after the job has ended. On RAID drives, this can contribute to unnecessary fragmentation and inefficient use of storage. However, there can be a performance trade-off because releasing unused space involves updating the Volume Table of Contents (VTOC), which is an I/O operation that can impact system performance. Hence, in systems where performance is critical and storage is less of a concern, you might prefer to disable RLSE to avoid these VTOC updates. In your scenario, where the majority of data sets are legacy types with a limit of 16 extents, it may be advisable to consider how often these data sets reach their maximum extent limit. If they often do, RLSE could potentially result in many VTOC updates, affecting performance. Conversely, if they rarely reach this limit, the impact of RLSE might be minimal. As for the question of whether to change RLSE to release only unused extends, or to disable RLSE and run periodic utilities to release unused extends, this depends on your specific circumstances. The former approach would likely lead to more frequent but smaller VTOC updates, while the latter could result in less frequent but larger updates. In high-performance, low-storage environments, the latter may be preferred. In environments where storage is at a premium, the former may be the better option. If you're considering program products or access methods that already specify TYPE=T with the CLOSE macro, this typically indicates that these are temporary data sets. These data sets are usually deleted and their space released automatically when the job ends, making RLSE redundant in this context. Lastly, regarding the new DISP= option, ASIS, which becomes OLD if the dataset exists and NEW if it doesn't, this could offer more flexibility in managing data sets. It could potentially reduce the need for JCL modifications when rerunning jobs or handling rerun scenarios. However, it would also require careful consideration of job flow and dependencies, as it could have unexpected consequences if not properly managed. In summary, the best approach depends on your specific circumstances, such as the nature of your workloads, the typical size and number of extents in your data sets, the performance and storage characteristics of your RAID drives, and the specifics of your operating environment. It's advisable to conduct performance and impact testing before making any significant changes. [image: User] Me: In z/OS JCL RLSE is short for ReLeaSE. Yes, you are correct. In IBM's z/OS Job Control Language (JCL), RLSE stands for ReLeaSE. The RLSE keyword indicates that, when a job finishes, the system should release all unused allocated space associated with a dataset. This can be a useful strategy for managing disk space, especially in situations where the exact amount of space needed may not be known in advance and over-allocation might occur. The impact of enabling or disabling RLSE really depends on the specific context. For instance, if a dataset often ends up using less space than allocated, having RLSE enabled can help save valuable disk space. However, keep in mind that releasing space involves updating the Volume Table of Contents (VTOC), which is an I/O operation and can potentially impact system performance. Therefore, deciding whether to use RLSE, or modify its behavior, or even to run periodic utilities to manage unused space, should be based on an assessment of your system's specific needs and constraints. It's all about finding the right balance between efficient space utilization and system performance. [image: User] Me: ASIS is a hypothetical proposal, not yet submited as a requirement. I see, thank you for the clarification. The concept of an ASIS option for the DISP= parameter in JCL is indeed an intriguing proposal. To recap, the proposed functionality would assign the dataset status as OLD if it already exists and NEW if it doesn't. This functionality could potentially simplify JCL code and provide dynamic handling for rerun scenarios. In today's JCL, the DISP= parameter requires the status to be explicitly stated as NEW, OLD, or SHR, depending on whether you want to create a new dataset, reuse an existing one, or share an existing dataset. While such an ASIS option could provide some flexibility and efficiency, it would require careful management and rigorous testing to ensure no unintended consequences occur due to ambiguous dataset statuses. And as with any proposed change to a system as critical and widely used as JCL, it would need to go through a significant review and approval process before being implemented. [image: User] Me: The discussion on RLSE applies primarily to RAID drives, which are very common in large installations. Indeed, you are correct. The discussion of the RLSE (ReLeaSE) subparameter of SPACE= in JCL is especially relevant in the context of RAID drives, which are prevalent in large-scale systems such as those found in enterprise environments. RAID (Redundant Array of Independent Disks) technology allows for the combination of multiple physical disk drives into a single logical unit for the purposes of data redundancy, performance improvement, or sometimes both. The inherent redundancy of RAID arrays makes them well-suited to high-availability environments where data loss can be particularly damaging. The RLSE subparameter can have specific implications for RAID drive usage. As previously mentioned, RLSE instructs z/OS to release unused allocated space when a dataset is closed. With the use of RAID technology and its chunking and striping methods of writing data, this could result in unnecessary fragmentation if RLSE is disabled, and therefore inefficient use of disk space. However, enabling RLSE also implies that each time a job is finished and unused space is released, the system must update the Volume Table of Contents (VTOC), which could impact system performance. In highly transactional environments often associated with RAID configurations, this might have a noticeable effect. The balance between storage efficiency and performance is a crucial consideration when configuring RAID-based systems in z/OS. It's also important to consider the potential impact of other system parameters and processes, including but not limited to, the allocation of extents, the frequency of VTOC updates, and the use of temporary datasets and their associated system commands. Therefore, system administrators must carefully evaluate the needs and constraints of their specific environments before making decisions about enabling or disabling RLSE or any other storage or system parameter. [image: User] Me: Disabling RLSE on RAID drives would not affect space usage on physical (host) drives. As far as fragmentation on logical (guest) drives, on the contrary, fragmentation would be reduced. Thank you for the correction and I apologize for the oversight. In a virtualized environment, like one where z/OS is running on a guest system, the relationship between RLSE and space management becomes more complex. When using virtualization, the management of physical (host) and logical (guest) storage is abstracted. The host system's storage management handles the underlying physical storage including RAID drives, while the guest systems (like z/OS) manage their logical view of storage. When RLSE is disabled, z/OS would keep the unused space associated with the dataset. This could actually lead to reduced fragmentation on the logical drives from the z/OS perspective, since it keeps the unused space as a contiguous block instead of releasing it back into the pool of free space to be allocated elsewhere. On the physical storage side, this would not necessarily affect space usage because virtualization typically involves thin provisioning, where physical storage is allocated on-demand as the guest system actually writes data rather than when the guest system allocates space. Therefore, disabling RLSE could potentially lead to more efficient use of space on the guest system, depending on the characteristics of the workloads running on it, by reducing fragmentation and the number of extents. However, as always, these decisions should be made based on a careful analysis of the specific requirements and constraints of your environment, considering factors like the nature of your workloads, your storage capacity and performance needs, and the specifics of your virtualization setup. [image: User] Me: We are not talking about guest systems, only the logical, emulated drives resident on RAID drives. 2 / 2 Thank you for the clarification. In the context of z/OS operating with emulated drives resident on RAID drives, RLSE could indeed impact the way storage is handled. When RLSE is enabled, it releases any unused allocated space when the dataset is closed, which can result in smaller, more fragmented sections of available space in the logical view of the storage. If RLSE is disabled, this would mean that any over-allocated but unused space would remain assigned to the respective dataset even after it is closed. This could indeed lead to reduced fragmentation in the logical view of the storage, since the unused space is kept as a contiguous block and not returned back to the pool to be allocated elsewhere. However, the notion of 'fragmentation' is somewhat less applicable at the logical level than at the physical level, especially in the case of RAID storage. The abstraction provided by RAID can scatter data across multiple drives, and the RAID controller handles the complexities of these operations transparently. >From a storage efficiency standpoint, it's essential to understand that disabling RLSE could potentially result in more efficient space use on the logical drives, as it keeps allocated but unused space associated with the dataset even after it's closed. But this might also mean that over-allocated space that isn't used could remain locked, effectively lowering the available space. As always, the decision to enable or disable RLSE should be based on a careful evaluation of the specific workloads, storage needs, and operational requirements. It's also important to note that this discussion is part of a broader strategy of storage management, including allocation strategies, VTOC updates frequency, and overall system performance. [image: User] Me: The use of RLSE on logical, RAID resident drives is more relevant to the 16 extent limit of conventional z/OS datasets. On such datasets, RLSE may cause the last extent to be trimmed to a smaller extent than were originally allocated, especially if the dataset in question grows modestly. Doing so repeatedly could result in many small extents, and the dataset no longer having the ability to grow to that allowed by it's original SPACD= specification. As such, it limits the ability to reuse the dataset on a regular basis. In turn, it becomes necessary to delete and recreate the dataset every time it is used. Typically, this is done with IEFBR14, without the understanding that, most of the time, a perfectly good dataset is being deleted just to recreate it. This wastes resources due to unnecessary catalog and VTOC churn. Thank you for the elaboration, and you've highlighted an important consideration in managing datasets on z/OS systems. Indeed, the use of the RLSE parameter in the SPACE= specification can lead to increased fragmentation, especially in datasets that grow incrementally. Since RLSE will release any unused space when the dataset is closed, this can cause the last extent to be smaller than initially allocated if the dataset grows modestly. If this process is repeated, it could lead to the creation of many small extents, which then could reach the 16-extent limit of conventional z/OS datasets more quickly. As you rightly point out, reaching this limit prematurely can hinder the ability to reuse the dataset on a regular basis. Consequently, to regain the full growth potential originally specified in the SPACE= parameter, one would have to delete and recreate the dataset every time it is used, often done with the IEFBR14 utility. While deleting and recreating datasets ensures the maximum potential space for growth, it can certainly result in unnecessary overhead due to catalog and VTOC updates (the churn), thus consuming more system resources. In this context, disabling RLSE could be a better strategy for managing such datasets, especially those that are reused frequently and grow modestly with each use. By retaining the unused allocated space, the dataset can continue to grow within its originally allocated extents, potentially reducing the need for additional extents and thus avoiding hitting the 16-extent limit prematurely. As always, it's crucial to weigh the benefits and drawbacks of each approach and consider the specifics of your workloads and operational needs when deciding on the best strategy for managing datasets in a z/OS environment. [image: User] Me: Furthermore, the SPACE= specification on the initial IEFBR14 step, if used to pre-allocate space, must be consistent with the usage where the dataset is actually written to. By being separate from the actual step that does the writing, it can be overlooked during software maintenance. Is there any evidence that IBM or another vendor is considering or addressing these issues, either by an existing feature, a sysgen option, a customer requirement, a statement of direction, etc.? As of my knowledge cutoff in September 2021, I am not aware of any specific IBM or other vendor initiative to address the concerns you've described related to the use of the RLSE parameter and the management of dataset extents in z/OS. However, IBM regularly updates and enhances its z/OS operating system based on customer feedback and technological advances, so it's possible that they may address these issues in the future. I would recommend reaching out to IBM or your vendor directly for the most up-to-date information. Also, participating in user groups like SHARE or attending IBM technical conferences could provide insights into future developments and allow you to raise these issues directly with the IBM team. In the meantime, it would be beneficial to establish internal processes and guidelines to handle these issues. This could include implementing rigorous change management and review processes to ensure the SPACE= specifications are consistent across all steps that handle a dataset. Also, regularly reviewing your dataset management practices and providing training and awareness to your team about the implications of the SPACE= parameters and the extent limitations of datasets can help mitigate these issues. [image: User] Me: Is the proposed addition of DISP=ASIS the best solution in terms of resources, JCL volume, simplicity, etc. or is there a better solution? Adding a DISP=ASIS parameter could certainly provide a level of dynamic flexibility that is not currently inherent in JCL, as it would potentially allow for more streamlined JCL code by not requiring explicit definition of a dataset's disposition (NEW, OLD, or SHR). >From a resources and JCL volume perspective, DISP=ASIS could potentially reduce the amount of JCL code needed for jobs, especially for those jobs that frequently need to handle rerun scenarios or dynamically determine the disposition of a dataset. In terms of simplicity, it could potentially reduce the cognitive load for programmers and operators by not requiring them to explicitly specify or change the dataset's disposition. This can reduce the potential for errors and increase productivity. However, the introduction of DISP=ASIS would also need to be carefully planned and managed. The ASIS behavior could lead to unexpected consequences if not correctly understood or managed, and it would need to be thoroughly tested in your environment to ensure it behaves as expected and does not introduce new issues. Also, existing processes, tools, and possibly even applications that analyze or generate JCL code would need to be updated to handle the new DISP=ASIS parameter. As with any proposed solution, the "best" solution will depend on the specific needs, constraints, and characteristics of your environment. While DISP=ASIS could provide significant benefits in terms of reduced JCL code and increased flexibility, these benefits need to be weighed against the potential costs and risks associated with its implementation. Ultimately, a combination of techniques might be necessary for optimal dataset management. This could include careful use of the SPACE= parameters, consistent dataset naming conventions, effective use of IEFBR14 to initialize datasets, rigorous change management processes to ensure consistent SPACE= specifications, and possibly the proposed DISP=ASIS parameter, if it were to be implemented. OREXXMan Q: What do you call the residence of the ungulate with the largest antlers? A: A moose pad. :-D Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Sat, Jul 1, 2023 at 8:15 AM Walt Farrell <walt.farr...@gmail.com> wrote: > On Thu, 29 Jun 2023 18:10:06 -0500, Hobart Spitz <orexx...@gmail.com> > wrote: > > >https://chat.openai.com/share/1718b445-7a89-47a3-ab23-b670aa8c2211 > > That URL gives a 404 error, for me. > > Perhaps you could have your conversation again, and quote the conversation > here directly next time? > > -- > Walt > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
