History notes . . .

The Great IBJOB Subroutine Linkage Controversy

by Conrad Weisert, June 1, 2012
ŠInformation Disciplines, Inc.

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.

Why is this interesting today?

Two years ago we examined The Great Green Words Controversy in which the SHARE user group prevailed over vendor bureacracy that had seemed immovable. The result was the avoidance of a serious incompatibility within the most widely used operating system of the 1960s and 1970s.

Several readers have asked whether that wasn't an extremely unusual, if not unique, victory for the "good guys" in a community of users. No, indeed. Two years earlier, the same adversaries, SHARE and IBM, had faced a similar impasse, and again SHARE prevailed.1

Let's look at the technical issue and its resolution. We'll also show how this incident set precedents from which today's computer users derive benefit and teach us lessons we could apply in the future.

A standard subroutine linkage convention

On the IBM 704 computer and later its solid-state successors the conventional way of invoking a subroutine was to execute a TSX (transfer and set index) instruction to branch to the subroutine and set the return address in index register 4. This convention was respected by assembly language programs and by object code generated by the Fortran compiler and other higher-level language processors.

A new operating system and a proposed new linkage convention

By 1962 it was recognized that the operating systems in general use were obsolete and that there were too many versions with minor and major incompatibilities. An entirely new operating system was needed to bridge the gap until the next generation2 computer systems.

Accordingly at the SHARE meeting in August, 1963, IBM unveiled IBSYS-IBJOB and a family of new processors for Fortran and Cobol. They proudly brought to the meeting piles of users' manuals describing the workings of those systems in detail.

Careful readers of those manuals noticed something IBM hadn't emphasized in its release announcements:   a new conventional subroutine linkage, incompatible with the old TSX one and subject to possible bugs: Instead of

programs would invoke a subroutine by:
   STL SYSLOC     * Save the instruction counter 
   TRA PROGNAME   * Branch to the routine
When questioned IBM explained that by freeing index register 4 from its former role in subroutine linkage, the compiler writers would have one more register to use in their sophisticated optimization algorithms. Who could possibly object to that?

Obvious and subtle objections

The first reaction from those who examined the manuals was an angry complaint that years worth of legacy programs were being invalidated and would require changes to comply with the new convention.

But careful readers noticed a more serious problem: The new convention wouldn't work if an interrupt occured after the STL instruction and before the called routine had a chance to move the return address from the global SYSLOC cell to a local place. Suppose the interrupt-handler should itself invoke a subroutine using the same convention; then the original return address would be lost, and the system would crash or go into an infinite loop.

"Not a problem," the IBM representatives answered confidently at a late-night meeting in a smoke-filled hotel room. The new convention is only for user programs; system code, such as operating system interrupt handlers, will follow the old convention or have its own way of invoking subroutines!

SHARE representatives reacted angrily. The operating system should observe its own conventions, they asserted. If a standard technique was good enough for the users it ought to be good enough for IBM. Besides, there were situations in which an interrupt handler would invoke a specified user-program "exit" to handle an exception condition such as an end-of-file.

At that point the IBM representatives fell back upon what they thought was the final argument:   It was too late to make such a disruptive change! The beautiful manuals3 had been printed and distributed. The compilers were already generating code using index register 4 for other purposes. To change now would cost a fortune and delay the release of this wonderful new operating system.

A frustrated SHARE representative wrote on the blackboard:

It may be too late already, but it's not as much too late now as it will be later.

After several hours of heated discussion the IBM representatives agreed to check with their management, and the SHARE representatives prepared to inform the various committees that would have a strong opinion. A few days later, IBM agreed to return to the old standard linkage convention.

The saying on the blackboard became part of SHARE lore and was applied later to a number of other IBM controversies.

Two lessons

One success

As far as I know that decision marked the end of the era in which system code would freely deviate from the rules that the system imposed upon its users. For example, when OS/360 was released two years later, IBM elected not to include a special SYSGEN program to customize a customer's operating system. Instead the process relied entirely upon the utility programs that were part of the operating system, available to any user. Some users complained that the resulting SYSGEN process was tedious and error prone, but they eventually got used to it and appreciated its flexibility.

And one failure

The other lesson should have been that the user community, when organized and working together, can bring considerable influence upon even the biggest vendors. Unfortunately, owners of $500 computers have a hard time organizing in a way comparable to the owners of $2 million computers, and no organization exists today with the resources and influence of SHARE. Large government and corporate user organizations, however, should keep in mind the SHARE precedents and be prepared to take action when circumstances warrant it.

1—I'm proud to recall playing a role in resolving both controversies.
2—The System/360 and its system software were announced in April, 1964 and delivered to customers a year or two later.
3—I wish I had thought to save one of those manuals. It would have become a collector's item.

Last modified June 5, 2012

Return to IDI home page
Historical notes.