individuals keep a standard LOGON ID, and change the set of filters instead of the IDs.

As an example of this set of conventions, consider a common problem of constantly shifting workloads. If the Storage Administrator was always faced with getting the data for a given application and moving it to another system, then it would make good sense to have a naming convention for the HLQ that would allow him to easily accomplish this via filtering techniques. Other reasons are for data portability to other installations for disaster/recovery situations that would cause an application to be brought up on an alien system.

One example of a naming convention for HLQs might be the following:

First Character:

-A - Accounting Support

-D - Documentation

-E - Engineering

-F - Field Support

-M - Marketing Support

-P - Programming

-$ - TSO user ID

An alternative here is to use one of the characters above as the first character of the TSO user ID to allow movement of all data within an application (including the TSO data). This is not the way recommended

by the author -- the preference would be a standard code for TSO, such as ²$².

The above list does not represent all of the possibilities. For example, a bank might have separation of HLQs by major application such as checking, savings, mortgage loans, investments or ATM. An insurance company might have applications such as life, auto, personal insurance, major medical and corporate accounts.

-Remaining Characters = Project Name or Code Number

Note: This might have been chosen because a project code might exist for programming, engineering, documentation, and accounting, but it does not imply that one must do it that way. It has been the experience of the author that similar project codes would not be common.

A more natural idea is to have the actual project name following the first character. For example, the remaining portion of the ²E² project could be the code name of the machine being designed, while a ²P² project could be the name of the programming application or product name.

Some examples might be:

-E3090M150

-E3090M200

-E3090M300

-E3090M400

-E3090M500

-E3090M600

-E3380K

-E3380J

Appendix C. DFSMS Naming Conventions 545

Page 569
Image 569
IBM OS/390 manual Appendix C. Dfsms Naming Conventions

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.