15.9.2 Automatic Restart

An automatic restart in the case of an ABEND can only take place if an ABEND is actually detected; it must therefore be forced. This is the role of PLIREST.

15.10 Overlay Structures

Overlay structures defined in DOS PL/I optimizer programs can remain valid in MVS PL/I optimizer programs. However, the CALL PLIOVLY statements must be removed. MVS linkage editor facilities (PARM=OVLY, INSERT, and OVERLAY) are used to build the overlay structure as discussed below.

15.10.1 Conversion

When converting a DOS PL/I program to MVS, if the former used an overlay structure, it will be necessary to suppress all calls to PLIOVLY, which do not make sense in MVS. The overlay structure will therefore disappear, and in the majority of cases will no longer be necessary in MVS, each user having his own independent address space. Programs which rely on REFETCH of overlays to re-initialize static storage will have to remain as overlay programs or be modified.

15.10.2 Overlay in MVS

If it is still necessary to retain an overlay structure, it will be necessary to

link-edit the program specifying PARM.LKED= OVLY and providing the linkage editor with INSERT and OVERLAY control statements. This is completely independent of the PL/I source code but not of the logic of the program.

15.11 Storage Management in PL/I

15.11.1 Storage Management in DOS

In DOS, PL/I considers that all the storage available in the partition is dedicated to it. It separates storage requests into LIFO and non-LIFO. DSA allocations are LIFO requests, in particular for AUTOMATIC variables. These requests are considered as LIFO because storage is de-allocated in the reverse order to allocation. Non-LIFO requests include, among others, the allocation of CONTROLLED and BASED variables, as are requests for space for loading transient modules, and for SORT if PLISRTx is used.

15.11.2 Storage Management in MVS

In MVS, PL/I acquires an Initial Storage Area (ISA). Its size is set by default when the user installs the PL/I Transient Library. The IBM-supplied default is half the storage outside the load module. The rest is left for the operating system. The distinction between LIFO and non-LIFO remains, but note that loading of modules from the transient library is done by MVS, and this will use the storage left free by PL/I. If the storage allocated to PL/I is not enough at the start of execution, it will issue GETMAINs for that part left for the operating system. These GETMAINs can slow down the execution of the program. The amount of storage allocated by PL/I at the start of execution and the number of GETMAINs and FREEMAINs can be found by use of the REPORT option. The amount of storage space allocated by PL/I at the start of execution can be specified by the parameter ISASIZE. It is almost always worthwhile to give a PL/I program a

Chapter 15. PL/I 345

Page 369
Image 369
IBM OS/390 manual Automatic Restart, Overlay Structures, Conversion, Overlay in MVS, Storage Management in MVS

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.