Application Location, Management Criteria

C.3.2 Application Location

If this application ever got moved to another site, then all of the data sets would have to be renamed. In some cases, it could be important to name the data by a location name, for example, CHICAGO. This could be perfectly acceptable in certain cases. Suppose there were two telephone directory files,

²TELPHDIR.CHICAGO² and ²TELPHDIR.PODUNK². This would be okay. That¢ s because it is very unlikely that either Chicago or Podunk would ever move.

Application workload is another story. For example, if an application currently runs in Chicago, or Podunk, one might be tempted to include this as part of the data set name for disaster/recovery purposes. If there is a chance of moving these applications to run in a different location, then it would be a bad idea to imbed it into a name.

C.3.3 Management Criteria

This type of generic criteria that some people recommend is the notion of identifying disaster/recovery data, or vital records, for example within the data set name. In general, it is not a good idea to imbed management criteria within the data set name, since it is mainly driven by the technology at hand. They may also change for business reasons (for example, a change in the state laws).

If either the technology or the business reason changes, then the data set would have to be renamed to match it. One should simply name the data for what it is and keep its management policy separate.

Therefore, it is not a good idea to specify qualifiers such as ²DR² or ²VITALREC². By always naming the data for what it is, the policy for managing it can be kept separately without ever needing to rename the data.

C.3.4 Output Device Type

This is a general class of information that is also based on a certain level of technology. As technology improves, you may very well decide to change the way it is managed. For example, you might put a data set qualifier of MICROFIC to indicate that this data set should be put out to microfiche -- whereas somewhere in the future, one could envision this same piece of data being put to

ahigh-speed link which is connected to some automated high-capacity storage device.

Qualifiers such as ²TAPE² or ²DISK² or ²T3480² or ²T3490² should never be coded in data set names. This type of qualifier is destined for change as newer device technologies are created.

C.3.5 Expiration Date

The EXPDT and RETPD allocation keywords associated with the data set are another form of management criteria in that they specify the purge date for data. These keywords clearly put storage management in the hands of the end users.

To change the policy, you must change the date associated with the data set. This is just as bad as forcing the application to go back and re-figure the new management criteria. It represents a policy of sorts and therefore, should be separated from the name itself. This type of information should be allowed to change without actually changing the name of the data.

548VSE to OS/390 Migration Workbook

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.

IBM OS/390 manual Application Location, Management Criteria, Output Device Type, Expiration Date

Models: OS/390