We are upgrading version of COBOL at our installation from 4.2 to 5.1. The upgrade involves updates to the compiler options, which are definitely the options that we specify in our compile jobs with IGYCRCTL.
Similar options are used in the link-edit jobs with IEWL - for instance LIST, MAP, AMODE, etc.. I believe that these options work similar to how the compiler options work but are these options really impacted with the COBOL upgrade? So is the linkage editor part of COBOL or z/OS or something else? Is there a place where I can find the complete list of these link-edit options?
Joined: 10 May 2007 Posts: 2454 Location: Hampshire, UK
Quote:
Is there a place where I can find the complete list of these link-edit options?
The link-edit, now called Binder, manual.
Quote:
is the linkage editor part of COBOL or z/OS or something else
It is just another program that takes the output of a compiler - not just the COBOL compiler - links/binds system routines with the object module to create a load module (or whatever it is called nowadays). This is a simplistic description but should be enough to get you on your way.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
The Binder and Linkage Editor are part of MVS, e.g., the operating system.
Yes, if you spend some quality time with the manuals, you will find the Linkage Editor is still included with the operating system, though it is now program name HEWLKED. The Binder does everything the Linkage Editor does, though there are some differences that rarely affect most of us.
The Linkage Editor has always had some severe performance issues. Back in the days of OS/360 there was always a plan to provide a high performance Linkage Editor, though this was never accomplished. In a very real sense the Binder is the culmination of the high performance Linkage Editor. When the Binder was released in the 1990s, I can still recall that large SMP jobs ran noticeably faster than equivalent jobs ran with the Linkage Editor.
Joined: 31 Oct 2006 Posts: 1050 Location: Richmond, Virginia
Back in the day I had a very big PL/I program that took about one hour to compile with optimization. There were some periodic changes that could, however, be incorporated into a subroutine.
We compiled the main program and saved the object code (compiler output).
When the subroutine changes were required, we (quickly) re-compiled the subroutine, and then just reran the link edit step.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Phrzby Phil is correct. An important characteristic of load modules (and program objects) in MVS is they retain their external symbols, so it is usually possible to replace individual modules in a load module as Phrzby Phil described. It is not necessary to retain the object output from the compilation as appears to be the case in toy and baby systems.
The whole point of SMP and the maintenance philosophy in MVS is maintenance is done by distributing just the object, and SMP directs the Linkage Editor (or Binder) to link just the object into the load modules. The SMP data base includes a list of the modules in the load modules that make up the system, so it can direct the Binder to build replacement load modules.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
A little history here, not that anyone cares.
The first OS/360 Linkage Editor was a disaster, in part because it had to run in very little storage (probably around 12K). Its load modules were restricted to text blocks of 1K. Worse, perhaps, it was unable to combine multiple CSECTs in one text block. In other words, load modules loaded s-l-o-w-l-y. Obviously, it ran s-l-o-w-l-y.
By the time I started using OS/360 in 1968, a second version of the Linkage Editor was in use. The same basic code survived for 30 years. While it wasn't "great" it was good enough. There were 3 variants.
The first variant was designed to run in 44K.
The second variant, by far the most common, ran in 88K.
The third ran in 128K.
These storage amounts, while trivial today, were important. Storage in the 1960s was horribly expensive. For all intents and purposes, the minimal usable OS/360 machine had 128K and ran the 88K version of the Linkage Editor.
In reality, there was one code base. The only difference between the three variants was how they were link edited. The 44K Linkage Editor was in a complex planned overlay structure. The 88K Linkage Editor was in the classic 3 segment overlay structure. The 128K Linkage Editor was a simple load module.
A few years later brought the virtual storage systems and the OS/VS Linkage Editor with a few improvements, and a major downgrade. It was link edited into the 44K overlay structure! Worse, and I tried it once, it would not run linked as a simple load module like the old 128K OS/360 Linkage Editor!
It stayed this way for more than 20 years until the Binder arrived to effectively replace the Linkage Editor. Since there were some differences, the old OS/VS Linkage Editor is still around, though it is no longer linked into old 44K planned overlay.
