Appendix C. DFSMS Naming Conventions

This chapter was written by John Tyrrell of IBMs Storage Systems Division. John is one of the original senior architects of DFSMS. He also invented TMM (Tape Management Methodology) and is the author of the Volume Mount Analyzer program which is part of DFSMSdfp. He is the senior architect/inventor of the DFSMS Optimizer product, one of the major components of DFSMS. John interacts with a wide variety of IBM customers, and has personally been to over 600 customer data centers and participated in over 350 tape and DASD studies to better understand and address IBM customer needs.

John spent 10 years in application development of a system with six million lines of code which ran in over 60 IBM data centers. Many of the data set naming techniques in this document were developed based on both Johns application experience as well as working with IBM customers.

This chapter offers suggestions on the naming of data sets such that you would be able to fully exploit the technology of both DFSMS and MVS/ESA. It does not imply that you must rename all of your data, nor does it imply that these are the only conventions that will work under DFSMS and MVS/ESA.

These naming conventions are suggestions resulting from many visits and interactions with IBM internal and IBM customer application areas. These suggestions reflect both the opinion and the experience of the author, and as such, do not necessarily represent the view of the IBM Corporation.

As with all standards, they should act as a guide for the reader. The reader, in this case, should really be the application designer. This is the person who will set up all of the JCL, CLISTs, ISPF panels, JCL skeletons, JOB networks and so on in order to run the major application. He or she is usually the person who sets up the standards to be applied to all procedures involved with running a major application.

It is recommended that the reader go through the entire chapter, and then build his or her own set of rules based on the suggestions offered here as applied to the particular application in question.

C.1 Data Set Naming Guidelines

The purpose of this chapter is to offer some guidelines as to what constitutes proper data set naming conventions. This would allow customers to easily exploit the functions of DFSMS for the proper assignment of System Managed Storage (SMS) policies to manage the data. Although the ACS (Automatic Class Selection) Routines will allow the Storage Administrator to filter on more than just data set name, the name of the data set is fundamentally important. Some of these advantages are listed below:

It allows more flexibility for the assignment of levels of service to data sets

It is easier to write/maintain ACS Routines

The ACS Routines are more durable (that is, meaningful over time)

Data set filters can be useful for other storage management techniques (for example, ISMF, DFDSS)

© Copyright IBM Corp. 1998

543

Page 567
Image 567
IBM OS/390 manual Appendix C. Dfsms Naming Conventions, Data Set Naming Guidelines, 543

OS/390 specifications

IBM OS/390, a versatile operating system, was a cornerstone in enterprise environments and played a pivotal role in mainframe computing. Released in the mid-1990s, OS/390 combined the strengths of IBM's MVS (Multiple Virtual Storage) with new features and enhancements, targeting scalability, reliability, and performance in demanding business applications.

One of the key features of OS/390 was its robust support for multiple users and processes. The system allowed thousands of concurrent users to access applications and data, ensuring high availability and minimizing downtime—a critical requirement for many large organizations. This scalability was supported through various enhancements in memory management and processor scheduling, enabling optimal resource allocation across diverse workloads.

OS/390 was known for its superior workload management capabilities. The Workload Manager (WLM) component allowed administrators to define service policies, specifying how system resources would be allocated according to the priority of tasks. This ensured that critical business processes received the necessary resources while less critical tasks were managed more flexibly.

Another significant characteristic of OS/390 was its commitment to security. The operating system provided comprehensive security features, including user authentication, data encryption, and auditing capabilities. This focus on security was vital for organizations handling sensitive data, ensuring compliance with regulations and safeguarding against unauthorized access.

OS/390 also supported advanced technologies that facilitated integration and development. The system included features like the IBM CICS (Customer Information Control System) for transaction processing and IMS (Information Management System) for database management. These technologies allowed organizations to build robust, high-performance applications tailored to specific business needs.

The ease of network integration was another strength of OS/390. With the advent of the Internet and global connectivity, OS/390 systems could easily interface with various network protocols, enabling businesses to operate in a connected world. This inclusion paved the way for many organizations to expand their capabilities and offer new services, driving digital transformation.

In conclusion, IBM OS/390 represented a significant advancement in mainframe technology, combining scalability, security, and robust workload management. Its rich feature set and support for critical enterprise applications solidified its role as a vital component of many organizations' IT infrastructures, ensuring they could meet their operational challenges head-on while supporting future growth. As technology continues to evolve, the legacy of OS/390 remains influential in the realm of computing.