Introduction to the z/OS operating system executable file

z/OS is the most advanced and modern operating system running on the IBM mainframe today. z/OS, formerly known as the OS/360 operating system, has undergone half a century of evolution since its release in 1964 and the z/Os V2R1 to be released in September this year (2013). Host operating systems for the z/OS series with high reliability (reliability), high availability (availability) and high service (serviceability), as well as I/O processing capabilities and backward compatibility (Backword compatibility) Known. On the z/OS operating system, the evolution of the executable file is a perfect illustration of the changes in the mainframe architecture and the respect of z/Os for backward compatibility. In this article I describe in detail the evolution of executable files in the z/OS operating system, including the structure, version, and supported features of the executable file. (If you want to fully understand this article, you need a reader with some background on z/OS and program compilation connections.) )

Linker basics

Before we cut into the topic, let's take a look at the basics of running files. An executable file is an operating system file that can be loaded into memory and executed by the operating system. An original file needs to be compiled or compiled to generate the target file, and then the target file is then linked to the final form of the executable file. The more common executables include portable executable (PE, portable Execute) files for Windows platforms, runnable links to Linux platforms (ELF, executable and linkable Format) files, The Mac platform can run file Mach-o (Mach object), as well as the executable LM (Load Module) and PO (program Object) in our today's lead z/OS operating system. Regardless of the executable format, some basic elements are necessary, and it is obvious that the file should contain code and data. Because files may reference external file-defined symbols (variables and functions), it is also necessary to reposition information and symbolic information. Some ancillary information is optional, such as debugging information, hardware information, and so on. Basically any type of executable file format is to save the above information in intervals, called segments (Segment) or sections (section). The meaning of the middle and section of the different file formats may be subtle, but it is clear from the context that this is not a critical issue. Finally, the executable file usually has a header to describe the overall structure of the file.

Executable Files lm and PO in z/OS

Here we go back to the z/OS operating system, focusing on our lead LM and PO. As shown in Figure 1: in z/OS we use Program Management Binder (Binder, as a linker in the z/OS operating system) to create LM and PO, if the executable file is stored in the PDS (partitioned Data Set, An older z/OS file format, the executable file will automatically become the LM format if the executable file is stored in Pdse (partitioned Data Set Extended, a new extensible z/OS file format) or HFS ( Hierarchical file System,z/os UNIX service file format), the running files will automatically become the PO format.

Figure 1: Using program Management binder to create LM and PO

After getting LM and Po, let's dive in and look at the internal structure of LM and PO. As shown in Figure 2, LM is a one-dimensional structure from the inside. All Csect on the left (Control section, code snippet, each csect can hold commands to run and load) are loadable parts that are loaded into memory at run time by the CPU. In LM, all Csect can only set a Run-time property (such as addressing, whether it is accessible, etc.), which means that all segments are the same at run time. The data segment on the right is not available and can not be read directly, and you must use the Binder tool if you want to read the data. Specific paragraph naming, we will be described in the following sections, as shown in table 2.

What's the picture 2:lm like?