[Info-vax] Ignorance promenade: On the nature of patching VMS

[glen herrmannsfeldt]

Bob Gezelter <gezelter at rlgsc.com> wrote:
> On Friday, December 13, 2013 6:15:25 PM UTC-5, Subcommandante XDelta wrote:

(snip)

>> Is it possible that certain adustments to deep levels of VMS could not
>> be achieved by the issuing of a patch, but would require the complete
>> recompilation of the VMS kernel image?

(snip)

> Actually, the elimination of binary "patching" is not so much a 
> switch in architecture from VAX to Alpha, but the advent of 
> compiled languages in system-level products.
 
> When writing in traditional assembler, it is not difficult to 
> determine precise addresses to modify (frequently inserting 
> a out-of-line transfer or call if more space is needed). 
> When using a compiled language, such micro-level detail 
> becomes difficult to manage for the purposes of patching. 
> It is far simpler to replace the component image with a 
> new version.

I suppose, but you could have a program go through to object
programs and record the differences.

In the early assembler days, though, it was usual to include a
patch area in the program to allow for patching. You would have
to be careful when making changes such that most of the bytes
wouldn't change.

The OS/360 object format has an address and length on each record (card)
such that one can patch object programs by adding new records at the
end, to write over previously defined bytes.

The OS/360 linkage editor can replace CSECTS inside already linked
load modules. That is, it can actually do editing, not just linking.

One that was commonly done in the early days of virtual storage was
to relink the Fortran H compiler to remove the overlay structure.
(Unless you add the appropriate control cards, it isn't preserved
when a load module is input to the link editor.)

Seems to me it is both the increase in high-level languages,
and the increase in the size of tapes that allows for less patching.

-- glen